* RE: [PATCH v7 RESEND 07/13] spi: imx: fix ERR009165
From: Robin Gong @ 2020-05-13 8:38 UTC (permalink / raw)
To: Sascha Hauer
Cc: vkoul@kernel.org, shawnguo@kernel.org,
u.kleine-koenig@pengutronix.de, robh+dt@kernel.org,
festevam@gmail.com, dan.j.williams@intel.com,
mark.rutland@arm.com, catalin.marinas@arm.com,
will.deacon@arm.com, l.stach@pengutronix.de,
martin.fuzzey@flowbird.group, kernel@pengutronix.de,
linux-spi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dl-linux-imx,
dmaengine@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <20200513072132.GL5877@pengutronix.de>
On 2020/05/13 Sascha Hauer <s.hauer@pengutronix.de> wrote:
> This patch is the one bisecting will end up with when somebody uses an older
> SDMA firmware or the ROM scripts. It should have a better description what
> happens and what should be done about it.
Emm..That's true. Timeout will be caught in such case, hence, maybe we can fall back it to pio always.
> >
> > Signed-off-by: Robin Gong <yibin.gong@nxp.com>
> > Acked-by: Mark Brown <broonie@kernel.org>
> > ---
> > drivers/spi/spi-imx.c | 16 ++++++++--------
> > 1 file changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c index
> > f4f28a4..70df8e6 100644
> > --- a/drivers/spi/spi-imx.c
> > +++ b/drivers/spi/spi-imx.c
> > @@ -585,8 +585,8 @@ static int mx51_ecspi_prepare_transfer(struct
> spi_imx_data *spi_imx,
> > ctrl |= mx51_ecspi_clkdiv(spi_imx, t->speed_hz, &clk);
> > spi_imx->spi_bus_clk = clk;
> >
> > - if (spi_imx->usedma)
> > - ctrl |= MX51_ECSPI_CTRL_SMC;
> > + /* ERR009165: work in XHC mode as PIO */
> > + ctrl &= ~MX51_ECSPI_CTRL_SMC;
> >
> > writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);
> >
> > @@ -617,7 +617,7 @@ static void mx51_setup_wml(struct spi_imx_data
> *spi_imx)
> > * and enable DMA request.
> > */
> > writel(MX51_ECSPI_DMA_RX_WML(spi_imx->wml - 1) |
> > - MX51_ECSPI_DMA_TX_WML(spi_imx->wml) |
> > + MX51_ECSPI_DMA_TX_WML(0) |
> > MX51_ECSPI_DMA_RXT_WML(spi_imx->wml) |
> > MX51_ECSPI_DMA_TEDEN | MX51_ECSPI_DMA_RXDEN |
> > MX51_ECSPI_DMA_RXTDEN, spi_imx->base + MX51_ECSPI_DMA);
> @@ -1171,7
> > +1171,11 @@ static int spi_imx_dma_configure(struct spi_master *master)
> > tx.direction = DMA_MEM_TO_DEV;
> > tx.dst_addr = spi_imx->base_phys + MXC_CSPITXDATA;
> > tx.dst_addr_width = buswidth;
> > - tx.dst_maxburst = spi_imx->wml;
> > + /*
> > + * For ERR009165 with tx_wml = 0 could enlarge burst size to fifo size
> > + * to speed up fifo filling as possible.
> > + */
> > + tx.dst_maxburst = spi_imx->devtype_data->fifo_size;
> > ret = dmaengine_slave_config(master->dma_tx, &tx);
> > if (ret) {
> > dev_err(spi_imx->dev, "TX dma configuration failed with %d\n",
> > ret); @@ -1265,10 +1269,6 @@ static int spi_imx_sdma_init(struct
> > device *dev, struct spi_imx_data *spi_imx, {
> > int ret;
> >
> > - /* use pio mode for i.mx6dl chip TKT238285 */
> > - if (of_machine_is_compatible("fsl,imx6dl"))
> > - return 0;
> > -
> > spi_imx->wml = spi_imx->devtype_data->fifo_size / 2;
> >
> > /* Prepare for TX DMA: */
> > --
> > 2.7.4
> >
> >
>
> --
> Pengutronix e.K. |
> |
> Steuerwalder Str. 21 |
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.pe
> ngutronix.de%2F&data=02%7C01%7Cyibin.gong%40nxp.com%7C2f49309
> 819cc4c45418108d7f70e46fb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> 7C1%7C637249513003506970&sdata=RoLVnDaCfG20i88OmmlpbMH6lZu
> qqW2CJv4VSSDkPcM%3D&reserved=0 |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
> |
> Amtsgericht Hildesheim, HRA 2686 | Fax:
> +49-5121-206917-5555 |
^ permalink raw reply
* RE: [PATCH v7 RESEND 00/13] add ecspi ERR009165 for i.mx6/7 soc family
From: Robin Gong @ 2020-05-13 8:20 UTC (permalink / raw)
To: Sascha Hauer
Cc: vkoul@kernel.org, shawnguo@kernel.org,
u.kleine-koenig@pengutronix.de, robh+dt@kernel.org,
festevam@gmail.com, dan.j.williams@intel.com,
mark.rutland@arm.com, catalin.marinas@arm.com,
will.deacon@arm.com, l.stach@pengutronix.de,
martin.fuzzey@flowbird.group, kernel@pengutronix.de,
linux-spi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dl-linux-imx,
dmaengine@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <20200513072012.GB15934@pengutronix.de>
On 2020/05/13 Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Tue, May 12, 2020 at 01:32:23AM +0800, Robin Gong wrote:
> > There is ecspi ERR009165 on i.mx6/7 soc family, which cause FIFO
> > transfer to be send twice in DMA mode. Please get more information from:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> >
> nxp.com%2Fdocs%2Fen%2Ferrata%2FIMX6DQCE.pdf&data=02%7C01%7C
> yibin.g
> >
> ong%40nxp.com%7C4276d42955334886056508d7f70e18af%7C686ea1d3bc2b4
> c6fa92
> >
> cd99c5c301635%7C0%7C1%7C637249512224944620&sdata=vh0e3BER01
> 02648t9HRe14h%2BaE9m%2BAlJ5Smd6v%2B9AhM%3D&reserved=0. The
> workaround is adding new sdma ram script which works in XCH mode as PIO
> inside sdma instead of SMC mode, meanwhile, 'TX_THRESHOLD' should be 0.
> The issue should be exist on all legacy i.mx6/7 soc family before i.mx6ul.
> > NXP fix this design issue from i.mx6ul, so newer chips including
> > i.mx6ul/ 6ull/6sll do not need this workaroud anymore. All other
> > i.mx6/7/8 chips still need this workaroud. This patch set add new
> 'fsl,imx6ul-ecspi'
> > for ecspi driver and 'ecspi_fixed' in sdma driver to choose if need
> > errata or not.
> > The first two reverted patches should be the same issue, though, it
> > seems 'fixed' by changing to other shp script. Hope Sean or Sascha
> > could have the chance to test this patch set if could fix their issues.
> > Besides, enable sdma support for i.mx8mm/8mq and fix ecspi1 not work
> > on i.mx8mm because the event id is zero.
>
> It's not nice to break SPI support when the new firmware is not present and I
> think we can do better. Wouldn't it be possible to fall back to PIO in this case?
I'm afraid that's not easy since spi driver don't know which firmware used. Could I add some comments in commit log?
^ permalink raw reply
* Re: [PATCH v2 90/91] dt-bindings: display: vc4: hdmi: Add BCM2711 HDMI controllers bindings
From: Maxime Ripard @ 2020-05-13 8:16 UTC (permalink / raw)
To: Rob Herring
Cc: Nicolas Saenz Julienne, Eric Anholt, dri-devel, linux-rpi-kernel,
bcm-kernel-feedback-list, linux-arm-kernel, linux-kernel,
Dave Stevenson, Tim Gover, Phil Elwell, devicetree
In-Reply-To: <20200511215014.GA4800@bogus>
[-- Attachment #1: Type: text/plain, Size: 3168 bytes --]
On Mon, May 11, 2020 at 04:50:14PM -0500, Rob Herring wrote:
> On Fri, Apr 24, 2020 at 05:35:11PM +0200, Maxime Ripard wrote:
> > The HDMI controllers found in the BCM2711 SoC need some adjustments to the
> > bindings, especially since the registers have been shuffled around in more
> > register ranges.
> >
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: devicetree@vger.kernel.org
> > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> > ---
> > Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml | 109 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
> > 1 file changed, 109 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> > new file mode 100644
> > index 000000000000..6091fe3d315b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> > @@ -0,0 +1,109 @@
> > +# SPDX-License-Identifier: GPL-2.0
>
> Dual license
>
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/brcm,bcm2711-hdmi.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Broadcom BCM2711 HDMI Controller Device Tree Bindings
> > +
> > +maintainers:
> > + - Eric Anholt <eric@anholt.net>
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - brcm,bcm2711-hdmi0
> > + - brcm,bcm2711-hdmi1
> > +
> > + reg:
> > + items:
> > + - description: HDMI controller register range
> > + - description: DVP register range
> > + - description: HDMI PHY register range
> > + - description: Rate Manager register range
> > + - description: Packet RAM register range
> > + - description: Metadata RAM register range
> > + - description: CSC register range
> > + - description: CEC register range
> > + - description: HD register range
> > +
> > + reg-names:
> > + items:
> > + - const: hdmi
> > + - const: dvp
> > + - const: phy
> > + - const: rm
> > + - const: packet
> > + - const: metadata
> > + - const: csc
> > + - const: cec
> > + - const: hd
> > +
> > + clocks:
> > + description: The HDMI state machine clock
> > +
> > + clock-names:
> > + const: hdmi
> > +
> > + ddc:
> > + allOf:
> > + - $ref: /schemas/types.yaml#/definitions/phandle
> > + description: >
> > + Phandle of the I2C controller used for DDC EDID probing
>
> This belongs in a connector node. (ddc-i2c-bus)
>
> > +
> > + hpd-gpios:
> > + description: >
> > + The GPIO pin for the HDMI hotplug detect (if it doesn't appear
> > + as an interrupt/status bit in the HDMI controller itself)
>
> This belongs in a connector node.
If we were to create a new binding, sure, but we're merely reusing the old
binding that is already there. The only reason it's in a separate file is
because you said it would be clearer in a separate file.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 03/91] dt-bindings: clock: Add a binding for the RPi Firmware clocks
From: Maxime Ripard @ 2020-05-13 8:13 UTC (permalink / raw)
To: Rob Herring
Cc: Nicolas Saenz Julienne, Eric Anholt, dri-devel, linux-rpi-kernel,
bcm-kernel-feedback-list, linux-arm-kernel, linux-kernel,
Dave Stevenson, Tim Gover, Phil Elwell, Michael Turquette,
Stephen Boyd, linux-clk, devicetree
In-Reply-To: <20200511214727.GA20924@bogus>
[-- Attachment #1: Type: text/plain, Size: 2140 bytes --]
Hi Rob,
On Mon, May 11, 2020 at 04:47:27PM -0500, Rob Herring wrote:
> On Fri, Apr 24, 2020 at 05:33:44PM +0200, Maxime Ripard wrote:
> > The firmware running on the RPi VideoCore can be used to discover and
> > change the various clocks running in the BCM2711. Since devices will
> > need to use them through the DT, let's add a pretty simple binding.
> >
> > Cc: Michael Turquette <mturquette@baylibre.com>
> > Cc: Stephen Boyd <sboyd@kernel.org>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: linux-clk@vger.kernel.org
> > Cc: devicetree@vger.kernel.org
> > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> > ---
> > Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 24 ++++++++++++++++++++++++
> > 1 file changed, 24 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> > index cec540c052b6..b48ed875eb8e 100644
> > --- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> > +++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> > @@ -22,6 +22,25 @@ properties:
> > Phandle to the firmware device's Mailbox.
> > (See: ../mailbox/mailbox.txt for more information)
> >
> > + clocks:
> > + type: object
> > +
> > + properties:
> > + compatible:
> > + const: raspberrypi,firmware-clocks
> > +
> > + "#clock-cells":
> > + const: 1
> > + description: >
> > + The argument is the ID of the clocks contained by the
> > + firmware messages.
>
> Not really any reason to make this a child node. The parent can be a
> clock provider.
This was meant to provide some consistency for that driver. It already has a nod
for the GPIOs exposed through the firmware in the RPi where you could make the
exact same argument, so I guess that, while we shouldn't make the same choices
if we had to design it from scratch, it's more important to keep the same design
choices for a given binding?
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: gw552x: add USB OTG support
From: Shawn Guo @ 2020-05-13 8:10 UTC (permalink / raw)
To: Tim Harvey; +Cc: Sascha Hauer, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <1588173755-18045-1-git-send-email-tharvey@gateworks.com>
On Wed, Apr 29, 2020 at 08:22:35AM -0700, Tim Harvey wrote:
> The GW552x-B board revision adds USB OTG support.
>
> Enable the device-tree node and configure the OTG_ID pin.
>
> Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Changed prefix to 'ARM: dts: imx6qdl-gw552x: ' and applied patch.
Shawn
> ---
> arch/arm/boot/dts/imx6qdl-gw552x.dtsi | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-gw552x.dtsi b/arch/arm/boot/dts/imx6qdl-gw552x.dtsi
> index dc646b7..bb35971 100644
> --- a/arch/arm/boot/dts/imx6qdl-gw552x.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-gw552x.dtsi
> @@ -258,6 +258,14 @@
> status = "okay";
> };
>
> +&usbotg {
> + vbus-supply = <®_5p0v>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usbotg>;
> + disable-over-current;
> + status = "okay";
> +};
> +
> &wdog1 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_wdog>;
> @@ -359,6 +367,12 @@
> >;
> };
>
> + pinctrl_usbotg: usbotggrp {
> + fsl,pins = <
> + MX6QDL_PAD_ENET_RX_ER__USB_OTG_ID 0x13059
> + >;
> + };
> +
> pinctrl_wdog: wdoggrp {
> fsl,pins = <
> MX6QDL_PAD_DISP0_DAT8__WDOG1_B 0x1b0b0
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH 01/11] dt-bindings: add a binding document for MediaTek PERICFG controller
From: Bartosz Golaszewski @ 2020-05-13 8:09 UTC (permalink / raw)
To: Rob Herring
Cc: David S . Miller, Matthias Brugger, Felix Fietkau, John Crispin,
Sean Wang, Mark Lee, Jakub Kicinski, Arnd Bergmann, Fabien Parent,
devicetree, Linux Kernel Mailing List, netdev, Linux ARM,
linux-mediatek, Bartosz Golaszewski
In-Reply-To: <20200513023855.GA23714@bogus>
śr., 13 maj 2020 o 04:38 Rob Herring <robh@kernel.org> napisał(a):
>
> On Tue, May 05, 2020 at 04:02:21PM +0200, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> >
> > This adds a binding document for the PERICFG controller present on
> > MediaTek SoCs. For now the only variant supported is 'mt8516-pericfg'.
> >
> > Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> > ---
> > .../arm/mediatek/mediatek,pericfg.yaml | 34 +++++++++++++++++++
> > 1 file changed, 34 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml
> > new file mode 100644
> > index 000000000000..74b2a6173ffb
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml
> > @@ -0,0 +1,34 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,pericfg.yaml#"
> > +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> > +
> > +title: MediaTek Peripheral Configuration Controller
> > +
> > +maintainers:
> > + - Bartosz Golaszewski <bgolaszewski@baylibre.com>
> > +
> > +properties:
> > + compatible:
> > + oneOf:
>
> Don't need oneOf.
>
> > + - items:
> > + - enum:
> > + - mediatek,pericfg
>
> PERICFG is exactly the same register set and functions on all Mediatek
> SoCs? Needs to be more specific.
>
> > + - const: syscon
> > +
> > + reg:
> > + maxItems: 1
> > +
> > +required:
> > + - compatible
> > + - reg
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + pericfg: pericfg@10003050 {
> > + compatible = "mediatek,mt8516-pericfg", "syscon";
> > + reg = <0 0x10003050 0 0x1000>;
>
> Default for examples is 1 cell for addr and size.
>
> > + };
> > --
> > 2.25.0
> >
Hi Rob,
I somehow missed the fact that there already is an old-style txt
binding document for pericfg. I'll first convert it and then add the
new compatible.
Bart
^ permalink raw reply
* RE: [PATCH v7 RESEND 03/13] Revert "dmaengine: imx-sdma: fix context cache"
From: Robin Gong @ 2020-05-13 8:06 UTC (permalink / raw)
To: Fuzzey, Martin, Sascha Hauer
Cc: vkoul@kernel.org, Shawn Guo, Uwe Kleine-König, Rob Herring,
Fabio Estevam, dan.j.williams@intel.com, mark.rutland@arm.com,
catalin.marinas@arm.com, Will Deacon, Lucas Stach, Sascha Hauer,
linux-spi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Linux-Kernel@Vger. Kernel. Org, dl-linux-imx,
dmaengine@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <CANh8QzxJg05nXasHfN2kC-G7TOKZ8trJkOP_v0KXvcy6S4df4Q@mail.gmail.com>
On 2020/05/13 Fuzzey, Martin <martin.fuzzey@flowbird.group> wrote:
> On Wed, 13 May 2020 at 08:07, Sascha Hauer <s.hauer@pengutronix.de>
> wrote:
> >
> > On Tue, May 12, 2020 at 01:32:26AM +0800, Robin Gong wrote:
> > > This reverts commit d288bddd8374e0a043ac9dde64a1ae6a09411d74, since
> > > 'context_loaded' finally removed.
> > >
> > > Signed-off-by: Robin Gong <yibin.gong@nxp.com>
> > > ---
> >
> > I think this can safely be folded into the next patch which makes it
> > more clear what is happening.
> >
>
> Agreed,
> not only that but having 2 separate patches also means that the bug that was
> fixed by the commit being reverted could reappear during bisection.
>
> More generally I think reverts should be reserved for commits that later turn
> out to be wrong or unneeded (ie should never really have been applied).
> If they were OK at the time but later become unnecessary due to other code
> changes I think all the related modifications should be done in a single normal
> non revert patch.
Okay, will remove it in v8.
^ permalink raw reply
* RE: [PATCH v7 RESEND 05/13] dmaengine: imx-sdma: remove dupilicated sdma_load_context
From: Robin Gong @ 2020-05-13 8:04 UTC (permalink / raw)
To: Sascha Hauer
Cc: vkoul@kernel.org, shawnguo@kernel.org,
u.kleine-koenig@pengutronix.de, robh+dt@kernel.org,
festevam@gmail.com, dan.j.williams@intel.com,
mark.rutland@arm.com, catalin.marinas@arm.com,
will.deacon@arm.com, l.stach@pengutronix.de,
martin.fuzzey@flowbird.group, kernel@pengutronix.de,
linux-spi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dl-linux-imx,
dmaengine@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <20200513060553.GK5877@pengutronix.de>
On 2020/05/13 14:06 Sascha Hauer <s.hauer@pengutronix.de> wrote:
> Subject: Re: [PATCH v7 RESEND 05/13] dmaengine: imx-sdma: remove
> dupilicated sdma_load_context
>
> In the subject: s/dupilicated/duplicated/
Will fix typo in v8.
^ permalink raw reply
* Re: [PATCH 4/5] dt-bindings: ufs: ti: Add missing 'additionalProperties: false'
From: Vignesh Raghavendra @ 2020-05-13 7:49 UTC (permalink / raw)
To: Rob Herring, devicetree
Cc: linux-clk, linux-usb, linux-spi, linux-kernel, Greg Kroah-Hartman,
Mark Brown
In-Reply-To: <20200512204543.22090-4-robh@kernel.org>
On 13/05/20 2:15 am, Rob Herring wrote:
> The ti,j721e-ufs schema is missing an 'additionalProperties: false'. Add
> that and and the missing assigned-clock properties.
>
> Cc: Vignesh Raghavendra <vigneshr@ti.com>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
Acked-by: Vignesh Raghavendra <vigneshr@ti.com>
Regards
Vignesh
> Documentation/devicetree/bindings/ufs/ti,j721e-ufs.yaml | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/ufs/ti,j721e-ufs.yaml b/Documentation/devicetree/bindings/ufs/ti,j721e-ufs.yaml
> index b503b1a918a5..4d13e6bc1c50 100644
> --- a/Documentation/devicetree/bindings/ufs/ti,j721e-ufs.yaml
> +++ b/Documentation/devicetree/bindings/ufs/ti,j721e-ufs.yaml
> @@ -25,6 +25,12 @@ properties:
> power-domains:
> maxItems: 1
>
> + assigned-clocks:
> + maxItems: 1
> +
> + assigned-clock-parents:
> + maxItems: 1
> +
> "#address-cells":
> const: 2
>
> @@ -47,6 +53,8 @@ patternProperties:
> Documentation/devicetree/bindings/ufs/cdns,ufshc.txt for binding
> documentation of child node
>
> +additionalProperties: false
> +
> examples:
> - |
> #include <dt-bindings/interrupt-controller/irq.h>
>
^ permalink raw reply
* Re: [PATCH 3/5] dt-bindings: ufs: ti: Fix address properties handling
From: Vignesh Raghavendra @ 2020-05-13 7:49 UTC (permalink / raw)
To: Rob Herring, devicetree
Cc: linux-clk, linux-usb, linux-spi, linux-kernel, Greg Kroah-Hartman,
Mark Brown
In-Reply-To: <20200512204543.22090-3-robh@kernel.org>
On 13/05/20 2:15 am, Rob Herring wrote:
> The ti,j721e-ufs schema and example have a couple of problems related to
> address properties. First, the default #size-cells and #address-cells
> are 1 for examples, so they need to be overriden with a bus node.
> Second, address translation for the child ufs node is broken because
> 'ranges', '#address-cells', and '#size-cells' are missing from the
> schema.
>
> Cc: Vignesh Raghavendra <vigneshr@ti.com>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
Acked-by: Vignesh Raghavendra <vigneshr@ti.com>
Regards
Vignesh
> Please ack, dependency for patch 5.
>
> .../devicetree/bindings/ufs/ti,j721e-ufs.yaml | 57 ++++++++++++-------
> 1 file changed, 36 insertions(+), 21 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/ufs/ti,j721e-ufs.yaml b/Documentation/devicetree/bindings/ufs/ti,j721e-ufs.yaml
> index c8a2a92074df..b503b1a918a5 100644
> --- a/Documentation/devicetree/bindings/ufs/ti,j721e-ufs.yaml
> +++ b/Documentation/devicetree/bindings/ufs/ti,j721e-ufs.yaml
> @@ -25,6 +25,14 @@ properties:
> power-domains:
> maxItems: 1
>
> + "#address-cells":
> + const: 2
> +
> + "#size-cells":
> + const: 2
> +
> + ranges: true
> +
> required:
> - compatible
> - reg
> @@ -44,25 +52,32 @@ examples:
> #include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
>
> - ufs_wrapper: ufs-wrapper@4e80000 {
> - compatible = "ti,j721e-ufs";
> - reg = <0x0 0x4e80000 0x0 0x100>;
> - power-domains = <&k3_pds 277>;
> - clocks = <&k3_clks 277 1>;
> - assigned-clocks = <&k3_clks 277 1>;
> - assigned-clock-parents = <&k3_clks 277 4>;
> - #address-cells = <2>;
> - #size-cells = <2>;
> -
> - ufs@4e84000 {
> - compatible = "cdns,ufshc-m31-16nm", "jedec,ufs-2.0";
> - reg = <0x0 0x4e84000 0x0 0x10000>;
> - interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
> - freq-table-hz = <19200000 19200000>;
> - power-domains = <&k3_pds 277>;
> - clocks = <&k3_clks 277 1>;
> - assigned-clocks = <&k3_clks 277 1>;
> - assigned-clock-parents = <&k3_clks 277 4>;
> - clock-names = "core_clk";
> - };
> + bus {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + ufs-wrapper@4e80000 {
> + compatible = "ti,j721e-ufs";
> + reg = <0x0 0x4e80000 0x0 0x100>;
> + power-domains = <&k3_pds 277>;
> + clocks = <&k3_clks 277 1>;
> + assigned-clocks = <&k3_clks 277 1>;
> + assigned-clock-parents = <&k3_clks 277 4>;
> +
> + ranges = <0x0 0x0 0x0 0x4e80000 0x0 0x14000>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + ufs@4000 {
> + compatible = "cdns,ufshc-m31-16nm", "jedec,ufs-2.0";
> + reg = <0x0 0x4000 0x0 0x10000>;
> + interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
> + freq-table-hz = <19200000 19200000>;
> + power-domains = <&k3_pds 277>;
> + clocks = <&k3_clks 277 1>;
> + assigned-clocks = <&k3_clks 277 1>;
> + assigned-clock-parents = <&k3_clks 277 4>;
> + clock-names = "core_clk";
> + };
> + };
> };
>
^ permalink raw reply
* Re: [PATCH v3 0/6] allow ramoops to collect all kmesg_dump events
From: Kees Cook @ 2020-05-13 7:47 UTC (permalink / raw)
To: Petr Mladek
Cc: Pavel Tatashin, Anton Vorontsov, Colin Cross, Tony Luck,
Jonathan Corbet, Rob Herring, Benson Leung,
Enric Balletbo i Serra, Sergey Senozhatsky, Steven Rostedt,
James Morris, Sasha Levin, Linux Doc Mailing List, LKML,
devicetree
In-Reply-To: <20200513073448.GG7340@linux-b0ei>
On Wed, May 13, 2020 at 09:34:49AM +0200, Petr Mladek wrote:
> On Tue 2020-05-12 11:45:54, Kees Cook wrote:
> > Here are the problems I see being solved by this:
> >
> > - lifting kmsg dump reason filtering out of the individual pstore
> > backends and making it part of the "infrastructure", so that
> > there is a central place to set expectations. Right now there
> > is a mix of explicit and implicit kmsg dump handling:
> >
> > - arch/powerpc/kernel/nvram_64.c has a hard-coded list
>
> It handles restart, halt, poweroff the same way. I wonder if anyone
> would want to distinguish them.
>
> > - drivers/firmware/efi/efi-pstore.c doesn't expect anything but
> > OOPS and PANIC.
> > - drivers/mtd/mtdoops.c tries to filter using its own dump_oops
> > and doesn't expect anything but OOPS and PANIC.
> > - fs/pstore/ram.c: has a hard-coded list and uses its own
> > dump_oops.
> > - drivers/mtd/mtdpstore.c (under development[3]) expected only
> > OOPS and PANIC and had its own dump_oops.
>
> The others handle only panic or oops.
>
> What about splitting the reason into two variables? One for severity
> and other for shutdown behavior. I mean:
>
> + reason: panic, oops, emergency, shutdown (ordered by severity)
> + handling: restart, halt, poweroff
>
> Or we might just replace KMSG_DUMP_RESTART, KMSG_DUMP_HALT,
> KMSG_DUMP_POWEROFF with a single KMSG_DUMP_SHUTDOWN.
>
> Then the max reason variable would make sense.
That would work for me, yeah. Pavel, is that enough granularity for you?
--
Kees Cook
^ permalink raw reply
* [V3 PATCH 1/2] dt-bindings: Added device tree binding for max98390
From: Steve Lee @ 2020-05-13 7:44 UTC (permalink / raw)
To: lgirdwood, broonie, robh+dt, alsa-devel, devicetree, linux-kernel
Cc: ryan.lee.maxim, ryans.lee, steves.lee, steves.lee.maxim
Add documentation for DT binding of max98390 amplifier driver.
Signed-off-by: Steve Lee <steves.lee@maximintegrated.com>
---
Changed since V2:
* No changes.
Changed since V1:
* Modified sample text in example
.../devicetree/bindings/sound/max98390.txt | 26 +++++++++++++++++++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/max98390.txt
diff --git a/Documentation/devicetree/bindings/sound/max98390.txt b/Documentation/devicetree/bindings/sound/max98390.txt
new file mode 100644
index 000000000000..0ddd4c6ae55e
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/max98390.txt
@@ -0,0 +1,26 @@
+Maxim Integrated MAX98390 Speaker Amplifier
+
+This device supports I2C.
+
+Required properties:
+
+ - compatible : "maxim,max98390"
+
+ - reg : the I2C address of the device.
+
+Optional properties:
+
+- maxim,temperature_calib
+ u32. The calculated temperature data was measured while doing the calibration. Data : Temp / 100 * 2^12
+
+- maxim,r0_calib
+ u32. This is r0 calibration data which was measured in factory mode.
+
+Example:
+
+codec: max98390@38 {
+ compatible = "maxim,max98390";
+ reg = <0x38>;
+ maxim,temperature_calib = <1024>;
+ maxim,r0_calib = <100232>;
+};
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v3 0/6] allow ramoops to collect all kmesg_dump events
From: Petr Mladek @ 2020-05-13 7:34 UTC (permalink / raw)
To: Kees Cook
Cc: Pavel Tatashin, Anton Vorontsov, Colin Cross, Tony Luck,
Jonathan Corbet, Rob Herring, Benson Leung,
Enric Balletbo i Serra, Sergey Senozhatsky, Steven Rostedt,
James Morris, Sasha Levin, Linux Doc Mailing List, LKML,
devicetree
In-Reply-To: <202005121111.6BECC45@keescook>
On Tue 2020-05-12 11:45:54, Kees Cook wrote:
> Here are the problems I see being solved by this:
>
> - lifting kmsg dump reason filtering out of the individual pstore
> backends and making it part of the "infrastructure", so that
> there is a central place to set expectations. Right now there
> is a mix of explicit and implicit kmsg dump handling:
>
> - arch/powerpc/kernel/nvram_64.c has a hard-coded list
It handles restart, halt, poweroff the same way. I wonder if anyone
would want to distinguish them.
> - drivers/firmware/efi/efi-pstore.c doesn't expect anything but
> OOPS and PANIC.
> - drivers/mtd/mtdoops.c tries to filter using its own dump_oops
> and doesn't expect anything but OOPS and PANIC.
> - fs/pstore/ram.c: has a hard-coded list and uses its own
> dump_oops.
> - drivers/mtd/mtdpstore.c (under development[3]) expected only
> OOPS and PANIC and had its own dump_oops.
The others handle only panic or oops.
What about splitting the reason into two variables? One for severity
and other for shutdown behavior. I mean:
+ reason: panic, oops, emergency, shutdown (ordered by severity)
+ handling: restart, halt, poweroff
Or we might just replace KMSG_DUMP_RESTART, KMSG_DUMP_HALT,
KMSG_DUMP_POWEROFF with a single KMSG_DUMP_SHUTDOWN.
Then the max reason variable would make sense.
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH v7 RESEND 07/13] spi: imx: fix ERR009165
From: Sascha Hauer @ 2020-05-13 7:33 UTC (permalink / raw)
To: Robin Gong
Cc: vkoul, shawnguo, u.kleine-koenig, robh+dt, festevam,
dan.j.williams, mark.rutland, catalin.marinas, will.deacon,
l.stach, martin.fuzzey, kernel, linux-spi, linux-arm-kernel,
linux-kernel, linux-imx, dmaengine, devicetree
In-Reply-To: <1589218356-17475-8-git-send-email-yibin.gong@nxp.com>
On Tue, May 12, 2020 at 01:32:30AM +0800, Robin Gong wrote:
> Change to XCH mode even in dma mode, please refer to the below
> errata:
> https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf
>
> Signed-off-by: Robin Gong <yibin.gong@nxp.com>
> Acked-by: Mark Brown <broonie@kernel.org>
> ---
> drivers/spi/spi-imx.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
> index f4f28a4..70df8e6 100644
> --- a/drivers/spi/spi-imx.c
> +++ b/drivers/spi/spi-imx.c
> @@ -585,8 +585,8 @@ static int mx51_ecspi_prepare_transfer(struct spi_imx_data *spi_imx,
> ctrl |= mx51_ecspi_clkdiv(spi_imx, t->speed_hz, &clk);
> spi_imx->spi_bus_clk = clk;
>
> - if (spi_imx->usedma)
> - ctrl |= MX51_ECSPI_CTRL_SMC;
> + /* ERR009165: work in XHC mode as PIO */
> + ctrl &= ~MX51_ECSPI_CTRL_SMC;
>
> writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);
>
> @@ -617,7 +617,7 @@ static void mx51_setup_wml(struct spi_imx_data *spi_imx)
> * and enable DMA request.
> */
> writel(MX51_ECSPI_DMA_RX_WML(spi_imx->wml - 1) |
> - MX51_ECSPI_DMA_TX_WML(spi_imx->wml) |
> + MX51_ECSPI_DMA_TX_WML(0) |
> MX51_ECSPI_DMA_RXT_WML(spi_imx->wml) |
> MX51_ECSPI_DMA_TEDEN | MX51_ECSPI_DMA_RXDEN |
> MX51_ECSPI_DMA_RXTDEN, spi_imx->base + MX51_ECSPI_DMA);
> @@ -1171,7 +1171,11 @@ static int spi_imx_dma_configure(struct spi_master *master)
> tx.direction = DMA_MEM_TO_DEV;
> tx.dst_addr = spi_imx->base_phys + MXC_CSPITXDATA;
> tx.dst_addr_width = buswidth;
> - tx.dst_maxburst = spi_imx->wml;
> + /*
> + * For ERR009165 with tx_wml = 0 could enlarge burst size to fifo size
> + * to speed up fifo filling as possible.
> + */
> + tx.dst_maxburst = spi_imx->devtype_data->fifo_size;
In the next patch this is changed again to:
+ if (spi_imx->devtype_data->tx_glitch_fixed)
+ tx.dst_maxburst = spi_imx->wml;
+ else
+ tx.dst_maxburst = spi_imx->devtype_data->fifo_size;
So with tx_glitch_fixed we end up with tx.dst_maxburst being the same
as two patches before which is rather confusing. Better introduce
tx_glitch_fixed in this patch, or maybe even merge this patch and the
next one.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH v7 RESEND 07/13] spi: imx: fix ERR009165
From: Sascha Hauer @ 2020-05-13 7:21 UTC (permalink / raw)
To: Robin Gong
Cc: vkoul, shawnguo, u.kleine-koenig, robh+dt, festevam,
dan.j.williams, mark.rutland, catalin.marinas, will.deacon,
l.stach, martin.fuzzey, kernel, linux-spi, linux-arm-kernel,
linux-kernel, linux-imx, dmaengine, devicetree
In-Reply-To: <1589218356-17475-8-git-send-email-yibin.gong@nxp.com>
On Tue, May 12, 2020 at 01:32:30AM +0800, Robin Gong wrote:
> Change to XCH mode even in dma mode, please refer to the below
> errata:
> https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf
This patch is the one bisecting will end up with when somebody uses an
older SDMA firmware or the ROM scripts. It should have a better
description what happens and what should be done about it.
Sascha
>
> Signed-off-by: Robin Gong <yibin.gong@nxp.com>
> Acked-by: Mark Brown <broonie@kernel.org>
> ---
> drivers/spi/spi-imx.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
> index f4f28a4..70df8e6 100644
> --- a/drivers/spi/spi-imx.c
> +++ b/drivers/spi/spi-imx.c
> @@ -585,8 +585,8 @@ static int mx51_ecspi_prepare_transfer(struct spi_imx_data *spi_imx,
> ctrl |= mx51_ecspi_clkdiv(spi_imx, t->speed_hz, &clk);
> spi_imx->spi_bus_clk = clk;
>
> - if (spi_imx->usedma)
> - ctrl |= MX51_ECSPI_CTRL_SMC;
> + /* ERR009165: work in XHC mode as PIO */
> + ctrl &= ~MX51_ECSPI_CTRL_SMC;
>
> writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);
>
> @@ -617,7 +617,7 @@ static void mx51_setup_wml(struct spi_imx_data *spi_imx)
> * and enable DMA request.
> */
> writel(MX51_ECSPI_DMA_RX_WML(spi_imx->wml - 1) |
> - MX51_ECSPI_DMA_TX_WML(spi_imx->wml) |
> + MX51_ECSPI_DMA_TX_WML(0) |
> MX51_ECSPI_DMA_RXT_WML(spi_imx->wml) |
> MX51_ECSPI_DMA_TEDEN | MX51_ECSPI_DMA_RXDEN |
> MX51_ECSPI_DMA_RXTDEN, spi_imx->base + MX51_ECSPI_DMA);
> @@ -1171,7 +1171,11 @@ static int spi_imx_dma_configure(struct spi_master *master)
> tx.direction = DMA_MEM_TO_DEV;
> tx.dst_addr = spi_imx->base_phys + MXC_CSPITXDATA;
> tx.dst_addr_width = buswidth;
> - tx.dst_maxburst = spi_imx->wml;
> + /*
> + * For ERR009165 with tx_wml = 0 could enlarge burst size to fifo size
> + * to speed up fifo filling as possible.
> + */
> + tx.dst_maxburst = spi_imx->devtype_data->fifo_size;
> ret = dmaengine_slave_config(master->dma_tx, &tx);
> if (ret) {
> dev_err(spi_imx->dev, "TX dma configuration failed with %d\n", ret);
> @@ -1265,10 +1269,6 @@ static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx,
> {
> int ret;
>
> - /* use pio mode for i.mx6dl chip TKT238285 */
> - if (of_machine_is_compatible("fsl,imx6dl"))
> - return 0;
> -
> spi_imx->wml = spi_imx->devtype_data->fifo_size / 2;
>
> /* Prepare for TX DMA: */
> --
> 2.7.4
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH v7 RESEND 00/13] add ecspi ERR009165 for i.mx6/7 soc family
From: Sascha Hauer @ 2020-05-13 7:20 UTC (permalink / raw)
To: Robin Gong
Cc: vkoul, shawnguo, u.kleine-koenig, robh+dt, festevam,
dan.j.williams, mark.rutland, catalin.marinas, will.deacon,
l.stach, martin.fuzzey, kernel, linux-spi, linux-arm-kernel,
linux-kernel, linux-imx, dmaengine, devicetree
In-Reply-To: <1589218356-17475-1-git-send-email-yibin.gong@nxp.com>
On Tue, May 12, 2020 at 01:32:23AM +0800, Robin Gong wrote:
> There is ecspi ERR009165 on i.mx6/7 soc family, which cause FIFO
> transfer to be send twice in DMA mode. Please get more information from:
> https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf. The workaround is adding
> new sdma ram script which works in XCH mode as PIO inside sdma instead
> of SMC mode, meanwhile, 'TX_THRESHOLD' should be 0. The issue should be
> exist on all legacy i.mx6/7 soc family before i.mx6ul.
> NXP fix this design issue from i.mx6ul, so newer chips including i.mx6ul/
> 6ull/6sll do not need this workaroud anymore. All other i.mx6/7/8 chips
> still need this workaroud. This patch set add new 'fsl,imx6ul-ecspi'
> for ecspi driver and 'ecspi_fixed' in sdma driver to choose if need errata
> or not.
> The first two reverted patches should be the same issue, though, it
> seems 'fixed' by changing to other shp script. Hope Sean or Sascha could
> have the chance to test this patch set if could fix their issues.
> Besides, enable sdma support for i.mx8mm/8mq and fix ecspi1 not work
> on i.mx8mm because the event id is zero.
It's not nice to break SPI support when the new firmware is not present
and I think we can do better. Wouldn't it be possible to fall back to PIO
in this case?
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH v7 RESEND 03/13] Revert "dmaengine: imx-sdma: fix context cache"
From: Fuzzey, Martin @ 2020-05-13 7:12 UTC (permalink / raw)
To: Sascha Hauer
Cc: Robin Gong, vkoul, Shawn Guo, Uwe Kleine-König, Rob Herring,
Fabio Estevam, dan.j.williams, mark.rutland, catalin.marinas,
Will Deacon, Lucas Stach, Sascha Hauer, linux-spi,
linux-arm-kernel, Linux-Kernel@Vger. Kernel. Org, dl-linux-imx,
dmaengine, devicetree
In-Reply-To: <20200513060525.GJ5877@pengutronix.de>
On Wed, 13 May 2020 at 08:07, Sascha Hauer <s.hauer@pengutronix.de> wrote:
>
> On Tue, May 12, 2020 at 01:32:26AM +0800, Robin Gong wrote:
> > This reverts commit d288bddd8374e0a043ac9dde64a1ae6a09411d74, since
> > 'context_loaded' finally removed.
> >
> > Signed-off-by: Robin Gong <yibin.gong@nxp.com>
> > ---
>
> I think this can safely be folded into the next patch which makes it
> more clear what is happening.
>
Agreed,
not only that but having 2 separate patches also means that the bug
that was fixed by the commit being reverted could reappear during
bisection.
More generally I think reverts should be reserved for commits that
later turn out to be wrong or unneeded (ie should never really have
been applied).
If they were OK at the time but later become unnecessary due to other
code changes I think all the related modifications should be done in a
single normal non revert patch.
Martin
^ permalink raw reply
* Re: [PATCH 5/5] dt-bindings: Fix incorrect 'reg' property sizes
From: Geert Uytterhoeven @ 2020-05-13 7:04 UTC (permalink / raw)
To: Rob Herring
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-clk, USB list, linux-spi, Linux Kernel Mailing List,
Greg Kroah-Hartman, Mark Brown
In-Reply-To: <20200512204543.22090-5-robh@kernel.org>
Hi Rob,
On Tue, May 12, 2020 at 10:46 PM Rob Herring <robh@kernel.org> wrote:
> The examples template is a 'simple-bus' with a size of 1 cell for
> #address-cells and #size-cells. The schema was only checking the entries
> had between 2 and 4 cells which really only errors on I2C or SPI type
> devices with a single cell.
>
> The easiest fix in most cases is to change the 'reg' property to for 1 cell
> address and size. In some cases with child devices having 2 cells, that
> doesn't make sense so a bus node is needed.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
Thanks for your patch!
> .../devicetree/bindings/arm/renesas,prr.yaml | 2 +-
> .../bindings/display/renesas,cmm.yaml | 2 +-
> .../interrupt-controller/renesas,irqc.yaml | 2 +-
> .../bindings/media/renesas,csi2.yaml | 2 +-
> .../bindings/media/renesas,vin.yaml | 6 +-
> .../bindings/net/renesas,ether.yaml | 2 +-
> .../bindings/pwm/renesas,pwm-rcar.yaml | 2 +-
> .../bindings/spi/renesas,sh-msiof.yaml | 2 +-
> .../bindings/thermal/rcar-thermal.yaml | 6 +-
> .../bindings/usb/renesas,usb3-peri.yaml | 2 +-
> .../bindings/usb/renesas,usbhs.yaml | 2 +-
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
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 v8 04/10] OPP: Add support for parsing interconnect bandwidth
From: Viresh Kumar @ 2020-05-13 7:01 UTC (permalink / raw)
To: Georgi Djakov
Cc: vireshk, nm, sboyd, rjw, saravanak, sibis, mka, robh+dt, rnayak,
bjorn.andersson, vincent.guittot, jcrouse, evgreen, linux-pm,
devicetree, linux-kernel
In-Reply-To: <20200513064139.5kxjjddcooqcvny3@vireshk-i7>
On 13-05-20, 12:11, Viresh Kumar wrote:
> On 12-05-20, 15:53, Georgi Djakov wrote:
> > The OPP bindings now support bandwidth values, so add support to parse it
> > from device tree and store it into the new dev_pm_opp_icc_bw struct, which
> > is part of the dev_pm_opp.
> >
> > Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> > ---
> > v8:
> > * Drop bandwidth requests and free memory in _opp_table_kref_release.
> > * Take into account the supply_count in struct size calculations.
> > * Free the temporary arrays for peak and average bandwidth.
> > * Fix the check for opp-level.
> > * Use dev_warn insted of dev_dbg.
> > * Rename _of_find_icc_paths to _of_find_icc_paths.
> > * Rename the variable count to supply_count.
>
> Added this delta to this patch:
+this :)
diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index 15f30ed70bbc..06e38f95116c 100644
--- a/drivers/opp/of.c
+++ b/drivers/opp/of.c
@@ -336,7 +336,7 @@ int dev_pm_opp_of_find_icc_paths(struct device *dev,
struct opp_table *opp_table)
{
struct device_node *np;
- int ret, i, count, num_paths;
+ int ret = 0, i, count, num_paths;
struct icc_path **paths;
np = of_node_get(dev->of_node);
@@ -375,10 +375,9 @@ int dev_pm_opp_of_find_icc_paths(struct device *dev,
if (opp_table) {
opp_table->paths = paths;
opp_table->path_count = num_paths;
+ return 0;
}
- return 0;
-
err:
while (i--)
icc_put(paths[i]);
--
viresh
^ permalink raw reply related
* Re: [PATCH v8 00/10] Introduce OPP bandwidth bindings
From: Viresh Kumar @ 2020-05-13 6:55 UTC (permalink / raw)
To: Georgi Djakov
Cc: vireshk, nm, sboyd, rjw, saravanak, sibis, mka, robh+dt, rnayak,
bjorn.andersson, vincent.guittot, jcrouse, evgreen, linux-pm,
devicetree, linux-kernel
In-Reply-To: <20200512125327.1868-1-georgi.djakov@linaro.org>
On 12-05-20, 15:53, Georgi Djakov wrote:
> Here is a proposal to extend the OPP bindings with bandwidth based on
> a few previous discussions [1] and patchsets from me [2][3] and Saravana
> [4][5][6][7][8][9].
>
> Changes in v8:
> * Addressed review comments from Matthias, Sibi and Viresh.
> * Picked reviewed-by tags.
> * Picked Sibi's interconnect-tag patches into this patchset.
I have applied the series with the modifications I replied with
separately.
Please lemme know if any more tags (reviewed/acked) etc need to be
applied or any more changes are required before I send the pull
request to Rafael.
Please give my branch a try as soon as you can.
Thanks.
--
viresh
^ permalink raw reply
* RE: [PATCH V2] dt-bindings: thermal: Convert i.MX to json-schema
From: Anson Huang @ 2020-05-13 6:55 UTC (permalink / raw)
To: Rob Herring
Cc: rui.zhang@intel.com, daniel.lezcano@linaro.org,
amit.kucheria@verdurent.com, shawnguo@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dl-linux-imx
In-Reply-To: <DB3PR0402MB3916B60832507A72F39750EAF5D50@DB3PR0402MB3916.eurprd04.prod.outlook.com>
Hi, Rob
> Subject: RE: [PATCH V2] dt-bindings: thermal: Convert i.MX to json-schema
>
> Hi, Rob
>
>
> > Subject: Re: [PATCH V2] dt-bindings: thermal: Convert i.MX to
> > json-schema
> >
> > On Fri, Apr 10, 2020 at 09:07:24AM +0800, Anson Huang wrote:
> > > Convert the i.MX thermal binding to DT schema format using
> > > json-schema
> > >
> > > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > > ---
> > > Changes since V1:
> > > - make clock property optional.
> > > ---
> > > .../devicetree/bindings/thermal/imx-thermal.txt | 61 --------------
> > > .../devicetree/bindings/thermal/imx-thermal.yaml | 96
> > ++++++++++++++++++++++
> > > 2 files changed, 96 insertions(+), 61 deletions(-) delete mode
> > > 100644 Documentation/devicetree/bindings/thermal/imx-thermal.txt
> > > create mode 100644
> > > Documentation/devicetree/bindings/thermal/imx-thermal.yaml
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/thermal/imx-thermal.txt
> > > b/Documentation/devicetree/bindings/thermal/imx-thermal.txt
> > > deleted file mode 100644
> > > index 823e417..0000000
> > > +
> > > +title: NXP i.MX Thermal Binding
> > > +
> > > +maintainers:
> > > + - Anson Huang <Anson.Huang@nxp.com>
> > > +
> > > +properties:
> > > + compatible:
> > > + oneOf:
> > > + - items:
> > > + - enum:
> > > + - fsl,imx6q-tempmon
> > > + - fsl,imx6sx-tempmon
> > > + - fsl,imx7d-tempmon
> > > +
> > > + interrupts:
> > > + description: |
> > > + The interrupt output of the controller, the IRQ will be triggered
> > > + when temperature is higher than high threshold.
> > > + maxItems: 1
> > > +
> > > + nvmem-cells:
> > > + description: |
> > > + Phandle to the calibration cells provided by ocotp for calibration
> > > + data and temperature grade.
> > > + maxItems: 2
> > > +
> > > + nvmem-cell-names:
> > > + maxItems: 2
> > > + items:
> > > + - const: calib
> > > + - const: temp_grade
> > > +
> > > + fsl,tempmon:
> > > + $ref: '/schemas/types.yaml#/definitions/phandle'
> > > + description: |
> > > + Phandle pointer to system controller that contains TEMPMON
> > control
> > > + registers, e.g. ANATOP on imx6q.
> >
> > Really, this should have been a child of the system controller. Not
> > too late to do that, but you'd need to keep this for compatibility.
>
> Sorry, I don't quite get your point, can you provide more details or example,
> thanks.
I guess you meant the tempmon node should be put inside anatop node? Then
DT files also needs to be changed? Right?
anatop: anatop@20c8000 {
compatible = "fsl,imx6sx-anatop", "fsl,imx6q-anatop",
"syscon", "simple-mfd";
reg = <0x020c8000 0x1000>;
interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
...
};
tempmon: tempmon {
compatible = "fsl,imx6sx-tempmon", "fsl,imx6q-tempmon";
interrupt-parent = <&gpc>;
interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
fsl,tempmon = <&anatop>;
nvmem-cells = <&tempmon_calib>, <&tempmon_temp_grade>;
nvmem-cell-names = "calib", "temp_grade";
clocks = <&clks IMX6SX_CLK_PLL3_USB_OTG>;
};
Thanks,
Anson
^ permalink raw reply
* Re: [PATCH v8 10/10] OPP: Add support for setting interconnect-tags
From: Viresh Kumar @ 2020-05-13 6:43 UTC (permalink / raw)
To: Georgi Djakov
Cc: vireshk, nm, sboyd, rjw, saravanak, sibis, mka, robh+dt, rnayak,
bjorn.andersson, vincent.guittot, jcrouse, evgreen, linux-pm,
devicetree, linux-kernel
In-Reply-To: <20200512125327.1868-11-georgi.djakov@linaro.org>
On 12-05-20, 15:53, Georgi Djakov wrote:
> From: Sibi Sankar <sibis@codeaurora.org>
>
> Add support for setting tags on icc paths associated with
> the opp_table.
>
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> ---
Applied this delta:
diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index f71dc5eb0eba..a4972c94f428 100644
--- a/drivers/opp/of.c
+++ b/drivers/opp/of.c
@@ -346,7 +346,6 @@ int dev_pm_opp_of_find_icc_paths(struct device *dev,
count = of_count_phandle_with_args(np, "interconnects",
"#interconnect-cells");
- of_node_put(np);
if (count < 0) {
ret = 0;
goto put_np;
@@ -380,7 +379,7 @@ int dev_pm_opp_of_find_icc_paths(struct device *dev,
/* Set tag if present */
if (!of_property_read_u32_index(np, "interconnect-tags",
i, &tag))
- icc_set_tag(opp_table->paths[i], tag);
+ icc_set_tag(paths[i], tag);
}
if (opp_table) {
--
viresh
^ permalink raw reply related
* Re: [PATCH v8 08/10] cpufreq: dt: Validate all interconnect paths
From: Viresh Kumar @ 2020-05-13 6:42 UTC (permalink / raw)
To: Georgi Djakov
Cc: vireshk, nm, sboyd, rjw, saravanak, sibis, mka, robh+dt, rnayak,
bjorn.andersson, vincent.guittot, jcrouse, evgreen, linux-pm,
devicetree, linux-kernel
In-Reply-To: <20200512125327.1868-9-georgi.djakov@linaro.org>
On 12-05-20, 15:53, Georgi Djakov wrote:
> Currently when we check for the available resources, we assume that there
> is only one interconnect path, but in fact it could be more than one. Do
> some validation to determine the number of paths and verify if each one
> of them is available.
>
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> ---
> v8:
> * New patch.
Merged this with the 7th patch and applied this delta:
diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index 15d70112454c..79742bbd221f 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -13,7 +13,6 @@
#include <linux/cpufreq.h>
#include <linux/cpumask.h>
#include <linux/err.h>
-#include <linux/interconnect.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/pm_opp.h>
@@ -91,49 +90,6 @@ static const char *find_supply_name(struct device *dev)
return name;
}
-static int find_icc_paths(struct device *dev)
-{
- struct device_node *np;
- struct icc_path **paths;
- int i, count, num_paths;
- int ret = 0;
-
- np = of_node_get(dev->of_node);
- if (!np)
- return 0;
-
- count = of_count_phandle_with_args(np, "interconnects",
- "#interconnect-cells");
- of_node_put(np);
- if (count < 0)
- return 0;
-
- /* two phandles when #interconnect-cells = <1> */
- if (count % 2) {
- dev_err(dev, "%s: Invalid interconnects values\n", __func__);
- return -EINVAL;
- }
-
- num_paths = count / 2;
- paths = kcalloc(num_paths, sizeof(*paths), GFP_KERNEL);
- if (!paths)
- return -ENOMEM;
-
- for (i = 0; i < num_paths; i++) {
- paths[i] = of_icc_get_by_index(dev, i);
- ret = PTR_ERR_OR_ZERO(paths[i]);
- if (ret)
- break;
- }
-
- while (i--)
- icc_put(paths[i]);
-
- kfree(paths);
-
- return ret;
-}
-
static int resources_available(void)
{
struct device *cpu_dev;
@@ -165,15 +121,9 @@ static int resources_available(void)
clk_put(cpu_clk);
- ret = find_icc_paths(cpu_dev);
- if (ret) {
- if (ret == -EPROBE_DEFER)
- dev_dbg(cpu_dev, "defer icc path: %d\n", ret);
- else
- dev_err(cpu_dev, "failed to get icc path: %d\n", ret);
-
+ ret = dev_pm_opp_of_find_icc_paths(cpu_dev, NULL);
+ if (ret)
return ret;
- }
name = find_supply_name(cpu_dev);
/* Platform doesn't require regulator */
--
viresh
^ permalink raw reply related
* Re: [PATCH v8 04/10] OPP: Add support for parsing interconnect bandwidth
From: Viresh Kumar @ 2020-05-13 6:41 UTC (permalink / raw)
To: Georgi Djakov
Cc: vireshk, nm, sboyd, rjw, saravanak, sibis, mka, robh+dt, rnayak,
bjorn.andersson, vincent.guittot, jcrouse, evgreen, linux-pm,
devicetree, linux-kernel
In-Reply-To: <20200512125327.1868-5-georgi.djakov@linaro.org>
On 12-05-20, 15:53, Georgi Djakov wrote:
> The OPP bindings now support bandwidth values, so add support to parse it
> from device tree and store it into the new dev_pm_opp_icc_bw struct, which
> is part of the dev_pm_opp.
>
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> ---
> v8:
> * Drop bandwidth requests and free memory in _opp_table_kref_release.
> * Take into account the supply_count in struct size calculations.
> * Free the temporary arrays for peak and average bandwidth.
> * Fix the check for opp-level.
> * Use dev_warn insted of dev_dbg.
> * Rename _of_find_icc_paths to _of_find_icc_paths.
> * Rename the variable count to supply_count.
Added this delta to this patch:
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index a3dd0bc9b9f6..8b640eac86d5 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -1000,7 +1000,7 @@ static struct opp_table *_allocate_opp_table(struct device *dev, int index)
}
/* Find interconnect path(s) for the device */
- ret = _of_find_icc_paths(opp_table, dev);
+ ret = dev_pm_opp_of_find_icc_paths(dev, opp_table);
if (ret)
dev_warn(dev, "%s: Error finding interconnect paths: %d\n",
__func__, ret);
diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index a41c0dc2ac04..15f30ed70bbc 100644
--- a/drivers/opp/of.c
+++ b/drivers/opp/of.c
@@ -332,10 +332,12 @@ static int _of_opp_alloc_required_opps(struct opp_table *opp_table,
return ret;
}
-int _of_find_icc_paths(struct opp_table *opp_table, struct device *dev)
+int dev_pm_opp_of_find_icc_paths(struct device *dev,
+ struct opp_table *opp_table)
{
struct device_node *np;
int ret, i, count, num_paths;
+ struct icc_path **paths;
np = of_node_get(dev->of_node);
if (!np)
@@ -354,15 +356,14 @@ int _of_find_icc_paths(struct opp_table *opp_table, struct device *dev)
}
num_paths = count / 2;
- opp_table->paths = kcalloc(num_paths, sizeof(*opp_table->paths),
- GFP_KERNEL);
- if (!opp_table->paths)
+ paths = kcalloc(num_paths, sizeof(*paths), GFP_KERNEL);
+ if (!paths)
return -ENOMEM;
for (i = 0; i < num_paths; i++) {
- opp_table->paths[i] = of_icc_get_by_index(dev, i);
- if (IS_ERR(opp_table->paths[i])) {
- ret = PTR_ERR(opp_table->paths[i]);
+ paths[i] = of_icc_get_by_index(dev, i);
+ if (IS_ERR(paths[i])) {
+ ret = PTR_ERR(paths[i]);
if (ret != -EPROBE_DEFER) {
dev_err(dev, "%s: Unable to get path%d: %d\n",
__func__, i, ret);
@@ -370,19 +371,23 @@ int _of_find_icc_paths(struct opp_table *opp_table, struct device *dev)
goto err;
}
}
- opp_table->path_count = num_paths;
+
+ if (opp_table) {
+ opp_table->paths = paths;
+ opp_table->path_count = num_paths;
+ }
return 0;
err:
while (i--)
- icc_put(opp_table->paths[i]);
+ icc_put(paths[i]);
- kfree(opp_table->paths);
- opp_table->paths = NULL;
+ kfree(paths);
return ret;
}
+EXPORT_SYMBOL_GPL(dev_pm_opp_of_find_icc_paths);
static bool _opp_is_supported(struct device *dev, struct opp_table *opp_table,
struct device_node *np)
diff --git a/drivers/opp/opp.h b/drivers/opp/opp.h
index 17d45119d9bc..2b81ffef1ba4 100644
--- a/drivers/opp/opp.h
+++ b/drivers/opp/opp.h
@@ -231,14 +231,12 @@ void _of_clear_opp_table(struct opp_table *opp_table);
struct opp_table *_managed_opp(struct device *dev, int index);
void _of_opp_free_required_opps(struct opp_table *opp_table,
struct dev_pm_opp *opp);
-int _of_find_icc_paths(struct opp_table *opp_table, struct device *dev);
#else
static inline void _of_init_opp_table(struct opp_table *opp_table, struct device *dev, int index) {}
static inline void _of_clear_opp_table(struct opp_table *opp_table) {}
static inline struct opp_table *_managed_opp(struct device *dev, int index) { return NULL; }
static inline void _of_opp_free_required_opps(struct opp_table *opp_table,
struct dev_pm_opp *opp) {}
-static inline int _of_find_icc_paths(struct opp_table *opp_table, struct device *dev) { return 0; }
#endif
#ifdef CONFIG_DEBUG_FS
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index cfceb0290401..d5c4a329321d 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -372,6 +372,7 @@ int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev, struct cpumask *cpuma
struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev);
struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp *opp);
int of_get_required_opp_performance_state(struct device_node *np, int index);
+int dev_pm_opp_of_find_icc_paths(struct device *dev, struct opp_table *opp_table);
void dev_pm_opp_of_register_em(struct cpumask *cpus);
#else
static inline int dev_pm_opp_of_add_table(struct device *dev)
@@ -420,6 +421,11 @@ static inline int of_get_required_opp_performance_state(struct device_node *np,
{
return -ENOTSUPP;
}
+
+static inline int dev_pm_opp_of_find_icc_paths(struct device *dev, struct opp_table *opp_table)
+{
+ return -ENOTSUPP;
+}
#endif
#endif /* __LINUX_OPP_H__ */
--
viresh
^ permalink raw reply related
* Re: [PATCH v8 02/10] OPP: Add helpers for reading the binding properties
From: Viresh Kumar @ 2020-05-13 6:40 UTC (permalink / raw)
To: Georgi Djakov
Cc: vireshk, nm, sboyd, rjw, saravanak, sibis, mka, robh+dt, rnayak,
bjorn.andersson, vincent.guittot, jcrouse, evgreen, linux-pm,
devicetree, linux-kernel
In-Reply-To: <20200512125327.1868-3-georgi.djakov@linaro.org>
On 12-05-20, 15:53, Georgi Djakov wrote:
> diff --git a/drivers/opp/of.c b/drivers/opp/of.c
> @@ -558,26 +580,13 @@ static struct dev_pm_opp *_opp_add_static_v2(struct opp_table *opp_table,
> if (!new_opp)
> return ERR_PTR(-ENOMEM);
>
> - ret = of_property_read_u64(np, "opp-hz", &rate);
> - if (ret < 0) {
> - /* "opp-hz" is optional for devices like power domains. */
> - if (!opp_table->is_genpd) {
> - dev_err(dev, "%s: opp-hz not found\n", __func__);
> - goto free_opp;
> - }
> -
> - rate_not_available = true;
> - } else {
> - /*
> - * Rate is defined as an unsigned long in clk API, and so
> - * casting explicitly to its type. Must be fixed once rate is 64
> - * bit guaranteed in clk API.
> - */
> - new_opp->rate = (unsigned long)rate;
> + ret = _read_opp_key(new_opp, np, &rate_not_available);
> + /* The key is optional for devices like power domains. */
Dropped this comment as key isn't optional for genpd as well as you
handled that in a later patch..
> + if (ret < 0 && !opp_table->is_genpd) {
> + dev_err(dev, "%s: opp key field not found\n", __func__);
> + goto free_opp;
> }
--
viresh
^ 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