Re: [PATCH v2] clk: renesas: cpg-mssr: Add R7S9210 support
On Mon, Aug 27, 2018 at 11:21:39AM -0500, Chris Brandt wrote: > Add support for the R7S9210 (RZ/A2) Clock Pulse Generator and Module > Standby. > > The Module Standby HW in the RZ/A series is very close to R-Car HW, except > for how the registers are laid out. > The MSTP registers are only 8-bits wide, there is no status registers > (MSTPST), and the register offsets are a little different. Since the RZ/A > hardware manuals refer to these registers as the Standby Control Registers, > we'll use that name to distinguish the RZ/A type for the R-Car type. > > Signed-off-by: Chris Brandt > --- > +++ b/drivers/clk/renesas/r7s9210-cpg-mssr.c > @@ -0,0 +1,192 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > +++ b/include/dt-bindings/clock/r7s9210-cpg-mssr.h > @@ -0,0 +1,21 @@ > +/* SPDX-License-Identifier: GPL-2.0+ The proper identifier is GPL-2.0-or-later
Re: [RFC PATCH v2 1/4] watchdog: core: add mechanism to prevent removing if NOWAYOUT
On Tue, Aug 28, 2018 at 10:07:40PM +0200, Wolfram Sang wrote: > Hi Guenter, > > > > + __driver.remove = NULL; \ > > > > Does that really do any good ? If I understand correctly, the only > > impact is that the platform driver remove function will believe that > > nothing needs to be done on removal. See platform_drv_remove(). > > This might be biased for my use case. Not calling remove will also leave > the clock for that module enabled. But true, the platform device will be > removed and without proper cleanup, there could be dangling pointers. > For many drivers the watchdog device would not be removed. That would indeed be fatal. > In general, what do you think of this approach if we'd left out the > above line? > LGTM without that line. Thanks, Guenter
Re: [PATCH] ASoC: rsnd: Add device tree binding for r8a77990
On Fri, Aug 17, 2018 at 04:53:55PM +0900, Yoshihiro Kaneko wrote: > From: Hiroyuki Yokoyama > > This patch adds the device tree binding of the r8a77990 SoC. This doesn't apply against current code, please check and resend. signature.asc Description: PGP signature
Re: [RFC PATCH v2 1/4] watchdog: core: add mechanism to prevent removing if NOWAYOUT
Hi Guenter, > > + __driver.remove = NULL; \ > > Does that really do any good ? If I understand correctly, the only > impact is that the platform driver remove function will believe that > nothing needs to be done on removal. See platform_drv_remove(). This might be biased for my use case. Not calling remove will also leave the clock for that module enabled. But true, the platform device will be removed and without proper cleanup, there could be dangling pointers. In general, what do you think of this approach if we'd left out the above line? Thanks, Wolfram signature.asc Description: PGP signature
Re: [RFC PATCH v2 1/4] watchdog: core: add mechanism to prevent removing if NOWAYOUT
On Tue, Aug 28, 2018 at 09:14:13PM +0200, Wolfram Sang wrote:
> To prevent removing if NOWAYOUT, we invalidate the .remove function and
> suppress the bind/unbind attributes in sysfs. These are driver
> capabilities, so we need to set it up at runtime during init. To avoid
> boilerplate, introduce module_watchdog_driver() similar to
> module_driver(). On top of that, we then build
> module_watchdog_platform_driver(). Others may follow, if needed.
>
> Signed-off-by: Wolfram Sang
> ---
> include/linux/watchdog.h | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/include/linux/watchdog.h b/include/linux/watchdog.h
> index 44985c4a1e86..5768fb6b5cde 100644
> --- a/include/linux/watchdog.h
> +++ b/include/linux/watchdog.h
> @@ -216,4 +216,24 @@ extern void watchdog_unregister_device(struct
> watchdog_device *);
> /* devres register variant */
> int devm_watchdog_register_device(struct device *dev, struct watchdog_device
> *);
>
> +#define module_watchdog_driver(__driver, __register, __unregister,
> __nowayout, ...) \
> +static int __init __driver##_init(void) \
> +{ \
> + if (__nowayout) { \
> + __driver.driver.suppress_bind_attrs = true; \
> + __driver.remove = NULL; \
Does that really do any good ? If I understand correctly, the only
impact is that the platform driver remove function will believe that
nothing needs to be done on removal. See platform_drv_remove().
> + } \
> + return __register(&(__driver) ##__VA_ARGS__); \
> +} \
> +module_init(__driver##_init); \
> +static void __exit __driver##_exit(void) \
> +{ \
> + __unregister(&(__driver), ##__VA_ARGS__); \
> +} \
> +module_exit(__driver##_exit)
> +
> +#define module_watchdog_platform_driver(__platform_driver, __nowayout) \
> + module_watchdog_driver(__platform_driver, platform_driver_register, \
> + platform_driver_unregister, __nowayout)
> +
> #endif /* ifndef _LINUX_WATCHDOG_H */
> --
> 2.11.0
>
[RFC PATCH v2 3/4] watchdog: core: add module_watchdog_pci_driver()
Allow PCI drivers to prevent removing if NOWAYOUT, too. Note: This is only a build-tested proof-of-concept! Signed-off-by: Wolfram Sang --- include/linux/watchdog.h | 4 1 file changed, 4 insertions(+) diff --git a/include/linux/watchdog.h b/include/linux/watchdog.h index 5768fb6b5cde..07c01e8050e8 100644 --- a/include/linux/watchdog.h +++ b/include/linux/watchdog.h @@ -236,4 +236,8 @@ module_exit(__driver##_exit) module_watchdog_driver(__platform_driver, platform_driver_register, \ platform_driver_unregister, __nowayout) +#define module_watchdog_pci_driver(__pci_driver, __nowayout) \ + module_watchdog_driver(__pci_driver, pci_register_driver, \ + pci_unregister_driver, __nowayout) + #endif /* ifndef _LINUX_WATCHDOG_H */ -- 2.11.0
[RFC PATCH v2 2/4] watchdog: renesas_wdt: avoid removing if NOWAYOUT
Use the new macro to prevent removing the driver if NOWAYOUT.
Signed-off-by: Wolfram Sang
---
drivers/watchdog/renesas_wdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c
index f45cb183fa75..92339c744cce 100644
--- a/drivers/watchdog/renesas_wdt.c
+++ b/drivers/watchdog/renesas_wdt.c
@@ -302,7 +302,7 @@ static struct platform_driver rwdt_driver = {
.probe = rwdt_probe,
.remove = rwdt_remove,
};
-module_platform_driver(rwdt_driver);
+module_watchdog_platform_driver(rwdt_driver, nowayout);
MODULE_DESCRIPTION("Renesas WDT Watchdog Driver");
MODULE_LICENSE("GPL v2");
--
2.11.0
[RFC PATCH v2 1/4] watchdog: core: add mechanism to prevent removing if NOWAYOUT
To prevent removing if NOWAYOUT, we invalidate the .remove function and
suppress the bind/unbind attributes in sysfs. These are driver
capabilities, so we need to set it up at runtime during init. To avoid
boilerplate, introduce module_watchdog_driver() similar to
module_driver(). On top of that, we then build
module_watchdog_platform_driver(). Others may follow, if needed.
Signed-off-by: Wolfram Sang
---
include/linux/watchdog.h | 20
1 file changed, 20 insertions(+)
diff --git a/include/linux/watchdog.h b/include/linux/watchdog.h
index 44985c4a1e86..5768fb6b5cde 100644
--- a/include/linux/watchdog.h
+++ b/include/linux/watchdog.h
@@ -216,4 +216,24 @@ extern void watchdog_unregister_device(struct
watchdog_device *);
/* devres register variant */
int devm_watchdog_register_device(struct device *dev, struct watchdog_device
*);
+#define module_watchdog_driver(__driver, __register, __unregister, __nowayout,
...) \
+static int __init __driver##_init(void) \
+{ \
+ if (__nowayout) { \
+ __driver.driver.suppress_bind_attrs = true; \
+ __driver.remove = NULL; \
+ } \
+ return __register(&(__driver) ##__VA_ARGS__); \
+} \
+module_init(__driver##_init); \
+static void __exit __driver##_exit(void) \
+{ \
+ __unregister(&(__driver), ##__VA_ARGS__); \
+} \
+module_exit(__driver##_exit)
+
+#define module_watchdog_platform_driver(__platform_driver, __nowayout) \
+ module_watchdog_driver(__platform_driver, platform_driver_register, \
+ platform_driver_unregister, __nowayout)
+
#endif /* ifndef _LINUX_WATCHDOG_H */
--
2.11.0
[RFC PATCH v2 0/4] watchdog: prevent removing a driver if NOWAYOUT
So, here is my second approach, now avoiding probe() and targetting the init call. To avoid boilerplate, I introduced macros similar to module_driver(). It still feels a little adventurous because of hard-coding '.remove' and '.driver.suppress_bind_attts' in the macro and trusting various driver types (like platform and PCI) to follow this structure. Having all this said, it works nicely on my Renesas Salvator-XS (R-Car M3-N). No reply from buildbot yet, but it is RFC only, so I'll send it out already. A git branch can be found here: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/wdt-suppress-attr Looking forward to comments. Thanks, Wolfram Wolfram Sang (4): watchdog: core: add mechanism to prevent removing if NOWAYOUT watchdog: renesas_wdt: avoid removing if NOWAYOUT watchdog: core: add module_watchdog_pci_driver() watchdog: i6300esb: avoid removing if NOWAYOUT drivers/watchdog/i6300esb.c| 2 +- drivers/watchdog/renesas_wdt.c | 2 +- include/linux/watchdog.h | 24 3 files changed, 26 insertions(+), 2 deletions(-) -- 2.11.0
[RFC PATCH v2 4/4] watchdog: i6300esb: avoid removing if NOWAYOUT
Use the new macro to prevent removing the driver if NOWAYOUT.
Note: This is only a build-tested proof-of-concept!
Signed-off-by: Wolfram Sang
---
drivers/watchdog/i6300esb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/i6300esb.c b/drivers/watchdog/i6300esb.c
index 950c71a8bb22..939224789e2a 100644
--- a/drivers/watchdog/i6300esb.c
+++ b/drivers/watchdog/i6300esb.c
@@ -356,7 +356,7 @@ static struct pci_driver esb_driver = {
.remove = esb_remove,
};
-module_pci_driver(esb_driver);
+module_watchdog_pci_driver(esb_driver, nowayout);
MODULE_AUTHOR("Ross Biro and David Härdeman");
MODULE_DESCRIPTION("Watchdog driver for Intel 6300ESB chipsets");
--
2.11.0
RE: [PATCH] clk: renesas: cpg-mssr: Add R7S9210 support
Hi Geert,
On Tuesday, August 28, 2018, Geert Uytterhoeven wrote:
> Seriously, you do have to prevent registering the reset controller when
> running on RZ/A2 (based on cpg_mssr_info.stbyctrl or some other indicator).
OK. Since the reset controller registration is the last thing done
cpg_mssr_probe, I'll just return.
+ if (info->stbyctrl)
+ return 0;
+
error = cpg_mssr_reset_controller_register(priv);
if (error)
return error;
return 0;
}
> When running on RZ/A2, I'd use a different pack function in
> cpg_mssr_clk_src_twocell_get() instead, so you can just write:
>
> clock = < CPG_MOD 36>;
>
> > r7s9210-cpg-mssr.c:
> >
> > static const struct mssr_mod_clk r7s9210_mod_clks[] __initconst = {
> > DEF_MOD("ostm0",STBCR_ID(36), R7S9210_CLK_P1C),
> > DEF_MOD("ostm1",STBCR_ID(35), R7S9210_CLK_P1C),
> > DEF_MOD("ostm2",STBCR_ID(34), R7S9210_CLK_P1C),
>
> ... and a different DEF_MOD() macro here, so you can just write:
>
> DEF_MOD("ostm0",36, R7S9210_CLK_P1C),
OK. I will do that instead.
Thank you,
Chris
Re: [PATCH] clk: renesas: cpg-mssr: Add R7S9210 support
Hi Chris,
On Tue, Aug 28, 2018 at 7:18 PM Chris Brandt wrote:
> Since my config for RZ/A2 does not set CONFIG_RESET_CONTROLLER, none of
> the reset code is built and cpg_mssr_reset_controller_register() just
> ends up being an empty function.
Let's try shmobile_defconfig instead :-)
Seriously, you do have to prevent registering the reset controller when
running on RZ/A2 (based on cpg_mssr_info.stbyctrl or some other indicator).
> So basically my only change at this point is to make DTS and the module
> clock table use "36" instead of "306".
>
> Are you OK with the idea of adding a macro ("STBCR_ID") in
> include/dt-bindings/clock/renesas-cpg-mssr.h?
>
>
> DTS:
>
> ostm0: timer@e803b000 {
> compatible = "renesas,r7s9210-ostm", "renesas,ostm";
> reg = <0xe803b000 0x30>;
> interrupts = ;
> clocks = < CPG_MOD STBCR_ID(36)>;
> clock-names = "ostm0";
> power-domains = <>;
> status = "disabled";
> };
When running on RZ/A2, I'd use a different pack function in
cpg_mssr_clk_src_twocell_get() instead, so you can just write:
clock = < CPG_MOD 36>;
> r7s9210-cpg-mssr.c:
>
> static const struct mssr_mod_clk r7s9210_mod_clks[] __initconst = {
> DEF_MOD("ostm0",STBCR_ID(36), R7S9210_CLK_P1C),
> DEF_MOD("ostm1",STBCR_ID(35), R7S9210_CLK_P1C),
> DEF_MOD("ostm2",STBCR_ID(34), R7S9210_CLK_P1C),
... and a different DEF_MOD() macro here, so you can just write:
DEF_MOD("ostm0",36, R7S9210_CLK_P1C),
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] clk: renesas: cpg-mssr: Add R7S9210 support
Hi Geert,
Since my config for RZ/A2 does not set CONFIG_RESET_CONTROLLER, none of
the reset code is built and cpg_mssr_reset_controller_register() just
ends up being an empty function.
So basically my only change at this point is to make DTS and the module
clock table use "36" instead of "306".
Are you OK with the idea of adding a macro ("STBCR_ID") in
include/dt-bindings/clock/renesas-cpg-mssr.h?
DTS:
ostm0: timer@e803b000 {
compatible = "renesas,r7s9210-ostm", "renesas,ostm";
reg = <0xe803b000 0x30>;
interrupts = ;
clocks = < CPG_MOD STBCR_ID(36)>;
clock-names = "ostm0";
power-domains = <>;
status = "disabled";
};
r7s9210-cpg-mssr.c:
static const struct mssr_mod_clk r7s9210_mod_clks[] __initconst = {
DEF_MOD("ostm0",STBCR_ID(36), R7S9210_CLK_P1C),
DEF_MOD("ostm1",STBCR_ID(35), R7S9210_CLK_P1C),
DEF_MOD("ostm2",STBCR_ID(34), R7S9210_CLK_P1C),
Thanks,
Chris
Re: [RFC PATCH] watchdog: HACK: disable bind attributes with NOWAYOUT
> void watchdog_set_nowayout(struct watchdog_device *wdd, struct driver > *drv, bool nowayout) > > I'd think this would work from a layering perspective. No, this is also bogus. probe() works per device, and .suppress_bind_attrs works per driver. We need to tackle this in the init callback. signature.asc Description: PGP signature
[PATCH] ARM: dts: r9a06g032: Use r9a06g032-sysctrl binding definitions
Replace the hardcoded clock indices by R9A06G032_CLK_* symbols.
Signed-off-by: Geert Uytterhoeven
---
arch/arm/boot/dts/r9a06g032.dtsi | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/r9a06g032.dtsi b/arch/arm/boot/dts/r9a06g032.dtsi
index afe29c95a006e8fa..3e45375b79aa9c0d 100644
--- a/arch/arm/boot/dts/r9a06g032.dtsi
+++ b/arch/arm/boot/dts/r9a06g032.dtsi
@@ -7,6 +7,7 @@
*/
#include
+#include
/ {
compatible = "renesas,r9a06g032";
@@ -21,14 +22,14 @@
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0>;
- clocks = < 84>;
+ clocks = < R9A06G032_CLK_A7MP>;
};
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <1>;
- clocks = < 84>;
+ clocks = < R9A06G032_CLK_A7MP>;
enable-method = "renesas,r9a06g032-smp";
cpu-release-addr = <0 0x4000c204>;
};
@@ -82,7 +83,7 @@
interrupts = ;
reg-shift = <2>;
reg-io-width = <4>;
- clocks = < 146>;
+ clocks = < R9A06G032_CLK_UART0>;
clock-names = "baudclk";
status = "disabled";
};
--
2.17.1
[PATCH] ARM: shmobile: defconfig: Refresh shmobile_defconfig for v4.19-rc1
Refresh the defconfig for Renesas ARM boards: - Move options that have moved, - Remove CONFIG_HAVE_ARM_ARCH_TIMER (auto-enabled), - Remove ENABLE_WARN_DEPRECATED (removed). Signed-off-by: Geert Uytterhoeven --- arch/arm/configs/shmobile_defconfig | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig index c8f2cb9fc7f3c8d8..7b48ec3e63ec3234 100644 --- a/arch/arm/configs/shmobile_defconfig +++ b/arch/arm/configs/shmobile_defconfig @@ -32,10 +32,8 @@ CONFIG_PCI_RCAR_GEN2=y CONFIG_PCIE_RCAR=y CONFIG_SMP=y CONFIG_SCHED_MC=y -CONFIG_HAVE_ARM_ARCH_TIMER=y CONFIG_NR_CPUS=8 CONFIG_HIGHMEM=y -CONFIG_CMA=y CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_ARM_APPENDED_DTB=y @@ -50,6 +48,7 @@ CONFIG_CPUFREQ_DT=y CONFIG_VFP=y CONFIG_NEON=y # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set +CONFIG_CMA=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y @@ -207,7 +206,6 @@ CONFIG_ROOT_NFS=y CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ISO8859_1=y CONFIG_PRINTK_TIME=y -# CONFIG_ENABLE_WARN_DEPRECATED is not set # CONFIG_ENABLE_MUST_CHECK is not set CONFIG_DEBUG_KERNEL=y # CONFIG_ARM_UNWIND is not set -- 2.17.1
[PATCH] [LOCAL] arm64: renesas_defconfig: Enable CRYPTO_DEV_CCREE
Enable support for the CryptoCell core present in some R-Car Gen3 SoCs, which allows to offload crypto operations. Signed-off-by: Geert Uytterhoeven --- arch/arm64/configs/renesas_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/renesas_defconfig b/arch/arm64/configs/renesas_defconfig index 4d831eb8dedd409a..1a019d2d17577401 100644 --- a/arch/arm64/configs/renesas_defconfig +++ b/arch/arm64/configs/renesas_defconfig @@ -321,6 +321,7 @@ CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ISO8859_1=y CONFIG_CRYPTO_ANSI_CPRNG=y # CONFIG_CRYPTO_DEV_VIRTIO is not set +CONFIG_CRYPTO_DEV_CCREE=y CONFIG_PRINTK_TIME=y CONFIG_MAGIC_SYSRQ=y CONFIG_DEBUG_KERNEL=y -- 2.17.1
[PATCH] [LOCAL] arm64: defconfig: Refresh renesas_defconfig for v4.19-rc1
Refresh the defconfig for Renesas R-Car Gen3 boards: - Move options that have moved, - Remove CONFIG_PCIE_DW_PLAT_HOST (auto-disabled), - Remove CONFIG_DEBUG_FS (auto-enabled). Signed-off-by: Geert Uytterhoeven --- arch/arm64/configs/renesas_defconfig | 40 +--- 1 file changed, 19 insertions(+), 21 deletions(-) diff --git a/arch/arm64/configs/renesas_defconfig b/arch/arm64/configs/renesas_defconfig index e2336fd21e355726..4d831eb8dedd409a 100644 --- a/arch/arm64/configs/renesas_defconfig +++ b/arch/arm64/configs/renesas_defconfig @@ -4,6 +4,7 @@ CONFIG_POSIX_MQUEUE=y CONFIG_AUDIT=y CONFIG_NO_HZ_IDLE=y CONFIG_HIGH_RES_TIMERS=y +CONFIG_PREEMPT=y CONFIG_IRQ_TIME_ACCOUNTING=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y @@ -27,9 +28,6 @@ CONFIG_SCHED_AUTOGROUP=y CONFIG_BLK_DEV_INITRD=y # CONFIG_COMPAT_BRK is not set CONFIG_PROFILING=y -CONFIG_JUMP_LABEL=y -CONFIG_BLK_DEV_INTEGRITY=y -# CONFIG_IOSCHED_DEADLINE is not set CONFIG_ARCH_RENESAS=y CONFIG_ARCH_R8A774A1=y CONFIG_ARCH_R8A7795=y @@ -46,7 +44,6 @@ CONFIG_PCI_IOV=y CONFIG_HOTPLUG_PCI=y CONFIG_PCIE_RCAR=y CONFIG_PCI_HOST_GENERIC=y -# CONFIG_PCIE_DW_PLAT_HOST is not set # CONFIG_CAVIUM_ERRATUM_22375 is not set # CONFIG_CAVIUM_ERRATUM_23154 is not set # CONFIG_CAVIUM_ERRATUM_27456 is not set @@ -58,17 +55,12 @@ CONFIG_PCI_HOST_GENERIC=y # CONFIG_HISILICON_ERRATUM_161600802 is not set CONFIG_ARM64_VA_BITS_48=y CONFIG_SCHED_MC=y -CONFIG_PREEMPT=y -CONFIG_KSM=y -CONFIG_TRANSPARENT_HUGEPAGE=y -CONFIG_CMA=y CONFIG_SECCOMP=y CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y CONFIG_XEN=y # CONFIG_ARM64_LSE_ATOMICS is not set # CONFIG_ARM64_RAS_EXTN is not set -# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set CONFIG_COMPAT=y CONFIG_HIBERNATION=y CONFIG_WQ_POWER_EFFICIENT_DEFAULT=y @@ -77,6 +69,22 @@ CONFIG_ARM_CPUIDLE=y CONFIG_CPU_FREQ=y CONFIG_CPUFREQ_DT=y CONFIG_ARM_BIG_LITTLE_CPUFREQ=y +# CONFIG_DMIID is not set +CONFIG_VIRTUALIZATION=y +CONFIG_KVM=y +CONFIG_ARM64_CRYPTO=y +CONFIG_CRYPTO_SHA1_ARM64_CE=y +CONFIG_CRYPTO_SHA2_ARM64_CE=y +CONFIG_CRYPTO_GHASH_ARM64_CE=y +CONFIG_CRYPTO_AES_ARM64_CE_CCM=y +CONFIG_CRYPTO_AES_ARM64_CE_BLK=y +CONFIG_JUMP_LABEL=y +CONFIG_BLK_DEV_INTEGRITY=y +# CONFIG_IOSCHED_DEADLINE is not set +# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set +CONFIG_KSM=y +CONFIG_TRANSPARENT_HUGEPAGE=y +CONFIG_CMA=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y @@ -294,7 +302,6 @@ CONFIG_PHY_RCAR_GEN3_USB2=y CONFIG_PHY_RCAR_GEN3_USB3=y CONFIG_TEE=y CONFIG_OPTEE=y -# CONFIG_DMIID is not set CONFIG_EXT4_FS=y CONFIG_EXT4_FS_POSIX_ACL=y CONFIG_FANOTIFY=y @@ -312,21 +319,12 @@ CONFIG_NFS_V4_2=y CONFIG_ROOT_NFS=y CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ISO8859_1=y -CONFIG_VIRTUALIZATION=y -CONFIG_KVM=y +CONFIG_CRYPTO_ANSI_CPRNG=y +# CONFIG_CRYPTO_DEV_VIRTIO is not set CONFIG_PRINTK_TIME=y -CONFIG_DEBUG_FS=y CONFIG_MAGIC_SYSRQ=y CONFIG_DEBUG_KERNEL=y # CONFIG_SCHED_DEBUG is not set # CONFIG_DEBUG_PREEMPT is not set CONFIG_PROVE_LOCKING=y # CONFIG_FTRACE is not set -CONFIG_CRYPTO_ANSI_CPRNG=y -# CONFIG_CRYPTO_DEV_VIRTIO is not set -CONFIG_ARM64_CRYPTO=y -CONFIG_CRYPTO_SHA1_ARM64_CE=y -CONFIG_CRYPTO_SHA2_ARM64_CE=y -CONFIG_CRYPTO_GHASH_ARM64_CE=y -CONFIG_CRYPTO_AES_ARM64_CE_CCM=y -CONFIG_CRYPTO_AES_ARM64_CE_BLK=y -- 2.17.1
Re: [RFC PATCH] watchdog: HACK: disable bind attributes with NOWAYOUT
Hi Guenter,
> > - if (nowayout)
> > + if (nowayout) {
> > set_bit(WDOG_NO_WAY_OUT, >status);
> > + wdd->parent->driver->suppress_bind_attrs = true;
>
> That makes sense to me. We can not assume that wdd->parent is set, so it
> won't work as-is.
Good point!
> Not sure what a "correct" solution might be. Passing "parent" as argument
> doesn't really
> solve any layering argument
I totally agree. I opted for passing a pointer to the driver to modify:
void watchdog_set_nowayout(struct watchdog_device *wdd, struct driver
*drv, bool nowayout)
I'd think this would work from a layering perspective.
> Did you ensure that the attributes are not already created by the time
> suppress_bind_attrs is set ?
Not yet. I first wanted to make sure if it makes sense, at all. But will
do for later versions.
Thanks for the review,
Wolfram
signature.asc
Description: PGP signature
[PATCH] arm64: dts: renesas: v3hsk: Move lvds0 node
To preserve alphabetical sort order.
Fixes: 4edac426aff11a37 ("arm64: dts: renesas: condor/v3hsk: add DU/LVDS/HDMI
support")
Signed-off-by: Geert Uytterhoeven
---
.../arm64/boot/dts/renesas/r8a77980-v3hsk.dts | 24 +--
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
b/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
index 44ab7344f8aa4922..dd14a41b32cdf242 100644
--- a/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
@@ -119,18 +119,6 @@
};
};
- {
- status = "okay";
-
- ports {
- port@1 {
- lvds0_out: endpoint {
- remote-endpoint = <_in>;
- };
- };
- };
-};
-
{
pinctrl-0 = <_pins>;
pinctrl-names = "default";
@@ -177,6 +165,18 @@
};
};
+ {
+ status = "okay";
+
+ ports {
+ port@1 {
+ lvds0_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+};
+
{
gether_pins: gether {
groups = "gether_mdio_a", "gether_rgmii",
--
2.17.1
[PATCH] arm64: dts: renesas: r8a77965: Move timer node
To preserve alphabetical sort order.
Fixes: 4c529600eef0a6b7 ("arm64: dts: renesas: r8a77965: Add R-Car Gen3 thermal
support")
Signed-off-by: Geert Uytterhoeven
---
arch/arm64/boot/dts/renesas/r8a77965.dtsi | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index 776928518c9b0011..b14a1bad461648ab 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -1932,14 +1932,6 @@
};
};
- timer {
- compatible = "arm,armv8-timer";
- interrupts-extended = < GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2)
| IRQ_TYPE_LEVEL_LOW)>,
- < GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2)
| IRQ_TYPE_LEVEL_LOW)>,
- < GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2)
| IRQ_TYPE_LEVEL_LOW)>,
- < GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2)
| IRQ_TYPE_LEVEL_LOW)>;
- };
-
thermal-zones {
sensor_thermal1: sensor-thermal1 {
polling-delay-passive = <250>;
@@ -1984,6 +1976,14 @@
};
};
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts-extended = < GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2)
| IRQ_TYPE_LEVEL_LOW)>,
+ < GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2)
| IRQ_TYPE_LEVEL_LOW)>,
+ < GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2)
| IRQ_TYPE_LEVEL_LOW)>,
+ < GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2)
| IRQ_TYPE_LEVEL_LOW)>;
+ };
+
/* External USB clocks - can be overridden by the board */
usb3s0_clk: usb3s0 {
compatible = "fixed-clock";
--
2.17.1
[PATCH] arm64: dts: renesas: r8a77965: Fix clock/reset for usb2_phy1
usb2_phy1 accidentally uses the same clock/reset as usb2_phy0.
Fixes: b5857630a829a8d5 ("arm64: dts: renesas: r8a77965: add usb2_phy nodes")
Signed-off-by: Geert Uytterhoeven
---
arch/arm64/boot/dts/renesas/r8a77965.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index 0567e0435e6e1d5c..776928518c9b0011 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -1530,9 +1530,9 @@
compatible = "renesas,usb2-phy-r8a77965",
"renesas,rcar-gen3-usb2-phy";
reg = <0 0xee0a0200 0 0x700>;
- clocks = < CPG_MOD 703>;
+ clocks = < CPG_MOD 702>;
power-domains = < R8A77965_PD_ALWAYS_ON>;
- resets = < 703>;
+ resets = < 702>;
#phy-cells = <0>;
status = "disabled";
};
--
2.17.1
[PATCH] arm64: dts: r8a7796: Fix whitespace around assignments
Signed-off-by: Geert Uytterhoeven
---
arch/arm64/boot/dts/renesas/r8a774a1.dtsi| 4 +-
arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi | 16 +++
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 48 ++--
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 48 ++--
arch/arm64/boot/dts/renesas/r8a77965.dtsi| 36 +++
arch/arm64/boot/dts/renesas/r8a77970.dtsi| 8 ++--
arch/arm64/boot/dts/renesas/r8a77980.dtsi| 16 +++
arch/arm64/boot/dts/renesas/ulcb-kf.dtsi | 2 +-
8 files changed, 89 insertions(+), 89 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
index 8e63e9aee4563883..7094c6ccde66fdee 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
@@ -55,7 +55,7 @@
power-domains = < 0>;
next-level-cache = <_CA57>;
enable-method = "psci";
- clocks =< CPG_CORE 0>;
+ clocks = < CPG_CORE 0>;
};
a57_1: cpu@1 {
@@ -65,7 +65,7 @@
power-domains = < 1>;
next-level-cache = <_CA57>;
enable-method = "psci";
- clocks =< CPG_CORE 0>;
+ clocks = < CPG_CORE 0>;
};
L2_CA57: cache-controller-0 {
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
index d915cff5b1b02cc5..0fb84c219b2feaca 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
@@ -232,7 +232,7 @@
port@1 {
vin0csi21: endpoint@1 {
reg = <1>;
- remote-endpoint= <>;
+ remote-endpoint = <>;
};
};
};
@@ -243,7 +243,7 @@
port@1 {
vin1csi21: endpoint@1 {
reg = <1>;
- remote-endpoint= <>;
+ remote-endpoint = <>;
};
};
};
@@ -254,7 +254,7 @@
port@1 {
vin2csi21: endpoint@1 {
reg = <1>;
- remote-endpoint= <>;
+ remote-endpoint = <>;
};
};
};
@@ -265,7 +265,7 @@
port@1 {
vin3csi21: endpoint@1 {
reg = <1>;
- remote-endpoint= <>;
+ remote-endpoint = <>;
};
};
};
@@ -276,7 +276,7 @@
port@1 {
vin4csi21: endpoint@1 {
reg = <1>;
- remote-endpoint= <>;
+ remote-endpoint = <>;
};
};
};
@@ -287,7 +287,7 @@
port@1 {
vin5csi21: endpoint@1 {
reg = <1>;
- remote-endpoint= <>;
+ remote-endpoint = <>;
};
};
};
@@ -298,7 +298,7 @@
port@1 {
vin6csi21: endpoint@1 {
reg = <1>;
- remote-endpoint= <>;
+ remote-endpoint = <>;
};
};
};
@@ -309,7 +309,7 @@
port@1 {
vin7csi21: endpoint@1 {
reg = <1>;
- remote-endpoint= <>;
+ remote-endpoint = <>;
};
};
};
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index efc24770c0fdaa35..c417d4a098df4c86 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -123,7 +123,7 @@
power-domains = < R8A7795_PD_CA57_CPU0>;
next-level-cache = <_CA57>;
enable-method = "psci";
- clocks =< CPG_CORE R8A7795_CLK_Z>;
+ clocks = < CPG_CORE R8A7795_CLK_Z>;
operating-points-v2 = <_opp>;
#cooling-cells = <2>;
};
@@ -135,7 +135,7 @@
power-domains = < R8A7795_PD_CA57_CPU1>;
next-level-cache = <_CA57>;
enable-method = "psci";
-
Re: [RFC PATCH] watchdog: HACK: disable bind attributes with NOWAYOUT
On 08/28/2018 03:29 AM, Wolfram Sang wrote:
With NOWAYOUT, prevent bind/unbind possibilities in SYSFS.
Proof-of-concept, not for upstream yet.
Signed-off-by: Wolfram Sang
---
So, this is really an RFC to check if something like this is considered useful
or not. If so, we probably need to do it differently because modifying the
parent's driver is likely a layering violation. We could add the driver to
modify as an optional parameter to watchdog_set_nowayout(). I wouldn't favor
another seperate function to configure this, but am open for discussion.
Thanks,
Wolfram
include/linux/watchdog.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/watchdog.h b/include/linux/watchdog.h
index 44985c4a1e86..241de0fa0010 100644
--- a/include/linux/watchdog.h
+++ b/include/linux/watchdog.h
@@ -143,8 +143,10 @@ static inline bool watchdog_hw_running(struct
watchdog_device *wdd)
/* Use the following function to set the nowayout feature */
static inline void watchdog_set_nowayout(struct watchdog_device *wdd, bool
nowayout)
{
- if (nowayout)
+ if (nowayout) {
set_bit(WDOG_NO_WAY_OUT, >status);
+ wdd->parent->driver->suppress_bind_attrs = true;
That makes sense to me. We can not assume that wdd->parent is set, so it won't
work as-is.
Not sure what a "correct" solution might be. Passing "parent" as argument
doesn't really
solve any layering argument - stating that it violates layering if parent is
pulled from
wdd but not if it is passed as argument seems to be a bit ridiculous.
Did you ensure that the attributes are not already created by the time
suppress_bind_attrs is set ?
Thanks,
Guenter
Re: [PATCH 2/2] watchdog: renesas_wdt: stop when unregistering
On 08/28/2018 03:13 AM, Wolfram Sang wrote: We want to go into a sane state when unregistering. Currently, it happens that the watchdog stops when unbinding because of RuntimePM stopping the core clock. When rebinding, the core clock gets reactivated and the watchdog fires even though it hasn't been opened by userspace yet. Strange scenario, yes, but sane state is much preferred anyhow. Signed-off-by: Wolfram Sang Reviewed-by: Guenter Roeck --- drivers/watchdog/renesas_wdt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c index 88d81feba4e6..f45cb183fa75 100644 --- a/drivers/watchdog/renesas_wdt.c +++ b/drivers/watchdog/renesas_wdt.c @@ -234,6 +234,7 @@ static int rwdt_probe(struct platform_device *pdev) watchdog_set_drvdata(>wdev, priv); watchdog_set_nowayout(>wdev, nowayout); watchdog_set_restart_priority(>wdev, 0); + watchdog_stop_on_unregister(>wdev); /* This overrides the default timeout only if DT configuration was found */ ret = watchdog_init_timeout(>wdev, 0, >dev);
Re: [PATCH 1/2] watchdog: core: fix null pointer dereference when releasing cdev
On 08/28/2018 03:13 AM, Wolfram Sang wrote:
watchdog_stop() calls watchdog_update_worker() which needs a valid
wdd->wd_data pointer. So, when unregistering the cdev, clear the
pointers after we call watchdog_stop(), not before.
Fixes: bb292ac1c602 ("watchdog: Introduce watchdog_stop_on_unregister helper")
Signed-off-by: Wolfram Sang
Reviewed-by: Guenter Roeck
---
drivers/watchdog/watchdog_dev.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index ffbdc4642ea5..f6c24b22b37c 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -1019,16 +1019,16 @@ static void watchdog_cdev_unregister(struct
watchdog_device *wdd)
old_wd_data = NULL;
}
- mutex_lock(_data->lock);
- wd_data->wdd = NULL;
- wdd->wd_data = NULL;
- mutex_unlock(_data->lock);
-
if (watchdog_active(wdd) &&
test_bit(WDOG_STOP_ON_UNREGISTER, >status)) {
watchdog_stop(wdd);
}
+ mutex_lock(_data->lock);
+ wd_data->wdd = NULL;
+ wdd->wd_data = NULL;
+ mutex_unlock(_data->lock);
+
hrtimer_cancel(_data->timer);
kthread_cancel_work_sync(_data->work);
[PATCH] arm64: dts: renesas: r8a77965: Fix HS-USB compatible
Should be "renesas,usbhs-r8a77965", not "renesas,usbhs-r8a7796".
Fixes: a06e8af801760a98 ("arm64: dts: renesas: r8a77965: add HS-USB node")
Signed-off-by: Geert Uytterhoeven
---
arch/arm64/boot/dts/renesas/r8a77965.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index 5ce978502ee9f48e..0567e0435e6e1d5c 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -589,7 +589,7 @@
};
hsusb: usb@e659 {
- compatible = "renesas,usbhs-r8a7796",
+ compatible = "renesas,usbhs-r8a77965",
"renesas,rcar-gen3-usbhs";
reg = <0 0xe659 0 0x100>;
interrupts = ;
--
2.17.1
Re: [PATCH 3/3] arm64: dts: renesas: r8a774a1: Add USB3.0 device nodes
On Fri, Aug 24, 2018 at 11:43:49AM +0100, Biju Das wrote: > Add usb3.0 phy, host and function device nodes on RZ/G2M SoC dtsi. > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro Thanks, This looks fine to me but I will wait to see if there are other reviews before applying. Reviewed-by: Simon Horman
renesas-drivers-2018-08-28-v4.19-rc1
I have pushed renesas-drivers-2018-08-28-v4.19-rc1 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-20180827-v4.19-rc1.
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: [PATCH 2/3] arm64: dts: renesas: r8a774a1: Add USB-DMAC and HSUSB device nodes
On Fri, Aug 24, 2018 at 11:43:48AM +0100, Biju Das wrote: > Add usb dmac and hsusb device nodes on RZ/G2M SoC dtsi. > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro Thanks, This looks fine to me but I will wait to see if there are other reviews before applying. Reviewed-by: Simon Horman
Re: [PATCH 1/3] arm64: dts: renesas: r8a774a1: Add USB2.0 phy and host(EHCI/OHCI) device nodes
On Fri, Aug 24, 2018 at 11:43:47AM +0100, Biju Das wrote: > Add USB2.0 phy and host (EHCI/OHCI) device nodes on RZ/G2M SoC dtsi. > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro Reviewed-by: Simon Horman
Re: [PATCH 4/5] arm64: dts: renesas: r8a774a1: Add Ethernet AVB node
On Fri, Aug 24, 2018 at 09:06:49AM +, Fabrizio Castro wrote:
> Hello Simon,
>
> Thank you for your feedback!
>
> > Subject: Re: [PATCH 4/5] arm64: dts: renesas: r8a774a1: Add Ethernet AVB
> > node
> >
> > On Thu, Aug 23, 2018 at 09:58:50AM +0100, Biju Das wrote:
> > > From: Fabrizio Castro
> > >
> > > This patch adds the SoC specific part of the Ethernet AVB
> > > device tree node.
> > >
> > > Signed-off-by: Fabrizio Castro
> > > Reviewed-by: Biju Das
> > > ---
> > > arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 45
> > > +++
> > > 1 file changed, 45 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > > b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > > index 15d7785..b771211 100644
> > > --- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > > +++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > > @@ -350,6 +350,51 @@
> > > dma-channels = <16>;
> > > };
> > >
> > > +avb: ethernet@e680 {
> > > +compatible = "renesas,etheravb-r8a774a1",
> > > + "renesas,etheravb-rcar-gen3";
> > > +reg = <0 0xe680 0 0x800>;
> >
> > Should a region, <0 0xe6a0 0 0x1>, also be added
> > here to describe the suggested space for descriptors?
>
> There is no STBE (Stream Buffer for EthernetAVB-IF) on the r8a774a1, and
> that's why this node doesn't come with such a region.
Thanks for the follow-up. In that case I'm fine with this patch but
I'd like to wait a little longer to allow review by others.
Reviewed-by: Simon Horman
vsps and channel indices (was: Re: [PATCH v3 1/2] arm64: dts: renesas: r8a77980: add FCPVD/VSPD/DU/LVDS support)
Hi Sergei, Laurent, Kieran,
On Wed, Jun 13, 2018 at 10:11 PM Sergei Shtylyov
wrote:
> Describe the interconnected FCPVD0, VSPD0, DU, and LVDS0 devices in the
> R8A77980 device tree...
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov
> Signed-off-by: Sergei Shtylyov
> Reviewed-by: Laurent Pinchart
> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> + du: display@feb0 {
> + compatible = "renesas,du-r8a77980",
> +"renesas,du-r8a77970";
> + reg = <0 0xfeb0 0 0x8>;
> + interrupts = ;
> + clocks = < CPG_MOD 724>;
> + clock-names = "du.0";
> + power-domains = < R8A77980_PD_ALWAYS_ON>;
> + resets = < 724>;
> + vsps = <>;
According to the bindings, the vsps property should also contain a
channel index.
Laurent added the indices to r8a7795.dtsi, but r8a7795-es.dtsi overrides
that with a version without the indices.
Kieran included the indices when adding DU support for r8a77965 and
r8a77995.
r8a7796.dtsi, r8a77970.dtsi, and r8a77980.dtsi lack the indices.
Commit fd57d77f9c649cf9 ("dt-bindings: display: rcar-du: Add a VSP channel
index to the vsps DT property") says a backwards-compatibility mode can be
implemented, but I fail to see how this can work, as rcar_du_vsps_init()
will just return an error, which is propagated.
What am I missing?
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
[GIT PULL LTSI-4.14] LTSI-v4.14 Backport or I2C R-Car Fix
Hi, This is intended as a submission to LTSI-4.14. It is the backport of a fix for the R-Car I2C driver, and its dependency, both of which are present in linux-next 20180821. This pull-request is based on "[GIT PULL LTSI-4.14] Renesas SoCs and Drivers to v4.18-rc8", tagged as backport/v4.14.61/snapshot-to-v4.18-rc8+fixes-flattened, which I have already sent a pull-request for. There are 2 patches. I have performed build testing of this backports on a wide range of defconfigs and I am not aware of any regressions over v4.14.40 (the baseline chosen when this work began). The following changes since commit cc88cfdc0571385f098e82db47f5a16b6f44726e: i2c: rcar: use the new get_bus_free callback (2018-08-09 17:22:00 +0200) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-backport.git backport/v4.14.61/snapshot-to-v4.18+fixes-flattened for you to fetch changes up to 4d4605e5c137ed9a53582e573118cbc16b82cbf1: i2c: rcar: implement STOP and REP_START according to docs (2018-08-28 13:35:06 +0200) LTSI-v4.14 Backport or I2C R-Car Fix Base: * v4.14.61 * Backports of components for Renesas SoCs to v4.18 Backport of post-v4.18 fix for i2c-rcar: * implement STOP and REP_START according to docs Dependency of above * Refactor private flags of i2c-rcar driver Wolfram Sang (2): i2c: rcar: refactor private flags i2c: rcar: implement STOP and REP_START according to docs drivers/i2c/busses/i2c-rcar.c | 39 +++ 1 file changed, 23 insertions(+), 16 deletions(-)
[PATCH v2] pinctrl: sh-pfc: r8a77990: Add DU pins, groups and function
This patch adds DU pins, groups and function for the R8A77990 (E3) SoC.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Add DU_CLKIN0
---
drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 110 ++
1 file changed, 110 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
index b81c807ac54d..bb9c943e2b37 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
@@ -1371,6 +1371,94 @@ static const unsigned int avb_avtp_capture_a_mux[] = {
AVB_AVTP_CAPTURE_A_MARK,
};
+/* - DU -
*/
+static const unsigned int du_rgb666_pins[] = {
+ /* R[7:2], G[7:2], B[7:2] */
+ RCAR_GP_PIN(0, 8), RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 5),
+ RCAR_GP_PIN(0, 3), RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 0),
+ RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12), RCAR_GP_PIN(1, 10),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(0, 15), RCAR_GP_PIN(0, 11),
+ RCAR_GP_PIN(0, 1), RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 16),
+ RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 14), RCAR_GP_PIN(1, 13),
+};
+static const unsigned int du_rgb666_mux[] = {
+ DU_DR7_MARK, DU_DR6_MARK, DU_DR5_MARK, DU_DR4_MARK,
+ DU_DR3_MARK, DU_DR2_MARK,
+ DU_DG7_MARK, DU_DG6_MARK, DU_DG5_MARK, DU_DG4_MARK,
+ DU_DG3_MARK, DU_DG2_MARK,
+ DU_DB7_MARK, DU_DB6_MARK, DU_DB5_MARK, DU_DB4_MARK,
+ DU_DB3_MARK, DU_DB2_MARK,
+};
+static const unsigned int du_rgb888_pins[] = {
+ /* R[7:0], G[7:0], B[7:0] */
+ RCAR_GP_PIN(0, 8), RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 5),
+ RCAR_GP_PIN(0, 3), RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 0),
+ RCAR_GP_PIN(1, 22), RCAR_GP_PIN(1, 21),
+ RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12), RCAR_GP_PIN(1, 10),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(0, 15), RCAR_GP_PIN(0, 11),
+ RCAR_GP_PIN(0, 10), RCAR_GP_PIN(0, 9),
+ RCAR_GP_PIN(0, 1), RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 16),
+ RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 14), RCAR_GP_PIN(1, 13),
+ RCAR_GP_PIN(1, 19), RCAR_GP_PIN(1, 18),
+};
+static const unsigned int du_rgb888_mux[] = {
+ DU_DR7_MARK, DU_DR6_MARK, DU_DR5_MARK, DU_DR4_MARK,
+ DU_DR3_MARK, DU_DR2_MARK, DU_DR1_MARK, DU_DR0_MARK,
+ DU_DG7_MARK, DU_DG6_MARK, DU_DG5_MARK, DU_DG4_MARK,
+ DU_DG3_MARK, DU_DG2_MARK, DU_DG1_MARK, DU_DG0_MARK,
+ DU_DB7_MARK, DU_DB6_MARK, DU_DB5_MARK, DU_DB4_MARK,
+ DU_DB3_MARK, DU_DB2_MARK, DU_DB1_MARK, DU_DB0_MARK,
+};
+static const unsigned int du_clk_in_0_pins[] = {
+ /* CLKIN0 */
+ RCAR_GP_PIN(0, 16),
+};
+static const unsigned int du_clk_in_0_mux[] = {
+ DU_DOTCLKIN0_MARK
+};
+static const unsigned int du_clk_in_1_pins[] = {
+ /* CLKIN1 */
+ RCAR_GP_PIN(1, 1),
+};
+static const unsigned int du_clk_in_1_mux[] = {
+ DU_DOTCLKIN1_MARK
+};
+static const unsigned int du_clk_out_0_pins[] = {
+ /* CLKOUT */
+ RCAR_GP_PIN(1, 3),
+};
+static const unsigned int du_clk_out_0_mux[] = {
+ DU_DOTCLKOUT0_MARK
+};
+static const unsigned int du_sync_pins[] = {
+ /* VSYNC, HSYNC */
+ RCAR_GP_PIN(1, 11), RCAR_GP_PIN(1, 8),
+};
+static const unsigned int du_sync_mux[] = {
+ DU_VSYNC_MARK, DU_HSYNC_MARK
+};
+static const unsigned int du_disp_cde_pins[] = {
+ /* DISP_CDE */
+ RCAR_GP_PIN(1, 1),
+};
+static const unsigned int du_disp_cde_mux[] = {
+ DU_DISP_CDE_MARK,
+};
+static const unsigned int du_cde_pins[] = {
+ /* CDE */
+ RCAR_GP_PIN(1, 0),
+};
+static const unsigned int du_cde_mux[] = {
+ DU_CDE_MARK,
+};
+static const unsigned int du_disp_pins[] = {
+ /* DISP */
+ RCAR_GP_PIN(1, 2),
+};
+static const unsigned int du_disp_mux[] = {
+ DU_DISP_MARK,
+};
+
/* - I2C
*/
static const unsigned int i2c1_a_pins[] = {
/* SCL, SDA */
@@ -1839,6 +1927,15 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(avb_avtp_pps),
SH_PFC_PIN_GROUP(avb_avtp_match_a),
SH_PFC_PIN_GROUP(avb_avtp_capture_a),
+ SH_PFC_PIN_GROUP(du_rgb666),
+ SH_PFC_PIN_GROUP(du_rgb888),
+ SH_PFC_PIN_GROUP(du_clk_in_0),
+ SH_PFC_PIN_GROUP(du_clk_in_1),
+ SH_PFC_PIN_GROUP(du_clk_out_0),
+ SH_PFC_PIN_GROUP(du_sync),
+ SH_PFC_PIN_GROUP(du_disp_cde),
+ SH_PFC_PIN_GROUP(du_cde),
+ SH_PFC_PIN_GROUP(du_disp),
SH_PFC_PIN_GROUP(i2c1_a),
SH_PFC_PIN_GROUP(i2c1_b),
SH_PFC_PIN_GROUP(i2c1_c),
@@ -1901,6 +1998,18 @@ static const char * const avb_groups[] = {
"avb_avtp_capture_a",
};
+static const char * const du_groups[] = {
+ "du_rgb666",
+ "du_rgb888",
+ "du_clk_in_0",
+ "du_clk_in_1",
+ "du_clk_out_0",
+ "du_sync",
+ "du_disp_cde",
+ "du_cde",
+ "du_disp",
+};
+
static const char *
Re: [PATCH] pinctrl: sh-pfc: r8a77990: Add DU pins, groups and function
Hi Geert,
On Tuesday, 28 August 2018 11:41:00 EEST Geert Uytterhoeven wrote:
> On Thu, Aug 23, 2018 at 9:09 AM Laurent Pinchart wrote:
> > This patch adds DU pins, groups and function for the R8A77990 (E3) SoC.
> >
> > Signed-off-by: Laurent Pinchart
> >
>
> Thanks for your patch!
>
> > --- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> > +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> > @@ -1371,6 +1371,87 @@ static const unsigned int avb_avtp_capture_a_mux[]
> > = {>
> > AVB_AVTP_CAPTURE_A_MARK,
> >
> > };
> >
> > +/* - DU
> > - */
> > +static const unsigned int du_rgb666_pins[] = {
> > + /* R[7:2], G[7:2], B[7:2] */
> > + RCAR_GP_PIN(0, 8), RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 5),
> > + RCAR_GP_PIN(0, 3), RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 0),
> > + RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12), RCAR_GP_PIN(1, 10),
> > + RCAR_GP_PIN(1, 4), RCAR_GP_PIN(0, 15), RCAR_GP_PIN(0, 11),
> > + RCAR_GP_PIN(0, 1), RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 16),
> > + RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 14), RCAR_GP_PIN(1, 13),
> > +};
> > +static const unsigned int du_rgb666_mux[] = {
> > + DU_DR7_MARK, DU_DR6_MARK, DU_DR5_MARK, DU_DR4_MARK,
> > + DU_DR3_MARK, DU_DR2_MARK,
> > + DU_DG7_MARK, DU_DG6_MARK, DU_DG5_MARK, DU_DG4_MARK,
> > + DU_DG3_MARK, DU_DG2_MARK,
> > + DU_DB7_MARK, DU_DB6_MARK, DU_DB5_MARK, DU_DB4_MARK,
> > + DU_DB3_MARK, DU_DB2_MARK,
> > +};
> > +static const unsigned int du_rgb888_pins[] = {
> > + /* R[7:0], G[7:0], B[7:0] */
> > + RCAR_GP_PIN(0, 8), RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 5),
> > + RCAR_GP_PIN(0, 3), RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 0),
> > + RCAR_GP_PIN(1, 22), RCAR_GP_PIN(1, 21),
> > + RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12), RCAR_GP_PIN(1, 10),
> > + RCAR_GP_PIN(1, 4), RCAR_GP_PIN(0, 15), RCAR_GP_PIN(0, 11),
> > + RCAR_GP_PIN(0, 10), RCAR_GP_PIN(0, 9),
> > + RCAR_GP_PIN(0, 1), RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 16),
> > + RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 14), RCAR_GP_PIN(1, 13),
> > + RCAR_GP_PIN(1, 19), RCAR_GP_PIN(1, 18),
> > +};
> > +static const unsigned int du_rgb888_mux[] = {
> > + DU_DR7_MARK, DU_DR6_MARK, DU_DR5_MARK, DU_DR4_MARK,
> > + DU_DR3_MARK, DU_DR2_MARK, DU_DR1_MARK, DU_DR0_MARK,
> > + DU_DG7_MARK, DU_DG6_MARK, DU_DG5_MARK, DU_DG4_MARK,
> > + DU_DG3_MARK, DU_DG2_MARK, DU_DG1_MARK, DU_DG0_MARK,
> > + DU_DB7_MARK, DU_DB6_MARK, DU_DB5_MARK, DU_DB4_MARK,
> > + DU_DB3_MARK, DU_DB2_MARK, DU_DB1_MARK, DU_DB0_MARK,
> > +};
> > +static const unsigned int du_clk_in_1_pins[] = {
> > + /* CLKIN */
> > + RCAR_GP_PIN(1, 1),
> > +};
> > +static const unsigned int du_clk_in_1_mux[] = {
> > + DU_DOTCLKIN1_MARK
> > +};
>
> Missing du_clk_in_0 (GP0_16)?
Indeed. v2 is on its way.
--
Regards,
Laurent Pinchart
Re: [RFT 0/8] arm64: dts: renesas: Ebisu: Add HDMI and CVBS input
Hi Niklas, On Monday, 27 August 2018 16:23:45 EEST Niklas Söderlund wrote: > On 2018-08-27 11:49:56 +0200, Jacopo Mondi wrote: > > On Sat, Aug 25, 2018 at 03:18:06PM +0200, jacopo mondi wrote: > >> On Sat, Aug 25, 2018 at 08:37:15AM +0200, Niklas Söderlund wrote: > >>> On 2018-08-25 02:54:44 +0300, Laurent Pinchart wrote: > On Monday, 20 August 2018 13:16:34 EEST Jacopo Mondi wrote: > > Hello renesas list, > > > > this series add supports for the HDMI and CVBS input to R-Car > > E3 R8A77990 Ebisu board. > > > > It's an RFT, as I don't have an Ebisu to test with :( > > > > The series adds supports for the following items: > > > > - PFC: add VIN groups and functions > > - R-Car VIN and R-Car CSI-2: add support for R8A77990 > > - R8A77990: Add I2C, VIN and CSI-2 nodes > > - Ebisu: describe HDMI and CVBS inputs > > > > Each patch, when relevant reports difference between the upported > > BSP patch and the proposed one. > > > > I know Laurent should receive an Ebisu sooner or later, maybe we > > can sync for testing :) > > I've given the series a first test, and I think a bit more work is > needed :-) > > [1.455533] adv748x 0-0070: Endpoint > /soc/i2c@e650/video-receiver@70/ port@7/endpoint on port 7 > [1.464683] adv748x 0-0070: Endpoint > /soc/i2c@e650/video-receiver@70/ port@8/endpoint on port 8 > [1.473728] adv748x 0-0070: Endpoint > /soc/i2c@e650/video-receiver@70/ port@a/endpoint on port 10 > [1.484835] adv748x 0-0070: chip found @ 0xe0 revision 2143 > [1.639470] adv748x 0-0070: No endpoint found for txb > [1.644653] adv748x 0-0070: Failed to probe TXB > >>> > >>> I fear this is a design choice in the adv748x driver. Currently the > >>> driver requires both of its two CSI-2 transmitters to be > >>> connected/used else probe fails. Furthermore the HDMI capture is always > >>> routed to TXA while the analog capture is always routed to TXB. > >>> > >>> Now that we have a board where only TXA is connected but both HDMI and > >>> analog captures are used maybe it's time to do some more work on v4l2 > >>> and the adv748x driver ;-P What's missing: > >>> > >>> - Probe should be OK with either TXA or TXB connected and not bail if > >>> not both are used. > >> > >> I have three patches for this I hope to share as soon as I'll be able > >> to do some more testing > >> > >>> - The media_device_ops or at least the .link_notify() callback of that > >>> struct must be changed so not one driver in the media graph is > >>> responsible for all links. In this case rcar-vin provides the > >>> callback and rcar-vin should not judge which links between the > >>> adv748x subdevices are OK to enable/disable. Currently the links > >>> between the adv748x subdevices are immutably enabled to avoid this > >>> particular problem. > >> > >> Uh, I didn't get this :/ Care to elaborate more? > > > > I'm thinking if it is not enough to just provide a .link_setup() > > callback to the (enabled) csi-2 sink pads of the adv748x and handle > > routing between the afe/hdmi sources and that sink, without the vin's > > registered link_notify playing any role in that. > > That is my point, the v4l2 framework needs work to allow all drivers to > provide a .link_setup() callback. And this as you describe will conflict > with the current solution where there is only one possible such > callback. So in addition to being able to have multiple such callbacks > the current drivers implementing one would need to be updated to ignore > links which it do not care about. Isn't this already possible ? We have a single top-level .link_notify() operation at the media device level, but also .link_setup() operations for each entity. > In our case the .link_setup() in rcar-vin should not care about the > links between the adv748x internal subdevice. Of course the other way > around is also true, the .link_setup() in adv748x should not care about > the links handled by rcar-vin :-) > > As you discovers this is not possible today and might require some work > or maybe even a different design then the one outlined above. > > >> What I was about to do, instead, given the fixed HDMI->TXA and AFE->TXB > >> routing in the adv748x driver was to insert a .link_validate() callback > >> for both the HDMI and AFE backends, that checks for the availability of > >> the corresponding output endpoint. This seems to me that this makes > >> easy when dynamic routing will be added to do the same on the > >> dynamically configured sink pad. > >> What do you think? > > > > On a second thought if a CSI-2 sink it's not enabled it is not part of > > the media graph neither, so it should not be possible to link it in any > > pipeline, so no link validation is required. The link simply can't > > exist. > > > > It seems to me that to support Ebisu-like designs is then
[RFC PATCH] watchdog: HACK: disable bind attributes with NOWAYOUT
With NOWAYOUT, prevent bind/unbind possibilities in SYSFS.
Proof-of-concept, not for upstream yet.
Signed-off-by: Wolfram Sang
---
So, this is really an RFC to check if something like this is considered useful
or not. If so, we probably need to do it differently because modifying the
parent's driver is likely a layering violation. We could add the driver to
modify as an optional parameter to watchdog_set_nowayout(). I wouldn't favor
another seperate function to configure this, but am open for discussion.
Thanks,
Wolfram
include/linux/watchdog.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/watchdog.h b/include/linux/watchdog.h
index 44985c4a1e86..241de0fa0010 100644
--- a/include/linux/watchdog.h
+++ b/include/linux/watchdog.h
@@ -143,8 +143,10 @@ static inline bool watchdog_hw_running(struct
watchdog_device *wdd)
/* Use the following function to set the nowayout feature */
static inline void watchdog_set_nowayout(struct watchdog_device *wdd, bool
nowayout)
{
- if (nowayout)
+ if (nowayout) {
set_bit(WDOG_NO_WAY_OUT, >status);
+ wdd->parent->driver->suppress_bind_attrs = true;
+ }
}
/* Use the following function to stop the watchdog on reboot */
--
2.11.0
[PATCH 0/2] watchdog: fix OOPS when using stop_on_unregister and use it for R-Car
I wanted to activate 'stop_on_unregister' for the Renesas R-Car driver (see patch 2) and stumbled over an OOPS when using it. So, patch 1 addresses this problem to the best of my knowledge. Looking forward to comments. Happy hacking, Wolfram Wolfram Sang (2): watchdog: core: fix null pointer dereference when releasing cdev watchdog: renesas_wdt: stop when unregistering drivers/watchdog/renesas_wdt.c | 1 + drivers/watchdog/watchdog_dev.c | 10 +- 2 files changed, 6 insertions(+), 5 deletions(-) -- 2.11.0
[PATCH 2/2] watchdog: renesas_wdt: stop when unregistering
We want to go into a sane state when unregistering. Currently, it happens that the watchdog stops when unbinding because of RuntimePM stopping the core clock. When rebinding, the core clock gets reactivated and the watchdog fires even though it hasn't been opened by userspace yet. Strange scenario, yes, but sane state is much preferred anyhow. Signed-off-by: Wolfram Sang --- drivers/watchdog/renesas_wdt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c index 88d81feba4e6..f45cb183fa75 100644 --- a/drivers/watchdog/renesas_wdt.c +++ b/drivers/watchdog/renesas_wdt.c @@ -234,6 +234,7 @@ static int rwdt_probe(struct platform_device *pdev) watchdog_set_drvdata(>wdev, priv); watchdog_set_nowayout(>wdev, nowayout); watchdog_set_restart_priority(>wdev, 0); + watchdog_stop_on_unregister(>wdev); /* This overrides the default timeout only if DT configuration was found */ ret = watchdog_init_timeout(>wdev, 0, >dev); -- 2.11.0
[PATCH 1/2] watchdog: core: fix null pointer dereference when releasing cdev
watchdog_stop() calls watchdog_update_worker() which needs a valid
wdd->wd_data pointer. So, when unregistering the cdev, clear the
pointers after we call watchdog_stop(), not before.
Fixes: bb292ac1c602 ("watchdog: Introduce watchdog_stop_on_unregister helper")
Signed-off-by: Wolfram Sang
---
drivers/watchdog/watchdog_dev.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index ffbdc4642ea5..f6c24b22b37c 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -1019,16 +1019,16 @@ static void watchdog_cdev_unregister(struct
watchdog_device *wdd)
old_wd_data = NULL;
}
- mutex_lock(_data->lock);
- wd_data->wdd = NULL;
- wdd->wd_data = NULL;
- mutex_unlock(_data->lock);
-
if (watchdog_active(wdd) &&
test_bit(WDOG_STOP_ON_UNREGISTER, >status)) {
watchdog_stop(wdd);
}
+ mutex_lock(_data->lock);
+ wd_data->wdd = NULL;
+ wdd->wd_data = NULL;
+ mutex_unlock(_data->lock);
+
hrtimer_cancel(_data->timer);
kthread_cancel_work_sync(_data->work);
--
2.11.0
Re: [PATCH 1/2] arm64: dts: r8a77965: add FDP1 device nodes
Hi Simon, On Monday, 27 August 2018 15:57:05 EEST Simon Horman wrote: > On Fri, Aug 24, 2018 at 11:45:52AM +0300, Laurent Pinchart wrote: > > On Friday, 24 August 2018 07:52:28 EEST Nguyen An Hoan wrote: > > > From: Hoan Nguyen An > > > > You're missing a commit message. I agree that for simple patches like this > > one the subject line often contains enough information, but adding a > > commit message is still a good practice that we try to enforce through > > the kernel. For instance, looking at git history for r8a7796, you could > > use > > > > "The r8a77965 has a single FDP1 instance." > > > > > Signed-off-by: Hoan Nguyen An > > > > Apart from that, > > > > Reviewed-by: Laurent Pinchart > > > > Simon, could you update the commit message when taking this patch in your > > tree, to avoid the need for a v2 ? > > Yes, can do. > > Can I confirm that it is safe, from a regression point of view, > to apply this patch without patch 2/2? As far as I know it is safe, yes. -- Regards, Laurent Pinchart
Re: [PATCH 2/2] clk: renesas: r8a77965: Add FDP clock
Hi Hoan,
On Fri, Aug 24, 2018 at 6:52 AM Nguyen An Hoan wrote:
> From: Hoan Nguyen An
>
> Signed-off-by: Hoan Nguyen An
Thanks for your patch!
> --- a/drivers/clk/renesas/r8a77965-cpg-mssr.c
> +++ b/drivers/clk/renesas/r8a77965-cpg-mssr.c
> @@ -112,6 +112,7 @@ static const struct cpg_core_clk r8a77965_core_clks[]
> __initconst = {
> };
>
> static const struct mssr_mod_clk r8a77965_mod_clks[] __initconst = {
> + DEF_MOD("fdp0", 119,R8A77965_CLK_S0D1),
In the datasheet, and in drivers for other SoCs, this clock is called fdp1-0.
> DEF_MOD("scif5",202,R8A77965_CLK_S3D4),
> DEF_MOD("scif4",203,R8A77965_CLK_S3D4),
> DEF_MOD("scif3",204,R8A77965_CLK_S3D4),
Reviewed-by: Geert Uytterhoeven
Will queue in clk-renesas-for-v4.20, with the clock name fixed, and a commit
message added (stolen from the r8a7796 commit ;-).
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] clk: renesas: r8a77970: add SD0H/SD0 clocks for SDHI
Hi Sergei,
On Tue, Aug 21, 2018 at 6:41 PM Sergei Shtylyov
wrote:
> 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
Thanks for your patch!
Looks good to me, but two minor nits below.
> --- renesas-drivers.orig/drivers/clk/renesas/r8a77970-cpg-mssr.c
> +++ renesas-drivers/drivers/clk/renesas/r8a77970-cpg-mssr.c
> @@ -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)
static
> +{
> + 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,
CPG_SD0CKCR instead of hardcoded 0x74?
> + _lock);
> +}
> +
> const struct cpg_mssr_info r8a77970_cpg_mssr_info __initconst = {
> /* Core Clocks */
> .core_clks = r8a77970_core_clks,
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: [RFT 5/8] pinctrl: sh-pfc: r8a77990: Add VIN pins, groups and functions
Hi Geert,
On Tue, Aug 28, 2018 at 09:46:57AM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Mon, Aug 20, 2018 at 12:17 PM Jacopo Mondi
> wrote:
> > From: Takeshi Kihara
> >
> > This patch adds VIN{4,5} pins, groups and functions to the R8A77990 SoC.
> >
> > Signed-off-by: Takeshi Kihara
> > Signed-off-by: Jacopo Mondi
>
> Thanks for your patch!
Thanks for review.
>
> > --- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> > +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> > @@ -1982,6 +1982,446 @@ static const unsigned int usb30_id_mux[] = {
> > USB3HS0_ID_MARK,
> > };
> >
> > +/* - VIN4
> > --- */
> > +static const unsigned int vin4_data8_a_pins[] = {
> > + RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
> > + RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
> > + RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
> > + RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
> > +};
> > +
> > +static const unsigned int vin4_data8_a_mux[] = {
> > + VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
> > + VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
> > + VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
> > + VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
> > +};
> > +
> > +static const unsigned int vin4_data10_a_pins[] = {
> > + RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
> > + RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
> > + RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
> > + RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
> > + RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
> > +};
> > +
> > +static const unsigned int vin4_data10_a_mux[] = {
> > + VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
> > + VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
> > + VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
> > + VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
> > + VI4_DATA8_MARK, VI4_DATA9_MARK,
> > +};
>
> Can you please use union vin_data and VIN_DATA_PIN_GROUP(), to reduce
> redundancies, cfr. commit 9942a5b52990b8d5 ("pinctrl: sh-pfc: r8a7795:
> Deduplicate VIN4 pin definitions")?
> Or do you want to do that in a follow-up patch (which means more
> review work)?
I will have to resend anyhow, so I can make this change in v2.
>
> > +static const unsigned int vin4_data8_sft8_pins[] = {
> > + RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
> > + RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
> > + RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
> > + RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
> > +};
>
> R-Car H3 and M3-W don't have the data8_sft8 groups yet (the BSP has).
> IIRC, that's due to rcar-vin not yet supporting that mode. Niklas?
Not sure what SFT mode is. The only registers naming this are related
to "Shift Down Volume" and RGB->YCrCb conversion. I'll wait for
Niklas, and eventually remove the pin group.
>
> > +static const unsigned int vin5_sync_a_pins[] = {
> > + /* HSYNC_N, VSYNC_N */
> > + RCAR_GP_PIN(1, 8), RCAR_GP_PIN(1, 9),
> > +};
> > +
> > +static const unsigned int vin5_sync_a_mux[] = {
> > + VI5_HSYNC_N_A_MARK, VI5_VSYNC_N_A_MARK,
> > +};
> > +
> > +static const unsigned int vin5_field_a_pins[] = {
> > + RCAR_GP_PIN(1, 10),
> > +};
> > +
> > +static const unsigned int vin5_field_a_mux[] = {
> > + VI5_FIELD_A_MARK,
> > +};
> > +
> > +static const unsigned int vin5_clkenb_a_pins[] = {
> > + RCAR_GP_PIN(0, 1),
> > +};
> > +
> > +static const unsigned int vin5_clkenb_a_mux[] = {
> > + VI5_CLKENB_A_MARK,
> > +};
>
> "A" groups without "B" groups? Usually we drop the "_A" suffix in that case.
>
> They're actually named like that in hardware user manual rev. 1.00 (and no
> update in the errata)?
It's true, the sync signal pins of VI4 do not have any "_a" or "_b"
mark, while the VI5 ones do. Eg. we have "VI5_VSYNC#_A" and
"VI4_VSYNC#". This might be an error in the chip manual or a
suggestion that VIN5_DATA.*_B pins do not support synchronism signals
and can only work with embedded synchronization. This seems unlikely
to me, and checking Table 26.20.3 that lists the supported input format
for each channel, I don't see anything like that mentioned.
Morimoto-san, Shimoda-san, could you please verify why those pins,
have a different naming scheme?
Thanks
j
>
> 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
signature.asc
Description: PGP signature
Re: [PATCH] pinctrl: sh-pfc: r8a77990: Add DU pins, groups and function
Hi Laurent,
On Thu, Aug 23, 2018 at 9:09 AM Laurent Pinchart
wrote:
> This patch adds DU pins, groups and function for the R8A77990 (E3) SoC.
>
> Signed-off-by: Laurent Pinchart
Thanks for your patch!
> --- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> @@ -1371,6 +1371,87 @@ static const unsigned int avb_avtp_capture_a_mux[] = {
> AVB_AVTP_CAPTURE_A_MARK,
> };
>
> +/* - DU
> - */
> +static const unsigned int du_rgb666_pins[] = {
> + /* R[7:2], G[7:2], B[7:2] */
> + RCAR_GP_PIN(0, 8), RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 5),
> + RCAR_GP_PIN(0, 3), RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 0),
> + RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12), RCAR_GP_PIN(1, 10),
> + RCAR_GP_PIN(1, 4), RCAR_GP_PIN(0, 15), RCAR_GP_PIN(0, 11),
> + RCAR_GP_PIN(0, 1), RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 16),
> + RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 14), RCAR_GP_PIN(1, 13),
> +};
> +static const unsigned int du_rgb666_mux[] = {
> + DU_DR7_MARK, DU_DR6_MARK, DU_DR5_MARK, DU_DR4_MARK,
> + DU_DR3_MARK, DU_DR2_MARK,
> + DU_DG7_MARK, DU_DG6_MARK, DU_DG5_MARK, DU_DG4_MARK,
> + DU_DG3_MARK, DU_DG2_MARK,
> + DU_DB7_MARK, DU_DB6_MARK, DU_DB5_MARK, DU_DB4_MARK,
> + DU_DB3_MARK, DU_DB2_MARK,
> +};
> +static const unsigned int du_rgb888_pins[] = {
> + /* R[7:0], G[7:0], B[7:0] */
> + RCAR_GP_PIN(0, 8), RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 5),
> + RCAR_GP_PIN(0, 3), RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 0),
> + RCAR_GP_PIN(1, 22), RCAR_GP_PIN(1, 21),
> + RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12), RCAR_GP_PIN(1, 10),
> + RCAR_GP_PIN(1, 4), RCAR_GP_PIN(0, 15), RCAR_GP_PIN(0, 11),
> + RCAR_GP_PIN(0, 10), RCAR_GP_PIN(0, 9),
> + RCAR_GP_PIN(0, 1), RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 16),
> + RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 14), RCAR_GP_PIN(1, 13),
> + RCAR_GP_PIN(1, 19), RCAR_GP_PIN(1, 18),
> +};
> +static const unsigned int du_rgb888_mux[] = {
> + DU_DR7_MARK, DU_DR6_MARK, DU_DR5_MARK, DU_DR4_MARK,
> + DU_DR3_MARK, DU_DR2_MARK, DU_DR1_MARK, DU_DR0_MARK,
> + DU_DG7_MARK, DU_DG6_MARK, DU_DG5_MARK, DU_DG4_MARK,
> + DU_DG3_MARK, DU_DG2_MARK, DU_DG1_MARK, DU_DG0_MARK,
> + DU_DB7_MARK, DU_DB6_MARK, DU_DB5_MARK, DU_DB4_MARK,
> + DU_DB3_MARK, DU_DB2_MARK, DU_DB1_MARK, DU_DB0_MARK,
> +};
> +static const unsigned int du_clk_in_1_pins[] = {
> + /* CLKIN */
> + RCAR_GP_PIN(1, 1),
> +};
> +static const unsigned int du_clk_in_1_mux[] = {
> + DU_DOTCLKIN1_MARK
> +};
Missing du_clk_in_0 (GP0_16)?
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/3] pinctrl: sh-pfc: r8a7795: Add I2C{0,3,5} pins, groups and functions
Hi Uli,
On Fri, Aug 17, 2018 at 3:19 PM Ulrich Hecht wrote:
> From: Takeshi Kihara
>
> This patch adds I2C{0,3,5} pins, groups and functions to the R8A7795 SoC.
>
> These pins are physically muxed with other pins. Therefore, setup of
> MOD_SEL is needed for exclusive control with other pins.
>
> Signed-off-by: Takeshi Kihara
> Signed-off-by: Ulrich Hecht
Thanks for your patch!
All comments below apply to all three patches.
> --- a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
> +++ b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
> @@ -578,11 +581,18 @@ enum {
> PINMUX_IPSR
> PINMUX_MOD_SELS
> PINMUX_STATIC
> + PINMUX_PHYS
> PINMUX_MARK_END,
> #undef F_
> #undef FM
> };
>
> +#define PINMUX_IPSR_MSEL2(ipsr, fn, msel1, msel2) \
> + PINMUX_DATA(fn##_MARK, FN_##msel1, FN_##msel2, FN_##fn, FN_##ipsr)
> +
> +#define PINMUX_IPSR_PHYS(ipsr, fn, msel) \
> + PINMUX_DATA(fn##_MARK, FN_##msel)
Please move the two definitions above to drivers/pinctrl/sh-pfc/sh_pfc.h,
so they can be shared, and add comments.
> @@ -4261,9 +4302,12 @@ static const struct sh_pfc_pin_group pinmux_groups[] =
> {
> SH_PFC_PIN_GROUP(hscif4_clk),
> SH_PFC_PIN_GROUP(hscif4_ctrl),
> SH_PFC_PIN_GROUP(hscif4_data_b),
> + SH_PFC_PIN_GROUP(i2c0),
> SH_PFC_PIN_GROUP(i2c1_a),
> SH_PFC_PIN_GROUP(i2c1_b),
> SH_PFC_PIN_GROUP(i2c2_a),
> + SH_PFC_PIN_GROUP(i2c3),
> + SH_PFC_PIN_GROUP(i2c5),
Please move the above two lines down, to preserve sort order.
> SH_PFC_PIN_GROUP(i2c2_b),
> SH_PFC_PIN_GROUP(i2c6_a),
> SH_PFC_PIN_GROUP(i2c6_b),
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 v3 1/2] mmc: renesas_sdhi: skip SCC error check when retuning
On 27 August 2018 at 17:13, Niklas Söderlund
wrote:
> 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 v2
> - Add comment to describe why checking SCC errors when using 4 taps is
> not needed.
>
> * Changes since v1
> - Use intermediate variable use_4tap to simplify check.
> ---
> drivers/mmc/host/renesas_sdhi_core.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/mmc/host/renesas_sdhi_core.c
> b/drivers/mmc/host/renesas_sdhi_core.c
> index 777e32b0e410e850..4427f0e7058f3ee5 100644
> --- a/drivers/mmc/host/renesas_sdhi_core.c
> +++ b/drivers/mmc/host/renesas_sdhi_core.c
> @@ -443,6 +443,19 @@ static int renesas_sdhi_select_tuning(struct
> tmio_mmc_host *host)
> static bool renesas_sdhi_check_scc_error(struct tmio_mmc_host *host)
> {
> struct renesas_sdhi *priv = host_to_priv(host);
> + bool use_4tap = host->pdata->flags & TMIO_MMC_HAVE_4TAP_HS400;
> +
> + /*
> +* Skip checking SCC errors when running on 4 taps in HS400 mode as
> +* any retuning would still result in the same 4 taps being used.
> +*/
> + 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;
> +
> + if (host->mmc->doing_retune)
To keep the tuning internals close to the mmc core, please add a new
inline function in include/linux/mmc/host.h to give the value of the
"doing_retune", something along the lines of this:
/* Allows hosts to distinguish between re-tuning and first time tuning. */
static inline bool mmc_doing_retune(struct mmc_host *host)
{
return host->doing_retune == 1;
}
And of course in separate patch.
[...]
Otherwise this looks okay to me.
Kind regards
Uffe
Re: [RFT 5/8] pinctrl: sh-pfc: r8a77990: Add VIN pins, groups and functions
Hi Jacopo,
On Mon, Aug 20, 2018 at 12:17 PM Jacopo Mondi wrote:
> From: Takeshi Kihara
>
> This patch adds VIN{4,5} pins, groups and functions to the R8A77990 SoC.
>
> Signed-off-by: Takeshi Kihara
> Signed-off-by: Jacopo Mondi
Thanks for your patch!
> --- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> @@ -1982,6 +1982,446 @@ static const unsigned int usb30_id_mux[] = {
> USB3HS0_ID_MARK,
> };
>
> +/* - VIN4
> --- */
> +static const unsigned int vin4_data8_a_pins[] = {
> + RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
> + RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
> + RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
> + RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
> +};
> +
> +static const unsigned int vin4_data8_a_mux[] = {
> + VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
> + VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
> + VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
> + VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
> +};
> +
> +static const unsigned int vin4_data10_a_pins[] = {
> + RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
> + RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
> + RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
> + RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
> + RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
> +};
> +
> +static const unsigned int vin4_data10_a_mux[] = {
> + VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
> + VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
> + VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
> + VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
> + VI4_DATA8_MARK, VI4_DATA9_MARK,
> +};
Can you please use union vin_data and VIN_DATA_PIN_GROUP(), to reduce
redundancies, cfr. commit 9942a5b52990b8d5 ("pinctrl: sh-pfc: r8a7795:
Deduplicate VIN4 pin definitions")?
Or do you want to do that in a follow-up patch (which means more
review work)?
> +static const unsigned int vin4_data8_sft8_pins[] = {
> + RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
> + RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
> + RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
> + RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
> +};
R-Car H3 and M3-W don't have the data8_sft8 groups yet (the BSP has).
IIRC, that's due to rcar-vin not yet supporting that mode. Niklas?
> +static const unsigned int vin5_sync_a_pins[] = {
> + /* HSYNC_N, VSYNC_N */
> + RCAR_GP_PIN(1, 8), RCAR_GP_PIN(1, 9),
> +};
> +
> +static const unsigned int vin5_sync_a_mux[] = {
> + VI5_HSYNC_N_A_MARK, VI5_VSYNC_N_A_MARK,
> +};
> +
> +static const unsigned int vin5_field_a_pins[] = {
> + RCAR_GP_PIN(1, 10),
> +};
> +
> +static const unsigned int vin5_field_a_mux[] = {
> + VI5_FIELD_A_MARK,
> +};
> +
> +static const unsigned int vin5_clkenb_a_pins[] = {
> + RCAR_GP_PIN(0, 1),
> +};
> +
> +static const unsigned int vin5_clkenb_a_mux[] = {
> + VI5_CLKENB_A_MARK,
> +};
"A" groups without "B" groups? Usually we drop the "_A" suffix in that case.
They're actually named like that in hardware user manual rev. 1.00 (and no
update in the errata)?
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 2/2] pinctrl: sh-pfc: r8a77965: add Audio SSI pin support
On Tue, Aug 28, 2018 at 6:37 AM Nguyen An Hoan wrote:
> From: Hoan Nguyen An
>
> Add Audio SSI pin support for r8a77965
>
> Signed-off-by: Hoan Nguyen An
Reviewed-by: Geert Uytterhoeven
i.e. will queue in sh-pfc-for-v4.20.
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] pinctrl: sh-pfc: r8a77965: add Audio clock pin support
Hi Hoan,
On Tue, Aug 28, 2018 at 6:37 AM Nguyen An Hoan wrote:
> From: Hoan Nguyen An
>
> Add Audio clock pin support for r8a77965
>
> Signed-off-by: Hoan Nguyen An
Thanks for the update!
Reviewed-by: Geert Uytterhoeven
i.e. will queue in sh-pfc-for-v4.20.
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] clk: renesas: cpg-mssr: Add R7S9210 support
Hi Chris,
On Tue, Aug 28, 2018 at 12:13 AM Chris Brandt wrote:
> On Monday, August 27, 2018 1, Geert Uytterhoeven wrote:
> > Given the differences, and the limited amount of RAM on RZ/A2, I think you
> > would be better off with a separate renesas-cpg-stbcr driver, and an
> > r7s9210-cpg-stbcr counterpart.
>
> I went and measured the amount of RAM being used by the driver
> (allocated during boot when the driver is loaded and probed), and it's only
> 8KB.
> That's not really much compared to other drivers and subsystems being
> loaded in the system. Of course RZ/A tries to be RAM sensitive...but 8KB
> for a clock driver is not my biggest concern.
>
> So with that said, I could add in a driver option to not register the
> reset controller. And, also make a macro so users can specify "36" instead
> of "306" in the DT.
> And then, I no longer have to worry about duplicate code (2 drivers do
> almost the same thing).
>
> What do you think?
OK for me.
Changing the print format in the debug prints is probably too much work,
but those matter less than the clock numbers in the DTS.
> Were you expecting the driver to allocate more than 8K of RAM on boot?
I was thinking mainly about code size. But you're right, (a) you use XIP
(with plenty of FLASH?), and (b) RAM size should be similar for a combined
and a separate driver.
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
