[PATCH /2] arm64: dts: renesas: r8a77970: add MMC support
Define the generic R8A77970 part of the MMC0 (SDHI2) device node.
Based on the original (and large) patches by Vladimir Barinov.
Signed-off-by: Vladimir Barinov
Signed-off-by: Sergei Shtylyov
---
arch/arm64/boot/dts/renesas/r8a77970.dtsi | 12
1 file changed, 12 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77970.dtsi
===
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77970.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77970.dtsi
@@ -754,6 +754,18 @@
#iommu-cells = <1>;
};
+ mmc0: mmc@ee14 {
+ compatible = "renesas,sdhi-r8a77970",
+"renesas,rcar-gen3-sdhi";
+ reg = <0 0xee14 0 0x2000>;
+ interrupts = ;
+ clocks = < CPG_MOD 314>;
+ power-domains = < R8A77970_PD_ALWAYS_ON>;
+ resets = < 314>;
+ max-frequency = <2>;
+ status = "disabled";
+ };
+
gic: interrupt-controller@f101 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
[PATCH 2/2] arm64: dts: renesas: v3msk: add eMMC support
Add the eMMC chip support for the V3M Started Kit board.
Based on the original (and large) patches by Vladimir Barinov.
Signed-off-by: Vladimir Barinov
Signed-off-by: Sergei Shtylyov
---
arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts | 26 +
1 file changed, 26 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts
===
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts
+++ renesas/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts
@@ -51,6 +51,15 @@
regulator-always-on;
};
+ vcc_vddq_vin0: regulator-2 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_VDDQ_VIN0";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
lvds-decoder {
compatible = "thine,thc63lvd1024";
vcc-supply = <_d3_3v>;
@@ -128,6 +137,12 @@
function = "i2c0";
};
+ mmc_pins: mmc_3_3v {
+ groups = "mmc_data8", "mmc_ctrl";
+ function = "mmc";
+ power-source = <3300>;
+ };
+
scif0_pins: scif0 {
groups = "scif0_data";
function = "scif0";
@@ -192,6 +207,17 @@
};
};
+ {
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+
+ vmmc-supply = <_d3_3v>;
+ vqmmc-supply = <_vddq_vin0>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
+
{
pinctrl-0 = <_pins>;
pinctrl-names = "default";
[PATCH 0/2] Add R8A77980/Condor eMMC support
Hello! Here's the set of 2 patches against Simon Horman's 'renesas.git' repo's 'renesas-devel-20180810-v4.18-rc7' tag. We're adding the R8A77970 MMC0 (SDHI2) device nodes and then enable eMMC support on the V3M Starter Kit board. The SDHI (w/internal DMA) driver patch white-listing the R8A77970 was posted last Saturday; the R8A77970 CPG/MSSR driver patch and the SDHI bindings patch have been posted earlier today. [1/2] arm64: dts: renesas: r8a77970: add MMC support [2/2] arm64: dts: renesas: v3msk: add eMMC support WBR, Sergei
Re: [PATCH/RFC 4/4] [WIP] ARM: shmobile: Enable ARM_GLOBAL_TIMER on Cortex-A9 MPCore SoCs
On Tue, Jul 31, 2018 at 6:08 PM Geert Uytterhoeven
wrote:
> SH-Mobile AG5 and R-Car H1 SoCs are based on the Cortex-A9 MPCore, which
> includes a global timer.
>
> Enable the ARM global timer on these SoCs, which will be used for:
> - the scheduler clock, improving scheduler accuracy from 10 ms to 3 or
> 4 ns,
> - delay loops, allowing removal of calls to shmobile_init_delay() from
> the corresponding machine vectors.
>
> Note that when using an old DTB lacking the global timer, the kernel
> will still work. However, loops-per-jiffies will no longer be preset,
> and the delay loop will need to be calibrated during boot.
>
> Signed-off-by: Geert Uytterhoeven
This seems to cause random system resume issues on the venerable SH-Mobile
AG5, ranging from plain lockups to RCU warnings:
WARNING: suspicious RCU usage
4.18.0-kzm9g-00218-gaf4425056bd09e9e #38 Not tainted
-
kernel/sched/fair.c:6231 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
RCU used illegally from offline CPU!
rcu_scheduler_active = 2, debug_locks = 1
3 locks held by swapper/1/0:
#0: 6d7f5781 ((cpu_died).wait.lock){}, at: complete+0x14/0x48
#1: 84ce6f8e (>pi_lock){-.-.}, at: try_to_wake_up+0x30/0x3cc
#2: 93591133 (rcu_read_lock){}, at: select_task_rq_fair+0x5c/0xe8c
stack backtrace:
CPU: 1 PID: 0 Comm: swapper/1 Not tainted
4.18.0-kzm9g-00218-gaf4425056bd09e9e #38
Hardware name: Generic SH73A0 (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x9c/0xd4)
[] (dump_stack) from [] (select_task_rq_fair+0x140/0xe8c)
[] (select_task_rq_fair) from []
(try_to_wake_up+0x210/0x3cc)
[] (try_to_wake_up) from [] (__wake_up_common+0xcc/0x140)
[] (__wake_up_common) from [] (__wake_up_locked+0x14/0x1c)
[] (__wake_up_locked) from [] (complete+0x38/0x48)
[] (complete) from [] (arch_cpu_idle_dead+0x2c/0x8c)
[] (arch_cpu_idle_dead) from [] (do_idle+0x98/0x148)
[] (do_idle) from [] (cpu_startup_entry+0x18/0x1c)
[] (cpu_startup_entry) from [<4010246c>] (0x4010246c)
Given secondary CPU startup is already quite flaky on this SoC, perhaps
it's best to leave it alone?
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] dt-bindings: mmc: tmio_mmc: document Renesas R8A77970 bindings
Document the R-Car V3M (R8A77970) SoC in the R-Car SDHI bindings -- it's the usual R-Car gen3 compatible controller with the internal DMA engine. Signed-off-by: Sergei Shtylyov --- This patch is against the 'next' branch of Ulf Hansson's 'mmc.git' repo. Documentation/devicetree/bindings/mmc/tmio_mmc.txt |1 + 1 file changed, 1 insertion(+) Index: mmc/Documentation/devicetree/bindings/mmc/tmio_mmc.txt === --- mmc.orig/Documentation/devicetree/bindings/mmc/tmio_mmc.txt +++ mmc/Documentation/devicetree/bindings/mmc/tmio_mmc.txt @@ -27,6 +27,7 @@ Required properties: "renesas,sdhi-r8a7795" - SDHI IP on R8A7795 SoC "renesas,sdhi-r8a7796" - SDHI IP on R8A7796 SoC "renesas,sdhi-r8a77965" - SDHI IP on R8A77965 SoC + "renesas,sdhi-r8a77970" - SDHI IP on R8A77970 SoC "renesas,sdhi-r8a77980" - SDHI IP on R8A77980 SoC "renesas,sdhi-r8a77990" - SDHI IP on R8A77990 SoC "renesas,sdhi-r8a77995" - SDHI IP on R8A77995 SoC
[PATCH] arm64: dts: renesas: enable SDR104 on R-Car Gen3
Successfully tested on H3 ES1.0 and ES2.0, M3-W ES1.0, and M3-N ES1.0. Even previously stubborn cards work fine. Transfer rates were >60MB/s. Signed-off-by: Wolfram Sang --- The problems I reported last week were simply me booting the wrong kernel on H3 ES1.0 :( arch/arm64/boot/dts/renesas/salvator-common.dtsi | 2 ++ arch/arm64/boot/dts/renesas/ulcb.dtsi| 1 + 2 files changed, 3 insertions(+) diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi b/arch/arm64/boot/dts/renesas/salvator-common.dtsi index 9256fbaaab7f..b144474ee876 100644 --- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi +++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi @@ -736,6 +736,7 @@ wp-gpios = < 13 GPIO_ACTIVE_HIGH>; bus-width = <4>; sd-uhs-sdr50; + sd-uhs-sdr104; status = "okay"; }; @@ -765,6 +766,7 @@ wp-gpios = < 16 GPIO_ACTIVE_HIGH>; bus-width = <4>; sd-uhs-sdr50; + sd-uhs-sdr104; status = "okay"; }; diff --git a/arch/arm64/boot/dts/renesas/ulcb.dtsi b/arch/arm64/boot/dts/renesas/ulcb.dtsi index 0edb16e6b372..c65a1d8141e4 100644 --- a/arch/arm64/boot/dts/renesas/ulcb.dtsi +++ b/arch/arm64/boot/dts/renesas/ulcb.dtsi @@ -419,6 +419,7 @@ cd-gpios = < 12 GPIO_ACTIVE_LOW>; bus-width = <4>; sd-uhs-sdr50; + sd-uhs-sdr104; status = "okay"; }; -- 2.11.0
[PATCH] clk: renesas: r8a77970: add SD0H/SD0 clocks for SDHI
On R-Car V3M (AKA R8A77970), the SD0CKCR is laid out differently than on
the other R-Car gen3 SoCs. In fact, the layout is the same as on R-Car gen2
SoCs, so we'll need to copy the divisor tables from the R-Car gen2 driver.
We'll also need to support the SoC specific clock types, thus we're adding
CLK_TYPE_GEN3_SOC_BASE at the end of 'enum rcar_gen3_clk_types', declare
SD0H/SDH clocks in 'enum r8a77970_clk_types', and handle those clocks in
the overridden cpg_clk_register() method; then, finally, add the SD-IF
module clock (derived from the SD0 clock).
Signed-off-by: Sergei Shtylyov
---
This patch is against the 'clk-renesas' branch of Geert's 'renesas-drivers.git'
repo.
drivers/clk/renesas/r8a77970-cpg-mssr.c | 64 +++-
drivers/clk/renesas/rcar-gen3-cpg.h |3 +
2 files changed, 65 insertions(+), 2 deletions(-)
Index: renesas-drivers/drivers/clk/renesas/r8a77970-cpg-mssr.c
===
--- renesas-drivers.orig/drivers/clk/renesas/r8a77970-cpg-mssr.c
+++ renesas-drivers/drivers/clk/renesas/r8a77970-cpg-mssr.c
@@ -1,7 +1,7 @@
/*
* r8a77970 Clock Pulse Generator / Module Standby and Software Reset
*
- * Copyright (C) 2017 Cogent Embedded Inc.
+ * Copyright (C) 2017-2018 Cogent Embedded Inc.
*
* Based on r8a7795-cpg-mssr.c
*
@@ -12,6 +12,7 @@
* the Free Software Foundation; version 2 of the License.
*/
+#include
#include
#include
#include
@@ -22,6 +23,11 @@
#include "renesas-cpg-mssr.h"
#include "rcar-gen3-cpg.h"
+enum r8a77970_clk_types {
+ CLK_TYPE_R8A77970_SD0H = CLK_TYPE_GEN3_SOC_BASE,
+ CLK_TYPE_R8A77970_SD0,
+};
+
enum clk_ids {
/* Core Clock Outputs exported to DT */
LAST_DT_CORE_CLK = R8A77970_CLK_OSC,
@@ -42,6 +48,20 @@ enum clk_ids {
MOD_CLK_BASE
};
+static spinlock_t cpg_lock;
+
+static const struct clk_div_table cpg_sd0h_div_table[] = {
+ { 0, 2 }, { 1, 3 }, { 2, 4 }, { 3, 6 },
+ { 4, 8 }, { 5, 12 }, { 6, 16 }, { 7, 18 },
+ { 8, 24 }, { 10, 36 }, { 11, 48 }, { 0, 0 },
+};
+
+static const struct clk_div_table cpg_sd0_div_table[] = {
+ { 4, 8 }, { 5, 12 }, { 6, 16 }, { 7, 18 },
+ { 8, 24 }, { 10, 36 }, { 11, 48 }, { 12, 10 },
+ { 0, 0 },
+};
+
static const struct cpg_core_clk r8a77970_core_clks[] __initconst = {
/* External Clock Inputs */
DEF_INPUT("extal", CLK_EXTAL),
@@ -68,6 +88,10 @@ static const struct cpg_core_clk r8a7797
DEF_FIXED("s2d2", R8A77970_CLK_S2D2, CLK_PLL1_DIV2, 12, 1),
DEF_FIXED("s2d4", R8A77970_CLK_S2D4, CLK_PLL1_DIV2, 24, 1),
+ DEF_BASE("sd0h", R8A77970_CLK_SD0H, CLK_TYPE_R8A77970_SD0H,
+CLK_PLL1_DIV2),
+ DEF_BASE("sd0", R8A77970_CLK_SD0, CLK_TYPE_R8A77970_SD0, CLK_PLL1_DIV2),
+
DEF_FIXED("cl", R8A77970_CLK_CL,CLK_PLL1_DIV2, 48, 1),
DEF_FIXED("cp", R8A77970_CLK_CP,CLK_EXTAL, 2, 1),
@@ -92,6 +116,7 @@ static const struct mssr_mod_clk r8a7797
DEF_MOD("mfis", 213, R8A77970_CLK_S2D2),
DEF_MOD("sys-dmac2", 217, R8A77970_CLK_S2D1),
DEF_MOD("sys-dmac1", 218, R8A77970_CLK_S2D1),
+ DEF_MOD("sd-if", 314, R8A77970_CLK_SD0),
DEF_MOD("rwdt", 402, R8A77970_CLK_R),
DEF_MOD("intc-ex", 407, R8A77970_CLK_CP),
DEF_MOD("intc-ap", 408, R8A77970_CLK_S2D1),
@@ -173,11 +198,46 @@ static int __init r8a77970_cpg_mssr_init
if (error)
return error;
+ spin_lock_init(_lock);
+
cpg_pll_config = _pll_configs[CPG_PLL_CONFIG_INDEX(cpg_mode)];
return rcar_gen3_cpg_init(cpg_pll_config, CLK_EXTALR, cpg_mode);
}
+struct clk * __init r8a77970_cpg_clk_register(struct device *dev,
+ const struct cpg_core_clk *core, const struct cpg_mssr_info *info,
+ struct clk **clks, void __iomem *base,
+ struct raw_notifier_head *notifiers)
+{
+ const struct clk_div_table *table;
+ const struct clk *parent;
+ unsigned int shift;
+
+ switch (core->type) {
+ case CLK_TYPE_R8A77970_SD0H:
+ table = cpg_sd0h_div_table;
+ shift = 8;
+ break;
+ case CLK_TYPE_R8A77970_SD0:
+ table = cpg_sd0_div_table;
+ shift = 4;
+ break;
+ default:
+ return rcar_gen3_cpg_clk_register(dev, core, info, clks, base,
+ notifiers);
+ }
+
+ parent = clks[core->parent];
+ if (IS_ERR(parent))
+ return ERR_CAST(parent);
+
+ return clk_register_divider_table(NULL, core->name,
+ __clk_get_name(parent), 0,
+ base + 0x74, shift, 4, 0, table,
+
Re: bcm2837: tons of DMA mask not set in 4.18.0-rc6-next-20180727
Hi Geert,
On 21/08/18 16:45, Geert Uytterhoeven wrote:
Hi Robin,
CC Lee (mfd), Wolfram (i2c), Marek (bd9571wmv + recent da9063 hacking)
On Fri, Jul 27, 2018 at 6:28 PM Robin Murphy wrote:
On 27/07/18 17:17, Stefan Wahren wrote:
i was noticed that recent linux-next on Raspberry Pi 3 (32 bit) doesn't boot
anymore. So i tested todays linux-next with multi_v7_defconfig and i'm getting
a lot of DMA mask not set warnings. At least USB dwc2 is broken.
Any suggestions before i start to bisect?
https://patchwork.kernel.org/patch/10547231/
Although the upside of this hiccup is that it should give us a fair view
of how many active drivers are still relying on implicit default DMA
masks - I'm now waiting for kernelci's boot chart to catch up with
today's -next to see the full fallout...
I'm still seeing the following on r8a7791/koelsch with a DA9063 PMIC, which
is an MFD device:
da9063-watchdog da9063-watchdog: DMA mask not set
da9063-rtc da9063-rtc: DMA mask not set
The dma masks (both normal and coherent) are NULL, and inherited from the
i2c parent device (6-0058):
pmic@58 {
compatible = "dlg,da9063";
reg = <0x58>;
interrupt-parent = <>;
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
rtc {
compatible = "dlg,da9063-rtc";
};
wdt {
compatible = "dlg,da9063-watchdog";
};
};
The DA9063 MFD driver creates more subdevices than the two listed above,
but the warning doesn't trigger for them, presumably because they don't
have corresponding nodes in DT.
On r8a779{5,6,65}*/salvator-x, there's also an MFD device (BD9571WMC PMIC)
on an i2c bus, inheriting NULL DMA masks from its parent, but it doesn't
have any subnodes in DT, and the warning isn't triggered neither.
I think the question here is why I2C slave devices are getting the
chance to be configured as DMA masters at all :/
Are they getting added to the wrong bus somehow?
Robin.
Anyone with a clue?
Thanks!
Gr{oetje,eeting}s,
Geert
Re: bcm2837: tons of DMA mask not set in 4.18.0-rc6-next-20180727
On Tue, Aug 21, 2018 at 05:45:43PM +0200, Geert Uytterhoeven wrote: > Hi Robin, > > CC Lee (mfd), Wolfram (i2c), Marek (bd9571wmv + recent da9063 hacking) > > On Fri, Jul 27, 2018 at 6:28 PM Robin Murphy wrote: > > On 27/07/18 17:17, Stefan Wahren wrote: > > > i was noticed that recent linux-next on Raspberry Pi 3 (32 bit) doesn't > > > boot anymore. So i tested todays linux-next with multi_v7_defconfig and > > > i'm getting a lot of DMA mask not set warnings. At least USB dwc2 is > > > broken. > > > > > > Any suggestions before i start to bisect? > > > > https://patchwork.kernel.org/patch/10547231/ > > > > Although the upside of this hiccup is that it should give us a fair view > > of how many active drivers are still relying on implicit default DMA > > masks - I'm now waiting for kernelci's boot chart to catch up with > > today's -next to see the full fallout... > > I'm still seeing the following on r8a7791/koelsch with a DA9063 PMIC, which > is an MFD device: > > da9063-watchdog da9063-watchdog: DMA mask not set > da9063-rtc da9063-rtc: DMA mask not set > > The dma masks (both normal and coherent) are NULL, and inherited from the > i2c parent device (6-0058): I think the larger question is: why is the kernel complaining about an unset DMA mask for a device that does not have any capability to perform DMA? Surely the warning is wrong. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up According to speedtest.net: 13Mbps down 490kbps up
renesas-drivers-2018-08-21-v4.18
I have pushed renesas-drivers-2018-08-21-v4.18 to
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git
This tree is meant to ease development of platform support and drivers
for Renesas ARM SoCs. It is created by merging (a) the for-next branches
of various subsystem trees and (b) branches with driver code submitted
or planned for submission to maintainers into the development branch of
Simon Horman's renesas.git tree.
Today's version is based on renesas-devel-20180810-v4.18-rc7.
Included branches with driver code:
- clk-renesas
- sh-pfc
- git://linuxtv.org/pinchartl/media.git#drm-du-iommu-v1-20171115
- git://git.ragnatech.se/linux#for-renesas-drivers
-
git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git#tags/vsp1/du/interlaced/v6
-
git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git#gmsl/for-renesas-drivers
Included fixes:
- spi: Fix double IDR allocation with DT aliases
- Revert "serial: sh-sci: Remove SCIx_RZ_SCIFA_REGTYPE"
- Revert "serial: sh-sci: Allow for compressed SCIF address"
- [LOCAL] arm64: defconfig: Refresh renesas_defconfig
- [LOCAL] arm64: defconfig: Update renesas_defconfig
Included subsystem trees:
- git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git#linux-next
- git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git#clk-next
-
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git#for-next
- git://git.infradead.org/users/dedekind/l2-mtd-2.6.git#master
- git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git#master
- git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git#tty-next
- git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git#i2c/for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git#master
- git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git#usb-next
- git://git.freedesktop.org/git/drm/drm.git#drm-next
- git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git#next
- git://linuxtv.org/media_tree.git#master
- git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git#next
-
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git#for-next
- git://git.linaro.org/people/daniel.lezcano/linux.git#clockevents/next
- git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git#testing/next
- git://git.infradead.org/users/vkoul/slave-dma.git#next
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git#staging-next
- git://git.armlinux.org.uk/~rmk/linux-arm.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git#next
- git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git#for-next
- git://git.infradead.org/users/jcooper/linux.git#irqchip/for-next
- git://github.com/bzolnier/linux.git#fbdev-for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git#for-next
-
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git#for-next
- git://www.linux-watchdog.org/linux-watchdog-next.git#master
- git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git#for-next/core
- git://anongit.freedesktop.org/drm/drm-misc#for-linux-next
- git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git#next
- git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git#next
-
git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git#next
- git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git#for-mfd-next
- git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git#for-next
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: bcm2837: tons of DMA mask not set in 4.18.0-rc6-next-20180727
Hi Robin,
CC Lee (mfd), Wolfram (i2c), Marek (bd9571wmv + recent da9063 hacking)
On Fri, Jul 27, 2018 at 6:28 PM Robin Murphy wrote:
> On 27/07/18 17:17, Stefan Wahren wrote:
> > i was noticed that recent linux-next on Raspberry Pi 3 (32 bit) doesn't
> > boot anymore. So i tested todays linux-next with multi_v7_defconfig and i'm
> > getting a lot of DMA mask not set warnings. At least USB dwc2 is broken.
> >
> > Any suggestions before i start to bisect?
>
> https://patchwork.kernel.org/patch/10547231/
>
> Although the upside of this hiccup is that it should give us a fair view
> of how many active drivers are still relying on implicit default DMA
> masks - I'm now waiting for kernelci's boot chart to catch up with
> today's -next to see the full fallout...
I'm still seeing the following on r8a7791/koelsch with a DA9063 PMIC, which
is an MFD device:
da9063-watchdog da9063-watchdog: DMA mask not set
da9063-rtc da9063-rtc: DMA mask not set
The dma masks (both normal and coherent) are NULL, and inherited from the
i2c parent device (6-0058):
pmic@58 {
compatible = "dlg,da9063";
reg = <0x58>;
interrupt-parent = <>;
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
rtc {
compatible = "dlg,da9063-rtc";
};
wdt {
compatible = "dlg,da9063-watchdog";
};
};
The DA9063 MFD driver creates more subdevices than the two listed above,
but the warning doesn't trigger for them, presumably because they don't
have corresponding nodes in DT.
On r8a779{5,6,65}*/salvator-x, there's also an MFD device (BD9571WMC PMIC)
on an i2c bus, inheriting NULL DMA masks from its parent, but it doesn't
have any subnodes in DT, and the warning isn't triggered neither.
Anyone with a clue?
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
Re: [PATCH V2 4/5] PCI: rcar: Support runtime PM, link state L1 handling
On Tue, Aug 21, 2018 at 08:58:38AM +, Phil Edworthy wrote: > Hi Lorenzo, > > On 20 August 2018 15:48 Lorenzo Pieralisi wrote: > > On Mon, Aug 20, 2018 at 01:44:48PM +, Phil Edworthy wrote: > > > > [...] > > > > > However, both before and after this patch, the RP does not transition > > > L1 when the endpoints change to L1. > > > This patch only transitions the RP to L1 during accessing a card's > > > config registers, if the RP is not in L1 link state and has received > > > PM_ENTER_L1 DLLP (e.g. resume). After this, the hardware will handle > > > the transition out of L1. > > > > > > The relevant part of the rcar manual says: "After a recovery to L0, if > > > the device is in the Non-D0 state and PM_Enter_L1 DLLP is transmitted > > > from the downstream device, software should confirm that hardware is > > > in the L0 state (PMSR.PMSTATE = L0) and initiate the L1 transition > > > sequence again (write 1 to PMCTLR.L1IATN). In this case, the sequence > > > is: L0 ??? L1 ??? L0 recovery ??? L1 again." > > > > Can you map these FSM steps to this patch code please ? I would like to > > understand what Link state maps to which command written and when. > I don't think I can because we are not initially entering L1. Looking at this > again, I think this section of the manual only helps in indicating how to > detect we should have gone into L1 and how to poke the HW to initiate the > transition to L1. > > On system suspend, the EP sends PM_Enter_L1 DLLP and enters L1 state. I am still struggling to understand what "EP enters L1 state" means. A link in L1 means both ends of the link are in electrical idle, it is a two-way handshake, see PCI express specifications 5.3.2.1 "Entry into the L1 state". > The rcar RP cannot enter L1 by HW alone, so is still in L0. See above. > The only way out of this from the PCIe spec FSM is for both EP and RP > to enter the Recovery state. > The patch simply detects that we should have gone into L1, and so initiates > that state change, and the HW will then handle the transition from L1 to > Recovery and then on to L0. That I can understand, I reckon it is to "reset" the RP link state machine to a "sane" state. > > > I don't think the potential issue that Bjorn talked about can happen > > > because the RP does go into L1. I could be wrong though... > > > > I do not understand this paragraph, mind elaborating on it ? > As rcar RP only supports D0 and D3hot/cold, (the manual says it supports > D3cold, but I cannot see how if it doesn't support L2 or L3 states), if you > force the link to D3, we can only be in L1 state. D3 is a device state, not a link state. I still do not understand this statement. The link between RP and EP can enter L1 when all functions in the EP are in a device state != D0 but, as I mentioned above, it is still unclear what happens in this platform since I do not get what state in the PCI spec 5.3.2.1 state machine the RP Link state machine is in. If we programme the device into any D-state and the device wants to send a PME message _before_ we reset the RP state machine with the procedure described in this thread, what happens ? Or, more explicitly, what are in _HW_ the states of upstream and downstream link state machines when the EP is put in, say, D1 ? That's in short our question. I would be happy to get to the bottom of this since it is an interesting issue we are facing, we need HW details, I can apply Marek's patch but I would be happier if I get the whole picture first. Thanks, Lorenzo > > > > > The driver should also have a runtime-PM hook to transition to L1 on > > > suspend in order to save power. However, that is somewhat separate to > > > the problem the patch fixes. > > > > Yes that's a separate patch. > > > > Thanks for chiming in, let's try to get to the bottom of this thread. > > > > Lorenzo > > Thanks > Phil
Re: [PATCH 1/2] mmc: renesas_sdhi_internal_dmac: fix typo in DM_CM_DTRAN_MODE.BUS_WIDTH field name
On Fri, Aug 17, 2018 at 11:19:02PM +0300, Sergei Shtylyov wrote: > Fix a stray underscore in the DM_CM_DTRAN_MODE.BUS_WIDTH register field > name. > > Signed-off-by: Sergei Shtylyov Reviewed-by: Simon Horman
Re: [PATCH 2/2] mmc: renesas_sdhi_internal_dmac: fix comment typo
On Fri, Aug 17, 2018 at 11:20:23PM +0300, Sergei Shtylyov wrote: > Fix the typo in the comment to #define DTRAN_MODE_CH_NUM_CH1. > > Signed-off-by: Sergei Shtylyov Reviewed-by: Simon Horman
Re: [PATCH v2 3/7] pinctrl: sh-pfc: r8a77965: Add HSCIF0 pins, groups, and functions
On Sun, Aug 12, 2018 at 03:31:45PM +0200, Eugeniu Rosca wrote:
> According to R-Car Gen3 HW manual Rev.1.00 Apr 2018, M3-N SoC implements
> five (0..4) HSCIF channels, similar to H3, M3-W and E3.
>
> The story behind this patch is tackling below dmesg warnings, which pop
> up when booting M3NULCB Kingfisher board:
>
> $ dmesg | grep sh-pfc
> sh-pfc e606.pin-controller: r8a77965_pfc support registered
> sh-pfc e606.pin-controller: function 'hscif0' not supported
> sh-pfc e606.pin-controller: invalid function hscif0 in map table
> sh-pfc e606.pin-controller: function 'hscif0' not supported
> sh-pfc e606.pin-controller: invalid function hscif0 in map table
>
> To fix them, extract the HSCIF0 part from below v4.15-rc1 commits:
> - commit 7a362e3488cb ("pinctrl: sh-pfc: r8a7795: Add HSCIF pins, groups,
> and functions")
> - commit 0e4e4999aac1 ("pinctrl: sh-pfc: r8a7796: Add HSCIF pins, groups,
> and functions")
>
> Note that `checkpatch --strict` throws several "CHECK: Please use a
> blank line after function/struct/union/enum declarations", which are
> ignored for the sake of staying in sync with the aforementioned commits.
>
> Signed-off-by: Eugeniu Rosca
Reviewed-by: Simon Horman
Re: [PATCH 1/2] thermal: rcar_gen3_thermal: Add r8a774a1 support
On Fri, Aug 17, 2018 at 03:53:03PM +0100, Fabrizio Castro wrote: > Add r8a774a1 specific compatible string. > > Signed-off-by: Fabrizio Castro > Reviewed-by: Biju Das Reviewed-by: Simon Horman
Re: [PATCH] spi: sh-msiof: Add r8a774a1 support
On Fri, Aug 17, 2018 at 03:58:34PM +0100, Fabrizio Castro wrote: > Document RZ/G2M (R8A774A1) SoC bindings. > > Signed-off-by: Fabrizio Castro > Reviewed-by: Biju Das Reviewed-by: Simon Horman
Re: [PATCH v2] arm64: dts: renesas: salvator-xs: enable SATA
> > +/* MD12 (SW12-7) must be set 'Off' which is not the default! */ > > Upon reading this again, I think this comment is confusing: the 'Off' refers > to the switch position, not to the MD12 logic value, while the parentheses > suggest otherwise. > > What about the following? > > SW12-7 must be set 'Off' (MD12 set to 1), which is not the default! I'd leave the ',' away but otherwise: Acked-by: Wolfram Sang Shall I send an incremental patch or do you want to do it? signature.asc Description: PGP signature
Re: [PATCH v2] arm64: dts: renesas: salvator-xs: enable SATA
Hi Wolfram, Simon,
On Mon, Jul 30, 2018 at 9:34 AM Wolfram Sang
wrote:
> Add the nodes to enable SATA. Note that MD12 (SW12-7) must be switched
> off for that to work.
>
> Signed-off-by: Wolfram Sang
> Reviewed-by: Geert Uytterhoeven
> ---
>
> Changes since v1:
> * fixed indentation (Thanks, Geert!)
> * merged two patches into one (Thanks, Simon!)
> * Added Geert's tag
> --- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
> @@ -176,6 +185,11 @@
> };
> };
>
> +/* MD12 (SW12-7) must be set 'Off' which is not the default! */
Upon reading this again, I think this comment is confusing: the 'Off' refers
to the switch position, not to the MD12 logic value, while the parentheses
suggest otherwise.
What about the following?
SW12-7 must be set 'Off' (MD12 set to 1), which is not the default!
> --- a/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts
> +/* MD12 (SW12-7) must be set 'Off' which is not the default! */
Likewise.
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 V2 4/5] PCI: rcar: Support runtime PM, link state L1 handling
Hi Lorenzo, On 20 August 2018 15:48 Lorenzo Pieralisi wrote: > On Mon, Aug 20, 2018 at 01:44:48PM +, Phil Edworthy wrote: > > [...] > > > However, both before and after this patch, the RP does not transition > > L1 when the endpoints change to L1. > > This patch only transitions the RP to L1 during accessing a card's > > config registers, if the RP is not in L1 link state and has received > > PM_ENTER_L1 DLLP (e.g. resume). After this, the hardware will handle > > the transition out of L1. > > > > The relevant part of the rcar manual says: "After a recovery to L0, if > > the device is in the Non-D0 state and PM_Enter_L1 DLLP is transmitted > > from the downstream device, software should confirm that hardware is > > in the L0 state (PMSR.PMSTATE = L0) and initiate the L1 transition > > sequence again (write 1 to PMCTLR.L1IATN). In this case, the sequence > > is: L0 → L1 → L0 recovery → L1 again." > > Can you map these FSM steps to this patch code please ? I would like to > understand what Link state maps to which command written and when. I don’t think I can because we are not initially entering L1. Looking at this again, I think this section of the manual only helps in indicating how to detect we should have gone into L1 and how to poke the HW to initiate the transition to L1. On system suspend, the EP sends PM_Enter_L1 DLLP and enters L1 state. The rcar RP cannot enter L1 by HW alone, so is still in L0. The only way out of this from the PCIe spec FSM is for both EP and RP to enter the Recovery state. The patch simply detects that we should have gone into L1, and so initiates that state change, and the HW will then handle the transition from L1 to Recovery and then on to L0. > > I don’t think the potential issue that Bjorn talked about can happen > > because the RP does go into L1. I could be wrong though... > > I do not understand this paragraph, mind elaborating on it ? As rcar RP only supports D0 and D3hot/cold, (the manual says it supports D3cold, but I cannot see how if it doesn’t support L2 or L3 states), if you force the link to D3, we can only be in L1 state. > > The driver should also have a runtime-PM hook to transition to L1 on > > suspend in order to save power. However, that is somewhat separate to > > the problem the patch fixes. > > Yes that's a separate patch. > > Thanks for chiming in, let's try to get to the bottom of this thread. > > Lorenzo Thanks Phil
Re: [RFC/RTF] drm: rcar-du: lvds: Handle LVDS interface reset
Hello Jacopo,
Thank you for the patch.
On Wednesday, 1 August 2018 17:26:36 EEST Jacopo Mondi wrote:
> The processor manual prescribes to clear reset of LVDS interface in CPG/MSSR
> module before display on, and to assert the same reset line at display off
> time, to have the module resuming in a known state.
>
> The module is said to be in "standby state" at initialization time, and this
> requires, according to section 37.3.7 of the manual, to de-assert the reset
> to have it functional.
>
> Based on the original patch from
> Koji Matsuoka
>
> Signed-off-by: Jacopo Mondi
>
> ---
> This patch upports commit:
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit
> / ?id=23b62b82a5a705d28ddac1d973ee98e6f51d54ea
>
> Even without this patch the LVDS interface has been succesfully tested on
> V3M/Eagle boards, and this makes me wonder on the real need for reset to
> be handled by the driver.
>
> I've been able to 'test' the reset assertion/deassertion on Draak, whose
> LVDS interface is not yet being enabled due to missing LVDS PLL support. If
> someone with a V3M/Eagle could test this to make sure this doesn't break
> anything, we can then discuss on the real need for this patch to be
> mainlined.
>
> Also, a series of patches to add reset to R8A7795/R8A7796/R8A77965 LVDS
> device nodes will be upported if this patch is considered useful.
I think we can upstream DT changes regardless of whether we merge this patch,
as the reset lines exist, so it makes sense to have them in DT.
> For the interested ones (Laurent, Geert) reset de-assertion at display on
> time takes in average a hundreds of micro seconds.
Not very long, but still, if not need, I'd rather avoid it.
My understanding is that resetting the LVDS encoder is recommended "just in
case" something goes wrong, but isn't needed in the general case. The question
is thus in my opinion whether something can go wrong if we otherwise handle
the LVDS controller according to the recommended procedure.
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> b/drivers/gpu/drm/rcar-du/rcar_lvds.c index 20e8c34..acf4238 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -53,6 +54,7 @@ struct rcar_lvds {
>
> void __iomem *mmio;
> struct clk *clock;
> + struct reset_control *rst;
> bool enabled;
>
> struct drm_display_mode display_mode;
> @@ -175,6 +177,12 @@ static void rcar_lvds_enable(struct drm_bridge *bridge)
> if (ret < 0)
> return;
>
> + ret = reset_control_deassert(lvds->rst);
> + if (ret < 0) {
> + clk_disable_unprepare(lvds->clock);
> + return;
> + }
> +
> /*
>* Hardcode the channels and control signals routing for now.
>*
> @@ -265,6 +273,7 @@ static void rcar_lvds_disable(struct drm_bridge *bridge)
> rcar_lvds_write(lvds, LVDCR0, 0);
> rcar_lvds_write(lvds, LVDCR1, 0);
>
> + reset_control_assert(lvds->rst);
> clk_disable_unprepare(lvds->clock);
>
> lvds->enabled = false;
> @@ -481,6 +490,12 @@ static int rcar_lvds_probe(struct platform_device
> *pdev) return PTR_ERR(lvds->clock);
> }
>
> + lvds->rst = devm_reset_control_get_optional_exclusive(>dev, NULL);
> + if (IS_ERR(lvds->rst)) {
> + dev_err(>dev, "failed to get reset\n");
> + return PTR_ERR(lvds->rst);
> + }
> +
> drm_bridge_add(>bridge);
>
> return 0;
--
Regards,
Laurent Pinchart
Re: [PATCH 13/13] sh: lib: convert to SPDX identifiers
Hi Sato-san > > > Given the above clause I wonder if the SPDX identifier should be: > > > > > > SPDX-License-Identifier: GPL-2.0+ WITH GCC-exception-2.0 > > > > Ahh, indeed. > > I will post v2 patch. > > Sato-san, can I post [13/13 v2] only ? or should post all patches ? > > > > Please sent all patches. > Thanks. OK, will do Best regards --- Kuninori Morimoto
