* RE: [PATCH 1/2] clocksource: Add support for i.MX TPM driver with ARM64
From: Anson Huang @ 2020-05-28 1:57 UTC (permalink / raw)
To: Anson Huang, catalin.marinas@arm.com, will@kernel.org,
daniel.lezcano@linaro.org, tglx@linutronix.de,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: dl-linux-imx
In-Reply-To: <1586500008-4418-1-git-send-email-Anson.Huang@nxp.com>
Gentle ping...
> -----Original Message-----
> From: Anson Huang <Anson.Huang@nxp.com>
> Sent: 2020年4月10日 14:27
> To: catalin.marinas@arm.com; will@kernel.org; daniel.lezcano@linaro.org;
> tglx@linutronix.de; linux-arm-kernel@lists.infradead.org;
> linux-kernel@vger.kernel.org
> Cc: dl-linux-imx <linux-imx@nxp.com>
> Subject: [PATCH 1/2] clocksource: Add support for i.MX TPM driver with
> ARM64
>
> Allows building and compile-testing the i.MX TPM driver for ARM64.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> drivers/clocksource/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig index
> f2142e6..e9e7fe1 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -617,7 +617,7 @@ config CLKSRC_IMX_GPT
>
> config CLKSRC_IMX_TPM
> bool "Clocksource using i.MX TPM" if COMPILE_TEST
> - depends on ARM && CLKDEV_LOOKUP
> + depends on (ARM || ARM64) && CLKDEV_LOOKUP
> select CLKSRC_MMIO
> help
> Enable this option to use IMX Timer/PWM Module (TPM) timer as
> --
> 2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH] mailbox: imx: Support runtime PM
From: Anson Huang @ 2020-05-28 2:01 UTC (permalink / raw)
To: Marc Kleine-Budde, jassisinghbrar@gmail.com, shawnguo@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: dl-linux-imx
In-Reply-To: <DB3PR0402MB3916D05B44D776E5242434B1F5DD0@DB3PR0402MB3916.eurprd04.prod.outlook.com>
Gentle ping...
> Subject: RE: [PATCH] mailbox: imx: Support runtime PM
>
> Hi, Marc
>
> > Subject: Re: [PATCH] mailbox: imx: Support runtime PM
> >
> > On 4/13/20 2:25 PM, Anson Huang wrote:
> > > Some power hungry sub-systems like VPU has its own MUs which also
> > > use mailbox driver, current mailbox driver uses platform driver
> > > model and MU's power will be ON after driver probed and left ON
> > > there, it may cause the whole sub-system can NOT enter lower power
> > > mode, take VPU driver for example, it has runtime PM support, but
> > > due to its MU always ON, the VPU sub-system will be always ON and
> > > consume many power during kernel idle.
> > >
> > > To save power in kernel idle, mailbox driver needs to support
> > > runtime PM in order to power off MU when it is unused. However, the
> > > runtime suspend/resume can ONLY be implemented in mailbox's
> > > .shutdown/.startup callback, so its consumer needs to call
> > > mbox_request_channel()/mbox_free_channel() in consumer driver's
> > > runtime PM callback, then the MU's power will be ON/OFF along with
> > > consumer's runtime PM status.
> > >
> > > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > > ---
> > > drivers/mailbox/imx-mailbox.c | 27 ++++++++++++++++++++++++++-
> > > 1 file changed, 26 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/mailbox/imx-mailbox.c
> > > b/drivers/mailbox/imx-mailbox.c index 7906624..97bf0ac 100644
> > > --- a/drivers/mailbox/imx-mailbox.c
> > > +++ b/drivers/mailbox/imx-mailbox.c
> > > @@ -12,6 +12,7 @@
> > > #include <linux/mailbox_controller.h> #include <linux/module.h>
> > > #include <linux/of_device.h>
> > > +#include <linux/pm_runtime.h>
> > > #include <linux/slab.h>
> > >
> > > #define IMX_MU_xSR_GIPn(x) BIT(28 + (3 - (x)))
> > > @@ -287,6 +288,7 @@ static int imx_mu_startup(struct mbox_chan
> *chan)
> > > struct imx_mu_con_priv *cp = chan->con_priv;
> > > int ret;
> > >
> > > + pm_runtime_get_sync(priv->dev);
> > > if (cp->type == IMX_MU_TYPE_TXDB) {
> > > /* Tx doorbell don't have ACK support */
> > > tasklet_init(&cp->txdb_tasklet, imx_mu_txdb_tasklet, @@
> -323,6
> > > +325,7 @@ static void imx_mu_shutdown(struct mbox_chan *chan)
> > >
> > > if (cp->type == IMX_MU_TYPE_TXDB) {
> > > tasklet_kill(&cp->txdb_tasklet);
> > > + pm_runtime_put_sync(priv->dev);
> > > return;
> > > }
> > >
> > > @@ -341,6 +344,7 @@ static void imx_mu_shutdown(struct mbox_chan
> > *chan)
> > > }
> > >
> > > free_irq(priv->irq, chan);
> > > + pm_runtime_put_sync(priv->dev);
> > > }
> > >
> > > static const struct mbox_chan_ops imx_mu_ops = { @@ -508,7 +512,27
> > @@
> > > static int imx_mu_probe(struct platform_device *pdev)
> > >
> > > platform_set_drvdata(pdev, priv);
> > >
> > > - return devm_mbox_controller_register(dev, &priv->mbox);
> > > + ret = devm_mbox_controller_register(dev, &priv->mbox);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + pm_runtime_enable(dev);
> > > +
> >
> > First registering at the system and then setting up the power
> > management looks racy. Don't know if this is serialized by some other
> means.
>
> Don't have other means, just refer to
> drivers/mailbox/omap-mailbox.c, it has same sequence, NOT sure if there is
> special requirement about this sequence.
>
> Thanks,
> Anson
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 05/14] dt-bindings: arm: sparx5: Add documentation for Microchip Sparx5 SoC
From: Rob Herring @ 2020-05-28 2:11 UTC (permalink / raw)
To: Lars Povlsen
Cc: devicetree, Alexandre Belloni, Arnd Bergmann, linux-gpio,
Stephen Boyd, Steen Hegelund, linux-clk, linux-kernel,
Microchip Linux Driver Support, Michael Turquette, SoC Team,
Olof Johansson, Linus Walleij, linux-arm-kernel
In-Reply-To: <20200513125532.24585-6-lars.povlsen@microchip.com>
On Wed, May 13, 2020 at 02:55:23PM +0200, Lars Povlsen wrote:
> This adds the main Sparx5 SoC DT documentation file, with information
> abut the supported board types.
>
> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
> ---
> .../bindings/arm/microchip,sparx5.yaml | 87 +++++++++++++++++++
> 1 file changed, 87 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/microchip,sparx5.yaml
>
> diff --git a/Documentation/devicetree/bindings/arm/microchip,sparx5.yaml b/Documentation/devicetree/bindings/arm/microchip,sparx5.yaml
> new file mode 100644
> index 0000000000000..83b36d1217988
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/microchip,sparx5.yaml
> @@ -0,0 +1,87 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/microchip,sparx5.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip Sparx5 Boards Device Tree Bindings
> +
> +maintainers:
> + - Lars Povlsen <lars.povlsen@microchip.com>
> +
> +description: |+
> + The Microchip Sparx5 SoC is a ARMv8-based used in a family of
> + gigabit TSN-capable gigabit switches.
> +
> + The SparX-5 Ethernet switch family provides a rich set of switching
> + features such as advanced TCAM-based VLAN and QoS processing
> + enabling delivery of differentiated services, and security through
> + TCAM-based frame processing using versatile content aware processor
> + (VCAP)
> +
> +properties:
> + $nodename:
> + const: '/'
> + compatible:
> + oneOf:
> + - description: The Sparx5 pcb125 board is a modular board,
> + which has both spi-nor and eMMC storage. The modular design
> + allows for connection of different network ports.
> + items:
> + - const: microchip,sparx5-pcb125
> + - const: microchip,sparx5
> +
> + - description: The Sparx5 pcb134 is a pizzabox form factor
> + gigabit switch with 20 SFP ports. It features spi-nor and
> + either spi-nand or eMMC storage (mount option).
> + items:
> + - const: microchip,sparx5-pcb134
> + - const: microchip,sparx5
> +
> + - description: The Sparx5 pcb135 is a pizzabox form factor
> + gigabit switch with 48+4 Cu ports. It features spi-nor and
> + either spi-nand or eMMC storage (mount option).
> + items:
> + - const: microchip,sparx5-pcb135
> + - const: microchip,sparx5
> +
> + axi@600000000:
> + type: object
> + description: the root node in the Sparx5 platforms must contain
> + an axi bus child node. They are always at physical address
> + 0x600000000 in all the Sparx5 variants.
> + properties:
> + compatible:
> + items:
> + - const: simple-bus
> + reg:
> + maxItems: 1
simple-bus doesn't have 'reg'. If there's bus registers, then it's not
simple.
> +
> + required:
> + - compatible
> + - reg
> +
> +patternProperties:
> + "^syscon@[0-9a-f]+$":
This should be under a bus node.
> + description: All Sparx5 boards must provide a system controller,
> + typically under the axi bus node. It contain reset registers and
> + other system control.
> + type: object
> + properties:
> + compatible:
> + items:
> + - const: microchip,sparx5-cpu-syscon
> + - const: syscon
This probably should be in its own document. If really this simple,
there's already syscon.yaml you can add to.
> + reg:
> + maxItems: 1
> +
> + required:
> + - compatible
> + - reg
> +
> +required:
> + - compatible
> + - axi@600000000
> + - syscon@600000000
> +
> +...
> --
> 2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 10/14] dt-bindings: clock: sparx5: Add Sparx5 SoC DPLL clock
From: Rob Herring @ 2020-05-28 2:18 UTC (permalink / raw)
To: Lars Povlsen
Cc: devicetree, Alexandre Belloni, Arnd Bergmann, linux-gpio,
Stephen Boyd, Steen Hegelund, linux-clk, linux-kernel,
Microchip Linux Driver Support, Michael Turquette, SoC Team,
Olof Johansson, Linus Walleij, linux-arm-kernel
In-Reply-To: <20200513125532.24585-11-lars.povlsen@microchip.com>
On Wed, May 13, 2020 at 02:55:28PM +0200, Lars Povlsen wrote:
> This add the DT bindings documentation for the Sparx5 SoC DPLL clock
>
> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
> ---
> .../bindings/clock/microchip,sparx5-dpll.yaml | 46 +++++++++++++++++++
> 1 file changed, 46 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/microchip,sparx5-dpll.yaml
>
> diff --git a/Documentation/devicetree/bindings/clock/microchip,sparx5-dpll.yaml b/Documentation/devicetree/bindings/clock/microchip,sparx5-dpll.yaml
> new file mode 100644
> index 0000000000000..594007d8fc59a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/microchip,sparx5-dpll.yaml
> @@ -0,0 +1,46 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/microchip,sparx5-dpll.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip Sparx5 DPLL Clock
> +
> +maintainers:
> + - Lars Povlsen <lars.povlsen@microchip.com>
> +
> +description: |
> + The Sparx5 DPLL clock controller generates and supplies clock to
> + various peripherals within the SoC.
> +
> + This binding uses common clock bindings
> + [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +properties:
> + compatible:
> + const: microchip,sparx5-dpll
> +
> + reg:
> + items:
> + - description: dpll registers
For a single entry, just:
maxItems: 1
> +
> + '#clock-cells':
> + const: 1
> +
> +required:
> + - compatible
> + - reg
> + - '#clock-cells'
> +
> +additionalProperties: false
> +
> +examples:
> + # Clock provider for eMMC:
> + - |
> + clks: clks@61110000c {
clock-controller@1110000c {
> + compatible = "microchip,sparx5-dpll";
> + #clock-cells = <1>;
> + reg = <0x1110000c 0x24>;
Looks like this is a sub-block in some other h/w block. What's the
parent device? That should be described and this should be part of it
either as a single node or a child node. Without a complete view of what
this block has I can't provide any guidance.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/5] dt-bindings: reset: ocelot: Add documentation for 'microchip,reset-switch-core' property
From: Rob Herring @ 2020-05-28 2:25 UTC (permalink / raw)
To: Lars Povlsen
Cc: devicetree, Alexandre Belloni, linux-pm, linux-kernel,
Sebastian Reichel, Microchip Linux Driver Support, SoC Team,
linux-arm-kernel
In-Reply-To: <20200513130842.24847-4-lars.povlsen@microchip.com>
On Wed, May 13, 2020 at 03:08:40PM +0200, Lars Povlsen wrote:
> This documents the 'microchip,reset-switch-core' property in the
> ocelot-reset driver.
>
> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
> ---
> .../devicetree/bindings/power/reset/ocelot-reset.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> index 4d530d8154848..20fff03753ad2 100644
> --- a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> +++ b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> @@ -9,9 +9,15 @@ microchip Sparx5 armv8 SoC's.
> Required Properties:
> - compatible: "mscc,ocelot-chip-reset" or "microchip,sparx5-chip-reset"
>
> +Optional properties:
> +- microchip,reset-switch-core : Perform a switch core reset at the
> + time of driver load. This is may be used to initialize the switch
> + core to a known state (before other drivers are loaded).
How do you know when other drivers are loaded? This could be a module
perhaps. Doesn't seem like something that belongs in DT.
Can this behavior be implied with "microchip,sparx5-chip-reset"?
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: sparx5: Add hwmon temperature sensor
From: Rob Herring @ 2020-05-28 2:29 UTC (permalink / raw)
To: Lars Povlsen
Cc: linux-hwmon, devicetree, Alexandre Belloni, Jean Delvare,
linux-kernel, Microchip Linux Driver Support, SoC Team,
linux-arm-kernel, Guenter Roeck
In-Reply-To: <20200513134140.25357-3-lars.povlsen@microchip.com>
On Wed, May 13, 2020 at 03:41:39PM +0200, Lars Povlsen wrote:
> This adds a hwmon temperature node sensor to the Sparx5 SoC.
>
> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
> ---
> arch/arm64/boot/dts/microchip/sparx5.dtsi | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/microchip/sparx5.dtsi b/arch/arm64/boot/dts/microchip/sparx5.dtsi
> index f09a49c41ce19..b5f2d088af30e 100644
> --- a/arch/arm64/boot/dts/microchip/sparx5.dtsi
> +++ b/arch/arm64/boot/dts/microchip/sparx5.dtsi
> @@ -233,5 +233,11 @@ i2c1: i2c@600103000 {
> clock-frequency = <100000>;
> clocks = <&ahb_clk>;
> };
> +
> + tmon0: tmon@610508110 {
> + compatible = "microchip,sparx5-temp";
> + reg = <0x6 0x10508110 0xc>;
These nodes are all very odd with a couple of registers spread out at
randomish addresses. DT nodes should roughly correlate to h/w blocks,
not sets of registers for a driver like this seems to be.
Please make the dts files one patch. Reviewing a node at a time is not
all that effective.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 14/15] dt-bindings: pinctrl: stm32: Add missing interrupts property
From: Rob Herring @ 2020-05-28 2:34 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: devicetree, alexandre.torgue, gregkh, linus.walleij, linux-usb,
linux-kernel, linux-gpio, robh+dt, mcoquelin.stm32, linux-stm32,
linux-arm-kernel
In-Reply-To: <20200513145935.22493-15-benjamin.gaignard@st.com>
On Wed, 13 May 2020 16:59:34 +0200, Benjamin Gaignard wrote:
> Driver use interrupt-parent field so update the bindings to allow it.
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml | 3 +++
> 1 file changed, 3 insertions(+)
>
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 15/15] dt-bindings: usb: dwc2: Fix issues for stm32mp15x SoC
From: Rob Herring @ 2020-05-28 2:34 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: devicetree, alexandre.torgue, gregkh, linus.walleij, linux-usb,
linux-kernel, linux-gpio, robh+dt, mcoquelin.stm32, linux-stm32,
linux-arm-kernel
In-Reply-To: <20200513145935.22493-16-benjamin.gaignard@st.com>
On Wed, 13 May 2020 16:59:35 +0200, Benjamin Gaignard wrote:
> Correct the compatible list for stm32mp15x SoC.
> Fix the name of the stm32mp15x dedicated supply to be aligned with
> what the driver use.
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> Documentation/devicetree/bindings/usb/dwc2.yaml | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 1/5] dt-bindings: vendor-prefixes: Add Xingbangda
From: Rob Herring @ 2020-05-28 2:40 UTC (permalink / raw)
To: Ondrej Jirman
Cc: devicetree, linux-sunxi, Martijn Braam, Samuel Holland,
David Airlie, Linus Walleij, Bhushan Shah, linux-kernel,
dri-devel, Luca Weiss, Chen-Yu Tsai, Rob Herring, Thierry Reding,
Maxime Ripard, Daniel Vetter, Sam Ravnborg, linux-arm-kernel,
Icenowy Zheng
In-Reply-To: <20200513212451.1919013-2-megous@megous.com>
On Wed, 13 May 2020 23:24:47 +0200, Ondrej Jirman wrote:
> From: Icenowy Zheng <icenowy@aosc.io>
>
> Shenzhen Xingbangda Display Technology Co., Ltd is a company which
> produces LCD modules. It supplies the LCD panels for the PinePhone.
>
> Add the vendor prefix of it.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Signed-off-by: Ondrej Jirman <megous@megous.com>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 2/5] dt-bindings: panel: Add binding for Xingbangda XBD599 panel
From: Rob Herring @ 2020-05-28 2:41 UTC (permalink / raw)
To: Ondrej Jirman
Cc: linux-arm-kernel, Martijn Braam, Samuel Holland, David Airlie,
Linus Walleij, Bhushan Shah, Chen-Yu Tsai, Maxime Ripard,
linux-kernel, Luca Weiss, Rob Herring, linux-sunxi,
Thierry Reding, dri-devel, Daniel Vetter, Sam Ravnborg,
devicetree, Icenowy Zheng
In-Reply-To: <20200513212451.1919013-3-megous@megous.com>
On Wed, 13 May 2020 23:24:48 +0200, Ondrej Jirman wrote:
> From: Icenowy Zheng <icenowy@aosc.io>
>
> Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI LCD panel. It is based on
> Sitronix ST7703 LCD controller.
>
> Add its device tree binding.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Signed-off-by: Ondrej Jirman <megous@megous.com>
> ---
> .../display/panel/sitronix,st7703.yaml | 63 +++++++++++++++++++
> 1 file changed, 63 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/sitronix,st7703.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: pwm: Convert imx pwm to json-schema
From: Rob Herring @ 2020-05-28 2:47 UTC (permalink / raw)
To: Aisheng Dong
Cc: linux-pwm@vger.kernel.org, p.zabel@pengutronix.de, Anson Huang,
devicetree@vger.kernel.org, festevam@gmail.com,
s.hauer@pengutronix.de, linux-kernel@vger.kernel.org,
thierry.reding@gmail.com, dl-linux-imx, kernel@pengutronix.de,
u.kleine-koenig@pengutronix.de, shawnguo@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <AM6PR04MB4966EC7122B2BFB9FEEDD74280B80@AM6PR04MB4966.eurprd04.prod.outlook.com>
On Mon, May 18, 2020 at 05:58:42AM +0000, Aisheng Dong wrote:
> > From: Anson Huang <Anson.Huang@nxp.com>
> > Sent: Thursday, May 14, 2020 2:54 PM
> >
> > Convert the imx pwm binding to DT schema format using json-schema.
> >
> > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > ---
> > Documentation/devicetree/bindings/pwm/imx-pwm.txt | 27 ---------
> > Documentation/devicetree/bindings/pwm/imx-pwm.yaml | 66
> > ++++++++++++++++++++++
> > 2 files changed, 66 insertions(+), 27 deletions(-) delete mode 100644
> > Documentation/devicetree/bindings/pwm/imx-pwm.txt
> > create mode 100644
> > Documentation/devicetree/bindings/pwm/imx-pwm.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> > b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> > deleted file mode 100644
> > index 22f1c3d..0000000
> > --- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> > +++ /dev/null
> > @@ -1,27 +0,0 @@
> > -Freescale i.MX PWM controller
> > -
> > -Required properties:
> > -- compatible : should be "fsl,<soc>-pwm" and one of the following
> > - compatible strings:
> > - - "fsl,imx1-pwm" for PWM compatible with the one integrated on i.MX1
> > - - "fsl,imx27-pwm" for PWM compatible with the one integrated on i.MX27
> > -- reg: physical base address and length of the controller's registers
> > -- #pwm-cells: 2 for i.MX1 and 3 for i.MX27 and newer SoCs. See pwm.yaml
> > - in this directory for a description of the cells format.
> > -- clocks : Clock specifiers for both ipg and per clocks.
> > -- clock-names : Clock names should include both "ipg" and "per"
> > -See the clock consumer binding,
> > - Documentation/devicetree/bindings/clock/clock-bindings.txt
> > -- interrupts: The interrupt for the pwm controller
> > -
> > -Example:
> > -
> > -pwm1: pwm@53fb4000 {
> > - #pwm-cells = <3>;
> > - compatible = "fsl,imx53-pwm", "fsl,imx27-pwm";
> > - reg = <0x53fb4000 0x4000>;
> > - clocks = <&clks IMX5_CLK_PWM1_IPG_GATE>,
> > - <&clks IMX5_CLK_PWM1_HF_GATE>;
> > - clock-names = "ipg", "per";
> > - interrupts = <61>;
> > -};
> > diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.yaml
> > b/Documentation/devicetree/bindings/pwm/imx-pwm.yaml
> > new file mode 100644
> > index 0000000..4b62af2
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pwm/imx-pwm.yaml
> > @@ -0,0 +1,66 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevice
> > +tree.org%2Fschemas%2Fpwm%2Fimx-pwm.yaml%23&data=02%7C01%
> > 7Caisheng.d
> > +ong%40nxp.com%7C9b5cc1814a4b47d1cb0d08d7f7d4f594%7C686ea1d3bc
> > 2b4c6fa92c
> > +d99c5c301635%7C0%7C0%7C637250366331627865&sdata=M2RPcty
> > wz61WZrpAW6S
> > +O3NJbr2wj2qXwnMMmBwCbInk%3D&reserved=0
> > +$schema:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevice
> > +tree.org%2Fmeta-schemas%2Fcore.yaml%23&data=02%7C01%7Caishen
> > g.dong%
> > +40nxp.com%7C9b5cc1814a4b47d1cb0d08d7f7d4f594%7C686ea1d3bc2b4c
> > 6fa92cd99c
> > +5c301635%7C0%7C0%7C637250366331627865&sdata=UxgYSClanyOjt
> > BmlyNrMZyF
> > +3%2F5awD%2FM3yaVPqgNKgxs%3D&reserved=0
> > +
> > +title: Freescale i.MX PWM controller
> > +
> > +maintainers:
> > + - Philipp Zabel <p.zabel@pengutronix.de>
> > +
> > +properties:
> > + "#pwm-cells":
> > + description: |
> > + Should be 2 for i.MX1 and 3 for i.MX27 and newer SoCs. See pwm.yaml
> > + in this directory for a description of the cells format.
>
> Should we add the reference to pwm.yaml?
> BTW, strange, I didn't see format description in pwm.yaml.
No need to. That's generally only needed when there's some structure
like SPI or I2C bus to include.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: pwm: Convert imx pwm to json-schema
From: Rob Herring @ 2020-05-28 2:47 UTC (permalink / raw)
To: Anson Huang
Cc: linux-pwm, kernel, devicetree, festevam, s.hauer, linux-kernel,
robh+dt, thierry.reding, Linux-imx, p.zabel, u.kleine-koenig,
shawnguo, linux-arm-kernel
In-Reply-To: <1589439259-28510-1-git-send-email-Anson.Huang@nxp.com>
On Thu, 14 May 2020 14:54:18 +0800, Anson Huang wrote:
> Convert the imx pwm binding to DT schema format using json-schema.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> Documentation/devicetree/bindings/pwm/imx-pwm.txt | 27 ---------
> Documentation/devicetree/bindings/pwm/imx-pwm.yaml | 66 ++++++++++++++++++++++
> 2 files changed, 66 insertions(+), 27 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/pwm/imx-pwm.txt
> create mode 100644 Documentation/devicetree/bindings/pwm/imx-pwm.yaml
>
Applied, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: pwm: Convert imx tpm pwm to json-schema
From: Rob Herring @ 2020-05-28 2:47 UTC (permalink / raw)
To: Anson Huang
Cc: linux-pwm, kernel, devicetree, festevam, s.hauer, linux-kernel,
robh+dt, thierry.reding, Linux-imx, p.zabel, u.kleine-koenig,
shawnguo, linux-arm-kernel
In-Reply-To: <1589439259-28510-2-git-send-email-Anson.Huang@nxp.com>
On Thu, 14 May 2020 14:54:19 +0800, Anson Huang wrote:
> Convert the imx tpm pwm binding to DT schema format using json-schema.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> .../devicetree/bindings/pwm/imx-tpm-pwm.txt | 22 ---------
> .../devicetree/bindings/pwm/imx-tpm-pwm.yaml | 55 ++++++++++++++++++++++
> 2 files changed, 55 insertions(+), 22 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/pwm/imx-tpm-pwm.txt
> create mode 100644 Documentation/devicetree/bindings/pwm/imx-tpm-pwm.yaml
>
Applied, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 04/20] arm64: dts: arm: vexpress: Move fixed devices out of bus node
From: Guenter Roeck @ 2020-05-28 2:48 UTC (permalink / raw)
To: Andre Przywara
Cc: Mark Rutland, Rob Herring, Lorenzo Pieralisi, devicetree,
Liviu Dudau, Sudeep Holla, linux-arm-kernel
In-Reply-To: <20200513103016.130417-5-andre.przywara@arm.com>
On Wed, May 13, 2020 at 11:30:00AM +0100, Andre Przywara wrote:
> The devicetree compiler complains when DT nodes without a reg property
> live inside a (simple) bus node:
> Warning (simple_bus_reg): Node /bus@8000000/motherboard-bus/refclk32khz
> missing or empty reg/ranges property
>
> Move the fixed clocks, the fixed regulator, the leds and the config bus
> subtree to the root node, since they do not depend on any busses.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
This patch results in tracebacks when booting the vexpress-a15 machine
with vexpress-v2p-ca15-tc1 devicetree file in qemu. Reverting it as well
as the subsequent patches affecting the same file (to avoid revert
conflicts) fixes the problem.
Guenter
---
[ 12.744248] ------------[ cut here ]------------
[ 12.744562] WARNING: CPU: 0 PID: 20 at drivers/tty/serial/serial_core.c:471 uart_get_baud_rate+0x100/0x154
[ 12.744607] Modules linked in:
[ 12.744785] CPU: 0 PID: 20 Comm: kworker/0:1 Not tainted 5.7.0-rc7-next-20200526 #1
[ 12.744818] Hardware name: ARM-Versatile Express
[ 12.745021] Workqueue: events amba_deferred_retry_func
[ 12.745155] [<c0312484>] (unwind_backtrace) from [<c030c490>] (show_stack+0x10/0x14)
[ 12.745206] [<c030c490>] (show_stack) from [<c0880f04>] (dump_stack+0xc8/0xdc)
[ 12.745239] [<c0880f04>] (dump_stack) from [<c0346e44>] (__warn+0xdc/0xf4)
[ 12.745270] [<c0346e44>] (__warn) from [<c0346f0c>] (warn_slowpath_fmt+0xb0/0xb8)
[ 12.745302] [<c0346f0c>] (warn_slowpath_fmt) from [<c0a6b16c>] (uart_get_baud_rate+0x100/0x154)
[ 12.745336] [<c0a6b16c>] (uart_get_baud_rate) from [<c0a7f5ac>] (pl011_set_termios+0x48/0x32c)
[ 12.745367] [<c0a7f5ac>] (pl011_set_termios) from [<c0a6bbbc>] (uart_set_options+0x124/0x164)
[ 12.745404] [<c0a6bbbc>] (uart_set_options) from [<c1b8c804>] (pl011_console_setup+0x214/0x230)
[ 12.745438] [<c1b8c804>] (pl011_console_setup) from [<c03ab0d8>] (try_enable_new_console+0x98/0x138)
[ 12.745469] [<c03ab0d8>] (try_enable_new_console) from [<c03acc64>] (register_console+0xe8/0x304)
[ 12.745499] [<c03acc64>] (register_console) from [<c0a6c88c>] (uart_add_one_port+0x4c0/0x504)
[ 12.745529] [<c0a6c88c>] (uart_add_one_port) from [<c0a80404>] (pl011_register_port+0x5c/0xac)
[ 12.745568] [<c0a80404>] (pl011_register_port) from [<c097f5a0>] (amba_probe+0x9c/0x110)
[ 12.745602] [<c097f5a0>] (amba_probe) from [<c0b57e84>] (really_probe+0x218/0x348)
[ 12.745632] [<c0b57e84>] (really_probe) from [<c0b580c0>] (driver_probe_device+0x5c/0xb4)
[ 12.745662] [<c0b580c0>] (driver_probe_device) from [<c0b55ff4>] (bus_for_each_drv+0x58/0xb8)
[ 12.745692] [<c0b55ff4>] (bus_for_each_drv) from [<c0b57bf8>] (__device_attach+0xd4/0x140)
[ 12.745721] [<c0b57bf8>] (__device_attach) from [<c0b56eb0>] (bus_probe_device+0x88/0x90)
[ 12.745751] [<c0b56eb0>] (bus_probe_device) from [<c0b53234>] (device_add+0x3d4/0x6e8)
[ 12.745782] [<c0b53234>] (device_add) from [<c097f664>] (amba_device_try_add+0x50/0x2d4)
[ 12.745812] [<c097f664>] (amba_device_try_add) from [<c097f924>] (amba_deferred_retry+0x3c/0x98)
[ 12.745847] [<c097f924>] (amba_deferred_retry) from [<c097f988>] (amba_deferred_retry_func+0x8/0x40)
[ 12.745881] [<c097f988>] (amba_deferred_retry_func) from [<c0365b6c>] (process_one_work+0x2b8/0x6e8)
[ 12.745912] [<c0365b6c>] (process_one_work) from [<c0365fe0>] (worker_thread+0x44/0x540)
[ 12.745942] [<c0365fe0>] (worker_thread) from [<c036d810>] (kthread+0x16c/0x178)
[ 12.745973] [<c036d810>] (kthread) from [<c03001a8>] (ret_from_fork+0x14/0x2c)
[ 12.746041] Exception stack(0xc73abfb0 to 0xc73abff8)
[ 12.746181] bfa0: 00000000 00000000 00000000 00000000
[ 12.746302] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 12.746397] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 12.746651] ---[ end trace 2a3f61da56bd8a49 ]---
---
# bad: [b0523c7b1c9d0edcd6c0fe6d2cb558a9ad5c60a8] Add linux-next specific files for 20200526
# good: [9cb1fd0efd195590b828b9b865421ad345a4a145] Linux 5.7-rc7
git bisect start 'next-20200526' 'v5.7-rc7'
# bad: [0c7351ad83670964e48cb9a098ad732c1ecbf804] Merge remote-tracking branch 'crypto/master'
git bisect bad 0c7351ad83670964e48cb9a098ad732c1ecbf804
# bad: [42e11d9b4682229fa7187d129758b8c382f8cd5d] Merge remote-tracking branch 'jc_docs/docs-next'
git bisect bad 42e11d9b4682229fa7187d129758b8c382f8cd5d
# bad: [ab6f501559e9efa687c711a781243cf6651a82d3] Merge remote-tracking branch 'm68k/for-next'
git bisect bad ab6f501559e9efa687c711a781243cf6651a82d3
# bad: [44aaa516ca63b3ab2da8ae81e9c6a58656e6acb5] Merge branch 'arm/drivers' into for-next
git bisect bad 44aaa516ca63b3ab2da8ae81e9c6a58656e6acb5
# good: [1cb00f8c3b36e6ae026fb58d1cd2ccd78b81aa9f] Merge tag 'qcom-arm64-for-5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/dt
git bisect good 1cb00f8c3b36e6ae026fb58d1cd2ccd78b81aa9f
# bad: [ed0c25932fbfafdfe37e9633dee21770d3c5a306] Merge branch 'arm/defconfig' into for-next
git bisect bad ed0c25932fbfafdfe37e9633dee21770d3c5a306
# bad: [9eddc06a3bc79402f50176703237ed045ae77b16] Merge branch 'mmp/fixes' into arm/dt
git bisect bad 9eddc06a3bc79402f50176703237ed045ae77b16
# bad: [87b990ab62722a8a3cb0691107971ab1bd7bddb5] Merge tag 'mvebu-dt64-5.8-1' of git://git.infradead.org/linux-mvebu into arm/dt
git bisect bad 87b990ab62722a8a3cb0691107971ab1bd7bddb5
# bad: [94cc3f1baabac5e5c4dcc6c2f070353f8315d0ee] arm64: dts: juno: Fix SCPI shared mem node name
git bisect bad 94cc3f1baabac5e5c4dcc6c2f070353f8315d0ee
# bad: [a78aee9e434932a500db36cc6d88daeff3745e9f] arm64: dts: juno: Fix GIC child nodes
git bisect bad a78aee9e434932a500db36cc6d88daeff3745e9f
# bad: [feebdc3f7950d7e44e914e821f6c04e58e292c74] arm64: dts: fvp: Move fixed clocks out of bus node
git bisect bad feebdc3f7950d7e44e914e821f6c04e58e292c74
# good: [849bfc3dfc13cde6ec04fbcf32af553ded9f7ec3] arm64: dts: fvp: Move fixed devices out of bus node
git bisect good 849bfc3dfc13cde6ec04fbcf32af553ded9f7ec3
# bad: [d9258898ad49cbb46caffe23af0d4f0b766e67a2] arm64: dts: vexpress: Move fixed devices out of bus node
git bisect bad d9258898ad49cbb46caffe23af0d4f0b766e67a2
# first bad commit: [d9258898ad49cbb46caffe23af0d4f0b766e67a2] arm64: dts: vexpress: Move fixed devices out of bus node
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 04/20] arm64: dts: arm: vexpress: Move fixed devices out of bus node
From: Guenter Roeck @ 2020-05-28 2:55 UTC (permalink / raw)
To: Andre Przywara
Cc: Mark Rutland, Rob Herring, Lorenzo Pieralisi, devicetree,
Liviu Dudau, Sudeep Holla, linux-arm-kernel
In-Reply-To: <20200528024810.GA232303@roeck-us.net>
On Wed, May 27, 2020 at 07:48:10PM -0700, Guenter Roeck wrote:
> On Wed, May 13, 2020 at 11:30:00AM +0100, Andre Przywara wrote:
> > The devicetree compiler complains when DT nodes without a reg property
> > live inside a (simple) bus node:
> > Warning (simple_bus_reg): Node /bus@8000000/motherboard-bus/refclk32khz
> > missing or empty reg/ranges property
> >
> > Move the fixed clocks, the fixed regulator, the leds and the config bus
> > subtree to the root node, since they do not depend on any busses.
> >
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>
> This patch results in tracebacks when booting the vexpress-a15 machine
> with vexpress-v2p-ca15-tc1 devicetree file in qemu. Reverting it as well
> as the subsequent patches affecting the same file (to avoid revert
> conflicts) fixes the problem.
>
On top of that, there is this message:
[ 19.817986] vexpress-reset mcc:reboot: Unable to restart (-14)
[ 20.818315] Reboot failed -- System halted
which also disappears after the patches have been reverted.
Here is my list of reverts on top of next-20200526:
bdc8a817612b (HEAD -> master) Revert "arm64: dts: vexpress: Move fixed devices out of bus node"
9a1f85df9e1a Revert "arm64: dts: fvp/juno: Fix serial node names"
381e0bbe8c00 Revert "arm64: dts: fvp/juno: Fix bus node names"
63723f67bf4b Revert "arm64: dts: vexpress: Fix VExpress LED names"
Guenter
> Guenter
>
> ---
> [ 12.744248] ------------[ cut here ]------------
> [ 12.744562] WARNING: CPU: 0 PID: 20 at drivers/tty/serial/serial_core.c:471 uart_get_baud_rate+0x100/0x154
> [ 12.744607] Modules linked in:
> [ 12.744785] CPU: 0 PID: 20 Comm: kworker/0:1 Not tainted 5.7.0-rc7-next-20200526 #1
> [ 12.744818] Hardware name: ARM-Versatile Express
> [ 12.745021] Workqueue: events amba_deferred_retry_func
> [ 12.745155] [<c0312484>] (unwind_backtrace) from [<c030c490>] (show_stack+0x10/0x14)
> [ 12.745206] [<c030c490>] (show_stack) from [<c0880f04>] (dump_stack+0xc8/0xdc)
> [ 12.745239] [<c0880f04>] (dump_stack) from [<c0346e44>] (__warn+0xdc/0xf4)
> [ 12.745270] [<c0346e44>] (__warn) from [<c0346f0c>] (warn_slowpath_fmt+0xb0/0xb8)
> [ 12.745302] [<c0346f0c>] (warn_slowpath_fmt) from [<c0a6b16c>] (uart_get_baud_rate+0x100/0x154)
> [ 12.745336] [<c0a6b16c>] (uart_get_baud_rate) from [<c0a7f5ac>] (pl011_set_termios+0x48/0x32c)
> [ 12.745367] [<c0a7f5ac>] (pl011_set_termios) from [<c0a6bbbc>] (uart_set_options+0x124/0x164)
> [ 12.745404] [<c0a6bbbc>] (uart_set_options) from [<c1b8c804>] (pl011_console_setup+0x214/0x230)
> [ 12.745438] [<c1b8c804>] (pl011_console_setup) from [<c03ab0d8>] (try_enable_new_console+0x98/0x138)
> [ 12.745469] [<c03ab0d8>] (try_enable_new_console) from [<c03acc64>] (register_console+0xe8/0x304)
> [ 12.745499] [<c03acc64>] (register_console) from [<c0a6c88c>] (uart_add_one_port+0x4c0/0x504)
> [ 12.745529] [<c0a6c88c>] (uart_add_one_port) from [<c0a80404>] (pl011_register_port+0x5c/0xac)
> [ 12.745568] [<c0a80404>] (pl011_register_port) from [<c097f5a0>] (amba_probe+0x9c/0x110)
> [ 12.745602] [<c097f5a0>] (amba_probe) from [<c0b57e84>] (really_probe+0x218/0x348)
> [ 12.745632] [<c0b57e84>] (really_probe) from [<c0b580c0>] (driver_probe_device+0x5c/0xb4)
> [ 12.745662] [<c0b580c0>] (driver_probe_device) from [<c0b55ff4>] (bus_for_each_drv+0x58/0xb8)
> [ 12.745692] [<c0b55ff4>] (bus_for_each_drv) from [<c0b57bf8>] (__device_attach+0xd4/0x140)
> [ 12.745721] [<c0b57bf8>] (__device_attach) from [<c0b56eb0>] (bus_probe_device+0x88/0x90)
> [ 12.745751] [<c0b56eb0>] (bus_probe_device) from [<c0b53234>] (device_add+0x3d4/0x6e8)
> [ 12.745782] [<c0b53234>] (device_add) from [<c097f664>] (amba_device_try_add+0x50/0x2d4)
> [ 12.745812] [<c097f664>] (amba_device_try_add) from [<c097f924>] (amba_deferred_retry+0x3c/0x98)
> [ 12.745847] [<c097f924>] (amba_deferred_retry) from [<c097f988>] (amba_deferred_retry_func+0x8/0x40)
> [ 12.745881] [<c097f988>] (amba_deferred_retry_func) from [<c0365b6c>] (process_one_work+0x2b8/0x6e8)
> [ 12.745912] [<c0365b6c>] (process_one_work) from [<c0365fe0>] (worker_thread+0x44/0x540)
> [ 12.745942] [<c0365fe0>] (worker_thread) from [<c036d810>] (kthread+0x16c/0x178)
> [ 12.745973] [<c036d810>] (kthread) from [<c03001a8>] (ret_from_fork+0x14/0x2c)
> [ 12.746041] Exception stack(0xc73abfb0 to 0xc73abff8)
> [ 12.746181] bfa0: 00000000 00000000 00000000 00000000
> [ 12.746302] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [ 12.746397] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
> [ 12.746651] ---[ end trace 2a3f61da56bd8a49 ]---
>
> ---
> # bad: [b0523c7b1c9d0edcd6c0fe6d2cb558a9ad5c60a8] Add linux-next specific files for 20200526
> # good: [9cb1fd0efd195590b828b9b865421ad345a4a145] Linux 5.7-rc7
> git bisect start 'next-20200526' 'v5.7-rc7'
> # bad: [0c7351ad83670964e48cb9a098ad732c1ecbf804] Merge remote-tracking branch 'crypto/master'
> git bisect bad 0c7351ad83670964e48cb9a098ad732c1ecbf804
> # bad: [42e11d9b4682229fa7187d129758b8c382f8cd5d] Merge remote-tracking branch 'jc_docs/docs-next'
> git bisect bad 42e11d9b4682229fa7187d129758b8c382f8cd5d
> # bad: [ab6f501559e9efa687c711a781243cf6651a82d3] Merge remote-tracking branch 'm68k/for-next'
> git bisect bad ab6f501559e9efa687c711a781243cf6651a82d3
> # bad: [44aaa516ca63b3ab2da8ae81e9c6a58656e6acb5] Merge branch 'arm/drivers' into for-next
> git bisect bad 44aaa516ca63b3ab2da8ae81e9c6a58656e6acb5
> # good: [1cb00f8c3b36e6ae026fb58d1cd2ccd78b81aa9f] Merge tag 'qcom-arm64-for-5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/dt
> git bisect good 1cb00f8c3b36e6ae026fb58d1cd2ccd78b81aa9f
> # bad: [ed0c25932fbfafdfe37e9633dee21770d3c5a306] Merge branch 'arm/defconfig' into for-next
> git bisect bad ed0c25932fbfafdfe37e9633dee21770d3c5a306
> # bad: [9eddc06a3bc79402f50176703237ed045ae77b16] Merge branch 'mmp/fixes' into arm/dt
> git bisect bad 9eddc06a3bc79402f50176703237ed045ae77b16
> # bad: [87b990ab62722a8a3cb0691107971ab1bd7bddb5] Merge tag 'mvebu-dt64-5.8-1' of git://git.infradead.org/linux-mvebu into arm/dt
> git bisect bad 87b990ab62722a8a3cb0691107971ab1bd7bddb5
> # bad: [94cc3f1baabac5e5c4dcc6c2f070353f8315d0ee] arm64: dts: juno: Fix SCPI shared mem node name
> git bisect bad 94cc3f1baabac5e5c4dcc6c2f070353f8315d0ee
> # bad: [a78aee9e434932a500db36cc6d88daeff3745e9f] arm64: dts: juno: Fix GIC child nodes
> git bisect bad a78aee9e434932a500db36cc6d88daeff3745e9f
> # bad: [feebdc3f7950d7e44e914e821f6c04e58e292c74] arm64: dts: fvp: Move fixed clocks out of bus node
> git bisect bad feebdc3f7950d7e44e914e821f6c04e58e292c74
> # good: [849bfc3dfc13cde6ec04fbcf32af553ded9f7ec3] arm64: dts: fvp: Move fixed devices out of bus node
> git bisect good 849bfc3dfc13cde6ec04fbcf32af553ded9f7ec3
> # bad: [d9258898ad49cbb46caffe23af0d4f0b766e67a2] arm64: dts: vexpress: Move fixed devices out of bus node
> git bisect bad d9258898ad49cbb46caffe23af0d4f0b766e67a2
> # first bad commit: [d9258898ad49cbb46caffe23af0d4f0b766e67a2] arm64: dts: vexpress: Move fixed devices out of bus node
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/4] Change i.MX/MXS SoCs ocotp/iim node name to efuse
From: Anson Huang @ 2020-05-28 3:12 UTC (permalink / raw)
To: robh+dt, shawnguo, s.hauer, kernel, festevam, daniel.baluta,
leonard.crestez, peng.fan, aford173, jun.li, shengjiu.wang,
horia.geanta, aisheng.dong, fugang.duan, agx, l.stach,
andrew.smirnov, devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
In the nvmem yaml schema, it requires the nodename to be one of
"eeprom|efuse|nvram", so need to change all i.MX/MXS SoCs ocotp/iim node
name to efuse:
MXS platforms: i.MX23/28;
i.MX platforms with IIM: i.MX25/27/31/35/51/53.
i.MX ARMv7 platforms with OCOTP: i.MX6QDL/6SL/6SX/6SLL/6UL/7S/7ULP.
i.MX ARMv8 platforms with OCOTP: i.MX8MQ/8MM/8MN/8MP.
Anson Huang (4):
ARM: dts: imx: change ocotp node name on i.MX6/7 SoCs
arm64: dts: imx8m: change ocotp node name on i.MX8M SoCs
ARM: dts: imx: change ocotp node name on MXS SoCs
ARM: dts: imx: change iim node name on i.MX SoCs
arch/arm/boot/dts/imx23.dtsi | 2 +-
arch/arm/boot/dts/imx25.dtsi | 2 +-
arch/arm/boot/dts/imx27.dtsi | 2 +-
arch/arm/boot/dts/imx28.dtsi | 2 +-
arch/arm/boot/dts/imx31.dtsi | 2 +-
arch/arm/boot/dts/imx35.dtsi | 2 +-
arch/arm/boot/dts/imx51.dtsi | 2 +-
arch/arm/boot/dts/imx53.dtsi | 2 +-
arch/arm/boot/dts/imx6qdl.dtsi | 2 +-
arch/arm/boot/dts/imx6sl.dtsi | 2 +-
arch/arm/boot/dts/imx6sll.dtsi | 2 +-
arch/arm/boot/dts/imx6sx.dtsi | 2 +-
arch/arm/boot/dts/imx6ul.dtsi | 2 +-
arch/arm/boot/dts/imx7s.dtsi | 2 +-
arch/arm/boot/dts/imx7ulp.dtsi | 2 +-
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 2 +-
arch/arm64/boot/dts/freescale/imx8mn.dtsi | 2 +-
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 2 +-
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 2 +-
19 files changed, 19 insertions(+), 19 deletions(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/4] ARM: dts: imx: change ocotp node name on i.MX6/7 SoCs
From: Anson Huang @ 2020-05-28 3:12 UTC (permalink / raw)
To: robh+dt, shawnguo, s.hauer, kernel, festevam, daniel.baluta,
leonard.crestez, peng.fan, aford173, jun.li, shengjiu.wang,
horia.geanta, aisheng.dong, fugang.duan, agx, l.stach,
andrew.smirnov, devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1590635570-8541-1-git-send-email-Anson.Huang@nxp.com>
Change OCOTP node name from ocotp-ctrl to efuse to be compliant with
yaml schema, it requires the nodename to be one of "eeprom|efuse|nvram".
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm/boot/dts/imx6qdl.dtsi | 2 +-
arch/arm/boot/dts/imx6sl.dtsi | 2 +-
arch/arm/boot/dts/imx6sll.dtsi | 2 +-
arch/arm/boot/dts/imx6sx.dtsi | 2 +-
arch/arm/boot/dts/imx6ul.dtsi | 2 +-
arch/arm/boot/dts/imx7s.dtsi | 2 +-
arch/arm/boot/dts/imx7ulp.dtsi | 2 +-
7 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 43d44d5..e14a6f2 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1162,7 +1162,7 @@
status = "disabled";
};
- ocotp: ocotp-ctrl@21bc000 {
+ ocotp: efuse@21bc000 {
compatible = "fsl,imx6q-ocotp", "syscon";
reg = <0x021bc000 0x4000>;
clocks = <&clks IMX6QDL_CLK_IIM>;
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index d8efc0a..11e7bf3 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -952,7 +952,7 @@
status = "disabled";
};
- ocotp: ocotp-ctrl@21bc000 {
+ ocotp: efuse@21bc000 {
compatible = "fsl,imx6sl-ocotp", "syscon";
reg = <0x021bc000 0x4000>;
clocks = <&clks IMX6SL_CLK_OCOTP>;
diff --git a/arch/arm/boot/dts/imx6sll.dtsi b/arch/arm/boot/dts/imx6sll.dtsi
index bf7f048..b715aa7 100644
--- a/arch/arm/boot/dts/imx6sll.dtsi
+++ b/arch/arm/boot/dts/imx6sll.dtsi
@@ -786,7 +786,7 @@
clocks = <&clks IMX6SLL_CLK_MMDC_P0_IPG>;
};
- ocotp: ocotp-ctrl@21bc000 {
+ ocotp: efuse@21bc000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,imx6sll-ocotp", "syscon";
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 8c4473b..5cccf69 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -1053,7 +1053,7 @@
status = "disabled";
};
- ocotp: ocotp-ctrl@21bc000 {
+ ocotp: efuse@21bc000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,imx6sx-ocotp", "syscon";
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index 505fd4f..a7a85c2 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -946,7 +946,7 @@
status = "disabled";
};
- ocotp: ocotp-ctrl@21bc000 {
+ ocotp: efuse@21bc000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,imx6ul-ocotp", "syscon";
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 3904558..4771d70 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -526,7 +526,7 @@
};
};
- ocotp: ocotp-ctrl@30350000 {
+ ocotp: efuse@30350000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,imx7d-ocotp", "syscon";
diff --git a/arch/arm/boot/dts/imx7ulp.dtsi b/arch/arm/boot/dts/imx7ulp.dtsi
index f7c4878..3674396 100644
--- a/arch/arm/boot/dts/imx7ulp.dtsi
+++ b/arch/arm/boot/dts/imx7ulp.dtsi
@@ -452,7 +452,7 @@
reg = <0x410a3000 0x1000>;
};
- ocotp: ocotp-ctrl@410a6000 {
+ ocotp: efuse@410a6000 {
compatible = "fsl,imx7ulp-ocotp", "syscon";
reg = <0x410a6000 0x4000>;
clocks = <&scg1 IMX7ULP_CLK_DUMMY>;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 4/4] ARM: dts: imx: change iim node name on i.MX SoCs
From: Anson Huang @ 2020-05-28 3:12 UTC (permalink / raw)
To: robh+dt, shawnguo, s.hauer, kernel, festevam, daniel.baluta,
leonard.crestez, peng.fan, aford173, jun.li, shengjiu.wang,
horia.geanta, aisheng.dong, fugang.duan, agx, l.stach,
andrew.smirnov, devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1590635570-8541-1-git-send-email-Anson.Huang@nxp.com>
Change IIM node name from iim to efuse to be compliant
with yaml schema, it requires the nodename to be one of
"eeprom|efuse|nvram".
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm/boot/dts/imx25.dtsi | 2 +-
arch/arm/boot/dts/imx27.dtsi | 2 +-
arch/arm/boot/dts/imx31.dtsi | 2 +-
arch/arm/boot/dts/imx35.dtsi | 2 +-
arch/arm/boot/dts/imx51.dtsi | 2 +-
arch/arm/boot/dts/imx53.dtsi | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index 1123e683..4eaf4eb 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -542,7 +542,7 @@
interrupts = <26>;
};
- iim: iim@53ff0000 {
+ iim: efuse@53ff0000 {
compatible = "fsl,imx25-iim", "fsl,imx27-iim";
reg = <0x53ff0000 0x4000>;
interrupts = <19>;
diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
index 002cd22..ee04771 100644
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -540,7 +540,7 @@
#clock-cells = <1>;
};
- iim: iim@10028000 {
+ iim: efuse@10028000 {
compatible = "fsl,imx27-iim";
reg = <0x10028000 0x1000>;
interrupts = <62>;
diff --git a/arch/arm/boot/dts/imx31.dtsi b/arch/arm/boot/dts/imx31.dtsi
index 18270ec..4f3d7ab 100644
--- a/arch/arm/boot/dts/imx31.dtsi
+++ b/arch/arm/boot/dts/imx31.dtsi
@@ -217,7 +217,7 @@
status = "disabled";
};
- iim: iim@5001c000 {
+ iim: efuse@5001c000 {
compatible = "fsl,imx31-iim", "fsl,imx27-iim";
reg = <0x5001c000 0x1000>;
interrupts = <19>;
diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi
index 2ebf2c1..502112b 100644
--- a/arch/arm/boot/dts/imx35.dtsi
+++ b/arch/arm/boot/dts/imx35.dtsi
@@ -320,7 +320,7 @@
status = "disabled";
};
- iim@53ff0000 {
+ efuse@53ff0000 {
compatible = "fsl,imx35-iim";
reg = <0x53ff0000 0x4000>;
interrupts = <19>;
diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index d3583aa..c83bc77 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -466,7 +466,7 @@
reg = <0x83f00000 0x60>;
};
- iim: iim@83f98000 {
+ iim: efuse@83f98000 {
compatible = "fsl,imx51-iim", "fsl,imx27-iim";
reg = <0x83f98000 0x4000>;
interrupts = <69>;
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index afa57bf..ed6b0c8 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -667,7 +667,7 @@
reg = <0x63f00000 0x60>;
};
- iim: iim@63f98000 {
+ iim: efuse@63f98000 {
compatible = "fsl,imx53-iim", "fsl,imx27-iim";
reg = <0x63f98000 0x4000>;
interrupts = <69>;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/4] ARM: dts: imx: change ocotp node name on MXS SoCs
From: Anson Huang @ 2020-05-28 3:12 UTC (permalink / raw)
To: robh+dt, shawnguo, s.hauer, kernel, festevam, daniel.baluta,
leonard.crestez, peng.fan, aford173, jun.li, shengjiu.wang,
horia.geanta, aisheng.dong, fugang.duan, agx, l.stach,
andrew.smirnov, devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1590635570-8541-1-git-send-email-Anson.Huang@nxp.com>
Change OCOTP node name from ocotp to efuse to be compliant
with yaml schema, it requires the nodename to be one of
"eeprom|efuse|nvram".
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm/boot/dts/imx23.dtsi | 2 +-
arch/arm/boot/dts/imx28.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
index c5edff3..18289f6 100644
--- a/arch/arm/boot/dts/imx23.dtsi
+++ b/arch/arm/boot/dts/imx23.dtsi
@@ -442,7 +442,7 @@
status = "disabled";
};
- ocotp@8002c000 {
+ efuse@8002c000 {
compatible = "fsl,imx23-ocotp", "fsl,ocotp";
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index a1cbbeb..a2b799c 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -1011,7 +1011,7 @@
status = "disabled";
};
- ocotp: ocotp@8002c000 {
+ ocotp: efuse@8002c000 {
compatible = "fsl,imx28-ocotp", "fsl,ocotp";
#address-cells = <1>;
#size-cells = <1>;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/4] arm64: dts: imx8m: change ocotp node name on i.MX8M SoCs
From: Anson Huang @ 2020-05-28 3:12 UTC (permalink / raw)
To: robh+dt, shawnguo, s.hauer, kernel, festevam, daniel.baluta,
leonard.crestez, peng.fan, aford173, jun.li, shengjiu.wang,
horia.geanta, aisheng.dong, fugang.duan, agx, l.stach,
andrew.smirnov, devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1590635570-8541-1-git-send-email-Anson.Huang@nxp.com>
Change OCOTP node name from ocotp-ctrl to efuse to be compliant with
yaml schema, it requires the nodename to be one of "eeprom|efuse|nvram".
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 2 +-
arch/arm64/boot/dts/freescale/imx8mn.dtsi | 2 +-
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 2 +-
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index aaf6e71..740cc62 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -467,7 +467,7 @@
reg = <0x30340000 0x10000>;
};
- ocotp: ocotp-ctrl@30350000 {
+ ocotp: efuse@30350000 {
compatible = "fsl,imx8mm-ocotp", "syscon";
reg = <0x30350000 0x10000>;
clocks = <&clk IMX8MM_CLK_OCOTP_ROOT>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index 9a4b65a..0625cc8 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -374,7 +374,7 @@
reg = <0x30340000 0x10000>;
};
- ocotp: ocotp-ctrl@30350000 {
+ ocotp: efuse@30350000 {
compatible = "fsl,imx8mn-ocotp", "fsl,imx8mm-ocotp", "syscon";
reg = <0x30350000 0x10000>;
clocks = <&clk IMX8MN_CLK_OCOTP_ROOT>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index 23e9a4c..c248e7f 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -340,7 +340,7 @@
reg = <0x30340000 0x10000>;
};
- ocotp: ocotp-ctrl@30350000 {
+ ocotp: efuse@30350000 {
compatible = "fsl,imx8mp-ocotp", "syscon";
reg = <0x30350000 0x10000>;
clocks = <&clk IMX8MP_CLK_OCOTP_ROOT>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 978f812..b156cd5 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -539,7 +539,7 @@
};
};
- ocotp: ocotp-ctrl@30350000 {
+ ocotp: efuse@30350000 {
compatible = "fsl,imx8mq-ocotp", "syscon";
reg = <0x30350000 0x10000>;
clocks = <&clk IMX8MQ_CLK_OCOTP_ROOT>;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v3 3/5] drm: panel: Add Xingbangda XBD599 panel (ST7703 controller)
From: Samuel Holland @ 2020-05-28 3:31 UTC (permalink / raw)
To: Ondrej Jirman, linux-sunxi, Thierry Reding, Sam Ravnborg,
David Airlie, Daniel Vetter, Rob Herring, Maxime Ripard,
Chen-Yu Tsai, Linus Walleij, Icenowy Zheng
Cc: devicetree, Bhushan Shah, linux-kernel, dri-devel, Luca Weiss,
Martijn Braam, linux-arm-kernel
In-Reply-To: <20200513212451.1919013-4-megous@megous.com>
On 5/13/20 4:24 PM, Ondrej Jirman wrote:
> From: Icenowy Zheng <icenowy@aosc.io>
>
> Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI IPS LCD panel made by
> Xingbangda, which is used on PinePhone final assembled phones.
>
> It is based on Sitronix ST7703 LCD controller.
>
> Add support for it.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Signed-off-by: Ondrej Jirman <megous@megous.com>
> ---
> drivers/gpu/drm/panel/Kconfig | 10 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 386 ++++++++++++++++++
> 3 files changed, 397 insertions(+)
> create mode 100644 drivers/gpu/drm/panel/panel-sitronix-st7703.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 39055c1f0e2f..b7bc157b0612 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -395,6 +395,16 @@ config DRM_PANEL_SITRONIX_ST7701
> ST7701 controller for 480X864 LCD panels with MIPI/RGB/SPI
> system interfaces.
>
> +config DRM_PANEL_SITRONIX_ST7703
> + tristate "Sitronix ST7703 panel driver"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE
> + help
> + Say Y here if you want to enable support for the Sitronix
> + ST7703 controller for 720X1440 LCD panels with MIPI/RGB/SPI
> + system interfaces.
> +
> config DRM_PANEL_SITRONIX_ST7789V
> tristate "Sitronix ST7789V panel"
> depends on OF && SPI
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index de74f282c433..47f4789a8685 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -41,6 +41,7 @@ obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
> obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) += panel-sitronix-st7701.o
> +obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7703) += panel-sitronix-st7703.o
> obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
> obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o
> obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> new file mode 100644
> index 000000000000..092dd73c86d0
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -0,0 +1,386 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * DRM driver for Sitronix ST7703 MIPI DSI panel
> + *
> + * Copyright (C) 2020 Ondrej Jirman <megous@megous.com>
> + * Copyright (C) 2019-2020 Icenowy Zheng <icenowy@aosc.io>
> + *
> + * Based on panel-rocktech-jh057n00900.c, which is:
> + * Copyright (C) Purism SPC 2019
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/regulator/consumer.h>
> +
> +#include <drm/drm_mipi_dsi.h>
> +#include <drm/drm_modes.h>
> +#include <drm/drm_panel.h>
> +#include <drm/drm_print.h>
> +
> +/* Manufacturer specific Commands send via DSI */
> +#define ST7703_CMD_ALL_PIXEL_OFF 0x22
> +#define ST7703_CMD_ALL_PIXEL_ON 0x23
> +#define ST7703_CMD_SETDISP 0xB2
> +#define ST7703_CMD_SETRGBIF 0xB3
> +#define ST7703_CMD_SETCYC 0xB4
> +#define ST7703_CMD_SETBGP 0xB5
> +#define ST7703_CMD_SETVCOM 0xB6
> +#define ST7703_CMD_SETOTP 0xB7
> +#define ST7703_CMD_SETPOWER_EXT 0xB8
> +#define ST7703_CMD_SETEXTC 0xB9
> +#define ST7703_CMD_SETMIPI 0xBA
> +#define ST7703_CMD_SETVDC 0xBC
> +#define ST7703_CMD_SETSCR 0xC0
> +#define ST7703_CMD_SETPOWER 0xC1
> +#define ST7703_CMD_UNK_C6 0xC6
> +#define ST7703_CMD_SETPANEL 0xCC
> +#define ST7703_CMD_SETGAMMA 0xE0
> +#define ST7703_CMD_SETEQ 0xE3
> +#define ST7703_CMD_SETGIP1 0xE9
> +#define ST7703_CMD_SETGIP2 0xEA
> +
> +struct st7703_panel_desc {
> + const struct drm_display_mode *mode;
> + unsigned int lanes;
> + unsigned long flags;
> + enum mipi_dsi_pixel_format format;
> + const char *const *supply_names;
> + unsigned int num_supplies;
> +};
> +
> +struct st7703 {
> + struct device *dev;
> + struct drm_panel panel;
> + struct gpio_desc *reset_gpio;
> + struct regulator_bulk_data *supplies;
> + const struct st7703_panel_desc *desc;
> + bool prepared;
> +};
> +
> +static inline struct st7703 *panel_to_st7703(struct drm_panel *panel)
> +{
> + return container_of(panel, struct st7703, panel);
> +}
> +
> +#define dsi_dcs_write_seq(dsi, cmd, seq...) do { \
> + static const u8 d[] = { seq }; \
> + int ret; \
> + ret = mipi_dsi_dcs_write(dsi, cmd, d, ARRAY_SIZE(d)); \
> + if (ret < 0) \
> + return ret; \
> + } while (0)
> +
> +static int st7703_init_sequence(struct st7703 *ctx)
> +{
> + struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> + struct device *dev = ctx->dev;
> + int ret;
> +
> + /*
> + * Init sequence was supplied by the panel vendor.
> + */
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETEXTC,
> + 0xF1, 0x12, 0x83);
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETMIPI,
> + 0x33, 0x81, 0x05, 0xF9, 0x0E, 0x0E, 0x20, 0x00,
> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x44, 0x25,
> + 0x00, 0x91, 0x0a, 0x00, 0x00, 0x02, 0x4F, 0x11,
> + 0x00, 0x00, 0x37);
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETPOWER_EXT,
> + 0x25, 0x22, 0x20, 0x03);
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETRGBIF,
> + 0x10, 0x10, 0x05, 0x05, 0x03, 0xFF, 0x00, 0x00,
> + 0x00, 0x00);
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETSCR,
> + 0x73, 0x73, 0x50, 0x50, 0x00, 0xC0, 0x08, 0x70,
> + 0x00);
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETVDC, 0x4E);
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETPANEL, 0x0B);
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETCYC, 0x80);
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETDISP, 0xF0, 0x12, 0xF0);
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETEQ,
> + 0x00, 0x00, 0x0B, 0x0B, 0x10, 0x10, 0x00, 0x00,
> + 0x00, 0x00, 0xFF, 0x00, 0xC0, 0x10);
> + dsi_dcs_write_seq(dsi, 0xC6, 0x01, 0x00, 0xFF, 0xFF, 0x00);
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETPOWER,
> + 0x74, 0x00, 0x32, 0x32, 0x77, 0xF1, 0xFF, 0xFF,
> + 0xCC, 0xCC, 0x77, 0x77);
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETBGP, 0x07, 0x07);
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETVCOM, 0x2C, 0x2C);
> + dsi_dcs_write_seq(dsi, 0xBF, 0x02, 0x11, 0x00);
> +
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETGIP1,
> + 0x82, 0x10, 0x06, 0x05, 0xA2, 0x0A, 0xA5, 0x12,
> + 0x31, 0x23, 0x37, 0x83, 0x04, 0xBC, 0x27, 0x38,
> + 0x0C, 0x00, 0x03, 0x00, 0x00, 0x00, 0x0C, 0x00,
> + 0x03, 0x00, 0x00, 0x00, 0x75, 0x75, 0x31, 0x88,
> + 0x88, 0x88, 0x88, 0x88, 0x88, 0x13, 0x88, 0x64,
> + 0x64, 0x20, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88,
> + 0x02, 0x88, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00);
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETGIP2,
> + 0x02, 0x21, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00, 0x02, 0x46, 0x02, 0x88,
> + 0x88, 0x88, 0x88, 0x88, 0x88, 0x64, 0x88, 0x13,
> + 0x57, 0x13, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88,
> + 0x75, 0x88, 0x23, 0x14, 0x00, 0x00, 0x02, 0x00,
> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x0A,
> + 0xA5, 0x00, 0x00, 0x00, 0x00);
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETGAMMA,
> + 0x00, 0x09, 0x0D, 0x23, 0x27, 0x3C, 0x41, 0x35,
> + 0x07, 0x0D, 0x0E, 0x12, 0x13, 0x10, 0x12, 0x12,
> + 0x18, 0x00, 0x09, 0x0D, 0x23, 0x27, 0x3C, 0x41,
> + 0x35, 0x07, 0x0D, 0x0E, 0x12, 0x13, 0x10, 0x12,
> + 0x12, 0x18);
> + msleep(20);
> +
> + ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dev, "Failed to exit sleep mode\n");
> + return ret;
> + }
> + msleep(250);
> +
> + ret = mipi_dsi_dcs_set_display_on(dsi);
Since you have the complementary call to mipi_dsi_dcs_set_display_off in
st7703_disable, I would suggest calling this from st7703_enable, after the call
to st7703_init_sequence. [but see below about moving all of this to prepare.]
> + if (ret)
> + return ret;
> + msleep(50);
This is the last step of the init sequence. According to table 8-1 of the
manual, T10 needs no delay. What is this delay for?
> +
> + DRM_DEV_DEBUG_DRIVER(dev, "Panel init sequence done\n");
> + return 0;
> +}
> +
> +static int st7703_prepare(struct drm_panel *panel)
> +{
> + struct st7703 *ctx = panel_to_st7703(panel);
> + int ret;
> +
> + if (ctx->prepared)
> + return 0;
> +
> + ret = regulator_bulk_enable(ctx->desc->num_supplies, ctx->supplies);
> + if (ret)
> + return ret;
> +
> + DRM_DEV_DEBUG_DRIVER(ctx->dev, "Resetting the panel\n");
> + gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> + usleep_range(20, 40);
> + gpiod_set_value_cansleep(ctx->reset_gpio, 0);
> + msleep(20);
> +
> + ctx->prepared = true;
> +
> + return 0;
> +}
> +
> +static int st7703_enable(struct drm_panel *panel)
> +{
> + struct st7703 *ctx = panel_to_st7703(panel);
> + int ret;
> +
> + ret = st7703_init_sequence(ctx);
v1 had this function called from prepare, not enable. From reading the comments
in drm_panel.h, that seems to be the right place for it.
> + if (ret < 0) {
> + DRM_DEV_ERROR(ctx->dev, "Panel init sequence failed: %d\n",
> + ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int st7703_disable(struct drm_panel *panel)
> +{
> + struct st7703 *ctx = panel_to_st7703(panel);
> + struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> +
> + return mipi_dsi_dcs_set_display_off(dsi);
The datasheet suggests in "5.6 Power on/off Sequence" that there also needs to
be a call to mipi_dsi_dcs_enter_sleep_mode() here.
> +}
> +
> +static int st7703_unprepare(struct drm_panel *panel)
> +{
> + struct st7703 *ctx = panel_to_st7703(panel);
> +
> + if (!ctx->prepared)
> + return 0;
> +
> + gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> + regulator_bulk_disable(ctx->desc->num_supplies, ctx->supplies);
> + ctx->prepared = false;
> +
> + return 0;
> +}
> +
> +static int st7703_get_modes(struct drm_panel *panel,
> + struct drm_connector *connector)
> +{
> + struct st7703 *ctx = panel_to_st7703(panel);
> + struct drm_display_mode *mode;
> +
> + mode = drm_mode_duplicate(connector->dev, ctx->desc->mode);
> + if (!mode) {
> + DRM_DEV_ERROR(ctx->dev, "Failed to add mode\n");
> + return -ENOMEM;
> + }
> +
> + drm_mode_set_name(mode);
> +
> + mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
This line...
> + connector->display_info.width_mm = mode->width_mm;
> + connector->display_info.height_mm = mode->height_mm;
> + drm_mode_probed_add(connector, mode);
> +
> + return 1;
> +}
> +
> +static const struct drm_panel_funcs st7703_drm_funcs = {
> + .prepare = st7703_prepare,
> + .enable = st7703_enable,
> + .disable = st7703_disable,
> + .unprepare = st7703_unprepare,
> + .get_modes = st7703_get_modes,
> +};
> +
> +static const struct drm_display_mode xbd599_mode = {
> + .hdisplay = 720,
> + .hsync_start = 720 + 40,
> + .hsync_end = 720 + 40 + 40,
> + .htotal = 720 + 40 + 40 + 40,
> + .vdisplay = 1440,
> + .vsync_start = 1440 + 18,
> + .vsync_end = 1440 + 18 + 10,
> + .vtotal = 1440 + 18 + 10 + 17,
> + .vrefresh = 60,
> + .clock = 69000,
> + .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
> +
> + .width_mm = 68,
> + .height_mm = 136,
> + .type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
...duplicates this line. I'm not sure which is the better place to put it; panel
drivers seem evenly split. But it doesn't need to be in both places.
Cheers,
Samuel
> +};
> +
> +static const char * const xbd599_supply_names[] = {
> + "iovcc",
> + "vcc",
> +};
> +
> +static const struct st7703_panel_desc xbd599_desc = {
> + .mode = &xbd599_mode,
> + .lanes = 4,
> + .flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE,
> + .format = MIPI_DSI_FMT_RGB888,
> + .supply_names = xbd599_supply_names,
> + .num_supplies = ARRAY_SIZE(xbd599_supply_names),
> +};
> +
> +static int st7703_probe(struct mipi_dsi_device *dsi)
> +{
> + const struct st7703_panel_desc *desc;
> + struct device *dev = &dsi->dev;
> + struct st7703 *ctx;
> + int i, ret;
> +
> + ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> + if (!ctx)
> + return -ENOMEM;
> +
> + ctx->dev = dev;
> + ctx->desc = desc = of_device_get_match_data(dev);
> +
> + dsi->mode_flags = desc->flags;
> + dsi->format = desc->format;
> + dsi->lanes = desc->lanes;
> +
> + ctx->supplies = devm_kcalloc(&dsi->dev, desc->num_supplies,
> + sizeof(*ctx->supplies),
> + GFP_KERNEL);
> + if (!ctx->supplies)
> + return -ENOMEM;
> +
> + for (i = 0; i < desc->num_supplies; i++)
> + ctx->supplies[i].supply = desc->supply_names[i];
> +
> + ret = devm_regulator_bulk_get(&dsi->dev, desc->num_supplies,
> + ctx->supplies);
> + if (ret < 0)
> + return ret;
> +
> + ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
> + if (IS_ERR(ctx->reset_gpio)) {
> + DRM_DEV_ERROR(dev, "Can't get reset gpio\n");
> + return PTR_ERR(ctx->reset_gpio);
> + }
> +
> + mipi_dsi_set_drvdata(dsi, ctx);
> +
> + drm_panel_init(&ctx->panel, &dsi->dev, &st7703_drm_funcs,
> + DRM_MODE_CONNECTOR_DSI);
> +
> + ret = drm_panel_of_backlight(&ctx->panel);
> + if (ret)
> + return ret;
> +
> + drm_panel_add(&ctx->panel);
> +
> + ret = mipi_dsi_attach(dsi);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dev, "mipi_dsi_attach failed. Is host ready?\n");
> + drm_panel_remove(&ctx->panel);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static void st7703_shutdown(struct mipi_dsi_device *dsi)
> +{
> + struct st7703 *ctx = mipi_dsi_get_drvdata(dsi);
> + int ret;
> +
> + ret = drm_panel_unprepare(&ctx->panel);
> + if (ret < 0)
> + DRM_DEV_ERROR(&dsi->dev, "Failed to unprepare panel: %d\n",
> + ret);
> +}
> +
> +static int st7703_remove(struct mipi_dsi_device *dsi)
> +{
> + struct st7703 *ctx = mipi_dsi_get_drvdata(dsi);
> + int ret;
> +
> + st7703_shutdown(dsi);
> +
> + ret = mipi_dsi_detach(dsi);
> + if (ret < 0)
> + DRM_DEV_ERROR(&dsi->dev, "Failed to detach from DSI host: %d\n",
> + ret);
> +
> + drm_panel_remove(&ctx->panel);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id st7703_of_match[] = {
> + { .compatible = "xingbangda,xbd599", .data = &xbd599_desc },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, st7703_of_match);
> +
> +static struct mipi_dsi_driver st7703_driver = {
> + .probe = st7703_probe,
> + .remove = st7703_remove,
> + .shutdown = st7703_shutdown,
> + .driver = {
> + .name = "st7703",
> + .of_match_table = st7703_of_match,
> + },
> +};
> +module_mipi_dsi_driver(st7703_driver);
> +
> +MODULE_AUTHOR("Icenowy Zheng <icenowy@aosc.io>");
> +MODULE_DESCRIPTION("DRM driver for Sitronix ST7703 MIPI DSI panel");
> +MODULE_LICENSE("GPL v2");
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [V9, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
From: Dongchun Zhu @ 2020-05-28 3:34 UTC (permalink / raw)
To: Sakari Ailus
Cc: Mark Rutland, Rob Herring, Andy Shevchenko, srv_heupstream,
devicetree, Linus Walleij,
Shengnan Wang (王圣男), Tomasz Figa,
Bartosz Golaszewski, Sj Huang, Nicolas Boichat,
moderated list:ARM/Mediatek SoC support, dongchun.zhu, Louis Kuo,
Matthias Brugger, Cao Bing Bu, Mauro Carvalho Chehab,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Linux Media Mailing List
In-Reply-To: <20200527211628.GT7618@paasikivi.fi.intel.com>
Hi Sakari, Rob,
On Thu, 2020-05-28 at 00:16 +0300, Sakari Ailus wrote:
> Hi Rob, Dongchun,
>
> On Wed, May 27, 2020 at 09:27:22AM -0600, Rob Herring wrote:
> > > > > + properties:
> > > > > + endpoint:
> > > > > + type: object
> > > > > + additionalProperties: false
> > > > > +
> > > > > + properties:
> > >
> > > Actually I wonder whether we need to declare 'clock-lanes' here?
> >
> > Yes, if you are using it.
>
> Dongchun, can you confirm the chip has a single data and a single clock
> lane and that it does not support lane reordering?
>
From the datasheet, 'MIPI inside the OV02A10 provides one single
uni-directional clock lane and one bi-directional data lane solution for
communication links between components inside a mobile device.
The data lane has full support for HS(uni-directional) and
LP(bi-directional) data transfer mode.'
The sensor doesn't support lane reordering, so 'clock-lanes' property
would not be added in next release.
> So if there's nothing to convey to the driver, also the data-lanes should
> be removed IMO.
>
However, 'data-lanes' property may still be required.
It is known that either data-lanes or clock-lanes is an array of
physical data lane indexes. Position of an entry determines the logical
lane number, while the value of an entry indicates physical lane, e.g.,
for 1-lane MIPI CSI-2 bus we could have "data-lanes = <1>;", assuming
the clock lane is on hardware lane 0.
As mentioned earlier, the OV02A10 sensor supports only 1C1D and does not
support lane reordering, so here we shall use 'data-lanes = <1>' as
there is only a clock lane for OV02A10.
Reminder:
If 'data-lanes' property is not present, the driver would assume
four-lane operation. This means for one-lane or two-lane operation, this
property must be present and set to the right physical lane indexes.
If the hardware does not support lane reordering, monotonically
incremented values shall be used from 0 or 1 onwards, depending on
whether or not there is also a clock lane.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: sparx5: Add hwmon temperature sensor
From: Alexandre Belloni @ 2020-05-28 3:39 UTC (permalink / raw)
To: Rob Herring
Cc: linux-hwmon, devicetree, Jean Delvare, linux-kernel,
Microchip Linux Driver Support, SoC Team, Lars Povlsen,
Guenter Roeck, linux-arm-kernel
In-Reply-To: <20200528022931.GA3238321@bogus>
Hi Rob,
On 27/05/2020 20:29:31-0600, Rob Herring wrote:
> On Wed, May 13, 2020 at 03:41:39PM +0200, Lars Povlsen wrote:
> > This adds a hwmon temperature node sensor to the Sparx5 SoC.
> >
> > Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> > Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
> > ---
> > arch/arm64/boot/dts/microchip/sparx5.dtsi | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/microchip/sparx5.dtsi b/arch/arm64/boot/dts/microchip/sparx5.dtsi
> > index f09a49c41ce19..b5f2d088af30e 100644
> > --- a/arch/arm64/boot/dts/microchip/sparx5.dtsi
> > +++ b/arch/arm64/boot/dts/microchip/sparx5.dtsi
> > @@ -233,5 +233,11 @@ i2c1: i2c@600103000 {
> > clock-frequency = <100000>;
> > clocks = <&ahb_clk>;
> > };
> > +
> > + tmon0: tmon@610508110 {
> > + compatible = "microchip,sparx5-temp";
> > + reg = <0x6 0x10508110 0xc>;
>
> These nodes are all very odd with a couple of registers spread out at
> randomish addresses. DT nodes should roughly correlate to h/w blocks,
> not sets of registers for a driver like this seems to be.
>
The DT nodes correlates to HW block, this and the previous families of
SoCs were designed with packed registers. There is no padding between HW
block registers.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Cache flush issue with page_mapping_file() and swap back shmem page ?
From: Hugh Dickins @ 2020-05-28 3:46 UTC (permalink / raw)
To: Jerome Glisse
Cc: Rich Felker, linux-sh, Catalin Marinas, linux-mips,
James E.J. Bottomley, linux-mm, Guo Ren, sparclinux, Paul Burton,
Helge Deller, Huang Ying, James Hogan, rmk+kernel, linux-xtensa,
Steven Capper, Rabin Vincent, Ley Foon Tan, Guan Xuetao,
linux-arm-kernel, Chris Zankel, Yoshinori Sato, linux-parisc,
Max Filippov, linux-kernel, Ralf Baechle, nios2-dev,
Andrew Morton, David S. Miller
In-Reply-To: <20200528002033.GB1992500@redhat.com>
Hi Jerome,
On Wed, 27 May 2020, Jerome Glisse wrote:
> So any arch code which uses page_mapping_file() might get the wrong
> answer, this function will return NULL for a swap backed page which
> can be a shmem pages. But shmem pages can still be shared among
> multiple process (and possibly at different virtual addresses if
> mremap was use).
>
> Attached is a patch that changes page_mapping_file() to return the
> shmem mapping for swap backed shmem page. I have not tested it (no
> way for me to test all those architecture) and i spotted this while
> working on something else. So i hope someone can take a closer look.
I'm certainly no expert on flush_dcache_page() and friends, but I'd
be very surprised if such a problem exists, yet has gone unnoticed
for so long. page_mapping_file() itself is fairly new, added when
a risk of crashing on a race with swapoff came in: but the previous
use of page_mapping() would have suffered equally if there were such
a cache flushinhg problem here.
And I'm afraid your patch won't do anything to help if there is a
problem: very soon after shmem calls add_to_swap_cache(), it calls
shmem_delete_from_page_cache(), which sets page->mapping to NULL.
But I can assure you that a shmem page (unlike an anon page) is never
put into swap cache while it is mapped into userspace, and never
mapped into userspace while it is still in swap cache: does that help?
Hugh
> This might be a shmem page that is in a sense a file that
> can be mapped multiple times in different processes at
> possibly different virtual addresses (fork + mremap). So
> return the shmem mapping that will allow any arch code to
> find all mappings of the page.
>
> Note that even if page is not anonymous then the page might
> have a NULL page->mapping field if it is being truncated,
> but then it is fine as each pte poiting to the page will be
> remove and cache flushing should be handled properly by that
> part of the code.
>
> Signed-off-by: Jerome Glisse <jglisse@redhat.com>
> Cc: "Huang, Ying" <ying.huang@intel.com>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Mel Gorman <mgorman@techsingularity.net>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
> ---
> mm/util.c | 18 +++++++++++++++++-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/mm/util.c b/mm/util.c
> index 988d11e6c17c..ec8739ab0cc3 100644
> --- a/mm/util.c
> +++ b/mm/util.c
> @@ -685,8 +685,24 @@ EXPORT_SYMBOL(page_mapping);
> */
> struct address_space *page_mapping_file(struct page *page)
> {
> - if (unlikely(PageSwapCache(page)))
> + if (unlikely(PageSwapCache(page))) {
> + /*
> + * This might be a shmem page that is in a sense a file that
> + * can be mapped multiple times in different processes at
> + * possibly different virtual addresses (fork + mremap). So
> + * return the shmem mapping that will allow any arch code to
> + * find all mappings of the page.
> + *
> + * Note that even if page is not anonymous then the page might
> + * have a NULL page->mapping field if it is being truncated,
> + * but then it is fine as each pte poiting to the page will be
> + * remove and cache flushing should be handled properly by that
> + * part of the code.
> + */
> + if (!PageAnon(page))
> + return page->mapping;
> return NULL;
> + }
> return page_mapping(page);
> }
>
> --
> 2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 2/2] ARM: DTS: Keystone update for v5.8
From: Santosh Shilimkar @ 2020-05-28 4:01 UTC (permalink / raw)
To: arm, linux-arm-kernel
Cc: arnd, khilman, santosh.shilimkar, linux-kernel, soc, olof
In-Reply-To: <1590638489-12023-1-git-send-email-santosh.shilimkar@oracle.com>
The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/keystone_dts_for_5.8
for you to fetch changes up to 644c5a582261ecdf1df41b11d05d10a1cccc0a66:
ARM: dts: keystone: Rename "msmram" node to "sram" (2020-05-27 20:36:32 -0700)
----------------------------------------------------------------
ARM: dts: Keystone update for v5.8
- Rename "msmram" node to "sram"
----------------------------------------------------------------
Krzysztof Kozlowski (1):
ARM: dts: keystone: Rename "msmram" node to "sram"
arch/arm/boot/dts/keystone-k2e.dtsi | 4 ++--
arch/arm/boot/dts/keystone-k2g.dtsi | 4 ++--
arch/arm/boot/dts/keystone-k2hk.dtsi | 4 ++--
arch/arm/boot/dts/keystone-k2l.dtsi | 4 ++--
4 files changed, 8 insertions(+), 8 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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