* Re: [PATCH v3 6/6] MAINTAINERS: Add maintainers for MIPS core drivers
From: Marc Zyngier @ 2020-06-02 10:12 UTC (permalink / raw)
To: Serge Semin
Cc: Thomas Bogendoerfer, Thomas Gleixner, Greg Kroah-Hartman,
Serge Semin, Alexey Malahov, Paul Burton, Rob Herring,
Arnd Bergmann, Jason Cooper, Rafael J. Wysocki, Daniel Lezcano,
James Hogan, linux-mips, devicetree, linux-kernel
In-Reply-To: <20200602100921.1155-7-Sergey.Semin@baikalelectronics.ru>
On 2020-06-02 11:09, Serge Semin wrote:
> Add Thomas and myself as maintainers of the MIPS CPU and GIC IRQchip,
> MIPS
> GIC timer and MIPS CPS CPUidle drivers.
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
>
> ---
>
> Changelog v3:
> - Keep the files list alphabetically ordered.
> - Add Thomas as the co-maintainer of the designated drivers.
> ---
> MAINTAINERS | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2926327e4976..20532e0287d7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11278,6 +11278,17 @@
> F: arch/mips/configs/generic/board-boston.config
> F: drivers/clk/imgtec/clk-boston.c
> F: include/dt-bindings/clock/boston-clock.h
>
> +MIPS CORE DRIVERS
> +M: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> +M: Serge Semin <fancer.lancer@gmail.com>
> +L: linux-mips@vger.kernel.org
> +S: Supported
> +F: drivers/bus/mips_cdmm.c
> +F: drivers/clocksource/mips-gic-timer.c
> +F: drivers/cpuidle/cpuidle-cps.c
> +F: drivers/irqchip/irq-mips-cpu.c
> +F: drivers/irqchip/irq-mips-gic.c
> +
> MIPS GENERIC PLATFORM
> M: Paul Burton <paulburton@kernel.org>
> L: linux-mips@vger.kernel.org
Acked-by: Marc Zyngier <maz@kernel.org>
I assume this will go via the MIPS tree.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v3 3/6] dt-bindings: bus: Add MIPS CDMM controller
From: Serge Semin @ 2020-06-02 10:09 UTC (permalink / raw)
To: Thomas Bogendoerfer, Thomas Gleixner, Greg Kroah-Hartman,
Rob Herring
Cc: Serge Semin, Serge Semin, Alexey Malahov, Paul Burton,
Arnd Bergmann, Jason Cooper, Marc Zyngier, Rafael J. Wysocki,
Daniel Lezcano, James Hogan, linux-mips, devicetree, linux-kernel,
Rob Herring
In-Reply-To: <20200602100921.1155-1-Sergey.Semin@baikalelectronics.ru>
It's a Common Device Memory Map controller embedded into the MIPS IP
cores, which dts node is supposed to have compatible and reg properties.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changelog prev:
- Lowercase the example hex'es.
---
.../bindings/bus/mti,mips-cdmm.yaml | 35 +++++++++++++++++++
1 file changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/bus/mti,mips-cdmm.yaml
diff --git a/Documentation/devicetree/bindings/bus/mti,mips-cdmm.yaml b/Documentation/devicetree/bindings/bus/mti,mips-cdmm.yaml
new file mode 100644
index 000000000000..b3ba98515cbe
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/mti,mips-cdmm.yaml
@@ -0,0 +1,35 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bus/mti,mips-cdmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MIPS Common Device Memory Map
+
+description: |
+ Defines a location of the MIPS Common Device Memory Map registers.
+
+maintainers:
+ - James Hogan <jhogan@kernel.org>
+
+properties:
+ compatible:
+ const: mti,mips-cdmm
+
+ reg:
+ description: |
+ Base address and size of an unoccupied memory region, which will be
+ used to map the MIPS CDMM registers block.
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ cdmm@1bde8000 {
+ compatible = "mti,mips-cdmm";
+ reg = <0 0x1bde8000 0 0x8000>;
+ };
+...
--
2.26.2
^ permalink raw reply related
* [PATCH v3 0/6] mips: Add DT bindings for MIPS CDMM and MIPS GIC
From: Serge Semin @ 2020-06-02 10:09 UTC (permalink / raw)
To: Thomas Bogendoerfer, Thomas Gleixner, Greg Kroah-Hartman
Cc: Serge Semin, Serge Semin, Alexey Malahov, Paul Burton,
Rob Herring, Arnd Bergmann, Jason Cooper, Marc Zyngier,
Rafael J. Wysocki, Daniel Lezcano, James Hogan, linux-mips,
devicetree, linux-kernel
Folks, the code and DT-related patches here have been mostly reviewed.
Please consider merge the series in or at least give me a feedback to
update the series, since merge window is getting opened and I would
really appreciate to see the leftover being merged in.
Regarding this patchset origin. Recently I've submitted a series of
patchset's which provided multiple fixes for the MIPS arch subsystem and
the MIPS GIC and DW APB Timer drivers, which were required for the
Baikal-T1 SoC correctly working with those drivers. Mostly those patchsets
have been already merged into the corresponding subsystems, but several
patches have been left floating since noone really responded for review
except Rob provided his approval regarding DT bindings. Thus in this
patchset I've collected all the leftovers so not to loose them in a pale
of the maintainers email logs.
The patchset includes the following updates: MIPS CPC and GIC DT bindings
legacy text-based file are converted to the DT schema (Rob has already
reviewed them), add MIPS CDMM DT node support to place the CDMM block at
the platform-specific MMIO range, make sure MIPS CDMM is available for
MIPS_R5 CPUs.
Seeing the series concerns the MIPS-related drivers it's better to merge
it in through the MIPS repository:
https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/
This patchset is rebased and tested on the mainline Linux kernel 5.7-rc4:
base-commit: 0e698dfa2822 ("Linux 5.7-rc4")
tag: v5.7-rc4
Suggestion.
Since Paul isn't looking after the MIPS arch code anymore, Ralf hasn't
been seen maintaining MIPS for a long time, Thomas is only responsible
for the next part of it:
F: Documentation/devicetree/bindings/mips/
F: Documentation/mips/
F: arch/mips/
F: drivers/platform/mips/
the MIPS-specific drivers like:
F: drivers/bus/mips_cdmm.c
F: drivers/irqchip/irq-mips-cpu.c
F: drivers/irqchip/irq-mips-gic.c
F: drivers/clocksource/mips-gic-timer.c
F: drivers/cpuidle/cpuidle-cps.c
seem to be left for the subsystems maintainers to support. So if you don't
mind or unless there is a better alternative, I can help with looking
after them to ease the maintainers review burden and since I'll be working
on our MIPS-based SoC drivers integrating into the mainline kernel repo
anyway. If you don't like this idea, please just decline the last
patch in the series.
Previous patchsets:
mips: Prepare MIPS-arch code for Baikal-T1 SoC support:
Link: https://lore.kernel.org/linux-mips/20200306124807.3596F80307C2@mail.baikalelectronics.ru
Link: https://lore.kernel.org/linux-mips/20200506174238.15385-1-Sergey.Semin@baikalelectronics.ru
Link: https://lore.kernel.org/linux-mips/20200521140725.29571-1-Sergey.Semin@baikalelectronics.ru
clocksource: Fix MIPS GIC and DW APB Timer for Baikal-T1 SoC support:
Link: https://lore.kernel.org/linux-rtc/20200324174325.14213-1-Sergey.Semin@baikalelectronics.ru
Link: https://lore.kernel.org/linux-rtc/20200506214107.25956-1-Sergey.Semin@baikalelectronics.ru
Link: https://lore.kernel.org/linux-rtc/20200521005321.12129-1-Sergey.Semin@baikalelectronics.ru
Changelog prev:
- Add yaml-based bindings file for MIPS CDMM dt-node.
- Convert mti,mips-cpc to DT schema.
- Use a shorter summary describing the bindings modification patches.
- Rearrange the SoBs with adding Alexey' co-development tag.
- Lowercase the hex numbers in the dt-bindings.
Changelog v2:
- Resend.
Link: https://lore.kernel.org/linux-mips/20200601122121.15809-1-Sergey.Semin@baikalelectronics.ru
Changelog v3:
- Keep F: MAINTAINERS section alphabetically ordered.
- Add Thomas as the co-maintainer of the MIPS CPU and GIC IRQchip, MIPS
GIC timer and MIPS CPS CPUidle drivers.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Marc Zyngier <maz@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Serge Semin (6):
dt-bindings: power: Convert mti,mips-cpc to DT schema
dt-bindings: interrupt-controller: Convert mti,gic to DT schema
dt-bindings: bus: Add MIPS CDMM controller
mips: cdmm: Add mti,mips-cdmm dtb node support
bus: cdmm: Add MIPS R5 arch support
MAINTAINERS: Add maintainers for MIPS core drivers
.../bindings/bus/mti,mips-cdmm.yaml | 35 +++++
.../interrupt-controller/mips-gic.txt | 67 --------
.../interrupt-controller/mti,gic.yaml | 148 ++++++++++++++++++
.../bindings/power/mti,mips-cpc.txt | 8 -
.../bindings/power/mti,mips-cpc.yaml | 35 +++++
MAINTAINERS | 11 ++
drivers/bus/Kconfig | 2 +-
drivers/bus/mips_cdmm.c | 15 ++
8 files changed, 245 insertions(+), 76 deletions(-)
create mode 100644 Documentation/devicetree/bindings/bus/mti,mips-cdmm.yaml
delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/mips-gic.txt
create mode 100644 Documentation/devicetree/bindings/interrupt-controller/mti,gic.yaml
delete mode 100644 Documentation/devicetree/bindings/power/mti,mips-cpc.txt
create mode 100644 Documentation/devicetree/bindings/power/mti,mips-cpc.yaml
--
2.26.2
^ permalink raw reply
* [PATCH v3 1/6] dt-bindings: power: Convert mti,mips-cpc to DT schema
From: Serge Semin @ 2020-06-02 10:09 UTC (permalink / raw)
To: Thomas Bogendoerfer, Thomas Gleixner, Greg Kroah-Hartman,
Paul Burton, Rob Herring
Cc: Serge Semin, Serge Semin, Alexey Malahov, Paul Burton,
Arnd Bergmann, Jason Cooper, Marc Zyngier, Rafael J. Wysocki,
Daniel Lezcano, James Hogan, linux-mips, devicetree, linux-kernel,
Rob Herring
In-Reply-To: <20200602100921.1155-1-Sergey.Semin@baikalelectronics.ru>
It's a Cluster Power Controller embedded into the MIPS IP cores.
Currently the corresponding dts node is supposed to have compatible
and reg properties.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changelog prev:
- Reword the changelog summary - use shorter version.
- Lowercase the example hex'es.
---
.../bindings/power/mti,mips-cpc.txt | 8 -----
.../bindings/power/mti,mips-cpc.yaml | 35 +++++++++++++++++++
2 files changed, 35 insertions(+), 8 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/power/mti,mips-cpc.txt
create mode 100644 Documentation/devicetree/bindings/power/mti,mips-cpc.yaml
diff --git a/Documentation/devicetree/bindings/power/mti,mips-cpc.txt b/Documentation/devicetree/bindings/power/mti,mips-cpc.txt
deleted file mode 100644
index c6b82511ae8a..000000000000
--- a/Documentation/devicetree/bindings/power/mti,mips-cpc.txt
+++ /dev/null
@@ -1,8 +0,0 @@
-Binding for MIPS Cluster Power Controller (CPC).
-
-This binding allows a system to specify where the CPC registers are
-located.
-
-Required properties:
-compatible : Should be "mti,mips-cpc".
-regs: Should describe the address & size of the CPC register region.
diff --git a/Documentation/devicetree/bindings/power/mti,mips-cpc.yaml b/Documentation/devicetree/bindings/power/mti,mips-cpc.yaml
new file mode 100644
index 000000000000..9cd92a57130c
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/mti,mips-cpc.yaml
@@ -0,0 +1,35 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/mti,mips-cpc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MIPS Cluster Power Controller
+
+description: |
+ Defines a location of the MIPS Cluster Power Controller registers.
+
+maintainers:
+ - Paul Burton <paulburton@kernel.org>
+
+properties:
+ compatible:
+ const: mti,mips-cpc
+
+ reg:
+ description: |
+ Base address and size of an unoccupied memory region, which will be
+ used to map the MIPS CPC registers block.
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ cpc@1bde0000 {
+ compatible = "mti,mips-cpc";
+ reg = <0 0x1bde0000 0 0x8000>;
+ };
+...
--
2.26.2
^ permalink raw reply related
* [PATCH v3 4/6] mips: cdmm: Add mti,mips-cdmm dtb node support
From: Serge Semin @ 2020-06-02 10:09 UTC (permalink / raw)
To: Thomas Bogendoerfer, Thomas Gleixner, Greg Kroah-Hartman,
Serge Semin
Cc: Serge Semin, Alexey Malahov, Paul Burton, Rob Herring,
Arnd Bergmann, Jason Cooper, Marc Zyngier, Rafael J. Wysocki,
Daniel Lezcano, James Hogan, linux-mips, devicetree, linux-kernel
In-Reply-To: <20200602100921.1155-1-Sergey.Semin@baikalelectronics.ru>
Since having and mapping the CDMM block is platform specific, then
instead of just returning a zero-address, lets make the default CDMM
base address search method (mips_cdmm_phys_base()) to do something
useful. For instance to find the address in a dedicated dtb-node in
order to support of-based platforms by default.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
---
Changelog prev:
- Use alphabetical order for the include pre-processor operator.
---
drivers/bus/mips_cdmm.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/bus/mips_cdmm.c b/drivers/bus/mips_cdmm.c
index 1b14256376d2..9f7ed1fcd428 100644
--- a/drivers/bus/mips_cdmm.c
+++ b/drivers/bus/mips_cdmm.c
@@ -13,6 +13,8 @@
#include <linux/cpu.h>
#include <linux/cpumask.h>
#include <linux/io.h>
+#include <linux/of_address.h>
+#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
#include <linux/smp.h>
@@ -337,9 +339,22 @@ static phys_addr_t mips_cdmm_cur_base(void)
* Picking a suitable physical address at which to map the CDMM region is
* platform specific, so this weak function can be overridden by platform
* code to pick a suitable value if none is configured by the bootloader.
+ * By default this method tries to find a CDMM-specific node in the system
+ * dtb. Note that this won't work for early serial console.
*/
phys_addr_t __weak mips_cdmm_phys_base(void)
{
+ struct device_node *np;
+ struct resource res;
+ int err;
+
+ np = of_find_compatible_node(NULL, NULL, "mti,mips-cdmm");
+ if (np) {
+ err = of_address_to_resource(np, 0, &res);
+ if (!err)
+ return res.start;
+ }
+
return 0;
}
--
2.26.2
^ permalink raw reply related
* [PATCH v3 6/6] MAINTAINERS: Add maintainers for MIPS core drivers
From: Serge Semin @ 2020-06-02 10:09 UTC (permalink / raw)
To: Thomas Bogendoerfer, Thomas Gleixner, Greg Kroah-Hartman
Cc: Serge Semin, Serge Semin, Alexey Malahov, Paul Burton,
Rob Herring, Arnd Bergmann, Jason Cooper, Marc Zyngier,
Rafael J. Wysocki, Daniel Lezcano, James Hogan, linux-mips,
devicetree, linux-kernel
In-Reply-To: <20200602100921.1155-1-Sergey.Semin@baikalelectronics.ru>
Add Thomas and myself as maintainers of the MIPS CPU and GIC IRQchip, MIPS
GIC timer and MIPS CPS CPUidle drivers.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
---
Changelog v3:
- Keep the files list alphabetically ordered.
- Add Thomas as the co-maintainer of the designated drivers.
---
MAINTAINERS | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2926327e4976..20532e0287d7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11278,6 +11278,17 @@ F: arch/mips/configs/generic/board-boston.config
F: drivers/clk/imgtec/clk-boston.c
F: include/dt-bindings/clock/boston-clock.h
+MIPS CORE DRIVERS
+M: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+M: Serge Semin <fancer.lancer@gmail.com>
+L: linux-mips@vger.kernel.org
+S: Supported
+F: drivers/bus/mips_cdmm.c
+F: drivers/clocksource/mips-gic-timer.c
+F: drivers/cpuidle/cpuidle-cps.c
+F: drivers/irqchip/irq-mips-cpu.c
+F: drivers/irqchip/irq-mips-gic.c
+
MIPS GENERIC PLATFORM
M: Paul Burton <paulburton@kernel.org>
L: linux-mips@vger.kernel.org
--
2.26.2
^ permalink raw reply related
* [PATCH v3 2/6] dt-bindings: interrupt-controller: Convert mti,gic to DT schema
From: Serge Semin @ 2020-06-02 10:09 UTC (permalink / raw)
To: Thomas Bogendoerfer, Thomas Gleixner, Greg Kroah-Hartman,
Jason Cooper, Marc Zyngier, Rob Herring
Cc: Serge Semin, Serge Semin, Alexey Malahov, Paul Burton,
Arnd Bergmann, Rafael J. Wysocki, Daniel Lezcano, James Hogan,
linux-mips, devicetree, linux-kernel, Rob Herring
In-Reply-To: <20200602100921.1155-1-Sergey.Semin@baikalelectronics.ru>
Modern device tree bindings are supposed to be created as YAML-files
in accordance with DT schema. This commit replaces MIPS GIC legacy bare
text binding with YAML file. As before the binding file states that the
corresponding dts node is supposed to be compatible with MIPS Global
Interrupt Controller indicated by the "mti,gic" compatible string and
to provide a mandatory interrupt-controller and '#interrupt-cells'
properties. There might be optional registers memory range,
"mti,reserved-cpu-vectors" and "mti,reserved-ipi-vectors" properties
specified.
MIPS GIC also includes a free-running global timer, per-CPU count/compare
timers, and a watchdog. Since currently the GIC Timer is only supported the
DT schema expects an IRQ and clock-phandler charged timer sub-node with
"mti,mips-gic-timer" compatible string.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Rob Herring <robh@kernel.org>
---
I don't really know who is the corresponding driver maintainer, so I
added Paul to the maintainers property since he used to be looking for the
MIPS arch and Thomas looking after it now. Any idea what email should be
specified there instead?
Changelog prev:
- Since timer sub-node has no unit-address, the node shouldn't be named
with one. So alter the MIPS GIC bindings to have a pure "timer"
sub-node.
- Discard allOf: [ $ref: /schemas/interrupt-controller.yaml# ].
- Since it's a conversion patch use GPL-2.0-only SPDX header.
---
.../interrupt-controller/mips-gic.txt | 67 --------
.../interrupt-controller/mti,gic.yaml | 148 ++++++++++++++++++
2 files changed, 148 insertions(+), 67 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/mips-gic.txt
create mode 100644 Documentation/devicetree/bindings/interrupt-controller/mti,gic.yaml
diff --git a/Documentation/devicetree/bindings/interrupt-controller/mips-gic.txt b/Documentation/devicetree/bindings/interrupt-controller/mips-gic.txt
deleted file mode 100644
index 173595305e26..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/mips-gic.txt
+++ /dev/null
@@ -1,67 +0,0 @@
-MIPS Global Interrupt Controller (GIC)
-
-The MIPS GIC routes external interrupts to individual VPEs and IRQ pins.
-It also supports local (per-processor) interrupts and software-generated
-interrupts which can be used as IPIs. The GIC also includes a free-running
-global timer, per-CPU count/compare timers, and a watchdog.
-
-Required properties:
-- compatible : Should be "mti,gic".
-- interrupt-controller : Identifies the node as an interrupt controller
-- #interrupt-cells : Specifies the number of cells needed to encode an
- interrupt specifier. Should be 3.
- - The first cell is the type of interrupt, local or shared.
- See <include/dt-bindings/interrupt-controller/mips-gic.h>.
- - The second cell is the GIC interrupt number.
- - The third cell encodes the interrupt flags.
- See <include/dt-bindings/interrupt-controller/irq.h> for a list of valid
- flags.
-
-Optional properties:
-- reg : Base address and length of the GIC registers. If not present,
- the base address reported by the hardware GCR_GIC_BASE will be used.
-- mti,reserved-cpu-vectors : Specifies the list of CPU interrupt vectors
- to which the GIC may not route interrupts. Valid values are 2 - 7.
- This property is ignored if the CPU is started in EIC mode.
-- mti,reserved-ipi-vectors : Specifies the range of GIC interrupts that are
- reserved for IPIs.
- It accepts 2 values, the 1st is the starting interrupt and the 2nd is the size
- of the reserved range.
- If not specified, the driver will allocate the last 2 * number of VPEs in the
- system.
-
-Required properties for timer sub-node:
-- compatible : Should be "mti,gic-timer".
-- interrupts : Interrupt for the GIC local timer.
-
-Optional properties for timer sub-node:
-- clocks : GIC timer operating clock.
-- clock-frequency : Clock frequency at which the GIC timers operate.
-
-Note that one of clocks or clock-frequency must be specified.
-
-Example:
-
- gic: interrupt-controller@1bdc0000 {
- compatible = "mti,gic";
- reg = <0x1bdc0000 0x20000>;
-
- interrupt-controller;
- #interrupt-cells = <3>;
-
- mti,reserved-cpu-vectors = <7>;
- mti,reserved-ipi-vectors = <40 8>;
-
- timer {
- compatible = "mti,gic-timer";
- interrupts = <GIC_LOCAL 1 IRQ_TYPE_NONE>;
- clock-frequency = <50000000>;
- };
- };
-
- uart@18101400 {
- ...
- interrupt-parent = <&gic>;
- interrupts = <GIC_SHARED 24 IRQ_TYPE_LEVEL_HIGH>;
- ...
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/mti,gic.yaml b/Documentation/devicetree/bindings/interrupt-controller/mti,gic.yaml
new file mode 100644
index 000000000000..9f0eb3addac4
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/mti,gic.yaml
@@ -0,0 +1,148 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/mti,gic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MIPS Global Interrupt Controller
+
+maintainers:
+ - Paul Burton <paulburton@kernel.org>
+ - Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+
+description: |
+ The MIPS GIC routes external interrupts to individual VPEs and IRQ pins.
+ It also supports local (per-processor) interrupts and software-generated
+ interrupts which can be used as IPIs. The GIC also includes a free-running
+ global timer, per-CPU count/compare timers, and a watchdog.
+
+properties:
+ compatible:
+ const: mti,gic
+
+ "#interrupt-cells":
+ const: 3
+ description: |
+ The 1st cell is the type of interrupt: local or shared defined in the
+ file 'dt-bindings/interrupt-controller/mips-gic.h'. The 2nd cell is the
+ GIC interrupt number. The 3d cell encodes the interrupt flags setting up
+ the IRQ trigger modes, which are defined in the file
+ 'dt-bindings/interrupt-controller/irq.h'.
+
+ reg:
+ description: |
+ Base address and length of the GIC registers space. If not present,
+ the base address reported by the hardware GCR_GIC_BASE will be used.
+ maxItems: 1
+
+ interrupt-controller: true
+
+ mti,reserved-cpu-vectors:
+ description: |
+ Specifies the list of CPU interrupt vectors to which the GIC may not
+ route interrupts. This property is ignored if the CPU is started in EIC
+ mode.
+ allOf:
+ - $ref: /schemas/types.yaml#definitions/uint32-array
+ - minItems: 1
+ maxItems: 6
+ uniqueItems: true
+ items:
+ minimum: 2
+ maximum: 7
+
+ mti,reserved-ipi-vectors:
+ description: |
+ Specifies the range of GIC interrupts that are reserved for IPIs.
+ It accepts two values: the 1st is the starting interrupt and the 2nd is
+ the size of the reserved range. If not specified, the driver will
+ allocate the last (2 * number of VPEs in the system).
+ allOf:
+ - $ref: /schemas/types.yaml#definitions/uint32-array
+ - items:
+ - minimum: 0
+ maximum: 254
+ - minimum: 2
+ maximum: 254
+
+ timer:
+ type: object
+ description: |
+ MIPS GIC includes a free-running global timer, per-CPU count/compare
+ timers, and a watchdog. Currently only the GIC Timer is supported.
+ properties:
+ compatible:
+ const: mti,gic-timer
+
+ interrupts:
+ description: |
+ Interrupt for the GIC local timer, so normally it's suppose to be of
+ <GIC_LOCAL X IRQ_TYPE_NONE> format.
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-frequency: true
+
+ required:
+ - compatible
+ - interrupts
+
+ oneOf:
+ - required:
+ - clocks
+ - required:
+ - clock-frequency
+
+ additionalProperties: false
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - "#interrupt-cells"
+ - interrupt-controller
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/mips-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ interrupt-controller@1bdc0000 {
+ compatible = "mti,gic";
+ reg = <0x1bdc0000 0x20000>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ mti,reserved-cpu-vectors = <7>;
+ mti,reserved-ipi-vectors = <40 8>;
+
+ timer {
+ compatible = "mti,gic-timer";
+ interrupts = <GIC_LOCAL 1 IRQ_TYPE_NONE>;
+ clock-frequency = <50000000>;
+ };
+ };
+ - |
+ #include <dt-bindings/interrupt-controller/mips-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ interrupt-controller@1bdc0000 {
+ compatible = "mti,gic";
+ reg = <0x1bdc0000 0x20000>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+
+ timer {
+ compatible = "mti,gic-timer";
+ interrupts = <GIC_LOCAL 1 IRQ_TYPE_NONE>;
+ clocks = <&cpu_pll>;
+ };
+ };
+ - |
+ interrupt-controller {
+ compatible = "mti,gic";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ };
+...
--
2.26.2
^ permalink raw reply related
* [PATCH v4 2/5] dt-bindings: regulator: Add labibb regulator
From: Sumit Semwal @ 2020-06-02 10:09 UTC (permalink / raw)
To: agross, bjorn.andersson, lgirdwood, broonie, robh+dt
Cc: nishakumari, linux-arm-msm, linux-kernel, devicetree, kgunda,
rnayak, Sumit Semwal
In-Reply-To: <20200602100924.26256-1-sumit.semwal@linaro.org>
From: Nisha Kumari <nishakumari@codeaurora.org>
Adding the devicetree binding for labibb regulator.
Signed-off-by: Nisha Kumari <nishakumari@codeaurora.org>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
[sumits: cleanup as per review comments and update to yaml]
--
v2: updated for better compatible string and names.
v3: moved to yaml
v4: fixed dt_binding_check issues
---
.../regulator/qcom-labibb-regulator.yaml | 79 +++++++++++++++++++
1 file changed, 79 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
diff --git a/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
new file mode 100644
index 000000000000..178820ec04c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/qcom-labibb-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm's LAB(LCD AMOLED Boost)/IBB(Inverting Buck Boost) Regulator
+
+maintainers:
+ - Sumit Semwal <sumit.semwal@linaro.org>
+
+description:
+ LAB can be used as a positive boost power supply and IBB can be used as a
+ negative boost power supply for display panels. Currently implemented for
+ pmi8998.
+
+allOf:
+ - $ref: "regulator.yaml#"
+
+properties:
+ compatible:
+ const: qcom,pmi8998-lab-ibb
+
+ lab:
+ type: object
+
+ properties:
+
+ interrupts:
+ maxItems: 1
+ description:
+ Short-circuit interrupt for lab.
+
+ interrupt-names:
+ const: sc-err
+
+ required:
+ - interrupts
+ - interrupt-names
+
+ ibb:
+ type: object
+
+ properties:
+
+ interrupts:
+ maxItems: 1
+ description:
+ Short-circuit interrupt for lab.
+
+ interrupt-names:
+ const: sc-err
+
+ required:
+ - interrupts
+ - interrupt-names
+
+required:
+ - compatible
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ labibb {
+ compatible = "qcom,pmi8998-lab-ibb";
+
+ lab {
+ interrupts = <0x3 0x0 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "sc-err";
+ };
+
+ ibb {
+ interrupts = <0x3 0x2 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "sc-err";
+ };
+ };
+
+...
--
2.26.2
^ permalink raw reply related
* [PATCH v4 3/5] arm64: dts: qcom: pmi8998: Add nodes for LAB and IBB regulators
From: Sumit Semwal @ 2020-06-02 10:09 UTC (permalink / raw)
To: agross, bjorn.andersson, lgirdwood, broonie, robh+dt
Cc: nishakumari, linux-arm-msm, linux-kernel, devicetree, kgunda,
rnayak, Sumit Semwal
In-Reply-To: <20200602100924.26256-1-sumit.semwal@linaro.org>
From: Nisha Kumari <nishakumari@codeaurora.org>
This patch adds devicetree nodes for LAB and IBB regulators.
Signed-off-by: Nisha Kumari <nishakumari@codeaurora.org>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
[sumits: Updated for better compatible strings and names]
--
v2: sumits: updated for better compatible string and names
v3: sumits: updated interrupt-names as per review comments
v4: sumits: removed labibb label
---
arch/arm64/boot/dts/qcom/pmi8998.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/pmi8998.dtsi b/arch/arm64/boot/dts/qcom/pmi8998.dtsi
index 23f9146a161e..3230b78b8048 100644
--- a/arch/arm64/boot/dts/qcom/pmi8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/pmi8998.dtsi
@@ -25,5 +25,19 @@ pmi8998_lsid1: pmic@3 {
reg = <0x3 SPMI_USID>;
#address-cells = <1>;
#size-cells = <0>;
+
+ labibb {
+ compatible = "qcom,pmi8998-lab-ibb";
+
+ ibb: ibb {
+ interrupts = <0x3 0xdc 0x2 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "sc-err";
+ };
+
+ lab: lab {
+ interrupts = <0x3 0xde 0x0 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "sc-err";
+ };
+ };
};
};
--
2.26.2
^ permalink raw reply related
* [PATCH v4 5/5] regulator: qcom: labibb: Add SC interrupt handling
From: Sumit Semwal @ 2020-06-02 10:09 UTC (permalink / raw)
To: agross, bjorn.andersson, lgirdwood, broonie, robh+dt
Cc: nishakumari, linux-arm-msm, linux-kernel, devicetree, kgunda,
rnayak, Sumit Semwal
In-Reply-To: <20200602100924.26256-1-sumit.semwal@linaro.org>
From: Nisha Kumari <nishakumari@codeaurora.org>
Add Short circuit interrupt handling and recovery for the lab and ibb
regulators on qcom platforms.
The client panel drivers need to register for REGULATOR_EVENT_OVER_CURRENT
notification which will be triggered on short circuit. They should
try to enable the regulator once, and if it doesn't get enabled,
handle shutting down the panel accordingly.
Signed-off-by: Nisha Kumari <nishakumari@codeaurora.org>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
[sumits: updated to rework to use regmap_read_poll_timeout, handle it per
regulator, add REGULATOR_EVENT_OVER_CURRENT handling and
notification to clients and other cleanup]
--
v2: sumits: reworked handling to user regmap_read_poll_timeout, and handle it
per-regulator instead of clearing both lab and ibb errors on either irq
triggering. Also added REGULATOR_EVENT_OVER_CURRENT handling and
notification to clients.
v3: sumits: updated as per review comments of v2: removed spurious check for
irq in handler and some unused variables; inlined some of the code,
omitted IRQF_TRIGGER_RISING as it's coming from DT.
v4: sumits: updated 'int vreg_enabled' to 'boot enabled', made sc_irq a local var
and other review comments from v3.
---
drivers/regulator/qcom-labibb-regulator.c | 102 +++++++++++++++++++++-
1 file changed, 99 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/qcom-labibb-regulator.c b/drivers/regulator/qcom-labibb-regulator.c
index 33b764ac69d1..bca0308b26dd 100644
--- a/drivers/regulator/qcom-labibb-regulator.c
+++ b/drivers/regulator/qcom-labibb-regulator.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0-only
// Copyright (c) 2020, The Linux Foundation. All rights reserved.
+#include <linux/interrupt.h>
#include <linux/module.h>
#include <linux/of_irq.h>
#include <linux/of.h>
@@ -18,6 +19,7 @@
#define REG_LABIBB_ENABLE_CTL 0x46
#define LABIBB_STATUS1_VREG_OK_BIT BIT(7)
#define LABIBB_CONTROL_ENABLE BIT(7)
+#define LABIBB_STATUS1_SC_DETECT_BIT BIT(6)
#define LAB_ENABLE_CTL_MASK BIT(7)
#define IBB_ENABLE_CTL_MASK (BIT(7) | BIT(6))
@@ -27,12 +29,16 @@
#define IBB_ENABLE_TIME (LABIBB_OFF_ON_DELAY * 10)
#define LABIBB_POLL_ENABLED_TIME 1000
+#define POLLING_SCP_DONE_INTERVAL_US 5000
+#define POLLING_SCP_TIMEOUT 16000
+
struct labibb_regulator {
struct regulator_desc desc;
struct device *dev;
struct regmap *regmap;
struct regulator_dev *rdev;
u16 base;
+ bool enabled;
u8 type;
};
@@ -59,12 +65,26 @@ static int qcom_labibb_regulator_is_enabled(struct regulator_dev *rdev)
static int qcom_labibb_regulator_enable(struct regulator_dev *rdev)
{
- return regulator_enable_regmap(rdev);
+ int ret;
+ struct labibb_regulator *reg = rdev_get_drvdata(rdev);
+
+ ret = regulator_enable_regmap(rdev);
+ if (ret >= 0)
+ reg->enabled = true;
+
+ return ret;
}
static int qcom_labibb_regulator_disable(struct regulator_dev *rdev)
{
- return regulator_disable_regmap(rdev);
+ int ret = 0;
+ struct labibb_regulator *reg = rdev_get_drvdata(rdev);
+
+ ret = regulator_disable_regmap(rdev);
+ if (ret >= 0)
+ reg->enabled = false;
+
+ return ret;
}
static struct regulator_ops qcom_labibb_ops = {
@@ -73,12 +93,70 @@ static struct regulator_ops qcom_labibb_ops = {
.is_enabled = qcom_labibb_regulator_is_enabled,
};
+static irqreturn_t labibb_sc_err_handler(int irq, void *_reg)
+{
+ int ret;
+ u16 reg;
+ unsigned int val;
+ struct labibb_regulator *labibb_reg = _reg;
+ bool in_sc_err, scp_done = false;
+
+ ret = regmap_read(labibb_reg->regmap,
+ labibb_reg->base + REG_LABIBB_STATUS1, &val);
+ if (ret < 0) {
+ dev_err(labibb_reg->dev, "sc_err_irq: Read failed, ret=%d\n",
+ ret);
+ return IRQ_HANDLED;
+ }
+
+ dev_dbg(labibb_reg->dev, "%s SC error triggered! STATUS1 = %d\n",
+ labibb_reg->desc.name, val);
+
+ in_sc_err = !!(val & LABIBB_STATUS1_SC_DETECT_BIT);
+
+ /*
+ * The SC(short circuit) fault would trigger PBS(Portable Batch
+ * System) to disable regulators for protection. This would
+ * cause the SC_DETECT status being cleared so that it's not
+ * able to get the SC fault status.
+ * Check if the regulator is enabled in the driver but
+ * disabled in hardware, this means a SC fault had happened
+ * and SCP handling is completed by PBS.
+ */
+ if (!in_sc_err) {
+
+ reg = labibb_reg->base + REG_LABIBB_ENABLE_CTL;
+
+ ret = regmap_read_poll_timeout(labibb_reg->regmap,
+ reg, val,
+ !(val & LABIBB_CONTROL_ENABLE),
+ POLLING_SCP_DONE_INTERVAL_US,
+ POLLING_SCP_TIMEOUT);
+
+ if (!ret && labibb_reg->enabled) {
+ dev_dbg(labibb_reg->dev,
+ "%s has been disabled by SCP\n",
+ labibb_reg->desc.name);
+ scp_done = true;
+ }
+ }
+
+ if (in_sc_err || scp_done) {
+ regulator_lock(labibb_reg->rdev);
+ regulator_notifier_call_chain(labibb_reg->rdev,
+ REGULATOR_EVENT_OVER_CURRENT,
+ NULL);
+ regulator_unlock(labibb_reg->rdev);
+ }
+ return IRQ_HANDLED;
+}
+
static struct regulator_dev *register_labibb_regulator(struct labibb_regulator *reg,
const struct labibb_regulator_data *reg_data,
struct device_node *of_node)
{
struct regulator_config cfg = {};
- int ret;
+ int ret, sc_irq;
reg->base = reg_data->base;
reg->type = reg_data->type;
@@ -95,6 +173,24 @@ static struct regulator_dev *register_labibb_regulator(struct labibb_regulator *
reg->desc.poll_enabled_time = LABIBB_POLL_ENABLED_TIME;
reg->desc.off_on_delay = LABIBB_OFF_ON_DELAY;
+ sc_irq = of_irq_get_byname(of_node, "sc-err");
+ if (sc_irq < 0) {
+ dev_err(reg->dev, "Unable to get sc-err, ret = %d\n",
+ sc_irq);
+ return ERR_PTR(sc_irq);
+ } else {
+ ret = devm_request_threaded_irq(reg->dev,
+ sc_irq,
+ NULL, labibb_sc_err_handler,
+ IRQF_ONESHOT,
+ "sc-err", reg);
+ if (ret) {
+ dev_err(reg->dev, "Failed to register sc-err irq ret=%d\n",
+ ret);
+ return ERR_PTR(ret);
+ }
+ }
+
cfg.dev = reg->dev;
cfg.driver_data = reg;
cfg.regmap = reg->regmap;
--
2.26.2
^ permalink raw reply related
* [PATCH v4 4/5] regulator: qcom: Add labibb driver
From: Sumit Semwal @ 2020-06-02 10:09 UTC (permalink / raw)
To: agross, bjorn.andersson, lgirdwood, broonie, robh+dt
Cc: nishakumari, linux-arm-msm, linux-kernel, devicetree, kgunda,
rnayak, Sumit Semwal
In-Reply-To: <20200602100924.26256-1-sumit.semwal@linaro.org>
From: Nisha Kumari <nishakumari@codeaurora.org>
Qualcomm platforms have LAB(LCD AMOLED Boost)/IBB(Inverting Buck Boost)
regulators, labibb for short, which are used as power supply for
LCD Mode displays.
This patch adds labibb regulator driver for pmi8998 PMIC, found on
SDM845 platforms.
Signed-off-by: Nisha Kumari <nishakumari@codeaurora.org>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
[sumits: reworked to driver for more common code, using core regulator
features, and using newly-added poll_enabled_time functionality
from core]
--
v2: sumits: reworked the driver for more common code, and addressed
review comments from v1
v3: sumits: addressed review comments from v2; moved to use core
regulator features like enable_time, off_on_delay, and the newly
added poll_enabled_time. Moved the check_enabled functionality
to core framework via poll_enabled_time.
v4: sumits: address review comments from v3, including cleaning up
register_labibb_regulator(), and adapted to updated meaning of
poll_enabled_time.
---
drivers/regulator/Kconfig | 10 ++
drivers/regulator/Makefile | 1 +
drivers/regulator/qcom-labibb-regulator.c | 193 ++++++++++++++++++++++
3 files changed, 204 insertions(+)
create mode 100644 drivers/regulator/qcom-labibb-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index f4b72cb098ef..58704a9fd05d 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -1167,5 +1167,15 @@ config REGULATOR_WM8994
This driver provides support for the voltage regulators on the
WM8994 CODEC.
+config REGULATOR_QCOM_LABIBB
+ tristate "QCOM LAB/IBB regulator support"
+ depends on SPMI || COMPILE_TEST
+ help
+ This driver supports Qualcomm's LAB/IBB regulators present on the
+ Qualcomm's PMIC chip pmi8998. QCOM LAB and IBB are SPMI
+ based PMIC implementations. LAB can be used as positive
+ boost regulator and IBB can be used as a negative boost regulator
+ for LCD display panel.
+
endif
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 6610ee001d9a..5b313786c0e8 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -87,6 +87,7 @@ obj-$(CONFIG_REGULATOR_MT6323) += mt6323-regulator.o
obj-$(CONFIG_REGULATOR_MT6358) += mt6358-regulator.o
obj-$(CONFIG_REGULATOR_MT6380) += mt6380-regulator.o
obj-$(CONFIG_REGULATOR_MT6397) += mt6397-regulator.o
+obj-$(CONFIG_REGULATOR_QCOM_LABIBB) += qcom-labibb-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_RPMH) += qcom-rpmh-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o
diff --git a/drivers/regulator/qcom-labibb-regulator.c b/drivers/regulator/qcom-labibb-regulator.c
new file mode 100644
index 000000000000..33b764ac69d1
--- /dev/null
+++ b/drivers/regulator/qcom-labibb-regulator.c
@@ -0,0 +1,194 @@
+// SPDX-License-Identifier: GPL-2.0-only
+// Copyright (c) 2020, The Linux Foundation. All rights reserved.
+
+#include <linux/module.h>
+#include <linux/of_irq.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/regulator/driver.h>
+#include <linux/regulator/of_regulator.h>
+
+#define REG_PERPH_TYPE 0x04
+#define QCOM_LAB_TYPE 0x24
+#define QCOM_IBB_TYPE 0x20
+
+#define REG_LABIBB_STATUS1 0x08
+#define REG_LABIBB_ENABLE_CTL 0x46
+#define LABIBB_STATUS1_VREG_OK_BIT BIT(7)
+#define LABIBB_CONTROL_ENABLE BIT(7)
+
+#define LAB_ENABLE_CTL_MASK BIT(7)
+#define IBB_ENABLE_CTL_MASK (BIT(7) | BIT(6))
+
+#define LABIBB_OFF_ON_DELAY 1000
+#define LAB_ENABLE_TIME (LABIBB_OFF_ON_DELAY * 2)
+#define IBB_ENABLE_TIME (LABIBB_OFF_ON_DELAY * 10)
+#define LABIBB_POLL_ENABLED_TIME 1000
+
+struct labibb_regulator {
+ struct regulator_desc desc;
+ struct device *dev;
+ struct regmap *regmap;
+ struct regulator_dev *rdev;
+ u16 base;
+ u8 type;
+};
+
+struct labibb_regulator_data {
+ u16 base;
+ const char *name;
+ u8 type;
+ unsigned int enable_time;
+ unsigned int enable_mask;
+};
+
+static int qcom_labibb_regulator_is_enabled(struct regulator_dev *rdev)
+{
+ int ret;
+ unsigned int val;
+ struct labibb_regulator *reg = rdev_get_drvdata(rdev);
+
+ ret = regmap_read(reg->regmap, reg->base + REG_LABIBB_STATUS1, &val);
+ if (ret < 0) {
+ dev_err(reg->dev, "Read register failed ret = %d\n", ret);
+ return ret;
+ }
+ return !!(val & LABIBB_STATUS1_VREG_OK_BIT);
+}
+
+static int qcom_labibb_regulator_enable(struct regulator_dev *rdev)
+{
+ return regulator_enable_regmap(rdev);
+}
+
+static int qcom_labibb_regulator_disable(struct regulator_dev *rdev)
+{
+ return regulator_disable_regmap(rdev);
+}
+
+static struct regulator_ops qcom_labibb_ops = {
+ .enable = qcom_labibb_regulator_enable,
+ .disable = qcom_labibb_regulator_disable,
+ .is_enabled = qcom_labibb_regulator_is_enabled,
+};
+
+static struct regulator_dev *register_labibb_regulator(struct labibb_regulator *reg,
+ const struct labibb_regulator_data *reg_data,
+ struct device_node *of_node)
+{
+ struct regulator_config cfg = {};
+ int ret;
+
+ reg->base = reg_data->base;
+ reg->type = reg_data->type;
+ reg->desc.enable_mask = reg_data->enable_mask;
+ reg->desc.enable_reg = reg->base + REG_LABIBB_ENABLE_CTL;
+ reg->desc.enable_val = LABIBB_CONTROL_ENABLE;
+ reg->desc.of_match = reg_data->name;
+ reg->desc.name = reg_data->name;
+ reg->desc.owner = THIS_MODULE;
+ reg->desc.type = REGULATOR_VOLTAGE;
+ reg->desc.ops = &qcom_labibb_ops;
+
+ reg->desc.enable_time = reg_data->enable_time;
+ reg->desc.poll_enabled_time = LABIBB_POLL_ENABLED_TIME;
+ reg->desc.off_on_delay = LABIBB_OFF_ON_DELAY;
+
+ cfg.dev = reg->dev;
+ cfg.driver_data = reg;
+ cfg.regmap = reg->regmap;
+ cfg.of_node = of_node;
+
+ return devm_regulator_register(reg->dev, ®->desc, &cfg);
+}
+
+static const struct labibb_regulator_data pmi8998_labibb_data[] = {
+ {0xde00, "lab", QCOM_LAB_TYPE, LAB_ENABLE_TIME, LAB_ENABLE_CTL_MASK},
+ {0xdc00, "ibb", QCOM_IBB_TYPE, IBB_ENABLE_TIME, IBB_ENABLE_CTL_MASK},
+ { },
+};
+
+static const struct of_device_id qcom_labibb_match[] = {
+ { .compatible = "qcom,pmi8998-lab-ibb", .data = &pmi8998_labibb_data},
+ { },
+};
+MODULE_DEVICE_TABLE(of, qcom_labibb_match);
+
+static int qcom_labibb_regulator_probe(struct platform_device *pdev)
+{
+ struct labibb_regulator *labibb_reg;
+ struct device *dev = &pdev->dev;
+ struct device_node *child;
+ const struct of_device_id *match;
+ const struct labibb_regulator_data *reg_data;
+ struct regmap *reg_regmap;
+ unsigned int type;
+ int ret;
+
+ reg_regmap = dev_get_regmap(pdev->dev.parent, NULL);
+ if (!reg_regmap) {
+ dev_err(&pdev->dev, "Couldn't get parent's regmap\n");
+ return -ENODEV;
+ }
+
+ match = of_match_device(qcom_labibb_match, &pdev->dev);
+ if (!match)
+ return -ENODEV;
+
+ for (reg_data = match->data; reg_data->name; reg_data++) {
+ child = of_get_child_by_name(pdev->dev.of_node, reg_data->name);
+
+ if (WARN_ON(child == NULL))
+ return -EINVAL;
+
+ /* Validate if the type of regulator is indeed
+ * what's mentioned in DT.
+ */
+ ret = regmap_read(reg_regmap, reg_data->base + REG_PERPH_TYPE,
+ &type);
+ if (ret < 0) {
+ dev_err(dev,
+ "Peripheral type read failed ret=%d\n",
+ ret);
+ return -EINVAL;
+ }
+
+ if (WARN_ON((type != QCOM_LAB_TYPE) && (type != QCOM_IBB_TYPE)) ||
+ WARN_ON(type != reg_data->type))
+ return -EINVAL;
+
+ labibb_reg = devm_kzalloc(&pdev->dev, sizeof(*labibb_reg),
+ GFP_KERNEL);
+ if (!labibb_reg)
+ return -ENOMEM;
+
+ labibb_reg->regmap = reg_regmap;
+ labibb_reg->dev = dev;
+
+ dev_info(dev, "Registering %s regulator\n", child->full_name);
+
+ labibb_reg->rdev = register_labibb_regulator(labibb_reg, reg_data, child);
+ if (IS_ERR(labibb_reg->rdev)) {
+ dev_err(dev,
+ "qcom_labibb: error registering %s : %d\n",
+ child->full_name, ret);
+ return PTR_ERR(labibb_reg->rdev);
+ }
+ }
+
+ return 0;
+}
+
+static struct platform_driver qcom_labibb_regulator_driver = {
+ .driver = {
+ .name = "qcom-lab-ibb-regulator",
+ .of_match_table = qcom_labibb_match,
+ },
+ .probe = qcom_labibb_regulator_probe,
+};
+module_platform_driver(qcom_labibb_regulator_driver);
+
+MODULE_DESCRIPTION("Qualcomm labibb driver");
+MODULE_LICENSE("GPL v2");
--
2.26.2
^ permalink raw reply related
* [PATCH v3 5/6] bus: cdmm: Add MIPS R5 arch support
From: Serge Semin @ 2020-06-02 10:09 UTC (permalink / raw)
To: Thomas Bogendoerfer, Thomas Gleixner, Greg Kroah-Hartman
Cc: Serge Semin, Serge Semin, Alexey Malahov, Paul Burton,
Rob Herring, Arnd Bergmann, Jason Cooper, Marc Zyngier,
Rafael J. Wysocki, Daniel Lezcano, James Hogan, linux-mips,
devicetree, linux-kernel
In-Reply-To: <20200602100921.1155-1-Sergey.Semin@baikalelectronics.ru>
CDMM may be available not only on MIPS R2 architectures, but also on
newer MIPS R5 chips. For instance our P5600 chip has one. Let's mark
the CDMM bus being supported for that MIPS arch too.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
---
drivers/bus/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 6d4e4497b59b..971c07bc92d4 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -58,7 +58,7 @@ config IMX_WEIM
config MIPS_CDMM
bool "MIPS Common Device Memory Map (CDMM) Driver"
- depends on CPU_MIPSR2
+ depends on CPU_MIPSR2 || CPU_MIPSR5
help
Driver needed for the MIPS Common Device Memory Map bus in MIPS
cores. This bus is for per-CPU tightly coupled devices such as the
--
2.26.2
^ permalink raw reply related
* [PATCH v4 1/5] regulator: Allow regulators to verify enabled during enable()
From: Sumit Semwal @ 2020-06-02 10:09 UTC (permalink / raw)
To: agross, bjorn.andersson, lgirdwood, broonie, robh+dt
Cc: nishakumari, linux-arm-msm, linux-kernel, devicetree, kgunda,
rnayak, Sumit Semwal
In-Reply-To: <20200602100924.26256-1-sumit.semwal@linaro.org>
Some regulators might need to verify that they have indeed been enabled
after the enable() call is made and enable_time delay has passed.
This is implemented by repeatedly checking is_enabled() upto
poll_enabled_time, waiting for the already calculated enable delay in
each iteration.
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
--
v2: Address review comments, including swapping enable_time and poll_enabled_time.
---
drivers/regulator/core.c | 58 +++++++++++++++++++++++++++++++-
include/linux/regulator/driver.h | 5 +++
2 files changed, 62 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 7486f6e4e613..d9ab888da95f 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2347,6 +2347,32 @@ static void _regulator_enable_delay(unsigned int delay)
udelay(us);
}
+/* _regulator_check_status_enabled
+ *
+ * returns:
+ * 1 if status shows regulator is in enabled state
+ * 0 if not enabled state
+ * else, error value as received from ops->get_status()
+ */
+static inline int _regulator_check_status_enabled(struct regulator_dev *rdev)
+{
+ int ret = rdev->desc->ops->get_status(rdev);
+
+ if (ret < 0) {
+ rdev_info(rdev, "get_status returned error: %d\n", ret);
+ return ret;
+ }
+
+ switch (ret) {
+ case REGULATOR_STATUS_OFF:
+ case REGULATOR_STATUS_ERROR:
+ case REGULATOR_STATUS_UNDEFINED:
+ return 0;
+ default:
+ return 1;
+ }
+}
+
static int _regulator_do_enable(struct regulator_dev *rdev)
{
int ret, delay;
@@ -2407,7 +2433,37 @@ static int _regulator_do_enable(struct regulator_dev *rdev)
* together. */
trace_regulator_enable_delay(rdev_get_name(rdev));
- _regulator_enable_delay(delay);
+ /* If poll_enabled_time is set, poll upto the delay calculated
+ * above, delaying poll_enabled_time uS to check if the regulator
+ * actually got enabled.
+ * If the regulator isn't enabled after enable_delay has
+ * expired, return -ETIMEDOUT.
+ */
+ if (rdev->desc->poll_enabled_time) {
+ unsigned int time_remaining = delay;
+
+ while (time_remaining > 0) {
+ _regulator_enable_delay(rdev->desc->poll_enabled_time);
+
+ if (rdev->desc->ops->get_status) {
+ ret = _regulator_check_status_enabled(rdev);
+ if (ret < 0)
+ return ret;
+ else if (ret)
+ break;
+ } else if (rdev->desc->ops->is_enabled(rdev))
+ break;
+
+ time_remaining -= rdev->desc->poll_enabled_time;
+ }
+
+ if (time_remaining <= 0) {
+ rdev_err(rdev, "Enabled check failed.\n");
+ return -ETIMEDOUT;
+ }
+ } else {
+ _regulator_enable_delay(delay);
+ }
trace_regulator_enable_complete(rdev_get_name(rdev));
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index 29d920516e0b..bb50e943010f 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -322,6 +322,9 @@ enum regulator_type {
* @enable_time: Time taken for initial enable of regulator (in uS).
* @off_on_delay: guard time (in uS), before re-enabling a regulator
*
+ * @poll_enabled_time: Maximum time (in uS) to poll if the regulator is
+ * actually enabled, after enable() call
+ *
* @of_map_mode: Maps a hardware mode defined in a DeviceTree to a standard mode
*/
struct regulator_desc {
@@ -389,6 +392,8 @@ struct regulator_desc {
unsigned int off_on_delay;
+ unsigned int poll_enabled_time;
+
unsigned int (*of_map_mode)(unsigned int mode);
};
--
2.26.2
^ permalink raw reply related
* [PATCH v4 0/5] Qualcomm labibb regulator driver
From: Sumit Semwal @ 2020-06-02 10:09 UTC (permalink / raw)
To: agross, bjorn.andersson, lgirdwood, broonie, robh+dt
Cc: nishakumari, linux-arm-msm, linux-kernel, devicetree, kgunda,
rnayak, Sumit Semwal
This series adds a driver for LAB/IBB regulators found on some Qualcomm SoCs.
These regulators provide positive and/or negative boost power supplies
for LCD/LED display panels connected to the SoC.
This series adds the support for pmi8998 PMIC found in SDM845 family of SoCs.
Changes from v3:
- Handled review comments from v3
- In core, swapped the meaning of enable_time and poll_enabled_time; so we
wait for total enable_time delay, and poll in-between at poll_enabled_time
interval now.
- fixed dt_bindings_check issues in dt-bindings patch.
- Cleanup of register_labibb_regulator(), and adapted to updated meaning of
poll_enabled_time.
Changes from v2:
- Review comments from v2
- Moved the poll-to-check-enabled functionality to regulator core.
- Used more core features to simplify enable/disable functions.
- Moved the devicetree binding to yaml.
- Updated interrupt-names and simplified handling.
Changes from v1:
- Incorporated review comments from v1
- Changed from virtual-regulator based handling to individual regulator based
handling.
- Reworked the core to merge most of enable/disable functions, combine the
regulator_ops into one and allow for future variations.
- is_enabled() is now _really_ is_enabled()
- Simplified the SC interrupt handling - use regmap_read_poll_timeout,
REGULATOR_EVENT_OVER_CURRENT handling and notification to clients.
Nisha Kumari (4):
dt-bindings: regulator: Add labibb regulator
arm64: dts: qcom: pmi8998: Add nodes for LAB and IBB regulators
regulator: qcom: Add labibb driver
regulator: qcom: labibb: Add SC interrupt handling
Sumit Semwal (1):
regulator: Allow regulators to verify enabled during enable()
.../regulator/qcom-labibb-regulator.yaml | 79 +++++
arch/arm64/boot/dts/qcom/pmi8998.dtsi | 14 +
drivers/regulator/Kconfig | 10 +
drivers/regulator/Makefile | 1 +
drivers/regulator/core.c | 58 +++-
drivers/regulator/qcom-labibb-regulator.c | 289 ++++++++++++++++++
include/linux/regulator/driver.h | 5 +
7 files changed, 455 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
create mode 100644 drivers/regulator/qcom-labibb-regulator.c
--
2.26.2
^ permalink raw reply
* Re: [V9, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
From: Sakari Ailus @ 2020-06-02 9:56 UTC (permalink / raw)
To: Dongchun Zhu
Cc: Tomasz Figa, Rob Herring, Linus Walleij, Bartosz Golaszewski,
Mauro Carvalho Chehab, Andy Shevchenko, Mark Rutland,
Nicolas Boichat, Matthias Brugger, Cao Bing Bu, srv_heupstream,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, Sj Huang,
Linux Media Mailing List, linux-devicetree, Louis Kuo,
Shengnan Wang (王圣男)
In-Reply-To: <1591078501.8804.539.camel@mhfsdcap03>
Hi Dongchun,
On Tue, Jun 02, 2020 at 02:15:01PM +0800, Dongchun Zhu wrote:
> Hi Tomasz, Sakari,
>
> On Mon, 2020-06-01 at 20:18 +0200, Tomasz Figa wrote:
> > On Mon, Jun 1, 2020 at 4:35 AM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > >
> > > Hi Tomasz,
> > >
> > > On Fri, 2020-05-29 at 15:43 +0200, Tomasz Figa wrote:
> > > > On Thu, May 28, 2020 at 10:06 AM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > > > >
> > > > > Hi Sakari,
> > > > >
> > > > > On Thu, 2020-05-28 at 10:23 +0300, Sakari Ailus wrote:
> > > > > > Hi Dongchun,
> > > > > >
> > > > > > On Thu, May 28, 2020 at 11:34:42AM +0800, Dongchun Zhu wrote:
> > > > > > > Hi Sakari, Rob,
> > > > > > >
> > > > > > > On Thu, 2020-05-28 at 00:16 +0300, Sakari Ailus wrote:
> > > > > > > > Hi Rob, Dongchun,
> > > > > > > >
> > > > > > > > On Wed, May 27, 2020 at 09:27:22AM -0600, Rob Herring wrote:
> > > > > > > > > > > > + properties:
> > > > > > > > > > > > + endpoint:
> > > > > > > > > > > > + type: object
> > > > > > > > > > > > + additionalProperties: false
> > > > > > > > > > > > +
> > > > > > > > > > > > + properties:
> > > > > > > > > >
> > > > > > > > > > Actually I wonder whether we need to declare 'clock-lanes' here?
> > > > > > > > >
> > > > > > > > > Yes, if you are using it.
> > > > > > > >
> > > > > > > > Dongchun, can you confirm the chip has a single data and a single clock
> > > > > > > > lane and that it does not support lane reordering?
> > > > > > > >
> > > > > > >
> > > > > > > From the datasheet, 'MIPI inside the OV02A10 provides one single
> > > > > > > uni-directional clock lane and one bi-directional data lane solution for
> > > > > > > communication links between components inside a mobile device.
> > > > > > > The data lane has full support for HS(uni-directional) and
> > > > > > > LP(bi-directional) data transfer mode.'
> > > > > > >
> > > > > > > The sensor doesn't support lane reordering, so 'clock-lanes' property
> > > > > > > would not be added in next release.
> > > > > > >
> > > > > > > > So if there's nothing to convey to the driver, also the data-lanes should
> > > > > > > > be removed IMO.
> > > > > > > >
> > > > > > >
> > > > > > > However, 'data-lanes' property may still be required.
> > > > > > > It is known that either data-lanes or clock-lanes is an array of
> > > > > > > physical data lane indexes. Position of an entry determines the logical
> > > > > > > lane number, while the value of an entry indicates physical lane, e.g.,
> > > > > > > for 1-lane MIPI CSI-2 bus we could have "data-lanes = <1>;", assuming
> > > > > > > the clock lane is on hardware lane 0.
> > > > > > >
> > > > > > > As mentioned earlier, the OV02A10 sensor supports only 1C1D and does not
> > > > > > > support lane reordering, so here we shall use 'data-lanes = <1>' as
> > > > > > > there is only a clock lane for OV02A10.
> > > > > > >
> > > > > > > Reminder:
> > > > > > > If 'data-lanes' property is not present, the driver would assume
> > > > > > > four-lane operation. This means for one-lane or two-lane operation, this
> > > > > > > property must be present and set to the right physical lane indexes.
> > > > > > > If the hardware does not support lane reordering, monotonically
> > > > > > > incremented values shall be used from 0 or 1 onwards, depending on
> > > > > > > whether or not there is also a clock lane.
> > > > > >
> > > > > > How can the driver use four lanes, considering the device only supports a
> > > > > > single lane??
> > > > > >
> > > > >
> > > > > I understood your meaning.
> > > > > If we omit the property 'data-lanes', the sensor should work still.
> > > > > But then what's the meaning of the existence of 'data-lanes'?
> > > > > If this property 'data-lanes' is always optional, then why dt-bindings
> > > > > provide the interface?
> > > > >
> > > > > In the meantime, if omitting 'data-lanes' for one sensor(transmitter)
> > > > > that has only one physical data lane, MIPI receiver(e.g., MIPI CSI-2)
> > > > > shall enable four-lane configuration, which may increase consumption of
> > > > > both power and resource in the process of IIC communication.
> > > >
> > > > Wouldn't the receiver still have the data-lanes property under its
> > > > endpoint node, telling it how many lanes and in which order should be
> > > > used?
> > > >
> > >
> > > The MIPI receiver(RX) shall use
> > > v4l2_async_notifier_add_fwnode_remote_subdev() API to parse the property
> > > "data-lanes" under sensor output port.
> >
> > That's not true. The MIPI receiver driver parses its own port node
> > corresponding to the sensor. Also quoting the documentation [1]:
> >
> > "An endpoint subnode of a device contains all properties needed for
> > _configuration of this device_ for data exchange with other device. In most
> > cases properties at the peer 'endpoint' nodes will be identical, however they
> > might need to be different when there is any signal modifications on the bus
> > between two devices, e.g. there are logic signal inverters on the lines."
> >
> > In this case, there is such a signal modification if the sensor has a
> > 1-lane bus and the receiver more lines, so the data-lanes properties
> > would be different on both sides.
> >
> > [1] https://elixir.bootlin.com/linux/v5.7/source/Documentation/devicetree/bindings/media/video-interfaces.txt
> >
>
> Sorry for the misunderstanding.
> After doing some experiments about the data-lanes property under sensor
> i2c node, we found the API
> v4l2_async_notifier_add_fwnode_remote_subdev() that MIPI receiver driver
> used indeed parses the data-lanes under its own port node.
>
> Sorry make a mistake for the use case of sensor data-lanes previously.
> Now We may encounter one new question for this patch.
> In practice we haven't used the data-lanes under sensor i2c node
> anywhere, if sensor driver itself doesn't parse that.
>
> But there is still one reason to keep the exactly right data-lanes in
> DT. That is, the data-lanes under sensor i2c node could be used as a
> reference for MIPI receiver driver.
> Just as Tomasz said, 'The MIPI receiver driver parses its own port node
> corresponding to the sensor'.
>
> Sakari, Tomasz, what's your opinions about the present of data-lanes
> under sensor node or not?
The receiver driver doesn't parse the properties in the sensor
(transmitter) device's endpoint. If that property provides no information
to the receiver, as is the case here, it should be omitted.
--
Regards,
Sakari Ailus
^ permalink raw reply
* Re: [V9, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
From: Sakari Ailus @ 2020-06-02 9:53 UTC (permalink / raw)
To: Tomasz Figa
Cc: Dongchun Zhu, Rob Herring, Linus Walleij, Bartosz Golaszewski,
Mauro Carvalho Chehab, Andy Shevchenko, Mark Rutland,
Nicolas Boichat, Matthias Brugger, Cao Bing Bu, srv_heupstream,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, Sj Huang,
Linux Media Mailing List, linux-devicetree, Louis Kuo,
Shengnan Wang (王圣男)
In-Reply-To: <CAAFQd5AuHDpQN8xZsWgnAt6m2reAYJbs9nBp0+mBo7_FS81LbQ@mail.gmail.com>
On Fri, May 29, 2020 at 03:43:30PM +0200, Tomasz Figa wrote:
> On Thu, May 28, 2020 at 10:06 AM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> >
> > Hi Sakari,
> >
> > On Thu, 2020-05-28 at 10:23 +0300, Sakari Ailus wrote:
> > > Hi Dongchun,
> > >
> > > On Thu, May 28, 2020 at 11:34:42AM +0800, Dongchun Zhu wrote:
> > > > Hi Sakari, Rob,
> > > >
> > > > On Thu, 2020-05-28 at 00:16 +0300, Sakari Ailus wrote:
> > > > > Hi Rob, Dongchun,
> > > > >
> > > > > On Wed, May 27, 2020 at 09:27:22AM -0600, Rob Herring wrote:
> > > > > > > > > + properties:
> > > > > > > > > + endpoint:
> > > > > > > > > + type: object
> > > > > > > > > + additionalProperties: false
> > > > > > > > > +
> > > > > > > > > + properties:
> > > > > > >
> > > > > > > Actually I wonder whether we need to declare 'clock-lanes' here?
> > > > > >
> > > > > > Yes, if you are using it.
> > > > >
> > > > > Dongchun, can you confirm the chip has a single data and a single clock
> > > > > lane and that it does not support lane reordering?
> > > > >
> > > >
> > > > From the datasheet, 'MIPI inside the OV02A10 provides one single
> > > > uni-directional clock lane and one bi-directional data lane solution for
> > > > communication links between components inside a mobile device.
> > > > The data lane has full support for HS(uni-directional) and
> > > > LP(bi-directional) data transfer mode.'
> > > >
> > > > The sensor doesn't support lane reordering, so 'clock-lanes' property
> > > > would not be added in next release.
> > > >
> > > > > So if there's nothing to convey to the driver, also the data-lanes should
> > > > > be removed IMO.
> > > > >
> > > >
> > > > However, 'data-lanes' property may still be required.
> > > > It is known that either data-lanes or clock-lanes is an array of
> > > > physical data lane indexes. Position of an entry determines the logical
> > > > lane number, while the value of an entry indicates physical lane, e.g.,
> > > > for 1-lane MIPI CSI-2 bus we could have "data-lanes = <1>;", assuming
> > > > the clock lane is on hardware lane 0.
> > > >
> > > > As mentioned earlier, the OV02A10 sensor supports only 1C1D and does not
> > > > support lane reordering, so here we shall use 'data-lanes = <1>' as
> > > > there is only a clock lane for OV02A10.
> > > >
> > > > Reminder:
> > > > If 'data-lanes' property is not present, the driver would assume
> > > > four-lane operation. This means for one-lane or two-lane operation, this
> > > > property must be present and set to the right physical lane indexes.
> > > > If the hardware does not support lane reordering, monotonically
> > > > incremented values shall be used from 0 or 1 onwards, depending on
> > > > whether or not there is also a clock lane.
> > >
> > > How can the driver use four lanes, considering the device only supports a
> > > single lane??
> > >
> >
> > I understood your meaning.
> > If we omit the property 'data-lanes', the sensor should work still.
> > But then what's the meaning of the existence of 'data-lanes'?
> > If this property 'data-lanes' is always optional, then why dt-bindings
> > provide the interface?
> >
> > In the meantime, if omitting 'data-lanes' for one sensor(transmitter)
> > that has only one physical data lane, MIPI receiver(e.g., MIPI CSI-2)
> > shall enable four-lane configuration, which may increase consumption of
> > both power and resource in the process of IIC communication.
>
> Wouldn't the receiver still have the data-lanes property under its
> endpoint node, telling it how many lanes and in which order should be
> used?
Yes.
--
Sakari Ailus
^ permalink raw reply
* Re: [RFC PATCH -next] MAINTAINERS: Update F: and X: entry ordering (was Re: [PATCH v2 6/6] MAINTAINERS: Add maintainers for MIPS core drivers)
From: Serge Semin @ 2020-06-02 9:51 UTC (permalink / raw)
To: Joe Perches
Cc: Serge Semin, Andy Shevchenko, Andrew Morton, Linus Torvalds,
Thomas Bogendoerfer, Thomas Gleixner, Greg Kroah-Hartman,
Alexey Malahov, Paul Burton, Rob Herring, Arnd Bergmann,
Jason Cooper, Marc Zyngier, Rafael J. Wysocki, Daniel Lezcano,
James Hogan, linux-mips, devicetree, Linux Kernel Mailing List
In-Reply-To: <2e96576791604862a11f094665b0c4e9c3263fd4.camel@perches.com>
Hello Joe
On Mon, Jun 01, 2020 at 11:22:58AM -0700, Joe Perches wrote:
> On Mon, 2020-06-01 at 19:04 +0300, Andy Shevchenko wrote:
> > On Mon, Jun 1, 2020 at 6:52 PM Serge Semin <Sergey.Semin@baikalelectronics.ru> wrote:
> > > On Mon, Jun 01, 2020 at 06:30:22PM +0300, Andy Shevchenko wrote:
> > > > On Mon, Jun 1, 2020 at 6:19 PM Serge Semin <Sergey.Semin@baikalelectronics.ru> wrote:
> > > > > On Mon, Jun 01, 2020 at 04:56:21PM +0300, Andy Shevchenko wrote:
> > > > > > On Mon, Jun 1, 2020 at 3:26 PM Serge Semin <Sergey.Semin@baikalelectronics.ru> wrote:
> > > > > > > Add myself as a maintainer of MIPS CPU and GIC IRQchip, MIPS GIC timer
> > > > > > > and MIPS CPS CPUidle drivers.
> > > > > > ...
> > > > > > > +MIPS CORE DRIVERS
> > > > > > > +M: Serge Semin <fancer.lancer@gmail.com>
> > > > > > > +L: linux-mips@vger.kernel.org
> > > > > > > +S: Supported
> > > > > > > +F: drivers/bus/mips_cdmm.c
> > > > > > > +F: drivers/irqchip/irq-mips-cpu.c
> > > > > > > +F: drivers/irqchip/irq-mips-gic.c
> > > > > > > +F: drivers/clocksource/mips-gic-timer.c
> > > > > > > +F: drivers/cpuidle/cpuidle-cps.c
> > > > > >
> > > > > > I think nowadays checkpatch.pl warns on wrong ordering in this data base.
> []
> > > Next time I won't forget that then. BTW the notes at the top of the MAINTAINERS
> > > file don't explicitly say about the files-list order. Only about the
> > > whole maintainers list entries order. Seeing the rest of the sub-entries like
> > > L:, M:, etc. aren't ordered then it's probably better to have an explicit
> > > statement, that files should be alphabetically listed, especially when
> > > checkpatch.pl starts warning about that.
> >
> > Joe, what do you think?
>
> Fine by me. Maybe something like the below.
>
> Another thing might be to intermix the F and X entries so that
> exclusions are more obviously against the F: entries.
>
> There aren't many MAINTAINERS lines changed when the modified
> parse-maintainers is run, but I think it reads better.
>
> It doesn't seem the last major reordering with parse-maintainers
> caused any significant issue for anyone.
I was also thinking about a text explaining the F: section order requirement.
Like this:
diff --git a/MAINTAINERS b/MAINTAINERS
index 865aeafee3b2..253f8f97891f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -111,7 +111,8 @@ Descriptions of section entries and preferred order
F: drivers/net/ all files in and below drivers/net
F: drivers/net/* all files in drivers/net, but not below
F: */net/* all files in "any top level directory"/net
- One pattern per line. Multiple F: lines acceptable.
+ One pattern per line. Multiple F: lines acceptable, but are
+ supposed to be listed in alphabetical order.
X: *Excluded* files and directories that are NOT maintained, same
rules as F:. Files exclusions are tested before file matches.
Can be useful for excluding a specific subdirectory, for instance:
The rest suggested by you is fine with me. Intermixing F and X seems reasonable
so the maintainers could group inclusion and exclusion sections together
with respect to the files/directories they refer to.
-Sergey
>
> I think having Linus run scripts/parse-maintainers.pl just before
> every release or every few releases would make this issue go away.
> ---
> MAINTAINERS | 1 +
> scripts/checkpatch.pl | 17 +++++++----------
> scripts/parse-maintainers.pl | 5 ++---
> 3 files changed, 10 insertions(+), 13 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b045b70e54df..4b53119504ff 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -118,6 +118,7 @@ Descriptions of section entries and preferred order
> F: net/
> X: net/ipv6/
> matches all files in and below net excluding net/ipv6/
> + F: and X: entries are intermixed in case sensitive alphabetic order
> N: Files and directories *Regex* patterns.
> N: [^a-z]tegra all files whose path contains tegra
> (not including files like integrator)
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index dd750241958b..499c85be0b2f 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -3099,16 +3099,13 @@ sub process {
> if ($curindex < 0) {
> WARN("MAINTAINERS_STYLE",
> "Unknown MAINTAINERS entry type: '$cur'\n" . $herecurr);
> - } else {
> - if ($previndex >= 0 && $curindex < $previndex) {
> - WARN("MAINTAINERS_STYLE",
> - "Misordered MAINTAINERS entry - list '$cur:' before '$prev:'\n" . $hereprev);
> - } elsif ((($prev eq 'F' && $cur eq 'F') ||
> - ($prev eq 'X' && $cur eq 'X')) &&
> - ($prevval cmp $curval) > 0) {
> - WARN("MAINTAINERS_STYLE",
> - "Misordered MAINTAINERS entry - list file patterns in alphabetic order\n" . $hereprev);
> - }
> + } elsif ($previndex >= 0 && $curindex < $previndex && !($prev =~ /[FX]/ && $cur =~ /[FX]/)) {
> + WARN("MAINTAINERS_STYLE",
> + "Misordered MAINTAINERS entry - list '$cur:' before '$prev:'\n" . $hereprev);
> + } elsif ((($prev =~ /[FX]/ && $cur =~ /[FX]/) &&
> + ($prevval cmp $curval) > 0)) {
> + WARN("MAINTAINERS_STYLE",
> + "Misordered MAINTAINERS entry - list F and X file patterns in alphabetic order\n" . $hereprev);
> }
> }
> }
> diff --git a/scripts/parse-maintainers.pl b/scripts/parse-maintainers.pl
> index 2ca4eb3f190d..8d2247a596f0 100755
> --- a/scripts/parse-maintainers.pl
> +++ b/scripts/parse-maintainers.pl
> @@ -84,9 +84,8 @@ sub by_pattern($$) {
> $a_index = 1000 if ($a_index == -1);
> $b_index = 1000 if ($b_index == -1);
>
> - if (($a1 =~ /^F$/ && $b1 =~ /^F$/) ||
> - ($a1 =~ /^X$/ && $b1 =~ /^X$/)) {
> - return $a cmp $b;
> + if (($a1 =~ /^[FX]$/ && $b1 =~ /^[FX]$/)) {
> + return substr($a, 1) cmp substr($b, 1);
> }
>
> if ($a_index < $b_index) {
>
>
^ permalink raw reply related
* Re: [PATCH 3/5] dt-bindings: reset: ocelot: Add documentation for 'microchip,reset-switch-core' property
From: Lars Povlsen @ 2020-06-02 9:49 UTC (permalink / raw)
To: Rob Herring
Cc: Lars Povlsen, Sebastian Reichel, SoC Team, Alexandre Belloni,
Microchip Linux Driver Support, linux-pm, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20200528022502.GA3234572@bogus>
Rob Herring writes:
> On Wed, May 13, 2020 at 03:08:40PM +0200, Lars Povlsen wrote:
>> This documents the 'microchip,reset-switch-core' property in the
>> ocelot-reset driver.
>>
>> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
>> ---
>> .../devicetree/bindings/power/reset/ocelot-reset.txt | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
>> index 4d530d8154848..20fff03753ad2 100644
>> --- a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
>> +++ b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
>> @@ -9,9 +9,15 @@ microchip Sparx5 armv8 SoC's.
>> Required Properties:
>> - compatible: "mscc,ocelot-chip-reset" or "microchip,sparx5-chip-reset"
>>
>> +Optional properties:
>> +- microchip,reset-switch-core : Perform a switch core reset at the
>> + time of driver load. This is may be used to initialize the switch
>> + core to a known state (before other drivers are loaded).
>
> How do you know when other drivers are loaded? This could be a module
> perhaps. Doesn't seem like something that belongs in DT.
>
The reset driver is loaded at postcore_initcall() time, which ensures it
is loaded before other drivers using the switch core. I noticed other
drivers do the same to do low-level system reset and initialization at
early boot time.
> Can this behavior be implied with "microchip,sparx5-chip-reset"?
Since we need to cater for both modus operandi, I would need two driver
compatible strings per platform, which scales worse than a single
property.
The "microchip,reset-switch-core" is a device configuration property
which tells the system (driver) how the hw should be handled. Since you
do not *always* want to reset the switch core (f.ex. when implementing
systems with warm reboot), I think it makes perfect sense - but I may be
biased off course :-)
Thank you for (all) of your comments, by the way!
---Lars
>
> Rob
--
Lars Povlsen,
Microchip
^ permalink raw reply
* Re: [PATCH v7 21/24] iommu/arm-smmu-v3: Add stall support for platform devices
From: Jean-Philippe Brucker @ 2020-06-02 9:38 UTC (permalink / raw)
To: Shameerali Kolothum Thodi
Cc: iommu@lists.linux-foundation.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org,
linux-mm@kvack.org, fenghua.yu@intel.com, kevin.tian@intel.com,
jgg@ziepe.ca, catalin.marinas@arm.com, robin.murphy@arm.com,
hch@infradead.org, zhangfei.gao@linaro.org,
felix.kuehling@amd.com, will@kernel.org, christian.koenig@amd.com
In-Reply-To: <4741b6c45d1a43b69041ecb5ce0be0d5@huawei.com>
Hi Shameer,
On Mon, Jun 01, 2020 at 12:42:15PM +0000, Shameerali Kolothum Thodi wrote:
> > /* IRQ and event handlers */
> > +static int arm_smmu_handle_evt(struct arm_smmu_device *smmu, u64 *evt)
> > +{
> > + int ret;
> > + u32 perm = 0;
> > + struct arm_smmu_master *master;
> > + bool ssid_valid = evt[0] & EVTQ_0_SSV;
> > + u8 type = FIELD_GET(EVTQ_0_ID, evt[0]);
> > + u32 sid = FIELD_GET(EVTQ_0_SID, evt[0]);
> > + struct iommu_fault_event fault_evt = { };
> > + struct iommu_fault *flt = &fault_evt.fault;
> > +
> > + /* Stage-2 is always pinned at the moment */
> > + if (evt[1] & EVTQ_1_S2)
> > + return -EFAULT;
> > +
> > + master = arm_smmu_find_master(smmu, sid);
> > + if (!master)
> > + return -EINVAL;
> > +
> > + if (evt[1] & EVTQ_1_READ)
> > + perm |= IOMMU_FAULT_PERM_READ;
> > + else
> > + perm |= IOMMU_FAULT_PERM_WRITE;
> > +
> > + if (evt[1] & EVTQ_1_EXEC)
> > + perm |= IOMMU_FAULT_PERM_EXEC;
> > +
> > + if (evt[1] & EVTQ_1_PRIV)
> > + perm |= IOMMU_FAULT_PERM_PRIV;
> > +
> > + if (evt[1] & EVTQ_1_STALL) {
> > + flt->type = IOMMU_FAULT_PAGE_REQ;
> > + flt->prm = (struct iommu_fault_page_request) {
> > + .flags = IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE,
> > + .pasid = FIELD_GET(EVTQ_0_SSID, evt[0]),
> > + .grpid = FIELD_GET(EVTQ_1_STAG, evt[1]),
> > + .perm = perm,
> > + .addr = FIELD_GET(EVTQ_2_ADDR, evt[2]),
> > + };
> > +
>
> > + if (ssid_valid)
> > + flt->prm.flags |= IOMMU_FAULT_PAGE_REQUEST_PASID_VALID;
>
> Do we need to set this for STALL mode only support? I had an issue with this
> being set on a vSVA POC based on our D06 zip device(which is a "fake " pci dev
> that supports STALL mode but no PRI). The issue is, CMDQ_OP_RESUME doesn't
> have any ssid or SSV params and works on sid and stag only.
I don't understand the problem, arm_smmu_page_response() doesn't set SSID
or SSV when sending a CMDQ_OP_RESUME. Could you detail the flow of a stall
event and RESUME command in your prototype? Are you getting issues with
the host driver or the guest driver?
We do need to forward the SSV flag all the way to the guest driver, so the
guest can find the faulting address space using the SSID. Once the guest
handled the fault, then we don't send the SSID back to the host as part of
the RESUME command.
Thanks,
Jean
> Hence, it is difficult for
> Qemu SMMUv3 to populate this fields while preparing a page response. I can see
> that this flag is being checked in iopf_handle_single() (patch 04/24) as well. For POC,
> I used a temp fix[1] to work around this. Please let me know your thoughts.
>
> Thanks,
> Shameer
>
> 1. https://github.com/hisilicon/kernel-dev/commit/99ff96146e924055f38d97a5897e4becfa378d15
>
^ permalink raw reply
* R: [PATCH v4 08/10] PCI: qcom: Add ipq8064 rev2 variant and set tx term offset
From: ansuelsmth @ 2020-06-02 9:34 UTC (permalink / raw)
To: 'Rob Herring'
Cc: 'Bjorn Andersson', 'Sham Muthayyan',
'Andy Gross', 'Bjorn Helgaas',
'Mark Rutland', 'Stanimir Varbanov',
'Lorenzo Pieralisi', 'Andrew Murray',
'Philipp Zabel', linux-arm-msm, linux-pci, devicetree,
linux-kernel
In-Reply-To: <20200601210844.GA1494556@bogus>
> -----Messaggio originale-----
> Da: Rob Herring <robh@kernel.org>
> Inviato: lunedì 1 giugno 2020 23:09
> A: Ansuel Smith <ansuelsmth@gmail.com>
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>; Sham Muthayyan
> <smuthayy@codeaurora.org>; Andy Gross <agross@kernel.org>; Bjorn
> Helgaas <bhelgaas@google.com>; Mark Rutland
> <mark.rutland@arm.com>; Stanimir Varbanov <svarbanov@mm-sol.com>;
> Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>; Andrew Murray
> <amurray@thegoodpenguin.co.uk>; Philipp Zabel
> <p.zabel@pengutronix.de>; linux-arm-msm@vger.kernel.org; linux-
> pci@vger.kernel.org; devicetree@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Oggetto: Re: [PATCH v4 08/10] PCI: qcom: Add ipq8064 rev2 variant and
> set tx term offset
>
> On Thu, May 14, 2020 at 10:07:09PM +0200, Ansuel Smith wrote:
> > Add tx term offset support to pcie qcom driver need in some revision of
> > the ipq806x SoC. Ipq8064 have tx term offset set to 7. Ipq8064-v2
> revision
> > and ipq8065 have the tx term offset set to 0.
>
> Seems like this should be 2 patches or why isn't 'Ipq8064 have tx term
> offset set to 7' done in the prior patch? One tweak is needed for
> stable, but this isn't?
>
Ok i will split this in 2 patch and set for stable the tx term patch.
> >
> > Signed-off-by: Sham Muthayyan <smuthayy@codeaurora.org>
> > Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> > ---
> > drivers/pci/controller/dwc/pcie-qcom.c | 18 ++++++++++++++++--
> > 1 file changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-qcom.c
> b/drivers/pci/controller/dwc/pcie-qcom.c
> > index f5398b0d270c..ab6f1bdd24c3 100644
> > --- a/drivers/pci/controller/dwc/pcie-qcom.c
> > +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> > @@ -45,6 +45,9 @@
> > #define PCIE_CAP_CPL_TIMEOUT_DISABLE 0x10
> >
> > #define PCIE20_PARF_PHY_CTRL 0x40
> > +#define PHY_CTRL_PHY_TX0_TERM_OFFSET_MASK GENMASK(20,
> 16)
> > +#define PHY_CTRL_PHY_TX0_TERM_OFFSET(x) ((x) << 16)
> > +
> > #define PCIE20_PARF_PHY_REFCLK 0x4C
> > #define PHY_REFCLK_SSP_EN BIT(16)
> > #define PHY_REFCLK_USE_PAD BIT(12)
> > @@ -363,7 +366,8 @@ static int qcom_pcie_init_2_1_0(struct
> qcom_pcie *pcie)
> > val &= ~BIT(0);
> > writel(val, pcie->parf + PCIE20_PARF_PHY_CTRL);
> >
> > - if (of_device_is_compatible(node, "qcom,pcie-ipq8064")) {
> > + if (of_device_is_compatible(node, "qcom,pcie-ipq8064") |
> > + of_device_is_compatible(node, "qcom,pcie-ipq8064-v2")) {
> > writel(PCS_DEEMPH_TX_DEEMPH_GEN1(24) |
> > PCS_DEEMPH_TX_DEEMPH_GEN2_3_5DB(24) |
> > PCS_DEEMPH_TX_DEEMPH_GEN2_6DB(34),
> > @@ -374,9 +378,18 @@ static int qcom_pcie_init_2_1_0(struct
> qcom_pcie *pcie)
> > writel(PHY_RX0_EQ(4), pcie->parf +
> PCIE20_PARF_CONFIG_BITS);
> > }
> >
> > + if (of_device_is_compatible(node, "qcom,pcie-ipq8064")) {
> > + /* set TX termination offset */
> > + val = readl(pcie->parf + PCIE20_PARF_PHY_CTRL);
> > + val &= ~PHY_CTRL_PHY_TX0_TERM_OFFSET_MASK;
> > + val |= PHY_CTRL_PHY_TX0_TERM_OFFSET(7);
> > + writel(val, pcie->parf + PCIE20_PARF_PHY_CTRL);
> > + }
> > +
> > /* enable external reference clock */
> > val = readl(pcie->parf + PCIE20_PARF_PHY_REFCLK);
> > - val |= BIT(16);
> > + val &= ~PHY_REFCLK_USE_PAD;
> > + val |= PHY_REFCLK_SSP_EN;
> > writel(val, pcie->parf + PCIE20_PARF_PHY_REFCLK);
> >
> > /* wait for clock acquisition */
> > @@ -1452,6 +1465,7 @@ static int qcom_pcie_probe(struct
> platform_device *pdev)
> > static const struct of_device_id qcom_pcie_match[] = {
> > { .compatible = "qcom,pcie-apq8084", .data = &ops_1_0_0 },
> > { .compatible = "qcom,pcie-ipq8064", .data = &ops_2_1_0 },
> > + { .compatible = "qcom,pcie-ipq8064-v2", .data = &ops_2_1_0 },
> > { .compatible = "qcom,pcie-apq8064", .data = &ops_2_1_0 },
> > { .compatible = "qcom,pcie-msm8996", .data = &ops_2_3_2 },
> > { .compatible = "qcom,pcie-ipq8074", .data = &ops_2_3_3 },
> > --
> > 2.25.1
> >
^ permalink raw reply
* R: [PATCH v4 08/10] PCI: qcom: Add ipq8064 rev2 variant and set tx term offset
From: ansuelsmth @ 2020-06-02 9:31 UTC (permalink / raw)
To: 'Stanimir Varbanov', 'Bjorn Andersson'
Cc: 'Sham Muthayyan', 'Andy Gross',
'Bjorn Helgaas', 'Rob Herring',
'Mark Rutland', 'Lorenzo Pieralisi',
'Andrew Murray', 'Philipp Zabel', linux-arm-msm,
linux-pci, devicetree, linux-kernel
In-Reply-To: <e672c516-29a4-e7d2-ee8b-3bce73bdf4e2@mm-sol.com>
> -----Messaggio originale-----
> Da: Stanimir Varbanov <svarbanov@mm-sol.com>
> Inviato: martedì 2 giugno 2020 09:54
> A: Ansuel Smith <ansuelsmth@gmail.com>; Bjorn Andersson
> <bjorn.andersson@linaro.org>
> Cc: Sham Muthayyan <smuthayy@codeaurora.org>; Andy Gross
> <agross@kernel.org>; Bjorn Helgaas <bhelgaas@google.com>; Rob Herring
> <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; Lorenzo
> Pieralisi <lorenzo.pieralisi@arm.com>; Andrew Murray
> <amurray@thegoodpenguin.co.uk>; Philipp Zabel
> <p.zabel@pengutronix.de>; linux-arm-msm@vger.kernel.org; linux-
> pci@vger.kernel.org; devicetree@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Oggetto: Re: [PATCH v4 08/10] PCI: qcom: Add ipq8064 rev2 variant and
> set tx term offset
>
> Hi,
>
> On 5/14/20 11:07 PM, Ansuel Smith wrote:
> > Add tx term offset support to pcie qcom driver need in some revision of
> > the ipq806x SoC. Ipq8064 have tx term offset set to 7. Ipq8064-v2
> revision
> > and ipq8065 have the tx term offset set to 0.
> >
> > Signed-off-by: Sham Muthayyan <smuthayy@codeaurora.org>
> > Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> > ---
> > drivers/pci/controller/dwc/pcie-qcom.c | 18 ++++++++++++++++--
> > 1 file changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-qcom.c
> b/drivers/pci/controller/dwc/pcie-qcom.c
> > index f5398b0d270c..ab6f1bdd24c3 100644
> > --- a/drivers/pci/controller/dwc/pcie-qcom.c
> > +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> > @@ -45,6 +45,9 @@
> > #define PCIE_CAP_CPL_TIMEOUT_DISABLE 0x10
> >
> > #define PCIE20_PARF_PHY_CTRL 0x40
> > +#define PHY_CTRL_PHY_TX0_TERM_OFFSET_MASK GENMASK(20,
> 16)
>
> I see you changed the mask, did you found the issue in previous v3 mask
> and shift?
>
I checked the original code and the old GENMASK declaration was wrong as you
suggested.
> > +#define PHY_CTRL_PHY_TX0_TERM_OFFSET(x) ((x) << 16)
> > +
> > #define PCIE20_PARF_PHY_REFCLK 0x4C
> > #define PHY_REFCLK_SSP_EN BIT(16)
> > #define PHY_REFCLK_USE_PAD BIT(12)
> > @@ -363,7 +366,8 @@ static int qcom_pcie_init_2_1_0(struct
> qcom_pcie *pcie)
> > val &= ~BIT(0);
> > writel(val, pcie->parf + PCIE20_PARF_PHY_CTRL);
> >
> > - if (of_device_is_compatible(node, "qcom,pcie-ipq8064")) {
> > + if (of_device_is_compatible(node, "qcom,pcie-ipq8064") |
>
> this should be logical OR
>
Will change in v5 since I will have to split this
> > + of_device_is_compatible(node, "qcom,pcie-ipq8064-v2")) {
> > writel(PCS_DEEMPH_TX_DEEMPH_GEN1(24) |
> > PCS_DEEMPH_TX_DEEMPH_GEN2_3_5DB(24) |
> > PCS_DEEMPH_TX_DEEMPH_GEN2_6DB(34),
> > @@ -374,9 +378,18 @@ static int qcom_pcie_init_2_1_0(struct
> qcom_pcie *pcie)
> > writel(PHY_RX0_EQ(4), pcie->parf +
> PCIE20_PARF_CONFIG_BITS);
> > }
> >
> > + if (of_device_is_compatible(node, "qcom,pcie-ipq8064")) {
> > + /* set TX termination offset */
> > + val = readl(pcie->parf + PCIE20_PARF_PHY_CTRL);
> > + val &= ~PHY_CTRL_PHY_TX0_TERM_OFFSET_MASK;
> > + val |= PHY_CTRL_PHY_TX0_TERM_OFFSET(7);
> > + writel(val, pcie->parf + PCIE20_PARF_PHY_CTRL);
> > + }
> > +
> > /* enable external reference clock */
> > val = readl(pcie->parf + PCIE20_PARF_PHY_REFCLK);
> > - val |= BIT(16);
> > + val &= ~PHY_REFCLK_USE_PAD;
> > + val |= PHY_REFCLK_SSP_EN;
> > writel(val, pcie->parf + PCIE20_PARF_PHY_REFCLK);
> >
> > /* wait for clock acquisition */
> > @@ -1452,6 +1465,7 @@ static int qcom_pcie_probe(struct
> platform_device *pdev)
> > static const struct of_device_id qcom_pcie_match[] = {
> > { .compatible = "qcom,pcie-apq8084", .data = &ops_1_0_0 },
> > { .compatible = "qcom,pcie-ipq8064", .data = &ops_2_1_0 },
> > + { .compatible = "qcom,pcie-ipq8064-v2", .data = &ops_2_1_0 },
> > { .compatible = "qcom,pcie-apq8064", .data = &ops_2_1_0 },
> > { .compatible = "qcom,pcie-msm8996", .data = &ops_2_3_2 },
> > { .compatible = "qcom,pcie-ipq8074", .data = &ops_2_3_3 },
> >
>
> --
> regards,
> Stan
^ permalink raw reply
* Re: [PATCH v5 00/11] dmaengine: dw: Take Baikal-T1 SoC DW DMAC peculiarities into account
From: Serge Semin @ 2020-06-02 9:27 UTC (permalink / raw)
To: Vinod Koul, Viresh Kumar
Cc: Serge Semin, Alexey Malahov, Maxim Kaurkin, Pavel Parkhomenko,
Ramil Zaripov, Ekaterina Skachko, Vadim Vlasov, Alexey Kolotnikov,
Thomas Bogendoerfer, Arnd Bergmann, Andy Shevchenko, Rob Herring,
linux-mips, dmaengine, devicetree, linux-kernel
In-Reply-To: <20200529144054.4251-1-Sergey.Semin@baikalelectronics.ru>
Vinod, Viresh
Andy's finished his review. So all the patches of the series (except one rather
decorative, which we have different opinion of) are tagged by him. Since merge
window is about to be opened please consider to merge the series in. I'll really
need it to be in the kernel to provide the noLLP-problem fix for the Dw APB SSI
in 5.8.
-Sergey
On Fri, May 29, 2020 at 05:40:43PM +0300, Serge Semin wrote:
> Baikal-T1 SoC has an DW DMAC on-board to provide a Mem-to-Mem, low-speed
> peripherals Dev-to-Mem and Mem-to-Dev functionality. Mostly it's compatible
> with currently implemented in the kernel DW DMAC driver, but there are some
> peculiarities which must be taken into account in order to have the device
> fully supported.
>
> First of all traditionally we replaced the legacy plain text-based dt-binding
> file with yaml-based one. Secondly Baikal-T1 DW DMA Controller provides eight
> channels, which alas have different max burst length configuration.
> In particular first two channels may burst up to 128 bits (16 bytes) at a time
> while the rest of them just up to 32 bits. We must make sure that the DMA
> subsystem doesn't set values exceeding these limitations otherwise the
> controller will hang up. In third currently we discovered the problem in using
> the DW APB SPI driver together with DW DMAC. The problem happens if there is no
> natively implemented multi-block LLP transfers support and the SPI-transfer
> length exceeds the max lock size. In this case due to asynchronous handling of
> Tx- and Rx- SPI transfers interrupt we might end up with Dw APB SSI Rx FIFO
> overflow. So if DW APB SSI (or any other DMAC service consumer) intends to use
> the DMAC to asynchronously execute the transfers we'd have to at least warn
> the user of the possible errors. In forth it's worth to set the DMA device max
> segment size with max block size config specific to the DW DMA controller. It
> shall help the DMA clients to create size-optimized SG-list items for the
> controller. This in turn will cause less dw_desc allocations, less LLP
> reinitializations, better DMA device performance.
>
> Finally there is a bug in the algorithm of the nollp flag detection.
> In particular even if DW DMAC parameters state the multi-block transfers
> support there is still HC_LLP (hardcode LLP) flag, which if set makes expected
> by the driver true multi-block LLP functionality unusable. This happens cause'
> if HC_LLP flag is set the LLP registers will be hardcoded to zero so the
> contiguous multi-block transfers will be only supported. We must take the
> flag into account when detecting the LLP support otherwise the driver just
> won't work correctly.
>
> This patchset is rebased and tested on the mainline Linux kernel 5.7-rc4:
> 0e698dfa2822 ("Linux 5.7-rc4")
> tag: v5.7-rc4
>
> Changelog v2:
> - Rearrange SoBs.
> - Move $ref to the root level of the properties. So do do with the
> constraints in the DT binding.
> - Replace "additionalProperties: false" with "unevaluatedProperties: false"
> property in the DT binding file.
> - Discard default settings defined out of property enum constraint.
> - Set default max-burst-len to 256 TR-WIDTH words in the DT binding.
> - Discard noLLP and block_size accessors.
> - Set max segment size of the DMA device structure with the DW DMA block size
> config.
> - Print warning if noLLP flag is set.
> - Discard max burst length accessor.
> - Add comment about why hardware accelerated LLP list support depends
> on both MBLK_EN and HC_LLP configs setting.
> - Use explicit bits state comparison operator in noLLP flag setting.
>
> Link: https://lore.kernel.org/dmaengine/20200508105304.14065-1-Sergey.Semin@baikalelectronics.ru/
> Changelog v3:
> - Use the block_size found for the very first channel instead of looking for
> the maximum of maximum block sizes.
> - Don't define device-specific device_dma_parameters object, since it has
> already been defined by the platform device core.
> - Add more details into the property description about what limitations
> snps,max-burst-len defines.
> - Move commit fb7e3bbfc830 ("dmaengine: dw: Take HC_LLP flag into account for
> noLLP auto-config") to the head of the series.
> - Add a new patch "dmaengine: Introduce min burst length capability" as a
> result of the discussion with Vinod and Andy regarding the burst length
> capability.
> - Add a new patch "dmaengine: Introduce max SG list entries capability"
> suggested by Andy.
> - Add a new patch "dmaengine: Introduce DMA-device device_caps callback" as
> a result of the discussion with Vinud and Andy in the framework of DW DMA
> burst and LLP capabilities.
> - Add a new patch "dmaengine: dw: Add dummy device_caps callback" as a
> preparation commit before setting the max_burst and max_sg_nents
> DW DMA capabilities.
> - Override the slave channel max_burst capability instead of calculating
> the minimum value of max burst lengths and setting the DMA-device
> generic capability.
> - Add a new patch "dmaengine: dw: Initialize max_sg_nents with nollp flag".
> This is required to fix the DW APB SSI issue of the Tx and Rx DMA
> channels de-synchronization.
>
> Link: https://lore.kernel.org/dmaengine/20200526225022.20405-1-Sergey.Semin@baikalelectronics.ru/
> Changelog v4:
> - Use explicit if-else statement when assigning the max_sg_nents field.
> - Clamp the dst and src burst lengths in the generic dwc_config() method
> instead of doing that in the encode_maxburst() callback.
> - Define max_burst with u32 type in struct dw_dma_platform_data.
> - Perform of_property_read_u32_array() with the platform data
> max_burst member passed directly.
> - Add a new patch "dmaengine: dw: Initialize min_burst capability",
> which initializes the min_burst capability with 1.
> - Fix of->if typo. It should be definitely "of" in the max_sg_list
> capability description.
>
> Link: https://lore.kernel.org/dmaengine/20200528222401.26941-1-Sergey.Semin@baikalelectronics.ru
> Changelog v5:
> - Introduce macro with extreme min and max burst lengths supported by the
> DW DMA controller. Define them in the patch with default min and max burst
> length iintializations.
> - Initialize max_burst length capability with extreme burst length supported
> by the DW DMAC IP-core.
> - Move DW_DMA_MAX_BURST macro definition to the patch "dmaengine: dw:
> Initialize min and max burst DMA device capability".
> - Add in-line comment at the point of the device_caps callback invocation.
> - Add doc-comment for the device_caps member of struct dma_device
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Maxim Kaurkin <Maxim.Kaurkin@baikalelectronics.ru>
> Cc: Pavel Parkhomenko <Pavel.Parkhomenko@baikalelectronics.ru>
> Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
> Cc: Ekaterina Skachko <Ekaterina.Skachko@baikalelectronics.ru>
> Cc: Vadim Vlasov <V.Vlasov@baikalelectronics.ru>
> Cc: Alexey Kolotnikov <Alexey.Kolotnikov@baikalelectronics.ru>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: linux-mips@vger.kernel.org
> Cc: dmaengine@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
>
> Serge Semin (11):
> dt-bindings: dma: dw: Convert DW DMAC to DT binding
> dt-bindings: dma: dw: Add max burst transaction length property
> dmaengine: Introduce min burst length capability
> dmaengine: Introduce max SG list entries capability
> dmaengine: Introduce DMA-device device_caps callback
> dmaengine: dw: Take HC_LLP flag into account for noLLP auto-config
> dmaengine: dw: Set DMA device max segment size parameter
> dmaengine: dw: Add dummy device_caps callback
> dmaengine: dw: Initialize min and max burst DMA device capability
> dmaengine: dw: Introduce max burst length hw config
> dmaengine: dw: Initialize max_sg_nents capability
>
> .../bindings/dma/snps,dma-spear1340.yaml | 176 ++++++++++++++++++
> .../devicetree/bindings/dma/snps-dma.txt | 69 -------
> drivers/dma/dmaengine.c | 12 ++
> drivers/dma/dw/core.c | 48 ++++-
> drivers/dma/dw/of.c | 5 +
> drivers/dma/dw/regs.h | 3 +
> include/linux/dmaengine.h | 16 ++
> include/linux/platform_data/dma-dw.h | 5 +
> 8 files changed, 264 insertions(+), 70 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
> delete mode 100644 Documentation/devicetree/bindings/dma/snps-dma.txt
>
> --
> 2.26.2
>
^ permalink raw reply
* Re: [PATCH 05/14] dt-bindings: arm: sparx5: Add documentation for Microchip Sparx5 SoC
From: Lars Povlsen @ 2020-06-02 9:10 UTC (permalink / raw)
To: Rob Herring
Cc: Lars Povlsen, SoC Team, Arnd Bergmann, Stephen Boyd,
Linus Walleij, Steen Hegelund, Microchip Linux Driver Support,
Olof Johansson, Michael Turquette, devicetree, linux-clk,
linux-gpio, linux-arm-kernel, linux-kernel, Alexandre Belloni
In-Reply-To: <20200528021137.GA3214411@bogus>
Rob Herring writes:
> On Wed, May 13, 2020 at 02:55:23PM +0200, Lars Povlsen wrote:
>> This adds the main Sparx5 SoC DT documentation file, with information
>> abut the supported board types.
>>
>> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
>> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
>> ---
>> .../bindings/arm/microchip,sparx5.yaml | 87 +++++++++++++++++++
>> 1 file changed, 87 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/arm/microchip,sparx5.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/arm/microchip,sparx5.yaml b/Documentation/devicetree/bindings/arm/microchip,sparx5.yaml
>> new file mode 100644
>> index 0000000000000..83b36d1217988
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/microchip,sparx5.yaml
>> @@ -0,0 +1,87 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/arm/microchip,sparx5.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Microchip Sparx5 Boards Device Tree Bindings
>> +
>> +maintainers:
>> + - Lars Povlsen <lars.povlsen@microchip.com>
>> +
>> +description: |+
>> + The Microchip Sparx5 SoC is a ARMv8-based used in a family of
>> + gigabit TSN-capable gigabit switches.
>> +
>> + The SparX-5 Ethernet switch family provides a rich set of switching
>> + features such as advanced TCAM-based VLAN and QoS processing
>> + enabling delivery of differentiated services, and security through
>> + TCAM-based frame processing using versatile content aware processor
>> + (VCAP)
>> +
>> +properties:
>> + $nodename:
>> + const: '/'
>> + compatible:
>> + oneOf:
>> + - description: The Sparx5 pcb125 board is a modular board,
>> + which has both spi-nor and eMMC storage. The modular design
>> + allows for connection of different network ports.
>> + items:
>> + - const: microchip,sparx5-pcb125
>> + - const: microchip,sparx5
>> +
>> + - description: The Sparx5 pcb134 is a pizzabox form factor
>> + gigabit switch with 20 SFP ports. It features spi-nor and
>> + either spi-nand or eMMC storage (mount option).
>> + items:
>> + - const: microchip,sparx5-pcb134
>> + - const: microchip,sparx5
>> +
>> + - description: The Sparx5 pcb135 is a pizzabox form factor
>> + gigabit switch with 48+4 Cu ports. It features spi-nor and
>> + either spi-nand or eMMC storage (mount option).
>> + items:
>> + - const: microchip,sparx5-pcb135
>> + - const: microchip,sparx5
>> +
>> + axi@600000000:
>> + type: object
>> + description: the root node in the Sparx5 platforms must contain
>> + an axi bus child node. They are always at physical address
>> + 0x600000000 in all the Sparx5 variants.
>> + properties:
>> + compatible:
>> + items:
>> + - const: simple-bus
>> + reg:
>> + maxItems: 1
>
> simple-bus doesn't have 'reg'. If there's bus registers, then it's not
> simple.
>
Ooops, that's a leftover. I'll remove.
>> +
>> + required:
>> + - compatible
>> + - reg
>> +
>> +patternProperties:
>> + "^syscon@[0-9a-f]+$":
>
> This should be under a bus node.
I thought it was? But anyway, with the change below I guess the entire
block goes away.
>
>> + description: All Sparx5 boards must provide a system controller,
>> + typically under the axi bus node. It contain reset registers and
>> + other system control.
>> + type: object
>> + properties:
>> + compatible:
>> + items:
>> + - const: microchip,sparx5-cpu-syscon
>> + - const: syscon
>
> This probably should be in its own document. If really this simple,
> there's already syscon.yaml you can add to.
Good suggestion, I'll add it to mfd/syscon.yaml then.
>
>> + reg:
>> + maxItems: 1
>> +
>> + required:
>> + - compatible
>> + - reg
>> +
>> +required:
>> + - compatible
>> + - axi@600000000
>> + - syscon@600000000
>> +
>> +...
>> --
>> 2.26.2
--
Lars Povlsen,
Microchip
^ permalink raw reply
* Re: [PATCH v2 04/12] iio: imu: inv_icm42600: add gyroscope IIO device
From: Jean-Baptiste Maneyrol @ 2020-06-02 9:10 UTC (permalink / raw)
To: Jonathan Cameron
Cc: robh+dt@kernel.org, robh@kernel.org, mchehab+huawei@kernel.org,
davem@davemloft.net, gregkh@linuxfoundation.org,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20200531125415.6904a94d@archlinux>
Hi Jonathan,
for the calibration bias, value is expressed in g unit, fixed, independant from any scale value.
So I can switch to g instead of SI unit, but this will still not be like raw data which are dependent of the scale value. That's why I used SI units.
Another solution, would be to adapt the value depending on the scale setting. So that it will correspond to raw data. But this also invovles complex computation.
Tell me what you prefer.
Thanks,
JB
From: Jonathan Cameron <jic23@kernel.org>
Sent: Sunday, May 31, 2020 13:54
To: Jean-Baptiste Maneyrol <JManeyrol@invensense.com>
Cc: robh+dt@kernel.org <robh+dt@kernel.org>; robh@kernel.org <robh@kernel.org>; mchehab+huawei@kernel.org <mchehab+huawei@kernel.org>; davem@davemloft.net <davem@davemloft.net>; gregkh@linuxfoundation.org <gregkh@linuxfoundation.org>; linux-iio@vger.kernel.org <linux-iio@vger.kernel.org>; devicetree@vger.kernel.org <devicetree@vger.kernel.org>; linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 04/12] iio: imu: inv_icm42600: add gyroscope IIO device
CAUTION: This email originated from outside of the organization. Please make sure the sender is who they say they are and do not click links or open attachments unless you recognize the sender and know the content is safe.
On Wed, 27 May 2020 20:57:03 +0200
Jean-Baptiste Maneyrol <jmaneyrol@invensense.com> wrote:
> Add IIO device for gyroscope sensor with data polling interface.
> Attributes: raw, scale, sampling_frequency, calibbias.
>
> Gyroscope in low noise mode.
>
> Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Unusual to have a calibration offset specified in output units,
which contributes a lot of the complexity in here.
Normally those are strictly front end (output of some calibration DAC).
So if they have units (and often they don't) I'd expect them to be
the same as _raw.
We need to tidy up the docs on this though as it doesn't express
any sort of preference. It's hard to be specific as often the calibration
scales are defined - they are just like tweaking a POT on an analog
sensor board.
A few trivial other things inline, including a suggestion to modify
the layering of the driver a tiny bit during probe.
Thanks,
Jonathan
> ---
> drivers/iio/imu/inv_icm42600/inv_icm42600.h | 6 +
> .../iio/imu/inv_icm42600/inv_icm42600_core.c | 4 +
> .../iio/imu/inv_icm42600/inv_icm42600_gyro.c | 600 ++++++++++++++++++
> 3 files changed, 610 insertions(+)
> create mode 100644 drivers/iio/imu/inv_icm42600/inv_icm42600_gyro.c
>
> diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600.h b/drivers/iio/imu/inv_icm42600/inv_icm42600.h
> index 14c8ef152418..c1023d59b37b 100644
> --- a/drivers/iio/imu/inv_icm42600/inv_icm42600.h
> +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600.h
> @@ -120,6 +120,8 @@ struct inv_icm42600_suspended {
> * @orientation: sensor chip orientation relative to main hardware.
> * @conf: chip sensors configurations.
> * @suspended: suspended sensors configuration.
> + * @indio_gyro: gyroscope IIO device.
> + * @buffer: data transfer buffer aligned for DMA.
> */
> struct inv_icm42600_state {
> struct mutex lock;
> @@ -131,6 +133,8 @@ struct inv_icm42600_state {
> struct iio_mount_matrix orientation;
> struct inv_icm42600_conf conf;
> struct inv_icm42600_suspended suspended;
> + struct iio_dev *indio_gyro;
> + uint8_t buffer[2] ____cacheline_aligned;
> };
>
> /* Virtual register addresses: @bank on MSB (4 upper bits), @address on LSB */
> @@ -369,4 +373,6 @@ int inv_icm42600_debugfs_reg(struct iio_dev *indio_dev, unsigned int reg,
> int inv_icm42600_core_probe(struct regmap *regmap, int chip,
> inv_icm42600_bus_setup bus_setup);
>
> +int inv_icm42600_gyro_init(struct inv_icm42600_state *st);
> +
> #endif
> diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c b/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c
> index 81b171d6782c..dccb7bcc782e 100644
> --- a/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c
> +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c
> @@ -510,6 +510,10 @@ int inv_icm42600_core_probe(struct regmap *regmap, int chip,
> if (ret)
> return ret;
>
> + ret = inv_icm42600_gyro_init(st);
> + if (ret)
> + return ret;
> +
> /* setup runtime power management */
> ret = pm_runtime_set_active(dev);
> if (ret)
> diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_gyro.c b/drivers/iio/imu/inv_icm42600/inv_icm42600_gyro.c
> new file mode 100644
> index 000000000000..9d9672989b23
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_gyro.c
> @@ -0,0 +1,600 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2020 Invensense, Inc.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/device.h>
> +#include <linux/mutex.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/regmap.h>
> +#include <linux/delay.h>
> +#include <linux/math64.h>
> +#include <linux/iio/iio.h>
> +
> +#include "inv_icm42600.h"
> +
> +#define INV_ICM42600_GYRO_CHAN(_modifier, _index, _ext_info) \
> + { \
> + .type = IIO_ANGL_VEL, \
> + .modified = 1, \
> + .channel2 = _modifier, \
> + .info_mask_separate = \
> + BIT(IIO_CHAN_INFO_RAW) | \
> + BIT(IIO_CHAN_INFO_CALIBBIAS), \
> + .info_mask_shared_by_type = \
> + BIT(IIO_CHAN_INFO_SCALE), \
> + .info_mask_shared_by_type_available = \
> + BIT(IIO_CHAN_INFO_SCALE) | \
> + BIT(IIO_CHAN_INFO_CALIBBIAS), \
> + .info_mask_shared_by_all = \
> + BIT(IIO_CHAN_INFO_SAMP_FREQ), \
> + .info_mask_shared_by_all_available = \
> + BIT(IIO_CHAN_INFO_SAMP_FREQ), \
> + .scan_index = _index, \
> + .scan_type = { \
> + .sign = 's', \
> + .realbits = 16, \
> + .storagebits = 16, \
> + .endianness = IIO_BE, \
> + }, \
> + .ext_info = _ext_info, \
> + }
> +
> +enum inv_icm42600_gyro_scan {
> + INV_ICM42600_GYRO_SCAN_X,
> + INV_ICM42600_GYRO_SCAN_Y,
> + INV_ICM42600_GYRO_SCAN_Z,
> +};
> +
> +static const struct iio_chan_spec_ext_info inv_icm42600_gyro_ext_infos[] = {
> + IIO_MOUNT_MATRIX(IIO_SHARED_BY_ALL, inv_icm42600_get_mount_matrix),
> + {},
> +};
> +
> +static const struct iio_chan_spec inv_icm42600_gyro_channels[] = {
> + INV_ICM42600_GYRO_CHAN(IIO_MOD_X, INV_ICM42600_GYRO_SCAN_X,
> + inv_icm42600_gyro_ext_infos),
> + INV_ICM42600_GYRO_CHAN(IIO_MOD_Y, INV_ICM42600_GYRO_SCAN_Y,
> + inv_icm42600_gyro_ext_infos),
> + INV_ICM42600_GYRO_CHAN(IIO_MOD_Z, INV_ICM42600_GYRO_SCAN_Z,
> + inv_icm42600_gyro_ext_infos),
> +};
> +
> +static int inv_icm42600_gyro_read_sensor(struct inv_icm42600_state *st,
> + struct iio_chan_spec const *chan,
> + int16_t *val)
> +{
> + struct device *dev = regmap_get_device(st->map);
> + struct inv_icm42600_sensor_conf conf = INV_ICM42600_SENSOR_CONF_INIT;
> + unsigned int reg;
> + __be16 *data;
> + int ret;
> +
> + if (chan->type != IIO_ANGL_VEL)
> + return -EINVAL;
> +
> + switch (chan->channel2) {
> + case IIO_MOD_X:
> + reg = INV_ICM42600_REG_GYRO_DATA_X;
> + break;
> + case IIO_MOD_Y:
> + reg = INV_ICM42600_REG_GYRO_DATA_Y;
> + break;
> + case IIO_MOD_Z:
> + reg = INV_ICM42600_REG_GYRO_DATA_Z;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + pm_runtime_get_sync(dev);
> + mutex_lock(&st->lock);
> +
> + /* enable gyro sensor */
> + conf.mode = INV_ICM42600_SENSOR_MODE_LOW_NOISE;
> + ret = inv_icm42600_set_gyro_conf(st, &conf, NULL);
> + if (ret)
> + goto exit;
> +
> + /* read gyro register data */
> + data = (__be16 *)&st->buffer[0];
> + ret = regmap_bulk_read(st->map, reg, data, sizeof(*data));
> + if (ret)
> + goto exit;
> +
> + *val = (int16_t)be16_to_cpup(data);
> + if (*val == INV_ICM42600_DATA_INVALID)
> + ret = -EINVAL;
> +exit:
> + mutex_unlock(&st->lock);
> + pm_runtime_mark_last_busy(dev);
> + pm_runtime_put_autosuspend(dev);
> + return ret;
> +}
> +
> +/* IIO format int + nano */
> +static const int inv_icm42600_gyro_scale[] = {
> + /* +/- 2000dps => 0.001065264 rad/s */
> + [2 * INV_ICM42600_GYRO_FS_2000DPS] = 0,
> + [2 * INV_ICM42600_GYRO_FS_2000DPS + 1] = 1065264,
> + /* +/- 1000dps => 0.000532632 rad/s */
> + [2 * INV_ICM42600_GYRO_FS_1000DPS] = 0,
> + [2 * INV_ICM42600_GYRO_FS_1000DPS + 1] = 532632,
> + /* +/- 500dps => 0.000266316 rad/s */
> + [2 * INV_ICM42600_GYRO_FS_500DPS] = 0,
> + [2 * INV_ICM42600_GYRO_FS_500DPS + 1] = 266316,
> + /* +/- 250dps => 0.000133158 rad/s */
> + [2 * INV_ICM42600_GYRO_FS_250DPS] = 0,
> + [2 * INV_ICM42600_GYRO_FS_250DPS + 1] = 133158,
> + /* +/- 125dps => 0.000066579 rad/s */
> + [2 * INV_ICM42600_GYRO_FS_125DPS] = 0,
> + [2 * INV_ICM42600_GYRO_FS_125DPS + 1] = 66579,
> + /* +/- 62.5dps => 0.000033290 rad/s */
> + [2 * INV_ICM42600_GYRO_FS_62_5DPS] = 0,
> + [2 * INV_ICM42600_GYRO_FS_62_5DPS + 1] = 33290,
> + /* +/- 31.25dps => 0.000016645 rad/s */
> + [2 * INV_ICM42600_GYRO_FS_31_25DPS] = 0,
> + [2 * INV_ICM42600_GYRO_FS_31_25DPS + 1] = 16645,
> + /* +/- 15.625dps => 0.000008322 rad/s */
> + [2 * INV_ICM42600_GYRO_FS_15_625DPS] = 0,
> + [2 * INV_ICM42600_GYRO_FS_15_625DPS + 1] = 8322,
> +};
> +
> +static int inv_icm42600_gyro_read_scale(struct inv_icm42600_state *st,
> + int *val, int *val2)
> +{
> + unsigned int idx;
> +
> + idx = st->conf.gyro.fs;
> +
> + *val = inv_icm42600_gyro_scale[2 * idx];
> + *val2 = inv_icm42600_gyro_scale[2 * idx + 1];
> + return IIO_VAL_INT_PLUS_NANO;
> +}
> +
> +static int inv_icm42600_gyro_write_scale(struct inv_icm42600_state *st,
> + int val, int val2)
> +{
> + struct device *dev = regmap_get_device(st->map);
> + unsigned int idx;
> + struct inv_icm42600_sensor_conf conf = INV_ICM42600_SENSOR_CONF_INIT;
> + int ret;
> +
> + for (idx = 0; idx < ARRAY_SIZE(inv_icm42600_gyro_scale); idx += 2) {
> + if (val == inv_icm42600_gyro_scale[idx] &&
> + val2 == inv_icm42600_gyro_scale[idx + 1])
> + break;
> + }
> + if (idx >= ARRAY_SIZE(inv_icm42600_gyro_scale))
> + return -EINVAL;
> +
> + conf.fs = idx / 2;
> +
> + pm_runtime_get_sync(dev);
> + mutex_lock(&st->lock);
> +
> + ret = inv_icm42600_set_gyro_conf(st, &conf, NULL);
> +
> + mutex_unlock(&st->lock);
> + pm_runtime_mark_last_busy(dev);
> + pm_runtime_put_autosuspend(dev);
> +
> + return ret;
> +}
> +
> +/* IIO format int + micro */
> +static const int inv_icm42600_gyro_odr[] = {
> + /* 12.5Hz */
> + 12, 500000,
> + /* 25Hz */
> + 25, 0,
> + /* 50Hz */
> + 50, 0,
> + /* 100Hz */
> + 100, 0,
> + /* 200Hz */
> + 200, 0,
> + /* 1kHz */
> + 1000, 0,
> + /* 2kHz */
> + 2000, 0,
> + /* 4kHz */
> + 4000, 0,
> +};
> +
> +static const int inv_icm42600_gyro_odr_conv[] = {
> + INV_ICM42600_ODR_12_5HZ,
> + INV_ICM42600_ODR_25HZ,
> + INV_ICM42600_ODR_50HZ,
> + INV_ICM42600_ODR_100HZ,
> + INV_ICM42600_ODR_200HZ,
> + INV_ICM42600_ODR_1KHZ_LN,
> + INV_ICM42600_ODR_2KHZ_LN,
> + INV_ICM42600_ODR_4KHZ_LN,
> +};
> +
> +static int inv_icm42600_gyro_read_odr(struct inv_icm42600_state *st,
> + int *val, int *val2)
> +{
> + unsigned int odr;
> + unsigned int i;
> +
> + odr = st->conf.gyro.odr;
> +
> + for (i = 0; i < ARRAY_SIZE(inv_icm42600_gyro_odr_conv); ++i) {
> + if (inv_icm42600_gyro_odr_conv[i] == odr)
> + break;
> + }
> + if (i >= ARRAY_SIZE(inv_icm42600_gyro_odr_conv))
> + return -EINVAL;
> +
> + *val = inv_icm42600_gyro_odr[2 * i];
> + *val2 = inv_icm42600_gyro_odr[2 * i + 1];
> +
> + return IIO_VAL_INT_PLUS_MICRO;
> +}
> +
> +static int inv_icm42600_gyro_write_odr(struct inv_icm42600_state *st,
> + int val, int val2)
> +{
> + struct device *dev = regmap_get_device(st->map);
> + unsigned int idx;
> + struct inv_icm42600_sensor_conf conf = INV_ICM42600_SENSOR_CONF_INIT;
> + int ret;
> +
> + for (idx = 0; idx < ARRAY_SIZE(inv_icm42600_gyro_odr); idx += 2) {
> + if (val == inv_icm42600_gyro_odr[idx] &&
> + val2 == inv_icm42600_gyro_odr[idx + 1])
> + break;
> + }
> + if (idx >= ARRAY_SIZE(inv_icm42600_gyro_odr))
> + return -EINVAL;
> +
> + conf.odr = inv_icm42600_gyro_odr_conv[idx / 2];
> +
> + pm_runtime_get_sync(dev);
> + mutex_lock(&st->lock);
> +
> + ret = inv_icm42600_set_gyro_conf(st, &conf, NULL);
> +
> + mutex_unlock(&st->lock);
> + pm_runtime_mark_last_busy(dev);
> + pm_runtime_put_autosuspend(dev);
> +
> + return ret;
> +}
> +
> +/*
> + * Calibration bias values, IIO range format int + nano.
> + * Value is limited to +/-64dps coded on 12 bits signed. Step is 1/32 dps.
> + */
> +static int inv_icm42600_gyro_calibbias[] = {
> + -1, 117010721, /* min: -1.117010721 rad/s */
> + 0, 545415, /* step: 0.000545415 rad/s */
> + 1, 116465306, /* max: 1.116465306 rad/s */
> +};
> +
> +static int inv_icm42600_gyro_read_offset(struct inv_icm42600_state *st,
> + struct iio_chan_spec const *chan,
> + int *val, int *val2)
> +{
> + struct device *dev = regmap_get_device(st->map);
> + int64_t val64;
> + int32_t bias;
> + unsigned int reg;
> + int16_t offset;
> + uint8_t data[2];
> + int ret;
> +
> + if (chan->type != IIO_ANGL_VEL)
> + return -EINVAL;
> +
> + switch (chan->channel2) {
> + case IIO_MOD_X:
> + reg = INV_ICM42600_REG_OFFSET_USER0;
> + break;
> + case IIO_MOD_Y:
> + reg = INV_ICM42600_REG_OFFSET_USER1;
> + break;
> + case IIO_MOD_Z:
> + reg = INV_ICM42600_REG_OFFSET_USER3;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + pm_runtime_get_sync(dev);
> + mutex_lock(&st->lock);
> +
> + ret = regmap_bulk_read(st->map, reg, st->buffer, sizeof(data));
> + memcpy(data, st->buffer, sizeof(data));
> +
> + mutex_unlock(&st->lock);
> + pm_runtime_mark_last_busy(dev);
> + pm_runtime_put_autosuspend(dev);
> + if (ret)
> + return ret;
> +
> + /* 12 bits signed value */
> + switch (chan->channel2) {
> + case IIO_MOD_X:
> + offset = sign_extend32(((data[1] & 0x0F) << 8) | data[0], 11);
> + break;
> + case IIO_MOD_Y:
> + offset = sign_extend32(((data[0] & 0xF0) << 4) | data[1], 11);
> + break;
> + case IIO_MOD_Z:
> + offset = sign_extend32(((data[1] & 0x0F) << 8) | data[0], 11);
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + /*
> + * convert raw offset to dps then to rad/s
> + * 12 bits signed raw max 64 to dps: 64 / 2048
> + * dps to rad: Pi / 180
> + * result in nano (1000000000)
> + * (offset * 64 * Pi * 1000000000) / (2048 * 180)
> + */
> + val64 = (int64_t)offset * 64LL * 3141592653LL;
> + /* for rounding, add + or - divisor (2048 * 180) divided by 2 */
> + if (val64 >= 0)
> + val64 += 2048 * 180 / 2;
> + else
> + val64 -= 2048 * 180 / 2;
> + bias = div_s64(val64, 2048 * 180);
> + *val = bias / 1000000000L;
> + *val2 = bias % 1000000000L;
> +
> + return IIO_VAL_INT_PLUS_NANO;
> +}
> +
> +static int inv_icm42600_gyro_write_offset(struct inv_icm42600_state *st,
> + struct iio_chan_spec const *chan,
> + int val, int val2)
> +{
> + struct device *dev = regmap_get_device(st->map);
> + int64_t val64, min, max;
> + unsigned int reg, regval;
> + int16_t offset;
> + int ret;
> +
> + if (chan->type != IIO_ANGL_VEL)
> + return -EINVAL;
> +
> + switch (chan->channel2) {
> + case IIO_MOD_X:
> + reg = INV_ICM42600_REG_OFFSET_USER0;
> + break;
> + case IIO_MOD_Y:
> + reg = INV_ICM42600_REG_OFFSET_USER1;
> + break;
> + case IIO_MOD_Z:
> + reg = INV_ICM42600_REG_OFFSET_USER3;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + /* inv_icm42600_gyro_calibbias: min - step - max in nano */
> + min = (int64_t)inv_icm42600_gyro_calibbias[0] * 1000000000LL +
> + (int64_t)inv_icm42600_gyro_calibbias[1];
> + max = (int64_t)inv_icm42600_gyro_calibbias[4] * 1000000000LL +
> + (int64_t)inv_icm42600_gyro_calibbias[5];
> + val64 = (int64_t)val * 1000000000LL + (int64_t)val2;
> + if (val64 < min || val64 > max)
> + return -EINVAL;
> +
> + /*
> + * convert rad/s to dps then to raw value
> + * rad to dps: 180 / Pi
> + * dps to raw 12 bits signed, max 64: 2048 / 64
> + * val in nano (1000000000)
> + * val * 180 * 2048 / (Pi * 1000000000 * 64)
> + */
> + val64 = val64 * 180LL * 2048LL;
> + /* for rounding, add + or - divisor (3141592653 * 64) divided by 2 */
> + if (val64 >= 0)
> + val64 += 3141592653LL * 64LL / 2LL;
> + else
> + val64 -= 3141592653LL * 64LL / 2LL;
> + offset = div64_s64(val64, 3141592653LL * 64LL);
> +
> + /* clamp value limited to 12 bits signed */
> + if (offset < -2048)
> + offset = -2048;
> + else if (offset > 2047)
> + offset = 2047;
> +
> + pm_runtime_get_sync(dev);
> + mutex_lock(&st->lock);
> +
> + switch (chan->channel2) {
> + case IIO_MOD_X:
> + /* OFFSET_USER1 register is shared */
> + ret = regmap_read(st->map, INV_ICM42600_REG_OFFSET_USER1,
> + ®val);
> + if (ret)
> + goto out_unlock;
> + st->buffer[0] = offset & 0xFF;
> + st->buffer[1] = (regval & 0xF0) | ((offset & 0xF00) >> 8);
> + break;
> + case IIO_MOD_Y:
> + /* OFFSET_USER1 register is shared */
> + ret = regmap_read(st->map, INV_ICM42600_REG_OFFSET_USER1,
> + ®val);
> + if (ret)
> + goto out_unlock;
> + st->buffer[0] = ((offset & 0xF00) >> 4) | (regval & 0x0F);
> + st->buffer[1] = offset & 0xFF;
> + break;
> + case IIO_MOD_Z:
> + /* OFFSET_USER4 register is shared */
> + ret = regmap_read(st->map, INV_ICM42600_REG_OFFSET_USER4,
> + ®val);
> + if (ret)
> + goto out_unlock;
> + st->buffer[0] = offset & 0xFF;
> + st->buffer[1] = (regval & 0xF0) | ((offset & 0xF00) >> 8);
> + break;
> + default:
> + ret = -EINVAL;
> + goto out_unlock;
> + }
> +
> + ret = regmap_bulk_write(st->map, reg, st->buffer, 2);
> +
> +out_unlock:
> + mutex_unlock(&st->lock);
> + pm_runtime_mark_last_busy(dev);
> + pm_runtime_put_autosuspend(dev);
> + return ret;
> +}
> +
> +static int inv_icm42600_gyro_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int *val, int *val2, long mask)
> +{
> + struct inv_icm42600_state *st = iio_device_get_drvdata(indio_dev);
> + int16_t data;
> + int ret;
> +
> + if (chan->type != IIO_ANGL_VEL)
> + return -EINVAL;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + ret = iio_device_claim_direct_mode(indio_dev);
> + if (ret)
> + return ret;
> + ret = inv_icm42600_gyro_read_sensor(st, chan, &data);
> + iio_device_release_direct_mode(indio_dev);
> + if (ret)
> + return ret;
> + *val = data;
> + return IIO_VAL_INT;
> + case IIO_CHAN_INFO_SCALE:
> + return inv_icm42600_gyro_read_scale(st, val, val2);
> + case IIO_CHAN_INFO_SAMP_FREQ:
> + return inv_icm42600_gyro_read_odr(st, val, val2);
> + case IIO_CHAN_INFO_CALIBBIAS:
> + return inv_icm42600_gyro_read_offset(st, chan, val, val2);
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int inv_icm42600_gyro_read_avail(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + const int **vals,
> + int *type, int *length, long mask)
> +{
> + if (chan->type != IIO_ANGL_VEL)
> + return -EINVAL;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_SCALE:
> + *vals = inv_icm42600_gyro_scale;
> + *type = IIO_VAL_INT_PLUS_NANO;
> + *length = ARRAY_SIZE(inv_icm42600_gyro_scale);
> + return IIO_AVAIL_LIST;
> + case IIO_CHAN_INFO_SAMP_FREQ:
> + *vals = inv_icm42600_gyro_odr;
> + *type = IIO_VAL_INT_PLUS_MICRO;
> + *length = ARRAY_SIZE(inv_icm42600_gyro_odr);
> + return IIO_AVAIL_LIST;
> + case IIO_CHAN_INFO_CALIBBIAS:
> + *vals = inv_icm42600_gyro_calibbias;
> + *type = IIO_VAL_INT_PLUS_NANO;
> + return IIO_AVAIL_RANGE;
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int inv_icm42600_gyro_write_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int val, int val2, long mask)
> +{
> + struct inv_icm42600_state *st = iio_device_get_drvdata(indio_dev);
> + int ret;
> +
> + if (chan->type != IIO_ANGL_VEL)
> + return -EINVAL;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_SCALE:
> + ret = iio_device_claim_direct_mode(indio_dev);
> + if (ret)
> + return ret;
> + ret = inv_icm42600_gyro_write_scale(st, val, val2);
> + iio_device_release_direct_mode(indio_dev);
> + return ret;
> + case IIO_CHAN_INFO_SAMP_FREQ:
> + return inv_icm42600_gyro_write_odr(st, val, val2);
> + case IIO_CHAN_INFO_CALIBBIAS:
> + ret = iio_device_claim_direct_mode(indio_dev);
> + if (ret)
> + return ret;
> + ret = inv_icm42600_gyro_write_offset(st, chan, val, val2);
> + iio_device_release_direct_mode(indio_dev);
> + return ret;
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int inv_icm42600_gyro_write_raw_get_fmt(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + long mask)
> +{
> + if (chan->type != IIO_ANGL_VEL)
> + return -EINVAL;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_SCALE:
> + return IIO_VAL_INT_PLUS_NANO;
> + case IIO_CHAN_INFO_SAMP_FREQ:
> + return IIO_VAL_INT_PLUS_MICRO;
> + case IIO_CHAN_INFO_CALIBBIAS:
> + return IIO_VAL_INT_PLUS_NANO;
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static const struct iio_info inv_icm42600_gyro_info = {
> + .read_raw = inv_icm42600_gyro_read_raw,
> + .read_avail = inv_icm42600_gyro_read_avail,
> + .write_raw = inv_icm42600_gyro_write_raw,
> + .write_raw_get_fmt = inv_icm42600_gyro_write_raw_get_fmt,
> + .debugfs_reg_access = inv_icm42600_debugfs_reg,
> +};
> +
> +int inv_icm42600_gyro_init(struct inv_icm42600_state *st)
This feels like the layering would be clearer if this
returned the struct iio_dev * and the assignment happened in the
core driver.
Then state parameter can be const and it'll be obvious it has
no side effects on the state structure.
> +{
> + struct device *dev = regmap_get_device(st->map);
> + const char *name;
> + struct iio_dev *indio_dev;
> +
> + name = devm_kasprintf(dev, GFP_KERNEL, "%s-gyro", st->name);
> + if (!name)
> + return -ENOMEM;
> +
> + indio_dev = devm_iio_device_alloc(dev, 0);
> + if (!indio_dev)
> + return -ENOMEM;
> +
> + iio_device_set_drvdata(indio_dev, st);
> + indio_dev->dev.parent = dev;
> + indio_dev->name = name;
> + indio_dev->info = &inv_icm42600_gyro_info;
> + indio_dev->modes = INDIO_DIRECT_MODE;
> + indio_dev->channels = inv_icm42600_gyro_channels;
> + indio_dev->num_channels = ARRAY_SIZE(inv_icm42600_gyro_channels);
> +
> + st->indio_gyro = indio_dev;
> + return devm_iio_device_register(dev, st->indio_gyro);
> +}
^ permalink raw reply
* Re: [PATCH v2 5/5] PCI: uniphier: Add error message when failed to get phy
From: Kunihiko Hayashi @ 2020-06-02 9:07 UTC (permalink / raw)
To: Rob Herring
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Masahiro Yamada, linux-pci, devicetree, linux-arm-kernel,
linux-kernel, Masami Hiramatsu, Jassi Brar
In-Reply-To: <20200601214302.GA1538223@bogus>
Hi Rob,
On 2020/06/02 6:43, Rob Herring wrote:
> On Fri, May 15, 2020 at 06:59:03PM +0900, Kunihiko Hayashi wrote:
>> Even if phy driver doesn't probe, the error message can't be distinguished
>> from other errors. This displays error message caused by the phy driver
>> explicitly.
>>
>> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
>> ---
>> drivers/pci/controller/dwc/pcie-uniphier.c | 7 +++++--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
>> index 493f105..7ae9688 100644
>> --- a/drivers/pci/controller/dwc/pcie-uniphier.c
>> +++ b/drivers/pci/controller/dwc/pcie-uniphier.c
>> @@ -468,8 +468,11 @@ static int uniphier_pcie_probe(struct platform_device *pdev)
>> return PTR_ERR(priv->rst);
>>
>> priv->phy = devm_phy_optional_get(dev, "pcie-phy");
>> - if (IS_ERR(priv->phy))
>> - return PTR_ERR(priv->phy);
>> + if (IS_ERR(priv->phy)) {
>> + ret = PTR_ERR(priv->phy);
>> + dev_err(dev, "Failed to get phy (%d)\n", ret);
>
> This will print an error on EPROBE_DEFERRED which isn't an error.
Thanks for pointing out.
Surely this message should be suppressed when returning EPROBE_DEFERRED.
Thank you,
---
Best Regards
Kunihiko Hayashi
^ 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