Re: clk: renesas: rcar-gen3: Fix error return code in cpg_sd_clock_recalc_rate
On 07/17, Geert Uytterhoeven wrote: > Hi Wolfram, > > On Mon, Jul 17, 2017 at 11:18 AM, Wolfram Sangwrote: > >> >> In .recalc_rate of struct clk_ops, it is desirable to return 0 if an > >> >> error occurs, but -EINVAL is returned. This patch fixes it. > >> >> > >> >> Fixes: 5b1defde7054 ("clk: renesas: cpg-mssr: Extract common R-Car Gen3 > >> >> support code") > >> >> Signed-off-by: Takeshi Kihara > >> >> Signed-off-by: Yoshihiro Kaneko > >> > > >> > Reviewed-by: Wolfram Sang > >> > >> Why is it desirable to return 0 if an error occurs? Because the return > >> type is > >> unsigned long? > > > > Yes, I'd think so. Instead of an arbitrary high, kind-of-random, number, > > just > > return 0 which also indicates that something unexpected happened? Also, all > > other drivers return zero in an error case (did some quick coccinelle > > grepping before). > > OK. > > >> Is this routine allowed to fail? I don't see any handling of zero by > >> its callers. > > > > From clk-provider.h: > > > > * @recalc_rate Recalculate the rate of this clock, by querying hardware. > > The > > * parent rate is an input parameter. It is up to the caller > > to > > * ensure that the prepare_mutex is held across this call. > > * Returns the calculated rate. Optional, but recommended - if > > * this op is not set then clock rate will be initialized to 0. > > > > What would be the benefit of keeping -EINVAL in an unsigned long? > > I do not mean that -EINVAL is correct. Obviously it isn't. But blindly > replacing -EINVAL by zero may not be the right solution neither. > > If recalc_rate cannot return an error value, perhaps there is a good reason > for that? Presumably you can always figure out what the rate of the clk is, or at least return the rate of the parent clk if it can't be figured out for some odd reason. In this case it looks like we don't have some divider mapping? Why not make it a WARN_ON() and return 0? Then we can fix the warning by adding the appropriate mapping in the table and not return some really large frequency. > > I see there's a similar check in cpg_sd_clock_enable(), so the clock also > cannot be enabled if this condition is met? > > When does this happen? If the firmware leaves a invalid/unsupported setting > in the register? If we can't recover from that, perhaps the clock's probe > should just fail instead? > > It looks like the only writer of that field is cpg_sd_clock_set_rate(), > which always writes a valid/supported value. Is it guaranteed that this > function is always called first? > If yes, the checks can just be removed instead? > This also works. I'm dropping this patch from my queue for now. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 14/14] [media] fix warning on v4l2_subdev_call() result interpreted as bool
On Mon, Jul 17, 2017 at 4:35 PM, Hans Verkuilwrote: > On 17/07/17 16:26, Arnd Bergmann wrote: >> Let me try again without ccache for now and see what warnings remain. >> We can find a solution for those first, and then decide how to deal with >> ccache. > > Sounds good. > > I'm OK with applying this if there is no other way to prevent these warnings. Small update: I noticed that having ccache being the default compiler even with CCACHE_DISABLE=1 causes a lot of these warnings. Completely taking ccache out of the picture however seems to have eliminated the warnings about v4l2_subdev_call() and other silly warnings, but not the interesting ones in the -Wint-in-bool-context category. Arnd
[PATCH V4 2/2] mfd: Add ROHM BD9571MWV-M MFD PMIC driver
Add the MFD part of the ROHM BD9571MWV-M PMIC driver and MAINTAINERS entry. The MFD part only specifies the regmap bits for the PMIC and binds the subdevs together. Signed-off-by: Marek VasutCc: linux-ker...@vger.kernel.org Cc: Geert Uytterhoeven Cc: Lee Jones --- V2: - Change BD9571MWV_AVS_VD09_VID0,1,2,3 to BD9571MWV_AVS_VD09_VID(n) - Change BD9571MWV_AVS_DVFS_VID0,1,2,3 to BD9571MWV_AVS_DVFS_VID(n) - Make the AVS_VD09 range RW, so it can be used by the regulator driver for the VD09 regulator - Report the regmap read return values when attempting to read ID registers fails V3: No change V4: select REGMAP_IRQ --- MAINTAINERS | 11 ++ drivers/mfd/Kconfig | 14 +++ drivers/mfd/Makefile | 1 + drivers/mfd/bd9571mwv.c | 230 ++ include/linux/mfd/bd9571mwv.h | 115 + 5 files changed, 371 insertions(+) create mode 100644 drivers/mfd/bd9571mwv.c create mode 100644 include/linux/mfd/bd9571mwv.h diff --git a/MAINTAINERS b/MAINTAINERS index 0b6ed8eb58b0..f369c1cb287e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11291,6 +11291,17 @@ L: linux-ser...@vger.kernel.org S: Odd Fixes F: drivers/tty/serial/rp2.* +ROHM MULTIFUNCTION BD9571MWV-M PMIC DEVICE DRIVERS +M: Marek Vasut +L: linux-ker...@vger.kernel.org +L: linux-renesas-soc@vger.kernel.org +S: Supported +F: drivers/mfd/bd9571mwv.c +F: drivers/regulator/bd9571mwv-regulator.c +F: drivers/gpio/gpio-bd9571mwv.c +F: include/linux/mfd/bd9571mwv.h +F: Documentation/devicetree/bindings/mfd/bd9571mwv.txt + ROSE NETWORK LAYER M: Ralf Baechle L: linux-h...@vger.kernel.org diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 94ad2c1c3d90..667665926fb3 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -133,6 +133,20 @@ config MFD_BCM590XX help Support for the BCM590xx PMUs from Broadcom +config MFD_BD9571MWV + tristate "ROHM BD9571MWV PMIC" + select MFD_CORE + select REGMAP_I2C + select REGMAP_IRQ + depends on I2C + help + Support for the ROHM BD9571MWV PMIC, which contains single + voltage regulator, voltage sampling units, GPIO block and + watchdog block. + + This driver can also be built as a module. If so, the module + will be called bd9571mwv. + config MFD_AC100 tristate "X-Powers AC100" select MFD_CORE diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index 080793b3fd0e..db15df3d9e8d 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -10,6 +10,7 @@ obj-$(CONFIG_MFD_ACT8945A)+= act8945a.o obj-$(CONFIG_MFD_SM501)+= sm501.o obj-$(CONFIG_MFD_ASIC3)+= asic3.o tmio_core.o obj-$(CONFIG_MFD_BCM590XX) += bcm590xx.o +obj-$(CONFIG_MFD_BD9571MWV)+= bd9571mwv.o cros_ec_core-objs := cros_ec.o cros_ec_core-$(CONFIG_ACPI)+= cros_ec_acpi_gpe.o obj-$(CONFIG_MFD_CROS_EC) += cros_ec_core.o diff --git a/drivers/mfd/bd9571mwv.c b/drivers/mfd/bd9571mwv.c new file mode 100644 index ..64e088dfe7b0 --- /dev/null +++ b/drivers/mfd/bd9571mwv.c @@ -0,0 +1,230 @@ +/* + * ROHM BD9571MWV-M MFD driver + * + * Copyright (C) 2017 Marek Vasut + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed "as is" WITHOUT ANY WARRANTY of any + * kind, whether expressed or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License version 2 for more details. + * + * Based on the TPS65086 driver + */ + +#include +#include +#include +#include + +#include + +static const struct mfd_cell bd9571mwv_cells[] = { + { .name = "bd9571mwv-regulator", }, + { .name = "bd9571mwv-gpio", }, +}; + +static const struct regmap_range bd9571mwv_readable_yes_ranges[] = { + regmap_reg_range(BD9571MWV_VENDOR_CODE, BD9571MWV_PRODUCT_REVISION), + regmap_reg_range(BD9571MWV_AVS_SET_MONI, BD9571MWV_AVS_DVFS_VID(3)), + regmap_reg_range(BD9571MWV_VD18_VID, BD9571MWV_VD33_VID), + regmap_reg_range(BD9571MWV_DVFS_VINIT, BD9571MWV_DVFS_VINIT), + regmap_reg_range(BD9571MWV_DVFS_SETVMAX, BD9571MWV_DVFS_MONIVDAC), + regmap_reg_range(BD9571MWV_GPIO_IN, BD9571MWV_GPIO_IN), + regmap_reg_range(BD9571MWV_GPIO_INT, BD9571MWV_GPIO_INTMASK), + regmap_reg_range(BD9571MWV_INT_INTREQ, BD9571MWV_INT_INTMASK), +}; + +static const struct regmap_access_table bd9571mwv_readable_table = { + .yes_ranges = bd9571mwv_readable_yes_ranges, +
Re: [PATCH V3 2/2] mfd: Add ROHM BD9571MWV-M MFD PMIC driver
On 07/10/2017 05:33 PM, Geert Uytterhoeven wrote: > Hi Marek, > > On Tue, May 2, 2017 at 2:18 PM, Marek Vasutwrote: >> Add the MFD part of the ROHM BD9571MWV-M PMIC driver and MAINTAINERS >> entry. The MFD part only specifies the regmap bits for the PMIC and >> binds the subdevs together. >> >> Signed-off-by: Marek Vasut >> Cc: linux-ker...@vger.kernel.org >> Cc: Geert Uytterhoeven >> Cc: Lee Jones > >> --- a/drivers/mfd/Kconfig >> +++ b/drivers/mfd/Kconfig >> @@ -133,6 +133,19 @@ config MFD_BCM590XX >> help >> Support for the BCM590xx PMUs from Broadcom >> >> +config MFD_BD9571MWV >> + tristate "ROHM BD9571MWV PMIC" >> + select MFD_CORE >> + select REGMAP_I2C > > Missing "select REGMAP_IRQ". > > Else it fails with: Added -- Best regards, Marek Vasut
[PATCH V4 1/2] mfd: Add ROHM BD9571MWV-M PMIC DT bindings
Add DT bindings for the ROHM BD9571MWV-M PMIC. This PMIC has the following features: - multiple voltage monitors for 1V8, 2V5, 3V3 voltage rail - one voltage regulator for DVFS - two GPIOs Signed-off-by: Marek VasutCc: devicet...@vger.kernel.org Cc: Rob Herring Cc: Geert Uytterhoeven Cc: linux-renesas-soc@vger.kernel.org Acked-by: Rob Herring --- V2: - Drop the compatible = "regulator-fixed" from the binding example, it should not be there. - List the VD09 regulator V3: Replace bd9571@30 with pmic@30 V4: No changes --- .../devicetree/bindings/mfd/bd9571mwv.txt | 49 ++ 1 file changed, 49 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/bd9571mwv.txt diff --git a/Documentation/devicetree/bindings/mfd/bd9571mwv.txt b/Documentation/devicetree/bindings/mfd/bd9571mwv.txt new file mode 100644 index ..9ab216a851d5 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/bd9571mwv.txt @@ -0,0 +1,49 @@ +* ROHM BD9571MWV Power Management Integrated Circuit (PMIC) bindings + +Required properties: + - compatible : Should be "rohm,bd9571mwv". + - reg : I2C slave address. + - interrupt-parent: Phandle to the parent interrupt controller. + - interrupts : The interrupt line the device is connected to. + - interrupt-controller: Marks the device node as an interrupt controller. + - #interrupt-cells: The number of cells to describe an IRQ, should be 2. + The first cell is the IRQ number. + The second cell is the flags, encoded as trigger + masks from ../interrupt-controller/interrupts.txt. + - gpio-controller : Marks the device node as a GPIO Controller. + - #gpio-cells : Should be two. The first cell is the pin number and +the second cell is used to specify flags. +See ../gpio/gpio.txt for more information. + - regulators: : List of child nodes that specify the regulator +initialization data. Child nodes must be named +after their hardware counterparts: +- vd09 +- vd18 +- vd25 +- vd33 +- dvfs + Each child node is defined using the standard + binding for regulators. + +Example: + + pmic: pmic@30 { + compatible = "rohm,bd9571mwv"; + reg = <0x30>; + interrupt-parent = <>; + interrupts = <0 IRQ_TYPE_LEVEL_LOW>; + interrupt-controller; + #interrupt-cells = <2>; + gpio-controller; + #gpio-cells = <2>; + + regulators { + dvfs: dvfs { + regulator-name = "dvfs"; + regulator-min-microvolt = <75>; + regulator-max-microvolt = <103>; + regulator-boot-on; + regulator-always-on; + }; + }; + }; -- 2.11.0
[renesas-drivers:topic/renesas-overlays 1/86] drivers//of/configfs.c:48:2: error: implicit declaration of function 'of_fdt_unflatten_tree'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git topic/renesas-overlays head: 8361d7e7432d1937f94e1863211fb3f852e37f36 commit: 1ba23467c1d052c0b5c35436c034f0fb7103eeaf [1/86] OF: DT-Overlay configfs interface (v7) config: sparc64-allmodconfig (attached as .config) compiler: sparc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 1ba23467c1d052c0b5c35436c034f0fb7103eeaf # save the attached .config to linux build tree make.cross ARCH=sparc64 All errors (new ones prefixed by >>): drivers//of/configfs.c: In function 'create_overlay': >> drivers//of/configfs.c:48:2: error: implicit declaration of function >> 'of_fdt_unflatten_tree' [-Werror=implicit-function-declaration] of_fdt_unflatten_tree(blob, NULL, >overlay); ^ cc1: some warnings being treated as errors vim +/of_fdt_unflatten_tree +48 drivers//of/configfs.c 42 43 static int create_overlay(struct cfs_overlay_item *overlay, void *blob) 44 { 45 int err; 46 47 /* unflatten the tree */ > 48 of_fdt_unflatten_tree(blob, NULL, >overlay); 49 if (overlay->overlay == NULL) { 50 pr_err("%s: failed to unflatten tree\n", __func__); 51 err = -EINVAL; 52 goto out_err; 53 } 54 pr_debug("%s: unflattened OK\n", __func__); 55 56 /* mark it as detached */ 57 of_node_set_flag(overlay->overlay, OF_DETACHED); 58 59 /* perform resolution */ 60 err = of_resolve_phandles(overlay->overlay); 61 if (err != 0) { 62 pr_err("%s: Failed to resolve tree\n", __func__); 63 goto out_err; 64 } 65 pr_debug("%s: resolved OK\n", __func__); 66 67 err = of_overlay_create(overlay->overlay); 68 if (err < 0) { 69 pr_err("%s: Failed to create overlay (err=%d)\n", 70 __func__, err); 71 goto out_err; 72 } 73 overlay->ov_id = err; 74 75 out_err: 76 return err; 77 } 78 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
[PATCH] watchdog: asm9260_wdt: don't round closest with get_timeleft
We should never return more time left than there actually is. So, switch to a plain divider instead of DIV_ROUND_CLOSEST. Signed-off-by: Wolfram Sang--- This is similar to a patch for the renesas-rwdt[1]. I think it makes sense to remove this pattern from the whole subsystem, if we can agree on the behaviour stated in the patch description. So, this is the other driver using DIV_ROUND_CLOSEST. Note: This driver and the lpc18xx_wdt.c extremly likely drive the same IP core. They would ideally be merged. [1] https://patchwork.kernel.org/patch/9845459/ drivers/watchdog/asm9260_wdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/asm9260_wdt.c b/drivers/watchdog/asm9260_wdt.c index 53da001f0838ee..f40dd71c904bef 100644 --- a/drivers/watchdog/asm9260_wdt.c +++ b/drivers/watchdog/asm9260_wdt.c @@ -82,7 +82,7 @@ static unsigned int asm9260_wdt_gettimeleft(struct watchdog_device *wdd) counter = ioread32(priv->iobase + HW_WDTV); - return DIV_ROUND_CLOSEST(counter, priv->wdt_freq); + return counter / priv->wdt_freq; } static int asm9260_wdt_updatetimeout(struct watchdog_device *wdd) -- 2.11.0
[PATCH v8 2/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver
A V4L2 driver for Renesas R-Car MIPI CSI-2 receiver. The driver supports the rcar-vin driver on R-Car Gen3 SoCs where separate CSI-2 hardware blocks are connected between the video sources and the video grabbers (VIN). Driver is based on a prototype by Koji Matsuoka in the Renesas BSP. Signed-off-by: Niklas Söderlund--- drivers/media/platform/rcar-vin/Kconfig | 12 + drivers/media/platform/rcar-vin/Makefile| 1 + drivers/media/platform/rcar-vin/rcar-csi2.c | 822 3 files changed, 835 insertions(+) create mode 100644 drivers/media/platform/rcar-vin/rcar-csi2.c diff --git a/drivers/media/platform/rcar-vin/Kconfig b/drivers/media/platform/rcar-vin/Kconfig index af4c98b44d2e22cb..6875f30c1ae42631 100644 --- a/drivers/media/platform/rcar-vin/Kconfig +++ b/drivers/media/platform/rcar-vin/Kconfig @@ -1,3 +1,15 @@ +config VIDEO_RCAR_CSI2 + tristate "R-Car MIPI CSI-2 Receiver" + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF + depends on ARCH_RENESAS || COMPILE_TEST + select V4L2_FWNODE + ---help--- + Support for Renesas R-Car MIPI CSI-2 receiver. + Supports R-Car Gen3 SoCs. + + To compile this driver as a module, choose M here: the + module will be called rcar-csi2. + config VIDEO_RCAR_VIN tristate "R-Car Video Input (VIN) Driver" depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF && HAS_DMA && MEDIA_CONTROLLER diff --git a/drivers/media/platform/rcar-vin/Makefile b/drivers/media/platform/rcar-vin/Makefile index 48c5632c21dc060b..5ab803d3e7c1aa57 100644 --- a/drivers/media/platform/rcar-vin/Makefile +++ b/drivers/media/platform/rcar-vin/Makefile @@ -1,3 +1,4 @@ rcar-vin-objs = rcar-core.o rcar-dma.o rcar-v4l2.o +obj-$(CONFIG_VIDEO_RCAR_CSI2) += rcar-csi2.o obj-$(CONFIG_VIDEO_RCAR_VIN) += rcar-vin.o diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c b/drivers/media/platform/rcar-vin/rcar-csi2.c new file mode 100644 index ..09a78dce29725a55 --- /dev/null +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c @@ -0,0 +1,822 @@ +/* + * Driver for Renesas R-Car MIPI CSI-2 Receiver + * + * Copyright (C) 2017 Renesas Electronics Corp. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +/* Register offsets and bits */ + +/* Control Timing Select */ +#define TREF_REG 0x00 +#define TREF_TREF (1 << 0) + +/* Software Reset */ +#define SRST_REG 0x04 +#define SRST_SRST (1 << 0) + +/* PHY Operation Control */ +#define PHYCNT_REG 0x08 +#define PHYCNT_SHUTDOWNZ (1 << 17) +#define PHYCNT_RSTZ(1 << 16) +#define PHYCNT_ENABLECLK (1 << 4) +#define PHYCNT_ENABLE_3(1 << 3) +#define PHYCNT_ENABLE_2(1 << 2) +#define PHYCNT_ENABLE_1(1 << 1) +#define PHYCNT_ENABLE_0(1 << 0) + +/* Checksum Control */ +#define CHKSUM_REG 0x0c +#define CHKSUM_ECC_EN (1 << 1) +#define CHKSUM_CRC_EN (1 << 0) + +/* + * Channel Data Type Select + * VCDT[0-15]: Channel 1 VCDT[16-31]: Channel 2 + * VCDT2[0-15]: Channel 3 VCDT2[16-31]: Channel 4 + */ +#define VCDT_REG 0x10 +#define VCDT2_REG 0x14 +#define VCDT_VCDTN_EN (1 << 15) +#define VCDT_SEL_VC(n) (((n) & 0x3) << 8) +#define VCDT_SEL_DTN_ON(1 << 6) +#define VCDT_SEL_DT(n) (((n) & 0x3f) << 0) + +/* Frame Data Type Select */ +#define FRDT_REG 0x18 + +/* Field Detection Control */ +#define FLD_REG0x1c +#define FLD_FLD_NUM(n) (((n) & 0xff) << 16) +#define FLD_FLD_EN4(1 << 3) +#define FLD_FLD_EN3(1 << 2) +#define FLD_FLD_EN2(1 << 1) +#define FLD_FLD_EN (1 << 0) + +/* Automatic Standby Control */ +#define ASTBY_REG 0x20 + +/* Long Data Type Setting 0 */ +#define LNGDT0_REG 0x28 + +/* Long Data Type Setting 1 */ +#define LNGDT1_REG 0x2c + +/* Interrupt Enable */ +#define INTEN_REG 0x30 + +/* Interrupt Source Mask */ +#define INTCLOSE_REG 0x34 + +/* Interrupt Status Monitor */ +#define INTSTATE_REG 0x38 + +/* Interrupt Error Status Monitor */ +#define INTERRSTATE_REG
[PATCH v8 1/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver documentation
Documentation for Renesas R-Car MIPI CSI-2 receiver. The CSI-2 receivers are located between the video sources (CSI-2 transmitters) and the video grabbers (VIN) on Gen3 of Renesas R-Car SoC. Each CSI-2 device is connected to more then one VIN device which simultaneously can receive video from the same CSI-2 device. Each VIN device can also be connected to more then one CSI-2 device. The routing of which link are used are controlled by the VIN devices. There are only a few possible routes which are set by hardware limitations, which are different for each SoC in the Gen3 family. To work with the limitations of routing possibilities it is necessary for the DT bindings to describe which VIN device is connected to which CSI-2 device. This is why port 1 needs to to assign reg numbers for each VIN device that be connected to it. To setup and to know which links are valid for each SoC is the responsibility of the VIN driver since the register to configure it belongs to the VIN hardware. Signed-off-by: Niklas Söderlund--- .../devicetree/bindings/media/rcar-csi2.txt| 118 + 1 file changed, 118 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/rcar-csi2.txt diff --git a/Documentation/devicetree/bindings/media/rcar-csi2.txt b/Documentation/devicetree/bindings/media/rcar-csi2.txt new file mode 100644 index ..c298a7d821153219 --- /dev/null +++ b/Documentation/devicetree/bindings/media/rcar-csi2.txt @@ -0,0 +1,118 @@ +Renesas R-Car MIPI CSI-2 + + +The rcar-csi2 device provides MIPI CSI-2 capabilities for the Renesas R-Car +family of devices. It is to be used in conjunction with the R-Car VIN module, +which provides the video capture capabilities. + +Mandatory properties + + - compatible: Must be one or more of the following + - "renesas,r8a7795-csi2" for the R8A7795 device. + - "renesas,r8a7796-csi2" for the R8A7796 device. + - "renesas,rcar-gen3-csi2" for a generic R-Car Gen3 compatible device. + + When compatible with a generic version nodes must list the + SoC-specific version corresponding to the platform first + followed by the generic version. + + - reg: the register base and size for the device registers + - interrupts: the interrupt for the device + - clocks: Reference to the parent clock + +The device node shall contain two 'port' child nodes according to the +bindings defined in Documentation/devicetree/bindings/media/ +video-interfaces.txt. Port 0 shall connect the node that is the video +source for to the CSI-2. Port 1 shall connect all the R-Car VIN +modules, which can make use of the CSI-2 module. + +- Port 0 - Video source (Mandatory) + - Reg 0 - sub-node describing the endpoint that is the video source + +- Port 1 - VIN instances (Mandatory for all VIN present in the SoC) + - Reg 0 - sub-node describing the endpoint that is VIN0 + - Reg 1 - sub-node describing the endpoint that is VIN1 + - Reg 2 - sub-node describing the endpoint that is VIN2 + - Reg 3 - sub-node describing the endpoint that is VIN3 + - Reg 4 - sub-node describing the endpoint that is VIN4 + - Reg 5 - sub-node describing the endpoint that is VIN5 + - Reg 6 - sub-node describing the endpoint that is VIN6 + - Reg 7 - sub-node describing the endpoint that is VIN7 + +Example: + +/* SoC properties */ + +csi20: csi2@fea8 { +compatible = "renesas,r8a7796-csi2"; +reg = <0 0xfea8 0 0x1>; +interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>; +clocks = < CPG_MOD 714>; +power-domains = < R8A7796_PD_ALWAYS_ON>; +status = "disabled"; + +ports { +#address-cells = <1>; +#size-cells = <0>; + +port@1 { +#address-cells = <1>; +#size-cells = <0>; + +reg = <1>; + +csi20vin0: endpoint@0 { +reg = <0>; +remote-endpoint = <>; +}; +csi20vin1: endpoint@1 { +reg = <1>; +remote-endpoint = <>; +}; +csi20vin2: endpoint@2 { +reg = <2>; +remote-endpoint = <>; +}; +csi20vin3: endpoint@3 { +reg = <3>; +remote-endpoint = <>; +}; +csi20vin4: endpoint@4 { +
[PATCH v8 0/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 support
Hi, This is the latest incarnation of R-Car MIPI CSI-2 receiver driver. It's based on top of the media-tree and are tested on Renesas Salvator-X together with the out of tree patches for rcar-vin to add support for Gen3 VIN and a driver for ADV7482. If anyone is interested to test video grabbing using these out of tree patches please see [1]. It depends on the patches: - [PATCH v4 0/3] v4l2-async: add subnotifier registration for subdevices Changes since v7: - Rebase on top of the latest incremental async patches. - Fix comments on DT documentation. - Use v4l2_ctrl_g_ctrl_int64() instead of v4l2_g_ext_ctrls(). - Handle try formats in .set_fmt() and .get_fmt(). - Don't call v4l2_device_register_subdev_nodes() as this is not needed with the complete() callbacks synchronized. - Fix line over 80 chars. - Fix varies spelling mistakes. Changes since v6: - Rebased on top of Sakaris fwnode patches. - Changed of RCAR_CSI2_PAD_MAX to NR_OF_RCAR_CSI2_PAD. - Remove assumtion about unkown medis bus type, thanks Sakari for pointing this out. - Created table for supported format information instead of scattering this information around the driver, thanks Sakari! - Small newline fixes and reduce some indentation levels. Changes since v5: - Make use of the incremental async subnotifer and helper to map DT endpoint to media pad number. This moves functionality which previously in the Gen3 patches for R-Car VIN driver to this R-Car CSI-2 driver. This is done in preparation to support the ADV7482 driver in development by Kieran which will register more then one subdevice and the CSI-2 driver needs to cope wit this. Further more it prepares the driver for another use-case where more then one subdevice is present upstream for the CSI-2. - Small cleanups. - Add explicit include for linux/io.h, thanks Kieran. Changes since v4: - Match SoC part numbers and drop trailing space in documentation, thanks Geert for pointing this out. - Clarify that the driver is a CSI-2 receiver by supervised s/interface/receiver/, thanks Laurent. - Add entries in Kconfig and Makefile alphabetically instead of append. - Rename struct rcar_csi2 member swap to lane_swap. - Remove macros to wrap calls to dev_{dbg,info,warn,err}. - Add wrappers for ioread32 and iowrite32. - Remove unused interrupt handler, but keep checking in probe that there are a interrupt define in DT. - Rework how to wait for LP-11 state, thanks Laurent for the great idea! - Remove unneeded delay in rcar_csi2_reset() - Remove check for duplicated lane id:s from DT parsing. Broken out to a separate patch adding this check directly to v4l2_of_parse_endpoint(). - Fixed rcar_csi2_start() to ask it's source subdevice for information about pixel rate and frame format. With this change having {set,get}_fmt operations became redundant, it was only used for figuring out this out so dropped them. - Tabulated frequency settings map. - Dropped V4L2_SUBDEV_FL_HAS_DEVNODE it should never have been set. - Switched from MEDIA_ENT_F_ATV_DECODER to MEDIA_ENT_F_PROC_VIDEO_PIXEL_FORMATTER as entity function. I can't find a more suitable function, and what the hardware do is to fetch video from an external chip and passes it on to a another SoC internal IP it's sort of a formatter. - Break out DT documentation and code in two patches. Changes since v3: - Update DT binding documentation with input from Geert Uytterhoeven, thanks! Changes since v2: - Added media control pads as this is needed by the new rcar-vin driver. - Update DT bindings after review comments and to add r8a7796 support. - Add get_fmt handler. - Fix media bus format error s/YUYV8/UYVY8/ Changes since v1: - Drop dependency on a pad aware s_stream operation. - Use the DT bindings format "renesas,-", thanks Geert for pointing this out. 1. http://elinux.org/R-Car/Tests:rcar-vin Niklas Söderlund (2): media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver documentation media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver .../devicetree/bindings/media/rcar-csi2.txt| 118 +++ drivers/media/platform/rcar-vin/Kconfig| 12 + drivers/media/platform/rcar-vin/Makefile | 1 + drivers/media/platform/rcar-vin/rcar-csi2.c| 822 + 4 files changed, 953 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/rcar-csi2.txt create mode 100644 drivers/media/platform/rcar-vin/rcar-csi2.c -- 2.13.1
[PATCH v4 3/3] v4l: async: add subnotifier to subdevices
Add a subdevice specific notifier which can be used by a subdevice driver to compliment the master device notifier to extend the subdevice discovery. The master device registers the subdevices closest to itself in its notifier while the subdevice(s) register notifiers for their closest neighboring devices. Subdevice drivers configures a notifier at probe time which are registered by the v4l2-async framework once the subdevice itself is register, since it's only at this point the v4l2_dev is available to the subnotifier. Using this incremental approach two problems can be solved: 1. The master device no longer has to care how many devices exist in the pipeline. It only needs to care about its closest subdevice and arbitrary long pipelines can be created without having to adapt the master device for each case. 2. Subdevices which are represented as a single DT node but register more than one subdevice can use this to improve the pipeline discovery, since the subdevice driver is the only one who knows which of its subdevices is linked with which subdevice of a neighboring DT node. To allow subdevices to provide its own list of subdevices to the v4l2-async framework v4l2_async_subdev_register_notifier() is added. This new function must be called before the subdevice itself is registered with the v4l2-async framework using v4l2_async_register_subdev(). Signed-off-by: Niklas Söderlund--- Documentation/media/kapi/v4l2-subdev.rst | 12 +++ drivers/media/v4l2-core/v4l2-async.c | 134 +-- include/media/v4l2-async.h | 25 ++ include/media/v4l2-subdev.h | 5 ++ 4 files changed, 168 insertions(+), 8 deletions(-) diff --git a/Documentation/media/kapi/v4l2-subdev.rst b/Documentation/media/kapi/v4l2-subdev.rst index e1f0b726e438f963..5957176965a6a3ef 100644 --- a/Documentation/media/kapi/v4l2-subdev.rst +++ b/Documentation/media/kapi/v4l2-subdev.rst @@ -262,6 +262,18 @@ is called. After all subdevices have been located the .complete() callback is called. When a subdevice is removed from the system the .unbind() method is called. All three callbacks are optional. +Subdevice drivers might in turn register subnotifier objects with an +array of other subdevice descriptors that the subdevice needs for its +own operation. Subnotifiers are an extension of the bridge drivers +notifier to allow for a incremental registering and matching of +subdevices. This is useful when a driver only has information about +which subdevice is closest to itself and would require knowledge from the +driver of that subdevice to know which other subdevice(s) lie beyond. +By registering subnotifiers drivers can incrementally move the subdevice +matching down the chain of drivers. This is performed using the +:c:func:`v4l2_async_subdev_register_notifier` call which must be performed +before registering the subdevice using :c:func:`v4l2_async_register_subdev`. + V4L2 sub-device userspace API - diff --git a/drivers/media/v4l2-core/v4l2-async.c b/drivers/media/v4l2-core/v4l2-async.c index 8fc84f7962386ddd..558fb3ec07e7fba8 100644 --- a/drivers/media/v4l2-core/v4l2-async.c +++ b/drivers/media/v4l2-core/v4l2-async.c @@ -100,6 +100,61 @@ static struct v4l2_async_subdev *v4l2_async_belongs(struct v4l2_async_notifier * return NULL; } +static int v4l2_async_notifier_complete(struct v4l2_async_notifier *notifier) +{ + struct v4l2_subdev *sd, *tmp; + + if (!notifier->num_subdevs) + return 0; + + list_for_each_entry_safe(sd, tmp, >done, async_list) { + v4l2_async_notifier_complete(>subnotifier); + } + + if (notifier->complete) + return notifier->complete(notifier); + + return 0; +} + +static bool +v4l2_async_is_notifier_complete(struct v4l2_async_notifier *notifier) +{ + struct v4l2_subdev *sd, *tmp; + + if (!list_empty(>waiting)) + return false; + + list_for_each_entry_safe(sd, tmp, >done, async_list) { + /* Don't consider empty subnotifiers */ + if (!sd->subnotifier.num_subdevs) + continue; + + if (!v4l2_async_is_notifier_complete(>subnotifier)) + return false; + } + + return true; +} + +static int +v4l2_async_try_complete_notifier(struct v4l2_async_notifier *notifier) +{ + struct v4l2_async_notifier *root = notifier; + + while (root->subnotifier) { + root = subnotifier_to_v4l2_subdev(root)->notifier; + /* No root notifier can be found at this time */ + if (!root) + return 0; + } + + if (v4l2_async_is_notifier_complete(root)) + return v4l2_async_notifier_complete(root); + + return 0; +} + static int v4l2_async_test_notify(struct v4l2_async_notifier *notifier,
[PATCH v4 1/3] v4l: async: fix unbind error in v4l2_async_notifier_unregister()
The call to v4l2_async_cleanup() will set sd->asd to NULL so passing it to notifier->unbind() have no effect and leaves the notifier confused. Call the unbind() callback prior to cleaning up the subdevice to avoid this. Signed-off-by: Niklas Söderlund--- drivers/media/v4l2-core/v4l2-async.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/v4l2-core/v4l2-async.c b/drivers/media/v4l2-core/v4l2-async.c index 851f128eba2219ad..0acf288d7227ba97 100644 --- a/drivers/media/v4l2-core/v4l2-async.c +++ b/drivers/media/v4l2-core/v4l2-async.c @@ -226,14 +226,14 @@ void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier) d = get_device(sd->dev); + if (notifier->unbind) + notifier->unbind(notifier, sd, sd->asd); + v4l2_async_cleanup(sd); /* If we handled USB devices, we'd have to lock the parent too */ device_release_driver(d); - if (notifier->unbind) - notifier->unbind(notifier, sd, sd->asd); - /* * Store device at the device cache, in order to call * put_device() on the final step -- 2.13.1
[PATCH v4 0/3] v4l2-async: add subnotifier registration for subdevices
Hi, This is a rewrite of the feature since v3, maybe it should have been posted as a new series? This series enables incremental async find and bind of subdevices, please se patch 3/3 for a more detailed description of the new behavior, changelog in this cover letter for the differences to v3. The two primary reasons for a new implementation where: 1. Hans expressed an interest having the async complete() callbacks to happen only once all notifiers in the pipeline where complete. To do this a stronger connection between the notifiers where needed, hence the subnotifier is now embedded in struct v4l2_subdev. Whit this change it is possible to check all notifiers in a pipeline is complete before calling any of them. 2. There where concerns that the v3 solution was a bit to complex and hard to refactor in the future if other issues in the v4l2-async framework where to be addressed. By hiding the notifier in the struct v4l2_subdev and adding a new function to set that structure the interface towards drivers are minimized while everything else happens in the v4l2-async framework. This leaves the interface in a good position for possible changes in v4l2-async. This is tested on Renesas H3 and M3-W together with the Renesas CSI-2 and VIN Gen3 driver (posted separately). It is based on top of the media-tree. * Changes since v3 - Almost a complete rewrite, so drop all Ack-ed by tags. - Do not add new functions to register/unregister subnotifiers from callbacks. Instead have have the subdevice drivers populate the subnotifer list at probe time and have the v4l2-async framework handle the (un)registration of the notifiers. - Synchronize the call off the complete() callbacks. They will now all happens once all notifiers in a pipeline are all complete and from the edge towards the root device. - Add a new function v4l2_async_subdev_register_notifier() to hide the setup of the subnotifier internals to ease improvements later. * Changes since v2 - Fixed lots of spelling mistakes, thanks Hans! - Used a goto instead if state variable when restarting iteration over subdev list as suggested by Sakari. Thank you it's much easier read now. - Added Acked-by from Sakari and Hans, thanks! - Rebased to latest media-tree. * Changes since v1: - Added a pre-patch which adds an error check which was previously in the new incremental async code but is more useful on its own. - Added documentation to Documentation/media/kapi/v4l2-subdev.rst. - Fixed data type of bool variable. - Added call to lockdep_assert_held(), thanks Sakari. - Fixed commit messages typo, thanks Sakari. Niklas Söderlund (3): v4l: async: fix unbind error in v4l2_async_notifier_unregister() v4l: async: do not hold list_lock when reprobing devices v4l: async: add subnotifier to subdevices Documentation/media/kapi/v4l2-subdev.rst | 12 +++ drivers/media/v4l2-core/v4l2-async.c | 165 +-- include/media/v4l2-async.h | 25 + include/media/v4l2-subdev.h | 5 + 4 files changed, 179 insertions(+), 28 deletions(-) -- 2.13.1
[PATCH v4 2/3] v4l: async: do not hold list_lock when reprobing devices
There is no good reason to hold the list_lock when reprobing the devices and it prevents a clean implementation of subdevice notifiers. Move the actual release of the devices outside of the loop which requires the lock to be held. Signed-off-by: Niklas Söderlund--- drivers/media/v4l2-core/v4l2-async.c | 29 ++--- 1 file changed, 10 insertions(+), 19 deletions(-) diff --git a/drivers/media/v4l2-core/v4l2-async.c b/drivers/media/v4l2-core/v4l2-async.c index 0acf288d7227ba97..8fc84f7962386ddd 100644 --- a/drivers/media/v4l2-core/v4l2-async.c +++ b/drivers/media/v4l2-core/v4l2-async.c @@ -206,7 +206,7 @@ void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier) unsigned int notif_n_subdev = notifier->num_subdevs; unsigned int n_subdev = min(notif_n_subdev, V4L2_MAX_SUBDEVS); struct device **dev; - int i = 0; + int i, count = 0; if (!notifier->v4l2_dev) return; @@ -222,37 +222,28 @@ void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier) list_del(>list); list_for_each_entry_safe(sd, tmp, >done, async_list) { - struct device *d; - - d = get_device(sd->dev); + if (dev) + dev[count] = get_device(sd->dev); + count++; if (notifier->unbind) notifier->unbind(notifier, sd, sd->asd); v4l2_async_cleanup(sd); + } - /* If we handled USB devices, we'd have to lock the parent too */ - device_release_driver(d); + mutex_unlock(_lock); - /* -* Store device at the device cache, in order to call -* put_device() on the final step -*/ + for (i = 0; i < count; i++) { + /* If we handled USB devices, we'd have to lock the parent too */ if (dev) - dev[i++] = d; - else - put_device(d); + device_release_driver(dev[i]); } - mutex_unlock(_lock); - /* * Call device_attach() to reprobe devices -* -* NOTE: If dev allocation fails, i is 0, and the whole loop won't be -* executed. */ - while (i--) { + for (i = 0; dev && i < count; i++) { struct device *d = dev[i]; if (d && device_attach(d) < 0) { -- 2.13.1
Re: [PATCH 2/6] ARM: shmobile_defconfig: Cleanup from non-existing options
On Mon, Jul 17, 2017 at 09:29:24AM +0200, Geert Uytterhoeven wrote: > Hi Krzysztof, > > On Mon, Jul 17, 2017 at 7:49 AM, Krzysztof Kozlowskiwrote: > > Remove options which do not exist anymore: > > - DRM_RCAR_HDMI was merged to generic DRM bridge and is obsolete since > >commit 5c602531feb3 ("drm: rcar-du: Replace manual bridge > >implementation with DRM bridge"); > > > > - SND_SOC_RSRC_CARD was replaced by SND_SIMPLE_SCU_CARD in commit > >d12c6216c4a5 ("ASoC: rsrc-card: rename rsrc-card to simple-scu-card > >phase3"); > > > > Signed-off-by: Krzysztof Kozlowski > > These have already be fixed in the defconfig-for-v4.14 branch Simon Horman's > tree (git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git). > > https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git/log/?h=defconfig-for-v4.14 > > They're not yet in -next as v4.13-rc1 wasn't released at that time, and > Simon is now on holidays. Ahhh, thanks for noticing this! Best regards, Krzysztof
Applied "spi: sh-msiof: Add support for R-Car H3" to the spi tree
The patch spi: sh-msiof: Add support for R-Car H3 has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 3d108f1e2d4c21026750cd4107e03b3e7a3e98a0 Mon Sep 17 00:00:00 2001 From: Geert UytterhoevenDate: Wed, 12 Jul 2017 12:24:07 +0200 Subject: [PATCH] spi: sh-msiof: Add support for R-Car H3 Add support for MSIOF in r8a7795 (R-Car H3). Due to a hardware erratum on R-Car H3 ES1.x, this is only supported on ES2.0 and later. No driver update is needed. Signed-off-by: Geert Uytterhoeven Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/sh-msiof.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/spi/sh-msiof.txt b/Documentation/devicetree/bindings/spi/sh-msiof.txt index 64ee489571c4..39e5ef7c5e71 100644 --- a/Documentation/devicetree/bindings/spi/sh-msiof.txt +++ b/Documentation/devicetree/bindings/spi/sh-msiof.txt @@ -6,6 +6,7 @@ Required properties: "renesas,msiof-r8a7792" (R-Car V2H) "renesas,msiof-r8a7793" (R-Car M2-N) "renesas,msiof-r8a7794" (R-Car E2) +"renesas,msiof-r8a7795" (R-Car H3) "renesas,msiof-r8a7796" (R-Car M3-W) "renesas,msiof-sh73a0" (SH-Mobile AG5) "renesas,sh-mobile-msiof" (generic SH-Mobile compatibile device) -- 2.13.2
Re: [PATCH net-next repost v2] dt-bindings: net: ravb : Add support for r8a7743 SoC
From: Biju DasDate: Mon, 17 Jul 2017 09:33:52 +0100 > Add a new compatible string for the RZ/G1M (R8A7743) SoC. > > Signed-off-by: Biju Das > Reviewed-by: Geert Uytterhoeven > Reviewed-by: Simon Horman Applied.
[RFC v2 6/6] ARM: dts: blanche: add SCIF1 and MAX9260 deserializer
Adds serial port SCIF1 and the MAX9260 deserializers connected to it. Signed-off-by: Ulrich Hecht--- arch/arm/boot/dts/r8a7792-blanche.dts | 52 +++ 1 file changed, 52 insertions(+) diff --git a/arch/arm/boot/dts/r8a7792-blanche.dts b/arch/arm/boot/dts/r8a7792-blanche.dts index 9b67dca..2ae9a87 100644 --- a/arch/arm/boot/dts/r8a7792-blanche.dts +++ b/arch/arm/boot/dts/r8a7792-blanche.dts @@ -21,6 +21,7 @@ aliases { serial0 = serial1 = + serial2 = }; chosen { @@ -186,6 +187,16 @@ gpio = < 12 GPIO_ACTIVE_HIGH>; enable-active-high; }; + + mux: mux-controller { + compatible = "gpio-mux"; + #mux-control-cells = <0>; + + mux-gpios = < 12 GPIO_ACTIVE_HIGH>, + < 13 GPIO_ACTIVE_HIGH>, + < 14 GPIO_ACTIVE_HIGH>, + < 15 GPIO_ACTIVE_HIGH>; + }; }; _clk { @@ -202,6 +213,11 @@ function = "scif0"; }; + scif1_pins: scif1 { + groups = "scif1_data"; + function = "scif1"; + }; + scif3_pins: scif3 { groups = "scif3_data"; function = "scif3"; @@ -246,6 +262,42 @@ status = "okay"; }; + { + pinctrl-0 = <_pins>; + pinctrl-names = "default"; + + status = "okay"; + + mux-controls = <>; + + #address-cells = <1>; + #size-cells = <0>; + gmsl-deserializer@0 { + compatible = "maxim,max9260"; + reg = <0x8>; + }; + gmsl-deserializer@1 { + compatible = "maxim,max9260"; + reg = <0x9>; + }; + gmsl-deserializer@2 { + compatible = "maxim,max9260"; + reg = <0xa>; + }; + gmsl-deserializer@3 { + compatible = "maxim,max9260"; + reg = <0xb>; + }; + gmsl-deserializer@4 { + compatible = "maxim,max9260"; + reg = <0x4>; + }; + gmsl-deserializer@5 { + compatible = "maxim,max9260"; + reg = <0x5>; + }; +}; + { pinctrl-0 = <_pins>; pinctrl-names = "default"; -- 2.7.4
[RFC v2 5/6] max9260: add driver for i2c over GMSL passthrough
This driver implements tunnelling of i2c requests over GMSL via a MAX9260 deserializer. It provides an i2c adapter that can be used to reach devices on the far side of the link. Signed-off-by: Ulrich Hecht--- drivers/media/i2c/Kconfig | 6 + drivers/media/i2c/Makefile | 1 + drivers/media/i2c/max9260.c | 288 3 files changed, 295 insertions(+) create mode 100644 drivers/media/i2c/max9260.c diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index 7641667..a405d67 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -423,6 +423,12 @@ config VIDEO_VPX3220 To compile this driver as a module, choose M here: the module will be called vpx3220. +config VIDEO_MAX9260 + tristate "Maxim MAX9260 GMSL deserializer support" + depends on I2C + ---help--- + This driver supports the Maxim MAX9260 GMSL deserializer. + comment "Video and audio decoders" config VIDEO_SAA717X diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index 30e856c..3b6f6f2 100644 --- a/drivers/media/i2c/Makefile +++ b/drivers/media/i2c/Makefile @@ -67,6 +67,7 @@ obj-$(CONFIG_VIDEO_OV7640) += ov7640.o obj-$(CONFIG_VIDEO_OV7670) += ov7670.o obj-$(CONFIG_VIDEO_OV9650) += ov9650.o obj-$(CONFIG_VIDEO_OV13858) += ov13858.o +obj-$(CONFIG_VIDEO_MAX9260) += max9260.o obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o obj-$(CONFIG_VIDEO_MT9M111) += mt9m111.o obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o diff --git a/drivers/media/i2c/max9260.c b/drivers/media/i2c/max9260.c new file mode 100644 index 000..ca34e67 --- /dev/null +++ b/drivers/media/i2c/max9260.c @@ -0,0 +1,288 @@ +/* + * Maxim MAX9260 GMSL Deserializer Driver + * + * Copyright (C) 2017 Ulrich Hecht + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#define SYNC 0x79 +#define ACK0xc3 + +#define RX_FINISHED0 +#define RX_FRAME_ERROR 1 +#define RX_EXPECT_ACK 2 +#define RX_EXPECT_ACK_DATA 3 +#define RX_EXPECT_DATA 4 + +struct max9260_device { + struct serdev_device *serdev; + u8 *rx_buf; + int rx_len; + int rx_state; + wait_queue_head_t rx_wq; + struct i2c_adapter adap; +}; + +static void wait_for_transaction(struct max9260_device *dev) +{ + wait_event_interruptible_timeout(dev->rx_wq, + dev->rx_state <= RX_FRAME_ERROR, + HZ/2); +} + +static void max9260_transact(struct max9260_device *dev, +int expect, +u8 *request, int len) +{ + serdev_device_mux_select(dev->serdev); + + serdev_device_set_baudrate(dev->serdev, 115200); + serdev_device_set_parity(dev->serdev, 1, 0); + + dev->rx_state = expect; + serdev_device_write_buf(dev->serdev, request, len); + + wait_for_transaction(dev); + + serdev_device_mux_deselect(dev->serdev); +} + +static int max9260_read_reg(struct max9260_device *dev, int reg) +{ + u8 request[] = { 0x79, 0x91, reg, 1 }; + u8 rx; + + dev->rx_len = 1; + dev->rx_buf = + + max9260_transact(dev, RX_EXPECT_ACK_DATA, request, 4); + + if (dev->rx_state == RX_FINISHED) + return rx; + + return -EIO; +} + +static int max9260_setup(struct max9260_device *dev) +{ + int ret; + + ret = max9260_read_reg(dev, 0x1e); + + if (ret != 0x02) { + dev_err(>serdev->dev, + "device does not identify as MAX9260\n"); + return -EINVAL; + } + + return 0; +} + +static void max9260_uart_write_wakeup(struct serdev_device *serdev) +{ +} + +static int max9260_uart_receive_buf(struct serdev_device *serdev, + const u8 *data, size_t count) +{ + struct max9260_device *dev = serdev_device_get_drvdata(serdev); + int accepted; + + switch (dev->rx_state) { + case RX_FINISHED: + dev_dbg(>serdev->dev, "excess data ignored\n"); + return count; + + case RX_EXPECT_ACK: + case RX_EXPECT_ACK_DATA: + if (data[0] != ACK) { + dev_dbg(>serdev->dev, "frame error"); + dev->rx_state = RX_FRAME_ERROR; + wake_up_interruptible(>rx_wq); + return 1; + } + + if (dev->rx_state == RX_EXPECT_ACK_DATA) { + dev->rx_state = RX_EXPECT_DATA; + } else { + dev->rx_state = RX_FINISHED; + wake_up_interruptible(>rx_wq);
[RFC v2 4/6] serial: core: support deferring serdev controller registration
serdev controllers may depend on other devices (such as multiplexers) and thus require deferred probing support. Signed-off-by: Ulrich Hecht--- drivers/tty/serial/serial_core.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c index f534a40..30a8997 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -2785,6 +2785,10 @@ int uart_add_one_port(struct uart_driver *drv, struct uart_port *uport) uport->line, uport->dev, port, uport->tty_groups); if (likely(!IS_ERR(tty_dev))) { device_set_wakeup_capable(tty_dev, 1); + } else if (PTR_ERR(tty_dev) == -EPROBE_DEFER) { + ret = -EPROBE_DEFER; + state->uart_port = NULL; + goto out; } else { dev_err(uport->dev, "Cannot register tty device on line %d\n", uport->line); -- 2.7.4
[RFC v2 2/6] serdev: add method to set parity
Adds serdev_device_set_parity() and an implementation for ttyport. Signed-off-by: Ulrich Hecht--- drivers/tty/serdev/core.c | 12 drivers/tty/serdev/serdev-ttyport.c | 17 + include/linux/serdev.h | 4 3 files changed, 33 insertions(+) diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c index f71b473..1fbaa4c 100644 --- a/drivers/tty/serdev/core.c +++ b/drivers/tty/serdev/core.c @@ -242,6 +242,18 @@ int serdev_device_set_tiocm(struct serdev_device *serdev, int set, int clear) } EXPORT_SYMBOL_GPL(serdev_device_set_tiocm); +int serdev_device_set_parity(struct serdev_device *serdev, +bool enable, bool odd) +{ + struct serdev_controller *ctrl = serdev->ctrl; + + if (!ctrl || !ctrl->ops->set_parity) + return -ENOTSUPP; + + return ctrl->ops->set_parity(ctrl, enable, odd); +} +EXPORT_SYMBOL_GPL(serdev_device_set_parity); + static int serdev_drv_probe(struct device *dev) { const struct serdev_device_driver *sdrv = to_serdev_device_driver(dev->driver); diff --git a/drivers/tty/serdev/serdev-ttyport.c b/drivers/tty/serdev/serdev-ttyport.c index 302018d..9114956 100644 --- a/drivers/tty/serdev/serdev-ttyport.c +++ b/drivers/tty/serdev/serdev-ttyport.c @@ -195,6 +195,22 @@ static int ttyport_set_tiocm(struct serdev_controller *ctrl, unsigned int set, u return tty->driver->ops->tiocmset(tty, set, clear); } +static int ttyport_set_parity(struct serdev_controller *ctrl, + bool enable, bool odd) +{ + struct serport *serport = serdev_controller_get_drvdata(ctrl); + struct tty_struct *tty = serport->tty; + struct ktermios ktermios = tty->termios; + + ktermios.c_cflag &= ~(PARENB | PARODD); + if (enable) + ktermios.c_cflag |= PARENB; + if (odd) + ktermios.c_cflag |= PARODD; + + return tty_set_termios(tty, ); +} + static const struct serdev_controller_ops ctrl_ops = { .write_buf = ttyport_write_buf, .write_flush = ttyport_write_flush, @@ -206,6 +222,7 @@ static const struct serdev_controller_ops ctrl_ops = { .wait_until_sent = ttyport_wait_until_sent, .get_tiocm = ttyport_get_tiocm, .set_tiocm = ttyport_set_tiocm, + .set_parity = ttyport_set_parity, }; struct device *serdev_tty_port_register(struct tty_port *port, diff --git a/include/linux/serdev.h b/include/linux/serdev.h index e69402d..8b67fcd 100644 --- a/include/linux/serdev.h +++ b/include/linux/serdev.h @@ -90,6 +90,7 @@ struct serdev_controller_ops { void (*wait_until_sent)(struct serdev_controller *, long); int (*get_tiocm)(struct serdev_controller *); int (*set_tiocm)(struct serdev_controller *, unsigned int, unsigned int); + int (*set_parity)(struct serdev_controller *, bool, bool); }; /** @@ -298,6 +299,9 @@ static inline int serdev_device_set_rts(struct serdev_device *serdev, bool enabl return serdev_device_set_tiocm(serdev, 0, TIOCM_RTS); } +int serdev_device_set_parity(struct serdev_device *serdev, +bool enable, bool odd); + /* * serdev hooks into TTY core */ -- 2.7.4
[RFC v2 0/6] serdev multiplexing support
Hi! This is a new attempt to add multiplexer support to serdev. It is now based on the mux subsystem, making it more generic than the previous iteration ("[RFC 0/4] serdev GPIO-based multiplexing support"). Thanks to reviewers for their comments. This revision incorporates the changes suggested as far as they are still applicable, which mostly applies to those concerning the MAX9260 i2c adapter driver. New patches have been added that fix a small issue in the mux include files ("mux: include compiler.h from mux/consumer.h"), and implement deferred probing of serdev controllers ("serial: core: support deferring serdev controller registration"), hopefully correctly. This series depends on the "pinctrl: sh-pfc: r8a7792: Add SCIF1 pin groups" patch as well as v15 of the mux subsystem series ("[PATCH v15 00/13] mux controller abstraction and iio/i2c muxes"). CU Uli Ulrich Hecht (6): mux: include compiler.h from mux/consumer.h serdev: add method to set parity serdev: add multiplexer support serial: core: support deferring serdev controller registration max9260: add driver for i2c over GMSL passthrough ARM: dts: blanche: add SCIF1 and MAX9260 deserializer arch/arm/boot/dts/r8a7792-blanche.dts | 52 ++ drivers/media/i2c/Kconfig | 6 + drivers/media/i2c/Makefile| 1 + drivers/media/i2c/max9260.c | 288 ++ drivers/tty/serdev/Kconfig| 3 + drivers/tty/serdev/Makefile | 1 + drivers/tty/serdev/core.c | 26 ++- drivers/tty/serdev/mux.c | 66 drivers/tty/serdev/serdev-ttyport.c | 17 ++ drivers/tty/serial/serial_core.c | 4 + include/linux/mux/consumer.h | 2 + include/linux/serdev.h| 20 ++- 12 files changed, 482 insertions(+), 4 deletions(-) create mode 100644 drivers/media/i2c/max9260.c create mode 100644 drivers/tty/serdev/mux.c -- 2.7.4
[RFC v2 3/6] serdev: add multiplexer support
Adds an interface for slave device multiplexing using the mux subsystem. Signed-off-by: Ulrich Hecht--- drivers/tty/serdev/Kconfig | 3 +++ drivers/tty/serdev/Makefile | 1 + drivers/tty/serdev/core.c | 14 +- drivers/tty/serdev/mux.c| 66 + include/linux/serdev.h | 16 --- 5 files changed, 96 insertions(+), 4 deletions(-) create mode 100644 drivers/tty/serdev/mux.c diff --git a/drivers/tty/serdev/Kconfig b/drivers/tty/serdev/Kconfig index cdc6b82..9096b71 100644 --- a/drivers/tty/serdev/Kconfig +++ b/drivers/tty/serdev/Kconfig @@ -13,4 +13,7 @@ config SERIAL_DEV_CTRL_TTYPORT depends on TTY depends on SERIAL_DEV_BUS != m +config SERIAL_DEV_MUX + bool "Serial device multiplexer support" + endif diff --git a/drivers/tty/serdev/Makefile b/drivers/tty/serdev/Makefile index 0cbdb94..d713381 100644 --- a/drivers/tty/serdev/Makefile +++ b/drivers/tty/serdev/Makefile @@ -1,5 +1,6 @@ serdev-objs := core.o obj-$(CONFIG_SERIAL_DEV_BUS) += serdev.o +obj-$(CONFIG_SERIAL_DEV_MUX) += mux.o obj-$(CONFIG_SERIAL_DEV_CTRL_TTYPORT) += serdev-ttyport.o diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c index 1fbaa4c..92c5bfa 100644 --- a/drivers/tty/serdev/core.c +++ b/drivers/tty/serdev/core.c @@ -305,7 +305,8 @@ struct serdev_device *serdev_device_alloc(struct serdev_controller *ctrl) return NULL; serdev->ctrl = ctrl; - ctrl->serdev = serdev; + if (!ctrl->serdev) + ctrl->serdev = serdev; device_initialize(>dev); serdev->dev.parent = >dev; serdev->dev.bus = _bus_type; @@ -368,6 +369,8 @@ static int of_serdev_register_devices(struct serdev_controller *ctrl) struct serdev_device *serdev = NULL; int err; bool found = false; + int nr = 0; + u32 reg; for_each_available_child_of_node(ctrl->dev.of_node, node) { if (!of_get_property(node, "compatible", NULL)) @@ -380,6 +383,10 @@ static int of_serdev_register_devices(struct serdev_controller *ctrl) continue; serdev->dev.of_node = node; + serdev->nr = nr++; + + if (!of_property_read_u32(node, "reg", )) + serdev->mux_addr = reg; err = serdev_device_add(serdev); if (err) { @@ -414,6 +421,11 @@ int serdev_controller_add(struct serdev_controller *ctrl) if (ret) return ret; +#ifdef CONFIG_SERIAL_DEV_MUX + if (of_serdev_register_mux(ctrl) == -EPROBE_DEFER) + return -EPROBE_DEFER; +#endif + ret = of_serdev_register_devices(ctrl); if (ret) goto out_dev_del; diff --git a/drivers/tty/serdev/mux.c b/drivers/tty/serdev/mux.c new file mode 100644 index 000..fc9405b --- /dev/null +++ b/drivers/tty/serdev/mux.c @@ -0,0 +1,66 @@ +/* + * Copyright (C) 2017 Ulrich Hecht + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 and + * only version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include +#include +#include +#include +#include + +int serdev_device_mux_select(struct serdev_device *serdev) +{ + struct mux_control *mux = serdev->ctrl->mux; + int ret; + + if (!mux) + return -EINVAL; + + ret = mux_control_select(mux, serdev->mux_addr); + serdev->ctrl->mux_do_not_deselect = ret < 0; + + serdev->ctrl->serdev = serdev; + + return ret; +} + +int serdev_device_mux_deselect(struct serdev_device *serdev) +{ + struct mux_control *mux = serdev->ctrl->mux; + + if (!mux) + return -EINVAL; + + if (!serdev->ctrl->mux_do_not_deselect) + return mux_control_deselect(mux); + else + return 0; +} + +int of_serdev_register_mux(struct serdev_controller *ctrl) +{ + struct mux_control *mux; + struct device *dev = >dev; + + mux = devm_mux_control_get(dev, NULL); + + if (IS_ERR(mux)) { + if (PTR_ERR(mux) != -EPROBE_DEFER) + dev_err(dev, "failed to get control mux\n"); + return PTR_ERR(mux); + } + + ctrl->mux = mux; + + return 0; +} + diff --git a/include/linux/serdev.h b/include/linux/serdev.h index 8b67fcd..26d5994 100644 --- a/include/linux/serdev.h +++ b/include/linux/serdev.h @@ -17,6 +17,7 @@ #include #include #include +#include struct serdev_controller; struct serdev_device; @@ -51,6 +52,7 @@ struct serdev_device { const struct
[RFC v2 1/6] mux: include compiler.h from mux/consumer.h
Required for __must_check. Signed-off-by: Ulrich Hecht--- include/linux/mux/consumer.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/mux/consumer.h b/include/linux/mux/consumer.h index 5577e1b..ea96d4c 100644 --- a/include/linux/mux/consumer.h +++ b/include/linux/mux/consumer.h @@ -13,6 +13,8 @@ #ifndef _LINUX_MUX_CONSUMER_H #define _LINUX_MUX_CONSUMER_H +#include + struct device; struct mux_control; -- 2.7.4
[PATCH 5/5] watchdog: renesas_wdt: add another divider option
If we set RWTCSRB to 0, we can gain 4096 as another divider value. This is supported by all R-Car Gen2 and Gen3 devices which we aim to support. Signed-off-by: Wolfram Sang--- drivers/watchdog/renesas_wdt.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c index 599ba5aaa0536f..e3f204bb8802aa 100644 --- a/drivers/watchdog/renesas_wdt.c +++ b/drivers/watchdog/renesas_wdt.c @@ -23,21 +23,22 @@ #define RWTCSRA_WOVF BIT(4) #define RWTCSRA_WRFLG BIT(5) #define RWTCSRA_TMEBIT(7) +#define RWTCSRB8 #define RWDT_DEFAULT_TIMEOUT 60U /* * In probe, clk_rate is checked to be not more than 16 bit * biggest clock - * divider (10 bits). d is only a factor to fully utilize the WDT counter and + * divider (12 bits). d is only a factor to fully utilize the WDT counter and * will not exceed its 16 bits. Thus, no overflow, we stay below 32 bits. */ #define MUL_BY_CLKS_PER_SEC(p, d) \ DIV_ROUND_UP((d) * (p)->clk_rate, clk_divs[(p)->cks]) -/* d is 16 bit, clk_divs 10 bit -> no 32 bit overflow */ +/* d is 16 bit, clk_divs 12 bit -> no 32 bit overflow */ #define DIV_BY_CLKS_PER_SEC(p, d) ((d) * clk_divs[(p)->cks] / (p)->clk_rate) -static const unsigned int clk_divs[] = { 1, 4, 16, 32, 64, 128, 1024 }; +static const unsigned int clk_divs[] = { 1, 4, 16, 32, 64, 128, 1024, 4096 }; static bool nowayout = WATCHDOG_NOWAYOUT; module_param(nowayout, bool, 0); @@ -77,6 +78,7 @@ static int rwdt_start(struct watchdog_device *wdev) clk_prepare_enable(priv->clk); + rwdt_write(priv, 0, RWTCSRB); rwdt_write(priv, priv->cks, RWTCSRA); rwdt_init_timeout(wdev); -- 2.11.0
[PATCH 4/5] watchdog: renesas_wdt: apply better precision
The error margin of the clks_per_second variable was too large and caused offsets when used with clock frequencies which left a remainder after applying the dividers. Now we always calculate directly using the clock rate and the divider using some helper macros. That also means that DIV_ROUND_UP moves from probe to the multiplication macro. In probe, we don't need to ensure anymore that 'clks_per_sec' would go too fast but rather ensure that the lower limit is really at least 1 to certainly get a full cycle. Signed-off-by: Takeshi KiharaSigned-off-by: Wolfram Sang --- drivers/watchdog/renesas_wdt.c | 28 +++- 1 file changed, 19 insertions(+), 9 deletions(-) diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c index d2390695d3453f..599ba5aaa0536f 100644 --- a/drivers/watchdog/renesas_wdt.c +++ b/drivers/watchdog/renesas_wdt.c @@ -26,6 +26,17 @@ #define RWDT_DEFAULT_TIMEOUT 60U +/* + * In probe, clk_rate is checked to be not more than 16 bit * biggest clock + * divider (10 bits). d is only a factor to fully utilize the WDT counter and + * will not exceed its 16 bits. Thus, no overflow, we stay below 32 bits. + */ +#define MUL_BY_CLKS_PER_SEC(p, d) \ + DIV_ROUND_UP((d) * (p)->clk_rate, clk_divs[(p)->cks]) + +/* d is 16 bit, clk_divs 10 bit -> no 32 bit overflow */ +#define DIV_BY_CLKS_PER_SEC(p, d) ((d) * clk_divs[(p)->cks] / (p)->clk_rate) + static const unsigned int clk_divs[] = { 1, 4, 16, 32, 64, 128, 1024 }; static bool nowayout = WATCHDOG_NOWAYOUT; @@ -37,7 +48,7 @@ struct rwdt_priv { void __iomem *base; struct watchdog_device wdev; struct clk *clk; - unsigned int clks_per_sec; + unsigned long clk_rate; u8 cks; }; @@ -55,7 +66,7 @@ static int rwdt_init_timeout(struct watchdog_device *wdev) { struct rwdt_priv *priv = watchdog_get_drvdata(wdev); - rwdt_write(priv, 65536 - wdev->timeout * priv->clks_per_sec, RWTCNT); + rwdt_write(priv, 65536 - MUL_BY_CLKS_PER_SEC(priv, wdev->timeout), RWTCNT); return 0; } @@ -92,7 +103,7 @@ static unsigned int rwdt_get_timeleft(struct watchdog_device *wdev) struct rwdt_priv *priv = watchdog_get_drvdata(wdev); u16 val = readw_relaxed(priv->base + RWTCNT); - return (65536 - val) / priv->clks_per_sec; + return DIV_BY_CLKS_PER_SEC(priv, 65536 - val); } static const struct watchdog_info rwdt_ident = { @@ -112,7 +123,7 @@ static int rwdt_probe(struct platform_device *pdev) { struct rwdt_priv *priv; struct resource *res; - unsigned long rate, clks_per_sec; + unsigned long clks_per_sec; int ret, i; priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL); @@ -128,14 +139,13 @@ static int rwdt_probe(struct platform_device *pdev) if (IS_ERR(priv->clk)) return PTR_ERR(priv->clk); - rate = clk_get_rate(priv->clk); - if (!rate) + priv->clk_rate = clk_get_rate(priv->clk); + if (!priv->clk_rate) return -ENOENT; for (i = ARRAY_SIZE(clk_divs) - 1; i >= 0; i--) { - clks_per_sec = DIV_ROUND_UP(rate, clk_divs[i]); + clks_per_sec = priv->clk_rate / clk_divs[i]; if (clks_per_sec && clks_per_sec < 65536) { - priv->clks_per_sec = clks_per_sec; priv->cks = i; break; } @@ -153,7 +163,7 @@ static int rwdt_probe(struct platform_device *pdev) priv->wdev.ops = _ops, priv->wdev.parent = >dev; priv->wdev.min_timeout = 1; - priv->wdev.max_timeout = 65536 / clks_per_sec; + priv->wdev.max_timeout = DIV_BY_CLKS_PER_SEC(priv, 65536); priv->wdev.timeout = min(priv->wdev.max_timeout, RWDT_DEFAULT_TIMEOUT); platform_set_drvdata(pdev, priv); -- 2.11.0
[PATCH 0/5] watchdog: renesas_wdt: improve precision
Currently, the renesas-rwdt driver is not precise with input clocks which have a remainder after the clock divisors are applied. This series should fix the situation and also pays attention to ensure variables have proper types and are divided properly. As a cherry on top, we also get a new divider value to allow for higher max_timeout :) Originally brought to attention by this BSP patch: https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?id=7d56256a4d189a83e278ec2013eb1f3648bc7411 Tested with a Salvator-X (R-Car M3-W) and the clock driver hacked to supply the internal clock of 32552 Hz instead of the externally supplied 32768 Hz. A branch can be found here: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/watchdog-fixes Please comment or apply... Thanks, Wolfram Wolfram Sang (5): watchdog: renesas_wdt: avoid (theoretical) type overflow watchdog: renesas_wdt: check rate also for upper limit watchdog: renesas_wdt: don't round closest with get_timeleft watchdog: renesas_wdt: apply better precision watchdog: renesas_wdt: add another divider option drivers/watchdog/renesas_wdt.c | 37 - 1 file changed, 24 insertions(+), 13 deletions(-) -- 2.11.0
[PATCH 1/5] watchdog: renesas_wdt: avoid (theoretical) type overflow
Because the smallest clock divider we can select is 1, 'clks_per_sec' must be the same type as 'rate'. Signed-off-by: Wolfram Sang--- drivers/watchdog/renesas_wdt.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c index cf61c92f7ecd63..4f8a3563b6aa53 100644 --- a/drivers/watchdog/renesas_wdt.c +++ b/drivers/watchdog/renesas_wdt.c @@ -112,8 +112,7 @@ static int rwdt_probe(struct platform_device *pdev) { struct rwdt_priv *priv; struct resource *res; - unsigned long rate; - unsigned int clks_per_sec; + unsigned long rate, clks_per_sec; int ret, i; priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL); -- 2.11.0
[PATCH 3/5] watchdog: renesas_wdt: don't round closest with get_timeleft
We should never return more time left than there actually is. So, switch to a plain divider instead of DIV_ROUND_CLOSEST. 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 0b9e8a9b1dd14c..d2390695d3453f 100644 --- a/drivers/watchdog/renesas_wdt.c +++ b/drivers/watchdog/renesas_wdt.c @@ -92,7 +92,7 @@ static unsigned int rwdt_get_timeleft(struct watchdog_device *wdev) struct rwdt_priv *priv = watchdog_get_drvdata(wdev); u16 val = readw_relaxed(priv->base + RWTCNT); - return DIV_ROUND_CLOSEST(65536 - val, priv->clks_per_sec); + return (65536 - val) / priv->clks_per_sec; } static const struct watchdog_info rwdt_ident = { -- 2.11.0
[PATCH 2/5] watchdog: renesas_wdt: check rate also for upper limit
When checking the clock rate, ensure also that counting all 16 bits takes at least one second to match the granularity of the framework. Signed-off-by: Wolfram Sang--- drivers/watchdog/renesas_wdt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c index 4f8a3563b6aa53..0b9e8a9b1dd14c 100644 --- a/drivers/watchdog/renesas_wdt.c +++ b/drivers/watchdog/renesas_wdt.c @@ -134,14 +134,14 @@ static int rwdt_probe(struct platform_device *pdev) for (i = ARRAY_SIZE(clk_divs) - 1; i >= 0; i--) { clks_per_sec = DIV_ROUND_UP(rate, clk_divs[i]); - if (clks_per_sec) { + if (clks_per_sec && clks_per_sec < 65536) { priv->clks_per_sec = clks_per_sec; priv->cks = i; break; } } - if (!clks_per_sec) { + if (i < 0) { dev_err(>dev, "Can't find suitable clock divider\n"); return -ERANGE; } -- 2.11.0
Re: [PATCH 14/14] [media] fix warning on v4l2_subdev_call() result interpreted as bool
On 17/07/17 16:26, Arnd Bergmann wrote: > On Mon, Jul 17, 2017 at 3:45 PM, Hans Verkuilwrote: >> On 14/07/17 11:36, Arnd Bergmann wrote: >>> @@ -201,8 +202,9 @@ static int cx18_g_fmt_sliced_vbi_cap(struct file *file, >>> void *fh, >>>* digitizer/slicer. Note, cx18_av_vbi() wipes the passed in >>>* fmt->fmt.sliced under valid calling conditions >>>*/ >>> - if (v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, >fmt.sliced)) >>> - return -EINVAL; >>> + ret = v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, >>> >fmt.sliced); >>> + if (ret) >>> + return ret; >> >> Please keep the -EINVAL here. I can't be 100% certain that returning 'ret' >> wouldn't >> break something. > > I think Dan was recommending the opposite here, if I understood you > both correctly: > he said we should propagate the error code unless we know it's wrong, while > you > want to keep the current behavior to avoid introducing changes ;-) > > I guess in either case, looking at the callers more carefully would be > a good idea. The subtle problem here is that v4l2_subdev_call will return -ENOIOCTLCMD if ops->vbi->g_sliced_fmt == NULL, which typically is not returned to userspace but either ignored or replaced by another error. It indicates that the sub device doesn't implement this operation, and it depends on the context and the operation whether or not that is to be considered an error. I have no clue what is expected here, without digging deep in the code. Better to keep it as-is. It really isn't important to waste time on this. > >>> - return 0; >>> + return ret; >>> } >>> >>> int atomisp_flash_enable(struct atomisp_sub_device *asd, int num_frames) >>> >> >> This is all very hackish, though. I'm not terribly keen on this patch. It's >> not >> clear to me *why* these warnings appear in your setup. > > it's possible that this only happened with 'ccache', which first preprocesses > the source and the passes it with v4l2_subdev_call expanded into the > compiler. This means the line looks like > > if ((!(cx->sd_av) ? -ENODEV : > (((cx->sd_av)->ops->vbi && (cx->sd_av)->ops->vbi->g_sliced_fmt) ? >(cx->sd_av)->ops->vbi->g_sliced_fmt(cx->sd_av)), > >fmt.sliced) : >-ENOIOCTLCMD)) > > The compiler now complains about the sub-expression that it sees for > cx->sd_av==NULL: > >if (-ENODEV) > > which it considers nonsense because it is always true and the value gets > ignored. > > Let me try again without ccache for now and see what warnings remain. > We can find a solution for those first, and then decide how to deal with > ccache. Sounds good. I'm OK with applying this if there is no other way to prevent these warnings. Regards, Hans > > Arnd >
Re: [PATCH 14/14] [media] fix warning on v4l2_subdev_call() result interpreted as bool
On 17/07/17 16:26, Arnd Bergmann wrote: > On Mon, Jul 17, 2017 at 3:45 PM, Hans Verkuilwrote: >> On 14/07/17 11:36, Arnd Bergmann wrote: >>> @@ -201,8 +202,9 @@ static int cx18_g_fmt_sliced_vbi_cap(struct file *file, >>> void *fh, >>>* digitizer/slicer. Note, cx18_av_vbi() wipes the passed in >>>* fmt->fmt.sliced under valid calling conditions >>>*/ >>> - if (v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, >fmt.sliced)) >>> - return -EINVAL; >>> + ret = v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, >>> >fmt.sliced); >>> + if (ret) >>> + return ret; >> >> Please keep the -EINVAL here. I can't be 100% certain that returning 'ret' >> wouldn't >> break something. > > I think Dan was recommending the opposite here, if I understood you > both correctly: > he said we should propagate the error code unless we know it's wrong, while > you > want to keep the current behavior to avoid introducing changes ;-) > > I guess in either case, looking at the callers more carefully would be > a good idea. The subtle problem here is that v4l2_subdev_call will return -ENOIOCTLCMD if ops->vbi->g_sliced_fmt == NULL, which typically is not returned to userspace but either ignored or replaced by another error. It indicates that the sub device doesn't implement this operation, and it depends on the context and the operation whether or not that is to be considered an error. I have no clue what is expected here, without digging deep in the code. Better to keep it as-is. It really isn't important to waste time on this. > >>> - return 0; >>> + return ret; >>> } >>> >>> int atomisp_flash_enable(struct atomisp_sub_device *asd, int num_frames) >>> >> >> This is all very hackish, though. I'm not terribly keen on this patch. It's >> not >> clear to me *why* these warnings appear in your setup. > > it's possible that this only happened with 'ccache', which first preprocesses > the source and the passes it with v4l2_subdev_call expanded into the > compiler. This means the line looks like > > if ((!(cx->sd_av) ? -ENODEV : > (((cx->sd_av)->ops->vbi && (cx->sd_av)->ops->vbi->g_sliced_fmt) ? >(cx->sd_av)->ops->vbi->g_sliced_fmt(cx->sd_av)), > >fmt.sliced) : >-ENOIOCTLCMD)) > > The compiler now complains about the sub-expression that it sees for > cx->sd_av==NULL: > >if (-ENODEV) > > which it considers nonsense because it is always true and the value gets > ignored. > > Let me try again without ccache for now and see what warnings remain. > We can find a solution for those first, and then decide how to deal with > ccache. Sounds good. I'm OK with applying this if there is no other way to prevent these warnings. Regards, Hans > > Arnd >
Re: [PATCH 14/14] [media] fix warning on v4l2_subdev_call() result interpreted as bool
On Mon, Jul 17, 2017 at 04:26:23PM +0200, Arnd Bergmann wrote: > On Mon, Jul 17, 2017 at 3:45 PM, Hans Verkuilwrote: > > On 14/07/17 11:36, Arnd Bergmann wrote: > >> @@ -201,8 +202,9 @@ static int cx18_g_fmt_sliced_vbi_cap(struct file > >> *file, void *fh, > >>* digitizer/slicer. Note, cx18_av_vbi() wipes the passed in > >>* fmt->fmt.sliced under valid calling conditions > >>*/ > >> - if (v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, >fmt.sliced)) > >> - return -EINVAL; > >> + ret = v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, > >> >fmt.sliced); > >> + if (ret) > >> + return ret; > > > > Please keep the -EINVAL here. I can't be 100% certain that returning 'ret' > > wouldn't > > break something. > > I think Dan was recommending the opposite here, if I understood you > both correctly: > he said we should propagate the error code unless we know it's wrong, while > you > want to keep the current behavior to avoid introducing changes ;-) > I don't know the subsystem rules at all, so don't listen to me. regards, dan carpenter
Re: [PATCH 14/14] [media] fix warning on v4l2_subdev_call() result interpreted as bool
On Mon, Jul 17, 2017 at 3:45 PM, Hans Verkuilwrote: > On 14/07/17 11:36, Arnd Bergmann wrote: >> @@ -201,8 +202,9 @@ static int cx18_g_fmt_sliced_vbi_cap(struct file *file, >> void *fh, >>* digitizer/slicer. Note, cx18_av_vbi() wipes the passed in >>* fmt->fmt.sliced under valid calling conditions >>*/ >> - if (v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, >fmt.sliced)) >> - return -EINVAL; >> + ret = v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, >fmt.sliced); >> + if (ret) >> + return ret; > > Please keep the -EINVAL here. I can't be 100% certain that returning 'ret' > wouldn't > break something. I think Dan was recommending the opposite here, if I understood you both correctly: he said we should propagate the error code unless we know it's wrong, while you want to keep the current behavior to avoid introducing changes ;-) I guess in either case, looking at the callers more carefully would be a good idea. >> - return 0; >> + return ret; >> } >> >> int atomisp_flash_enable(struct atomisp_sub_device *asd, int num_frames) >> > > This is all very hackish, though. I'm not terribly keen on this patch. It's > not > clear to me *why* these warnings appear in your setup. it's possible that this only happened with 'ccache', which first preprocesses the source and the passes it with v4l2_subdev_call expanded into the compiler. This means the line looks like if ((!(cx->sd_av) ? -ENODEV : (((cx->sd_av)->ops->vbi && (cx->sd_av)->ops->vbi->g_sliced_fmt) ? (cx->sd_av)->ops->vbi->g_sliced_fmt(cx->sd_av)), >fmt.sliced) : -ENOIOCTLCMD)) The compiler now complains about the sub-expression that it sees for cx->sd_av==NULL: if (-ENODEV) which it considers nonsense because it is always true and the value gets ignored. Let me try again without ccache for now and see what warnings remain. We can find a solution for those first, and then decide how to deal with ccache. Arnd
Re: [PATCH 14/14] [media] fix warning on v4l2_subdev_call() result interpreted as bool
On 14/07/17 11:36, Arnd Bergmann wrote: > v4l2_subdev_call is a macro returning whatever the callback return > type is, usually 'int'. With gcc-7 and ccache, this can lead to > many wanings like: > > media/platform/pxa_camera.c: In function 'pxa_mbus_build_fmts_xlate': > media/platform/pxa_camera.c:766:27: error: ?: using integer constants in > boolean context [-Werror=int-in-bool-context] > while (!v4l2_subdev_call(subdev, pad, enum_mbus_code, NULL, )) { > media/atomisp/pci/atomisp2/atomisp_cmd.c: In function 'atomisp_s_ae_window': > media/atomisp/pci/atomisp2/atomisp_cmd.c:6414:52: error: ?: using integer > constants in boolean context [-Werror=int-in-bool-context] > if (v4l2_subdev_call(isp->inputs[asd->input_curr].camera, > > The best workaround I could come up with is to change all the > callers that use the return code from v4l2_subdev_call() in an > 'if' or 'while' condition. > > In case of simple 'if' checks, adding a temporary variable is > usually ok, and sometimes this can be used to propagate or > print an error code, so I do that. > > For the 'while' loops, I ended up adding an otherwise useless > comparison with zero, which unfortunately makes the code a little > uglied. > > Signed-off-by: Arnd Bergmann> --- > drivers/media/pci/cx18/cx18-ioctl.c | 6 -- > drivers/media/pci/saa7146/mxb.c | 5 +++-- > drivers/media/platform/atmel/atmel-isc.c | 4 ++-- > drivers/media/platform/atmel/atmel-isi.c | 4 ++-- > drivers/media/platform/blackfin/bfin_capture.c | 4 ++-- > drivers/media/platform/omap3isp/ispccdc.c| 5 +++-- > drivers/media/platform/pxa_camera.c | 3 ++- > drivers/media/platform/rcar-vin/rcar-core.c | 2 +- > drivers/media/platform/rcar-vin/rcar-dma.c | 4 +++- > drivers/media/platform/soc_camera/soc_camera.c | 4 ++-- > drivers/media/platform/stm32/stm32-dcmi.c| 4 ++-- > drivers/media/platform/ti-vpe/cal.c | 6 -- > drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c | 13 +++-- > 13 files changed, 37 insertions(+), 27 deletions(-) > > diff --git a/drivers/media/pci/cx18/cx18-ioctl.c > b/drivers/media/pci/cx18/cx18-ioctl.c > index 80b902b12a78..1803f28fc501 100644 > --- a/drivers/media/pci/cx18/cx18-ioctl.c > +++ b/drivers/media/pci/cx18/cx18-ioctl.c > @@ -188,6 +188,7 @@ static int cx18_g_fmt_sliced_vbi_cap(struct file *file, > void *fh, > { > struct cx18 *cx = fh2id(fh)->cx; > struct v4l2_sliced_vbi_format *vbifmt = >fmt.sliced; > + int ret; > > /* sane, V4L2 spec compliant, defaults */ > vbifmt->reserved[0] = 0; > @@ -201,8 +202,9 @@ static int cx18_g_fmt_sliced_vbi_cap(struct file *file, > void *fh, >* digitizer/slicer. Note, cx18_av_vbi() wipes the passed in >* fmt->fmt.sliced under valid calling conditions >*/ > - if (v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, >fmt.sliced)) > - return -EINVAL; > + ret = v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, >fmt.sliced); > + if (ret) > + return ret; Please keep the -EINVAL here. I can't be 100% certain that returning 'ret' wouldn't break something. > > vbifmt->service_set = cx18_get_service_set(vbifmt); > return 0; > diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c > b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c > index 97093baf28ac..fe56a037f065 100644 > --- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c > +++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c > @@ -6405,19 +6405,20 @@ int atomisp_s_ae_window(struct atomisp_sub_device > *asd, > struct atomisp_device *isp = asd->isp; > /* Coverity CID 298071 - initialzize struct */ > struct v4l2_subdev_selection sel = { 0 }; > + int ret; > > sel.r.left = arg->x_left; > sel.r.top = arg->y_top; > sel.r.width = arg->x_right - arg->x_left + 1; > sel.r.height = arg->y_bottom - arg->y_top + 1; > > - if (v4l2_subdev_call(isp->inputs[asd->input_curr].camera, > - pad, set_selection, NULL, )) { > - dev_err(isp->dev, "failed to call sensor set_selection.\n"); > - return -EINVAL; > - } > + ret = v4l2_subdev_call(isp->inputs[asd->input_curr].camera, > +pad, set_selection, NULL, ); > + if (ret) > + dev_err(isp->dev, "failed to call sensor set_selection: %d\n", > + ret); Same here: just keep the 'return -EINVAL'. > > - return 0; > + return ret; > } > > int atomisp_flash_enable(struct atomisp_sub_device *asd, int num_frames) > This is all very hackish, though. I'm not terribly keen on this patch. It's not clear to me *why* these warnings appear in your setup. Regards, Hans
Re: [renesas-drivers:topic/renesas-overlays 20/86] drivers//of/unittest.c:2586:3: error: implicit declaration of function '__of_attach_node_sysfs'
On Mon, Jul 17, 2017 at 3:13 PM, kbuild test robotwrote: > tree: > https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git > topic/renesas-overlays > head: 21b4ee226c68bdaba9db7f6fc7cbdfab58db40b9 > commit: 3b480353c59beefd9537feca3febda56339bbb21 [20/86] of: rename > *_node_sysfs to _node_post > config: x86_64-randconfig-x013-201729 (attached as .config) > compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 > reproduce: > git checkout 3b480353c59beefd9537feca3febda56339bbb21 > # save the attached .config to linux build tree > make ARCH=x86_64 > > All errors (new ones prefixed by >>): > >drivers//of/unittest.c: In function 'of_unittest_overlay_high_level': >>> drivers//of/unittest.c:2586:3: error: implicit declaration of function >>> '__of_attach_node_sysfs' [-Werror=implicit-function-declaration] > __of_attach_node_sysfs(np); > ^~ Upstream got one more user of __of_attach_node_sysfs() to be converted... 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 v2] ARM: shmobile: Remove ARCH_SHMOBILE_MULTI
The migration from ARCH_SHMOBILE_MULTI to ARCH_RENESAS has been completed in v4.12 by commit 9ed2d4bc5c0c244d ("ARM: dts: renesas: Switch from ARCH_SHMOBILE_MULTI to ARCH_RENESAS"), so the ARCH_SHMOBILE_MULTI symbol can be removed. Signed-off-by: Geert Uytterhoeven--- v2: - Reference final commit. --- arch/arm/mach-shmobile/Kconfig | 4 1 file changed, 4 deletions(-) diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig index ad7d604ff0013268..280e7312a9e1b300 100644 --- a/arch/arm/mach-shmobile/Kconfig +++ b/arch/arm/mach-shmobile/Kconfig @@ -1,9 +1,6 @@ config ARCH_SHMOBILE bool -config ARCH_SHMOBILE_MULTI - bool - config PM_RMOBILE bool select PM @@ -34,7 +31,6 @@ menuconfig ARCH_RENESAS depends on ARCH_MULTI_V7 && MMU select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE select ARCH_SHMOBILE - select ARCH_SHMOBILE_MULTI select ARM_GIC select GPIOLIB select HAVE_ARM_SCU if SMP -- 2.7.4
[PATCH] ARM: shmobile: Remove ARCH_SHMOBILE_MULTI
The migration from ARCH_SHMOBILE_MULTI to ARCH_RENESAS has been completed in v4.12 by commit 9ed2d4bc5c0c244d ("ARM: dts: renesas: Switch from ARCH_SHMOBILE_MULTI to ARCH_RENESAS"), so the ARCH_SHMOBILE_MULTI symbol can be removed. Signed-off-by: Geert Uytterhoeven--- v2: - Reference final commit. --- arch/arm/mach-shmobile/Kconfig | 4 1 file changed, 4 deletions(-) diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig index ad7d604ff0013268..280e7312a9e1b300 100644 --- a/arch/arm/mach-shmobile/Kconfig +++ b/arch/arm/mach-shmobile/Kconfig @@ -1,9 +1,6 @@ config ARCH_SHMOBILE bool -config ARCH_SHMOBILE_MULTI - bool - config PM_RMOBILE bool select PM @@ -34,7 +31,6 @@ menuconfig ARCH_RENESAS depends on ARCH_MULTI_V7 && MMU select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE select ARCH_SHMOBILE - select ARCH_SHMOBILE_MULTI select ARM_GIC select GPIOLIB select HAVE_ARM_SCU if SMP -- 2.7.4
[renesas-drivers:topic/renesas-overlays 20/86] drivers//of/unittest.c:2586:3: error: implicit declaration of function '__of_attach_node_sysfs'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git topic/renesas-overlays head: 21b4ee226c68bdaba9db7f6fc7cbdfab58db40b9 commit: 3b480353c59beefd9537feca3febda56339bbb21 [20/86] of: rename *_node_sysfs to _node_post config: x86_64-randconfig-x013-201729 (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: git checkout 3b480353c59beefd9537feca3febda56339bbb21 # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): drivers//of/unittest.c: In function 'of_unittest_overlay_high_level': >> drivers//of/unittest.c:2586:3: error: implicit declaration of function >> '__of_attach_node_sysfs' [-Werror=implicit-function-declaration] __of_attach_node_sysfs(np); ^~ In file included from include/linux/err.h:4:0, from include/linux/clk.h:15, from drivers//of/unittest.c:7: drivers//of/unittest.c: At top level: include/linux/compiler.h:162:4: warning: '__f' is static but declared in inline function 'strcpy' which is not static __f = { \ ^ include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if' #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) ) ^~ include/linux/string.h:390:2: note: in expansion of macro 'if' if (p_size == (size_t)-1 && q_size == (size_t)-1) ^~ include/linux/compiler.h:162:4: warning: '__f' is static but declared in inline function 'kmemdup' which is not static __f = { \ ^ include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if' #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) ) ^~ include/linux/string.h:380:2: note: in expansion of macro 'if' if (p_size < size) ^~ include/linux/compiler.h:162:4: warning: '__f' is static but declared in inline function 'kmemdup' which is not static __f = { \ ^ include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if' #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) ) ^~ include/linux/string.h:378:2: note: in expansion of macro 'if' if (__builtin_constant_p(size) && p_size < size) ^~ include/linux/compiler.h:162:4: warning: '__f' is static but declared in inline function 'memchr_inv' which is not static __f = { \ ^ include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if' #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) ) ^~ include/linux/string.h:369:2: note: in expansion of macro 'if' if (p_size < size) ^~ include/linux/compiler.h:162:4: warning: '__f' is static but declared in inline function 'memchr_inv' which is not static __f = { \ ^ include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if' #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) ) ^~ include/linux/string.h:367:2: note: in expansion of macro 'if' if (__builtin_constant_p(size) && p_size < size) ^~ include/linux/compiler.h:162:4: warning: '__f' is static but declared in inline function 'memchr' which is not static __f = { \ ^ include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if' #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) ) ^~ include/linux/string.h:358:2: note: in expansion of macro 'if' if (p_size < size) ^~ include/linux/compiler.h:162:4: warning: '__f' is static but declared in inline function 'memchr' which is not static __f = { \ ^ include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if' #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) ) ^~ include/linux/string.h:356:2: note: in expansion of macro 'if' if (__builtin_constant_p(size) && p_size < size) ^~ include/linux/compiler.h:162:4: warning: '__f' is static but declared in inline function 'memcmp' which is not static __f = { \ ^ include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if' #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) ) ^~ include/linux/string.h:348:2: note: in expansion of macro 'if' if (p_size < size || q_size < size) ^~ include/linux/compiler.h:162:4: warning: '__f' is static but declared in inline function 'memcmp' which is not static __f = { \ ^ include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if' #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) ) ^~
[PATCH v2 04/05] iommu/ipmmu-vmsa: Replace local utlb code with fwspec ids
From: Magnus DammNow when both 32-bit and 64-bit code inside the driver is using fwspec it is possible to replace the utlb handling with fwspec ids that get populated from ->of_xlate(). Suggested-by: Robin Murphy Signed-off-by: Magnus Damm --- Changes since V1: - Rebased to apply on top of earlier changes in series drivers/iommu/ipmmu-vmsa.c | 104 1 file changed, 19 insertions(+), 85 deletions(-) --- 0006/drivers/iommu/ipmmu-vmsa.c +++ work/drivers/iommu/ipmmu-vmsa.c 2017-07-17 21:12:11.650607110 +0900 @@ -19,6 +19,7 @@ #include #include #include +#include #include #include #include @@ -59,8 +60,6 @@ struct ipmmu_vmsa_domain { struct ipmmu_vmsa_iommu_priv { struct ipmmu_vmsa_device *mmu; - unsigned int *utlbs; - unsigned int num_utlbs; struct device *dev; struct list_head list; }; @@ -550,13 +549,14 @@ static int ipmmu_attach_device(struct io struct device *dev) { struct ipmmu_vmsa_iommu_priv *priv = to_priv(dev); + struct iommu_fwspec *fwspec = dev->iommu_fwspec; struct ipmmu_vmsa_device *mmu = priv->mmu; struct ipmmu_vmsa_domain *domain = to_vmsa_domain(io_domain); unsigned long flags; unsigned int i; int ret = 0; - if (!mmu) { + if (!priv || !priv->mmu) { dev_err(dev, "Cannot attach to IPMMU\n"); return -ENXIO; } @@ -583,8 +583,8 @@ static int ipmmu_attach_device(struct io if (ret < 0) return ret; - for (i = 0; i < priv->num_utlbs; ++i) - ipmmu_utlb_enable(domain, priv->utlbs[i]); + for (i = 0; i < fwspec->num_ids; ++i) + ipmmu_utlb_enable(domain, fwspec->ids[i]); return 0; } @@ -592,12 +592,12 @@ static int ipmmu_attach_device(struct io static void ipmmu_detach_device(struct iommu_domain *io_domain, struct device *dev) { - struct ipmmu_vmsa_iommu_priv *priv = to_priv(dev); + struct iommu_fwspec *fwspec = dev->iommu_fwspec; struct ipmmu_vmsa_domain *domain = to_vmsa_domain(io_domain); unsigned int i; - for (i = 0; i < priv->num_utlbs; ++i) - ipmmu_utlb_disable(domain, priv->utlbs[i]); + for (i = 0; i < fwspec->num_ids; ++i) + ipmmu_utlb_disable(domain, fwspec->ids[i]); /* * TODO: Optimize by disabling the context when no device is attached. @@ -633,102 +633,36 @@ static phys_addr_t ipmmu_iova_to_phys(st return domain->iop->iova_to_phys(domain->iop, iova); } -static int ipmmu_find_utlbs(struct ipmmu_vmsa_device *mmu, struct device *dev, - unsigned int *utlbs, unsigned int num_utlbs) -{ - unsigned int i; - - for (i = 0; i < num_utlbs; ++i) { - struct of_phandle_args args; - int ret; - - ret = of_parse_phandle_with_args(dev->of_node, "iommus", -"#iommu-cells", i, ); - if (ret < 0) - return ret; - - of_node_put(args.np); - - if (args.np != mmu->dev->of_node || args.args_count != 1) - return -EINVAL; - - utlbs[i] = args.args[0]; - } - - return 0; -} - -static int ipmmu_init_platform_device(struct device *dev) +static int ipmmu_init_platform_device(struct device *dev, + struct of_phandle_args *args) { + struct platform_device *ipmmu_pdev; struct ipmmu_vmsa_iommu_priv *priv; - struct ipmmu_vmsa_device *mmu; - unsigned int *utlbs; - unsigned int i; - int num_utlbs; - int ret = -ENODEV; - - /* Find the master corresponding to the device. */ - num_utlbs = of_count_phandle_with_args(dev->of_node, "iommus", - "#iommu-cells"); - if (num_utlbs < 0) + ipmmu_pdev = of_find_device_by_node(args->np); + if (!ipmmu_pdev) return -ENODEV; - utlbs = kcalloc(num_utlbs, sizeof(*utlbs), GFP_KERNEL); - if (!utlbs) - return -ENOMEM; - - spin_lock(_devices_lock); - - list_for_each_entry(mmu, _devices, list) { - ret = ipmmu_find_utlbs(mmu, dev, utlbs, num_utlbs); - if (!ret) { - /* -* TODO Take a reference to the MMU to protect -* against device removal. -*/ - break; - } - } - - spin_unlock(_devices_lock); - - if (ret < 0) - goto error; - - for (i = 0; i < num_utlbs; ++i) { - if (utlbs[i] >= mmu->num_utlbs) { - ret =
[PATCH v2 02/05] iommu/ipmmu-vmsa: Consistent ->of_xlate() handling
From: Magnus DammThe 32-bit ARM code gets updated to make use of ->of_xlate() and the code is shared between 64-bit and 32-bit ARM. The of_device_is_available() check gets dropped since it is included in of_iommu_xlate(). Suggested-by: Robin Murphy Signed-off-by: Magnus Damm --- Changes since V1: - Moved "Initialize once" check to ipmmu_of_xlate() - thanks Geert! drivers/iommu/ipmmu-vmsa.c | 51 ++-- 1 file changed, 17 insertions(+), 34 deletions(-) --- 0002/drivers/iommu/ipmmu-vmsa.c +++ work/drivers/iommu/ipmmu-vmsa.c 2017-07-17 21:03:38.340607110 +0900 @@ -734,6 +734,16 @@ error: return ret; } +static int ipmmu_of_xlate(struct device *dev, + struct of_phandle_args *spec) +{ + /* Initialize once - xlate() will call multiple times */ + if (to_priv(dev)) + return 0; + + return ipmmu_init_platform_device(dev); +} + #if defined(CONFIG_ARM) && !defined(CONFIG_IOMMU_DMA) static struct iommu_domain *ipmmu_domain_alloc(unsigned type) @@ -750,11 +760,11 @@ static int ipmmu_add_device(struct devic struct iommu_group *group; int ret; - if (to_priv(dev)) { - dev_warn(dev, "IOMMU driver already assigned to device %s\n", -dev_name(dev)); - return -EINVAL; - } + /* +* Only let through devices that have been verified in xlate() +*/ + if (!to_priv(dev)) + return -ENODEV; /* Create a device group and add the device to it. */ group = iommu_group_alloc(); @@ -773,10 +783,6 @@ static int ipmmu_add_device(struct devic goto error; } - ret = ipmmu_init_platform_device(dev); - if (ret < 0) - goto error; - /* * Create the ARM mapping, used by the ARM DMA mapping core to allocate * VAs. This will allocate a corresponding IOMMU domain. @@ -817,24 +823,13 @@ error: if (!IS_ERR_OR_NULL(group)) iommu_group_remove_device(dev); - kfree(to_priv(dev)->utlbs); - kfree(to_priv(dev)); - set_priv(dev, NULL); - return ret; } static void ipmmu_remove_device(struct device *dev) { - struct ipmmu_vmsa_iommu_priv *priv = to_priv(dev); - arm_iommu_detach_device(dev); iommu_group_remove_device(dev); - - kfree(priv->utlbs); - kfree(priv); - - set_priv(dev, NULL); } static const struct iommu_ops ipmmu_ops = { @@ -849,6 +844,7 @@ static const struct iommu_ops ipmmu_ops .add_device = ipmmu_add_device, .remove_device = ipmmu_remove_device, .pgsize_bitmap = SZ_1G | SZ_2M | SZ_4K, + .of_xlate = ipmmu_of_xlate, }; #endif /* !CONFIG_ARM && CONFIG_IOMMU_DMA */ @@ -958,19 +954,6 @@ static struct iommu_group *ipmmu_find_gr return group; } -static int ipmmu_of_xlate_dma(struct device *dev, - struct of_phandle_args *spec) -{ - /* If the IPMMU device is disabled in DT then return error -* to make sure the of_iommu code does not install ops -* even though the iommu device is disabled -*/ - if (!of_device_is_available(spec->np)) - return -ENODEV; - - return ipmmu_init_platform_device(dev); -} - static const struct iommu_ops ipmmu_ops = { .domain_alloc = ipmmu_domain_alloc_dma, .domain_free = ipmmu_domain_free_dma, @@ -984,7 +967,7 @@ static const struct iommu_ops ipmmu_ops .remove_device = ipmmu_remove_device_dma, .device_group = ipmmu_find_group_dma, .pgsize_bitmap = SZ_1G | SZ_2M | SZ_4K, - .of_xlate = ipmmu_of_xlate_dma, + .of_xlate = ipmmu_of_xlate, }; #endif /* CONFIG_IOMMU_DMA */
[PATCH v2 01/05] iommu/ipmmu-vmsa: Use iommu_device_register()/unregister()
From: Magnus DammExtend the driver to make use of iommu_device_register()/unregister() functions together with iommu_device_set_ops() and iommu_set_fwnode(). These used to be part of the earlier posted 64-bit ARM (r8a7795) series but it turns out that these days they are required on 32-bit ARM as well. Signed-off-by: Magnus Damm --- Changes since V1: - Perform iommu_device_set_ops() and iommu_device_set_fwnode() before iommu_device_register() - thanks Robin! drivers/iommu/ipmmu-vmsa.c | 10 ++ 1 file changed, 10 insertions(+) --- 0001/drivers/iommu/ipmmu-vmsa.c +++ work/drivers/iommu/ipmmu-vmsa.c 2017-07-17 21:01:47.140607110 +0900 @@ -35,6 +35,7 @@ struct ipmmu_vmsa_device { struct device *dev; void __iomem *base; + struct iommu_device iommu; struct list_head list; unsigned int num_utlbs; @@ -1054,6 +1055,13 @@ static int ipmmu_probe(struct platform_d ipmmu_device_reset(mmu); + iommu_device_set_ops(>iommu, _ops); + iommu_device_set_fwnode(>iommu, >dev.of_node->fwnode); + + ret = iommu_device_register(>iommu); + if (ret) + return ret; + /* * We can't create the ARM mapping here as it requires the bus to have * an IOMMU, which only happens when bus_set_iommu() is called in @@ -1077,6 +1085,8 @@ static int ipmmu_remove(struct platform_ list_del(>list); spin_unlock(_devices_lock); + iommu_device_unregister(>iommu); + #if defined(CONFIG_ARM) && !defined(CONFIG_IOMMU_DMA) arm_iommu_release_mapping(mmu->mapping); #endif
[PATCH v2 05/05] iommu/ipmmu-vmsa: Clean up device tracking
From: Robin MurphyGet rid of now unused device tracking code. Future code should instead be able to use driver_for_each_device() for this purpose. This is a simplified version of the following patch from Robin [PATCH] iommu/ipmmu-vmsa: Clean up group allocation Signed-off-by: Robin Murphy Signed-off-by: Magnus Damm --- Change since V1: - New patch drivers/iommu/ipmmu-vmsa.c | 12 1 file changed, 12 deletions(-) --- 0008/drivers/iommu/ipmmu-vmsa.c +++ work/drivers/iommu/ipmmu-vmsa.c 2017-07-17 21:35:26.690607110 +0900 @@ -37,7 +37,6 @@ struct ipmmu_vmsa_device { struct device *dev; void __iomem *base; struct iommu_device iommu; - struct list_head list; unsigned int num_utlbs; spinlock_t lock;/* Protects ctx and domains[] */ @@ -64,9 +63,6 @@ struct ipmmu_vmsa_iommu_priv { struct list_head list; }; -static DEFINE_SPINLOCK(ipmmu_devices_lock); -static LIST_HEAD(ipmmu_devices); - static struct ipmmu_vmsa_domain *to_vmsa_domain(struct iommu_domain *dom) { return container_of(dom, struct ipmmu_vmsa_domain, io_domain); @@ -970,10 +966,6 @@ static int ipmmu_probe(struct platform_d * ipmmu_init() after the probe function returns. */ - spin_lock(_devices_lock); - list_add(>list, _devices); - spin_unlock(_devices_lock); - platform_set_drvdata(pdev, mmu); return 0; @@ -983,10 +975,6 @@ static int ipmmu_remove(struct platform_ { struct ipmmu_vmsa_device *mmu = platform_get_drvdata(pdev); - spin_lock(_devices_lock); - list_del(>list); - spin_unlock(_devices_lock); - iommu_device_unregister(>iommu); #if defined(CONFIG_ARM) && !defined(CONFIG_IOMMU_DMA)
[PATCH v2 03/05] iommu/ipmmu-vmsa: Use fwspec on both 32 and 64-bit ARM
From: Robin MurphyConsolidate the 32-bit and 64-bit code to make use of fwspec instead of archdata for the 32-bit ARM case. This is a simplified version of the fwspec handling code from Robin posted as [PATCH] iommu/ipmmu-vmsa: Convert to iommu_fwspec Signed-off-by: Robin Murphy Signed-off-by: Magnus Damm --- Changes since V1: - Rebased to apply on top of earlier changes in series drivers/iommu/ipmmu-vmsa.c | 21 +++-- 1 file changed, 3 insertions(+), 18 deletions(-) --- 0004/drivers/iommu/ipmmu-vmsa.c +++ work/drivers/iommu/ipmmu-vmsa.c 2017-07-17 21:04:54.850607110 +0900 @@ -73,22 +73,9 @@ static struct ipmmu_vmsa_domain *to_vmsa return container_of(dom, struct ipmmu_vmsa_domain, io_domain); } - static struct ipmmu_vmsa_iommu_priv *to_priv(struct device *dev) { -#if defined(CONFIG_ARM) - return dev->archdata.iommu; -#else - return dev->iommu_fwspec->iommu_priv; -#endif -} -static void set_priv(struct device *dev, struct ipmmu_vmsa_iommu_priv *p) -{ -#if defined(CONFIG_ARM) - dev->archdata.iommu = p; -#else - dev->iommu_fwspec->iommu_priv = p; -#endif + return dev->iommu_fwspec ? dev->iommu_fwspec->iommu_priv : NULL; } #define TLB_LOOP_TIMEOUT 100 /* 100us */ @@ -726,7 +713,7 @@ static int ipmmu_init_platform_device(st priv->utlbs = utlbs; priv->num_utlbs = num_utlbs; priv->dev = dev; - set_priv(dev, priv); + dev->iommu_fwspec->iommu_priv = priv; return 0; error: @@ -887,14 +874,12 @@ static void ipmmu_domain_free_dma(struct static int ipmmu_add_device_dma(struct device *dev) { - struct iommu_fwspec *fwspec = dev->iommu_fwspec; struct iommu_group *group; /* * Only let through devices that have been verified in xlate() -* We may get called with dev->iommu_fwspec set to NULL. */ - if (!fwspec || !fwspec->iommu_priv) + if (!to_priv(dev)) return -ENODEV; group = iommu_group_get_for_dev(dev);
[PATCH v2 00/05] iommu/ipmmu-vmsa: 32-bit ARM update V2
iommu/ipmmu-vmsa: 32-bit ARM update V2 [PATCH v2 01/05] iommu/ipmmu-vmsa: Use iommu_device_register()/unregister() [PATCH v2 02/05] iommu/ipmmu-vmsa: Consistent ->of_xlate() handling [PATCH v2 03/05] iommu/ipmmu-vmsa: Use fwspec on both 32 and 64-bit ARM [PATCH v2 04/05] iommu/ipmmu-vmsa: Replace local utlb code with fwspec ids [PATCH v2 05/05] iommu/ipmmu-vmsa: Clean up device tracking This series updates the IPMMU driver to make use of recent IOMMU framework changes and also improves code sharing in the driver between the 32-bit and 64-bit dma-mapping architecture glue code. Suggested-by: Robin Murphy(Patch 2 and 4) Signed-off-by: Robin Murphy (Patch 3 and 5) Signed-off-by: Magnus Damm --- Changes since V1: - Minor changes to patch 1 and 2 - thanks Robin and Geert! - Added patch 5 to include further clean ups Developed on top of v4.13-rc1 drivers/iommu/ipmmu-vmsa.c | 198 ++-- 1 file changed, 49 insertions(+), 149 deletions(-)
RE: [PATCH] ARM: dts: iwg20m: Correct indentation of mmcif0 properties
Hello Geert, > From: Geert Uytterhoeven [mailto:geert+rene...@glider.be] > Sent: 17 July 2017 13:07 > > Fixes: 4658c4b789d8e2ae ("ARM: dts: iwg20m: Add MMCIF0 support") > Signed-off-by: Geert UytterhoevenThanks for this, I'm not sure how we all missed it before! Reviewed-by: Chris Paterson Kind regards, Chris > --- > arch/arm/boot/dts/r8a7743-iwg20m.dtsi | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/arch/arm/boot/dts/r8a7743-iwg20m.dtsi > b/arch/arm/boot/dts/r8a7743-iwg20m.dtsi > index f78dbc542a824f40..ff799381863763de 100644 > --- a/arch/arm/boot/dts/r8a7743-iwg20m.dtsi > +++ b/arch/arm/boot/dts/r8a7743-iwg20m.dtsi > @@ -45,11 +45,11 @@ > }; > > { > - pinctrl-0 = <_pins>; > - pinctrl-names = "default"; > + pinctrl-0 = <_pins>; > + pinctrl-names = "default"; > > - vmmc-supply = <_3p3v>; > - bus-width = <8>; > - non-removable; > - status = "okay"; > + vmmc-supply = <_3p3v>; > + bus-width = <8>; > + non-removable; > + status = "okay"; > }; > -- > 2.7.4
[PATCH] ARM: dts: iwg20m: Correct indentation of mmcif0 properties
Fixes: 4658c4b789d8e2ae ("ARM: dts: iwg20m: Add MMCIF0 support") Signed-off-by: Geert Uytterhoeven--- arch/arm/boot/dts/r8a7743-iwg20m.dtsi | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm/boot/dts/r8a7743-iwg20m.dtsi b/arch/arm/boot/dts/r8a7743-iwg20m.dtsi index f78dbc542a824f40..ff799381863763de 100644 --- a/arch/arm/boot/dts/r8a7743-iwg20m.dtsi +++ b/arch/arm/boot/dts/r8a7743-iwg20m.dtsi @@ -45,11 +45,11 @@ }; { - pinctrl-0 = <_pins>; - pinctrl-names = "default"; + pinctrl-0 = <_pins>; + pinctrl-names = "default"; - vmmc-supply = <_3p3v>; - bus-width = <8>; - non-removable; - status = "okay"; + vmmc-supply = <_3p3v>; + bus-width = <8>; + non-removable; + status = "okay"; }; -- 2.7.4
[PATCH] clk: renesas: Allow compile-testing of all (sub)drivers
Enable compile-testing of the remaining clock drivers and subdrivers, now dummies are available for of_clk_get_from_provider(), of_device_compatible_match(), and rcar_rst_read_mode_pins(), and the CPG/MSSR driver core has been converted from of_match_node() to of_device_get_match_data(). Signed-off-by: Geert Uytterhoeven--- To be queued in clk-renesas-for-v4.14. drivers/clk/renesas/Kconfig | 38 +++--- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/drivers/clk/renesas/Kconfig b/drivers/clk/renesas/Kconfig index 78d1df9112ba3932..85526ca3920229c8 100644 --- a/drivers/clk/renesas/Kconfig +++ b/drivers/clk/renesas/Kconfig @@ -34,94 +34,94 @@ config CLK_EMEV2 bool "Emma Mobile EV2 clock support" if COMPILE_TEST config CLK_RZA1 - bool + bool "RZ/A1H clock support" if COMPILE_TEST select CLK_RENESAS_CPG_MSTP config CLK_R8A73A4 - bool + bool "R-Mobile APE6 clock support" if COMPILE_TEST select CLK_RENESAS_CPG_MSTP select CLK_RENESAS_DIV6 config CLK_R8A7740 - bool + bool "R-Mobile A1 clock support" if COMPILE_TEST select CLK_RENESAS_CPG_MSTP select CLK_RENESAS_DIV6 config CLK_R8A7743 - bool + bool "RZ/G1M clock support" if COMPILE_TEST select CLK_RCAR_GEN2_CPG config CLK_R8A7745 - bool + bool "RZ/G1E clock support" if COMPILE_TEST select CLK_RCAR_GEN2_CPG config CLK_R8A7778 - bool + bool "R-Car M1A clock support" if COMPILE_TEST select CLK_RENESAS_CPG_MSTP config CLK_R8A7779 - bool + bool "R-Car H1 clock support" if COMPILE_TEST select CLK_RENESAS_CPG_MSTP config CLK_R8A7790 - bool + bool "R-Car H2 clock support" if COMPILE_TEST select CLK_RCAR_GEN2 if CLK_RENESAS_LEGACY select CLK_RCAR_GEN2_CPG select CLK_RENESAS_DIV6 config CLK_R8A7791 - bool + bool "R-Car M2-W/N clock support" if COMPILE_TEST select CLK_RCAR_GEN2 if CLK_RENESAS_LEGACY select CLK_RCAR_GEN2_CPG select CLK_RENESAS_DIV6 config CLK_R8A7792 - bool + bool "R-Car V2H clock support" if COMPILE_TEST select CLK_RCAR_GEN2 if CLK_RENESAS_LEGACY select CLK_RCAR_GEN2_CPG config CLK_R8A7794 - bool + bool "R-Car E2 clock support" if COMPILE_TEST select CLK_RCAR_GEN2 if CLK_RENESAS_LEGACY select CLK_RCAR_GEN2_CPG select CLK_RENESAS_DIV6 config CLK_R8A7795 - bool + bool "R-Car H3 clock support" if COMPILE_TEST select CLK_RCAR_GEN3_CPG config CLK_R8A7796 - bool + bool "R-Car M3-W clock support" if COMPILE_TEST select CLK_RCAR_GEN3_CPG config CLK_SH73A0 - bool + bool "SH-Mobile AG5 clock support" if COMPILE_TEST select CLK_RENESAS_CPG_MSTP select CLK_RENESAS_DIV6 # Family config CLK_RCAR_GEN2 - bool + bool "R-Car Gen2 legacy clock support" if COMPILE_TEST select CLK_RENESAS_CPG_MSTP select CLK_RENESAS_DIV6 config CLK_RCAR_GEN2_CPG - bool + bool "R-Car Gen2 CPG clock support" if COMPILE_TEST select CLK_RENESAS_CPG_MSSR config CLK_RCAR_GEN3_CPG - bool + bool "R-Car Gen3 CPG clock support" if COMPILE_TEST select CLK_RENESAS_CPG_MSSR # Generic config CLK_RENESAS_CPG_MSSR - bool + bool "CPG/MSSR clock support" if COMPILE_TEST select CLK_RENESAS_DIV6 config CLK_RENESAS_CPG_MSTP - bool + bool "MSTP clock support" if COMPILE_TEST config CLK_RENESAS_DIV6 bool "DIV6 clock support" if COMPILE_TEST -- 2.7.4
Re: [PATCH 4/6] ARM: vexpress_defconfig: Cleanup from non-existing options
On Mon, Jul 17, 2017 at 07:49:54AM +0200, Krzysztof Kozlowski wrote: > ARCH_VEXPRESS_CA9X4 is gone since commit 81cc3f868d30 ("ARM: vexpress: > Remove non-DT code"). > > Signed-off-by: Krzysztof KozlowskiAcked-by: Liviu Dudau Thanks for the cleanup! Best regards, Liviu > --- > arch/arm/configs/vexpress_defconfig | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/arm/configs/vexpress_defconfig > b/arch/arm/configs/vexpress_defconfig > index 0fa0ed577b15..edae1c58fe80 100644 > --- a/arch/arm/configs/vexpress_defconfig > +++ b/arch/arm/configs/vexpress_defconfig > @@ -19,7 +19,6 @@ CONFIG_MODULE_UNLOAD=y > # CONFIG_IOSCHED_DEADLINE is not set > # CONFIG_IOSCHED_CFQ is not set > CONFIG_ARCH_VEXPRESS=y > -CONFIG_ARCH_VEXPRESS_CA9X4=y > CONFIG_ARCH_VEXPRESS_DCSCB=y > CONFIG_ARCH_VEXPRESS_TC2_PM=y > # CONFIG_SWP_EMULATE is not set > -- > 2.7.4 > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯
[PULL REQUEST: Renesas Drivers] vsp1/pa-improvements (v2)
Hi Geert, Please consider the following for integration in Renesas Drivers This branch (based on a vanilla v4.13-rc1) has been tested successfully on a Salvator-X (ES 1.0) and Salvator-XS (ES 2.0) (with 5 iterations of the tests each) The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877: Linux v4.13-rc1 (2017-07-15 15:22:10 -0700) are available in the git repository at: g...@gitolite.kernel.org:pub/scm/linux/kernel/git/kbingham/rcar.git vsp1/pa-improvements/v2 for you to fetch changes up to 0bc6b19d31e26b4ee0b5cddff249a9b9493a5d7f: v4l: vsp1: Allow entities to participate in the partition algorithm (2017-07-17 09:53:18 +0100) Kieran Bingham (6): v4l: vsp1: Move vsp1_video_pipeline_setup_partitions() function v4l: vsp1: Calculate partition sizes at stream start. v4l: vsp1: Remove redundant context variables v4l: vsp1: Move partition rectangles to struct and operate directly v4l: vsp1: Provide UDS register updates v4l: vsp1: Allow entities to participate in the partition algorithm drivers/media/platform/vsp1/vsp1_entity.h | 8 ++ drivers/media/platform/vsp1/vsp1_pipe.c | 22 drivers/media/platform/vsp1/vsp1_pipe.h | 48 - drivers/media/platform/vsp1/vsp1_regs.h | 14 +++ drivers/media/platform/vsp1/vsp1_rpf.c| 31 +++--- drivers/media/platform/vsp1/vsp1_sru.c| 30 ++ drivers/media/platform/vsp1/vsp1_uds.c| 43 +++- drivers/media/platform/vsp1/vsp1_video.c | 163 +- drivers/media/platform/vsp1/vsp1_wpf.c| 33 -- 9 files changed, 289 insertions(+), 103 deletions(-)
Re: clk: renesas: rcar-gen3: Fix error return code in cpg_sd_clock_recalc_rate
Scrap my response from before, please. Not sure myself what I was trying to defend :/ signature.asc Description: PGP signature
Re: clk: renesas: rcar-gen3: Fix error return code in cpg_sd_clock_recalc_rate
> I do not mean that -EINVAL is correct. Obviously it isn't. But blindly > replacing -EINVAL by zero may not be the right solution neither. Okay, it may not be perfect but it is definately better :) signature.asc Description: PGP signature
Re: clk: renesas: rcar-gen3: Fix error return code in cpg_sd_clock_recalc_rate
Hi Wolfram, On Mon, Jul 17, 2017 at 11:18 AM, Wolfram Sangwrote: >> >> In .recalc_rate of struct clk_ops, it is desirable to return 0 if an >> >> error occurs, but -EINVAL is returned. This patch fixes it. >> >> >> >> Fixes: 5b1defde7054 ("clk: renesas: cpg-mssr: Extract common R-Car Gen3 >> >> support code") >> >> Signed-off-by: Takeshi Kihara >> >> Signed-off-by: Yoshihiro Kaneko >> > >> > Reviewed-by: Wolfram Sang >> >> Why is it desirable to return 0 if an error occurs? Because the return type >> is >> unsigned long? > > Yes, I'd think so. Instead of an arbitrary high, kind-of-random, number, just > return 0 which also indicates that something unexpected happened? Also, all > other drivers return zero in an error case (did some quick coccinelle > grepping before). OK. >> Is this routine allowed to fail? I don't see any handling of zero by >> its callers. > > From clk-provider.h: > > * @recalc_rate Recalculate the rate of this clock, by querying hardware. The > * parent rate is an input parameter. It is up to the caller to > * ensure that the prepare_mutex is held across this call. > * Returns the calculated rate. Optional, but recommended - if > * this op is not set then clock rate will be initialized to 0. > > What would be the benefit of keeping -EINVAL in an unsigned long? I do not mean that -EINVAL is correct. Obviously it isn't. But blindly replacing -EINVAL by zero may not be the right solution neither. If recalc_rate cannot return an error value, perhaps there is a good reason for that? I see there's a similar check in cpg_sd_clock_enable(), so the clock also cannot be enabled if this condition is met? When does this happen? If the firmware leaves a invalid/unsupported setting in the register? If we can't recover from that, perhaps the clock's probe should just fail instead? It looks like the only writer of that field is cpg_sd_clock_set_rate(), which always writes a valid/supported value. Is it guaranteed that this function is always called first? If yes, the checks can just be removed instead? 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: clk: renesas: rcar-gen3: Fix error return code in cpg_sd_clock_recalc_rate
Hi Geert, > >> In .recalc_rate of struct clk_ops, it is desirable to return 0 if an > >> error occurs, but -EINVAL is returned. This patch fixes it. > >> > >> Fixes: 5b1defde7054 ("clk: renesas: cpg-mssr: Extract common R-Car Gen3 > >> support code") > >> Signed-off-by: Takeshi Kihara> >> Signed-off-by: Yoshihiro Kaneko > > > > Reviewed-by: Wolfram Sang > > Why is it desirable to return 0 if an error occurs? Because the return type is > unsigned long? Yes, I'd think so. Instead of an arbitrary high, kind-of-random, number, just return 0 which also indicates that something unexpected happened? Also, all other drivers return zero in an error case (did some quick coccinelle grepping before). > > Is this routine allowed to fail? I don't see any handling of zero by > its callers. From clk-provider.h: * @recalc_rate Recalculate the rate of this clock, by querying hardware. The * parent rate is an input parameter. It is up to the caller to * ensure that the prepare_mutex is held across this call. * Returns the calculated rate. Optional, but recommended - if * this op is not set then clock rate will be initialized to 0. What would be the benefit of keeping -EINVAL in an unsigned long? Regards, Wolfram signature.asc Description: PGP signature
Re: [RFC] pinctrl: sh-pfc: propagate errors on group config
On Mon, Jun 20, 2016 at 8:40 AM, Wolfram Sangwrote: > From: Wolfram Sang > > On group configuration, bail out if setting one of the individual pins > fails. We don't need to roll-back, the pinctrl core will do this for us. > > Signed-off-by: Wolfram Sang > --- > > Tested on a Lager and Salvator-X without problems. Needs probably more testing > on various HW to avoid regressions? Queueing in sh-pfc-for-v4.14, now commit 13132b3f44d36009 ("ARM: dts: armadillo800eva: Split LCD mux and gpio") is in v4.13-rc1. 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 net-next repost v2] dt-bindings: net: ravb : Add support for r8a7743 SoC
Add a new compatible string for the RZ/G1M (R8A7743) SoC. Signed-off-by: Biju DasReviewed-by: Geert Uytterhoeven Reviewed-by: Simon Horman --- v1->v2 * Changed the subject * re-formatted the required properties .../devicetree/bindings/net/renesas,ravb.txt | 29 +- 1 file changed, 17 insertions(+), 12 deletions(-) diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt b/Documentation/devicetree/bindings/net/renesas,ravb.txt index b519503..4717bc2 100644 --- a/Documentation/devicetree/bindings/net/renesas,ravb.txt +++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt @@ -4,19 +4,24 @@ This file provides information on what the device node for the Ethernet AVB interface contains. Required properties: -- compatible: "renesas,etheravb-r8a7790" if the device is a part of R8A7790 SoC. - "renesas,etheravb-r8a7791" if the device is a part of R8A7791 SoC. - "renesas,etheravb-r8a7792" if the device is a part of R8A7792 SoC. - "renesas,etheravb-r8a7793" if the device is a part of R8A7793 SoC. - "renesas,etheravb-r8a7794" if the device is a part of R8A7794 SoC. - "renesas,etheravb-r8a7795" if the device is a part of R8A7795 SoC. - "renesas,etheravb-r8a7796" if the device is a part of R8A7796 SoC. - "renesas,etheravb-rcar-gen2" for generic R-Car Gen 2 compatible interface. - "renesas,etheravb-rcar-gen3" for generic R-Car Gen 3 compatible interface. +- compatible: Must contain one or more of the following: + - "renesas,etheravb-r8a7743" for the R8A7743 SoC. + - "renesas,etheravb-r8a7790" for the R8A7790 SoC. + - "renesas,etheravb-r8a7791" for the R8A7791 SoC. + - "renesas,etheravb-r8a7792" for the R8A7792 SoC. + - "renesas,etheravb-r8a7793" for the R8A7793 SoC. + - "renesas,etheravb-r8a7794" for the R8A7794 SoC. + - "renesas,etheravb-rcar-gen2" as a fallback for the above + R-Car Gen2 and RZ/G1 devices. - When compatible with the generic version, nodes must list the - SoC-specific version corresponding to the platform first - followed by the generic version. + - "renesas,etheravb-r8a7795" for the R8A7795 SoC. + - "renesas,etheravb-r8a7796" for the R8A7796 SoC. + - "renesas,etheravb-rcar-gen3" as a fallback for the above + R-Car Gen3 devices. + + When compatible with the generic version, nodes must list the + SoC-specific version corresponding to the platform first followed by + the generic version. - reg: offset and length of (1) the register block and (2) the stream buffer. - interrupts: A list of interrupt-specifiers, one for each entry in -- 1.9.1
Re: [PATCH 3/3] ARM: dts: r8a7794: Use R-Car Gen 2 fallback binding for vin nodes
On Tue, Jul 11, 2017 at 2:56 PM, Simon Hormanwrote: > Use R-Car Gen 2 fallback binding for vind nodes in DT for r8a7794 SoC. > > This has no run-time effect for the current driver as the initialisation > sequence is the same for the SoC-specific binding for r8a7794 and the > fallback binding for R-Car Gen 2 > > Signed-off-by: Simon Horman Reviewed-by: Geert Uytterhoeven 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] ARM: dts: r8a7791: Use R-Car Gen 2 fallback binding for vin nodes
On Tue, Jul 11, 2017 at 2:56 PM, Simon Hormanwrote: > Use R-Car Gen 2 fallback binding for vind nodes in DT for r8a7791 SoC. > > This has no run-time effect for the current driver as the initialisation > sequence is the same for the SoC-specific binding for r8a7791 and the > fallback binding for R-Car Gen 2 > > Signed-off-by: Simon Horman Reviewed-by: Geert Uytterhoeven 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] ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for vin nodes
On Tue, Jul 11, 2017 at 2:56 PM, Simon Hormanwrote: > Use R-Car Gen 2 fallback binding for vind nodes in DT for r8a7790 SoC. > > This has no run-time effect for the current driver as the initialisation > sequence is the same for the SoC-specific binding for r8a7790 and the > fallback binding for R-Car Gen 2 > > Signed-off-by: Simon Horman Reviewed-by: Geert Uytterhoeven 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] arm64: dts: renesas: salvator-common: Remove extra LVDS port label
On Thu, Jul 13, 2017 at 2:17 PM, Laurent Pinchartwrote: > The DU LVDS output is on port 3 on R8A7795 but on port 2 on R8A7796. The > lvds_connector label thus can't be defined in salvator-common.dtsi, > common to the two SoCs. > > The lvds_connector label is meant for convience to be referenced from > panel device tree files, such as r8a77xx-aa104xd12-panel.dtsi or > r8a77xx-aa121td01-panel.dtsi. As those files are not included in any > device tree source, and the label never used elsewhere, we can simply > remove it. Out-of-tree patches that include panel device tree files can > then add a > > #define lvds_connector du_out_lvds0 > > before including the panel device tree file. > > Signed-off-by: Laurent Pinchart Reviewed-by: Geert Uytterhoeven 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: clk: renesas: rcar-gen3: Fix error return code in cpg_sd_clock_recalc_rate
Hi Wolfram, Kaneko-san, On Fri, Jul 14, 2017 at 4:25 PM, Wolfram Sangwrote: > On Thu, Apr 20, 2017 at 02:46:33AM +0900, Yoshihiro Kaneko wrote: >> From: Takeshi Kihara >> >> In .recalc_rate of struct clk_ops, it is desirable to return 0 if an >> error occurs, but -EINVAL is returned. This patch fixes it. >> >> Fixes: 5b1defde7054 ("clk: renesas: cpg-mssr: Extract common R-Car Gen3 >> support code") >> Signed-off-by: Takeshi Kihara >> Signed-off-by: Yoshihiro Kaneko > > Reviewed-by: Wolfram Sang Why is it desirable to return 0 if an error occurs? Because the return type is unsigned long? Is this routine allowed to fail? I don't see any handling of zero by its callers. 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] drm: rcar-du: Setup planes before enabling CRTC to avoid flicker
Hi Maxime, On 17/07/17 07:32, Maxime Ripard wrote: > On Thu, Jul 13, 2017 at 05:25:08PM +0100, Kieran Bingham wrote: > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c > b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > index 82b978a5dae6..c2f382feca07 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > @@ -255,9 +255,9 @@ static void rcar_du_atomic_commit_tail(struct > drm_atomic_state *old_state) > > /* Apply the atomic update. */ > drm_atomic_helper_commit_modeset_disables(dev, old_state); > - drm_atomic_helper_commit_modeset_enables(dev, old_state); > drm_atomic_helper_commit_planes(dev, old_state, > DRM_PLANE_COMMIT_ACTIVE_ONLY); Except for DRM_PLANE_COMMIT_ACTIVE_ONLY, this function now looks very much like the default drm_atomic_helper_commit_tail() code. Reading around other uses /variants of commit_tail() style functions in other drivers has left me confused as to how the ordering affects things here. Could be worth adding a comment at least to describe why we can't use the default helper... >>> >>> Or better still ... Use Maxime's new : >>> >>> [PATCH 1/4] drm/atomic: implement drm_atomic_helper_commit_tail for >>> runtime_pm users >> >> Never mind - I've just looked again, and seen that this new helper function >> is >> the ordering previous to *this* patch, and therefore isn't the same. >> >> However - it's worth noting that Maxime's patch converts this function to the >> new helper - which contradicts this patch's motivations. > > So I guess I should drop the renesas modifications in my serie then? Yes, Please. I think we have a few extra modifications in this function as well which will take it further away from a default implementation. Regards Kieran > > Maxime >
Re: [PATCH 2/6] ARM: shmobile_defconfig: Cleanup from non-existing options
Hi Krzysztof, On Mon, Jul 17, 2017 at 7:49 AM, Krzysztof Kozlowskiwrote: > Remove options which do not exist anymore: > - DRM_RCAR_HDMI was merged to generic DRM bridge and is obsolete since >commit 5c602531feb3 ("drm: rcar-du: Replace manual bridge >implementation with DRM bridge"); > > - SND_SOC_RSRC_CARD was replaced by SND_SIMPLE_SCU_CARD in commit >d12c6216c4a5 ("ASoC: rsrc-card: rename rsrc-card to simple-scu-card >phase3"); > > Signed-off-by: Krzysztof Kozlowski These have already be fixed in the defconfig-for-v4.14 branch Simon Horman's tree (git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git). https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git/log/?h=defconfig-for-v4.14 They're not yet in -next as v4.13-rc1 wasn't released at that time, and Simon is now on holidays. 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/6] ARM: multi_v7_defconfig: Cleanup from non-existing options
Hi Krzysztof, On Mon, Jul 17, 2017 at 7:49 AM, Krzysztof Kozlowskiwrote: > Remove options which do not exist anymore: > - DRM_RCAR_HDMI was merged to generic DRM bridge and is obsolete since >commit 5c602531feb3 ("drm: rcar-du: Replace manual bridge >implementation with DRM bridge"); > > - SND_SOC_RSRC_CARD was replaced by SND_SIMPLE_SCU_CARD in commit >d12c6216c4a5 ("ASoC: rsrc-card: rename rsrc-card to simple-scu-card >phase3"); These have already be fixed in the defconfig-for-v4.14 branch Simon Horman's tree (git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git). They're not yet in -next as v4.13-rc1 wasn't released at that time, and Simon is noew on holidays. 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 4/4] drm/sun4i: make sure we don't have a commit pending
On Mon, Jul 17, 2017 at 2:55 PM, Maxime Ripardwrote: > On Fri, Jul 14, 2017 at 04:56:01PM +0800, Chen-Yu Tsai wrote: >> Hi, >> >> On Thu, Jul 13, 2017 at 10:41 PM, Maxime Ripard >> wrote: >> > In the earlier display engine designs, any register access while a commit >> > is pending is forbidden. >> > >> > One of the symptoms is that reading a register will return another, random, >> > register value which can lead to register corruptions if we ever do a >> > read/modify/write cycle. >> >> Alternatively, if changes to the backend (layers) are guaranteed to happen >> while the CRTC is disabled (which seems to be the case after looking at >> drm_atomic_helper_commit_planes and drm_atomic_helper_commit_tail), we >> could just turn on register auto-commit all the time and not deal with >> this. > > As far as I understand, it will only be the case if we need a new > modeset or we changed the active CRTC or connectors. But if you change > only the format, buffers or properties it won't be the case, and we'll > need to commit. So in other words, if someone were to use it for actual compositing and moved the upper composited layer around, we would need commit support to be safe. Sounds more or less like something a video player would do. Thanks ChenYu
Re: [PATCH 4/4] drm/sun4i: make sure we don't have a commit pending
On Fri, Jul 14, 2017 at 04:56:01PM +0800, Chen-Yu Tsai wrote: > Hi, > > On Thu, Jul 13, 2017 at 10:41 PM, Maxime Ripard >wrote: > > In the earlier display engine designs, any register access while a commit > > is pending is forbidden. > > > > One of the symptoms is that reading a register will return another, random, > > register value which can lead to register corruptions if we ever do a > > read/modify/write cycle. > > Alternatively, if changes to the backend (layers) are guaranteed to happen > while the CRTC is disabled (which seems to be the case after looking at > drm_atomic_helper_commit_planes and drm_atomic_helper_commit_tail), we > could just turn on register auto-commit all the time and not deal with > this. As far as I understand, it will only be the case if we need a new modeset or we changed the active CRTC or connectors. But if you change only the format, buffers or properties it won't be the case, and we'll need to commit. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH] drm: rcar-du: Setup planes before enabling CRTC to avoid flicker
On Thu, Jul 13, 2017 at 05:25:08PM +0100, Kieran Bingham wrote: > >>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c > >>> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > >>> index 82b978a5dae6..c2f382feca07 100644 > >>> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c > >>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > >>> @@ -255,9 +255,9 @@ static void rcar_du_atomic_commit_tail(struct > >>> drm_atomic_state *old_state) > >>> > >>> /* Apply the atomic update. */ > >>> drm_atomic_helper_commit_modeset_disables(dev, old_state); > >>> - drm_atomic_helper_commit_modeset_enables(dev, old_state); > >>> drm_atomic_helper_commit_planes(dev, old_state, > >>> DRM_PLANE_COMMIT_ACTIVE_ONLY); > >> > >> Except for DRM_PLANE_COMMIT_ACTIVE_ONLY, this function now looks very much > >> like > >> the default drm_atomic_helper_commit_tail() code. > >> > >> Reading around other uses /variants of commit_tail() style functions in > >> other > >> drivers has left me confused as to how the ordering affects things here. > >> > >> Could be worth adding a comment at least to describe why we can't use the > >> default helper... > > > > Or better still ... Use Maxime's new : > > > > [PATCH 1/4] drm/atomic: implement drm_atomic_helper_commit_tail for > > runtime_pm users > > Never mind - I've just looked again, and seen that this new helper function is > the ordering previous to *this* patch, and therefore isn't the same. > > However - it's worth noting that Maxime's patch converts this function to the > new helper - which contradicts this patch's motivations. So I guess I should drop the renesas modifications in my serie then? Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature