* Re: [PATCH 4/9] dt-bindings: dma: renesas,rcar-dmac: Document R8A774E1 bindings
From: Vinod Koul @ 2020-07-15 10:40 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Geert Uytterhoeven, Rob Herring, Linus Walleij,
Bartosz Golaszewski, Joerg Roedel, Sergei Shtylyov,
David S. Miller, Jakub Kicinski, Magnus Damm, Yoshihiro Shimoda,
dmaengine, devicetree, linux-gpio, iommu, netdev,
linux-renesas-soc, linux-kernel, Prabhakar
In-Reply-To: <1594676120-5862-5-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On 13-07-20, 22:35, Lad Prabhakar wrote:
> Renesas RZ/G2H (R8A774E1) SoC also has the R-Car gen3 compatible
> DMA controllers, therefore document RZ/G2H specific bindings.
Applied, thanks
--
~Vinod
^ permalink raw reply
* Re: [PATCH 9/9] arm64: dts: renesas: r8a774e1: Add Ethernet AVB node
From: Geert Uytterhoeven @ 2020-07-15 10:21 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Vinod Koul, Rob Herring, Linus Walleij, Bartosz Golaszewski,
Joerg Roedel, Sergei Shtylyov, David S. Miller, Jakub Kicinski,
Magnus Damm, Yoshihiro Shimoda, dmaengine,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:GPIO SUBSYSTEM, Linux IOMMU, netdev, Linux-Renesas,
Linux Kernel Mailing List, Prabhakar
In-Reply-To: <1594676120-5862-10-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Mon, Jul 13, 2020 at 11:36 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> From: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
>
> This patch adds the SoC specific part of the Ethernet AVB
> device tree node.
>
> Signed-off-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v5.9.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 7/9] arm64: dts: renesas: r8a774e1: Add GPIO device nodes
From: Geert Uytterhoeven @ 2020-07-15 10:21 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Vinod Koul, Rob Herring, Linus Walleij, Bartosz Golaszewski,
Joerg Roedel, Sergei Shtylyov, David S. Miller, Jakub Kicinski,
Magnus Damm, Yoshihiro Shimoda, dmaengine,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:GPIO SUBSYSTEM, Linux IOMMU, netdev, Linux-Renesas,
Linux Kernel Mailing List, Prabhakar
In-Reply-To: <1594676120-5862-8-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Mon, Jul 13, 2020 at 11:35 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> From: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
>
> Add GPIO device nodes to the DT of the r8a774e1 SoC.
>
> Signed-off-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v5.9.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 5/9] arm64: dts: renesas: r8a774e1: Add SYS-DMAC device nodes
From: Geert Uytterhoeven @ 2020-07-15 10:20 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Vinod Koul, Rob Herring, Linus Walleij, Bartosz Golaszewski,
Joerg Roedel, Sergei Shtylyov, David S. Miller, Jakub Kicinski,
Magnus Damm, Yoshihiro Shimoda, dmaengine,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:GPIO SUBSYSTEM, Linux IOMMU, netdev, Linux-Renesas,
Linux Kernel Mailing List, Prabhakar
In-Reply-To: <1594676120-5862-6-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Mon, Jul 13, 2020 at 11:35 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> From: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
>
> Add sys-dmac[0-2] device nodes for RZ/G2H (R8A774E1) SoC.
>
> Signed-off-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v5.9.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 3/9] arm64: dts: renesas: r8a774e1: Add IPMMU device nodes
From: Geert Uytterhoeven @ 2020-07-15 10:18 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Vinod Koul, Rob Herring, Linus Walleij, Bartosz Golaszewski,
Joerg Roedel, Sergei Shtylyov, David S. Miller, Jakub Kicinski,
Magnus Damm, Yoshihiro Shimoda, dmaengine,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:GPIO SUBSYSTEM, Linux IOMMU, netdev, Linux-Renesas,
Linux Kernel Mailing List, Prabhakar
In-Reply-To: <1594676120-5862-4-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Mon, Jul 13, 2020 at 11:35 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> From: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
>
> Add RZ/G2H (R8A774E1) IPMMU nodes.
>
> Signed-off-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v5.9.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] gpio: omap: handle pin config bias flags
From: Grygorii Strashko @ 2020-07-15 10:09 UTC (permalink / raw)
To: Drew Fustini, Tony Lindgren, Linus Walleij, Bartosz Golaszewski,
Santosh Shilimkar, Kevin Hilman, linux-omap, linux-gpio,
linux-kernel
In-Reply-To: <20200709223401.780051-1-drew@beagleboard.org>
On 10/07/2020 01:34, Drew Fustini wrote:
> Modify omap_gpio_set_config() to handle pin config bias flags by calling
> gpiochip_generic_config().
>
> The pin group for the gpio line must have the corresponding pinconf
> properties:
>
> PIN_CONFIG_BIAS_PULL_UP requires "pinctrl-single,bias-pullup"
> PIN_CONFIG_BIAS_PULL_DOWN requires "pinctrl-single,bias-pulldown"
>
> This is necessary for pcs_pinconf_set() to find the requested bias
> parameter in the PIN_MAP_TYPE_CONFIGS_GROUP pinctrl map.
>
> Signed-off-by: Drew Fustini <drew@beagleboard.org>
> ---
> drivers/gpio/gpio-omap.c | 21 +++++++++++++++++----
> 1 file changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index b8e2ecc3eade..a471a152f318 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -896,12 +896,25 @@ static int omap_gpio_set_config(struct gpio_chip *chip, unsigned offset,
> unsigned long config)
> {
> u32 debounce;
> + int ret;
ret = -ENOTSUPP;
>
> - if (pinconf_to_config_param(config) != PIN_CONFIG_INPUT_DEBOUNCE)
> - return -ENOTSUPP;
> + if ((pinconf_to_config_param(config) == PIN_CONFIG_BIAS_DISABLE) ||
> + (pinconf_to_config_param(config) == PIN_CONFIG_BIAS_PULL_UP) ||
> + (pinconf_to_config_param(config) == PIN_CONFIG_BIAS_PULL_DOWN))
> + {
> + ret = gpiochip_generic_config(chip, offset, config);
> + }
> + else if (pinconf_to_config_param(config) == PIN_CONFIG_INPUT_DEBOUNCE)
> + {
> + debounce = pinconf_to_config_argument(config);
> + ret = omap_gpio_debounce(chip, offset, debounce);
> + }
> + else
> + {
> + ret = -ENOTSUPP;
> + }
drop above "else"?
>
> - debounce = pinconf_to_config_argument(config);
> - return omap_gpio_debounce(chip, offset, debounce);
> + return ret;
> }
>
> static void omap_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
>
Minor comment, Otherwise:
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
--
Best regards,
grygorii
^ permalink raw reply
* [PATCH v10.1 3/4] dt-bindings: media: i2c: Add bindings for IMI RDACM2x
From: Kieran Bingham @ 2020-07-15 9:43 UTC (permalink / raw)
To: linux-renesas-soc, linux-media, linux-gpio, devicetree,
linux-kernel, Mauro Carvalho Chehab, sakari.ailus, Rob Herring
Cc: Kieran Bingham, Laurent Pinchart, Jacopo Mondi,
Niklas Söderlund, Hans Verkuil, Hyun Kwon,
Manivannan Sadhasivam, Linus Walleij, Jacopo Mondi,
Kieran Bingham, Rob Herring
In-Reply-To: <20200612144713.502006-4-kieran.bingham+renesas@ideasonboard.com>
From: Jacopo Mondi <jacopo+renesas@jmondi.org>
The IMI RDACM20 and IMI RDACM21 are Gigabit Multimedia Serial Link
(GMSL) camera capable of transmitting video and I2C control messages on
a coax cable physical link for automotive applications.
Document their device tree bindings.
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
v2:
- Provide imi vendor prefix
- Fix minor spelling
v3:
- update binding descriptions
v4:
- No change
v5:
- Specify optional third reg address for the MCU
v7:
[Jacopo]
- Rename to imi,rdacm2x-gmsl.yaml
- Exand bindings to describe RDACM21
v9:
[Jacopo]
- Rework 'compatible' property as suggested by Rob
- Re-order vendor prefixes ('g' comes before 'i' ... )
- Add Rob's tag
v10.1:
[Kieran]
- Fix up the two examples 'reg' value for the i2c nodes.
.../bindings/media/i2c/imi,rdacm2x-gmsl.yaml | 159 ++++++++++++++++++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
2 files changed, 161 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml
diff --git a/Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml b/Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml
new file mode 100644
index 000000000000..5ad4b8c356cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml
@@ -0,0 +1,159 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+# Copyright (C) 2019 Renesas Electronics Corp.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/imi,rdacm2x-gmsl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: IMI D&D RDACM20 and RDACM21 Automotive Camera Platforms
+
+maintainers:
+ - Jacopo Mondi <jacopo+renesas@jmondi.org>
+ - Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
+ - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
+ - Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
+
+description: -|
+ The IMI D&D RDACM20 and RDACM21 are GMSL-compatible camera designed for
+ automotive applications.
+
+ The RDACM20 camera module encloses a Maxim Integrated MAX9271 GMSL serializer,
+ coupled with an OV10635 image sensor and an embedded MCU. Both the MCU and
+ the image sensor are connected to the serializer local I2C bus and are
+ accessible by the host SoC by direct addressing.
+
+ The RDACM21 camera module encloses the same serializer, coupled with an
+ OV10640 image sensor and an OV490 ISP. Only the OV490 ISP is interfaced to
+ the serializer local I2C bus while the image sensor is not accessible from
+ the host SoC.
+
+ They both connect to a remote GMSL endpoint through a coaxial cable.
+
+ IMI RDACM20
+ +---------------+ +--------------------------------+
+ | GMSL | <- Video Stream | <- Video--------\ |
+ | |< === GMSL Link ====== >|MAX9271<- I2C bus-> <-->OV10635 |
+ | de-serializer | <- I2C messages -> | \<-->MCU |
+ +---------------+ +--------------------------------+
+
+ IMI RDACM21
+ +---------------+ +--------------------------------+
+ | GMSL | <- Video Stream | <- Video--------\ |
+ | |< === GMSL Link ====== >|MAX9271<- I2C bus-> <-->OV490 |
+ | | <- I2C messages -> | | |
+ | de-serializer | | OV10640 <-------| |
+ +---------------+ +--------------------------------+
+
+ Both camera modules serialize video data generated by the embedded camera
+ sensor on the GMSL serial channel to a remote GMSL de-serializer. They also
+ receive and transmit I2C messages encapsulated and transmitted on the GMSL
+ bidirectional control channel.
+
+ All I2C traffic received on the GMSL link not directed to the serializer is
+ propagated on the local I2C bus to the remote device there connected. All the
+ I2C traffic generated on the local I2C bus not directed to the serializer is
+ propagated to the remote de-serializer encapsulated in the GMSL control
+ channel.
+
+ The RDACM20 and RDACM21 DT node should be a direct child of the GMSL
+ deserializer's I2C bus corresponding to the GMSL link that the camera is
+ attached to.
+
+properties:
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ compatible:
+ enum:
+ - imi,rdacm20
+ - imi,rdacm21
+
+ reg:
+ description: -|
+ I2C device addresses, the first to be assigned to the serializer, the
+ following ones to be assigned to the remote devices.
+
+ For RDACM20 the second entry of the property is assigned to the
+ OV10635 image sensor and the optional third one to the embedded MCU.
+
+ For RDACM21 the second entry is assigned to the OV490 ISP and the optional
+ third one ignored.
+
+ minItems: 2
+ maxItems: 3
+
+ port:
+ type: object
+ additionalProperties: false
+ description: -|
+ Connection to the remote GMSL endpoint are modelled using the OF graph
+ bindings in accordance with the video interface bindings defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+ The device node contains a single "port" child node with a single
+ "endpoint" sub-device.
+
+ properties:
+ endpoint:
+ type: object
+ additionalProperties: false
+
+ properties:
+ remote-endpoint:
+ description: -|
+ phandle to the remote GMSL endpoint sub-node in the remote node
+ port.
+ maxItems: 1
+
+ required:
+ - remote-endpoint
+
+ required:
+ - endpoint
+
+required:
+ - compatible
+ - reg
+ - port
+
+examples:
+ - |
+ i2c@e66d8000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg = <0 0xe66d8000>;
+
+ camera@31 {
+ compatible = "imi,rdacm20";
+ reg = <0x31>, <0x41>, <0x51>;
+
+ port {
+ rdacm20_out0: endpoint {
+ remote-endpoint = <&max9286_in0>;
+ };
+ };
+ };
+ };
+
+ - |
+ i2c@e66d8000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg = <0 0xe66d8000>;
+
+ camera@31 {
+ compatible = "imi,rdacm21";
+ reg = <0x31>, <0x41>;
+
+ port {
+ rdacm21_out0: endpoint {
+ remote-endpoint = <&max9286_in0>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 9aeab66be85f..8261ede298f8 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -469,6 +469,8 @@ patternProperties:
description: ILI Technology Corporation (ILITEK)
"^img,.*":
description: Imagination Technologies Ltd.
+ "^imi,.*":
+ description: Integrated Micro-Electronics Inc.
"^incircuit,.*":
description: In-Circuit GmbH
"^inet-tek,.*":
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 20/25] pinctrl: pinctrl-rza1: Demote some kerneldoc headers and fix others
From: Geert Uytterhoeven @ 2020-07-15 7:30 UTC (permalink / raw)
To: Lee Jones
Cc: Linus Walleij, Linux Kernel Mailing List,
open list:GPIO SUBSYSTEM, Geert Uytterhoeven, Jacopo Mondi,
Linux-Renesas
In-Reply-To: <20200713144930.1034632-21-lee.jones@linaro.org>
Hi Lee,
On Mon, Jul 13, 2020 at 4:49 PM Lee Jones <lee.jones@linaro.org> wrote:
> Some description blocks are void of any description/documentation,
> others are missing 'struct' identifiers, there are also a couple of
> misspellings of function parameter names. Fix all of them.
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/pinctrl/pinctrl-rza1.c:81: warning: cannot understand function prototype: 'struct rza1_bidir_pin '
> drivers/pinctrl/pinctrl-rza1.c:90: warning: cannot understand function prototype: 'struct rza1_bidir_entry '
> drivers/pinctrl/pinctrl-rza1.c:98: warning: cannot understand function prototype: 'struct rza1_swio_pin '
> drivers/pinctrl/pinctrl-rza1.c:108: warning: cannot understand function prototype: 'struct rza1_swio_entry '
> drivers/pinctrl/pinctrl-rza1.c:116: warning: cannot understand function prototype: 'struct rza1_pinmux_conf '
> drivers/pinctrl/pinctrl-rza1.c:443: warning: cannot understand function prototype: 'struct rza1_mux_conf '
> drivers/pinctrl/pinctrl-rza1.c:462: warning: cannot understand function prototype: 'struct rza1_port '
> drivers/pinctrl/pinctrl-rza1.c:482: warning: cannot understand function prototype: 'struct rza1_pinctrl '
> drivers/pinctrl/pinctrl-rza1.c:546: warning: Function parameter or member 'port' not described in 'rza1_pinmux_get_flags'
> drivers/pinctrl/pinctrl-rza1.c:546: warning: Function parameter or member 'pin' not described in 'rza1_pinmux_get_flags'
> drivers/pinctrl/pinctrl-rza1.c:546: warning: Function parameter or member 'func' not described in 'rza1_pinmux_get_flags'
> drivers/pinctrl/pinctrl-rza1.c:546: warning: Function parameter or member 'rza1_pctl' not described in 'rza1_pinmux_get_flags'
> drivers/pinctrl/pinctrl-rza1.c:575: warning: Function parameter or member 'port' not described in 'rza1_set_bit'
> drivers/pinctrl/pinctrl-rza1.c:575: warning: Function parameter or member 'reg' not described in 'rza1_set_bit'
> drivers/pinctrl/pinctrl-rza1.c:575: warning: Function parameter or member 'bit' not described in 'rza1_set_bit'
> drivers/pinctrl/pinctrl-rza1.c:575: warning: Function parameter or member 'set' not described in 'rza1_set_bit'
> drivers/pinctrl/pinctrl-rza1.c:672: warning: Function parameter or member 'rza1_pctl' not described in 'rza1_pin_mux_single'
> drivers/pinctrl/pinctrl-rza1.c:672: warning: Excess function parameter 'pinctrl' description in 'rza1_pin_mux_single'
>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Jacopo Mondi <jacopo+renesas@jmondi.org>
> Cc: linux-renesas-soc@vger.kernel.org
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in sh-pfc-for-v5.9.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* RE: [PATCH 1/3] gpio: mxc: Support module build
From: Anson Huang @ 2020-07-15 2:44 UTC (permalink / raw)
To: Linus Walleij
Cc: Russell King, Shawn Guo, Sascha Hauer, Sascha Hauer,
Fabio Estevam, Catalin Marinas, Will Deacon, Bartosz Golaszewski,
oleksandr.suvorov@toradex.com, Adam Ford, Andreas Kemnade,
hverkuil-cisco@xs4all.nl, Bjorn Andersson, Leo Li, Vinod Koul,
Geert Uytterhoeven, Olof Johansson, Linux ARM,
linux-kernel@vger.kernel.org, open list:GPIO SUBSYSTEM,
dl-linux-imx
In-Reply-To: <DB3PR0402MB39168FEA9306CBF90A596E31F5630@DB3PR0402MB3916.eurprd04.prod.outlook.com>
Hi, Linus
> Subject: RE: [PATCH 1/3] gpio: mxc: Support module build
>
> Hi, Linus
>
> > Subject: Re: [PATCH 1/3] gpio: mxc: Support module build
> >
> > On Wed, Jul 8, 2020 at 1:28 AM Anson Huang <Anson.Huang@nxp.com>
> > wrote:
> >
> > > subsys_initcall(gpio_mxc_init);
> > > +
> > > +MODULE_AUTHOR("Shawn Guo <shawn.guo@linaro.org>");
> > > +MODULE_DESCRIPTION("i.MX GPIO Driver"); MODULE_LICENSE("GPL");
> >
> > You are making this modualrizable but keeping the subsys_initcall(),
> > which doesn't make very much sense. It is obviously not necessary to
> > do this probe at subsys_initcall() time, right?
> >
>
> If building it as module, the subsys_initcall() will be equal to module_init(), I
> keep it unchanged is because I try to make it identical when built-in, since
> most of the config will still have it built-in, except the Android GKI support.
> Does it make sense?
>
> > Take this opportunity to convert the driver to use
> > module_platform_driver() as well.
>
> If you think it has to be or it is better to use module_platform_driver(), I will do
> it in V2.
I tried to replace the subsys_initcall() with module_platform_driver(), but met issue
about " register_syscore_ops(&mxc_gpio_syscore_ops);" which is called in gpio_mxc_init()
function, this function should be called ONLY once, moving it to .probe function is NOT
working, so we may need to keep the gpio_mxc_init(), that is another reason that we may
need to keep subsys_initcall()?
Thanks,
Anson
^ permalink raw reply
* Re: [PATCH v3 1/5] pinctrl: qcom: Remove irq_disable callback from msmgpio irqchip
From: Doug Anderson @ 2020-07-15 0:08 UTC (permalink / raw)
To: Maulik Shah
Cc: Bjorn Andersson, Marc Zyngier, LinusW, Stephen Boyd, Evan Green,
Matthias Kaehlcke, LKML, linux-arm-msm, open list:GPIO SUBSYSTEM,
Andy Gross, Thomas Gleixner, Jason Cooper, Rajendra Nayak,
Lina Iyer, Srinivas Rao L
In-Reply-To: <723acb53-364a-9045-8dbd-fa2a270798a6@codeaurora.org>
Hi,
On Tue, Jul 14, 2020 at 3:38 AM Maulik Shah <mkshah@codeaurora.org> wrote:
>
> Hi,
>
> On 7/14/2020 3:47 AM, Doug Anderson wrote:
>
> Hi,
>
> On Mon, Jun 22, 2020 at 2:32 AM Maulik Shah <mkshah@codeaurora.org> wrote:
>
> > > The gpio can be marked for wakeup and drivers can invoke disable_irq()
> > > during suspend, in such cases unlazy approach will also disable at HW
> > > and such gpios will not wakeup device from suspend to RAM.
> > >
> > > Remove irq_disable callback to allow gpio interrupts to lazy disabled.
> > > The gpio interrupts will get disabled during irq_mask callback.
> > >
> > > Acked-by: Linus Walleij <linus.walleij@linaro.org>
> > > Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
> > > ---
> > > drivers/pinctrl/qcom/pinctrl-msm.c | 13 -------------
> > > 1 file changed, 13 deletions(-)
> >
> > While the code of this patch looks fairly correct to me (there's no
> > need to implement the irq_disable callback and we can just rely on the
> > masking), I'm slightly anxious about the description. It almost feels
> > like you're somehow relying on the laziness to "fix" your issue here.
>
> i don't think thats the case here. As i have mentioned in previous discussions, reiterating here..
I hadn't followed all the previous discussions, but generally if two
people are independently confused by the same thing it's a sign that
it needs to be explained better. In this case that means a better
commit message that explains exactly why this isn't a problem.
> During suspend there is no way IRQ will be enabled/unmasked in HW even if its marked for wakeup.
>
> All kernel does during suspend is if an IRQ is not marked for wakeup (did not invoke enable_irq_wake())
> then during suspend those IRQs will get disabled/masked in HW to prevent them waking up.
>
> Note that kernel don't do anything for the IRQs that are marked for wakeup. those IRQs are left in its original state.
> by original state, i mean if the IRQ was enabled/unmasked in HW, it will stay as is, if its disabled/masked it will stay same.
> suspend process won't change the state of those IRQs.
>
> Lets take two cases of lazy and unlazy disable/mask.
>
> case-1)
>
> if the irq_chip implements .irq_disable callback, genirq by default takes unlazy path (immediatly disabled in SW + HW).
> if device enters suspend after client driver calls disable_irq(), there is no way to wakeup with such IRQs, even though
> driver choosen to mark it for wakeup. As i told above, kernel leaves such IRQ in its original state (disabled in SW + HW here)
> This is the problem case where we started with.
>
> case -2)
>
> If the irq_chip did not implements .irq_disable callback, genirq takes lazy disable path and only marks IRQ disabled in SW.
> It is still left enabled in HW. This is what current series is implemented for.
OK, I think I understand what you're trying to say. What you're
saying is that the important thing is that when you're using the
kernel's "lazy" mode that the kernel will have knowledge of whether a
disabled IRQ is pending. That's because the IRQ fired once (and the
kernel set IRQS_PENDING) before it got masked. If we're using a
non-lazy case then the IRQ could be pending but the kernel wouldn't
know.
If that's what you're relying on for this patch to work then it
belongs in the commit message.
...but (see below) I don't think it's working like you think it does.
> > ...but the laziness is supposed to just be an optimization.
> > Specifically if an interrupt happens to fire at any point in time
> > after a driver has called disable_irq() then it acts just like a
> > non-lazy disable.
> >
> > Said another way, I think this is a valid thing for a driver to do and
> > it should get woken up if the irq fires in suspend:
> >
> > disable_irq();
> > msleep(1000);
> > enable_irq_wake()
> >
> > Specifically if an IRQ comes in during that sleep then it will be just
> > like you had a non-lazy IRQ.
>
> i don't think, Let me take your example...driver calls below during suspend
>
>
> 1. disable_irq();
> 2. msleep(1000);
> 3. enable_irq_wake();
>
> a) if the IRQ comes in before (1) No issue in this case, its just like during active time if any other IRQ gets handled.
>
> b) if IRQ comes anytime after (1) is over, but (3) is not done (i.e. during msleep())
>
> - genirq will find that IRQ was disabled in SW,
> - driver's IRQ handler will not get called since it was disabled in SW via (1).
> - it will mark pending in SW and then really disables in HW now (lazy disable)
> - next call is enable_irq_wake(), which will mark IRQ as wake up capable and also re-enable in HW from patch-4 of this series
> in PDC driver's .irq_set_wake call...
> if (on) {
> pdc_enable_intr(d, true);
> irq_chip_enable_parent(d);
> set_bit(d->hwirq, pdc_wake_irqs);
> }
> with this IRQ will be left enabled/unmasked in HW.
> - device goes to suspend.
> - since its enabled/unmasked in HW, it will be able to wake up with this IRQ since GIC will forward this IRQ to CPU to wake it up.
...but what if it's an edge interrupt? Then:
1. It will fire.
2. It will get marked as IRQS_PENDING and Acked.
3. It will get masked.
4. Your code will unmask and wake up from future edges but the edge
that already came in won't cause a wakeup, right?
Hrm, though I guess that's just a problem in general. Probably
suspend_device_irq() should check to see if an IRQ is pending? In any
case, at this point in time it's not a bug that is affecting me since
(right now) cros_ec sets the wakeup _before_ disabling, but it
probably should still be fixed.
> c) if IRQ comes in anytime after (3) is done,
>
> - genirq will find that IRQ was disabled in SW
> - driver's IRQ handler will not get called since it was disabled in SW via (1).
> - it will mark pending in SW and then really disables in HW now (lazy disable)
> - it will also notify suspend PM core about this event to abort the suspend since this IRQ was marked for wakeup.
So I tested this and it didn't seem to work. I went into
cros_ec_suspend() and added a delay after the disable_irq() call. I
pressed a key on my keyboard while the delay was happening. When I
pressed the key I saw qcom_pdc_gic_mask() get called for the
interrupt. ...and the suspend was _not_ aborted. I watched and the
system continued all the way.
I watched the system go all the way down and shut down the CPUs.
Then, after 6 seconds (!) it woke back up. I don't quite understand
it, but the 6 seconds here seems to be the time needed to wakeup if
PDC is enabled but the interrupt is masked at the gic level.
Digging a little deeper, I see that in irq_may_run() it was getting true for:
!irqd_has_set(&desc->irq_data, mask)
...and thus it was returning true for irq_may_run() without setting
irq_pm_check_wakeup().
Given that it's not working as you describe it to be working, I feel
like you might need to go back and re-evaluate your approach. I'll
try to spend more time thinking about this tomorrow too, but I'm about
out of time for the day.
> So, in all cases we are fine.
>
>
> So while I'm for this patch, I'd suggest a simpler description
> (assuming my understanding is correct):
>
> There is no reason to implement irq_disable() and irq_mask(). Let's just
> use irq_mask() and let the rest of the core handle it.
>
> i think current description is fine with above explanation.
As per above, if nothing else you need to clarify things so people
aren't so confused.
> Also: it feels really weird to me that you're getting rid of the
> irq_disable() but keeping irq_enable(). That seems like asking for
> trouble, though I'd have to do more research to see if I could figure
> out exactly what might go wrong. Could you remove your irq_enable()
> too?
>
>
> -Doug
>
> irq_enable() servers another purpose of clearing any errornous IRQ when enabling it first time, so its kept as it is.
>
> i do not think it causes any troubles.
I kinda ran out of time to dig more here, but it still worries me.
I'll try to dig more tomorrow. In any case, can't you just clear out
any erroneous IRQs at init time and make it symmetric?
-Doug
^ permalink raw reply
* Re: [PATCH 10/25] pinctrl: mediatek: pinctrl-mtk-common-v2: Mark 'mtk_default_register_base_names' as __maybe_unused
From: Sean Wang @ 2020-07-14 21:21 UTC (permalink / raw)
To: Lee Jones
Cc: Linus Walleij, lkml, open list:GPIO SUBSYSTEM, Matthias Brugger,
moderated list:ARM/Mediatek SoC support
In-Reply-To: <20200713144930.1034632-11-lee.jones@linaro.org>
On Mon, Jul 13, 2020 at 7:49 AM Lee Jones <lee.jones@linaro.org> wrote:
>
> Not all sourcefiles which end up including pinctrl-mtk-common-v2.h make use
> of 'mtk_default_register_base_names' and there is nowhere we can place the
> definition to void the need for __maybe_unused except its own headerfile,
> which seems like overkill. So instead we tell the compiler that it's okay
> for it to be unused by some of the consumers.
>
> Fixes the following W=1 kernel build warning(s):
>
> In file included from drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c:19:
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h:83:27: warning: ‘mtk_default_register_base_names’ defined but not used [-Wunused-const-variable=]
> 83 | static const char const mtk_default_register_base_names[] = {
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from drivers/pinctrl/mediatek/pinctrl-moore.h:25,
> from drivers/pinctrl/mediatek/pinctrl-moore.c:12:
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h:83:27: warning: ‘mtk_default_register_base_names’ defined but not used [-Wunused-const-variable=]
> 83 | static const char const mtk_default_register_base_names[] = {
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from drivers/pinctrl/mediatek/pinctrl-paris.h:27,
> from drivers/pinctrl/mediatek/pinctrl-paris.c:15:
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h:83:27: warning: ‘mtk_default_register_base_names’ defined but not used [-Wunused-const-variable=]
> 83 | static const char const mtk_default_register_base_names[] = {
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from drivers/pinctrl/mediatek/pinctrl-paris.h:27,
> from drivers/pinctrl/mediatek/pinctrl-mtk-mt6797.h:15,
> from drivers/pinctrl/mediatek/pinctrl-mt6797.c:13:
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h:83:27: warning: ‘mtk_default_register_base_names’ defined but not used [-Wunused-const-variable=]
> 83 | static const char const mtk_default_register_base_names[] = {
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from drivers/pinctrl/mediatek/pinctrl-paris.h:27,
> from drivers/pinctrl/mediatek/pinctrl-mtk-mt8183.h:12,
> from drivers/pinctrl/mediatek/pinctrl-mt8183.c:9:
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h:83:27: warning: ‘mtk_default_register_base_names’ defined but not used [-Wunused-const-variable=]
> 83 | static const char const mtk_default_register_base_names[] = {
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from drivers/pinctrl/mediatek/pinctrl-paris.h:27,
> from drivers/pinctrl/mediatek/pinctrl-mtk-mt6765.h:12,
> from drivers/pinctrl/mediatek/pinctrl-mt6765.c:10:
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h:83:27: warning: ‘mtk_default_register_base_names’ defined but not used [-Wunused-const-variable=]
> 83 | static const char const mtk_default_register_base_names[] = {
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Cc: Sean Wang <sean.wang@kernel.org>
> Cc: Matthias Brugger <matthias.bgg@gmail.com>
> Cc: linux-mediatek@lists.infradead.org
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Those MediaTek SoCs with multiple register bases wouldn't refer to the array
Acked-by: Sean Wang <sean.wang@kernel.org>
> ---
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h | 2 +-
^ permalink raw reply
* Re: [PATCH 3/3] pinctrl: add pinctrl driver on mt8192
From: Sean Wang @ 2020-07-14 21:14 UTC (permalink / raw)
To: Zhiyong Tao
Cc: Rob Herring, Linus Walleij, Mark Rutland, Matthias Brugger,
srv_heupstream, hui.liu, Eddie Huang (黃智傑),
Chuanjia Liu (柳传嘉), Biao Huang,
Hongzhou Yang, Erin Lo (羅雅齡),
Sean Wang (王志亘),
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, lkml,
linux-arm Mailing List, moderated list:ARM/Mediatek SoC support,
open list:GPIO SUBSYSTEM
In-Reply-To: <20200710072717.3056-4-zhiyong.tao@mediatek.com>
On Fri, Jul 10, 2020 at 12:28 AM Zhiyong Tao <zhiyong.tao@mediatek.com> wrote:
>
> This commit includes pinctrl driver for mt8192.
>
> Signed-off-by: Zhiyong Tao <zhiyong.tao@mediatek.com>
It is good to see the clean driver with mtk-common-v2.
Acked-by: Sean Wang <sean.wang@kernel.org>
> ---
> drivers/pinctrl/mediatek/Kconfig | 7 +
> drivers/pinctrl/mediatek/Makefile | 1 +
> drivers/pinctrl/mediatek/pinctrl-mt8192.c | 1453 +++++++++++
> drivers/pinctrl/mediatek/pinctrl-mtk-mt8192.h | 2228 +++++++++++++++++
> 4 files changed, 3689 insertions(+)
> create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt8192.c
> create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt8192.h
>
> diff --git a/drivers/pinctrl/mediatek/Kconfig b/drivers/pinctrl/mediatek/Kconfig
> index f32d3644c509..8d5ffc6aa8dc 100644
> --- a/drivers/pinctrl/mediatek/Kconfig
> +++ b/drivers/pinctrl/mediatek/Kconfig
> @@ -121,6 +121,13 @@ config PINCTRL_MT8183
> default ARM64 && ARCH_MEDIATEK
> select PINCTRL_MTK_PARIS
>
> +config PINCTRL_MT8192
> + bool "Mediatek MT8192 pin control"
> + depends on OF
> + depends on ARM64 || COMPILE_TEST
> + default ARM64 && ARCH_MEDIATEK
> + select PINCTRL_MTK_PARIS
> +
<snip>
^ permalink raw reply
* Re: [PATCH v5 07/13] pwm: add support for sl28cpld PWM controller
From: Michael Walle @ 2020-07-14 21:09 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Thierry Reding, linux-gpio, devicetree, linux-kernel, linux-hwmon,
linux-pwm, linux-watchdog, linux-arm-kernel, Linus Walleij,
Bartosz Golaszewski, Rob Herring, Jean Delvare, Guenter Roeck,
Lee Jones, Wim Van Sebroeck, Shawn Guo, Li Yang, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Mark Brown, Greg Kroah-Hartman,
Andy Shevchenko
In-Reply-To: <20200714160856.rjqi7lv63geil3hm@pengutronix.de>
Hi Uwe,
Am 2020-07-14 18:08, schrieb Uwe Kleine-König:
> On Tue, Jul 14, 2020 at 01:31:13PM +0200, Michael Walle wrote:
>> Am 2020-07-13 10:47, schrieb Uwe Kleine-König:
>> > I already thought about proposing pwm_get_rate_hw(), but for now there
>> > is (AFAICT) no user who would need it. And it's hard to know which
>> > variant is actually preferred by consumers. My expectation is that most
>> > don't even care.
>> >
>> > I also have a pwm_round_rate() function in mind that will give you the
>> > actual rate without applying it. This can then be used by consumers who
>> > care. But also there is no user who would need it today.
>>
>> Ok. I take it that all such improvements are still in the making ;)
>
> If you have a real use case, present it, then I give it a boost on my
> todo list.
Not really.
>> > > But the PWM subsystem returns the cached state,
>> > > right? get_state() is called only on device request (and during
>> > > debug it seems). Actually, enabling PWM_DEBUG might choke on this
>> > > workaround (".apply didn't pick the best available period"). Is
>> > > this ok?
>> >
>> > hmm, I didn't consider this when writing the checks for PWM_DEBUG.
>> > According to the currently checked rules the expected configuration is
>> > to pick the 250Hz mode and use cycle = 0x7f.
>>
>> Not to use 0x80, which is the max_duty_cycle? Like its 0x40 for the
>> 500Hz
>> mode.
>
> No, when I thought about a sane set of rules (and so checks for
> PWM_DEBUG) I didn't consider a PWM that can implement 100% but not for
> all otherwise available period lengths. I'm still amazed sometimes how
> different the capabilities of different implementations for something
> so
> seemingly easy like a PWM are.
>
>> > Hmm, I have to think about
>> > this. Maybe we should weaken the check to the cases with
>> > 0 < duty_cycle < period. Thierry, what do you think?
>> >
>> > Special casing 0% and 100% is annoying, but insisting 250Hz + 0x7f seems
>> > to be far from reality. (Is it?)
>>
>> If you mean by insisting to clip at 0x7f, yeah thats bad IMHO, because
>> the user wants an all-high line, but in the end it would be a toggling
>> line. It wouldn't be that bad for anything in between 0% and 100% but
>> IMHO its bad for exactly 0% and 100%.
>>
>> You could also ask the driver about known quirks, like special 0% and
>> 100% handling and exclude it from the tests accordingly.
>
> Do you care enough to propose a patch? You're in the situation to test
> it.
Ok. I'll come up with something outside of this patch series.
>> > > > > + ret = regmap_write(priv->regmap, priv->offset + PWM_CTRL, ctrl);
>> > > > > + if (ret)
>> > > > > + return ret;
>> > > > > +
>> > > > > + return regmap_write(priv->regmap, priv->offset + PWM_CYCLE,
>> > > > > (u8)cycle);
>> > > >
>> > > > I assume this can result in broken output? Consider the hardware runs
>> > > > with mode = 1 & cycle = 0x23 and you want to go to mode = 0 & cycle =
>> > > > 0x42: Can this result in a period that has mode = 0 & cycle = 0x23?
>> > >
>> > > Isn't that always the case if a write may fail and there are more than
>> > > one register to configure?
>> >
>> > Depending on hardware capabilities you might not be able to prevent
>> > this yes. Unfortunately this is quite common.
>> >
>> > But there are hardware implementations that are not prone to such
>> > failures. (E.g. the registers written can be only shadow values that are
>> > latched into hardware only when the last value is written.)
>>
>> Maybe this could be improved in the future.
>
> We should somewhere describe, what an ideal PWM can do.
> My wishlist (just as it comes to my mind, so no guarantee of
> completeness):
>
> - can do 0% duty cycle for all supported period lengths
> - can do 100% duty cycle for all supported period lengths
> - supports both polarities
> - supports immediate change of configuration and after completion of
> the currently running period
> - atomic update (i.e. if you go from configuration A to configuration
> B
> the hardware guarantees to only emit periods of type A and then type
> B. (Depending on the item above, the last A period might be cut
> off.)
We actually discussed this, because the implementation would be easier.
But
if the change takes place immediately you might end up with a longer
duty
cycle. Assume the PWM runs at 80% duty cycle and starts with the
on-period.
If you now change that to 50% you might end up with one successive duty
cycle of "130%". Eg. the 80% of the old and right after that you switch
to
the new 50% and then you'd have a high output which corresponds to a
130%
cycle. I don't know if that is acceptable for all applications.
> - emits an irq when configuration changes
Why would you need the interrupt?
>
>> > If you change only cycle but not mode, does the hardware complete the
>> > currently running period?
>>
>> No it does not.
>
> Please document this as a Limitation.
I've discussed this internally, for now its a limitation. In the worst
case you'd do one 100% duty cycle. Maybe we can fix the hardware. I
acknowledge that this is a severe limitation, esp. if you use the PWM
for controlling stuff (for now its only LCD backlight.. so thats ok).
>> > What about disable()?
>>
>> Mhh well, it would do one 100% cycle.. mhh ;) Lets see if there we can
>> fix that (in hardware), not much we can do in the driver here. We are
>> _very_ constraint in size, therefore all that little edge cases fall
>> off
>> the table.
>
> You're saying that on disable the hardware emits a constant high level
> for one cycle? I hope not ...
Mh, I was mistaken, disabling the PWM will turn it off immediately, but
one 100% duty cycle may happen if you change from a higher to a lower
duty cycle setting. See above.
> I never programmed a CPLD to emulate a hardware PWM, but I wonder if
> these are really edge cases that increase the size of the binary?!
At the moment there is only one 8bit register which stores the value
which is used for matching. If you want to change that setting after
a whole cycle, you'd use another 8bit register to cache the new value.
So this would at least needs 8 additional flip-flops. This doesn't
sound much, but we are already near 100% usage of the CPLD. So its
hard to convince people why this is really necessary.
-michael
^ permalink raw reply
* Re: [PATCH v4 04/16] dt-bindings: pinctrl: sunxi: Add A100 pinctrl bindings
From: Rob Herring @ 2020-07-14 20:51 UTC (permalink / raw)
To: Frank Lee
Cc: liyong, linus.walleij, linux-kernel, robh+dt, tiny.windzz,
huangshuosheng, linux-arm-kernel, wens, linux-gpio, mripard,
devicetree
In-Reply-To: <7be3efafd34cbb5938ea73dfe08f3db3e7747123.1594708864.git.frank@allwinnertech.com>
On Tue, 14 Jul 2020 15:06:23 +0800, Frank Lee wrote:
> From: Yangtao Li <frank@allwinnertech.com>
>
> Add device tree binding Documentation details for A100 pinctrl driver,
> which has a r pin controller and a pin controller with more irq lines.
>
> Signed-off-by: Yangtao Li <frank@allwinnertech.com>
> ---
> .../pinctrl/allwinner,sun4i-a10-pinctrl.yaml | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 03/16] dt-bindings: pinctrl: sunxi: Get rid of continual nesting
From: Rob Herring @ 2020-07-14 20:50 UTC (permalink / raw)
To: Frank Lee
Cc: wens, liyong, linux-kernel, robh+dt, devicetree, linux-arm-kernel,
huangshuosheng, mripard, linus.walleij, tiny.windzz, linux-gpio
In-Reply-To: <b486dc2f07aeb4772af7ee2ed521932582354a34.1594708864.git.frank@allwinnertech.com>
On Tue, 14 Jul 2020 15:03:53 +0800, Frank Lee wrote:
> From: Yangtao Li <frank@allwinnertech.com>
>
> Rather than a continual nesting of 'else' clauses, just make
> each 'if' a new entry under 'allOf' and get rid of the else.
>
> Signed-off-by: Yangtao Li <frank@allwinnertech.com>
> ---
> .../pinctrl/allwinner,sun4i-a10-pinctrl.yaml | 124 ++++++++++--------
> 1 file changed, 68 insertions(+), 56 deletions(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v8 3/7] pinctrl: mediatek: avoid virtual gpio trying to set reg
From: Sean Wang @ 2020-07-14 20:47 UTC (permalink / raw)
To: Hanks Chen
Cc: Linus Walleij, Rob Herring, Matthias Brugger, Michael Turquette,
Stephen Boyd, mtk01761, Andy Teng, open list:GPIO SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-arm Mailing List, moderated list:ARM/Mediatek SoC support,
lkml, wsd_upstream, CC Hwang, Loda Chou, Mars Cheng
In-Reply-To: <1594718402-20813-4-git-send-email-hanks.chen@mediatek.com>
On Tue, Jul 14, 2020 at 2:20 AM Hanks Chen <hanks.chen@mediatek.com> wrote:
>
> for virtual gpios, they should not do reg setting and
> should behave as expected for eint function.
>
> Signed-off-by: Mars Cheng <mars.cheng@mediatek.com>
> Signed-off-by: Hanks Chen <hanks.chen@mediatek.com>
Acked-by: Sean Wang <sean.wang@kernel.org>
> ---
> .../pinctrl/mediatek/pinctrl-mtk-common-v2.c | 25 +++++++++++++++++++
> .../pinctrl/mediatek/pinctrl-mtk-common-v2.h | 1 +
> drivers/pinctrl/mediatek/pinctrl-paris.c | 7 ++++++
> 3 files changed, 33 insertions(+)
^ permalink raw reply
* Re: [PATCH v6 3/7] pinctrl: mediatek: avoid virtual gpio trying to set reg
From: Sean Wang @ 2020-07-14 20:39 UTC (permalink / raw)
To: Linus Walleij
Cc: Hanks Chen, Rob Herring, Matthias Brugger, Michael Turquette,
Stephen Boyd, mtk01761, Andy Teng, open list:GPIO SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, moderated list:ARM/Mediatek SoC support,
linux-kernel@vger.kernel.org, linux-clk, wsd_upstream, CC Hwang,
Loda Chou, Mars Cheng
In-Reply-To: <CACRpkdb5TyictD3j_PE5JtBJmxX87Bk04YkxF1ErsbHwO4TSOg@mail.gmail.com>
> > Sean if you're OK with this patch I can just apply it separately.
>
> Ah nevermind since the next patch has your ACK I just applied this
> too since it's a dependency. Yell if this is wrong.
The patch looks good to me too.
By the way, I didn't see those applied patches in for-next branch yet
I just think Hanks should send those patch based on the top if he has
the next version
>
> Yours,
> Linus Walleij
^ permalink raw reply
* Re: [PATCH v8 2/7] dt-bindings: pinctrl: add bindings for MediaTek MT6779 SoC
From: Rob Herring @ 2020-07-14 20:35 UTC (permalink / raw)
To: Hanks Chen
Cc: linux-gpio, linux-kernel, Rob Herring, Michael Turquette,
Linus Walleij, Loda Chou, Matthias Brugger, Sean Wang,
linux-mediatek, mtk01761, wsd_upstream, linux-arm-kernel,
Stephen Boyd, CC Hwang, devicetree, Andy Teng
In-Reply-To: <1594718402-20813-3-git-send-email-hanks.chen@mediatek.com>
On Tue, 14 Jul 2020 17:19:57 +0800, Hanks Chen wrote:
> From: Andy Teng <andy.teng@mediatek.com>
>
> Add devicetree bindings for MediaTek MT6779 pinctrl driver.
>
> Signed-off-by: Andy Teng <andy.teng@mediatek.com>
> Signed-off-by: Hanks Chen <hanks.chen@mediatek.com>
> ---
> .../pinctrl/mediatek,mt6779-pinctrl.yaml | 203 ++++++++++++++++++
> 1 file changed, 203 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v8 1/7] pinctrl: mediatek: update pinmux definitions for mt6779
From: Rob Herring @ 2020-07-14 20:34 UTC (permalink / raw)
To: Hanks Chen
Cc: Rob Herring, Loda Chou, Linus Walleij, Andy Teng, Stephen Boyd,
linux-mediatek, Matthias Brugger, mtk01761, Michael Turquette,
linux-arm-kernel, Sean Wang, linux-gpio, CC Hwang, linux-kernel,
devicetree, wsd_upstream, Mars Cheng
In-Reply-To: <1594718402-20813-2-git-send-email-hanks.chen@mediatek.com>
On Tue, 14 Jul 2020 17:19:56 +0800, Hanks Chen wrote:
> Add devicetree bindings for Mediatek mt6779 SoC Pin Controller.
>
> Acked-by: Sean Wang <sean.wang@kernel.org>
> Signed-off-by: Mars Cheng <mars.cheng@mediatek.com>
> Signed-off-by: Andy Teng <andy.teng@mediatek.com>
> Signed-off-by: Hanks Chen <hanks.chen@mediatek.com>
> ---
> include/dt-bindings/pinctrl/mt6779-pinfunc.h | 1242 ++++++++++++++++++
> 1 file changed, 1242 insertions(+)
> create mode 100644 include/dt-bindings/pinctrl/mt6779-pinfunc.h
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 19/25] pinctrl: pinctrl-rockchip: Fix a bunch of kerneldoc misdemeanours
From: Heiko Stuebner @ 2020-07-14 18:32 UTC (permalink / raw)
To: Lee Jones
Cc: linus.walleij, linux-kernel, linux-gpio,
Jean-Christophe PLAGNIOL-VILLARD, linux-rockchip
In-Reply-To: <20200713144930.1034632-20-lee.jones@linaro.org>
Am Montag, 13. Juli 2020, 16:49:24 CEST schrieb Lee Jones:
> Demote headers which are clearly not kerneldoc, provide titles for
> struct definition blocks, fix API slip (bitrot) misspellings and
> provide some missing entries.
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/pinctrl/pinctrl-rockchip.c:82: warning: cannot understand function prototype: 'struct rockchip_iomux '
> drivers/pinctrl/pinctrl-rockchip.c:97: warning: Enum value 'DRV_TYPE_IO_DEFAULT' not described in enum 'rockchip_pin_drv_type'
> drivers/pinctrl/pinctrl-rockchip.c:97: warning: Enum value 'DRV_TYPE_IO_1V8_OR_3V0' not described in enum 'rockchip_pin_drv_type'
> drivers/pinctrl/pinctrl-rockchip.c:97: warning: Enum value 'DRV_TYPE_IO_1V8_ONLY' not described in enum 'rockchip_pin_drv_type'
> drivers/pinctrl/pinctrl-rockchip.c:97: warning: Enum value 'DRV_TYPE_IO_1V8_3V0_AUTO' not described in enum 'rockchip_pin_drv_type'
> drivers/pinctrl/pinctrl-rockchip.c:97: warning: Enum value 'DRV_TYPE_IO_3V3_ONLY' not described in enum 'rockchip_pin_drv_type'
> drivers/pinctrl/pinctrl-rockchip.c:97: warning: Enum value 'DRV_TYPE_MAX' not described in enum 'rockchip_pin_drv_type'
> drivers/pinctrl/pinctrl-rockchip.c:106: warning: Enum value 'PULL_TYPE_IO_DEFAULT' not described in enum 'rockchip_pin_pull_type'
> drivers/pinctrl/pinctrl-rockchip.c:106: warning: Enum value 'PULL_TYPE_IO_1V8_ONLY' not described in enum 'rockchip_pin_pull_type'
> drivers/pinctrl/pinctrl-rockchip.c:106: warning: Enum value 'PULL_TYPE_MAX' not described in enum 'rockchip_pin_pull_type'
> drivers/pinctrl/pinctrl-rockchip.c:109: warning: Cannot understand * @drv_type: drive strength variant using rockchip_perpin_drv_type
> on line 109 - I thought it was a doc line
> drivers/pinctrl/pinctrl-rockchip.c:122: warning: Cannot understand * @reg_base: register base of the gpio bank
> on line 109 - I thought it was a doc line
> drivers/pinctrl/pinctrl-rockchip.c:325: warning: Function parameter or member 'route_location' not described in 'rockchip_mux_route_data'
> drivers/pinctrl/pinctrl-rockchip.c:328: warning: Cannot understand */
> on line 109 - I thought it was a doc line
> drivers/pinctrl/pinctrl-rockchip.c:375: warning: Function parameter or member 'data' not described in 'rockchip_pin_group'
> drivers/pinctrl/pinctrl-rockchip.c:387: warning: Function parameter or member 'ngroups' not described in 'rockchip_pmx_func'
>
> Cc: Heiko Stuebner <heiko@sntech.de>
> Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Cc: linux-rockchip@lists.infradead.org
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Thanks for fixing these doc issues
^ permalink raw reply
* Re: [PATCH 07/25] pinctrl: samsung: pinctrl-s3c24xx: Fix formatting issues
From: Heiko Stuebner @ 2020-07-14 18:30 UTC (permalink / raw)
To: Lee Jones
Cc: linus.walleij, linux-kernel, linux-gpio, Kukjin Kim,
Krzysztof Kozlowski, Tomasz Figa, Sylwester Nawrocki,
linux-samsung-soc
In-Reply-To: <20200713144930.1034632-8-lee.jones@linaro.org>
Am Montag, 13. Juli 2020, 16:49:12 CEST schrieb Lee Jones:
> Kerneldoc struct titles must be followed by whitespace. Also attributes
> need to be in the format '@.*: ' else the checker gets confused.
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/pinctrl/samsung/pinctrl-s3c24xx.c:100: warning: cannot understand function prototype: 'struct s3c24xx_eint_domain_data '
>
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Cc: Heiko Stuebner <heiko@sntech.de>
> Cc: linux-samsung-soc@vger.kernel.org
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
> ---
> drivers/pinctrl/samsung/pinctrl-s3c24xx.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pinctrl/samsung/pinctrl-s3c24xx.c b/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
> index 9bd0a3de101dd..5e24838a582f5 100644
> --- a/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
> +++ b/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
> @@ -80,7 +80,7 @@ static const struct samsung_pin_bank_type bank_type_2bit = {
> }
>
> /**
> - * struct s3c24xx_eint_data: EINT common data
> + * struct s3c24xx_eint_data - EINT common data
> * @drvdata: pin controller driver data
> * @domains: IRQ domains of particular EINT interrupts
> * @parents: mapped parent irqs in the main interrupt controller
> @@ -92,10 +92,10 @@ struct s3c24xx_eint_data {
> };
>
> /**
> - * struct s3c24xx_eint_domain_data: per irq-domain data
> + * struct s3c24xx_eint_domain_data - per irq-domain data
> * @bank: pin bank related to the domain
> * @eint_data: common data
> - * eint0_3_parent_only: live eints 0-3 only in the main intc
> + * @eint0_3_parent_only: live eints 0-3 only in the main intc
> */
> struct s3c24xx_eint_domain_data {
> struct samsung_pin_bank *bank;
>
^ permalink raw reply
* Re: [PATCH] pinctrl: rockchip: Replace HTTP links with HTTPS ones
From: Heiko Stuebner @ 2020-07-14 18:27 UTC (permalink / raw)
To: Alexander A. Klimov
Cc: linus.walleij, linux-gpio, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20200713183541.36963-1-grandmaster@al2klimov.de>
Am Montag, 13. Juli 2020, 20:35:41 CEST schrieb Alexander A. Klimov:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
>
> Deterministic algorithm:
> For each file:
> If not .svg:
> For each line:
> If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
> If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:
> Replace HTTP with HTTPS.
>
> Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
At least from my cursory glance the www.samsung.com below
also behaves the same with both http and https .
In general ... I don't really believe anybody would use the rockchip
pinctrl-driver to access either Linaro nor Samsung, but I don't care that
much so ;-)
Acked-by: Heiko Stuebner <heiko@sntech.de>
> ---
> Continuing my work started at 93431e0607e5.
> See also: git log --oneline '--author=Alexander A. Klimov <grandmaster@al2klimov.de>' v5.7..master
> (Actually letting a shell for loop submit all this stuff for me.)
>
> If there are any URLs to be removed completely or at least not just HTTPSified:
> Just clearly say so and I'll *undo my change*.
> See also: https://lkml.org/lkml/2020/6/27/64
>
> If there are any valid, but yet not changed URLs:
> See: https://lkml.org/lkml/2020/6/26/837
>
> If you apply the patch, please let me know.
>
> Sorry again to all maintainers who complained about subject lines.
> Now I realized that you want an actually perfect prefixes,
> not just subsystem ones.
> I tried my best...
> And yes, *I could* (at least half-)automate it.
> Impossible is nothing! :)
>
>
> drivers/pinctrl/pinctrl-rockchip.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/pinctrl-rockchip.c b/drivers/pinctrl/pinctrl-rockchip.c
> index c07324d1f265..a94b54636da9 100644
> --- a/drivers/pinctrl/pinctrl-rockchip.c
> +++ b/drivers/pinctrl/pinctrl-rockchip.c
> @@ -9,7 +9,7 @@
> * Copyright (c) 2012 Samsung Electronics Co., Ltd.
> * http://www.samsung.com
> * Copyright (c) 2012 Linaro Ltd
> - * http://www.linaro.org
> + * https://www.linaro.org
> *
> * and pinctrl-at91:
> * Copyright (C) 2011-2012 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
>
^ permalink raw reply
* Re: [PATCH v8 6/7] arm64: dts: add dts nodes for MT6779
From: Matthias Brugger @ 2020-07-14 18:14 UTC (permalink / raw)
To: Hanks Chen, Linus Walleij, Rob Herring, Michael Turquette,
Stephen Boyd, Sean Wang
Cc: mtk01761, Andy Teng, linux-gpio, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel, wsd_upstream, CC Hwang, Loda Chou
In-Reply-To: <1594718402-20813-7-git-send-email-hanks.chen@mediatek.com>
On 14/07/2020 11:20, Hanks Chen wrote:
> this adds initial MT6779 dts settings for board support,
> including cpu, gic, timer, ccf, pinctrl, uart, sysirq...etc.
>
> Signed-off-by: Hanks Chen <hanks.chen@mediatek.com>
> ---
> arch/arm64/boot/dts/mediatek/Makefile | 1 +
> arch/arm64/boot/dts/mediatek/mt6779-evb.dts | 31 +++
> arch/arm64/boot/dts/mediatek/mt6779.dtsi | 271 ++++++++++++++++++++
> 3 files changed, 303 insertions(+)
> create mode 100644 arch/arm64/boot/dts/mediatek/mt6779-evb.dts
> create mode 100644 arch/arm64/boot/dts/mediatek/mt6779.dtsi
>
[...]
> +
> + uart0: serial@11002000 {
> + compatible = "mediatek,mt6779-uart",
> + "mediatek,mt6577-uart";
> + reg = <0 0x11002000 0 0x400>;
> + interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&clk26m>, <&infracfg_ao CLK_INFRA_UART0>;
> + clock-names = "baud", "bus";
> + status = "disabled";
> + };
> +
> + uart1: serial@11003000 {
> + compatible = "mediatek,mt6779-uart",
> + "mediatek,mt6577-uart";
> + reg = <0 0x11003000 0 0x400>;
> + interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&clk26m>, <&infracfg_ao CLK_INFRA_UART1>;
> + clock-names = "baud", "bus";
> + status = "disabled";
> + };
> +
> + uart2: serial@11004000 {
> + compatible = "mediatek,mt6779-uart",
> + "mediatek,mt6577-uart";
> + reg = <0 0x11004000 0 0x400>;
> + interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&clk26m>, <&infracfg_ao CLK_INFRA_UART2>;
> + clock-names = "baud", "bus";
> + status = "disabled";
> + };
Devicetree describes the HW we have. As far as I know, we have 4 UARTs on
MT6779. So we should list them all here.
Regards,
Matthias
^ permalink raw reply
* Re: [PATCH 01/25] pinctrl: actions: pinctrl-owl: Supply missing 'struct owl_pinctrl' attribute descriptions
From: Manivannan Sadhasivam @ 2020-07-14 17:18 UTC (permalink / raw)
To: Lee Jones
Cc: linus.walleij, linux-kernel, linux-gpio, Andreas Färber,
David Liu
In-Reply-To: <20200713144930.1034632-2-lee.jones@linaro.org>
On Mon, Jul 13, 2020 at 03:49:06PM +0100, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/pinctrl/actions/pinctrl-owl.c:52: warning: Function parameter or member 'clk' not described in 'owl_pinctrl'
> drivers/pinctrl/actions/pinctrl-owl.c:52: warning: Function parameter or member 'irq_chip' not described in 'owl_pinctrl'
> drivers/pinctrl/actions/pinctrl-owl.c:52: warning: Function parameter or member 'num_irq' not described in 'owl_pinctrl'
> drivers/pinctrl/actions/pinctrl-owl.c:52: warning: Function parameter or member 'irq' not described in 'owl_pinctrl'
>
> Cc: "Andreas Färber" <afaerber@suse.de>
> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Cc: David Liu <liuwei@actions-semi.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Thanks,
Mani
> ---
> drivers/pinctrl/actions/pinctrl-owl.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/pinctrl/actions/pinctrl-owl.c b/drivers/pinctrl/actions/pinctrl-owl.c
> index 5a0c8e87aa7cd..7efdfb4f3e9ba 100644
> --- a/drivers/pinctrl/actions/pinctrl-owl.c
> +++ b/drivers/pinctrl/actions/pinctrl-owl.c
> @@ -35,8 +35,12 @@
> * @pctrldev: pinctrl handle
> * @chip: gpio chip
> * @lock: spinlock to protect registers
> + * @clk: clock control
> * @soc: reference to soc_data
> * @base: pinctrl register base address
> + * @irq_chip: IRQ chip information
> + * @num_irq: number of possible interrupts
> + * @irq: interrupt numbers
> */
> struct owl_pinctrl {
> struct device *dev;
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH 18/25] pinctrl: pinctrl-bm1880: Rename ill documented struct attribute entries
From: Manivannan Sadhasivam @ 2020-07-14 17:17 UTC (permalink / raw)
To: Lee Jones; +Cc: linus.walleij, linux-kernel, linux-gpio
In-Reply-To: <20200713144930.1034632-19-lee.jones@linaro.org>
On Mon, Jul 13, 2020 at 03:49:23PM +0100, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/pinctrl/pinctrl-bm1880.c:40: warning: Function parameter or member 'pctrldev' not described in 'bm1880_pinctrl'
> drivers/pinctrl/pinctrl-bm1880.c:40: warning: Function parameter or member 'pinconf' not described in 'bm1880_pinctrl'
>
> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Thanks,
Mani
> ---
> drivers/pinctrl/pinctrl-bm1880.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-bm1880.c b/drivers/pinctrl/pinctrl-bm1880.c
> index d1a7d98367870..a8e267237435f 100644
> --- a/drivers/pinctrl/pinctrl-bm1880.c
> +++ b/drivers/pinctrl/pinctrl-bm1880.c
> @@ -22,12 +22,12 @@
> /**
> * struct bm1880_pinctrl - driver data
> * @base: Pinctrl base address
> - * @pctrl: Pinctrl device
> + * @pctrldev: Pinctrl device
> * @groups: Pingroups
> * @ngroups: Number of @groups
> * @funcs: Pinmux functions
> * @nfuncs: Number of @funcs
> - * @pconf: Pinconf data
> + * @pinconf: Pinconf data
> */
> struct bm1880_pinctrl {
> void __iomem *base;
> --
> 2.25.1
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox