* Re: [PATCH 11/13] arm64: dts: qcom: qcs404: Add CPR and populate OPP table
From: Niklas Cassel @ 2019-07-25 10:40 UTC (permalink / raw)
To: Viresh Kumar
Cc: Andy Gross, linux-arm-msm, jorge.ramirez-ortiz, sboyd, vireshk,
bjorn.andersson, ulf.hansson, Rob Herring, Mark Rutland,
devicetree, linux-kernel
In-Reply-To: <20190723015635.rl5a2isjnjn23fzh@vireshk-i7>
On Tue, Jul 23, 2019 at 07:26:35AM +0530, Viresh Kumar wrote:
> On 19-07-19, 17:45, Niklas Cassel wrote:
> > Hello Viresh,
> >
> > Could you please have a look at the last two patches here:
> > https://git.linaro.org/people/niklas.cassel/kernel.git/log/?h=cpr-opp-hz
>
> There is no sane way of providing review comments with a link to the
> git tree :)
>
> I still had a look and I see that you don't search for max frequency
> but just any OPP that has required-opps set to the level u want. Also,
> can't there be multiple phandles in required-opps in your case ?
For each OPP in the CPR OPP table, we need three things,
opp-level, qcom,fuse-level and opp-hz.
The first two can simply be parsed from the OPP node
itself while iterating the CPR OPP table.
The opp-hz has to be fetched from the CPU OPP table.
Several OPPs might have the same qcom,fuse-level value.
However, they will have unique opp-level values and unique
opp-hz values. Each opp-level has a matching opp-hz.
required-opps is basically a connection between a opp-hz
(CPU OPP table) and and a opp-level (CPR OPP table).
So there will be only one match. No need to search for
max frequency.
I think you are confusing this with something else.
The CPR hardware has to be programmed with the highest
frequency for each qcom,fuse-corner.
This is done here:
https://git.linaro.org/people/niklas.cassel/kernel.git/tree/drivers/power/avs/qcom-cpr.c?h=cpr-full#n1219
by saving the highest frequency for each fuse level
while iterating the OPP table.
There can be only one phandle in the required-opps in my case,
this is one of the reasons why I prefer implementing it in the
CPR driver. If it were to be implemented in OPP core, it probably
has to handle multiple phandles.
>
> > If you like my proposal then I could send out the first patch (the one to
> > OPP core) as a real patch (with an improved commit message), and
> > incorporate the second patch into my CPR patch series when I send out a V2.
>
> Send them both in your series only, otherwise the first one is useless
> anyway.
Ok, will do.
Kind regards,
Niklas
^ permalink raw reply
* [PATCH v2 00/14] Add support for QCOM Core Power Reduction
From: Niklas Cassel @ 2019-07-25 10:41 UTC (permalink / raw)
To: linux-pm, linux-arm-msm
Cc: devicetree, ulf.hansson, sboyd, vireshk, linux-kernel,
bjorn.andersson, Niklas Cassel, jorge.ramirez-ortiz,
linux-arm-kernel
This series adds support for Core Power Reduction (CPR), a form of
Adaptive Voltage Scaling (AVS), found on certain Qualcomm SoCs.
This series is based on top of the qcs404 cpufreq patch series that
hasn't landed yet:
https://patchwork.kernel.org/project/linux-arm-msm/list/?series=137809
CPR is a technology that reduces core power on a CPU or on other device.
It reads voltage settings from efuses (that have been written in
production), it uses these voltage settings as initial values, for each
OPP.
After moving to a certain OPP, CPR monitors dynamic factors such as
temperature, etc. and adjusts the voltage for that frequency accordingly
to save power and meet silicon characteristic requirements.
This driver has been developed together with Jorge Ramirez-Ortiz, and
is based on an RFC by Stephen Boyd[1], which in turn is based on work
by others on codeaurora.org[2].
[1] https://lkml.org/lkml/2015/9/18/833
[2] https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.10/tree/drivers/regulator/cpr-regulator.c?h=msm-3.10
Changes since V1:
Added a new patch implementing dev_pm_opp_find_level_exact() in order to
make the CPR OPP table in device tree cleaner.
For more detailed changes, check the "Changes since V1" as comments in
the individual patches, where applicable.
Jorge Ramirez-Ortiz (1):
cpufreq: Add qcs404 to cpufreq-dt-platdev blacklist
Niklas Cassel (11):
opp: Add dev_pm_opp_find_level_exact()
dt-bindings: cpufreq: qcom-nvmem: Make speedbin related properties
optional
cpufreq: qcom: Refactor the driver to make it easier to extend
dt-bindings: cpufreq: qcom-nvmem: Support pstates provided by a power
domain
cpufreq: qcom: Add support for qcs404 on nvmem driver
dt-bindings: opp: Add qcom-opp bindings with properties needed for CPR
dt-bindings: power: avs: Add support for CPR (Core Power Reduction)
power: avs: Add support for CPR (Core Power Reduction)
arm64: dts: qcom: qcs404: Add CPR and populate OPP table
arm64: defconfig: enable CONFIG_QCOM_CPR
arm64: defconfig: enable CONFIG_ARM_QCOM_CPUFREQ_NVMEM
Sricharan R (2):
dt-bindings: cpufreq: Re-organise kryo cpufreq to use it for other
nvmem based qcom socs
cpufreq: qcom: Re-organise kryo cpufreq to use it for other nvmem
based qcom socs
...ryo-cpufreq.txt => qcom-nvmem-cpufreq.txt} | 125 +-
.../devicetree/bindings/opp/qcom-opp.txt | 19 +
.../bindings/power/avs/qcom,cpr.txt | 193 ++
MAINTAINERS | 13 +-
arch/arm64/boot/dts/qcom/qcs404.dtsi | 142 +-
arch/arm64/configs/defconfig | 2 +
drivers/cpufreq/Kconfig.arm | 4 +-
drivers/cpufreq/Makefile | 2 +-
drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
drivers/cpufreq/qcom-cpufreq-kryo.c | 249 ---
drivers/cpufreq/qcom-cpufreq-nvmem.c | 352 +++
drivers/opp/core.c | 48 +
drivers/power/avs/Kconfig | 15 +
drivers/power/avs/Makefile | 1 +
drivers/power/avs/qcom-cpr.c | 1885 +++++++++++++++++
include/linux/pm_opp.h | 8 +
16 files changed, 2792 insertions(+), 267 deletions(-)
rename Documentation/devicetree/bindings/opp/{kryo-cpufreq.txt => qcom-nvmem-cpufreq.txt} (87%)
create mode 100644 Documentation/devicetree/bindings/opp/qcom-opp.txt
create mode 100644 Documentation/devicetree/bindings/power/avs/qcom,cpr.txt
delete mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c
create mode 100644 drivers/cpufreq/qcom-cpufreq-nvmem.c
create mode 100644 drivers/power/avs/qcom-cpr.c
--
2.21.0
^ permalink raw reply
* [PATCH v2 02/14] dt-bindings: cpufreq: Re-organise kryo cpufreq to use it for other nvmem based qcom socs
From: Niklas Cassel @ 2019-07-25 10:41 UTC (permalink / raw)
To: Viresh Kumar, Nishanth Menon, Stephen Boyd, Andy Gross, Ilia Lin
Cc: linux-arm-msm, jorge.ramirez-ortiz, bjorn.andersson, ulf.hansson,
Sricharan R, Niklas Cassel, Rob Herring, Rob Herring,
Mark Rutland, linux-pm, devicetree, linux-kernel
In-Reply-To: <20190725104144.22924-1-niklas.cassel@linaro.org>
From: Sricharan R <sricharan@codeaurora.org>
The kryo cpufreq driver reads the nvmem cell and uses that data to
populate the opps. There are other qcom cpufreq socs like krait which
does similar thing. Except for the interpretation of the read data,
rest of the driver is same for both the cases. So pull the common things
out for reuse.
Signed-off-by: Sricharan R <sricharan@codeaurora.org>
[niklas.cassel@linaro.org: split dt-binding into a separate patch and
do not rename the compatible string.]
Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org>
Reviewed-by: Ilia Lin <ilia.lin@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changes since V1:
-Picked up tags.
.../opp/{kryo-cpufreq.txt => qcom-nvmem-cpufreq.txt} | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
rename Documentation/devicetree/bindings/opp/{kryo-cpufreq.txt => qcom-nvmem-cpufreq.txt} (98%)
diff --git a/Documentation/devicetree/bindings/opp/kryo-cpufreq.txt b/Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt
similarity index 98%
rename from Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
rename to Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt
index c2127b96805a..198441e80ba8 100644
--- a/Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
+++ b/Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt
@@ -1,13 +1,13 @@
-Qualcomm Technologies, Inc. KRYO CPUFreq and OPP bindings
+Qualcomm Technologies, Inc. NVMEM CPUFreq and OPP bindings
===================================
-In Certain Qualcomm Technologies, Inc. SoCs like apq8096 and msm8996
-that have KRYO processors, the CPU ferequencies subset and voltage value
-of each OPP varies based on the silicon variant in use.
+In Certain Qualcomm Technologies, Inc. SoCs like apq8096 and msm8996,
+the CPU frequencies subset and voltage value of each OPP varies based on
+the silicon variant in use.
Qualcomm Technologies, Inc. Process Voltage Scaling Tables
defines the voltage and frequency value based on the msm-id in SMEM
and speedbin blown in the efuse combination.
-The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
+The qcom-cpufreq-nvmem driver reads the msm-id and efuse value from the SoC
to provide the OPP framework with required information (existing HW bitmap).
This is used to determine the voltage and frequency value for each OPP of
operating-points-v2 table when it is parsed by the OPP framework.
--
2.21.0
^ permalink raw reply related
* [PATCH v2 04/14] dt-bindings: cpufreq: qcom-nvmem: Make speedbin related properties optional
From: Niklas Cassel @ 2019-07-25 10:41 UTC (permalink / raw)
To: Andy Gross, Ilia Lin, Viresh Kumar, Nishanth Menon, Stephen Boyd
Cc: linux-arm-msm, jorge.ramirez-ortiz, bjorn.andersson, ulf.hansson,
Niklas Cassel, Rob Herring, Rob Herring, Mark Rutland, linux-pm,
devicetree, linux-kernel
In-Reply-To: <20190725104144.22924-1-niklas.cassel@linaro.org>
Not all Qualcomm platforms need to care about the speedbin efuse,
nor the value blown into the speedbin efuse.
Therefore, make the nvmem-cells and opp-supported-hw properties
optional.
Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org>
Reviewed-by: Ilia Lin <ilia.lin@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changes since V1:
-Picked up tags.
Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt b/Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt
index 198441e80ba8..c5ea8b90e35d 100644
--- a/Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt
+++ b/Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt
@@ -20,6 +20,10 @@ In 'cpus' nodes:
In 'operating-points-v2' table:
- compatible: Should be
- 'operating-points-v2-kryo-cpu' for apq8096 and msm8996.
+
+Optional properties:
+--------------------
+In 'operating-points-v2' table:
- nvmem-cells: A phandle pointing to a nvmem-cells node representing the
efuse registers that has information about the
speedbin that is used to select the right frequency/voltage
--
2.21.0
^ permalink raw reply related
* [PATCH v2 06/14] dt-bindings: cpufreq: qcom-nvmem: Support pstates provided by a power domain
From: Niklas Cassel @ 2019-07-25 10:41 UTC (permalink / raw)
To: Andy Gross, Ilia Lin, Viresh Kumar, Nishanth Menon, Stephen Boyd
Cc: linux-arm-msm, jorge.ramirez-ortiz, bjorn.andersson, ulf.hansson,
Niklas Cassel, Rob Herring, Mark Rutland, linux-pm, devicetree,
linux-kernel
In-Reply-To: <20190725104144.22924-1-niklas.cassel@linaro.org>
Some Qualcomm SoCs have support for Core Power Reduction (CPR).
On these platforms, we need to attach to the power domain provider
providing the performance states, so that the leaky device (the CPU)
can configure the performance states (which represent different
CPU clock frequencies).
Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org>
---
.../bindings/opp/qcom-nvmem-cpufreq.txt | 111 ++++++++++++++++++
1 file changed, 111 insertions(+)
diff --git a/Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt b/Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt
index c5ea8b90e35d..e19a95318e98 100644
--- a/Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt
+++ b/Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt
@@ -23,6 +23,15 @@ In 'operating-points-v2' table:
Optional properties:
--------------------
+In 'cpus' nodes:
+- power-domains: A phandle pointing to the PM domain specifier which provides
+ the performance states available for active state management.
+ Please refer to the power-domains bindings
+ Documentation/devicetree/bindings/power/power_domain.txt
+ and also examples below.
+- power-domain-names: Should be
+ - 'cpr' for qcs404.
+
In 'operating-points-v2' table:
- nvmem-cells: A phandle pointing to a nvmem-cells node representing the
efuse registers that has information about the
@@ -682,3 +691,105 @@ soc {
};
};
};
+
+Example 2:
+---------
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ CPU0: cpu@100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x100>;
+ ....
+ clocks = <&apcs_glb>;
+ operating-points-v2 = <&cpu_opp_table>;
+ power-domains = <&cprpd>;
+ power-domain-names = "cpr";
+ };
+
+ CPU1: cpu@101 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x101>;
+ ....
+ clocks = <&apcs_glb>;
+ operating-points-v2 = <&cpu_opp_table>;
+ power-domains = <&cprpd>;
+ power-domain-names = "cpr";
+ };
+
+ CPU2: cpu@102 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x102>;
+ ....
+ clocks = <&apcs_glb>;
+ operating-points-v2 = <&cpu_opp_table>;
+ power-domains = <&cprpd>;
+ power-domain-names = "cpr";
+ };
+
+ CPU3: cpu@103 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x103>;
+ ....
+ clocks = <&apcs_glb>;
+ operating-points-v2 = <&cpu_opp_table>;
+ power-domains = <&cprpd>;
+ power-domain-names = "cpr";
+ };
+ };
+
+ cpu_opp_table: cpu-opp-table {
+ compatible = "operating-points-v2-kryo-cpu";
+ opp-shared;
+
+ opp-1094400000 {
+ opp-hz = /bits/ 64 <1094400000>;
+ required-opps = <&cpr_opp1>;
+ };
+ opp-1248000000 {
+ opp-hz = /bits/ 64 <1248000000>;
+ required-opps = <&cpr_opp2>;
+ };
+ opp-1401600000 {
+ opp-hz = /bits/ 64 <1401600000>;
+ required-opps = <&cpr_opp3>;
+ };
+ };
+
+ cpr_opp_table: cpr-opp-table {
+ compatible = "operating-points-v2-qcom-level";
+
+ cpr_opp1: opp1 {
+ opp-level = <1>;
+ ....
+ };
+ cpr_opp2: opp2 {
+ opp-level = <2>;
+ ....
+ };
+ cpr_opp3: opp3 {
+ opp-level = <3>;
+ ....
+ };
+ };
+
+....
+
+soc {
+....
+ cprpd: cpr@b018000 {
+ compatible = "qcom,qcs404-cpr", "qcom,cpr";
+ reg = <0x0b018000 0x1000>;
+ ....
+ vdd-apc-supply = <&pms405_s3>;
+ #power-domain-cells = <0>;
+ operating-points-v2 = <&cpr_opp_table>;
+ ....
+ };
+};
--
2.21.0
^ permalink raw reply related
* [PATCH v2 09/14] dt-bindings: opp: Add qcom-opp bindings with properties needed for CPR
From: Niklas Cassel @ 2019-07-25 10:41 UTC (permalink / raw)
To: Andy Gross, Viresh Kumar, Nishanth Menon, Stephen Boyd
Cc: linux-arm-msm, jorge.ramirez-ortiz, bjorn.andersson, ulf.hansson,
Niklas Cassel, Rob Herring, Mark Rutland, linux-pm, devicetree,
linux-kernel
In-Reply-To: <20190725104144.22924-1-niklas.cassel@linaro.org>
Add qcom-opp bindings with properties needed for Core Power Reduction
(CPR).
CPR is included in a great variety of Qualcomm SoCs, e.g. msm8916 and
msm8996. CPR was first introduced in msm8974.
Co-developed-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org>
---
.../devicetree/bindings/opp/qcom-opp.txt | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
create mode 100644 Documentation/devicetree/bindings/opp/qcom-opp.txt
diff --git a/Documentation/devicetree/bindings/opp/qcom-opp.txt b/Documentation/devicetree/bindings/opp/qcom-opp.txt
new file mode 100644
index 000000000000..f204685d029c
--- /dev/null
+++ b/Documentation/devicetree/bindings/opp/qcom-opp.txt
@@ -0,0 +1,19 @@
+Qualcomm OPP bindings to describe OPP nodes
+
+The bindings are based on top of the operating-points-v2 bindings
+described in Documentation/devicetree/bindings/opp/opp.txt
+Additional properties are described below.
+
+* OPP Table Node
+
+Required properties:
+- compatible: Allow OPPs to express their compatibility. It should be:
+ "operating-points-v2-qcom-level"
+
+* OPP Node
+
+Optional properties:
+- qcom,opp-fuse-level: A positive value representing the fuse corner/level
+ associated with this OPP node. Sometimes several corners/levels shares
+ a certain fuse corner/level. A fuse corner/level contains e.g. ref uV,
+ min uV, and max uV.
--
2.21.0
^ permalink raw reply related
* [PATCH v2 10/14] dt-bindings: power: avs: Add support for CPR (Core Power Reduction)
From: Niklas Cassel @ 2019-07-25 10:41 UTC (permalink / raw)
To: Niklas Cassel, Jorge Ramirez-Ortiz
Cc: linux-arm-msm, sboyd, vireshk, bjorn.andersson, ulf.hansson,
Rob Herring, Rob Herring, Mark Rutland, linux-pm, devicetree,
linux-kernel
In-Reply-To: <20190725104144.22924-1-niklas.cassel@linaro.org>
Add DT bindings to describe the CPR HW found on certain Qualcomm SoCs.
Co-developed-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changes since V1:
-Picked up tags.
.../bindings/power/avs/qcom,cpr.txt | 193 ++++++++++++++++++
1 file changed, 193 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/avs/qcom,cpr.txt
diff --git a/Documentation/devicetree/bindings/power/avs/qcom,cpr.txt b/Documentation/devicetree/bindings/power/avs/qcom,cpr.txt
new file mode 100644
index 000000000000..93be67fa8f38
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/avs/qcom,cpr.txt
@@ -0,0 +1,193 @@
+QCOM CPR (Core Power Reduction)
+
+CPR (Core Power Reduction) is a technology to reduce core power on a CPU
+or other device. Each OPP of a device corresponds to a "corner" that has
+a range of valid voltages for a particular frequency. While the device is
+running at a particular frequency, CPR monitors dynamic factors such as
+temperature, etc. and suggests adjustments to the voltage to save power
+and meet silicon characteristic requirements.
+
+- compatible:
+ Usage: required
+ Value type: <string>
+ Definition: should be "qcom,qcs404-cpr", "qcom,cpr" for qcs404
+
+- reg:
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: base address and size of the rbcpr register region
+
+- interrupts:
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: should specify the CPR interrupt
+
+- clocks:
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: phandle to the reference clock
+
+- clock-names:
+ Usage: required
+ Value type: <stringlist>
+ Definition: must be "ref"
+
+- vdd-apc-supply:
+ Usage: required
+ Value type: <phandle>
+ Definition: phandle to the vdd-apc-supply regulator
+
+- #power-domain-cells:
+ Usage: required
+ Value type: <u32>
+ Definition: should be 0
+
+- operating-points-v2:
+ Usage: required
+ Value type: <phandle>
+ Definition: A phandle to the OPP table containing the
+ performance states supported by the CPR
+ power domain
+
+- acc-syscon:
+ Usage: optional
+ Value type: <phandle>
+ Definition: phandle to syscon for writing ACC settings
+
+- nvmem-cells:
+ Usage: required
+ Value type: <phandle>
+ Definition: phandle to nvmem cells containing the data
+ that makes up a fuse corner, for each fuse corner.
+ As well as the CPR fuse revision.
+
+- nvmem-cell-names:
+ Usage: required
+ Value type: <stringlist>
+ Definition: should be "cpr_quotient_offset1", "cpr_quotient_offset2",
+ "cpr_quotient_offset3", "cpr_init_voltage1",
+ "cpr_init_voltage2", "cpr_init_voltage3", "cpr_quotient1",
+ "cpr_quotient2", "cpr_quotient3", "cpr_ring_osc1",
+ "cpr_ring_osc2", "cpr_ring_osc3", "cpr_fuse_revision"
+ for qcs404.
+
+- qcom,cpr-timer-delay-us:
+ Usage: required
+ Value type: <u32>
+ Definition: delay in uS for the timer interval
+
+- qcom,cpr-timer-cons-up:
+ Usage: required
+ Value type: <u32>
+ Definition: Consecutive number of timer intervals, or units of
+ qcom,cpr-timer-delay-us, that occur before issuing an up
+ interrupt
+
+- qcom,cpr-timer-cons-down:
+ Usage: required
+ Value type: <u32>
+ Definition: Consecutive number of timer intervals, or units of
+ qcom,cpr-timer-delay-us, that occur before issuing a down
+ interrupt
+
+- qcom,cpr-up-threshold:
+ Usage: optional
+ Value type: <u32>
+ Definition: The threshold for CPR to issue interrupt when error_steps
+ is greater than it when stepping up
+
+- qcom,cpr-down-threshold:
+ Usage: optional
+ Value type: <u32>
+ Definition: The threshold for CPR to issue interrupt when error_steps
+ is greater than it when stepping down
+
+- qcom,cpr-idle-clocks:
+ Usage: optional
+ Value type: <u32>
+ Definition: Idle clock cycles ring oscillator can be in
+
+- qcom,cpr-gcnt-us:
+ Usage: required
+ Value type: <u32>
+ Definition: The time for gate count in uS
+
+- qcom,vdd-apc-step-up-limit:
+ Usage: required
+ Value type: <u32>
+ Definition: Limit of number of vdd-apc-supply regulator steps for
+ scaling up
+
+- qcom,vdd-apc-step-down-limit:
+ Usage: required
+ Value type: <u32>
+ Definition: Limit of number of vdd-apc-supply regulator steps for
+ scaling down
+
+Example:
+
+ cpr_opp_table: cpr-opp-table {
+ compatible = "operating-points-v2-qcom-level";
+
+ cpr_opp1: opp1 {
+ opp-level = <1>;
+ ....
+ };
+ cpr_opp2: opp2 {
+ opp-level = <2>;
+ ....
+ };
+ cpr_opp3: opp3 {
+ opp-level = <3>;
+ ....
+ };
+ };
+
+ cpr@b018000 {
+ compatible = "qcom,qcs404-cpr", "qcom,cpr";
+ reg = <0x0b018000 0x1000>;
+ interrupts = <0 15 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&xo_board>;
+ clock-names = "ref";
+ vdd-apc-supply = <&pms405_s3>;
+ #power-domain-cells = <0>;
+ operating-points-v2 = <&cpr_opp_table>;
+ acc-syscon = <&tcsr>;
+
+ nvmem-cells = <&cpr_efuse_quot_offset1>,
+ <&cpr_efuse_quot_offset2>,
+ <&cpr_efuse_quot_offset3>,
+ <&cpr_efuse_init_voltage1>,
+ <&cpr_efuse_init_voltage2>,
+ <&cpr_efuse_init_voltage3>,
+ <&cpr_efuse_quot1>,
+ <&cpr_efuse_quot2>,
+ <&cpr_efuse_quot3>,
+ <&cpr_efuse_ring1>,
+ <&cpr_efuse_ring2>,
+ <&cpr_efuse_ring3>,
+ <&cpr_efuse_revision>;
+ nvmem-cell-names = "cpr_quotient_offset1",
+ "cpr_quotient_offset2",
+ "cpr_quotient_offset3",
+ "cpr_init_voltage1",
+ "cpr_init_voltage2",
+ "cpr_init_voltage3",
+ "cpr_quotient1",
+ "cpr_quotient2",
+ "cpr_quotient3",
+ "cpr_ring_osc1",
+ "cpr_ring_osc2",
+ "cpr_ring_osc3",
+ "cpr_fuse_revision";
+
+ qcom,cpr-timer-delay-us = <5000>;
+ qcom,cpr-timer-cons-up = <0>;
+ qcom,cpr-timer-cons-down = <2>;
+ qcom,cpr-up-threshold = <1>;
+ qcom,cpr-down-threshold = <3>;
+ qcom,cpr-idle-clocks = <15>;
+ qcom,cpr-gcnt-us = <1>;
+ qcom,vdd-apc-step-up-limit = <1>;
+ qcom,vdd-apc-step-down-limit = <1>;
+ };
--
2.21.0
^ permalink raw reply related
* [PATCH v2 12/14] arm64: dts: qcom: qcs404: Add CPR and populate OPP table
From: Niklas Cassel @ 2019-07-25 10:41 UTC (permalink / raw)
To: Andy Gross
Cc: linux-arm-msm, jorge.ramirez-ortiz, sboyd, vireshk,
bjorn.andersson, ulf.hansson, Niklas Cassel, Rob Herring,
Mark Rutland, devicetree, linux-kernel
In-Reply-To: <20190725104144.22924-1-niklas.cassel@linaro.org>
Add CPR and populate OPP table.
Co-developed-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org>
---
Changes since V1:
-Removed opp-hz from CPR OPP table.
arch/arm64/boot/dts/qcom/qcs404.dtsi | 142 +++++++++++++++++++++++++--
1 file changed, 134 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi b/arch/arm64/boot/dts/qcom/qcs404.dtsi
index ff9198740431..5519422b762d 100644
--- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
@@ -38,7 +38,8 @@
#cooling-cells = <2>;
clocks = <&apcs_glb>;
operating-points-v2 = <&cpu_opp_table>;
- cpu-supply = <&pms405_s3>;
+ power-domains = <&cprpd>;
+ power-domain-names = "cpr";
};
CPU1: cpu@101 {
@@ -51,7 +52,8 @@
#cooling-cells = <2>;
clocks = <&apcs_glb>;
operating-points-v2 = <&cpu_opp_table>;
- cpu-supply = <&pms405_s3>;
+ power-domains = <&cprpd>;
+ power-domain-names = "cpr";
};
CPU2: cpu@102 {
@@ -64,7 +66,8 @@
#cooling-cells = <2>;
clocks = <&apcs_glb>;
operating-points-v2 = <&cpu_opp_table>;
- cpu-supply = <&pms405_s3>;
+ power-domains = <&cprpd>;
+ power-domain-names = "cpr";
};
CPU3: cpu@103 {
@@ -77,7 +80,8 @@
#cooling-cells = <2>;
clocks = <&apcs_glb>;
operating-points-v2 = <&cpu_opp_table>;
- cpu-supply = <&pms405_s3>;
+ power-domains = <&cprpd>;
+ power-domain-names = "cpr";
};
L2_0: l2-cache {
@@ -101,20 +105,37 @@
};
cpu_opp_table: cpu-opp-table {
- compatible = "operating-points-v2";
+ compatible = "operating-points-v2-kryo-cpu";
opp-shared;
opp-1094400000 {
opp-hz = /bits/ 64 <1094400000>;
- opp-microvolt = <1224000 1224000 1224000>;
+ required-opps = <&cpr_opp1>;
};
opp-1248000000 {
opp-hz = /bits/ 64 <1248000000>;
- opp-microvolt = <1288000 1288000 1288000>;
+ required-opps = <&cpr_opp2>;
};
opp-1401600000 {
opp-hz = /bits/ 64 <1401600000>;
- opp-microvolt = <1384000 1384000 1384000>;
+ required-opps = <&cpr_opp3>;
+ };
+ };
+
+ cpr_opp_table: cpr-opp-table {
+ compatible = "operating-points-v2-qcom-level";
+
+ cpr_opp1: opp1 {
+ opp-level = <1>;
+ qcom,opp-fuse-level = <1>;
+ };
+ cpr_opp2: opp2 {
+ opp-level = <2>;
+ qcom,opp-fuse-level = <2>;
+ };
+ cpr_opp3: opp3 {
+ opp-level = <3>;
+ qcom,opp-fuse-level = <3>;
};
};
@@ -294,6 +315,62 @@
tsens_caldata: caldata@d0 {
reg = <0x1f8 0x14>;
};
+ cpr_efuse_speedbin: speedbin@13c {
+ reg = <0x13c 0x4>;
+ bits = <2 3>;
+ };
+ cpr_efuse_quot_offset1: qoffset1@231 {
+ reg = <0x231 0x4>;
+ bits = <4 7>;
+ };
+ cpr_efuse_quot_offset2: qoffset2@232 {
+ reg = <0x232 0x4>;
+ bits = <3 7>;
+ };
+ cpr_efuse_quot_offset3: qoffset3@233 {
+ reg = <0x233 0x4>;
+ bits = <2 7>;
+ };
+ cpr_efuse_init_voltage1: ivoltage1@229 {
+ reg = <0x229 0x4>;
+ bits = <4 6>;
+ };
+ cpr_efuse_init_voltage2: ivoltage2@22a {
+ reg = <0x22a 0x4>;
+ bits = <2 6>;
+ };
+ cpr_efuse_init_voltage3: ivoltage3@22b {
+ reg = <0x22b 0x4>;
+ bits = <0 6>;
+ };
+ cpr_efuse_quot1: quot1@22b {
+ reg = <0x22b 0x4>;
+ bits = <6 12>;
+ };
+ cpr_efuse_quot2: quot2@22d {
+ reg = <0x22d 0x4>;
+ bits = <2 12>;
+ };
+ cpr_efuse_quot3: quot3@230 {
+ reg = <0x230 0x4>;
+ bits = <0 12>;
+ };
+ cpr_efuse_ring1: ring1@228 {
+ reg = <0x228 0x4>;
+ bits = <0 3>;
+ };
+ cpr_efuse_ring2: ring2@228 {
+ reg = <0x228 0x4>;
+ bits = <4 3>;
+ };
+ cpr_efuse_ring3: ring3@229 {
+ reg = <0x229 0x4>;
+ bits = <0 3>;
+ };
+ cpr_efuse_revision: revision@218 {
+ reg = <0x218 0x4>;
+ bits = <3 3>;
+ };
};
rng: rng@e3000 {
@@ -901,6 +978,55 @@
clock-names = "xo";
};
+ cprpd: cpr@b018000 {
+ compatible = "qcom,qcs404-cpr", "qcom,cpr";
+ reg = <0x0b018000 0x1000>;
+ interrupts = <0 15 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&xo_board>;
+ clock-names = "ref";
+ vdd-apc-supply = <&pms405_s3>;
+ #power-domain-cells = <0>;
+ operating-points-v2 = <&cpr_opp_table>;
+ acc-syscon = <&tcsr>;
+
+ nvmem-cells = <&cpr_efuse_quot_offset1>,
+ <&cpr_efuse_quot_offset2>,
+ <&cpr_efuse_quot_offset3>,
+ <&cpr_efuse_init_voltage1>,
+ <&cpr_efuse_init_voltage2>,
+ <&cpr_efuse_init_voltage3>,
+ <&cpr_efuse_quot1>,
+ <&cpr_efuse_quot2>,
+ <&cpr_efuse_quot3>,
+ <&cpr_efuse_ring1>,
+ <&cpr_efuse_ring2>,
+ <&cpr_efuse_ring3>,
+ <&cpr_efuse_revision>;
+ nvmem-cell-names = "cpr_quotient_offset1",
+ "cpr_quotient_offset2",
+ "cpr_quotient_offset3",
+ "cpr_init_voltage1",
+ "cpr_init_voltage2",
+ "cpr_init_voltage3",
+ "cpr_quotient1",
+ "cpr_quotient2",
+ "cpr_quotient3",
+ "cpr_ring_osc1",
+ "cpr_ring_osc2",
+ "cpr_ring_osc3",
+ "cpr_fuse_revision";
+
+ qcom,cpr-timer-delay-us = <5000>;
+ qcom,cpr-timer-cons-up = <0>;
+ qcom,cpr-timer-cons-down = <2>;
+ qcom,cpr-up-threshold = <1>;
+ qcom,cpr-down-threshold = <3>;
+ qcom,cpr-idle-clocks = <15>;
+ qcom,cpr-gcnt-us = <1>;
+ qcom,vdd-apc-step-up-limit = <1>;
+ qcom,vdd-apc-step-down-limit = <1>;
+ };
+
timer@b120000 {
#address-cells = <1>;
#size-cells = <1>;
--
2.21.0
^ permalink raw reply related
* Re: [RFC, v3 8/9] media: platform: Add Mediatek ISP P1 SCP communication
From: Tomasz Figa @ 2019-07-25 10:56 UTC (permalink / raw)
To: Jungo Lin
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
Sean Cheng (鄭昇弘),
Frederic Chen (陳俊元),
Rynn Wu (吳育恩), srv_heupstream, Rob Herring,
Ryan Yu (余孟修),
Frankie Chiu (邱文凱), Hans Verkuil,
ddavenport-F7+t8E8rja9g9hUCZPvPmw, Sj Huang,
moderated list:ARM/Mediatek SoC support, Laurent Pinchart,
Matthias Brugger, Mauro Carvalho Chehab
In-Reply-To: <1563675513.1212.444.camel@mtksdccf07>
Hi Jungo,
On Sun, Jul 21, 2019 at 11:18 AM Jungo Lin <jungo.lin-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
[snip]
> > > + wake_up_interruptible(&isp_ctx->composer_tx_thread.wq);
> > > + isp_ctx->composer_tx_thread.thread = NULL;
> > > + }
> > > +
> > > + if (isp_ctx->composer_deinit_thread.thread) {
> > > + wake_up(&isp_ctx->composer_deinit_thread.wq);
> > > + isp_ctx->composer_deinit_thread.thread = NULL;
> > > + }
> > > + mutex_unlock(&isp_ctx->lock);
> > > +
> > > + pm_runtime_put_sync(&p1_dev->pdev->dev);
> >
> > No need to use the sync variant.
> >
>
> We don't get this point. If we will call pm_runtime_get_sync in
> mtk_isp_hw_init function, will we need to call
> pm_runtime_put_sync_autosuspend in mtk_isp_hw_release in next patch?
> As we know, we should call runtime pm functions in pair.
>
My point is that pm_runtime_put_sync() is only needed if one wants the
runtime count to be decremented after the function returns. Normally
there is no need to do so and one would call pm_runtime_put(), or if
autosuspend is used, pm_runtime_put_autosuspend() (note there is no
"sync" in the name).
[snip]
> > +static void isp_composer_handler(void *data, unsigned int len, void *priv)
> > > +{
> > > + struct mtk_isp_p1_ctx *isp_ctx = (struct mtk_isp_p1_ctx *)priv;
> > > + struct isp_p1_device *p1_dev = p1_ctx_to_dev(isp_ctx);
> > > + struct device *dev = &p1_dev->pdev->dev;
> > > + struct mtk_isp_scp_p1_cmd *ipi_msg;
> > > +
> > > + ipi_msg = (struct mtk_isp_scp_p1_cmd *)data;
> >
> > Should we check that len == sizeof(*ipi_msg)? (Or at least >=, if data could
> > contain some extra bytes at the end.)
> >
>
> The len parameter is the actual sending bytes from SCP to kernel.
> In the runtime, it is only 6 bytes for isp_ack_info command
> However, sizeof(*ipi_msg) is large due to struct mtk_isp_scp_p1_cmd is
> union structure.
>
That said we still should check if len is enough to cover the data
we're accessing below.
> > > +
> > > + if (ipi_msg->cmd_id != ISP_CMD_ACK)
> > > + return;
> > > +
> > > + if (ipi_msg->ack_info.cmd_id == ISP_CMD_FRAME_ACK) {
> > > + dev_dbg(dev, "ack frame_num:%d",
> > > + ipi_msg->ack_info.frame_seq_no);
> > > + atomic_set(&isp_ctx->composed_frame_id,
> > > + ipi_msg->ack_info.frame_seq_no);
> >
> > I suppose we are expecting here that ipi_msg->ack_info.frame_seq_no would be
> > just isp_ctx->composed_frame_id + 1, right? If not, we probably dropped some
> > frames and we should handle that somehow.
> >
>
> No, we use isp_ctx->composed_frame_id to save which frame sequence
> number are composed done in SCP. In new design, we will move this from
> isp_ctx to p1_dev.
But we compose the frames in order, don't we? Wouldn't every composed
frame would be just previous frame ID + 1?
[snip]
> > > +void isp_composer_hw_init(struct device *dev)
> > > +{
> > > + struct mtk_isp_scp_p1_cmd composer_tx_cmd;
> > > + struct isp_p1_device *p1_dev = get_p1_device(dev);
> > > + struct mtk_isp_p1_ctx *isp_ctx = &p1_dev->isp_ctx;
> > > +
> > > + memset(&composer_tx_cmd, 0, sizeof(composer_tx_cmd));
> > > + composer_tx_cmd.cmd_id = ISP_CMD_INIT;
> > > + composer_tx_cmd.frameparam.hw_module = isp_ctx->isp_hw_module;
> > > + composer_tx_cmd.frameparam.cq_addr.iova = isp_ctx->scp_mem_iova;
> > > + composer_tx_cmd.frameparam.cq_addr.scp_addr = isp_ctx->scp_mem_pa;
> >
> > Should we also specify the size of the buffer? Otherwise we could end up
> > with some undetectable overruns.
> >
>
> The size of SCP composer's memory is fixed to 0x200000.
> Is it necessary to specify the size of this buffer?
>
> #define MTK_ISP_COMPOSER_MEM_SIZE 0x200000
>
> ptr = dma_alloc_coherent(p1_dev->cam_dev.smem_dev,
> MTK_ISP_COMPOSER_MEM_SIZE, &addr, GFP_KERNEL);
>
Okay, but please add a comment saying that this is an implicit
requirement of the firmware.
Best regards,
Tomasz
^ permalink raw reply
* Re: [PATCH V6 01/21] irqchip: tegra: Do not disable COP IRQ during suspend
From: Dmitry Osipenko @ 2019-07-25 10:59 UTC (permalink / raw)
To: Peter De Schrijver
Cc: Sowjanya Komatineni, thierry.reding, jonathanh, tglx, jason,
marc.zyngier, linus.walleij, stefan, mark.rutland, pgaikwad,
sboyd, linux-clk, linux-gpio, jckuo, josephl, talho, linux-tegra,
linux-kernel, mperttunen, spatra, robh+dt, devicetree
In-Reply-To: <20190725103813.GO12715@pdeschrijver-desktop.Nvidia.com>
25.07.2019 13:38, Peter De Schrijver пишет:
> On Thu, Jul 25, 2019 at 01:33:48PM +0300, Peter De Schrijver wrote:
>> On Thu, Jul 25, 2019 at 01:05:13PM +0300, Dmitry Osipenko wrote:
>>> 25.07.2019 12:55, Peter De Schrijver пишет:
>>>> On Mon, Jul 22, 2019 at 12:54:51PM +0300, Dmitry Osipenko wrote:
>>>>>
>>>>> All Tegra SoCs support SC7, hence the 'supports_sc7' and the comment
>>>>> doesn't sound correct to me. Something like 'firmware_sc7' should suit
>>>>> better here.
>>>>>
>>>>>> + writel_relaxed(~0ul, ictlr + ICTLR_COP_IER_CLR);
>>>>>
>>>>> Secondly, I'm also not sure why COP interrupts need to be disabled for
>>>>> pre-T210 at all, since COP is unused. This looks to me like it was
>>>>> cut-n-pasted from downstream kernel without a good reason and could be
>>>>> simply removed.
>>>>
>>>> I don't think we can rely on the fact that COP is unused. People can
>>>> write their own code to run on COP.
>>>
>>> 1. Not upstream - doesn't matter.
>>>
>>
>> The code is not part of the kernel, so obviously it's not upstream?
>>
>>> 2. That's not very good if something unknown is running on COP and then
>>> kernel suddenly intervenes, don't you think so?
>>
>> Unless the code was written with this in mind.
>>
In that case, please see 1. ;)
>
> Looking at this again, I don't think we need to enable the IRQ at all.
Could you please clarify? The code only saves/restores COP's interrupts
context across suspend-resume.
Again, that's absolutely useless code for the upstream kernel which
could be removed safely to avoid the confusion, IMHO. I can type a patch
if you're agreeing.
^ permalink raw reply
* [PATCH RESEND 0/5] ARM: dts: mmp2: devicetree updates
From: Lubomir Rintel @ 2019-07-25 11:07 UTC (permalink / raw)
To: Olof Johansson
Cc: Rob Herring, Mark Rutland, linux-arm-kernel, devicetree,
linux-kernel
Hi,
Here's a couple of updates for the MMP2 SoC devicetree files.
They're pretty much independent of each other, can be applied in any
order.
Hopefully I'm sending them the right way.
Lubo
^ permalink raw reply
* [PATCH 1/5] ARM: dts: mmp2: trivial whitespace fix
From: Lubomir Rintel @ 2019-07-25 11:07 UTC (permalink / raw)
To: Olof Johansson
Cc: Rob Herring, Mark Rutland, linux-arm-kernel, devicetree,
linux-kernel, Lubomir Rintel
In-Reply-To: <20190725110731.3294411-1-lkundrak@v3.sk>
A missing space before a curly brace.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
---
arch/arm/boot/dts/mmp2.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
index b6f40743e07b0..50b6c38b39cc3 100644
--- a/arch/arm/boot/dts/mmp2.dtsi
+++ b/arch/arm/boot/dts/mmp2.dtsi
@@ -379,7 +379,7 @@
};
};
- soc_clocks: clocks{
+ soc_clocks: clocks {
compatible = "marvell,mmp2-clock";
reg = <0xd4050000 0x1000>,
<0xd4282800 0x400>,
--
2.21.0
^ permalink raw reply related
* [PATCH 2/5] ARM: dts: mmp2: fix the SPI nodes
From: Lubomir Rintel @ 2019-07-25 11:07 UTC (permalink / raw)
To: Olof Johansson
Cc: Mark Rutland, devicetree, linux-kernel, Lubomir Rintel,
Rob Herring, linux-arm-kernel
In-Reply-To: <20190725110731.3294411-1-lkundrak@v3.sk>
The SPI bus has a single address cell and not size cells.
Also, dtc thinks the SPI nodes are preferrably called "spi" and it is
right to think so.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
---
arch/arm/boot/dts/mmp2.dtsi | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
index 50b6c38b39cc3..e64639ce57a91 100644
--- a/arch/arm/boot/dts/mmp2.dtsi
+++ b/arch/arm/boot/dts/mmp2.dtsi
@@ -346,35 +346,43 @@
status = "disabled";
};
- ssp1: ssp@d4035000 {
+ ssp1: spi@d4035000 {
compatible = "marvell,mmp2-ssp";
reg = <0xd4035000 0x1000>;
clocks = <&soc_clocks MMP2_CLK_SSP0>;
interrupts = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "disabled";
};
- ssp2: ssp@d4036000 {
+ ssp2: spi@d4036000 {
compatible = "marvell,mmp2-ssp";
reg = <0xd4036000 0x1000>;
clocks = <&soc_clocks MMP2_CLK_SSP1>;
interrupts = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "disabled";
};
- ssp3: ssp@d4037000 {
+ ssp3: spi@d4037000 {
compatible = "marvell,mmp2-ssp";
reg = <0xd4037000 0x1000>;
clocks = <&soc_clocks MMP2_CLK_SSP2>;
interrupts = <20>;
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "disabled";
};
- ssp4: ssp@d4039000 {
+ ssp4: spi@d4039000 {
compatible = "marvell,mmp2-ssp";
reg = <0xd4039000 0x1000>;
clocks = <&soc_clocks MMP2_CLK_SSP3>;
interrupts = <21>;
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "disabled";
};
};
--
2.21.0
^ permalink raw reply related
* [PATCH 3/5] ARM: dts: mmp2: rename the USB PHY node
From: Lubomir Rintel @ 2019-07-25 11:07 UTC (permalink / raw)
To: Olof Johansson
Cc: Mark Rutland, devicetree, linux-kernel, Lubomir Rintel,
Rob Herring, linux-arm-kernel
In-Reply-To: <20190725110731.3294411-1-lkundrak@v3.sk>
This device is not an OTG phy, it's a regular USB HS phy. Follow the
generic node name recommendation, and rename it to "usb-phy".
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
---
arch/arm/boot/dts/mmp2.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
index e64639ce57a91..21432cb9143f7 100644
--- a/arch/arm/boot/dts/mmp2.dtsi
+++ b/arch/arm/boot/dts/mmp2.dtsi
@@ -117,7 +117,7 @@
mrvl,intc-nr-irqs = <2>;
};
- usb_otg_phy0: usb-otg-phy@d4207000 {
+ usb_phy0: usb-phy@d4207000 {
compatible = "marvell,mmp2-usb-phy";
reg = <0xd4207000 0x40>;
#phy-cells = <0>;
@@ -130,7 +130,7 @@
interrupts = <44>;
clocks = <&soc_clocks MMP2_CLK_USB>;
clock-names = "USBCLK";
- phys = <&usb_otg_phy0>;
+ phys = <&usb_phy0>;
phy-names = "usb";
status = "disabled";
};
--
2.21.0
^ permalink raw reply related
* [PATCH 4/5] ARM: dts: mmp2: add camera interfaces
From: Lubomir Rintel @ 2019-07-25 11:07 UTC (permalink / raw)
To: Olof Johansson
Cc: Rob Herring, Mark Rutland, linux-arm-kernel, devicetree,
linux-kernel, Lubomir Rintel
In-Reply-To: <20190725110731.3294411-1-lkundrak@v3.sk>
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
---
arch/arm/boot/dts/mmp2.dtsi | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
index 21432cb9143f7..68b5470773232 100644
--- a/arch/arm/boot/dts/mmp2.dtsi
+++ b/arch/arm/boot/dts/mmp2.dtsi
@@ -170,6 +170,28 @@
interrupts = <54>;
status = "disabled";
};
+
+ camera0: camera@d420a000 {
+ compatible = "marvell,mmp2-ccic";
+ reg = <0xd420a000 0x800>;
+ interrupts = <42>;
+ clocks = <&soc_clocks MMP2_CLK_CCIC0>;
+ clock-names = "axi";
+ #clock-cells = <0>;
+ clock-output-names = "mclk";
+ status = "disabled";
+ };
+
+ camera1: camera@d420a800 {
+ compatible = "marvell,mmp2-ccic";
+ reg = <0xd420a800 0x800>;
+ interrupts = <30>;
+ clocks = <&soc_clocks MMP2_CLK_CCIC1>;
+ clock-names = "axi";
+ #clock-cells = <0>;
+ clock-output-names = "mclk";
+ status = "disabled";
+ };
};
apb@d4000000 { /* APB */
--
2.21.0
^ permalink raw reply related
* [PATCH 5/5] ARM: dts: mmp2: specify reg-shift for the UARTs
From: Lubomir Rintel @ 2019-07-25 11:07 UTC (permalink / raw)
To: Olof Johansson
Cc: Rob Herring, Mark Rutland, linux-arm-kernel, devicetree,
linux-kernel, Lubomir Rintel
In-Reply-To: <20190725110731.3294411-1-lkundrak@v3.sk>
This makes the 8250_of driver happy. There are two more drivers in the
tree that bind to mrvl,mmp-uart compatibles: pxa and 8250_pxa and
neither of them requires the reg-shift property, assuming it's always 2.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
---
Changes since v1:
- Updated the subject to fit the style of the DTS updates
---
arch/arm/boot/dts/mmp2.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
index 68b5470773232..6a2f072c1d0a8 100644
--- a/arch/arm/boot/dts/mmp2.dtsi
+++ b/arch/arm/boot/dts/mmp2.dtsi
@@ -214,6 +214,7 @@
interrupts = <27>;
clocks = <&soc_clocks MMP2_CLK_UART0>;
resets = <&soc_clocks MMP2_CLK_UART0>;
+ reg-shift = <2>;
status = "disabled";
};
@@ -223,6 +224,7 @@
interrupts = <28>;
clocks = <&soc_clocks MMP2_CLK_UART1>;
resets = <&soc_clocks MMP2_CLK_UART1>;
+ reg-shift = <2>;
status = "disabled";
};
@@ -232,6 +234,7 @@
interrupts = <24>;
clocks = <&soc_clocks MMP2_CLK_UART2>;
resets = <&soc_clocks MMP2_CLK_UART2>;
+ reg-shift = <2>;
status = "disabled";
};
@@ -241,6 +244,7 @@
interrupts = <46>;
clocks = <&soc_clocks MMP2_CLK_UART3>;
resets = <&soc_clocks MMP2_CLK_UART3>;
+ reg-shift = <2>;
status = "disabled";
};
--
2.21.0
^ permalink raw reply related
* Re: [PATCH 2/2] dt-bindings: leds: document new "power-supply" property
From: Jean-Jacques Hiblot @ 2019-07-25 11:08 UTC (permalink / raw)
To: Rob Herring
Cc: jacek.anaszewski, pavel, mark.rutland, daniel.thompson, dmurphy,
linux-leds, linux-kernel, devicetree
In-Reply-To: <20190724164757.GA3723@bogus>
Hi Rob,
On 24/07/2019 18:47, Rob Herring wrote:
> On Mon, Jul 08, 2019 at 12:35:47PM +0200, Jean-Jacques Hiblot wrote:
>> Most of the LEDs are powered by a voltage/current regulator. describing in
>> the device-tree makes it possible for the LED core to enable/disable it
>> when needed.
>>
>> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
>> ---
>> Documentation/devicetree/bindings/leds/common.txt | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt
>> index 70876ac11367..e093a2b7eb90 100644
>> --- a/Documentation/devicetree/bindings/leds/common.txt
>> +++ b/Documentation/devicetree/bindings/leds/common.txt
>> @@ -61,6 +61,11 @@ Optional properties for child nodes:
>> - panic-indicator : This property specifies that the LED should be used,
>> if at all possible, as a panic indicator.
>>
>> +- power-supply : A voltage/current regulator used to to power the LED. When a
>> + LED is turned off, the LED core disable its regulator. The
>> + same regulator can power many LED (or other) devices. It is
>> + turned off only when all of its users disabled it.
> Not sure this should be common. It wouldn't apply to cases where we have
> an LED controller parent nor gpio and pwm LEDs and those are most cases.
It does make sense for GPIO and PWM bindings if the anode of LED is tied
to a regulated voltage and the cathod to the control line.
The same is true for a certain class of true LED controller that do not
deliver power but act like current sinks.
JJ
>
> Perhaps what makes sense here is an regulator-led binding.
>
>> +
>> - trigger-sources : List of devices which should be used as a source triggering
>> this LED activity. Some LEDs can be related to a specific
>> device and should somehow indicate its state. E.g. USB 2.0
>> --
>> 2.17.1
>>
^ permalink raw reply
* [PATCH net-next v2 0/4] enetc: Add mdio bus driver for the PCIe MDIO endpoint
From: Claudiu Manoil @ 2019-07-25 11:19 UTC (permalink / raw)
To: David S . Miller
Cc: andrew, Rob Herring, Li Yang, alexandru.marginean, netdev,
devicetree, linux-arm-kernel, linux-kernel
Second patch just registers the PCIe endpoint device containing
the MDIO registers as a standalone MDIO bus driver, to allow
an alternative way to control the MDIO bus. The same code used
by the ENETC ports (eth controllers) to manage MDIO via local
registers applies and is reused.
Bindings are provided for the new MDIO node, similarly to ENETC
port nodes bindings.
Last patch enables the ENETC port 1 and its RGMII PHY on the
LS1028A QDS board, where the MDIO muxing configuration relies
on the MDIO support provided in the first patch.
Claudiu Manoil (4):
enetc: Clean up local mdio bus allocation
enetc: Add mdio bus driver for the PCIe MDIO endpoint
dt-bindings: net: fsl: enetc: Add bindings for the central MDIO PCIe
endpoint
arm64: dts: fsl: ls1028a: Enable eth port1 on the ls1028a QDS board
.../devicetree/bindings/net/fsl-enetc.txt | 42 +++-
.../boot/dts/freescale/fsl-ls1028a-qds.dts | 40 ++++
.../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 6 +
.../net/ethernet/freescale/enetc/enetc_mdio.c | 190 +++++++++++++-----
.../net/ethernet/freescale/enetc/enetc_pf.c | 5 +-
5 files changed, 232 insertions(+), 51 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH net-next v2 1/4] enetc: Clean up local mdio bus allocation
From: Claudiu Manoil @ 2019-07-25 11:19 UTC (permalink / raw)
To: David S . Miller
Cc: andrew, Rob Herring, Li Yang, alexandru.marginean, netdev,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <1564053568-20522-1-git-send-email-claudiu.manoil@nxp.com>
What's needed is basically a pointer to the mdio registers.
This is one way to store it inside bus->priv allocated space,
without upsetting sparse.
Reworked accessor design as requested by Andrew Lunn in the
process.
Used devm_* variant to further clean up the init error /
remove paths.
Fixes following sparse warning:
warning: incorrect type in assignment (different address spaces)
expected void *priv
got struct enetc_mdio_regs [noderef] <asn:2>*[assigned] regs
Fixes: ebfcb23d62ab ("enetc: Add ENETC PF level external MDIO support")
CC: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
v1 - added this patch
v2 - reworked accessors as per Andrew Lunn's request
.../net/ethernet/freescale/enetc/enetc_mdio.c | 94 +++++++++----------
1 file changed, 46 insertions(+), 48 deletions(-)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_mdio.c b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
index 77b9cd10ba2b..05094601ece8 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
@@ -8,16 +8,22 @@
#include "enetc_pf.h"
-struct enetc_mdio_regs {
- u32 mdio_cfg; /* MDIO configuration and status */
- u32 mdio_ctl; /* MDIO control */
- u32 mdio_data; /* MDIO data */
- u32 mdio_addr; /* MDIO address */
+#define ENETC_MDIO_REG_OFFSET 0x1c00
+#define ENETC_MDIO_CFG 0x0 /* MDIO configuration and status */
+#define ENETC_MDIO_CTL 0x4 /* MDIO control */
+#define ENETC_MDIO_DATA 0x8 /* MDIO data */
+#define ENETC_MDIO_ADDR 0xc /* MDIO address */
+
+#define enetc_mdio_rd(hw, off) \
+ enetc_port_rd(hw, ENETC_##off + ENETC_MDIO_REG_OFFSET)
+#define enetc_mdio_wr(hw, off, val) \
+ enetc_port_wr(hw, ENETC_##off + ENETC_MDIO_REG_OFFSET, val)
+#define enetc_mdio_rd_reg(off) enetc_mdio_rd(hw, off)
+
+struct enetc_mdio_priv {
+ struct enetc_hw *hw;
};
-#define bus_to_enetc_regs(bus) (struct enetc_mdio_regs __iomem *)((bus)->priv)
-
-#define ENETC_MDIO_REG_OFFSET 0x1c00
#define ENETC_MDC_DIV 258
#define MDIO_CFG_CLKDIV(x) ((((x) >> 1) & 0xff) << 8)
@@ -33,18 +39,19 @@ struct enetc_mdio_regs {
#define MDIO_DATA(x) ((x) & 0xffff)
#define TIMEOUT 1000
-static int enetc_mdio_wait_complete(struct enetc_mdio_regs __iomem *regs)
+static int enetc_mdio_wait_complete(struct enetc_hw *hw)
{
u32 val;
- return readx_poll_timeout(enetc_rd_reg, ®s->mdio_cfg, val,
+ return readx_poll_timeout(enetc_mdio_rd_reg, MDIO_CFG, val,
!(val & MDIO_CFG_BSY), 10, 10 * TIMEOUT);
}
static int enetc_mdio_write(struct mii_bus *bus, int phy_id, int regnum,
u16 value)
{
- struct enetc_mdio_regs __iomem *regs = bus_to_enetc_regs(bus);
+ struct enetc_mdio_priv *mdio_priv = bus->priv;
+ struct enetc_hw *hw = mdio_priv->hw;
u32 mdio_ctl, mdio_cfg;
u16 dev_addr;
int ret;
@@ -59,29 +66,29 @@ static int enetc_mdio_write(struct mii_bus *bus, int phy_id, int regnum,
mdio_cfg &= ~MDIO_CFG_ENC45;
}
- enetc_wr_reg(®s->mdio_cfg, mdio_cfg);
+ enetc_mdio_wr(hw, MDIO_CFG, mdio_cfg);
- ret = enetc_mdio_wait_complete(regs);
+ ret = enetc_mdio_wait_complete(hw);
if (ret)
return ret;
/* set port and dev addr */
mdio_ctl = MDIO_CTL_PORT_ADDR(phy_id) | MDIO_CTL_DEV_ADDR(dev_addr);
- enetc_wr_reg(®s->mdio_ctl, mdio_ctl);
+ enetc_mdio_wr(hw, MDIO_CTL, mdio_ctl);
/* set the register address */
if (regnum & MII_ADDR_C45) {
- enetc_wr_reg(®s->mdio_addr, regnum & 0xffff);
+ enetc_mdio_wr(hw, MDIO_ADDR, regnum & 0xffff);
- ret = enetc_mdio_wait_complete(regs);
+ ret = enetc_mdio_wait_complete(hw);
if (ret)
return ret;
}
/* write the value */
- enetc_wr_reg(®s->mdio_data, MDIO_DATA(value));
+ enetc_mdio_wr(hw, MDIO_DATA, MDIO_DATA(value));
- ret = enetc_mdio_wait_complete(regs);
+ ret = enetc_mdio_wait_complete(hw);
if (ret)
return ret;
@@ -90,7 +97,8 @@ static int enetc_mdio_write(struct mii_bus *bus, int phy_id, int regnum,
static int enetc_mdio_read(struct mii_bus *bus, int phy_id, int regnum)
{
- struct enetc_mdio_regs __iomem *regs = bus_to_enetc_regs(bus);
+ struct enetc_mdio_priv *mdio_priv = bus->priv;
+ struct enetc_hw *hw = mdio_priv->hw;
u32 mdio_ctl, mdio_cfg;
u16 dev_addr, value;
int ret;
@@ -104,41 +112,41 @@ static int enetc_mdio_read(struct mii_bus *bus, int phy_id, int regnum)
mdio_cfg &= ~MDIO_CFG_ENC45;
}
- enetc_wr_reg(®s->mdio_cfg, mdio_cfg);
+ enetc_mdio_wr(hw, MDIO_CFG, mdio_cfg);
- ret = enetc_mdio_wait_complete(regs);
+ ret = enetc_mdio_wait_complete(hw);
if (ret)
return ret;
/* set port and device addr */
mdio_ctl = MDIO_CTL_PORT_ADDR(phy_id) | MDIO_CTL_DEV_ADDR(dev_addr);
- enetc_wr_reg(®s->mdio_ctl, mdio_ctl);
+ enetc_mdio_wr(hw, MDIO_CTL, mdio_ctl);
/* set the register address */
if (regnum & MII_ADDR_C45) {
- enetc_wr_reg(®s->mdio_addr, regnum & 0xffff);
+ enetc_mdio_wr(hw, MDIO_ADDR, regnum & 0xffff);
- ret = enetc_mdio_wait_complete(regs);
+ ret = enetc_mdio_wait_complete(hw);
if (ret)
return ret;
}
/* initiate the read */
- enetc_wr_reg(®s->mdio_ctl, mdio_ctl | MDIO_CTL_READ);
+ enetc_mdio_wr(hw, MDIO_CTL, mdio_ctl | MDIO_CTL_READ);
- ret = enetc_mdio_wait_complete(regs);
+ ret = enetc_mdio_wait_complete(hw);
if (ret)
return ret;
/* return all Fs if nothing was there */
- if (enetc_rd_reg(®s->mdio_cfg) & MDIO_CFG_RD_ER) {
+ if (enetc_mdio_rd(hw, MDIO_CFG) & MDIO_CFG_RD_ER) {
dev_dbg(&bus->dev,
"Error while reading PHY%d reg at %d.%hhu\n",
phy_id, dev_addr, regnum);
return 0xffff;
}
- value = enetc_rd_reg(®s->mdio_data) & 0xffff;
+ value = enetc_mdio_rd(hw, MDIO_DATA) & 0xffff;
return value;
}
@@ -146,12 +154,12 @@ static int enetc_mdio_read(struct mii_bus *bus, int phy_id, int regnum)
int enetc_mdio_probe(struct enetc_pf *pf)
{
struct device *dev = &pf->si->pdev->dev;
- struct enetc_mdio_regs __iomem *regs;
+ struct enetc_mdio_priv *mdio_priv;
struct device_node *np;
struct mii_bus *bus;
- int ret;
+ int err;
- bus = mdiobus_alloc_size(sizeof(regs));
+ bus = devm_mdiobus_alloc_size(dev, sizeof(*mdio_priv));
if (!bus)
return -ENOMEM;
@@ -159,41 +167,31 @@ int enetc_mdio_probe(struct enetc_pf *pf)
bus->read = enetc_mdio_read;
bus->write = enetc_mdio_write;
bus->parent = dev;
+ mdio_priv = bus->priv;
+ mdio_priv->hw = &pf->si->hw;
snprintf(bus->id, MII_BUS_ID_SIZE, "%s", dev_name(dev));
- /* store the enetc mdio base address for this bus */
- regs = pf->si->hw.port + ENETC_MDIO_REG_OFFSET;
- bus->priv = regs;
-
np = of_get_child_by_name(dev->of_node, "mdio");
if (!np) {
dev_err(dev, "MDIO node missing\n");
- ret = -EINVAL;
- goto err_registration;
+ return -EINVAL;
}
- ret = of_mdiobus_register(bus, np);
- if (ret) {
+ err = of_mdiobus_register(bus, np);
+ if (err) {
of_node_put(np);
dev_err(dev, "cannot register MDIO bus\n");
- goto err_registration;
+ return err;
}
of_node_put(np);
pf->mdio = bus;
return 0;
-
-err_registration:
- mdiobus_free(bus);
-
- return ret;
}
void enetc_mdio_remove(struct enetc_pf *pf)
{
- if (pf->mdio) {
+ if (pf->mdio)
mdiobus_unregister(pf->mdio);
- mdiobus_free(pf->mdio);
- }
}
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v2 2/4] enetc: Add mdio bus driver for the PCIe MDIO endpoint
From: Claudiu Manoil @ 2019-07-25 11:19 UTC (permalink / raw)
To: David S . Miller
Cc: andrew, Rob Herring, Li Yang, alexandru.marginean, netdev,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <1564053568-20522-1-git-send-email-claudiu.manoil@nxp.com>
ENETC ports can manage the MDIO bus via local register
interface. However there's also a centralized way
to manage the MDIO bus, via the MDIO PCIe endpoint
device integrated by the same root complex that also
integrates the ENETC ports (eth controllers).
Depending on board design and use case, centralized
access to MDIO may be better than using local ENETC
port registers. For instance, on the LS1028A QDS board
where MDIO muxing is requiered. Also, the LS1028A on-chip
switch doesn't have a local MDIO register interface.
The current patch registers the above PCIe enpoint as a
separate MDIO bus and provides a driver for it by re-using
the code used for local MDIO access. It also allows the
ENETC port PHYs to be managed by this driver if the local
"mdio" node is missing from the ENETC port node.
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
v1 - fixed mdio bus allocation
- requested only BAR0 region, as it's the only one used by the driver
v2 - reworked accessors as per Andrew Lunn's request
.../net/ethernet/freescale/enetc/enetc_mdio.c | 98 +++++++++++++++++++
.../net/ethernet/freescale/enetc/enetc_pf.c | 5 +-
2 files changed, 102 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_mdio.c b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
index 05094601ece8..56ad94a3504c 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
@@ -195,3 +195,101 @@ void enetc_mdio_remove(struct enetc_pf *pf)
if (pf->mdio)
mdiobus_unregister(pf->mdio);
}
+
+#define ENETC_MDIO_DEV_ID 0xee01
+#define ENETC_MDIO_DEV_NAME "FSL PCIe IE Central MDIO"
+#define ENETC_MDIO_BUS_NAME ENETC_MDIO_DEV_NAME " Bus"
+#define ENETC_MDIO_DRV_NAME ENETC_MDIO_DEV_NAME " driver"
+#define ENETC_MDIO_DRV_ID "fsl_enetc_mdio"
+
+static int enetc_pci_mdio_probe(struct pci_dev *pdev,
+ const struct pci_device_id *ent)
+{
+ struct enetc_mdio_priv *mdio_priv;
+ struct device *dev = &pdev->dev;
+ struct enetc_hw *hw;
+ struct mii_bus *bus;
+ int err;
+
+ hw = devm_kzalloc(dev, sizeof(*hw), GFP_KERNEL);
+ if (!hw)
+ return -ENOMEM;
+
+ bus = devm_mdiobus_alloc_size(dev, sizeof(*mdio_priv));
+ if (!bus)
+ return -ENOMEM;
+
+ bus->name = ENETC_MDIO_BUS_NAME;
+ bus->read = enetc_mdio_read;
+ bus->write = enetc_mdio_write;
+ bus->parent = dev;
+ mdio_priv = bus->priv;
+ mdio_priv->hw = hw;
+ snprintf(bus->id, MII_BUS_ID_SIZE, "%s", dev_name(dev));
+
+ pcie_flr(pdev);
+ err = pci_enable_device_mem(pdev);
+ if (err) {
+ dev_err(dev, "device enable failed\n");
+ return err;
+ }
+
+ err = pci_request_region(pdev, 0, ENETC_MDIO_DRV_ID);
+ if (err) {
+ dev_err(dev, "pci_request_region failed\n");
+ goto err_pci_mem_reg;
+ }
+
+ hw->port = pci_iomap(pdev, 0, 0);
+ if (!bus->priv) {
+ err = -ENXIO;
+ dev_err(dev, "iomap failed\n");
+ goto err_ioremap;
+ }
+
+ err = of_mdiobus_register(bus, dev->of_node);
+ if (err)
+ goto err_mdiobus_reg;
+
+ pci_set_drvdata(pdev, bus);
+
+ return 0;
+
+err_mdiobus_reg:
+ iounmap(mdio_priv->hw->port);
+err_ioremap:
+ pci_release_mem_regions(pdev);
+err_pci_mem_reg:
+ pci_disable_device(pdev);
+
+ return err;
+}
+
+static void enetc_pci_mdio_remove(struct pci_dev *pdev)
+{
+ struct mii_bus *bus = pci_get_drvdata(pdev);
+ struct enetc_mdio_priv *mdio_priv;
+
+ mdiobus_unregister(bus);
+ mdio_priv = bus->priv;
+ iounmap(mdio_priv->hw->port);
+ pci_release_mem_regions(pdev);
+ pci_disable_device(pdev);
+}
+
+static const struct pci_device_id enetc_pci_mdio_id_table[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, ENETC_MDIO_DEV_ID) },
+ { 0, } /* End of table. */
+};
+MODULE_DEVICE_TABLE(pci, enetc_mdio_id_table);
+
+static struct pci_driver enetc_pci_mdio_driver = {
+ .name = ENETC_MDIO_DRV_ID,
+ .id_table = enetc_pci_mdio_id_table,
+ .probe = enetc_pci_mdio_probe,
+ .remove = enetc_pci_mdio_remove,
+};
+module_pci_driver(enetc_pci_mdio_driver);
+
+MODULE_DESCRIPTION(ENETC_MDIO_DRV_NAME);
+MODULE_LICENSE("Dual BSD/GPL");
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.c b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
index 258b3cb38a6f..7d6513ff8507 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
@@ -750,6 +750,7 @@ static int enetc_of_get_phy(struct enetc_ndev_priv *priv)
{
struct enetc_pf *pf = enetc_si_priv(priv->si);
struct device_node *np = priv->dev->of_node;
+ struct device_node *mdio_np;
int err;
if (!np) {
@@ -773,7 +774,9 @@ static int enetc_of_get_phy(struct enetc_ndev_priv *priv)
priv->phy_node = of_node_get(np);
}
- if (!of_phy_is_fixed_link(np)) {
+ mdio_np = of_get_child_by_name(np, "mdio");
+ if (mdio_np) {
+ of_node_put(mdio_np);
err = enetc_mdio_probe(pf);
if (err) {
of_node_put(priv->phy_node);
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v2 3/4] dt-bindings: net: fsl: enetc: Add bindings for the central MDIO PCIe endpoint
From: Claudiu Manoil @ 2019-07-25 11:19 UTC (permalink / raw)
To: David S . Miller
Cc: andrew, Rob Herring, Li Yang, alexandru.marginean, netdev,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <1564053568-20522-1-git-send-email-claudiu.manoil@nxp.com>
The on-chip PCIe root complex that integrates the ENETC ethernet
controllers also integrates a PCIe enpoint for the MDIO controller
provinding for cetralized control of the ENETC mdio bus.
Add bindings for this "central" MDIO Integrated PCIe Endpoit.
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
v1 - none
v2 - none
.../devicetree/bindings/net/fsl-enetc.txt | 42 +++++++++++++++++--
1 file changed, 39 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/fsl-enetc.txt b/Documentation/devicetree/bindings/net/fsl-enetc.txt
index 25fc687419db..c090f6df7a39 100644
--- a/Documentation/devicetree/bindings/net/fsl-enetc.txt
+++ b/Documentation/devicetree/bindings/net/fsl-enetc.txt
@@ -11,7 +11,9 @@ Required properties:
to parent node bindings.
- compatible : Should be "fsl,enetc".
-1) The ENETC external port is connected to a MDIO configurable phy:
+1. The ENETC external port is connected to a MDIO configurable phy
+
+1.1. Using the local ENETC Port MDIO interface
In this case, the ENETC node should include a "mdio" sub-node
that in turn should contain the "ethernet-phy" node describing the
@@ -47,8 +49,42 @@ Example:
};
};
-2) The ENETC port is an internal port or has a fixed-link external
-connection:
+1.2. Using the central MDIO PCIe enpoint device
+
+In this case, the mdio node should be defined as another PCIe
+endpoint node, at the same level with the ENETC port nodes.
+
+Required properties:
+
+- reg : Specifies PCIe Device Number and Function
+ Number of the ENETC endpoint device, according
+ to parent node bindings.
+- compatible : Should be "fsl,enetc-mdio".
+
+The remaining required mdio bus properties are standard, their bindings
+already defined in Documentation/devicetree/bindings/net/mdio.txt.
+
+Example:
+
+ ethernet@0,0 {
+ compatible = "fsl,enetc";
+ reg = <0x000000 0 0 0 0>;
+ phy-handle = <&sgmii_phy0>;
+ phy-connection-type = "sgmii";
+ };
+
+ mdio@0,3 {
+ compatible = "fsl,enetc-mdio";
+ reg = <0x000300 0 0 0 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ sgmii_phy0: ethernet-phy@2 {
+ reg = <0x2>;
+ };
+ };
+
+2. The ENETC port is an internal port or has a fixed-link external
+connection
In this case, the ENETC port node defines a fixed link connection,
as specified by Documentation/devicetree/bindings/net/fixed-link.txt.
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v2 4/4] arm64: dts: fsl: ls1028a: Enable eth port1 on the ls1028a QDS board
From: Claudiu Manoil @ 2019-07-25 11:19 UTC (permalink / raw)
To: David S . Miller
Cc: andrew, Rob Herring, Li Yang, alexandru.marginean, netdev,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <1564053568-20522-1-git-send-email-claudiu.manoil@nxp.com>
LS1028a has one Ethernet management interface. On the QDS board, the
MDIO signals are multiplexed to either on-board AR8035 PHY device or
to 4 PCIe slots allowing for SGMII cards.
To enable the Ethernet ENETC Port 1, which can only be connected to a
RGMII PHY, the multiplexer needs to be configured to route the MDIO to
the AR8035 PHY. The MDIO/MDC routing is controlled by bits 7:4 of FPGA
board config register 0x54, and value 0 selects the on-board RGMII PHY.
The FPGA board config registers are accessible on the i2c bus, at address
0x66.
The PF3 MDIO PCIe integrated endpoint device allows for centralized access
to the MDIO bus. Add the corresponding devicetree node and set it to be
the MDIO bus parent.
Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com>
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
v1 - none
v2 - none
.../boot/dts/freescale/fsl-ls1028a-qds.dts | 40 +++++++++++++++++++
.../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 6 +++
2 files changed, 46 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
index de6ef39f3118..663c4b728c07 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
@@ -85,6 +85,26 @@
system-clock-frequency = <25000000>;
};
};
+
+ mdio-mux {
+ compatible = "mdio-mux-multiplexer";
+ mux-controls = <&mux 0>;
+ mdio-parent-bus = <&enetc_mdio_pf3>;
+ #address-cells=<1>;
+ #size-cells = <0>;
+
+ /* on-board RGMII PHY */
+ mdio@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ qds_phy1: ethernet-phy@5 {
+ /* Atheros 8035 */
+ reg = <5>;
+ };
+ };
+ };
};
&duart0 {
@@ -164,6 +184,26 @@
};
};
};
+
+ fpga@66 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,ls1028aqds-fpga", "fsl,fpga-qixis-i2c",
+ "simple-mfd";
+ reg = <0x66>;
+
+ mux: mux-controller {
+ compatible = "reg-mux";
+ #mux-control-cells = <1>;
+ mux-reg-masks = <0x54 0xf0>; /* 0: reg 0x54, bits 7:4 */
+ };
+ };
+
+};
+
+&enetc_port1 {
+ phy-handle = <&qds_phy1>;
+ phy-connection-type = "rgmii-id";
};
&sai1 {
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index 7975519b4f56..de71153fda00 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -536,6 +536,12 @@
compatible = "fsl,enetc";
reg = <0x000100 0 0 0 0>;
};
+ enetc_mdio_pf3: mdio@0,3 {
+ compatible = "fsl,enetc-mdio";
+ reg = <0x000300 0 0 0 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
ethernet@0,4 {
compatible = "fsl,enetc-ptp";
reg = <0x000400 0 0 0 0>;
--
2.17.1
^ permalink raw reply related
* [PATCH 0/2] STMFX GPIO consumers update
From: Amelie Delaunay @ 2019-07-25 11:36 UTC (permalink / raw)
To: Maxime Coquelin, Alexandre Torgue, Rob Herring, Mark Rutland
Cc: devicetree, Amelie Delaunay, linux-stm32, linux-arm-kernel,
linux-kernel
This series depends on a STMFX pinctrl driver update
(https://lkml.org/lkml/2019/7/25/536).
Now, STMFX GPIO consumers can use standard GPIO bindings.
Alexandre Torgue (2):
ARM: dts: stm32: remove OV5640 pinctrl definition on stm32mp157c-ev1
ARM: dts: stm32: change pinctrl definition for joystick pins on
stm32mp157c-ev1
arch/arm/boot/dts/stm32mp157c-ev1.dts | 13 ++-----------
1 file changed, 2 insertions(+), 11 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/2] ARM: dts: stm32: remove OV5640 pinctrl definition on stm32mp157c-ev1
From: Amelie Delaunay @ 2019-07-25 11:36 UTC (permalink / raw)
To: Maxime Coquelin, Alexandre Torgue, Rob Herring, Mark Rutland
Cc: linux-stm32, linux-arm-kernel, devicetree, linux-kernel,
Amelie Delaunay
In-Reply-To: <1564054607-2028-1-git-send-email-amelie.delaunay@st.com>
From: Alexandre Torgue <alexandre.torgue@st.com>
"push-pull" configuration is now fully handled by the gpiolib and the
STMFX pinctrl driver. There is no longer need to declare a pinctrl group
to only configure "push-pull" setting for the line. It is done directly by
the gpiolib.
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
---
arch/arm/boot/dts/stm32mp157c-ev1.dts | 12 ++----------
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/stm32mp157c-ev1.dts b/arch/arm/boot/dts/stm32mp157c-ev1.dts
index 9ab25da..e4b04dd 100644
--- a/arch/arm/boot/dts/stm32mp157c-ev1.dts
+++ b/arch/arm/boot/dts/stm32mp157c-ev1.dts
@@ -182,14 +182,12 @@
ov5640: camera@3c {
compatible = "ovti,ov5640";
- pinctrl-names = "default";
- pinctrl-0 = <&ov5640_pins>;
reg = <0x3c>;
clocks = <&clk_ext_camera>;
clock-names = "xclk";
DOVDD-supply = <&v2v8>;
- powerdown-gpios = <&stmfx_pinctrl 18 GPIO_ACTIVE_HIGH>;
- reset-gpios = <&stmfx_pinctrl 19 GPIO_ACTIVE_LOW>;
+ powerdown-gpios = <&stmfx_pinctrl 18 (GPIO_ACTIVE_HIGH | GPIO_PUSH_PULL)>;
+ reset-gpios = <&stmfx_pinctrl 19 (GPIO_ACTIVE_LOW | GPIO_PUSH_PULL)>;
rotation = <180>;
status = "okay";
@@ -225,12 +223,6 @@
drive-push-pull;
bias-pull-down;
};
-
- ov5640_pins: camera {
- pins = "agpio2", "agpio3"; /* stmfx pins 18 & 19 */
- drive-push-pull;
- output-low;
- };
};
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: stm32: change pinctrl definition for joystick pins on stm32mp157c-ev1
From: Amelie Delaunay @ 2019-07-25 11:36 UTC (permalink / raw)
To: Maxime Coquelin, Alexandre Torgue, Rob Herring, Mark Rutland
Cc: linux-stm32, linux-arm-kernel, devicetree, linux-kernel,
Amelie Delaunay
In-Reply-To: <1564054607-2028-1-git-send-email-amelie.delaunay@st.com>
From: Alexandre Torgue <alexandre.torgue@st.com>
Pins used for joystick are all configured as input. "Push-pull" is not
a valid setting for an input.
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
---
arch/arm/boot/dts/stm32mp157c-ev1.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/stm32mp157c-ev1.dts b/arch/arm/boot/dts/stm32mp157c-ev1.dts
index e4b04dd..7d15f05 100644
--- a/arch/arm/boot/dts/stm32mp157c-ev1.dts
+++ b/arch/arm/boot/dts/stm32mp157c-ev1.dts
@@ -220,7 +220,6 @@
joystick_pins: joystick {
pins = "gpio0", "gpio1", "gpio2", "gpio3", "gpio4";
- drive-push-pull;
bias-pull-down;
};
};
--
2.7.4
^ permalink raw reply related
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