Re: [PATCH] ASoC: rsnd: Document R-Car M3-N support
Hi > From: Hiroyuki Yokoyama > > Document support for the sound modules in the Renesas M3-N (r8a77965) > SoC. > > No driver update is needed. > > Signed-off-by: Hiroyuki Yokoyama > Signed-off-by: Yoshihiro Kaneko > --- Acked-by: Kuninori Morimoto
Re: [PATCH 1/9] ARM: dts: porter: Add missing PMIC nodes
On 07/23/2018 11:03 AM, Geert Uytterhoeven wrote:
> Hi Marek,
Hi,
> On Sun, Jul 22, 2018 at 2:07 PM Marek Vasut wrote:
>> On 07/20/2018 06:38 PM, Sergei Shtylyov wrote:
>>> On 07/20/2018 03:05 PM, Simon Horman wrote:
From: Marek Vasut
Add PMIC nodes to Porter and connect CPU DVFS supply. There is
one DA9063L and one DA9210 on Porter, the only difference from
the other boards is that DA9063L is at I2C address 0x5a rather
than 0x58 .
Signed-off-by: Marek Vasut
Reviewed-by: Geert Uytterhoeven
Signed-off-by: Simon Horman
---
arch/arm/boot/dts/r8a7791-porter.dts | 33
+
1 file changed, 33 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7791-porter.dts
b/arch/arm/boot/dts/r8a7791-porter.dts
index a01101b49d99..5f77d73d7462 100644
--- a/arch/arm/boot/dts/r8a7791-porter.dts
+++ b/arch/arm/boot/dts/r8a7791-porter.dts
@@ -375,10 +375,43 @@
clock-frequency = <40>;
};
+ {
+status = "okay";
+clock-frequency = <10>;
+
+pmic@5a {
+compatible = "dlg,da9063l";
+reg = <0x5a>;
+interrupt-parent = <>;
+interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+interrupt-controller;
>>>
>>>Without a label and #interrupt-cells?
>>
>> Just like the other boards do. What's the problem here ?
>
> Does it support external interrupt inputs? Or only the internal
> interrupt sources?
The PMIC itself no, but the mfd subdevices do (ie. the GPIO block, for
which we don't have driver), see drivers/mfd/da9063-irq.c .
> If the former, it needs at least #interrupt-cells (also in the DT bindings).
[...]
--
Best regards,
Marek Vasut
Re: [PATCH V2 4/5] PCI: rcar: Support runtime PM, link state L1 handling
On 06/13/2018 07:25 PM, Bjorn Helgaas wrote:
> On Wed, Jun 13, 2018 at 04:52:52PM +0100, Lorenzo Pieralisi wrote:
>> On Wed, Jun 13, 2018 at 08:53:08AM -0500, Bjorn Helgaas wrote:
>>> On Wed, Jun 13, 2018 at 01:54:51AM +0200, Marek Vasut wrote:
On 06/11/2018 03:59 PM, Bjorn Helgaas wrote:
> On Sun, Jun 10, 2018 at 03:57:10PM +0200, Marek Vasut wrote:
>> On 11/17/2017 06:49 PM, Lorenzo Pieralisi wrote:
>>> On Fri, Nov 10, 2017 at 10:58:42PM +0100, Marek Vasut wrote:
From: Phil Edworthy
Most PCIe host controllers support L0s and L1 power states via ASPM.
The R-Car hardware only supports L0s, so when the system suspends and
resumes we have to manually handle L1.
When the system suspends, cards can put themselves into L1 and send a
>>>
>>> I assumed L1 entry has to be negotiated depending upon the PCIe
>>> hierarchy capabilities, I would appreciate if you can explain to
>>> me what's the root cause of the issue please.
>>
>> You should probably ignore the suspend/resume part altogether. The issue
>> here is that the cards can enter L1 state, while the controller won't do
>> that automatically, it can only detect that the link went into L1 state.
>> If that happens,the driver must manually put the controller to L1 state.
>> The controller can transition out of L1 state automatically though.
>
> From earlier discussion I thought the R-Car root port did not
> advertise L1 support.
Which discussion ? This one or somewhere else ?
>>>
>>> https://lkml.kernel.org/r/hk2pr0601mb1393d917d343e6363484ca68f5...@hk2pr0601mb1393.apcprd06.prod.outlook.com
>>>
>>> Re-reading that, I think I see my misunderstanding. I was only
>>> considering L1 in the ASPM context. I didn't realize the L1
>>> implications of devices being in states other than D0.
>>>
>>> Obviously L1 support for ASPM is optional and advertised via Link
>>> Capabilities. But per PCIe r4.0, sec 5.2, L1 support is required for
>>> PCI-PM compatible power management, and is entered "whenever all
>>> Functions ... are programmed to a D-state other than D0."
>>>
>>> So I guess this means *every* device is supposed to support L1 when it
>>> is in a non-D0 power state. I think *this* is the case you're
>>> solving.
>>>
>>> A little more of this detail, e.g., that this issue has nothing to do
>>> with ASPM, it's probably an R-Car erratum that the RC can't transition
>>> from L1 to L0, etc., in the changelog would really help clear things
>>> up for me.
>>
>> I think that the issue is related to the L0->L1 transition upon system
>> suspend (ie the kernel must force the controller into L1 when all
>> devices are in a sleep state) and for this specific reason I still think
>> that checking for a PM_Enter_L1 DLLP reception and doing the L0->L1
>> transition within a config access is wrong and prone to error (what's
>> the rationale behind that ?), this ought to be done using PM methods in
>> the host controller driver.
>
> But doesn't the problem happen whenever the link goes to L1, for any
> reason? E.g., runtime power management might put an endpoint in D3
> even if we're not doing a whole system suspend. A user could even
> force the endpoint to D3 by writing to PCI_PM_CTRL with "setpci". If
> that's the case, I don't think the host controller PM methods will be
> enough to work around the issue.
I think so, it's the link that goes into L1 state and this can happen
without any action from the controller side.
> The comment in the patch ("If we are not in L1 link state and we have
> received PM_ENTER_L1 DLLP, transition to L1 link state") suggests that
> the R-Car host doesn't handle step 10 in PCIe r4.0, sec 5.3.2.1
> correctly, i.e., it doesn't complete the transition of the link to L1.
>
> Putting this workaround in the config accessor makes sense to me
> because in this situation the endpoint thinks it's in L1 and it won't
> receive TLPs for config accesses. Apparently forcing the RP to L1
> completes the L1 entry, and the RP correctly handles the "Exit from L1
> State" (sec 5.3.2.2) that's required when the RP needs to send a TLP
> to the endpoint.
>
> I think there's still a potential issue if the endpoint goes to a
> non-D0 state, the link is stuck in this transitional state (endpoint
> thinks it's L1, RP thinks it's L0), and the *endpoint* wants to exit
> L1, e.g., so it can send a PME message for a wakeup. I don't know
> what happens then.
Is there some hardware which I can use to simulate this situation ?
> If there were a real erratum writeup for this, it would probably
> discuss this situation.
I went through the latest errata sheet and don't see anything. The
datasheet only mentions that L0/L0s/L1 is supported and L2 is not supported.
Maybe Phil can comment on this too ?
[...]
--
Best regards,
Marek Vasut
[PATCH v2 0/3] ARM: shmobile: Add support for RZ/A2
Introduce RZ/A2 (R7S9210) as an SoC that can be selected.
There is no DT mainlined yet, so this is what the entry would look
like for the BSID register:
bsid: chipid@fcfe8004 {
compatible = "renesas,bsid";
reg = <0xfcfe8004 4>;
};
Chris Brandt (3):
ARM: shmobile: Add basic RZ/A2 SoC support
soc: renesas: identify RZ/A2
dt-bindings: arm: Document RZ/A2 SoC DT bindings
Documentation/devicetree/bindings/arm/shmobile.txt | 4 +-
arch/arm/mach-shmobile/Kconfig | 6 +++
arch/arm/mach-shmobile/Makefile| 1 +
arch/arm/mach-shmobile/setup-r7s9210.c | 27 ++
drivers/soc/renesas/renesas-soc.c | 60 +-
5 files changed, 85 insertions(+), 13 deletions(-)
create mode 100644 arch/arm/mach-shmobile/setup-r7s9210.c
--
2.16.1
[PATCH v2 3/3] dt-bindings: arm: Document RZ/A2 SoC DT bindings
Add device tree bindings documentation for Renesas RZ/A2 (r7s9210) SoC. Also document new option for "renesas,bsid" Signed-off-by: Chris Brandt Reviewed-by: Geert Uytterhoeven --- v2: * added Reviewed-by * added renesas,bsid comment --- Documentation/devicetree/bindings/arm/shmobile.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt index 89b4a389fbc7..1b2e32171924 100644 --- a/Documentation/devicetree/bindings/arm/shmobile.txt +++ b/Documentation/devicetree/bindings/arm/shmobile.txt @@ -7,6 +7,8 @@ SoCs: compatible = "renesas,emev2" - RZ/A1H (R7S72100) compatible = "renesas,r7s72100" + - RZ/A2 (R7S9210) +compatible = "renesas,r7s9210" - SH-Mobile AG5 (R8A73A00/SH73A0) compatible = "renesas,sh73a0" - R-Mobile APE6 (R8A73A40) @@ -148,7 +150,7 @@ product and revision information. If present, a device node for this register should be added. Required properties: - - compatible: Must be "renesas,prr". + - compatible: Must be "renesas,prr" or "renesas,bsid" - reg: Base address and length of the register block. -- 2.16.1
[PATCH v2 2/3] soc: renesas: identify RZ/A2
Add support for identifying the RZ/A2M (R7S9210) SoC.
Also add support for reading the BSID register which is a different format
than the PRR.
Signed-off-by: Chris Brandt
---
drivers/soc/renesas/renesas-soc.c | 60 +++
1 file changed, 48 insertions(+), 12 deletions(-)
diff --git a/drivers/soc/renesas/renesas-soc.c
b/drivers/soc/renesas/renesas-soc.c
index d44d0e687ab8..e528744b07c3 100644
--- a/drivers/soc/renesas/renesas-soc.c
+++ b/drivers/soc/renesas/renesas-soc.c
@@ -20,10 +20,15 @@
#include
#include
+enum {
+ TYPE_PRR,
+ TYPE_BSID,
+};
struct renesas_family {
const char name[16];
- u32 reg;/* CCCR or PRR, if not in DT */
+ u32 reg;/* CCCR, PRR or BSID, if not in DT */
+ u8 type;
};
static const struct renesas_family fam_rcar_gen1 __initconst __maybe_unused = {
@@ -46,8 +51,14 @@ static const struct renesas_family fam_rmobile __initconst
__maybe_unused = {
.reg= 0xe600101c, /* CCCR (Common Chip Code Register) */
};
-static const struct renesas_family fam_rza __initconst __maybe_unused = {
- .name = "RZ/A",
+static const struct renesas_family fam_rza1 __initconst __maybe_unused = {
+ .name = "RZ/A1",
+};
+
+static const struct renesas_family fam_rza2 __initconst __maybe_unused = {
+ .name = "RZ/A2",
+ .reg= 0xfcfe8004, /* BSID (Boundary Scan ID Register) */
+ .type = TYPE_BSID,
};
static const struct renesas_family fam_rzg __initconst __maybe_unused = {
@@ -67,7 +78,12 @@ struct renesas_soc {
};
static const struct renesas_soc soc_rz_a1h __initconst __maybe_unused = {
- .family = _rza,
+ .family = _rza1,
+};
+
+static const struct renesas_soc soc_rz_a2m __initconst __maybe_unused = {
+ .family = _rza2,
+ .id = 0x3b,
};
static const struct renesas_soc soc_rmobile_ape6 __initconst __maybe_unused = {
@@ -184,6 +200,9 @@ static const struct of_device_id renesas_socs[] __initconst
= {
#ifdef CONFIG_ARCH_R7S72100
{ .compatible = "renesas,r7s72100", .data = _rz_a1h },
#endif
+#ifdef CONFIG_ARCH_R7S9210
+ { .compatible = "renesas,r7s9210", .data = _rz_a2m },
+#endif
#ifdef CONFIG_ARCH_R8A73A4
{ .compatible = "renesas,r8a73a4", .data = _rmobile_ape6 },
#endif
@@ -263,6 +282,7 @@ static int __init renesas_soc_init(void)
struct soc_device *soc_dev;
struct device_node *np;
unsigned int product;
+ u8 reg_type = TYPE_PRR;
match = of_match_node(renesas_socs, of_root);
if (!match)
@@ -271,23 +291,39 @@ static int __init renesas_soc_init(void)
soc = match->data;
family = soc->family;
- /* Try PRR first, then hardcoded fallback */
+ /* Try PRR and BSID first, then hardcoded fallback */
np = of_find_compatible_node(NULL, NULL, "renesas,prr");
+ if (!np) {
+ np = of_find_compatible_node(NULL, NULL, "renesas,bsid");
+ if (np)
+ reg_type = TYPE_BSID;
+ }
if (np) {
chipid = of_iomap(np, 0);
of_node_put(np);
} else if (soc->id) {
chipid = ioremap(family->reg, 4);
+ reg_type = family->type;
}
if (chipid) {
product = readl(chipid);
iounmap(chipid);
- /* R-Car M3-W ES1.1 incorrectly identifies as ES2.0 */
- if ((product & 0x7fff) == 0x5210)
- product ^= 0x11;
- if (soc->id && ((product >> 8) & 0xff) != soc->id) {
- pr_warn("SoC mismatch (product = 0x%x)\n", product);
- return -ENODEV;
+
+ if (reg_type == TYPE_PRR) {
+ /* R-Car M3-W ES1.1 incorrectly identifies as ES2.0 */
+ if ((product & 0x7fff) == 0x5210)
+ product ^= 0x11;
+ if (soc->id && ((product >> 8) & 0xff) != soc->id) {
+ pr_warn("SoC mismatch (product = 0x%x)\n",
+ product);
+ return -ENODEV;
+ }
+ } else if (reg_type == TYPE_BSID) {
+ if (soc->id && ((product >> 16) & 0xff) != soc->id) {
+ pr_warn("SoC mismatch (product = 0x%x)\n",
+ product);
+ return -ENODEV;
+ }
}
}
@@ -302,7 +338,7 @@ static int __init renesas_soc_init(void)
soc_dev_attr->family = kstrdup_const(family->name, GFP_KERNEL);
soc_dev_attr->soc_id = kstrdup_const(strchr(match->compatible, ',') + 1,
GFP_KERNEL);
- if (chipid)
+ if (chipid && (reg_type ==
[PATCH v2 1/3] ARM: shmobile: Add basic RZ/A2 SoC support
Add the RZ/A2 SoC to the Renesas SoC collection.
Signed-off-by: Chris Brandt
---
arch/arm/mach-shmobile/Kconfig | 6 ++
arch/arm/mach-shmobile/Makefile| 1 +
arch/arm/mach-shmobile/setup-r7s9210.c | 27 +++
3 files changed, 34 insertions(+)
create mode 100644 arch/arm/mach-shmobile/setup-r7s9210.c
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 0b67254eabb2..9338eb0d574f 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -54,6 +54,12 @@ config ARCH_R7S72100
select SYS_SUPPORTS_SH_MTU2
select RENESAS_OSTM
+config ARCH_R7S9210
+ bool "RZ/A2 (R7S9210)"
+ select PM
+ select PM_GENERIC_DOMAINS
+ select RENESAS_OSTM
+
config ARCH_R8A73A4
bool "R-Mobile APE6 (R8A73A40)"
select ARCH_RMOBILE
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index b33dc59d8698..5591646cb9bb 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_ARCH_R8A7778)+= setup-r8a7778.o
obj-$(CONFIG_ARCH_R8A7779) += setup-r8a7779.o
obj-$(CONFIG_ARCH_EMEV2) += setup-emev2.o
obj-$(CONFIG_ARCH_R7S72100)+= setup-r7s72100.o
+obj-$(CONFIG_ARCH_R7S9210) += setup-r7s9210.o
# CPU reset vector handling objects
cpu-y := platsmp.o headsmp.o
diff --git a/arch/arm/mach-shmobile/setup-r7s9210.c
b/arch/arm/mach-shmobile/setup-r7s9210.c
new file mode 100644
index ..573fb9955e7e
--- /dev/null
+++ b/arch/arm/mach-shmobile/setup-r7s9210.c
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * r7s9210 processor support
+ *
+ * Copyright (C) 2018 Renesas Electronics Corporation
+ * Copyright (C) 2018 Chris Brandt
+ *
+ */
+
+#include
+
+#include
+
+#include "common.h"
+
+static const char *const r7s9210_boards_compat_dt[] __initconst = {
+ "renesas,r7s9210",
+ NULL,
+};
+
+DT_MACHINE_START(R7S72100_DT, "Generic R7S9210 (Flattened Device Tree)")
+ .l2c_aux_val= 0,
+ .l2c_aux_mask = ~0,
+ .init_early = shmobile_init_delay,
+ .init_late = shmobile_init_late,
+ .dt_compat = r7s9210_boards_compat_dt,
+MACHINE_END
--
2.16.1
Re: [PATCH] iommu/ipmmu-vmsa: Clarify supported platforms
Hi Geert, Thank you for the patch. On Wednesday, 25 July 2018 16:10:29 EEST Geert Uytterhoeven wrote: > The Renesas IPMMU-VMSA driver supports not just R-Car H2 and M2 SoCs, > but also other R-Car Gen2 and R-Car Gen3 SoCs. > > Drop a superfluous "Renesas" while at it. > > Signed-off-by: Geert Uytterhoeven Reviewed-by: Laurent Pinchart > --- > drivers/iommu/Kconfig | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig > index 568ae81b0e99b67b..c69dc0b29b5df37f 100644 > --- a/drivers/iommu/Kconfig > +++ b/drivers/iommu/Kconfig > @@ -306,8 +306,8 @@ config IPMMU_VMSA > select IOMMU_IO_PGTABLE_LPAE > select ARM_DMA_USE_IOMMU > help > - Support for the Renesas VMSA-compatible IPMMU Renesas found in the > - R-Mobile APE6 and R-Car H2/M2 SoCs. > + Support for the Renesas VMSA-compatible IPMMU found in the R-Mobile > + APE6, R-Car Gen2, and R-Car Gen3 SoCs. > > If unsure, say N. -- Regards, Laurent Pinchart
Re: [PATCH 07/12] i2c: stu300: use core to detect 'no zero length' quirk
On Mon, Jul 23, 2018 at 10:26 PM Wolfram Sang wrote: > And don't reimplement in the driver. > > Signed-off-by: Wolfram Sang Reviewed-by: Linus Walleij Yours, Linus Walleij
[PATCH/RFT] arm64: dts: renesas: r8a77965: Add OPPs table for cpu devices
From: Dien Pham
This patch adds OPPs table for CA57{0,1} cpu devices
Signed-off-by: Dien Pham
Signed-off-by: Takeshi Kihara
Signed-off-by: Yoshihiro Kaneko
---
This patch is based on the devel branch of Simon Horman's renesas tree.
arch/arm64/boot/dts/renesas/r8a77965.dtsi | 44 +++
1 file changed, 44 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index 0a64b72..28dcbb6 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -60,6 +60,46 @@
clock-frequency = <0>;
};
+ cluster0_opp: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp@5 {
+ opp-hz = /bits/ 64 <5>;
+ opp-microvolt = <83>;
+ clock-latency-ns = <30>;
+ };
+ opp@10 {
+ opp-hz = /bits/ 64 <10>;
+ opp-microvolt = <83>;
+ clock-latency-ns = <30>;
+ };
+ opp@15 {
+ opp-hz = /bits/ 64 <15>;
+ opp-microvolt = <83>;
+ clock-latency-ns = <30>;
+ opp-suspend;
+ };
+ opp@16 {
+ opp-hz = /bits/ 64 <16>;
+ opp-microvolt = <90>;
+ clock-latency-ns = <30>;
+ turbo-mode;
+ };
+ opp@17 {
+ opp-hz = /bits/ 64 <17>;
+ opp-microvolt = <90>;
+ clock-latency-ns = <30>;
+ turbo-mode;
+ };
+ opp@18 {
+ opp-hz = /bits/ 64 <18>;
+ opp-microvolt = <96>;
+ clock-latency-ns = <30>;
+ turbo-mode;
+ };
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -71,6 +111,8 @@
power-domains = < R8A77965_PD_CA57_CPU0>;
next-level-cache = <_CA57>;
enable-method = "psci";
+ clocks =< CPG_CORE R8A77965_CLK_Z>;
+ operating-points-v2 = <_opp>;
};
a57_1: cpu@1 {
@@ -80,6 +122,8 @@
power-domains = < R8A77965_PD_CA57_CPU1>;
next-level-cache = <_CA57>;
enable-method = "psci";
+ clocks =< CPG_CORE R8A77965_CLK_Z>;
+ operating-points-v2 = <_opp>;
};
L2_CA57: cache-controller-0 {
--
1.9.1
[PATCH] ASoC: rsnd: Document R-Car M3-N support
From: Hiroyuki Yokoyama Document support for the sound modules in the Renesas M3-N (r8a77965) SoC. No driver update is needed. Signed-off-by: Hiroyuki Yokoyama Signed-off-by: Yoshihiro Kaneko --- This patch is based on the devel branch of Simon Horman's renesas tree. Documentation/devicetree/bindings/sound/renesas,rsnd.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt index b86d790..9e764270 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt @@ -352,6 +352,7 @@ Required properties: - "renesas,rcar_sound-r8a7794" (R-Car E2) - "renesas,rcar_sound-r8a7795" (R-Car H3) - "renesas,rcar_sound-r8a7796" (R-Car M3-W) + - "renesas,rcar_sound-r8a77965" (R-Car M3-N) - reg : Should contain the register physical address. required register is SRU/ADG/SSI if generation1 -- 1.9.1
[PATCH/RFT] arm64: dts: renesas: r8a77965: Add Sound and Audio DMAC device nodes
From: Takeshi Kihara
Based on a similar patch of the R8A7796 device tree
by Kuninori Morimoto .
Signed-off-by: Takeshi Kihara
Signed-off-by: Yoshihiro Kaneko
---
The following patches were squashed into this patch:
arm64: dts: r8a77965: Add Audio-DMAC device nodes
arm64: dts: r8a77965: Add Sound device node and SSI support
arm64: dts: r8a77965: Add Sound SRC support
arm64: dts: r8a77965: Add Sound DVC device nodes
arm64: dts: r8a77965: Add Sound CTU support
arm64: dts: r8a77965: Add Sound MIX support
This patch is based on the devel branch of Simon Horman's renesas tree.
arch/arm64/boot/dts/renesas/r8a77965.dtsi | 245 --
1 file changed, 234 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index 0cd4446..0a64b72 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -12,7 +12,7 @@
#include
#include
-#define CPG_AUDIO_CLK_I10
+#define CPG_AUDIO_CLK_IR8A77965_CLK_S0D4
/ {
compatible = "renesas,r8a77965";
@@ -1324,46 +1324,269 @@
};
rcar_sound: sound@ec50 {
+ /*
+* #sound-dai-cells is required
+*
+* Single DAI : #sound-dai-cells = <0>; <_sound>;
+* Multi DAI : #sound-dai-cells = <1>; <_sound N>;
+*/
+ /*
+* #clock-cells is required for audio_clkout0/1/2/3
+*
+* clkout : #clock-cells = <0>; <_sound>;
+* clkout0/1/2/3: #clock-cells = <1>; <_sound N>;
+*/
+ compatible = "renesas,rcar_sound-r8a77965",
"renesas,rcar_sound-gen3";
reg = <0 0xec50 0 0x1000>, /* SCU */
<0 0xec5a 0 0x100>, /* ADG */
<0 0xec54 0 0x1000>, /* SSIU */
<0 0xec541000 0 0x280>, /* SSI */
<0 0xec74 0 0x200>; /* Audio DMAC peri
peri*/
- /* placeholder */
+ reg-names = "scu", "adg", "ssiu", "ssi", "audmapp";
+
+ clocks = < CPG_MOD 1005>,
+< CPG_MOD 1006>, < CPG_MOD 1007>,
+< CPG_MOD 1008>, < CPG_MOD 1009>,
+< CPG_MOD 1010>, < CPG_MOD 1011>,
+< CPG_MOD 1012>, < CPG_MOD 1013>,
+< CPG_MOD 1014>, < CPG_MOD 1015>,
+< CPG_MOD 1022>, < CPG_MOD 1023>,
+< CPG_MOD 1024>, < CPG_MOD 1025>,
+< CPG_MOD 1026>, < CPG_MOD 1027>,
+< CPG_MOD 1028>, < CPG_MOD 1029>,
+< CPG_MOD 1030>, < CPG_MOD 1031>,
+< CPG_MOD 1020>, < CPG_MOD 1021>,
+< CPG_MOD 1020>, < CPG_MOD 1021>,
+< CPG_MOD 1019>, < CPG_MOD 1018>,
+<_clk_a>, <_clk_b>,
+<_clk_c>,
+< CPG_CORE R8A77965_CLK_S0D4>;
+ clock-names = "ssi-all",
+ "ssi.9", "ssi.8", "ssi.7", "ssi.6",
+ "ssi.5", "ssi.4", "ssi.3", "ssi.2",
+ "ssi.1", "ssi.0",
+ "src.9", "src.8", "src.7", "src.6",
+ "src.5", "src.4", "src.3", "src.2",
+ "src.1", "src.0",
+ "mix.1", "mix.0",
+ "ctu.1", "ctu.0",
+ "dvc.0", "dvc.1",
+ "clk_a", "clk_b", "clk_c", "clk_i";
+ power-domains = < R8A77965_PD_ALWAYS_ON>;
+ resets = < 1005>,
+< 1006>, < 1007>,
+< 1008>, < 1009>,
+< 1010>, < 1011>,
+< 1012>, < 1013>,
+< 1014>, < 1015>;
+ reset-names = "ssi-all",
+ "ssi.9", "ssi.8", "ssi.7", "ssi.6",
+ "ssi.5", "ssi.4", "ssi.3", "ssi.2",
+ "ssi.1", "ssi.0";
+ status = "disabled";
rcar_sound,dvc {
dvc0: dvc-0 {
+ dmas = < 0xbc>;
+
Re: [PATCH] gpiolib: use better errno if get_direction is not available
> That all being said, I think this patch is still useful as is. Linus, do you have time to comment on this? signature.asc Description: PGP signature
Re: [PATCH] serial: sh-sci: Document that serial aliases became optional
On Fri, Jul 20, 2018 at 02:19:40PM +0200, Geert Uytterhoeven wrote:
> Serial aliases are optional since commit 7678f4c20fa7670f ("serial:
> sh-sci: Add support for dynamic instances").
> Update the DT bindings to reflect this.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Rob Herring
[PATCH 0/2] arm64: dts: enable SATA on Gen3 boards
Since Geert also argumented that it is reasonable to have this in the board DTS files [1], I converted the RFC into proper patches. So, SATA will be available out of the box for H3 and M3-N if MD12 is switched off properly. Patches are bases on current renesas-drivers/master. M3-N has been tested successfully, too. [1] https://patchwork.kernel.org/patch/10131041/ Changes since RFC: * added comments * kept the sorting * used GPIO macros instead of hardcoded values * added Geert's tag * added a patch for M3-N, too Wolfram Sang (2): arm64: dts: r8a7795: salvator-xs: enable SATA arm64: dts: r8a77965: salvator-xs: enable SATA arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts | 14 ++ arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts | 14 ++ 2 files changed, 28 insertions(+) -- 2.11.0
[PATCH 2/2] arm64: dts: r8a77965: salvator-xs: enable SATA
Add the nodes to enable SATA. Note that MD12 (SW12-7) must be switched
off for that to work.
Signed-off-by: Wolfram Sang
---
arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts
b/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts
index 9de4e3db1621..224c8f68f13b 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts
@@ -47,3 +47,17 @@
_con {
remote-endpoint = <_dw_hdmi0_out>;
};
+
+ {
+ pcie_sata_switch {
+ gpio-hog;
+ gpios = <7 GPIO_ACTIVE_HIGH>;
+ output-low; /* enable SATA by default */
+ line-name = "PCIE/SATA switch";
+ };
+};
+
+ /* MD12 (SW12-7) must be set 'Off' which is not the default! */
+ {
+ status = "okay";
+};
--
2.11.0
[PATCH 1/2] arm64: dts: r8a7795: salvator-xs: enable SATA
Add the nodes to enable SATA. Note that MD12 (SW12-7) must be switched
off for that to work.
Signed-off-by: Wolfram Sang
Tested-by: Geert Uytterhoeven
---
arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
index 8ded64d0a4d5..3032bdb8c47d 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
@@ -152,6 +152,15 @@
};
};
+ {
+ pcie_sata_switch {
+ gpio-hog;
+ gpios = <7 GPIO_ACTIVE_HIGH>;
+ output-low; /* enable SATA by default */
+ line-name = "PCIE/SATA switch";
+ };
+};
+
{
usb2_pins: usb2 {
groups = "usb2";
@@ -176,6 +185,11 @@
};
};
+ /* MD12 (SW12-7) must be set 'Off' which is not the default! */
+ {
+ status = "okay";
+};
+
_phy2 {
pinctrl-0 = <_pins>;
pinctrl-names = "default";
--
2.11.0
[PATCH] arm64: dts: r8a77965: Add SATA controller node
From: Takeshi Kihara
This patch adds SATA controller node for the R8A77965 SoC.
Signed-off-by: Takeshi Kihara
[wsa: rebased to upstream base]
Signed-off-by: Wolfram Sang
---
arch/arm64/boot/dts/renesas/r8a77965.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index 0cd44461a0bd..d2144b9b2572 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -908,6 +908,17 @@
status = "disabled";
};
+ sata: sata@ee30 {
+ compatible = "renesas,sata-r8a77965",
+"renesas,rcar-gen3-sata";
+ reg = <0 0xee30 0 0x20>;
+ interrupts = ;
+ clocks = < CPG_MOD 815>;
+ power-domains = < R8A77965_PD_ALWAYS_ON>;
+ resets = < 815>;
+ status = "disabled";
+ };
+
scif0: serial@e6e6 {
compatible = "renesas,scif-r8a77965",
"renesas,rcar-gen3-scif", "renesas,scif";
--
2.11.0
[PATCH] ata: sata_rcar: Add r8a77965 support
Update the binding docs for Renesas R-Car M3-N. No driver changes are needed. Signed-off-by: Wolfram Sang --- Documentation/devicetree/bindings/ata/sata_rcar.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/ata/sata_rcar.txt b/Documentation/devicetree/bindings/ata/sata_rcar.txt index e20eac7a3087..4268e17d2411 100644 --- a/Documentation/devicetree/bindings/ata/sata_rcar.txt +++ b/Documentation/devicetree/bindings/ata/sata_rcar.txt @@ -8,6 +8,7 @@ Required properties: - "renesas,sata-r8a7791" for R-Car M2-W - "renesas,sata-r8a7793" for R-Car M2-N - "renesas,sata-r8a7795" for R-Car H3 + - "renesas,sata-r8a77965" for R-Car M3-N - "renesas,rcar-gen2-sata" for a generic R-Car Gen2 compatible device - "renesas,rcar-gen3-sata" for a generic R-Car Gen3 compatible device - "renesas,rcar-sata" is deprecated -- 2.11.0
[PATCH] pinctrl: sh-pfc: r8a77965: Add SATA pins, groups and functions
From: Takeshi Kihara
This patch adds SATA0 pin, group and function to the R8A77965 SoC.
Signed-off-by: Takeshi Kihara
[wsa: rebased to upstream base]
Signed-off-by: Wolfram Sang
---
drivers/pinctrl/sh-pfc/pfc-r8a77965.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
index cfd7de67e3e3..e43a5b39784c 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
@@ -2907,6 +2907,25 @@ static const unsigned int pwm6_b_mux[] = {
PWM6_B_MARK,
};
+/* - SATA
*/
+static const unsigned int sata0_devslp_a_pins[] = {
+ /* DEVSLP */
+ RCAR_GP_PIN(6, 16),
+};
+
+static const unsigned int sata0_devslp_a_mux[] = {
+ SATA_DEVSLP_A_MARK,
+};
+
+static const unsigned int sata0_devslp_b_pins[] = {
+ /* DEVSLP */
+ RCAR_GP_PIN(4, 6),
+};
+
+static const unsigned int sata0_devslp_b_mux[] = {
+ SATA_DEVSLP_B_MARK,
+};
+
/* - SCIF0 --
*/
static const unsigned int scif0_data_pins[] = {
/* RX, TX */
@@ -3579,6 +3598,8 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(pwm5_b),
SH_PFC_PIN_GROUP(pwm6_a),
SH_PFC_PIN_GROUP(pwm6_b),
+ SH_PFC_PIN_GROUP(sata0_devslp_a),
+ SH_PFC_PIN_GROUP(sata0_devslp_b),
SH_PFC_PIN_GROUP(scif0_data),
SH_PFC_PIN_GROUP(scif0_clk),
SH_PFC_PIN_GROUP(scif0_ctrl),
@@ -3664,6 +3685,11 @@ static const char * const du_groups[] = {
"du_disp",
};
+static const char * const sata0_groups[] = {
+ "sata0_devslp_a",
+ "sata0_devslp_b",
+};
+
static const char * const hscif0_groups[] = {
"hscif0_data",
"hscif0_clk",
@@ -3999,6 +4025,7 @@ static const struct sh_pfc_function pinmux_functions[] = {
SH_PFC_FUNCTION(pwm4),
SH_PFC_FUNCTION(pwm5),
SH_PFC_FUNCTION(pwm6),
+ SH_PFC_FUNCTION(sata0),
SH_PFC_FUNCTION(scif0),
SH_PFC_FUNCTION(scif1),
SH_PFC_FUNCTION(scif2),
--
2.11.0
[PATCH] clk: renesas: r8a77965: Add SATA clock
From: Takeshi Kihara
This patch adds SATA clock to the R8A77965 SoC.
Signed-off-by: Takeshi Kihara
[wsa: rebased to upstream base]
Signed-off-by: Wolfram Sang
---
drivers/clk/renesas/r8a77965-cpg-mssr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/renesas/r8a77965-cpg-mssr.c
b/drivers/clk/renesas/r8a77965-cpg-mssr.c
index 8fae5e9c4a77..98c97f2cc7cb 100644
--- a/drivers/clk/renesas/r8a77965-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a77965-cpg-mssr.c
@@ -192,6 +192,7 @@ static const struct mssr_mod_clk r8a77965_mod_clks[]
__initconst = {
DEF_MOD("vin1", 810,R8A77965_CLK_S0D2),
DEF_MOD("vin0", 811,R8A77965_CLK_S0D2),
DEF_MOD("etheravb", 812,R8A77965_CLK_S0D6),
+ DEF_MOD("sata0",815,R8A77965_CLK_S3D2),
DEF_MOD("imr1", 822,R8A77965_CLK_S0D2),
DEF_MOD("imr0", 823,R8A77965_CLK_S0D2),
--
2.11.0
Re: [PATCH 2/2] ata: sata_rcar: Add rudimentary Runtime PM support
On Fri, Jul 20, 2018 at 02:27:39PM +0200, Geert Uytterhoeven wrote: > Replace the explicit clock handling to enable/disable the SATA module by > calls to Runtime PM. > > This makes the driver independent of actual SoC clock/power hierarchies, > and is needed to support virtualization, where the guest is not in full > control of power management. > > Signed-off-by: Geert Uytterhoeven For the record, works fine with the newly added SATA support for M3-N: Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang signature.asc Description: PGP signature
Re: [PATCH 1/2] ata: sata_rcar: Provide a short-hand for >dev
On Fri, Jul 20, 2018 at 02:27:38PM +0200, Geert Uytterhoeven wrote: > No functional changes. > > Signed-off-by: Geert Uytterhoeven For the record, works fine with the newly added SATA support for M3-N: Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang signature.asc Description: PGP signature
Re: [PATCH] DT: irqchip: renesas-irqc: document R8A77980 support
On Tue, Jul 17, 2018 at 10:23:17PM +0300, Sergei Shtylyov wrote: > Document R-Car V3H (AKA R8A77980) SoC bindings. > > Signed-off-by: Sergei Shtylyov > > --- > Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt | > 1 + > 1 file changed, 1 insertion(+) Acked-by: Rob Herring > > Index: > renesas/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt > === > --- > renesas.orig/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt > +++ > renesas/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt > @@ -16,6 +16,7 @@ Required properties: > - "renesas,intc-ex-r8a7796" (R-Car M3-W) > - "renesas,intc-ex-r8a77965" (R-Car M3-N) > - "renesas,intc-ex-r8a77970" (R-Car V3M) > +- "renesas,intc-ex-r8a77980" (R-Car V3H) > - "renesas,intc-ex-r8a77995" (R-Car D3) > - #interrupt-cells: has to be <2>: an interrupt index and flags, as defined > in >interrupts.txt in this directory
Re: [PATCH] arm64: dts: renesas: r8a77980: add Cortex-A53 PMU support
On Wed, Jul 25, 2018 at 6:44 PM Sergei Shtylyov
wrote:
> Describe the performance monitor unit (PMU) for the Cortex-A53 cores in
> the R8A77970 SoC's device tree.
8?
Can you hack up a check in checkpatch.pl to catch such mistakes? ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
[PATCH] arm64: dts: renesas: r8a77980: add Cortex-A53 PMU support
Describe the performance monitor unit (PMU) for the Cortex-A53 cores in
the R8A77970 SoC's device tree.
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov
Signed-off-by: Sergei Shtylyov
---
The patch is against the 'renesas-devel-20180724-v4.18-rc6' tag of Simon
Horman's 'renesas.git' repo.
arch/arm64/boot/dts/renesas/r8a77980.dtsi |9 +
1 file changed, 9 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -98,6 +98,15 @@
clock-frequency = <0>;
};
+ pmu_a53 {
+ compatible = "arm,cortex-a53-pmu";
+ interrupts-extended = < GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>,
+ < GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>,
+ < GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
+ < GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <_0>, <_1>, <_2>, <_3>;
+ };
+
psci {
compatible = "arm,psci-1.0", "arm,psci-0.2";
method = "smc";
Re: [PATCH] arm64: dts: renesas: r8a77980: add RWDT support
On Wed, Jul 25, 2018 at 06:08:21PM +0300, Sergei Shtylyov wrote: > Hello! > > On 07/24/2018 02:45 PM, Simon Horman wrote: > > [...] > > On Tue, Jul 24, 2018 at 09:01:59AM +0200, Geert Uytterhoeven wrote: > >> On Fri, Jul 20, 2018 at 9:21 PM Sergei Shtylyov > >> wrote: > >>> Describe RWDT in the R8A77980 SoC device tree. > >>> > >>> Enable RWDT on the Condor and V3H Starter Kit boards. > >>> > >>> Based on the original (and large) patch by Vladimir Barinov. > >>> > >>> Signed-off-by: Vladimir Barinov > >>> Signed-off-by: Sergei Shtylyov > >> > >> Reviewed-by: Geert Uytterhoeven > > > > Thanks, applied for v4.20. > >Sorry, still not seeing any 'devel' branch updates... forgot to push? I did push but, as discussed elsewhere, it seems that there was a glitch in The Matrix. Updates are now there after repushing them.
Re: [PATCH] arm64: dts: renesas: r8a77980: add RWDT support
Hello! On 07/24/2018 02:45 PM, Simon Horman wrote: [...] > On Tue, Jul 24, 2018 at 09:01:59AM +0200, Geert Uytterhoeven wrote: >> On Fri, Jul 20, 2018 at 9:21 PM Sergei Shtylyov >> wrote: >>> Describe RWDT in the R8A77980 SoC device tree. >>> >>> Enable RWDT on the Condor and V3H Starter Kit boards. >>> >>> Based on the original (and large) patch by Vladimir Barinov. >>> >>> Signed-off-by: Vladimir Barinov >>> Signed-off-by: Sergei Shtylyov >> >> Reviewed-by: Geert Uytterhoeven > > Thanks, applied for v4.20. Sorry, still not seeing any 'devel' branch updates... forgot to push? MBR, Sergei
[PATCH v2 0/3] serial: sh-sci: Add support for RZ/A2
The RZ/A2 uses a modified SCIF that until recently was only used in
Renesas MCU devices (not MPU devices).
So, while it functions mostly the same as a normal SCIF, some things
needed to be shifted around.
In the end, a standard compatible = "renesas,scif" is all that is really
needed (not a SoC specific "renesas,scif-r7s9210").
Becase there is no device tree yet, here is sample of what it would
look like:
scif0: serial@e8007000 {
compatible = "renesas,scif-r7s9210", "renesas,scif";
reg = <0xe8007000 18>;
interrupts = ,
,
,
,
,
;
clocks = <_clks R7S9210_CLK_SCIF0>;
clock-names = "fck";
power-domains = <_clocks>;
status = "disabled";
};
Chris Brandt (3):
serial: sh-sci: Allow for compressed SCIF address space
serial: sh-sci: Add support for separate TEI+DRI interrupts
serial: sh-sci: Document r7s9210 bindings
.../bindings/serial/renesas,sci-serial.txt | 17 +-
drivers/tty/serial/sh-sci.c| 66 ++
2 files changed, 70 insertions(+), 13 deletions(-)
--
2.16.1
[PATCH v2 3/3] serial: sh-sci: Document r7s9210 bindings
Add R7S9210 (RZ/A2) support. Also describe interrupts property in more detail. Signed-off-by: Chris Brandt --- v2: * Add more details to interrupts property * Geert gave a Reviewed-by for V1, but then later said that was a mistake because it was missing the interrupts description, so I didn't include his Reviewed-by yet. --- .../devicetree/bindings/serial/renesas,sci-serial.txt | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt index 106808b55b6d..5d0997a04697 100644 --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt @@ -5,6 +5,7 @@ Required properties: - compatible: Must contain one or more of the following: - "renesas,scif-r7s72100" for R7S72100 (RZ/A1H) SCIF compatible UART. +- "renesas,scif-r7s9210" for R7S9210 (RZ/A2) SCIF compatible UART. - "renesas,scifa-r8a73a4" for R8A73A4 (R-Mobile APE6) SCIFA compatible UART. - "renesas,scifb-r8a73a4" for R8A73A4 (R-Mobile APE6) SCIFB compatible UART. - "renesas,scifa-r8a7740" for R8A7740 (R-Mobile A1) SCIFA compatible UART. @@ -72,7 +73,21 @@ Required properties: family-specific and/or generic versions. - reg: Base address and length of the I/O registers used by the UART. - - interrupts: Must contain an interrupt-specifier for the SCIx interrupt. + - interrupts: Must contain one or more interrupt-specifiers for the SCIx. +If a single interrupt is expressed, then all events are +multiplexed into this single interrupt. + +If multiple interrupts are provided by the hardware, the order +in which the interrupts are listed must match order below. Note +that some HW interrupt events may be muxed together resulting +in duplicate entires. +The interrupt order is as follows: + 1. Error (ERI) + 2. Receive buffer full (RXI) + 3. Transmit buffer empty (TXI) + 4. Break (BRI) + 5. Data Ready (DRI) + 6. Transmit End (TEI) - clocks: Must contain a phandle and clock-specifier pair for each entry in clock-names. -- 2.16.1
[PATCH v2 2/3] serial: sh-sci: Add support for separate TEI+DRI interrupts
Some SCIF versions mux error and break interrupts together and then provide
a separate interrupt ID for just TEI/DRI.
Allow all 6 types of interrupts to be specified via platform data (or DT)
and for any signals that are muxed together (have the same interrupt
number) simply register one handler.
Signed-off-by: Chris Brandt
---
v2:
* Move compressed SCIF reg address space to a separate commit
* Handle all 6 possible interrupt types
---
drivers/tty/serial/sh-sci.c | 44 +---
1 file changed, 41 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index d9202ad1c9ca..f1272fecbe44 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -65,6 +65,8 @@ enum {
SCIx_RXI_IRQ,
SCIx_TXI_IRQ,
SCIx_BRI_IRQ,
+ SCIx_DRI_IRQ,
+ SCIx_TEI_IRQ,
SCIx_NR_IRQS,
SCIx_MUX_IRQ = SCIx_NR_IRQS,/* special case */
@@ -1683,11 +1685,26 @@ static irqreturn_t sci_tx_interrupt(int irq, void *ptr)
return IRQ_HANDLED;
}
+static irqreturn_t sci_br_interrupt(int irq, void *ptr);
+
static irqreturn_t sci_er_interrupt(int irq, void *ptr)
{
struct uart_port *port = ptr;
struct sci_port *s = to_sci_port(port);
+ if (s->irqs[SCIx_ERI_IRQ] == s->irqs[SCIx_BRI_IRQ]) {
+ /* Break and Error interrupts are muxed */
+ unsigned short ssr_status = serial_port_in(port, SCxSR);
+
+ /* Break Interrupt */
+ if (ssr_status & SCxSR_BRK(port))
+ sci_br_interrupt(irq, ptr);
+
+ /* Break only? */
+ if (!(ssr_status & SCxSR_ERRORS(port)))
+ return IRQ_HANDLED;
+ }
+
/* Handle errors */
if (port->type == PORT_SCI) {
if (sci_handle_errors(port)) {
@@ -1794,6 +1811,16 @@ static const struct sci_irq_desc {
.handler = sci_br_interrupt,
},
+ [SCIx_DRI_IRQ] = {
+ .desc = "rx ready",
+ .handler = sci_rx_interrupt,
+ },
+
+ [SCIx_TEI_IRQ] = {
+ .desc = "tx end",
+ .handler = sci_tx_interrupt,
+ },
+
/*
* Special muxed handler.
*/
@@ -1806,12 +1833,19 @@ static const struct sci_irq_desc {
static int sci_request_irq(struct sci_port *port)
{
struct uart_port *up = >port;
- int i, j, ret = 0;
+ int i, j, w, ret = 0;
for (i = j = 0; i < SCIx_NR_IRQS; i++, j++) {
const struct sci_irq_desc *desc;
int irq;
+ /* Check if already registered (muxed) */
+ for (w = 0; w < i; w++)
+ if (port->irqs[w] == port->irqs[i])
+ w = i + 1;
+ if (w > i)
+ continue;
+
if (SCIx_IRQ_IS_MUXED(port)) {
i = SCIx_MUX_IRQ;
irq = up->irq;
@@ -2799,8 +2833,10 @@ static int sci_init_single(struct platform_device *dev,
/* The SCI generates several interrupts. They can be muxed together or
* connected to different interrupt lines. In the muxed case only one
-* interrupt resource is specified. In the non-muxed case three or four
-* interrupt resources are specified, as the BRI interrupt is optional.
+* interrupt resource is specified as there is only one interrupt ID.
+* In the non-muxed case, up to 6 interrupt signals might be generated
+* from the SCI, however those signals might have their own individual
+* interrupt ID numbers, or muxed together with another interrupt.
*/
if (sci_port->irqs[0] < 0)
return -ENXIO;
@@ -2809,6 +2845,8 @@ static int sci_init_single(struct platform_device *dev,
sci_port->irqs[1] = sci_port->irqs[0];
sci_port->irqs[2] = sci_port->irqs[0];
sci_port->irqs[3] = sci_port->irqs[0];
+ sci_port->irqs[4] = sci_port->irqs[0];
+ sci_port->irqs[5] = sci_port->irqs[0];
}
sci_port->params = sci_probe_regmap(p);
--
2.16.1
[PATCH v2 1/3] serial: sh-sci: Allow for compressed SCIF address space
Some devices with SCIx_SH4_SCIF_REGTYPE have no space between registers.
Use the register area size to determine the spacing between register.
Signed-off-by: Chris Brandt
---
drivers/tty/serial/sh-sci.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index c181eb37f985..d9202ad1c9ca 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -315,15 +315,15 @@ static const struct sci_port_params
sci_port_params[SCIx_NR_REGTYPES] = {
[SCIx_SH4_SCIF_REGTYPE] = {
.regs = {
[SCSMR] = { 0x00, 16 },
- [SCBRR] = { 0x04, 8 },
- [SCSCR] = { 0x08, 16 },
- [SCxTDR]= { 0x0c, 8 },
- [SCxSR] = { 0x10, 16 },
- [SCxRDR]= { 0x14, 8 },
- [SCFCR] = { 0x18, 16 },
- [SCFDR] = { 0x1c, 16 },
- [SCSPTR]= { 0x20, 16 },
- [SCLSR] = { 0x24, 16 },
+ [SCBRR] = { 0x02, 8 },
+ [SCSCR] = { 0x04, 16 },
+ [SCxTDR]= { 0x06, 8 },
+ [SCxSR] = { 0x08, 16 },
+ [SCxRDR]= { 0x0a, 8 },
+ [SCFCR] = { 0x0c, 16 },
+ [SCFDR] = { 0x0e, 16 },
+ [SCSPTR]= { 0x10, 16 },
+ [SCLSR] = { 0x12, 16 },
},
.fifosize = 16,
.overrun_reg = SCLSR,
@@ -2869,6 +2869,10 @@ static int sci_init_single(struct platform_device *dev,
port->regshift = 1;
}
+ if (p->regtype == SCIx_SH4_SCIF_REGTYPE)
+ if (sci_port->reg_size >= 0x20)
+ port->regshift = 1;
+
/*
* The UART port needs an IRQ value, so we peg this to the RX IRQ
* for the multi-IRQ ports, which is where we are primarily
--
2.16.1
[PATCH v3 2/4] hw/arm/sysbus-fdt: Allow device matching with DT compatible value
From: Auger Eric
Up to now we have relied on the device type to identify a device tree
node creation function. Since we would like the vfio-platform device to
be instantiatable with different compatible strings we introduce the
capability to specialize the node creation depending on actual
compatible value.
NodeCreationPair is renamed into BindingEntry. The struct is enhanced
with compat and match_fn() fields. We introduce a new matching function
adapted to the vfio-platform generic device.
>From now on, the AMD XGBE can be instantiated with either manner, i.e.:
-device vfio-amd-xgbe,host=e090.xgmac
or using the new option line:
-device vfio-platform,host=e090.xgmac
Signed-off-by: Eric Auger
[geert: Match using compatible values in sysfs instead of user-supplied
manufacturer/model options, reword]
Signed-off-by: Geert Uytterhoeven
---
Not tested with amd-xgbe due to lack of hardware.
v3:
- Match using the compatible values from sysfs instead of using
user-supplied manufacturer and model options,
- Reword patch description,
- Drop RFC state,
v2:
- No changes,
v1:
- No changes,
v0:
- Original version from Eric.
---
hw/arm/sysbus-fdt.c | 61 ++---
1 file changed, 47 insertions(+), 14 deletions(-)
diff --git a/hw/arm/sysbus-fdt.c b/hw/arm/sysbus-fdt.c
index 43d6a7bb48ddc351..0e24c803a1c2c734 100644
--- a/hw/arm/sysbus-fdt.c
+++ b/hw/arm/sysbus-fdt.c
@@ -50,11 +50,13 @@ typedef struct PlatformBusFDTData {
PlatformBusDevice *pbus;
} PlatformBusFDTData;
-/* struct that associates a device type name and a node creation function */
-typedef struct NodeCreationPair {
+/* struct that allows to match a device and create its FDT node */
+typedef struct BindingEntry {
const char *typename;
-int (*add_fdt_node_fn)(SysBusDevice *sbdev, void *opaque);
-} NodeCreationPair;
+const char *compat;
+int (*add_fn)(SysBusDevice *sbdev, void *opaque);
+bool (*match_fn)(SysBusDevice *sbdev, const struct BindingEntry *combo);
+} BindingEntry;
/* helpers */
@@ -413,6 +415,27 @@ static int add_amd_xgbe_fdt_node(SysBusDevice *sbdev, void
*opaque)
return 0;
}
+/* DT compatible matching */
+static bool vfio_platform_match(SysBusDevice *sbdev,
+const BindingEntry *entry)
+{
+VFIOPlatformDevice *vdev = VFIO_PLATFORM_DEVICE(sbdev);
+const char *compat;
+unsigned int n;
+
+for (n = vdev->num_compat, compat = vdev->compat; n > 0;
+ n--, compat += strlen(compat) + 1) {
+if (!strcmp(entry->compat, compat)) {
+return true;
+}
+}
+
+return false;
+}
+
+#define VFIO_PLATFORM_BINDING(compat, add_fn) \
+{TYPE_VFIO_PLATFORM, (compat), (add_fn), vfio_platform_match}
+
#endif /* CONFIG_LINUX */
static int no_fdt_node(SysBusDevice *sbdev, void *opaque)
@@ -420,14 +443,23 @@ static int no_fdt_node(SysBusDevice *sbdev, void *opaque)
return 0;
}
-/* list of supported dynamic sysbus devices */
-static const NodeCreationPair add_fdt_node_functions[] = {
+/* Device type based matching */
+static bool type_match(SysBusDevice *sbdev, const BindingEntry *entry)
+{
+return !strcmp(object_get_typename(OBJECT(sbdev)), entry->typename);
+}
+
+#define TYPE_BINDING(type, add_fn) {(type), NULL, (add_fn), type_match}
+
+/* list of supported dynamic sysbus bindings */
+static const BindingEntry bindings[] = {
#ifdef CONFIG_LINUX
-{TYPE_VFIO_CALXEDA_XGMAC, add_calxeda_midway_xgmac_fdt_node},
-{TYPE_VFIO_AMD_XGBE, add_amd_xgbe_fdt_node},
+TYPE_BINDING(TYPE_VFIO_CALXEDA_XGMAC, add_calxeda_midway_xgmac_fdt_node),
+TYPE_BINDING(TYPE_VFIO_AMD_XGBE, add_amd_xgbe_fdt_node),
+VFIO_PLATFORM_BINDING("amd,xgbe-seattle-v1a", add_amd_xgbe_fdt_node),
#endif
-{TYPE_RAMFB_DEVICE, no_fdt_node},
-{"", NULL}, /* last element */
+TYPE_BINDING(TYPE_RAMFB_DEVICE, no_fdt_node),
+TYPE_BINDING("", NULL), /* last element */
};
/* Generic Code */
@@ -446,10 +478,11 @@ static void add_fdt_node(SysBusDevice *sbdev, void
*opaque)
{
int i, ret;
-for (i = 0; i < ARRAY_SIZE(add_fdt_node_functions); i++) {
-if (!strcmp(object_get_typename(OBJECT(sbdev)),
-add_fdt_node_functions[i].typename)) {
-ret = add_fdt_node_functions[i].add_fdt_node_fn(sbdev, opaque);
+for (i = 0; i < ARRAY_SIZE(bindings); i++) {
+const BindingEntry *iter = [i];
+
+if (iter->match_fn(sbdev, iter)) {
+ret = iter->add_fn(sbdev, opaque);
assert(!ret);
return;
}
--
2.17.1
[PATCH v3 0/4] hw/arm/sysbus-fdt: Generic DT Pass-Through
Hi all,
This patch series allows to export generic devices in DT using
vfio-platform, providing direct access from a QEMU+KVM guest to the
exported devices.
- Patches 1-2 (submitted before by Eric Auger) make the vfio-platform
device non-abstract, incl. matching using a compatible string.
- Patch 3 allows dynamic sysbus devices again, without needing to
create device-specific vfio types for each and every new device.
- Patch 4 adds code to instantiate device nodes for generic DT
devices, copying a set of generic properties from the host.
This avoids having to write device-specific instantation methods for
each and every "simple" device using only a set of generic properties.
Devices that need more specialized handling can still provide their own
instantation method.
Changes compared to v2 (not submitted to the mailing list):
- Use the compatible values from sysfs instead of user-supplied
manufacturer and model options,
- Replace "hw/arm/sysbus-fdt: Enable rcar-gen3-gpio dynamic
instatiation" by generic "hw/arm/sysbus-fdt: Add support for
instantiating generic devices",
- Reword patch descriptions,
- Drop RFC state,
- Drop "vfio: No-IOMMU mode support".
Changes compared to v1 ("R-Car Gen3 GPIO Pass-Through Prototype (QEMU)",
https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg02716.html):
- Restrict dynamic sysbus devices to TYPE_VFIO_PLATFORM, as suggested
by Eric Auger.
For proper operation, this depends on "hw/arm/sysbus-fdt: Fix assertion
in copy_properties_from_host()"
(https://lists.gnu.org/archive/html/qemu-devel/2018-07/msg04922.html).
Thanks!
For testing, this patch series and all prerequisites are available in
the topic/rcar3-virt-gpio-passthrough-v3 branch of my git repository at
https://github.com/geertu/qemu.git.
This has been tested on a Renesas Salvator-XS board with R-Car H3 ES2.0
with SATA:
-device vfio-platform,host=ee30.sata
and GPIO (needs VFIO No-IOMMU support):
-device vfio-platform,host=e6055400.gpio
Thanks!
Auger Eric (2):
vfio/platform: Make the vfio-platform device non-abstract
hw/arm/sysbus-fdt: Allow device matching with DT compatible value
Geert Uytterhoeven (2):
hw/arm/virt: Allow dynamic sysbus devices again
hw/arm/sysbus-fdt: Add support for instantiating generic devices
hw/arm/sysbus-fdt.c | 163 +---
hw/arm/virt.c | 1 +
hw/vfio/amd-xgbe.c | 1 +
hw/vfio/calxeda-xgmac.c | 1 +
hw/vfio/platform.c | 22 -
include/hw/vfio/vfio-platform.h | 3 +-
6 files changed, 175 insertions(+), 16 deletions(-)
--
2.17.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
[PATCH v3 1/4] vfio/platform: Make the vfio-platform device non-abstract
From: Auger Eric
Up to now the vfio-platform device has been abstract and could not be
instantiated. The integration of a new vfio platform device required
creating a dummy derived device which only set the compatible string.
Following the few vfio-platform device integrations we have seen the
actual requested adaptation happens on device tree node creation
(sysbus-fdt).
Hence remove the abstract setting, and read the list of compatible
values from sysfs if not set by a derived device.
Update the amd-xgbe and calxeda-xgmac drivers to fill in the number of
compatible values, as there can now be more than one.
Note that sysbus-fdt does not support the instantiation of the
vfio-platform device yet.
Signed-off-by: Eric Auger
[geert: Rebase, set user_creatable=true, use compatible values in sysfs
instead of user-supplied manufacturer/model options, reword]
Signed-off-by: Geert Uytterhoeven
---
v3:
- Read all compatible values from sysfs instead of using user-supplied
manufacturer and model options,
- Reword patch description,
- Drop RFC state,
v2:
- No changes,
v1:
- Rebase, Set user_creatable=true,
v0:
- Original version from Eric.
---
hw/vfio/amd-xgbe.c | 1 +
hw/vfio/calxeda-xgmac.c | 1 +
hw/vfio/platform.c | 22 +-
include/hw/vfio/vfio-platform.h | 3 ++-
4 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/hw/vfio/amd-xgbe.c b/hw/vfio/amd-xgbe.c
index 0c4ec4ba25170366..ee64a3b4a2e45bf5 100644
--- a/hw/vfio/amd-xgbe.c
+++ b/hw/vfio/amd-xgbe.c
@@ -20,6 +20,7 @@ static void amd_xgbe_realize(DeviceState *dev, Error **errp)
VFIOAmdXgbeDeviceClass *k = VFIO_AMD_XGBE_DEVICE_GET_CLASS(dev);
vdev->compat = g_strdup("amd,xgbe-seattle-v1a");
+vdev->num_compat = 1;
k->parent_realize(dev, errp);
}
diff --git a/hw/vfio/calxeda-xgmac.c b/hw/vfio/calxeda-xgmac.c
index 24cee6d06512c1b6..e7767c4b021be566 100644
--- a/hw/vfio/calxeda-xgmac.c
+++ b/hw/vfio/calxeda-xgmac.c
@@ -20,6 +20,7 @@ static void calxeda_xgmac_realize(DeviceState *dev, Error
**errp)
VFIOCalxedaXgmacDeviceClass *k = VFIO_CALXEDA_XGMAC_DEVICE_GET_CLASS(dev);
vdev->compat = g_strdup("calxeda,hb-xgmac");
+vdev->num_compat = 1;
k->parent_realize(dev, errp);
}
diff --git a/hw/vfio/platform.c b/hw/vfio/platform.c
index 57c4a0ee2b58da70..e264555cd5dafb16 100644
--- a/hw/vfio/platform.c
+++ b/hw/vfio/platform.c
@@ -655,6 +655,25 @@ static void vfio_platform_realize(DeviceState *dev, Error
**errp)
goto out;
}
+if (!vdev->compat) {
+gchar *contents;
+gsize length;
+char *tmp;
+
+tmp = g_strdup_printf("%s/of_node/compatible", vbasedev->sysfsdev);
+if (!g_file_get_contents(tmp, , , NULL)) {
+error_report("failed to load \"%s\"", tmp);
+exit(1);
+}
+g_free(tmp);
+vdev->compat = contents;
+for (vdev->num_compat = 0; length; vdev->num_compat++) {
+size_t skip = strlen(contents) + 1;
+contents += skip;
+length -= skip;
+}
+}
+
for (i = 0; i < vbasedev->num_regions; i++) {
if (vfio_region_mmap(vdev->regions[i])) {
error_report("%s mmap unsupported. Performance may be slow",
@@ -700,6 +719,8 @@ static void vfio_platform_class_init(ObjectClass *klass,
void *data)
dc->desc = "VFIO-based platform device assignment";
sbc->connect_irq_notifier = vfio_start_irqfd_injection;
set_bit(DEVICE_CATEGORY_MISC, dc->categories);
+/* Supported by TYPE_VIRT_MACHINE */
+dc->user_creatable = true;
}
static const TypeInfo vfio_platform_dev_info = {
@@ -708,7 +729,6 @@ static const TypeInfo vfio_platform_dev_info = {
.instance_size = sizeof(VFIOPlatformDevice),
.class_init = vfio_platform_class_init,
.class_size = sizeof(VFIOPlatformDeviceClass),
-.abstract = true,
};
static void register_vfio_platform_dev_type(void)
diff --git a/include/hw/vfio/vfio-platform.h b/include/hw/vfio/vfio-platform.h
index 9baaa2db09b84f3e..0ee10b1d71ed2503 100644
--- a/include/hw/vfio/vfio-platform.h
+++ b/include/hw/vfio/vfio-platform.h
@@ -54,7 +54,8 @@ typedef struct VFIOPlatformDevice {
QLIST_HEAD(, VFIOINTp) intp_list; /* list of IRQs */
/* queue of pending IRQs */
QSIMPLEQ_HEAD(pending_intp_queue, VFIOINTp) pending_intp_queue;
-char *compat; /* compatibility string */
+char *compat; /* DT compatible values, separated by NUL */
+unsigned int num_compat; /* number of compatible values */
uint32_t mmap_timeout; /* delay to re-enable mmaps after interrupt */
QEMUTimer *mmap_timer; /* allows fast-path resume after IRQ hit */
QemuMutex intp_mutex; /* protect the intp_list IRQ state */
--
2.17.1
[PATCH v3 3/4] hw/arm/virt: Allow dynamic sysbus devices again
Allow the instantation of generic dynamic sysbus devices again, without
the need to create a new device-specific vfio type.
This is more or less a partial revert of commit 6f2062b9758ebc64
("hw/arm/virt: Allow only supported dynamic sysbus devices").
Signed-off-by: Geert Uytterhoeven
---
v3:
- Drop RFC state,
v2:
- Restrict from TYPE_SYS_BUS_DEVICE to TYPE_VFIO_PLATFORM, as
suggested by Eric Auger.
---
hw/arm/virt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 281ddcdf6e26236d..24c1d8e28c7c4285 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1724,6 +1724,7 @@ static void virt_machine_class_init(ObjectClass *oc, void
*data)
machine_class_allow_dynamic_sysbus_dev(mc, TYPE_VFIO_CALXEDA_XGMAC);
machine_class_allow_dynamic_sysbus_dev(mc, TYPE_VFIO_AMD_XGBE);
machine_class_allow_dynamic_sysbus_dev(mc, TYPE_RAMFB_DEVICE);
+machine_class_allow_dynamic_sysbus_dev(mc, TYPE_VFIO_PLATFORM);
mc->block_default_type = IF_VIRTIO;
mc->no_cdrom = 1;
mc->pci_allow_0_address = true;
--
2.17.1
[PATCH v3 4/4] hw/arm/sysbus-fdt: Add support for instantiating generic devices
Add a fallback for instantiating generic devices without a type-specific
or compatible-specific instantation method. This will be used when no
other match is found.
The generic instantation method creates a device node with "reg" and
(optional) "interrupts" properties, and copies the "compatible"
property and other optional properties from the host.
For now the following optional properties are copied, if found:
- "#gpio-cells",
- "gpio-controller",
- "#interrupt-cells",
- "interrupt-controller",
- "interrupt-names".
More can be added when needed.
This avoids having to write device-specific instantation methods for
each and every "simple" device using only a set of generic properties.
Devices that need more specialized handling can still provide their
own instantation method.
This has been tested on a Renesas Salvator-XS board with R-Car H3 ES2.0
with SATA:
-device vfio-platform,host=ee30.sata
and GPIO (needs VFIO No-IOMMU support):
-device vfio-platform,host=e6055400.gpio
Signed-off-by: Geert Uytterhoeven
---
v3:
- New.
---
hw/arm/sysbus-fdt.c | 102
1 file changed, 102 insertions(+)
diff --git a/hw/arm/sysbus-fdt.c b/hw/arm/sysbus-fdt.c
index 0e24c803a1c2c734..8040af00ccf131d7 100644
--- a/hw/arm/sysbus-fdt.c
+++ b/hw/arm/sysbus-fdt.c
@@ -415,6 +415,99 @@ static int add_amd_xgbe_fdt_node(SysBusDevice *sbdev, void
*opaque)
return 0;
}
+static HostProperty generic_copied_properties[] = {
+{"compatible", false},
+{"#gpio-cells", true},
+{"gpio-controller", true},
+{"#interrupt-cells", true},
+{"interrupt-controller", true},
+{"interrupt-names", true},
+};
+
+/**
+ * add_generic_fdt_node
+ *
+ * Generates a generic DT node by copying properties from the host
+ */
+static int add_generic_fdt_node(SysBusDevice *sbdev, void *opaque)
+{
+PlatformBusFDTData *data = opaque;
+VFIOPlatformDevice *vdev = VFIO_PLATFORM_DEVICE(sbdev);
+const char *parent_node = data->pbus_node_name;
+void *guest_fdt = data->fdt, *host_fdt;
+VFIODevice *vbasedev = >vbasedev;
+char **node_path, *node_name, *dt_name;
+PlatformBusDevice *pbus = data->pbus;
+int i, irq_number;
+uint32_t *reg_attr, *irq_attr;
+uint64_t mmio_base;
+
+host_fdt = load_device_tree_from_sysfs();
+
+dt_name = sysfs_to_dt_name(vbasedev->name);
+if (!dt_name) {
+error_report("%s incorrect sysfs device name %s", __func__,
+ vbasedev->name);
+exit(1);
+}
+node_path = qemu_fdt_node_path(host_fdt, dt_name, vdev->compat,
+ _fatal);
+if (!node_path || !node_path[0]) {
+error_report("%s unable to retrieve node path for %s/%s", __func__,
+ dt_name, vdev->compat);
+exit(1);
+}
+
+if (node_path[1]) {
+error_report("%s more than one node matching %s/%s!", __func__,
dt_name,
+ vdev->compat);
+exit(1);
+}
+
+mmio_base = platform_bus_get_mmio_addr(pbus, sbdev, 0);
+node_name = g_strdup_printf("%s/%s@%" PRIx64, parent_node,
+ vbasedev->name, mmio_base);
+qemu_fdt_add_subnode(guest_fdt, node_name);
+
+/* Copy generic properties */
+copy_properties_from_host(generic_copied_properties,
+ ARRAY_SIZE(generic_copied_properties), host_fdt,
+ guest_fdt, node_path[0], node_name);
+
+/* Copy reg (remapped) */
+reg_attr = g_new(uint32_t, vbasedev->num_regions * 2);
+for (i = 0; i < vbasedev->num_regions; i++) {
+mmio_base = platform_bus_get_mmio_addr(pbus, sbdev, i);
+reg_attr[2 * i] = cpu_to_be32(mmio_base);
+reg_attr[2 * i + 1] = cpu_to_be32(
+memory_region_size(vdev->regions[i]->mem));
+}
+qemu_fdt_setprop(guest_fdt, node_name, "reg", reg_attr,
+ vbasedev->num_regions * 2 * sizeof(uint32_t));
+
+/* Copy interrupts (remapped) */
+if (vbasedev->num_irqs) {
+irq_attr = g_new(uint32_t, vbasedev->num_irqs * 3);
+for (i = 0; i < vbasedev->num_irqs; i++) {
+irq_number = platform_bus_get_irqn(pbus, sbdev , i)
+ + data->irq_start;
+irq_attr[3 * i] = cpu_to_be32(GIC_FDT_IRQ_TYPE_SPI);
+irq_attr[3 * i + 1] = cpu_to_be32(irq_number);
+irq_attr[3 * i + 2] = cpu_to_be32(GIC_FDT_IRQ_FLAGS_LEVEL_HI);
+}
+qemu_fdt_setprop(guest_fdt, node_name, "interrupts",
+ irq_attr, vbasedev->num_irqs * 3 * sizeof(uint32_t));
+g_free(irq_attr);
+}
+
+g_free(reg_attr);
+g_free(node_name);
+g_strfreev(node_path);
+g_free(dt_name);
+g_free(host_fdt);
+return 0;
+}
+
/* DT compatible matching */
static bool vfio_platform_match(SysBusDevice *sbdev,
const BindingEntry *entry)
@@ -423,6
[PATCH/RFC] iommu/ipmmu-vmsa: Whitelist SATA for IOMMU use and virtualization
SATA on R-Car H3 ES2.0 works fine with the IOMMU.
This is also needed for virtualization.
Signed-off-by: Geert Uytterhoeven
---
For testing virtualization, this patch and all prerequisites are
available in the topic/rcar3-virt-gpio-passthrough-v3 branch of my git
repository at
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git.
drivers/iommu/ipmmu-vmsa.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index ef566b4989d6e2f8..f6f7b7e8cb982769 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -751,6 +751,9 @@ static int ipmmu_init_platform_device(struct device *dev,
static bool ipmmu_slave_whitelist(struct device *dev)
{
+ if (!strcmp(dev_name(dev), "ee30.sata"))
+ return true;
+
/* By default, do not allow use of IPMMU */
return false;
}
--
2.17.1
Re: [PATCH/RFC] drivers/vfio: Allow type-1 IOMMU instantiation with Renesas IPMMU-VMSA
Hi Geert, On 25/07/18 14:34, Geert Uytterhoeven wrote: The Renesas IPMMU-VMSA driver is compatible with the notion of a type-1 IOMMU in VFIO. This patch allows guests to use the VFIO_IOMMU_TYPE1 API on hosts equipped with a Renesas VMSA-compatible IPMMU. Signed-off-by: Geert Uytterhoeven --- Lightly tested with sata_rcar on Renesas R-Car H3 ES2.0. For testing, this patch and all prerequisites are available in the topic/rcar3-virt-gpio-passthrough-v3 branch of my git repository at git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git. --- drivers/vfio/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig index c84333eb5eb59bef..a3e21e7c066596d7 100644 --- a/drivers/vfio/Kconfig +++ b/drivers/vfio/Kconfig @@ -21,7 +21,8 @@ config VFIO_VIRQFD menuconfig VFIO tristate "VFIO Non-Privileged userspace driver framework" depends on IOMMU_API - select VFIO_IOMMU_TYPE1 if (X86 || S390 || ARM_SMMU || ARM_SMMU_V3) + select VFIO_IOMMU_TYPE1 if (X86 || S390 || ARM_SMMU || ARM_SMMU_V3 || \ + IPMMU_VMSA) I recall this came up in the context of virtio-iommu too[1], wherein we decided that listing individual drivers was actually a bit silly and this should simply have ARM || ARM64 for consistency. Looks like there's even more justification now :) Robin. [1] https://www.mail-archive.com/kvmarm@lists.cs.columbia.edu/msg16235.html select ANON_INODES help VFIO provides a framework for secure userspace device drivers.
[v2 2/2] media: i2c: Add driver for Aptina MT9V111
From: Jacopo Mondi Add V4L2 sensor driver for Aptina MT9V111 CMOS image sensor. The MT9V111 is a 1/4-Inch CMOS image sensor based on MT9V011 with an integrated Image Flow Processor. Reviewed-by: Kieran Bingham Signed-off-by: Jacopo Mondi --- drivers/media/i2c/Kconfig | 11 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/mt9v111.c | 1298 +++ 3 files changed, 1310 insertions(+) create mode 100644 drivers/media/i2c/mt9v111.c diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index 8669853..b6fea81 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -861,6 +861,17 @@ config VIDEO_MT9V032 This is a Video4Linux2 sensor-level driver for the Micron MT9V032 752x480 CMOS sensor. +config VIDEO_MT9V111 + tristate "Aptina MT9V111 sensor support" + depends on I2C && VIDEO_V4L2 + depends on MEDIA_CAMERA_SUPPORT + help + This is a Video4Linux2 sensor driver for the Aptina/Micron + MT9V111 sensor. + + To compile this driver as a module, choose M here: the + module will be called mt9v111. + config VIDEO_SR030PC30 tristate "Siliconfile SR030PC30 sensor support" depends on I2C && VIDEO_V4L2 diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index 837c428..ba9a1e4 100644 --- a/drivers/media/i2c/Makefile +++ b/drivers/media/i2c/Makefile @@ -86,6 +86,7 @@ obj-$(CONFIG_VIDEO_MT9T001) += mt9t001.o obj-$(CONFIG_VIDEO_MT9T112) += mt9t112.o obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o +obj-$(CONFIG_VIDEO_MT9V111) += mt9v111.o obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o obj-$(CONFIG_VIDEO_RJ54N1) += rj54n1cb0c.o diff --git a/drivers/media/i2c/mt9v111.c b/drivers/media/i2c/mt9v111.c new file mode 100644 index 000..da8f6ab --- /dev/null +++ b/drivers/media/i2c/mt9v111.c @@ -0,0 +1,1298 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * V4L2 sensor driver for Aptina MT9V111 image sensor + * Copyright (C) 2018 Jacopo Mondi + * + * Based on mt9v032 driver + * Copyright (C) 2010, Laurent Pinchart + * Copyright (C) 2008, Guennadi Liakhovetski + * + * Based on mt9v011 driver + * Copyright (c) 2009 Mauro Carvalho Chehab + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +/* + * MT9V111 is a 1/4-Inch CMOS digital image sensor with an integrated + * Image Flow Processing (IFP) engine and a sensor core loosely based on + * MT9V011. + * + * The IFP can produce several output image formats from the sensor core + * output. This driver currently supports only YUYV format permutations. + * + * The driver allows manual frame rate control through s_frame_interval subdev + * operation or V4L2_CID_V/HBLANK controls, but it is known that the + * auto-exposure algorithm might modify the programmed frame rate. While the + * driver initially programs the sensor with auto-exposure and + * auto-white-balancing enabled, it is possible to disable them and more + * precisely control the frame rate. + * + * While it seems possible to instruct the auto-exposure control algorithm to + * respect a programmed frame rate when adjusting the pixel integration time, + * registers controlling this feature are not documented in the public + * available sensor manual used to develop this driver (09005aef80e90084, + * MT9V111_1.fm - Rev. G 1/05 EN). + */ + +#define MT9V111_CHIP_ID_HIGH 0x82 +#define MT9V111_CHIP_ID_LOW0x3a + +#define MT9V111_R01_ADDR_SPACE 0x01 +#define MT9V111_R01_IFP0x01 +#define MT9V111_R01_CORE 0x04 + +#define MT9V111_IFP_R06_OPMODE_CTRL0x06 +#defineMT9V111_IFP_R06_OPMODE_CTRL_AWB_EN BIT(1) +#defineMT9V111_IFP_R06_OPMODE_CTRL_AE_EN BIT(14) +#define MT9V111_IFP_R07_IFP_RESET 0x07 +#defineMT9V111_IFP_R07_IFP_RESET_MASK BIT(0) +#define MT9V111_IFP_R08_OUTFMT_CTRL0x08 +#defineMT9V111_IFP_R08_OUTFMT_CTRL_FLICKER BIT(11) +#defineMT9V111_IFP_R08_OUTFMT_CTRL_PCLKBIT(5) +#define MT9V111_IFP_R3A_OUTFMT_CTRL2 0x3a +#defineMT9V111_IFP_R3A_OUTFMT_CTRL2_SWAP_CBCR BIT(0) +#defineMT9V111_IFP_R3A_OUTFMT_CTRL2_SWAP_YCBIT(1) +#defineMT9V111_IFP_R3A_OUTFMT_CTRL2_SWAP_MASK GENMASK(2, 0) +#define MT9V111_IFP_RA5_HPAN 0xa5 +#define MT9V111_IFP_RA6_HZOOM 0xa6 +#define MT9V111_IFP_RA7_HOUT 0xa7 +#define MT9V111_IFP_RA8_VPAN 0xa8 +#define MT9V111_IFP_RA9_VZOOM
[v2 1/2] dt-bindings: media: i2c: Document MT9V111 bindings
From: Jacopo Mondi
Add documentation for Aptina MT9V111 image sensor.
Reviewed-by: Rob Herring
Signed-off-by: Jacopo Mondi
---
.../bindings/media/i2c/aptina,mt9v111.txt | 46 ++
MAINTAINERS| 8
2 files changed, 54 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
b/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
new file mode 100644
index 000..bd896e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
@@ -0,0 +1,46 @@
+* Aptina MT9V111 CMOS sensor
+
+
+The Aptina MT9V111 is a 1/4-Inch VGA-format digital image sensor with a core
+based on Aptina MT9V011 sensor and an integrated Image Flow Processor (IFP).
+
+The sensor has an active pixel array of 640x480 pixels and can output a number
+of image resolution and formats controllable through a simple two-wires
+interface.
+
+Required properties:
+
+
+- compatible: shall be "aptina,mt9v111".
+- clocks: reference to the system clock input provider.
+
+Optional properties:
+
+
+- enable-gpios: output enable signal, pin name "OE#". Active low.
+- standby-gpios: low power state control signal, pin name "STANDBY".
+ Active high.
+- reset-gpios: chip reset signal, pin name "RESET#". Active low.
+
+The device node must contain one 'port' child node with one 'endpoint' child
+sub-node for its digital output video port, in accordance with the video
+interface bindings defined in:
+Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+
+ {
+camera@48 {
+compatible = "aptina,mt9v111";
+reg = <0x48>;
+
+clocks = <_clk>;
+
+port {
+mt9v111_out: endpoint {
+remote-endpoint = <_in>;
+};
+};
+};
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index bbd9b9b..4ab113c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9651,6 +9651,14 @@ F:
Documentation/devicetree/bindings/media/i2c/mt9v032.txt
F: drivers/media/i2c/mt9v032.c
F: include/media/i2c/mt9v032.h
+MT9V111 APTINA CAMERA SENSOR
+M: Jacopo Mondi
+L: linux-me...@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
+F: drivers/media/i2c/mt9v111.c
+
MULTIFUNCTION DEVICES (MFD)
M: Lee Jones
T: git git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git
--
2.7.4
[v2 0/2] media: i2c: mt9v111 sensor driver
Hello, this is a sensor level driver for Aptina MT9V111. Compared to v1 the biggest difference is that now auto-exposure and auto-white-balancing are exposed through the v4l2-ctrl framework, and can be activated/deactivated by the user. For this reason, while auto-exposure algorithm still controls the frame rate in low light conditions, the driver now enables it by default and let the user disable it to more precisely control the framerate. (Most of the) comments from Sakari and Kieran have been addressed, see changelog for a more precise list. Tested VGA, QVGA QQVGA resolutions at 5, 10, 15 and 30 frame per second. v4l2-compliance fails on some tests, and I've not been able to identify what's wrong with the driver. Copy of the failures reported here below: fail: v4l2-test-subdevs.cpp(69): doioctl(node, VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL, ) != EINVAL fail: v4l2-test-subdevs.cpp(180): ret && ret != ENOTTY fail: v4l2-test-subdevs.cpp(248): ret && ret != ENOTTY test Active VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: FAIL I've found no mention of ENOTTY to be reported by enum_frame_interval in the documentation, but apparently v4l2-compliance checks for that. v1: https://lkml.org/lkml/2018/6/11/467 Thanks j v1 -> v2: - Addressed syntax mistakes pointed out by Kieran - Drop spinlock around address space change - Extend mutex to cover frame rate and format get/set operations - Add controls for auto-exposure and auto-white-balancing - Move MAINTAINERS modifications to bindings patch - Fix resolution in bindings document - Drop dependency on OF - Drop subdev 'open' function in favour of pad operation init_cfg and use a default configuration to initialize the sensor - Turn off power if sensor identification fails Jacopo Mondi (2): dt-bindings: media: i2c: Document MT9V111 bindings media: i2c: Add driver for Aptina MT9V111 .../bindings/media/i2c/aptina,mt9v111.txt | 46 + MAINTAINERS|8 + drivers/media/i2c/Kconfig | 11 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/mt9v111.c| 1299 5 files changed, 1365 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt create mode 100644 drivers/media/i2c/mt9v111.c -- 2.7.4
Re: [PATCH 1/2] mmc: renesas_sdhi: skip SCC error check when retuning
Hi Wolfram, On 2018-07-25 14:21:07 +0200, Wolfram Sang wrote: > Hi Niklas, > > > * Changes since v3 > > - Add check for 4TAP for HS400. > > Is it the same in the BSP or where does this info come from? It comes from the BSP but I had to modify it to fit with the upstream implementation of 4 vs 8 taps. The original code from BSP: if (!(host->mmc->ios.timing == MMC_TIMING_UHS_SDR104) && !(host->mmc->ios.timing == MMC_TIMING_MMC_HS200) && !(host->mmc->ios.timing == MMC_TIMING_MMC_HS400 && !host->hs400_use_4tap)) return false; > > > > + if (!(host->mmc->ios.timing == MMC_TIMING_UHS_SDR104) && > > + !(host->mmc->ios.timing == MMC_TIMING_MMC_HS200) && > > + !(host->mmc->ios.timing == MMC_TIMING_MMC_HS400 && > > + !(host->pdata->flags & TMIO_MMC_HAVE_4TAP_HS400))) > > This becomes very hard to read. We need to simplify it. I agree but I could not find a neat way of doing it. How about? bool use_4tap = host->pdata->flags & TMIO_MMC_HAVE_4TAP_HS400; if (!(host->mmc->ios.timing == MMC_TIMING_UHS_SDR104) && !(host->mmc->ios.timing == MMC_TIMING_MMC_HS200) && !(host->mmc->ios.timing == MMC_TIMING_MMC_HS400 && !use_4tap)) return false; > > And can you bounce me your debugging mail from today again? I seem to > have lost it :( Bounced. > > Thanks, > >Wolfram -- Regards, Niklas Söderlund
[PATCH/RFC] drivers/vfio: Allow type-1 IOMMU instantiation with Renesas IPMMU-VMSA
The Renesas IPMMU-VMSA driver is compatible with the notion of a type-1 IOMMU in VFIO. This patch allows guests to use the VFIO_IOMMU_TYPE1 API on hosts equipped with a Renesas VMSA-compatible IPMMU. Signed-off-by: Geert Uytterhoeven --- Lightly tested with sata_rcar on Renesas R-Car H3 ES2.0. For testing, this patch and all prerequisites are available in the topic/rcar3-virt-gpio-passthrough-v3 branch of my git repository at git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git. --- drivers/vfio/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig index c84333eb5eb59bef..a3e21e7c066596d7 100644 --- a/drivers/vfio/Kconfig +++ b/drivers/vfio/Kconfig @@ -21,7 +21,8 @@ config VFIO_VIRQFD menuconfig VFIO tristate "VFIO Non-Privileged userspace driver framework" depends on IOMMU_API - select VFIO_IOMMU_TYPE1 if (X86 || S390 || ARM_SMMU || ARM_SMMU_V3) + select VFIO_IOMMU_TYPE1 if (X86 || S390 || ARM_SMMU || ARM_SMMU_V3 || \ + IPMMU_VMSA) select ANON_INODES help VFIO provides a framework for secure userspace device drivers. -- 2.17.1
[PATCH v2] iommu/ipmmu-vmsa: Fix allocation in atomic context
When attaching a device to an IOMMU group with
CONFIG_DEBUG_ATOMIC_SLEEP=y:
BUG: sleeping function called from invalid context at mm/slab.h:421
in_atomic(): 1, irqs_disabled(): 128, pid: 61, name: kworker/1:1
...
Call trace:
...
arm_lpae_alloc_pgtable+0x114/0x184
arm_64_lpae_alloc_pgtable_s1+0x2c/0x128
arm_32_lpae_alloc_pgtable_s1+0x40/0x6c
alloc_io_pgtable_ops+0x60/0x88
ipmmu_attach_device+0x140/0x334
ipmmu_attach_device() takes a spinlock, while arm_lpae_alloc_pgtable()
allocates memory using GFP_KERNEL. Originally, the ipmmu-vmsa driver
had its own custom page table allocation implementation using
GFP_ATOMIC, hence the spinlock was fine.
Fix this by replacing the spinlock by a mutex, like the arm-smmu driver
does.
Fixes: f20ed39f53145e45 ("iommu/ipmmu-vmsa: Use the ARM LPAE page table
allocator")
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
---
v2:
- Add Reviewed-by.
---
drivers/iommu/ipmmu-vmsa.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 40ae6e87cb880223..ef566b4989d6e2f8 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -73,7 +73,7 @@ struct ipmmu_vmsa_domain {
struct io_pgtable_ops *iop;
unsigned int context_id;
- spinlock_t lock;/* Protects mappings */
+ struct mutex mutex; /* Protects mappings */
};
static struct ipmmu_vmsa_domain *to_vmsa_domain(struct iommu_domain *dom)
@@ -595,7 +595,7 @@ static struct iommu_domain *__ipmmu_domain_alloc(unsigned
type)
if (!domain)
return NULL;
- spin_lock_init(>lock);
+ mutex_init(>mutex);
return >io_domain;
}
@@ -641,7 +641,6 @@ static int ipmmu_attach_device(struct iommu_domain
*io_domain,
struct iommu_fwspec *fwspec = dev->iommu_fwspec;
struct ipmmu_vmsa_device *mmu = to_ipmmu(dev);
struct ipmmu_vmsa_domain *domain = to_vmsa_domain(io_domain);
- unsigned long flags;
unsigned int i;
int ret = 0;
@@ -650,7 +649,7 @@ static int ipmmu_attach_device(struct iommu_domain
*io_domain,
return -ENXIO;
}
- spin_lock_irqsave(>lock, flags);
+ mutex_lock(>mutex);
if (!domain->mmu) {
/* The domain hasn't been used yet, initialize it. */
@@ -674,7 +673,7 @@ static int ipmmu_attach_device(struct iommu_domain
*io_domain,
} else
dev_info(dev, "Reusing IPMMU context %u\n", domain->context_id);
- spin_unlock_irqrestore(>lock, flags);
+ mutex_unlock(>mutex);
if (ret < 0)
return ret;
--
2.17.1
[PATCH] iommu/ipmmu-vmsa: Clarify supported platforms
The Renesas IPMMU-VMSA driver supports not just R-Car H2 and M2 SoCs, but also other R-Car Gen2 and R-Car Gen3 SoCs. Drop a superfluous "Renesas" while at it. Signed-off-by: Geert Uytterhoeven --- drivers/iommu/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index 568ae81b0e99b67b..c69dc0b29b5df37f 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -306,8 +306,8 @@ config IPMMU_VMSA select IOMMU_IO_PGTABLE_LPAE select ARM_DMA_USE_IOMMU help - Support for the Renesas VMSA-compatible IPMMU Renesas found in the - R-Mobile APE6 and R-Car H2/M2 SoCs. + Support for the Renesas VMSA-compatible IPMMU found in the R-Mobile + APE6, R-Car Gen2, and R-Car Gen3 SoCs. If unsure, say N. -- 2.17.1
Re: [PATCH 2/2] serial: sh-sci: Document r7s9210 bindings
Hi Chris,
On Wed, Jul 25, 2018 at 2:05 PM Chris Brandt wrote:
> On Wednesday, July 25, 2018, Geert Uytterhoeven wrote:
> > > However, if "interrupt-names" is specified in DT, then the driver
> > > determines what the interrupt are based on their names, not the order in
> > which
> > > they are listed.
> > >
> > > Correct?
> >
> > Correct.
>
> One final note on this before I submit v2 of the patch.
>
> I just coded up something that works and is more simple and I don't even
> need "interrupt-names".
>
> Basically by using your suggestion from the code review made everything
> work.
>
> On Friday, July 20, 2018, Geert Uytterhoeven wrote:
> > > --- a/drivers/tty/serial/sh-sci.c
> > > +++ b/drivers/tty/serial/sh-sci.c
> > > @@ -65,6 +65,7 @@ enum {
> > > SCIx_RXI_IRQ,
> > > SCIx_TXI_IRQ,
> > > SCIx_BRI_IRQ,
> > > + SCIx_TEIDRI_IRQ,
> >
> > Why not separate enum values for TEI and DRI? According to the RZ/A2 docs,
> > there are 6 separate interrupts, but they are multiplexed at the interrupt
> > controller level.
>
>
> enum {
> SCIx_ERI_IRQ,
> SCIx_RXI_IRQ,
> SCIx_TXI_IRQ,
> SCIx_BRI_IRQ,
> + SCIx_DRI_IRQ,
> + SCIx_TEI_IRQ,
> SCIx_NR_IRQS,
>
> SCIx_MUX_IRQ = SCIx_NR_IRQS,/* special case */
> };
>
> Listing the same interrupt ID number twice in the DT (because it is
> muxed) is fine because the driver will check for that.
>
> This seems to satisfy all the SCI/SCIF variants in all the SH and ARM
> SoCs in the kernel today (DT and non-DT).
>
> So as long as I describe the interrupt order in the DT Documentation,
> all seems good.
Yes, that should work too.
"interrupt-names" is handy for DTS writers, so they don't have to look up the
order in the bindings, and it's less likely they make mistakes in the
order of the
interrupts.
However, as soon as there will be an SoC where you will need a "hole"
in the list,
you're gonna need interrupt-names anyway.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
Re: [PATCH 1/2] mmc: renesas_sdhi: skip SCC error check when retuning
Hi Niklas, > * Changes since v3 > - Add check for 4TAP for HS400. Is it the same in the BSP or where does this info come from? > + if (!(host->mmc->ios.timing == MMC_TIMING_UHS_SDR104) && > + !(host->mmc->ios.timing == MMC_TIMING_MMC_HS200) && > + !(host->mmc->ios.timing == MMC_TIMING_MMC_HS400 && > + !(host->pdata->flags & TMIO_MMC_HAVE_4TAP_HS400))) This becomes very hard to read. We need to simplify it. And can you bounce me your debugging mail from today again? I seem to have lost it :( Thanks, Wolfram signature.asc Description: PGP signature
[PATCH 2/2] mmc: tmio: Fix SCC error detection
From: Masaharu Hayakawa
SDR104 and HS200 need to check for SCC error. If SCC error is detected,
retuning is necessary.
Signed-off-by: Masaharu Hayakawa
[Niklas: update commit message]
Signed-off-by: Niklas Söderlund
---
drivers/mmc/host/tmio_mmc_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index 72ac806e0c762d83..81883bc08524e441 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -920,8 +920,8 @@ static void tmio_mmc_finish_request(struct tmio_mmc_host
*host)
if (mrq->cmd->error || (mrq->data && mrq->data->error))
tmio_mmc_abort_dma(host);
- if (host->check_scc_error)
- host->check_scc_error(host);
+ if (host->check_scc_error && host->check_scc_error(host))
+ mrq->cmd->error = -EILSEQ;
/* If SET_BLOCK_COUNT, continue with main command */
if (host->mrq && !mrq->cmd->error) {
--
2.18.0
[PATCH 0/2] mmc: {tmio,renesas_sdhi}: retune if SCC error detected
Hi, These patches triggers a retune if a SCC error is detected. They where ported from the renesas BSP. Masaharu-san did all the real work I just ported them to upstream and did small fixups. These patches where broken out of my retuning series as more work where needed to adapt them to the recent HS400 series picked-up. It's tested on M3-N using both HS200 and HS400 and on H3 ES2.0 using HS200. Masaharu Hayakawa (2): mmc: renesas_sdhi: skip SCC error check when retuning mmc: tmio: Fix SCC error detection drivers/mmc/host/renesas_sdhi_core.c | 9 + drivers/mmc/host/tmio_mmc_core.c | 4 ++-- 2 files changed, 11 insertions(+), 2 deletions(-) -- 2.18.0
[PATCH 1/2] mmc: renesas_sdhi: skip SCC error check when retuning
From: Masaharu Hayakawa
Checking for SCC error during retuning is unnecessary.
Signed-off-by: Masaharu Hayakawa
[Niklas: fix small style issue]
Signed-off-by: Niklas Söderlund
---
* Changes since v3
- Add check for 4TAP for HS400.
* Changes since v2
- Added check for HS400 as it's now merged.
- Added tags from Wolfram.
---
drivers/mmc/host/renesas_sdhi_core.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/mmc/host/renesas_sdhi_core.c
b/drivers/mmc/host/renesas_sdhi_core.c
index 777e32b0e410e850..2e0d2eafd62ebecf 100644
--- a/drivers/mmc/host/renesas_sdhi_core.c
+++ b/drivers/mmc/host/renesas_sdhi_core.c
@@ -444,6 +444,15 @@ static bool renesas_sdhi_check_scc_error(struct
tmio_mmc_host *host)
{
struct renesas_sdhi *priv = host_to_priv(host);
+ if (!(host->mmc->ios.timing == MMC_TIMING_UHS_SDR104) &&
+ !(host->mmc->ios.timing == MMC_TIMING_MMC_HS200) &&
+ !(host->mmc->ios.timing == MMC_TIMING_MMC_HS400 &&
+ !(host->pdata->flags & TMIO_MMC_HAVE_4TAP_HS400)))
+ return false;
+
+ if (host->mmc->doing_retune)
+ return false;
+
/* Check SCC error */
if (sd_scc_read32(host, priv, SH_MOBILE_SDHI_SCC_RVSCNTL) &
SH_MOBILE_SDHI_SCC_RVSCNTL_RVSEN &&
--
2.18.0
RE: [PATCH 2/2] serial: sh-sci: Document r7s9210 bindings
Hi Geert,
On Wednesday, July 25, 2018, Geert Uytterhoeven wrote:
> > However, if "interrupt-names" is specified in DT, then the driver
> > determines what the interrupt are based on their names, not the order in
> which
> > they are listed.
> >
> > Correct?
>
> Correct.
One final note on this before I submit v2 of the patch.
I just coded up something that works and is more simple and I don't even
need "interrupt-names".
Basically by using your suggestion from the code review made everything
work.
On Friday, July 20, 2018, Geert Uytterhoeven wrote:
> > --- a/drivers/tty/serial/sh-sci.c
> > +++ b/drivers/tty/serial/sh-sci.c
> > @@ -65,6 +65,7 @@ enum {
> > SCIx_RXI_IRQ,
> > SCIx_TXI_IRQ,
> > SCIx_BRI_IRQ,
> > + SCIx_TEIDRI_IRQ,
>
> Why not separate enum values for TEI and DRI? According to the RZ/A2 docs,
> there are 6 separate interrupts, but they are multiplexed at the interrupt
> controller level.
enum {
SCIx_ERI_IRQ,
SCIx_RXI_IRQ,
SCIx_TXI_IRQ,
SCIx_BRI_IRQ,
+ SCIx_DRI_IRQ,
+ SCIx_TEI_IRQ,
SCIx_NR_IRQS,
SCIx_MUX_IRQ = SCIx_NR_IRQS,/* special case */
};
Listing the same interrupt ID number twice in the DT (because it is
muxed) is fine because the driver will check for that.
This seems to satisfy all the SCI/SCIF variants in all the SH and ARM
SoCs in the kernel today (DT and non-DT).
So as long as I describe the interrupt order in the DT Documentation,
all seems good.
Chris
[PATCH] hw/arm/sysbus-fdt: Fix assertion in copy_properties_from_host()
When copy_properties_from_host() ignores the error for an optional
property, it frees the error, but fails to reset it.
Hence if two or more optional properties are missing, an assertion is
triggered:
util/error.c:57: error_setv: Assertion `*errp == NULL' failed.
Fis this by resetting err to NULL after ignoring the error.
Fixes: 9481cf2e5f2f2bb6 ("hw/arm/sysbus-fdt: helpers for clock node generation")
Signed-off-by: Geert Uytterhoeven
---
hw/arm/sysbus-fdt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/arm/sysbus-fdt.c b/hw/arm/sysbus-fdt.c
index 0d4c75702c3ddfae..43d6a7bb48ddc351 100644
--- a/hw/arm/sysbus-fdt.c
+++ b/hw/arm/sysbus-fdt.c
@@ -107,6 +107,7 @@ static void copy_properties_from_host(HostProperty *props,
int nb_props,
/* mandatory property not found: bail out */
exit(1);
}
+err = NULL;
}
}
}
--
2.17.1
[PATCH v4] drivers/firmware: psci_checker: stash and use topology_core_cpumask for hotplug tests
Commit 7f9545aa1a91 ("arm64: smp: remove cpu and numa topology
information when hotplugging out CPU") updates the cpu topology when
the CPU is hotplugged out. However the PSCI checker code uses the
topology_core_cpumask pointers for some of the cpu hotplug testing.
Since the pointer to the core_cpumask of the first CPU in the group
is used, which when that CPU itself is hotpugged out is just set to
itself, the testing terminates after that particular CPU is tested out.
But the intention of this tests is to cover all the CPU in the group.
In order to support that, we need to stash the topology_core_cpumask
before the start of the test and use that value instead of pointer to
a cpumask which will be updated on CPU hotplug.
Fixes: 7f9545aa1a91a9a4 ("arm64: smp: remove cpu and numa topology
information when hotplugging out CPU")
Reported-by: Geert Uytterhoeven
Tested-by: Geert Uytterhoeven
Cc: Mark Rutland
Acked-by: Lorenzo Pieralisi
Signed-off-by: Sudeep Holla
---
drivers/firmware/psci_checker.c | 83 -
1 file changed, 49 insertions(+), 34 deletions(-)
Hi ARM SoC,
Though the fixes tag points to a commit in arm64/for-next/core,
it shouldn't be any issue to take this via ARM SoC for v4.19
Will suggested the same.
Regards,
Sudeep
v3->v4:
- Added all tested and acks
- Resending including arm-soc team
v2->v3:
- Got rid of find_cpu_groups as suggested by Lorenzo
diff --git a/drivers/firmware/psci_checker.c b/drivers/firmware/psci_checker.c
index bb1c068bff19..346943657962 100644
--- a/drivers/firmware/psci_checker.c
+++ b/drivers/firmware/psci_checker.c
@@ -77,28 +77,6 @@ static int psci_ops_check(void)
return 0;
}
-static int find_cpu_groups(const struct cpumask *cpus,
- const struct cpumask **cpu_groups)
-{
- unsigned int nb = 0;
- cpumask_var_t tmp;
-
- if (!alloc_cpumask_var(, GFP_KERNEL))
- return -ENOMEM;
- cpumask_copy(tmp, cpus);
-
- while (!cpumask_empty(tmp)) {
- const struct cpumask *cpu_group =
- topology_core_cpumask(cpumask_any(tmp));
-
- cpu_groups[nb++] = cpu_group;
- cpumask_andnot(tmp, tmp, cpu_group);
- }
-
- free_cpumask_var(tmp);
- return nb;
-}
-
/*
* offlined_cpus is a temporary array but passing it as an argument avoids
* multiple allocations.
@@ -166,29 +144,66 @@ static unsigned int down_and_up_cpus(const struct cpumask
*cpus,
return err;
}
+static void free_cpu_groups(int num, cpumask_var_t **pcpu_groups)
+{
+ int i;
+ cpumask_var_t *cpu_groups = *pcpu_groups;
+
+ for (i = 0; i < num; ++i)
+ free_cpumask_var(cpu_groups[i]);
+ kfree(cpu_groups);
+}
+
+static int alloc_init_cpu_groups(cpumask_var_t **pcpu_groups)
+{
+ int num_groups = 0;
+ cpumask_var_t tmp, *cpu_groups;
+
+ if (!alloc_cpumask_var(, GFP_KERNEL))
+ return -ENOMEM;
+
+ cpu_groups = kcalloc(nb_available_cpus, sizeof(cpu_groups),
+GFP_KERNEL);
+ if (!cpu_groups)
+ return -ENOMEM;
+
+ cpumask_copy(tmp, cpu_online_mask);
+
+ while (!cpumask_empty(tmp)) {
+ const struct cpumask *cpu_group =
+ topology_core_cpumask(cpumask_any(tmp));
+
+ if (!alloc_cpumask_var(_groups[num_groups], GFP_KERNEL)) {
+ free_cpu_groups(num_groups, _groups);
+ return -ENOMEM;
+ }
+ cpumask_copy(cpu_groups[num_groups++], cpu_group);
+ cpumask_andnot(tmp, tmp, cpu_group);
+ }
+
+ free_cpumask_var(tmp);
+ *pcpu_groups = cpu_groups;
+
+ return num_groups;
+}
+
static int hotplug_tests(void)
{
- int err;
- cpumask_var_t offlined_cpus;
- int i, nb_cpu_group;
- const struct cpumask **cpu_groups;
+ int i, nb_cpu_group, err = -ENOMEM;
+ cpumask_var_t offlined_cpus, *cpu_groups;
char *page_buf;
- err = -ENOMEM;
if (!alloc_cpumask_var(_cpus, GFP_KERNEL))
return err;
- /* We may have up to nb_available_cpus cpu_groups. */
- cpu_groups = kmalloc_array(nb_available_cpus, sizeof(*cpu_groups),
- GFP_KERNEL);
- if (!cpu_groups)
+
+ nb_cpu_group = alloc_init_cpu_groups(_groups);
+ if (nb_cpu_group < 0)
goto out_free_cpus;
page_buf = (char *)__get_free_page(GFP_KERNEL);
if (!page_buf)
goto out_free_cpu_groups;
err = 0;
- nb_cpu_group = find_cpu_groups(cpu_online_mask, cpu_groups);
-
/*
* Of course the last CPU cannot be powered down and cpu_down() should
* refuse doing that.
@@ -212,7 +227,7 @@ static int hotplug_tests(void)
free_page((unsigned long)page_buf);
out_free_cpu_groups:
-
[PATCH] dmaengine: sh: rcar-dmac: Should not stop the DMAC by rcar_dmac_sync_tcr()
rcar_dmac_chan_get_residue() should not stop the DMAC, because
the commit 538603c6026c ("dmaengine: sh: rcar-dmac: avoid to write
CHCR.TE to 1 if TCR is set to 0") had fixed unexpected re-transferring
issue. But it had caused the next issue which might stop the cyclic
mode transferring. Thus, for example R-Car sound might be stopped
suddenly.
According to the commit 73a47bd0da66 ("dmaengine: rcar-dmac: use TCRB
instead of TCR for residue"), the purpose of clearing CHCR.DE bit is
flushing buffered data to calculate the exact residue.
Such the "exact" residue had been required by sh-sci driver. sh-sci
driver is calling dmaengine_pause() to stop transferring, and get
"exact" residue. Otherwise, it might receive extra data during
getting residue without pausing.
In rx_timer_fn() of sh-sci driver:
dmaengine_tx_status(); /* For checking roughly */
dmaengine_pause();
dmaengine_tx_status(); /* For getting residue */
dmaengine_terminate_all();
But, unfortunately the rcar-dmac driver didn't support dmaengine_pause()
at that time. So, the sh-sci driver cannot get the "exact" residue
without stopping the transferring, because rcar-dmac is buffering data
inside.
Because of these backgrounds, rcar-dmac had been cleared/set CHCR.DE
bit in rcar_dmac_chan_get_residue() to synchronizing data and getting
"exact" residue.
However, rcar-dmac driver has rcar_dmac_chan_pause() now, and clearing
CHCR.DE bit in rcar_dmac_chan_get_residue() doesn't need anymore.
So, this patch removes the rcar_dmac_sync_tcr().
Fixes: 73a47bd0da66 ("dmaengine: rcar-dmac: use TCRB instead of TCR for
residue")
Signed-off-by: Yoshihiro Shimoda
Tested-by: Hiroyuki Yokoyama
---
drivers/dma/sh/rcar-dmac.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index be82d69..48ee35e 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -770,20 +770,6 @@ static void rcar_dmac_clear_chcr_de(struct rcar_dmac_chan
*chan)
rcar_dmac_chcr_de_barrier(chan);
}
-static void rcar_dmac_sync_tcr(struct rcar_dmac_chan *chan)
-{
- u32 chcr = rcar_dmac_chan_read(chan, RCAR_DMACHCR);
-
- if (!(chcr & RCAR_DMACHCR_DE))
- return;
-
- rcar_dmac_clear_chcr_de(chan);
-
- /* back DE if remain data exists */
- if (rcar_dmac_chan_read(chan, RCAR_DMATCR))
- rcar_dmac_chan_write(chan, RCAR_DMACHCR, chcr);
-}
-
static void rcar_dmac_chan_halt(struct rcar_dmac_chan *chan)
{
u32 chcr = rcar_dmac_chan_read(chan, RCAR_DMACHCR);
@@ -1367,9 +1353,6 @@ static unsigned int rcar_dmac_chan_get_residue(struct
rcar_dmac_chan *chan,
residue += chunk->size;
}
- if (desc->direction == DMA_DEV_TO_MEM)
- rcar_dmac_sync_tcr(chan);
-
/* Add the residue for the current chunk. */
residue += rcar_dmac_chan_read(chan, RCAR_DMATCRB) << desc->xfer_shift;
--
1.9.1
Re: [PATCH 2/2] serial: sh-sci: Document r7s9210 bindings
Hi Chris,
On Wed, Jul 25, 2018 at 3:38 AM Chris Brandt wrote:
> I have one last clarification about your idea regarding documenting the
> interrupts separately for RZ/A2.
>
> On Thursday, July 19, 2018, Geert Uytterhoeven wrote:
> > For DT backwards compatibility, we have to keep support for the following
> > 2 schemes:
> > 1. Single "interrupts" value, no "interrupt-names", for fully
> > multiplexed
> > interrupts (SH/R-Mobile, R-Car).
> > 2. Four "interrupts" values, no "interrupt-names", for ERI/RXI/TXI/TEI
> > (RZ/A1, H8/300).
> >
> > For RZ/A2, I suggest extending the bindings with interrupt-names,
> > documenting all 6 interrupt sources, and let the driver handle that.
> > That means there should be 6, not 5, "interrupts" values.
> > Whether the driver implements all possible combinations, or only what you
> > need for RZ/A2, is up to you. I agree the interrupt handling in the driver
> > is already sufficiently complex.
> > Ideally, you would document support for RZ/A1 with interrupt-names too,
> > and handle that as well.
>
> So for backward compatibility, no existing DT or setup-xxx.c (SH) file
> should change and the driver needs to assume the order of interrupts.
You can change the setup-xxx.c (SH) files, if needed. There's no in-kernel
stable ABI.
> However, if "interrupt-names" is specified in DT, then the driver
> determines what the interrupt are based on their names, not the order in which
> they are listed.
>
> Correct?
Correct.
> So for example, RZ/A1 DT will stay the same and since "interrupt-names"
> was never used and the interrupt order will be assumed as
> ERI/RXI/TXI/BRI.
>
> RZ/A1 [ r7s72100.dtsi ]
> scif0: serial@e8007000 {
> compatible = "renesas,scif-r7s72100", "renesas,scif";
> reg = <0xe8007000 64>;
> interrupts = ,
> ,
> ,
> ;
> clocks = <_clks R7S72100_CLK_SCIF0>;
> clock-names = "fck";
> power-domains = <_clocks>;
> status = "disabled";
> };
Correct.
> However, for RZ/A2, "interrupt-names" will be used and then the driver
> will sort things out however it needs to (figuring out what signals
> are muxed together an such).
>
> RZ/A2 [ r7s9210.dtsi ]
> scif0: serial@e8007000 {
> compatible = "renesas,scif-r7s9210", "renesas,scif";
> reg = <0xe8007000 18>;
> interrupts = , /* ERI/BRI */
> , /* RXI */
> , /* TXI */
> , /* ERI/BRI */
> , /* TEI/DRI */
> ; /* TEI/DRI */
> interrupt-names = "eri", "rxi", "txi", "bri", "tei", "dri";
>
> clocks = <_clks R7S9210_CLK_SCIF0>;
> clock-names = "fck";
> power-domains = <_clocks>;
> status = "disabled";
> };
Correct.
> Are we on the same page?
I think so.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
