* Re: [PATCH v5 03/16] spi: dw: Locally wait for the DMA transactions completion
From: Serge Semin @ 2020-05-29 8:12 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Serge Semin, Mark Brown, Georgy Vlasov, Ramil Zaripov,
Alexey Malahov, Thomas Bogendoerfer, Arnd Bergmann, Feng Tang,
Andy Shevchenko, Rob Herring, linux-mips, devicetree, linux-spi,
Linux Kernel Mailing List
In-Reply-To: <CAHp75VcT2zKnuRW3uxCQtbF0A65cbS20OFpz9sX0hftbjFp1hA@mail.gmail.com>
On Fri, May 29, 2020 at 10:55:32AM +0300, Andy Shevchenko wrote:
> On Fri, May 29, 2020 at 7:02 AM Serge Semin
> <Sergey.Semin@baikalelectronics.ru> wrote:
> >
> > Even if DMA transactions are finished it doesn't mean that the SPI
> > transfers are also completed. It's specifically concerns the Tx-only
> > SPI transfers, since there might be data left in the SPI Tx FIFO after
> > the DMA engine notifies that the Tx DMA procedure is done. In order to
> > completely fix the problem first the driver has to wait for the DMA
> > transaction completion, then for the corresponding SPI operations to be
> > finished. In this commit we implement the former part of the solution.
> >
> > Note we can't just move the SPI operations wait procedure to the DMA
> > completion callbacks, since these callbacks might be executed in the
> > tasklet context (and they will be in case of the DW DMA). In case of
> > slow SPI bus it can cause significant system performance drop.
>
> I read commit message, I read the code. What's going on here since you
> repeated xfer_completion (and its wait routine) from SPI core and I'm
> wondering what happened to it? Why we are not calling
> spi_finalize_current_transfer()?
We discussed that in v4. You complained about using ndelay() for slow SPI bus,
which may cause too long atomic context execution. We agreed. Since we can't wait
in the tasklet context and using a dedicated kernel thread for waiting would be too
much, Me and Mark agreed, that even if it causes us of the local wait-function
re-implementation the best approach would be not to use the generic
spi_transfer_wait() method, but instead wait for the DMA transactions locally
in the DMA driver and just return 0 from the transfer_one callback indicating
that the SPI transfer is finished and there is no need for SPI core to wait. As
a lot of DMA-based SPI drivers do.
If you don't understand what the commit message says, just say so. I'll
reformulate it.
-Sergey
>
> ...
>
> > dws->master->cur_msg->status = -EIO;
> > - spi_finalize_current_transfer(dws->master);
> > + complete(&dws->dma_completion);
> > return IRQ_HANDLED;
>
> ...
>
> > +static int dw_spi_dma_wait(struct dw_spi *dws, struct spi_transfer *xfer)
> > +{
> > + unsigned long long ms;
> > +
> > + ms = xfer->len * MSEC_PER_SEC * BITS_PER_BYTE;
> > + do_div(ms, xfer->effective_speed_hz);
> > + ms += ms + 200;
> > +
> > + if (ms > UINT_MAX)
> > + ms = UINT_MAX;
> > +
> > + ms = wait_for_completion_timeout(&dws->dma_completion,
> > + msecs_to_jiffies(ms));
> > +
> > + if (ms == 0) {
> > + dev_err(&dws->master->cur_msg->spi->dev,
> > + "DMA transaction timed out\n");
> > + return -ETIMEDOUT;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > /*
> > * dws->dma_chan_busy is set before the dma transfer starts, callback for tx
> > * channel will clear a corresponding bit.
> > @@ -155,7 +184,7 @@ static void dw_spi_dma_tx_done(void *arg)
> > return;
> >
> > dw_writel(dws, DW_SPI_DMACR, 0);
> > - spi_finalize_current_transfer(dws->master);
> > + complete(&dws->dma_completion);
> > }
> >
> > static struct dma_async_tx_descriptor *dw_spi_dma_prepare_tx(struct dw_spi *dws,
> > @@ -204,7 +233,7 @@ static void dw_spi_dma_rx_done(void *arg)
> > return;
> >
> > dw_writel(dws, DW_SPI_DMACR, 0);
> > - spi_finalize_current_transfer(dws->master);
> > + complete(&dws->dma_completion);
> > }
>
>
> --
> With Best Regards,
> Andy Shevchenko
^ permalink raw reply
* Re: [V6 PATCH 1/2] dt-bindings: Added device tree binding for max98390
From: Steve Lee @ 2020-05-29 8:06 UTC (permalink / raw)
To: Rob Herring
Cc: Steve Lee, robh+dt, ryans.lee, Mark Brown, ALSA development,
ryan.lee.maxim, devicetree, Liam Girdwood,
Linux Kernel Mailing List
In-Reply-To: <20200528141542.GA4186430@bogus>
On Thu, May 28, 2020 at 11:15 PM Rob Herring <robh@kernel.org> wrote:
>
> On Thu, 28 May 2020 19:37:55 +0900, Steve Lee wrote:
> > Add DT binding of max98390 amplifier driver.
> >
> > Signed-off-by: Steve Lee <steves.lee@maximintegrated.com>
> > ---
> > Changed since V5:
> > * Change txt to yaml and fix up the examples.
> > Changed since V4:
> > * No changes.
> > Changed since V3:
> > * No changes.
> > Changed since V2:
> > * No changes.
> > Changed since V1:
> > * Modified sample text in example
> >
> > .../bindings/sound/maxim,max98390.yaml | 39 +++++++++++++++++++
> > 1 file changed, 39 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/sound/maxim,max98390.yaml
> >
>
>
> My bot found errors running 'make dt_binding_check' on your patch:
>
> Documentation/devicetree/bindings/sound/maxim,max98390.yaml: mapping values are not allowed in this context
> in "<unicode string>", line 22, column 97
> Documentation/devicetree/bindings/Makefile:12: recipe for target 'Documentation/devicetree/bindings/sound/maxim,max98390.example.dts' failed
> make[1]: *** [Documentation/devicetree/bindings/sound/maxim,max98390.example.dts] Error 1
> make[1]: *** Waiting for unfinished jobs....
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/sound/maxim,max98390.yaml: ignoring, error parsing file
> warning: no schema found in file: ./Documentation/devicetree/bindings/sound/maxim,max98390.yaml
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/sound/maxim,max98390.yaml: ignoring, error parsing file
> warning: no schema found in file: ./Documentation/devicetree/bindings/sound/maxim,max98390.yaml
> Makefile:1300: recipe for target 'dt_binding_check' failed
> make: *** [dt_binding_check] Error 2
>
> See https://patchwork.ozlabs.org/patch/1299651
>
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure dt-schema is up to date:
>
> pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade
>
> Please check and re-submit.
>
Thanks for feedback. I re-submit with after dt binding check again.
^ permalink raw reply
* Re: [PATCH v10 10/10] arm64: dts: Add node for ufs exynos7
From: Krzysztof Kozlowski @ 2020-05-29 8:05 UTC (permalink / raw)
To: Alim Akhtar
Cc: robh, devicetree, linux-scsi, avri.altman, martin.petersen,
kwmad.kim, stanley.chu, cang, linux-samsung-soc, linux-arm-kernel,
linux-kernel
In-Reply-To: <20200528011658.71590-11-alim.akhtar@samsung.com>
On Thu, May 28, 2020 at 06:46:58AM +0530, Alim Akhtar wrote:
> Adding dt node foe UFS and UFS-PHY for exynos7 SoC.
>
> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
> Tested-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
> ---
> .../boot/dts/exynos/exynos7-espresso.dts | 4 ++
> arch/arm64/boot/dts/exynos/exynos7.dtsi | 43 ++++++++++++++++++-
Thanks, applied to next/dt-late. It might miss this merge
window and in such case I will keep it for v5.9 cycle.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump
From: Will Deacon @ 2020-05-29 8:05 UTC (permalink / raw)
To: John Donnelly
Cc: Baoquan He, Chen Zhou, tglx, mingo, catalin.marinas, dyoung,
robh+dt, arnd, devicetree, linux-doc, kexec, linux-kernel, horms,
guohanjun, pkushwaha, linux-arm-kernel, james.morse
In-Reply-To: <897ea1b9-a68c-8544-6532-a21be135ce01@oracle.com>
[+James Morse]
On Thu, May 28, 2020 at 05:20:34PM -0500, John Donnelly wrote:
> On 5/25/20 8:42 PM, Baoquan He wrote:
> > On 05/21/20 at 05:38pm, Chen Zhou wrote:
> > > This patch series enable reserving crashkernel above 4G in arm64.
[...]
> > > Chen Zhou (5):
> > > x86: kdump: move reserve_crashkernel_low() into crash_core.c
> > > arm64: kdump: reserve crashkenel above 4G for crash dump kernel
> > > arm64: kdump: add memory for devices by DT property, low-memory-range
> > > kdump: update Documentation about crashkernel on arm64
> > > dt-bindings: chosen: Document linux,low-memory-range for arm64 kdump
> > >
> > > Documentation/admin-guide/kdump/kdump.rst | 13 ++-
> > > .../admin-guide/kernel-parameters.txt | 12 ++-
> > > Documentation/devicetree/bindings/chosen.txt | 25 ++++++
> > > arch/arm64/kernel/setup.c | 8 +-
> > > arch/arm64/mm/init.c | 61 ++++++++++++-
> > > arch/x86/kernel/setup.c | 66 ++------------
> > > include/linux/crash_core.h | 3 +
> > > include/linux/kexec.h | 2 -
> > > kernel/crash_core.c | 85 +++++++++++++++++++
> > > kernel/kexec_core.c | 17 ----
> > > 10 files changed, 208 insertions(+), 84 deletions(-)
> > >
> This proposal to improve vmcore creation on Arm has been going on for
> almost a year now.
>
> Who is the final maintainer that needs to approve and except these ?
>
> What are the lingering issues that are remaining so we get these accepted
> into a upstream commit ?
The arm64 bits need an Ack from James Morse, but he's not on CC despite
offering feedback on earlier versions.
Will
^ permalink raw reply
* Re: [PATCH v5 03/16] spi: dw: Locally wait for the DMA transactions completion
From: Andy Shevchenko @ 2020-05-29 7:55 UTC (permalink / raw)
To: Serge Semin
Cc: Mark Brown, Serge Semin, Georgy Vlasov, Ramil Zaripov,
Alexey Malahov, Thomas Bogendoerfer, Arnd Bergmann, Feng Tang,
Andy Shevchenko, Rob Herring, linux-mips, devicetree, linux-spi,
Linux Kernel Mailing List
In-Reply-To: <20200529035915.20790-4-Sergey.Semin@baikalelectronics.ru>
On Fri, May 29, 2020 at 7:02 AM Serge Semin
<Sergey.Semin@baikalelectronics.ru> wrote:
>
> Even if DMA transactions are finished it doesn't mean that the SPI
> transfers are also completed. It's specifically concerns the Tx-only
> SPI transfers, since there might be data left in the SPI Tx FIFO after
> the DMA engine notifies that the Tx DMA procedure is done. In order to
> completely fix the problem first the driver has to wait for the DMA
> transaction completion, then for the corresponding SPI operations to be
> finished. In this commit we implement the former part of the solution.
>
> Note we can't just move the SPI operations wait procedure to the DMA
> completion callbacks, since these callbacks might be executed in the
> tasklet context (and they will be in case of the DW DMA). In case of
> slow SPI bus it can cause significant system performance drop.
I read commit message, I read the code. What's going on here since you
repeated xfer_completion (and its wait routine) from SPI core and I'm
wondering what happened to it? Why we are not calling
spi_finalize_current_transfer()?
...
> dws->master->cur_msg->status = -EIO;
> - spi_finalize_current_transfer(dws->master);
> + complete(&dws->dma_completion);
> return IRQ_HANDLED;
...
> +static int dw_spi_dma_wait(struct dw_spi *dws, struct spi_transfer *xfer)
> +{
> + unsigned long long ms;
> +
> + ms = xfer->len * MSEC_PER_SEC * BITS_PER_BYTE;
> + do_div(ms, xfer->effective_speed_hz);
> + ms += ms + 200;
> +
> + if (ms > UINT_MAX)
> + ms = UINT_MAX;
> +
> + ms = wait_for_completion_timeout(&dws->dma_completion,
> + msecs_to_jiffies(ms));
> +
> + if (ms == 0) {
> + dev_err(&dws->master->cur_msg->spi->dev,
> + "DMA transaction timed out\n");
> + return -ETIMEDOUT;
> + }
> +
> + return 0;
> +}
> +
> /*
> * dws->dma_chan_busy is set before the dma transfer starts, callback for tx
> * channel will clear a corresponding bit.
> @@ -155,7 +184,7 @@ static void dw_spi_dma_tx_done(void *arg)
> return;
>
> dw_writel(dws, DW_SPI_DMACR, 0);
> - spi_finalize_current_transfer(dws->master);
> + complete(&dws->dma_completion);
> }
>
> static struct dma_async_tx_descriptor *dw_spi_dma_prepare_tx(struct dw_spi *dws,
> @@ -204,7 +233,7 @@ static void dw_spi_dma_rx_done(void *arg)
> return;
>
> dw_writel(dws, DW_SPI_DMACR, 0);
> - spi_finalize_current_transfer(dws->master);
> + complete(&dws->dma_completion);
> }
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] dt-bindings: thermal: Convert qoriq to json-schema
From: Anson Huang @ 2020-05-29 7:28 UTC (permalink / raw)
To: rui.zhang, daniel.lezcano, amit.kucheria, robh+dt, hongtao.jia,
linux-pm, devicetree, linux-kernel
Cc: Linux-imx
Convert the qoriq thermal binding to DT schema format using json-schema
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
.../devicetree/bindings/thermal/qoriq-thermal.txt | 71 -------------
.../devicetree/bindings/thermal/qoriq-thermal.yaml | 111 +++++++++++++++++++++
2 files changed, 111 insertions(+), 71 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
create mode 100644 Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt b/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
deleted file mode 100644
index 28f2cba..0000000
--- a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
+++ /dev/null
@@ -1,71 +0,0 @@
-* Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs
-
-Required properties:
-- compatible : Must include "fsl,qoriq-tmu" or "fsl,imx8mq-tmu". The
- version of the device is determined by the TMU IP Block Revision
- Register (IPBRR0) at offset 0x0BF8.
- Table of correspondences between IPBRR0 values and example chips:
- Value Device
- ---------- -----
- 0x01900102 T1040
-- reg : Address range of TMU registers.
-- interrupts : Contains the interrupt for TMU.
-- fsl,tmu-range : The values to be programmed into TTRnCR, as specified by
- the SoC reference manual. The first cell is TTR0CR, the second is
- TTR1CR, etc.
-- fsl,tmu-calibration : A list of cell pairs containing temperature
- calibration data, as specified by the SoC reference manual.
- The first cell of each pair is the value to be written to TTCFGR,
- and the second is the value to be written to TSCFGR.
-- #thermal-sensor-cells : Must be 1. The sensor specifier is the monitoring
- site ID, and represents the "n" in TRITSRn and TRATSRn.
-
-Optional property:
-- little-endian : If present, the TMU registers are little endian. If absent,
- the default is big endian.
-- clocks : the clock for clocking the TMU silicon.
-
-Example:
-
-tmu@f0000 {
- compatible = "fsl,qoriq-tmu";
- reg = <0xf0000 0x1000>;
- interrupts = <18 2 0 0>;
- fsl,tmu-range = <0x000a0000 0x00090026 0x0008004a 0x0001006a>;
- fsl,tmu-calibration = <0x00000000 0x00000025
- 0x00000001 0x00000028
- 0x00000002 0x0000002d
- 0x00000003 0x00000031
- 0x00000004 0x00000036
- 0x00000005 0x0000003a
- 0x00000006 0x00000040
- 0x00000007 0x00000044
- 0x00000008 0x0000004a
- 0x00000009 0x0000004f
- 0x0000000a 0x00000054
-
- 0x00010000 0x0000000d
- 0x00010001 0x00000013
- 0x00010002 0x00000019
- 0x00010003 0x0000001f
- 0x00010004 0x00000025
- 0x00010005 0x0000002d
- 0x00010006 0x00000033
- 0x00010007 0x00000043
- 0x00010008 0x0000004b
- 0x00010009 0x00000053
-
- 0x00020000 0x00000010
- 0x00020001 0x00000017
- 0x00020002 0x0000001f
- 0x00020003 0x00000029
- 0x00020004 0x00000031
- 0x00020005 0x0000003c
- 0x00020006 0x00000042
- 0x00020007 0x0000004d
- 0x00020008 0x00000056
-
- 0x00030000 0x00000012
- 0x00030001 0x0000001d>;
- #thermal-sensor-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
new file mode 100644
index 0000000..bfbfa04
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
@@ -0,0 +1,111 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/qoriq-thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs
+
+maintainers:
+ - Hongtao Jia <hongtao.jia@freescale.com>
+
+properties:
+ compatible:
+ description: |
+ The version of the device is determined by the TMU IP Block Revision
+ Register (IPBRR0) at offset 0x0BF8.
+ Table of correspondences between IPBRR0 values and example chips:
+ Value Device
+ ---------- -----
+ 0x01900102 T1040
+ enum:
+ - fsl,qoriq-tmu
+ - fsl,imx8mq-tmu
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ fsl,tmu-range:
+ $ref: '/schemas/types.yaml#/definitions/uint32-array'
+ description: |
+ The values to be programmed into TTRnCR, as specified by the SoC
+ reference manual. The first cell is TTR0CR, the second is TTR1CR, etc.
+
+ fsl,tmu-calibration:
+ $ref: '/schemas/types.yaml#/definitions/uint32-array'
+ description: |
+ A list of cell pairs containing temperature calibration data, as
+ specified by the SoC reference manual. The first cell of each pair
+ is the value to be written to TTCFGR, and the second is the value
+ to be written to TSCFGR.
+
+ little-endian:
+ description: |
+ boolean, if present, the TMU registers are little endian. If absent,
+ the default is big endian.
+ type: boolean
+
+ clocks:
+ maxItems: 1
+
+ "#thermal-sensor-cells":
+ const: 1
+ description: |
+ Number of cells required to uniquely identify the thermal sensors. This
+ is set to 1 for multiple sensors.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - fsl,tmu-range
+ - fsl,tmu-calibration
+ - '#thermal-sensor-cells'
+
+examples:
+ - |
+ tmu@f0000 {
+ compatible = "fsl,qoriq-tmu";
+ reg = <0xf0000 0x1000>;
+ interrupts = <18 2 0 0>;
+ fsl,tmu-range = <0x000a0000 0x00090026 0x0008004a 0x0001006a>;
+ fsl,tmu-calibration = <0x00000000 0x00000025
+ 0x00000001 0x00000028
+ 0x00000002 0x0000002d
+ 0x00000003 0x00000031
+ 0x00000004 0x00000036
+ 0x00000005 0x0000003a
+ 0x00000006 0x00000040
+ 0x00000007 0x00000044
+ 0x00000008 0x0000004a
+ 0x00000009 0x0000004f
+ 0x0000000a 0x00000054
+
+ 0x00010000 0x0000000d
+ 0x00010001 0x00000013
+ 0x00010002 0x00000019
+ 0x00010003 0x0000001f
+ 0x00010004 0x00000025
+ 0x00010005 0x0000002d
+ 0x00010006 0x00000033
+ 0x00010007 0x00000043
+ 0x00010008 0x0000004b
+ 0x00010009 0x00000053
+
+ 0x00020000 0x00000010
+ 0x00020001 0x00000017
+ 0x00020002 0x0000001f
+ 0x00020003 0x00000029
+ 0x00020004 0x00000031
+ 0x00020005 0x0000003c
+ 0x00020006 0x00000042
+ 0x00020007 0x0000004d
+ 0x00020008 0x00000056
+
+ 0x00030000 0x00000012
+ 0x00030001 0x0000001d>;
+ #thermal-sensor-cells = <1>;
+ };
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] usb/phy-generic: Add support for OTG VBUS supply control
From: Peter Chen @ 2020-05-29 7:20 UTC (permalink / raw)
To: Mike Looijmans
Cc: linux-usb@vger.kernel.org, gregkh@linuxfoundation.org,
robh+dt@kernel.org, balbi@kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <3fe53080-cc74-3b0b-3041-2c4fde1b7e30@topic.nl>
On 20-05-29 07:47:37, Mike Looijmans wrote:
>
> Met vriendelijke groet / kind regards,
>
> Mike Looijmans
> System Expert
>
>
> TOPIC Embedded Products B.V.
> Materiaalweg 4, 5681 RJ Best
> The Netherlands
>
> T: +31 (0) 499 33 69 69
> E: mike.looijmans@topicproducts.com
> W: https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.topicproducts.com%2F&data=02%7C01%7Cpeter.chen%40nxp.com%7Cc8a5e33bbd3141b57d5408d80393cff2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637263280668758097&sdata=e5yJuVtOJ9%2BUqmRl6HNk14Fd0%2FPR2jQAhOl1vHtYJKg%3D&reserved=0
>
> Please consider the environment before printing this e-mail
> On 28-05-2020 13:20, Peter Chen wrote:
> > On 20-05-26 16:50:51, Mike Looijmans wrote:
> > > This enables support for VBUS on boards where the power is supplied
> > > by a regulator. The regulator is enabled when the USB port enters
> > > HOST mode.
> > >
> > Why you don't do this at your host controller driver?
>
> That was my first thought too, but it made more sense to do it here. It's
> about how things are connected on the board, and not about the controller.
> Also makes for a consistent devicetree when using different SOCs on the same
> carrier board.
A standard interface is: port_power for hc_driver, but seems the xHCI
doesn't implement it.
>
> I already needed this driver to properly reset the USB phy, which the
> controller driver also did not do. So it made sense to add the vbus power
> control to this driver too.
>
> If you have a strong preference for the controller driver, I can move this
> to the DWC3 driver which happens to be the controller for the latest batch
> of SOMs.
>
You may ask Mathias or Felipe for comments where is suitable for vbus
regulator.
> > > +
> > > nop->dev = dev;
> > > nop->phy.dev = nop->dev;
> > > nop->phy.label = "nop-xceiv";
> > > @@ -278,6 +319,7 @@ int usb_phy_gen_create_phy(struct device *dev, struct usb_phy_generic *nop)
> > > nop->phy.otg->usb_phy = &nop->phy;
> > > nop->phy.otg->set_host = nop_set_host;
> > > nop->phy.otg->set_peripheral = nop_set_peripheral;
> > > + nop->phy.otg->set_vbus = nop_set_vbus;
OTG is dead, even USB-IF has refused OTG test since 2019-09, you may
avoid to use OTG structure.
Peter
> > > return 0;
> > > }
> > > diff --git a/drivers/usb/phy/phy-generic.h b/drivers/usb/phy/phy-generic.h
> > > index 7ee80211a688..a3663639ea1e 100644
> > > --- a/drivers/usb/phy/phy-generic.h
> > > +++ b/drivers/usb/phy/phy-generic.h
> > > @@ -14,7 +14,9 @@ struct usb_phy_generic {
> > > struct gpio_desc *gpiod_reset;
> > > struct gpio_desc *gpiod_vbus;
> > > struct regulator *vbus_draw;
> > > + struct regulator *vbus_reg;
> > > bool vbus_draw_enabled;
> > > + bool vbus_reg_enabled;
> > > unsigned long mA;
> > > unsigned int vbus;
> > > };
> > > --
> > > 2.17.1
> > >
>
> --
> Mike Looijmans
>
--
Thanks,
Peter Chen
^ permalink raw reply
* Re: [PATCH v4 2/7] dt-bindings: mdf: ti,j721e-system-controller.yaml: Add J721e
From: Roger Quadros @ 2020-05-29 6:55 UTC (permalink / raw)
To: t-kristo, robh; +Cc: kishon, nm, nsekhar, vigneshr, devicetree, linux-kernel
In-Reply-To: <a2d6b4c3-f17f-389b-305e-8be4646aa397@ti.com>
Hi Rob,
On 19/05/2020 16:51, Roger Quadros wrote:
> Add DT binding schema for J721e system controller.
>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> ---
> Changelog:
> v4
> -address comments.
Hope this patch is OK now?
cheers,
-roger
>
> .../mfd/ti,j721e-system-controller.yaml | 76 +++++++++++++++++++
> 1 file changed, 76 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml
>
> diff --git a/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml b/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml
> new file mode 100644
> index 000000000000..cb28dc480c4c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml
> @@ -0,0 +1,76 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/ti,j721e-system-controller.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TI J721e System Controller Registers R/W Device Tree Bindings
> +
> +description: |
> + This represents the Control Module registers (CTRL_MMR0) on the SoC.
> + System controller node represents a register region containing a set
> + of miscellaneous registers. The registers are not cohesive enough to
> + represent as any specific type of device. The typical use-case is
> + for some other node's driver, or platform-specific code, to acquire
> + a reference to the syscon node (e.g. by phandle, node path, or
> + search using a specific compatible value), interrogate the node (or
> + associated OS driver) to determine the location of the registers,
> + and access the registers directly.
> +
> +maintainers:
> + - Kishon Vijay Abraham I <kishon@ti.com>
> + - Roger Quadros <rogerq@ti.com
> +
> +properties:
> + compatible:
> + anyOf:
> + - items:
> + - enum:
> + - ti,j721e-system-controller
> + - const: syscon
> + - const: simple-mfd
> +
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 1
> +
> + ranges:
> + description:
> + Should translate from local addresses to bus addresses.
> +
> +# Optional children
> +
> + "^serdes-ln-ctrl@[0-9a-f]+$":
> + type: object
> + description: |
> + This is the SERDES lane control mux. It should follow the bindings
> + specified in
> + Documentation/devicetree/bindings/mux/reg-mux.txt
> +
> +required:
> + - compatible
> + - reg
> + - "#address-cells"
> + - "#size-cells"
> + - ranges
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + scm_conf: scm-conf@100000 {
> + compatible = "ti,j721e-system-controller", "syscon", "simple-mfd";
> + reg = <0x00100000 0x1c000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + serdes_ln_ctrl: serdes-ln-ctrl@4080 {
> + compatible = "mmio-mux";
> + reg = <0x00004080 0x50>;
> + };
> + };
> +...
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
* Re: [PATCH 0/6] arm64: dts: qcom: smmu/USB nodes and HDK855/HDK865 dts
From: Bjorn Andersson @ 2020-05-29 6:44 UTC (permalink / raw)
To: Jonathan Marek
Cc: linux-arm-msm, Andy Gross,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Rob Herring
In-Reply-To: <0630ae9c-6ae7-b74e-5dd3-0c569bad74f5@marek.ca>
On Thu 28 May 20:15 PDT 2020, Jonathan Marek wrote:
> On 5/28/20 11:05 PM, Bjorn Andersson wrote:
> > On Sat 23 May 19:38 PDT 2020, Jonathan Marek wrote:
> >
> > > Add dts nodes for apps_smmu and USB for both sm8150 and sm8250.
> > >
> > > Also add initial dts files for HDK855 and HDK865, based on mtp dts, with a
> > > few changes. Notably, the HDK865 dts has regulator config changed a bit based
> > > on downstream (I think sm8250-mtp.dts is wrong and copied too much from sm8150).
> >
> > Can you please elaborate on this discrepancy? I do remember seeing
> > something odd when looking at this, but it seems like I didn't document
> > it anywhere...
> >
> > Thanks,
> > Bjorn
> >
>
> Mainly there's a few regulators with different min/max voltage values. For
> example with l16a, downstream has min/max 3024000/3304000 but upstream
> sm8250-mtp has 2704000/2960000. I also added l18a.
>
Thanks, we'll double check these.
Regards,
Bjorn
> > >
> > > Jonathan Marek (6):
> > > arm64: dts: qcom: sm8150: add apps_smmu node
> > > arm64: dts: qcom: sm8250: add apps_smmu node
> > > arm64: dts: qcom: sm8150: Add secondary USB and PHY nodes
> > > arm64: dts: qcom: sm8250: Add USB and PHY device nodes
> > > arm64: dts: qcom: add sm8150 hdk dts
> > > arm64: dts: qcom: add sm8250 hdk dts
> > >
> > > arch/arm64/boot/dts/qcom/Makefile | 2 +
> > > arch/arm64/boot/dts/qcom/sm8150-hdk.dts | 461 ++++++++++++++++++++++++
> > > arch/arm64/boot/dts/qcom/sm8150.dtsi | 180 +++++++++
> > > arch/arm64/boot/dts/qcom/sm8250-hdk.dts | 454 +++++++++++++++++++++++
> > > arch/arm64/boot/dts/qcom/sm8250.dtsi | 287 +++++++++++++++
> > > 5 files changed, 1384 insertions(+)
> > > create mode 100644 arch/arm64/boot/dts/qcom/sm8150-hdk.dts
> > > create mode 100644 arch/arm64/boot/dts/qcom/sm8250-hdk.dts
> > >
> > > --
> > > 2.26.1
> > >
^ permalink raw reply
* [PATCH] dt-bindings: clock: Convert i.MX8QXP LPCG to json-schema
From: Anson Huang @ 2020-05-29 6:21 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, shawnguo, s.hauer, kernel, festevam,
aisheng.dong, linux-clk, devicetree, linux-arm-kernel,
linux-kernel
Cc: Linux-imx
Convert the i.MX8QXP LPCG binding to DT schema format using json-schema.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
.../devicetree/bindings/clock/imx8qxp-lpcg.txt | 51 ---------------
.../devicetree/bindings/clock/imx8qxp-lpcg.yaml | 72 ++++++++++++++++++++++
2 files changed, 72 insertions(+), 51 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/clock/imx8qxp-lpcg.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml
diff --git a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.txt b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.txt
deleted file mode 100644
index 965cfa4..0000000
--- a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.txt
+++ /dev/null
@@ -1,51 +0,0 @@
-* NXP i.MX8QXP LPCG (Low-Power Clock Gating) Clock bindings
-
-The Low-Power Clock Gate (LPCG) modules contain a local programming
-model to control the clock gates for the peripherals. An LPCG module
-is used to locally gate the clocks for the associated peripheral.
-
-Note:
-This level of clock gating is provided after the clocks are generated
-by the SCU resources and clock controls. Thus even if the clock is
-enabled by these control bits, it might still not be running based
-on the base resource.
-
-Required properties:
-- compatible: Should be one of:
- "fsl,imx8qxp-lpcg-adma",
- "fsl,imx8qxp-lpcg-conn",
- "fsl,imx8qxp-lpcg-dc",
- "fsl,imx8qxp-lpcg-dsp",
- "fsl,imx8qxp-lpcg-gpu",
- "fsl,imx8qxp-lpcg-hsio",
- "fsl,imx8qxp-lpcg-img",
- "fsl,imx8qxp-lpcg-lsio",
- "fsl,imx8qxp-lpcg-vpu"
-- reg: Address and length of the register set
-- #clock-cells: Should be <1>
-
-The clock consumer should specify the desired clock by having the clock
-ID in its "clocks" phandle cell.
-See the full list of clock IDs from:
-include/dt-bindings/clock/imx8qxp-clock.h
-
-Examples:
-
-#include <dt-bindings/clock/imx8qxp-clock.h>
-
-conn_lpcg: clock-controller@5b200000 {
- compatible = "fsl,imx8qxp-lpcg-conn";
- reg = <0x5b200000 0xb0000>;
- #clock-cells = <1>;
-};
-
-usdhc1: mmc@5b010000 {
- compatible = "fsl,imx8qxp-usdhc", "fsl,imx7d-usdhc";
- interrupt-parent = <&gic>;
- interrupts = <GIC_SPI 232 IRQ_TYPE_LEVEL_HIGH>;
- reg = <0x5b010000 0x10000>;
- clocks = <&conn_lpcg IMX8QXP_CONN_LPCG_SDHC0_IPG_CLK>,
- <&conn_lpcg IMX8QXP_CONN_LPCG_SDHC0_PER_CLK>,
- <&conn_lpcg IMX8QXP_CONN_LPCG_SDHC0_HCLK>;
- clock-names = "ipg", "per", "ahb";
-};
diff --git a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml
new file mode 100644
index 0000000..d5b6825
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/imx8qxp-lpcg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP i.MX8QXP LPCG (Low-Power Clock Gating) Clock bindings
+
+maintainers:
+ - Aisheng Dong <aisheng.dong@nxp.com>
+
+description: |
+ The Low-Power Clock Gate (LPCG) modules contain a local programming
+ model to control the clock gates for the peripherals. An LPCG module
+ is used to locally gate the clocks for the associated peripheral.
+
+ This level of clock gating is provided after the clocks are generated
+ by the SCU resources and clock controls. Thus even if the clock is
+ enabled by these control bits, it might still not be running based
+ on the base resource.
+
+ The clock consumer should specify the desired clock by having the clock
+ ID in its "clocks" phandle cell. See the full list of clock IDs from:
+ include/dt-bindings/clock/imx8-clock.h
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx8qxp-lpcg-adma
+ - fsl,imx8qxp-lpcg-conn
+ - fsl,imx8qxp-lpcg-dc
+ - fsl,imx8qxp-lpcg-dsp
+ - fsl,imx8qxp-lpcg-gpu
+ - fsl,imx8qxp-lpcg-hsio
+ - fsl,imx8qxp-lpcg-img
+ - fsl,imx8qxp-lpcg-lsio
+ - fsl,imx8qxp-lpcg-vpu
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx8-clock.h>
+ #include <dt-bindings/firmware/imx/rsrc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ clock-controller@5b200000 {
+ compatible = "fsl,imx8qxp-lpcg-conn";
+ reg = <0x5b200000 0xb0000>;
+ #clock-cells = <1>;
+ };
+
+ mmc@5b010000 {
+ compatible = "fsl,imx8qxp-usdhc", "fsl,imx7d-usdhc";
+ interrupts = <GIC_SPI 232 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <0x5b010000 0x10000>;
+ clocks = <&conn_lpcg IMX_CONN_LPCG_SDHC0_IPG_CLK>,
+ <&conn_lpcg IMX_CONN_LPCG_SDHC0_PER_CLK>,
+ <&conn_lpcg IMX_CONN_LPCG_SDHC0_HCLK>;
+ clock-names = "ipg", "per", "ahb";
+ power-domains = <&pd IMX_SC_R_SDHC_0>;
+ status = "disabled";
+ };
--
2.7.4
^ permalink raw reply related
* Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
From: Viresh Kumar @ 2020-05-29 6:27 UTC (permalink / raw)
To: Jassi Brar
Cc: Rob Herring, Arnd Bergmann, Frank Rowand, Bjorn Andersson,
Vincent Guittot, linux-arm-kernel, Sudeep Holla, Devicetree List,
Linux Kernel Mailing List
In-Reply-To: <CABb+yY3KKpDHTsTBescW_rXmqmLzJh-Ogaotk2n=nYRkfHy2cg@mail.gmail.com>
On 29-05-20, 00:20, Jassi Brar wrote:
> The fact that all these bits are backed by one physical signal makes
I believe that within the IP itself, there must be 32 signals, just
that only one comes out of it all OR'd together. Maybe that can be
verified by writing 0x01 to it multiple times and it should generate
the interrupt only once on the first instance. i.e. writing 1 to any
big again won't raise the interrupt.
> the firmware implement its own mux-demux'ing scheme.
Similar to how the interrupt controllers do it in the kernel, they
receive a single interrupt and then go check its registers/bits to see
which peripheral raised it.
> So the choice was
> between demux and single signal at a time.
Well, the demux is on the firmware side and the kernel may not need to
worry about that, let the platform do it ?
> Had there been one signal
> per bit, the implementation would have definitely been 'efficient'.
I will say 'More efficient', it will still be 'efficient' if we
implement doorbell.
> And the first platform the driver was developed on, required message
> passing over the registers.
I think it was correctly done at that point of time. No doubt about
that.
> So now my approach is to make do with what
> we have...unless it shows in numbers.
ARM's office is closed (lock-down) and he doesn't have remote access
to the board and so was unable to do it until now.
Numbers or no numbers, I don't think there is a question here about
what is the most efficient way of doing it. Doing it in parallel (when
the hardware allows) is surely going to be more efficient. Sending a
signal, getting it processed by the firmware, doing something with it
and then sending an Ack and that being received by kernel will take
time. Why make a queue on the kernel side when we don't have to. :)
> Anyways, if it comes to that, I'd rather a separate "doorbell' driver
> than a driver working in two s/w modes.
I think that would be fine with everyone, if you are fine with that
now (based on plain logic and no numbers), maybe we can get that done
now?
--
viresh
^ permalink raw reply
* [PATCH 1/2] dt-bindings: rtc: add wakeup-source for FlexTimer
From: Ran Wang @ 2020-05-29 6:10 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Rob Herring, Li Biwen
Cc: linux-rtc, devicetree, linux-kernel, Ran Wang
Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
---
Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt b/Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt
index fffac74..d7c482c 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt
@@ -20,6 +20,7 @@ Required properties:
Optional properties:
- big-endian: If the host controller is big-endian mode, specify this property.
The default endian mode is little-endian.
+- wakeup-source: Enable it as a wakeup source
Example:
rcpm: rcpm@1e34040 {
@@ -32,5 +33,6 @@ ftm_alarm0: timer@2800000 {
compatible = "fsl,ls1088a-ftm-alarm";
reg = <0x0 0x2800000 0x0 0x10000>;
fsl,rcpm-wakeup = <&rcpm 0x0 0x0 0x0 0x0 0x4000 0x0>;
+ wakeup-source;
interrupts = <0 44 4>;
};
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] rtc: fsl-ftm-alarm: fix freeze(s2idle) doesnot wake
From: Ran Wang @ 2020-05-29 6:10 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Rob Herring, Li Biwen
Cc: linux-rtc, devicetree, linux-kernel, Ran Wang
In-Reply-To: <20200529061035.18912-1-ran.wang_1@nxp.com>
Use dev_pm_set_wake_irq() instead of flag IRQF_NO_SUSPEND to enable
wakeup system feature for both freeze(s2idle) and mem(deep).
Use property 'wakeup-source' to control this feature.
Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
---
drivers/rtc/rtc-fsl-ftm-alarm.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-fsl-ftm-alarm.c b/drivers/rtc/rtc-fsl-ftm-alarm.c
index 756af62..c6945d84 100644
--- a/drivers/rtc/rtc-fsl-ftm-alarm.c
+++ b/drivers/rtc/rtc-fsl-ftm-alarm.c
@@ -21,6 +21,7 @@
#include <linux/rtc.h>
#include <linux/time.h>
#include <linux/acpi.h>
+#include <linux/pm_wakeirq.h>
#define FTM_SC_CLK(c) ((c) << FTM_SC_CLK_MASK_SHIFT)
@@ -41,6 +42,7 @@ struct ftm_rtc {
struct rtc_device *rtc_dev;
void __iomem *base;
bool big_endian;
+ bool wakeup;
u32 alarm_freq;
};
@@ -267,6 +269,9 @@ static int ftm_rtc_probe(struct platform_device *pdev)
return PTR_ERR(rtc->base);
}
+ rtc->wakeup =
+ device_property_read_bool(&pdev->dev, "wakeup-source");
+
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
dev_err(&pdev->dev, "can't get irq number\n");
@@ -274,7 +279,7 @@ static int ftm_rtc_probe(struct platform_device *pdev)
}
ret = devm_request_irq(&pdev->dev, irq, ftm_rtc_alarm_interrupt,
- IRQF_NO_SUSPEND, dev_name(&pdev->dev), rtc);
+ 0, dev_name(&pdev->dev), rtc);
if (ret < 0) {
dev_err(&pdev->dev, "failed to request irq\n");
return ret;
@@ -286,7 +291,10 @@ static int ftm_rtc_probe(struct platform_device *pdev)
rtc->alarm_freq = (u32)FIXED_FREQ_CLK / (u32)MAX_FREQ_DIV;
rtc->rtc_dev->ops = &ftm_rtc_ops;
- device_init_wakeup(&pdev->dev, true);
+ device_init_wakeup(&pdev->dev, rtc->wakeup);
+ ret = dev_pm_set_wake_irq(&pdev->dev, irq);
+ if (ret)
+ dev_err(&pdev->dev, "irq wake enable failed.\n");
ret = rtc_register_device(rtc->rtc_dev);
if (ret) {
--
2.7.4
^ permalink raw reply related
* Fwd: [PATCH v3 2/2] media: cec: i2c: ch7322: Add ch7322 CEC controller driver
From: Jeff Chase @ 2020-05-29 6:10 UTC (permalink / raw)
To: linux-media; +Cc: mchehab, Hans Verkuil, robh+dt, devicetree
In-Reply-To: <CALTkaQ2OR+bc2QGeucA5aP3SiM5HLnx5=DoZQ51E_1d99Hb5Uw@mail.gmail.com>
(Resending as plain text, sorry)
> +static int ch7322_cec_adap_enable(struct cec_adapter *adap, bool enable)
> +{
> + struct ch7322 *ch7322 = cec_get_drvdata(adap);
> + int ret;
> +
> + if (enable)
> + ret = ch7322_unmask_interrupt(ch7322);
> + else
> + ret = ch7322_mask_interrupt(ch7322);
> +
> + return ret;
> +}
> +
I just realized that doing this here is broken -- the driver depends
on the interrupt to detect when the physical address changes. I could
mask only the tx/rx interrupt here instead but that is starting to
feel a bit pointless.
I haven't looked into the cec notifier mechanism yet but would it be
better to try to use that instead if possible and just ignore this
device's physical address detection? Then I could do more of a proper
reset in this enable op. But I'm not sure if I can properly associate
the device with an HDMI port on my platform unless I make some changes
to coreboot.
Thanks,
Jeff
^ permalink raw reply
* [PATCH v2] usb/phy-generic: Add support for OTG VBUS supply control
From: Mike Looijmans @ 2020-05-29 6:00 UTC (permalink / raw)
To: linux-usb
Cc: gregkh, robh+dt, balbi, devicetree, linux-kernel, Mike Looijmans
This enables support for VBUS on boards where the power is supplied
by a regulator. The regulator is enabled when the USB port enters
HOST mode.
Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
---
v2: Added missing "return 0;" in set_vbus method
.../devicetree/bindings/usb/usb-nop-xceiv.txt | 3 ++
drivers/usb/phy/phy-generic.c | 46 ++++++++++++++++++-
drivers/usb/phy/phy-generic.h | 2 +
3 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
index 4dc6a8ee3071..775a19fdb613 100644
--- a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
+++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
@@ -16,6 +16,9 @@ Optional properties:
- vcc-supply: phandle to the regulator that provides power to the PHY.
+- vbus-supply: phandle to the regulator that provides the VBUS power for when
+ the device is in HOST mode.
+
- reset-gpios: Should specify the GPIO for reset.
- vbus-detect-gpio: should specify the GPIO detecting a VBus insertion
diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
index 661a229c105d..69bf39510e27 100644
--- a/drivers/usb/phy/phy-generic.c
+++ b/drivers/usb/phy/phy-generic.c
@@ -203,13 +203,45 @@ static int nop_set_host(struct usb_otg *otg, struct usb_bus *host)
return 0;
}
+static int nop_set_vbus(struct usb_otg *otg, bool enabled)
+{
+ struct usb_phy_generic *nop;
+ int ret;
+
+ if (!otg)
+ return -ENODEV;
+
+ nop = container_of(otg->usb_phy, struct usb_phy_generic, phy);
+
+ if (!nop->vbus_reg)
+ return 0;
+
+ if (enabled) {
+ if (nop->vbus_reg_enabled)
+ return 0;
+ ret = regulator_enable(nop->vbus_reg);
+ if (ret < 0)
+ return ret;
+ nop->vbus_reg_enabled = true;
+ } else {
+ if (!nop->vbus_reg_enabled)
+ return 0;
+ ret = regulator_disable(nop->vbus_reg);
+ if (ret < 0)
+ return ret;
+ nop->vbus_reg_enabled = false;
+ }
+
+ return 0;
+}
+
int usb_phy_gen_create_phy(struct device *dev, struct usb_phy_generic *nop)
{
enum usb_phy_type type = USB_PHY_TYPE_USB2;
int err = 0;
u32 clk_rate = 0;
- bool needs_vcc = false, needs_clk = false;
+ bool needs_vcc = false, needs_clk = false, needs_vbus = false;
if (dev->of_node) {
struct device_node *node = dev->of_node;
@@ -219,6 +251,7 @@ int usb_phy_gen_create_phy(struct device *dev, struct usb_phy_generic *nop)
needs_vcc = of_property_read_bool(node, "vcc-supply");
needs_clk = of_property_read_bool(node, "clocks");
+ needs_vbus = of_property_read_bool(node, "vbus-supply");
}
nop->gpiod_reset = devm_gpiod_get_optional(dev, "reset",
GPIOD_ASIS);
@@ -268,6 +301,16 @@ int usb_phy_gen_create_phy(struct device *dev, struct usb_phy_generic *nop)
return -EPROBE_DEFER;
}
+ nop->vbus_reg = devm_regulator_get(dev, "vbus");
+ if (IS_ERR(nop->vbus_reg)) {
+ dev_dbg(dev, "Error getting vbus regulator: %ld\n",
+ PTR_ERR(nop->vbus_reg));
+ if (needs_vbus)
+ return -EPROBE_DEFER;
+
+ nop->vbus_reg = NULL;
+ }
+
nop->dev = dev;
nop->phy.dev = nop->dev;
nop->phy.label = "nop-xceiv";
@@ -278,6 +321,7 @@ int usb_phy_gen_create_phy(struct device *dev, struct usb_phy_generic *nop)
nop->phy.otg->usb_phy = &nop->phy;
nop->phy.otg->set_host = nop_set_host;
nop->phy.otg->set_peripheral = nop_set_peripheral;
+ nop->phy.otg->set_vbus = nop_set_vbus;
return 0;
}
diff --git a/drivers/usb/phy/phy-generic.h b/drivers/usb/phy/phy-generic.h
index 7ee80211a688..a3663639ea1e 100644
--- a/drivers/usb/phy/phy-generic.h
+++ b/drivers/usb/phy/phy-generic.h
@@ -14,7 +14,9 @@ struct usb_phy_generic {
struct gpio_desc *gpiod_reset;
struct gpio_desc *gpiod_vbus;
struct regulator *vbus_draw;
+ struct regulator *vbus_reg;
bool vbus_draw_enabled;
+ bool vbus_reg_enabled;
unsigned long mA;
unsigned int vbus;
};
--
2.17.1
^ permalink raw reply related
* [PATCH v4 1/2] dt-bindings: sc16is7xx: Add flag to activate IrDA mode
From: Daniel Mack @ 2020-05-29 5:50 UTC (permalink / raw)
To: devicetree, linux-serial
Cc: gregkh, robh+dt, jslaby, jringle, m.brock, pascal.huerst,
Daniel Mack, Rob Herring
In-Reply-To: <20200529055058.1606910-1-daniel@zonque.org>
From: Pascal Huerst <pascal.huerst@gmail.com>
This series of uart controllers is able to work in IrDA mode.
This adds a property to the device tree to enable that feature on
selected ports if needed.
Signed-off-by: Pascal Huerst <pascal.huerst@gmail.com>
Signed-off-by: Daniel Mack <daniel@zonque.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt
index c1091a923a89..0fa8e3e43bf8 100644
--- a/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt
+++ b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt
@@ -21,6 +21,8 @@ Optional properties:
the second cell is used to specify the GPIO polarity:
0 = active high,
1 = active low.
+- irda-mode-ports: An array that lists the indices of the port that
+ should operate in IrDA mode.
Example:
sc16is750: sc16is750@51 {
@@ -55,6 +57,8 @@ Optional properties:
the second cell is used to specify the GPIO polarity:
0 = active high,
1 = active low.
+- irda-mode-ports: An array that lists the indices of the port that
+ should operate in IrDA mode.
Example:
sc16is750: sc16is750@0 {
--
2.26.2
^ permalink raw reply related
* [PATCH v4 2/2] sc16is7xx: Add flag to activate IrDA mode
From: Daniel Mack @ 2020-05-29 5:50 UTC (permalink / raw)
To: devicetree, linux-serial
Cc: gregkh, robh+dt, jslaby, jringle, m.brock, pascal.huerst,
Daniel Mack
In-Reply-To: <20200529055058.1606910-1-daniel@zonque.org>
From: Pascal Huerst <pascal.huerst@gmail.com>
This series of uart controllers is able to work in IrDA mode.
Add per-port flag to the device-tree to enable that feature if needed.
Signed-off-by: Pascal Huerst <pascal.huerst@gmail.com>
Signed-off-by: Daniel Mack <daniel@zonque.org>
---
drivers/tty/serial/sc16is7xx.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c
index 56508e63f9a0..deb55e2ad169 100644
--- a/drivers/tty/serial/sc16is7xx.c
+++ b/drivers/tty/serial/sc16is7xx.c
@@ -315,6 +315,7 @@ struct sc16is7xx_one {
struct kthread_work tx_work;
struct kthread_work reg_work;
struct sc16is7xx_one_config config;
+ bool irda_mode;
};
struct sc16is7xx_port {
@@ -986,6 +987,7 @@ static int sc16is7xx_config_rs485(struct uart_port *port,
static int sc16is7xx_startup(struct uart_port *port)
{
+ struct sc16is7xx_one *one = to_sc16is7xx_one(port, port);
struct sc16is7xx_port *s = dev_get_drvdata(port->dev);
unsigned int val;
@@ -1024,6 +1026,13 @@ static int sc16is7xx_startup(struct uart_port *port)
/* Now, initialize the UART */
sc16is7xx_port_write(port, SC16IS7XX_LCR_REG, SC16IS7XX_LCR_WORD_LEN_8);
+ /* Enable IrDA mode if requested in DT */
+ /* This bit must be written with LCR[7] = 0 */
+ sc16is7xx_port_update(port, SC16IS7XX_MCR_REG,
+ SC16IS7XX_MCR_IRDA_BIT,
+ one->irda_mode ?
+ SC16IS7XX_MCR_IRDA_BIT : 0);
+
/* Enable the Rx and Tx FIFO */
sc16is7xx_port_update(port, SC16IS7XX_EFCR_REG,
SC16IS7XX_EFCR_RXDISABLE_BIT |
@@ -1304,6 +1313,17 @@ static int sc16is7xx_probe(struct device *dev,
sc16is7xx_power(&s->p[i].port, 0);
}
+ if (dev->of_node) {
+ struct property *prop;
+ const __be32 *p;
+ u32 u;
+
+ of_property_for_each_u32(dev->of_node, "irda-mode-ports",
+ prop, p, u)
+ if (u < devtype->nr_uart)
+ s->p[u].irda_mode = true;
+ }
+
/*
* Setup interrupt. We first try to acquire the IRQ line as level IRQ.
* If that succeeds, we can allow sharing the interrupt as well.
--
2.26.2
^ permalink raw reply related
* [PATCH v4 0/2] sc16is7xx: IrDA mode and threaded IRQs
From: Daniel Mack @ 2020-05-29 5:50 UTC (permalink / raw)
To: devicetree, linux-serial
Cc: gregkh, robh+dt, jslaby, jringle, m.brock, pascal.huerst,
Daniel Mack
This is a resend of the first two patches of the series to bring IrDA
support to the sc16is7xx driver.
The "linux," prefix is now dropped from the DT property.
The patches are rebased on top of the other 4 that have already been
merged.
Pascal Huerst (2):
dt-bindings: sc16is7xx: Add flag to activate IrDA mode
sc16is7xx: Add flag to activate IrDA mode
.../bindings/serial/nxp,sc16is7xx.txt | 4 ++++
drivers/tty/serial/sc16is7xx.c | 20 +++++++++++++++++++
2 files changed, 24 insertions(+)
--
2.26.2
^ permalink raw reply
* Re: [PATCH] usb/phy-generic: Add support for OTG VBUS supply control
From: Mike Looijmans @ 2020-05-29 5:47 UTC (permalink / raw)
To: Peter Chen
Cc: linux-usb@vger.kernel.org, gregkh@linuxfoundation.org,
robh+dt@kernel.org, balbi@kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20200528112051.GB2604@b29397-desktop>
Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands
T: +31 (0) 499 33 69 69
E: mike.looijmans@topicproducts.com
W: www.topicproducts.com
Please consider the environment before printing this e-mail
On 28-05-2020 13:20, Peter Chen wrote:
> On 20-05-26 16:50:51, Mike Looijmans wrote:
>> This enables support for VBUS on boards where the power is supplied
>> by a regulator. The regulator is enabled when the USB port enters
>> HOST mode.
>>
> Why you don't do this at your host controller driver?
That was my first thought too, but it made more sense to do it here.
It's about how things are connected on the board, and not about the
controller. Also makes for a consistent devicetree when using different
SOCs on the same carrier board.
I already needed this driver to properly reset the USB phy, which the
controller driver also did not do. So it made sense to add the vbus
power control to this driver too.
If you have a strong preference for the controller driver, I can move
this to the DWC3 driver which happens to be the controller for the
latest batch of SOMs.
>
> Peter
>> Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
>> ---
>> .../devicetree/bindings/usb/usb-nop-xceiv.txt | 3 ++
>> drivers/usb/phy/phy-generic.c | 44 ++++++++++++++++++-
>> drivers/usb/phy/phy-generic.h | 2 +
>> 3 files changed, 48 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>> index 4dc6a8ee3071..775a19fdb613 100644
>> --- a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>> +++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>> @@ -16,6 +16,9 @@ Optional properties:
>>
>> - vcc-supply: phandle to the regulator that provides power to the PHY.
>>
>> +- vbus-supply: phandle to the regulator that provides the VBUS power for when
>> + the device is in HOST mode.
>> +
>> - reset-gpios: Should specify the GPIO for reset.
>>
>> - vbus-detect-gpio: should specify the GPIO detecting a VBus insertion
>> diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
>> index 661a229c105d..ebfb90764511 100644
>> --- a/drivers/usb/phy/phy-generic.c
>> +++ b/drivers/usb/phy/phy-generic.c
>> @@ -203,13 +203,43 @@ static int nop_set_host(struct usb_otg *otg, struct usb_bus *host)
>> return 0;
>> }
>>
>> +static int nop_set_vbus(struct usb_otg *otg, bool enabled)
>> +{
>> + struct usb_phy_generic *nop;
>> + int ret;
>> +
>> + if (!otg)
>> + return -ENODEV;
>> +
>> + nop = container_of(otg->usb_phy, struct usb_phy_generic, phy);
>> +
>> + if (!nop->vbus_reg)
>> + return 0;
>> +
>> + if (enabled) {
>> + if (nop->vbus_reg_enabled)
>> + return 0;
>> + ret = regulator_enable(nop->vbus_reg);
>> + if (ret < 0)
>> + return ret;
>> + nop->vbus_reg_enabled = true;
>> + } else {
>> + if (!nop->vbus_reg_enabled)
>> + return 0;
>> + ret = regulator_disable(nop->vbus_reg);
>> + if (ret < 0)
>> + return ret;
>> + nop->vbus_reg_enabled = false;
>> + }
There's a "return 0" missing here, will fix that in v2
>> +}
>> +
>> int usb_phy_gen_create_phy(struct device *dev, struct usb_phy_generic *nop)
>> {
>> enum usb_phy_type type = USB_PHY_TYPE_USB2;
>> int err = 0;
>>
>> u32 clk_rate = 0;
>> - bool needs_vcc = false, needs_clk = false;
>> + bool needs_vcc = false, needs_clk = false, needs_vbus = false;
>>
>> if (dev->of_node) {
>> struct device_node *node = dev->of_node;
>> @@ -219,6 +249,7 @@ int usb_phy_gen_create_phy(struct device *dev, struct usb_phy_generic *nop)
>>
>> needs_vcc = of_property_read_bool(node, "vcc-supply");
>> needs_clk = of_property_read_bool(node, "clocks");
>> + needs_vbus = of_property_read_bool(node, "vbus-supply");
>> }
>> nop->gpiod_reset = devm_gpiod_get_optional(dev, "reset",
>> GPIOD_ASIS);
>> @@ -268,6 +299,16 @@ int usb_phy_gen_create_phy(struct device *dev, struct usb_phy_generic *nop)
>> return -EPROBE_DEFER;
>> }
>>
>> + nop->vbus_reg = devm_regulator_get(dev, "vbus");
>> + if (IS_ERR(nop->vbus_reg)) {
>> + dev_dbg(dev, "Error getting vbus regulator: %ld\n",
>> + PTR_ERR(nop->vbus_reg));
>> + if (needs_vbus)
>> + return -EPROBE_DEFER;
>> +
>> + nop->vbus_reg = NULL;
>> + }
>> +
>> nop->dev = dev;
>> nop->phy.dev = nop->dev;
>> nop->phy.label = "nop-xceiv";
>> @@ -278,6 +319,7 @@ int usb_phy_gen_create_phy(struct device *dev, struct usb_phy_generic *nop)
>> nop->phy.otg->usb_phy = &nop->phy;
>> nop->phy.otg->set_host = nop_set_host;
>> nop->phy.otg->set_peripheral = nop_set_peripheral;
>> + nop->phy.otg->set_vbus = nop_set_vbus;
>>
>> return 0;
>> }
>> diff --git a/drivers/usb/phy/phy-generic.h b/drivers/usb/phy/phy-generic.h
>> index 7ee80211a688..a3663639ea1e 100644
>> --- a/drivers/usb/phy/phy-generic.h
>> +++ b/drivers/usb/phy/phy-generic.h
>> @@ -14,7 +14,9 @@ struct usb_phy_generic {
>> struct gpio_desc *gpiod_reset;
>> struct gpio_desc *gpiod_vbus;
>> struct regulator *vbus_draw;
>> + struct regulator *vbus_reg;
>> bool vbus_draw_enabled;
>> + bool vbus_reg_enabled;
>> unsigned long mA;
>> unsigned int vbus;
>> };
>> --
>> 2.17.1
>>
--
Mike Looijmans
^ permalink raw reply
* Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
From: Jassi Brar @ 2020-05-29 5:20 UTC (permalink / raw)
To: Rob Herring
Cc: Viresh Kumar, Arnd Bergmann, Frank Rowand, Bjorn Andersson,
Vincent Guittot, linux-arm-kernel, Sudeep Holla, Devicetree List,
Linux Kernel Mailing List
In-Reply-To: <20200528192005.GA494874@bogus>
On Thu, May 28, 2020 at 2:20 PM Rob Herring <robh@kernel.org> wrote:
>
> On Fri, May 15, 2020 at 10:47:38AM +0530, Viresh Kumar wrote:
> > From: Sudeep Holla <sudeep.holla@arm.com>
> >
> > Hi Rob, Arnd and Jassi,
> >
> > This stuff has been doing rounds on the mailing list since several years
> > now with no agreed conclusion by all the parties. And here is another
> > attempt to get some feedback from everyone involved to close this once
> > and for ever. Your comments will very much be appreciated.
> >
> > The ARM MHU is defined here in the TRM [1] for your reference, which
> > states following:
> >
> > "The MHU drives the signal using a 32-bit register, with all 32
> > bits logically ORed together. The MHU provides a set of
> > registers to enable software to set, clear, and check the status
> > of each of the bits of this register independently. The use of
> > 32 bits for each interrupt line enables software to provide more
> > information about the source of the interrupt. For example, each
> > bit of the register can be associated with a type of event that
> > can contribute to raising the interrupt."
> >
> > On few other platforms, like qcom, similar doorbell mechanism is present
> > with separate interrupt for each of the bits (that's how I understood
> > it), while in case of ARM MHU, there is a single interrupt line for all
> > the 32 bits. Also in case of ARM MHU, these registers and interrupts
> > have 3 copies for different priority levels, i.e. low priority
> > non-secure, high priority non-secure and secure channels.
> >
> > For ARM MHU, both the dt bindings and the Linux driver support 3
> > channels for the different priorities right now and support sending a 32
> > bit data on every transfer in a locked fashion, i.e. only one transfer
> > can be done at once and the other have to wait for it to finish first.
> >
> > Here are the point of view of the parties involved on this subject:
> >
> > Jassi's viewpoint:
> >
> > - Virtualization of channels should be discouraged in software based on
> > specific usecases of the application. This may invite other mailbox
> > driver authors to ask for doing virtualization in their drivers.
> >
> > - In mailbox's terminology, every channel is equivalent to a signal,
> > since there is only one signal generated here by the MHU, there should
> > be only one channel per priority level.
> >
> > - The clients should send data (of just setting 1 bit or many in the 32
> > bit word) using the existing mechanism as the delays due to
> > serialization shouldn't be significant anyway.
> >
> > - The driver supports 90% of the users with the current implementation
> > and it shouldn't be extended to support doorbell and implement two
> > different modes by changing value of #mbox-cells field in bindings.
> >
> > Sudeep (ARM) and myself as well to some extent:
> >
> > - The hardware gives us the capability to write the register in
> > parallel, i.e. we can write 0x800 and 0x400 together without any
> > software locks, and so these 32 bits should be considered as separate
> > channel even if only one interrupt is issued by the hardware finally.
> > This shouldn't be called as virtualization of the channels, as the
> > hardware supports this (as clearly mentioned in the TRM) and it takes
> > care of handling the signal properly.
> >
> > - With serialization, if we use only one channel as today at every
> > priority, if there are 5 requests to send signal to the receiver and
> > the dvfs request is the last one in queue (which may be called from
> > scheduler's hot path with fast switching), it unnecessarily needs to
> > wait for the first four transfers to finish due to the software
> > locking imposed by the mailbox framework. This adds additional delay,
> > maybe of few ms only, which isn't required by the hardware but just by
> > the software and few ms can be important in scheduler's hotpath.
> >
> > - With the current approach it isn't possible to assign different bits
> > (or doorbell numbers) to clients from DT and the only way of doing
> > that without adding new bindings is by extending #mbox-cells to accept
> > a value of 2 as done in this patch.
> >
> > Jassi and Sudeep, I hope I was able to represent both the view points
> > properly here. Please correct me if I have made a mistake here.
> >
> > This is it. It would be nice to get the views of everyone now on this
> > and how should this be handled.
>
> I am perfectly fine with adding another cell which seems appropriate
> here. You can have 5 cells for all I care if that makes sense for
> the h/w. That has nothing to do with the Linux design. Whether Linux
> requires serializing mailbox accesses is a separate issue. On that side,
> it seems silly to not allow driving the h/w in the most efficient way
> possible.
>
The fact that all these bits are backed by one physical signal makes
the firmware implement its own mux-demux'ing scheme. So the choice was
between demux and single signal at a time. Had there been one signal
per bit, the implementation would have definitely been 'efficient'.
And the first platform the driver was developed on, required message
passing over the registers. So now my approach is to make do with what
we have...unless it shows in numbers.
Anyways, if it comes to that, I'd rather a separate "doorbell' driver
than a driver working in two s/w modes.
Thanks.
^ permalink raw reply
* Re: [PATCH v8 04/10] OPP: Add support for parsing interconnect bandwidth
From: Viresh Kumar @ 2020-05-29 4:44 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:
> struct dev_pm_opp *_opp_allocate(struct opp_table *table)
> {
> struct dev_pm_opp *opp;
> - int count, supply_size;
> + int supply_count, supply_size, icc_size;
>
> /* Allocate space for at least one supply */
> - count = table->regulator_count > 0 ? table->regulator_count : 1;
> - supply_size = sizeof(*opp->supplies) * count;
> + supply_count = table->regulator_count > 0 ? table->regulator_count : 1;
> + supply_size = sizeof(*opp->supplies) * supply_count;
> + icc_size = sizeof(*opp->bandwidth) * table->path_count;
>
> /* allocate new OPP node and supplies structures */
> - opp = kzalloc(sizeof(*opp) + supply_size, GFP_KERNEL);
> + opp = kzalloc(sizeof(*opp) + supply_size + icc_size, GFP_KERNEL);
> +
> if (!opp)
> return NULL;
>
> /* Put the supplies at the end of the OPP structure as an empty array */
> opp->supplies = (struct dev_pm_opp_supply *)(opp + 1);
> + opp->bandwidth = (struct dev_pm_opp_icc_bw *)(opp->supplies + supply_count);
> INIT_LIST_HEAD(&opp->node);
Added this delta here.
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 7302f2631f8d..dfbd3d10410c 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -1330,7 +1330,8 @@ struct dev_pm_opp *_opp_allocate(struct opp_table *table)
/* Put the supplies at the end of the OPP structure as an empty array */
opp->supplies = (struct dev_pm_opp_supply *)(opp + 1);
- opp->bandwidth = (struct dev_pm_opp_icc_bw *)(opp->supplies + supply_count);
+ if (icc_size)
+ opp->bandwidth = (struct dev_pm_opp_icc_bw *)(opp->supplies + supply_count);
INIT_LIST_HEAD(&opp->node);
return opp;
--
viresh
^ permalink raw reply related
* Re: [PATCH 0/3] MIPS: Loongson64: Initial LS7A PCH support
From: Jiaxun Yang @ 2020-05-29 4:36 UTC (permalink / raw)
To: Huacai Chen
Cc: Marc Zyngier, Thomas Bogendoerfer, Rob Herring, open list:MIPS,
devicetree, LKML
In-Reply-To: <CAAhV-H5B+6drcEiz=JCexa0LC3JAPS0K5WZ0zwndvuKv-e9NRQ@mail.gmail.com>
于 2020年5月29日 GMT+08:00 下午12:13:36, Huacai Chen <chenhc@lemote.com> 写到:
>Hi, Jiaxun,
>
>On Fri, May 29, 2020 at 11:45 AM Jiaxun Yang <jiaxun.yang@flygoat.com> wrote:
>>
>> With this series, LS7A and Loongson-3A4000 is finally supported
>> note that this series should depend on irqchip support[1], which
>> is likely to get merged soon.
>>
>> Thanks.
>>
>> [1]: https://lkml.org/lkml/2020/5/16/72
>>
>> Jiaxun Yang (3):
>> dt-bindings: mips: Document two Loongson generic boards
>> MIPS: Loongson64: DeviceTree for LS7A PCH
>> MIPS: Loongson64:Load LS7A dtbs
>>
>> .../bindings/mips/loongson/devices.yaml | 8 +
>> arch/mips/boot/dts/loongson/Makefile | 5 +-
>> .../dts/loongson/loongson3-r4-package.dtsi | 74 +++++++
>> .../dts/loongson/loongson3_4core_ls7a.dts | 25 +++
>> .../boot/dts/loongson/loongson3_r4_ls7a.dts | 10 +
>> arch/mips/boot/dts/loongson/ls7a-pch.dtsi | 185 ++++++++++++++++++
>> .../asm/mach-loongson64/builtin_dtbs.h | 2 +
>> arch/mips/loongson64/env.c | 56 +++---
>> 8 files changed, 342 insertions(+), 23 deletions(-)
>> create mode 100644 arch/mips/boot/dts/loongson/loongson3-r4-package.dtsi
>> create mode 100644 arch/mips/boot/dts/loongson/loongson3_4core_ls7a.dts
>> create mode 100644 arch/mips/boot/dts/loongson/loongson3_r4_ls7a.dts
>> create mode 100644 arch/mips/boot/dts/loongson/ls7a-pch.dtsi
>I think the naming can be like this: Old processor (Loongson 3A R1~R3)
>use loongson64c_ prefix instead of loongson3, new processor (Loongson
>3A R4) use loongson64g_ prefix instead of loongson3_r4, and
>Loongson-2K use loongson64r_ prefix, this makes them consistent with
>their PRID definitions.
DeviceTree bindings have stable ABI. Although they're currently
only used internally in Kernel. I don't think it's a good idea
to rename existing bindings.
Also, Loongson64C/64G/64R never came to a part of Loongson's
official naming. I doubt if end users will recognize these names.
I'd prefer keep naming as is. It's really not a big deal.
Thanks.
>
>>
>> --
>> 2.27.0.rc0
>>
--
Jiaxun Yang
^ permalink raw reply
* Re: [PATCH V2 1/3] clk: vc5: Allow Versaclock driver to support multiple instances
From: Stephen Boyd @ 2020-05-29 4:29 UTC (permalink / raw)
To: Adam Ford, linux-clk
Cc: aford, charles.stevens, Adam Ford, Michael Turquette, Rob Herring,
Marek Vasut, devicetree, linux-kernel
In-Reply-To: <20200502122126.188001-1-aford173@gmail.com>
Quoting Adam Ford (2020-05-02 05:21:24)
> diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c
> index fa96659f8023..81255d923f00 100644
> --- a/drivers/clk/clk-versaclock5.c
> +++ b/drivers/clk/clk-versaclock5.c
> @@ -881,6 +871,8 @@ static int vc5_probe(struct i2c_client *client,
> goto err_clk;
> }
>
> + dev_info(&client->dev, "probed");
> +
Please remove this.
> return 0;
>
> err_clk:
^ permalink raw reply
* Re: [PATCH 5/5] clk: mediatek: Add MT6765 clock support
From: Stephen Boyd @ 2020-05-29 4:24 UTC (permalink / raw)
To: Catalin Marinas, Chunfeng Yun, Evan Green, Fabien Parent,
Joerg Roedel, Macpaul Lin, Marc Zyngier, Mark Rutland, Mars Cheng,
Matthias Brugger, Michael Turquette, Owen Chen, Rob Herring,
Ryder Lee, Sean Wang, Shawn Guo, Weiyi Lu, Will Deacon, Yong Wu,
devicetree, linux-arm-kernel, linux-clk, linux-kernel,
linux-mediatek, mtk01761
Cc: Mediatek WSD Upstream, CC Hwang, Loda Chou
In-Reply-To: <1582278742-1626-6-git-send-email-macpaul.lin@mediatek.com>
Quoting Macpaul Lin (2020-02-21 01:52:22)
> From: Owen Chen <owen.chen@mediatek.com>
>
> Add MT6765 clock support, include topckgen, apmixedsys,
> infracfg, mcucfg and subsystem clocks.
>
> Signed-off-by: Owen Chen <owen.chen@mediatek.com>
> Signed-off-by: Mars Cheng <mars.cheng@mediatek.com>
> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
> ---
Applied to clk-next
^ permalink raw reply
* Re: [PATCH 4/5] clk: mediatek: add mt6765 clock IDs
From: Stephen Boyd @ 2020-05-29 4:24 UTC (permalink / raw)
To: Catalin Marinas, Chunfeng Yun, Evan Green, Fabien Parent,
Joerg Roedel, Macpaul Lin, Marc Zyngier, Mark Rutland, Mars Cheng,
Matthias Brugger, Michael Turquette, Owen Chen, Rob Herring,
Ryder Lee, Sean Wang, Shawn Guo, Weiyi Lu, Will Deacon, Yong Wu,
devicetree, linux-arm-kernel, linux-clk, linux-kernel,
linux-mediatek, mtk01761
Cc: Mediatek WSD Upstream, CC Hwang, Loda Chou
In-Reply-To: <1582278742-1626-5-git-send-email-macpaul.lin@mediatek.com>
Quoting Macpaul Lin (2020-02-21 01:52:21)
> From: Mars Cheng <mars.cheng@mediatek.com>
>
> Add MT6765 clock dt-bindings, include topckgen, apmixedsys,
> infracfg, mcucfg and subsystem clocks.
>
> Signed-off-by: Mars Cheng <mars.cheng@mediatek.com>
> Signed-off-by: Owen Chen <owen.chen@mediatek.com>
> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
Applied to clk-next
^ 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