* [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: David Collins @ 2018-05-12 2:28 UTC (permalink / raw)
To: broonie, lgirdwood, robh+dt, mark.rutland
Cc: David Collins, linux-arm-msm, linux-arm-kernel, devicetree,
linux-kernel, rnayak, sboyd, dianders
In-Reply-To: <cover.1526088081.git.collinsd@codeaurora.org>
Introduce bindings for RPMh regulator devices found on some
Qualcomm Technlogies, Inc. SoCs. These devices allow a given
processor within the SoC to make PMIC regulator requests which
are aggregated within the RPMh hardware block along with requests
from other processors in the SoC to determine the final PMIC
regulator hardware state.
Signed-off-by: David Collins <collinsd@codeaurora.org>
---
.../bindings/regulator/qcom,rpmh-regulator.txt | 208 +++++++++++++++++++++
.../dt-bindings/regulator/qcom,rpmh-regulator.h | 36 ++++
2 files changed, 244 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
create mode 100644 include/dt-bindings/regulator/qcom,rpmh-regulator.h
diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
new file mode 100644
index 0000000..ad2185e
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
@@ -0,0 +1,208 @@
+Qualcomm Technologies, Inc. RPMh Regulators
+
+rpmh-regulator devices support PMIC regulator management via the Voltage
+Regulator Manager (VRM) and Oscillator Buffer (XOB) RPMh accelerators. The APPS
+processor communicates with these hardware blocks via a Resource State
+Coordinator (RSC) using command packets. The VRM allows changing four
+parameters for a given regulator: enable state, output voltage, operating mode,
+and minimum headroom voltage. The XOB allows changing only a single parameter
+for a given regulator: its enable state. Despite its name, the XOB is capable
+of controlling the enable state of any PMIC peripheral. It is used for clock
+buffers, low-voltage switches, and LDO/SMPS regulators which have a fixed
+voltage and mode.
+
+=======================
+Required Node Structure
+=======================
+
+RPMh regulators must be described in two levels of device nodes. The first
+level describes the PMIC containing the regulators and must reside within an
+RPMh device node. The second level describes each regulator within the PMIC
+which is to be used on the board. Each of these regulators maps to a single
+RPMh resource.
+
+The names used for regulator nodes must match those supported by a given PMIC.
+Supported regulator node names:
+ PM8998: smps1 - smps13, ldo1 - ldo28, lvs1 - lvs2
+ PMI8998: bob
+ PM8005: smps1 - smps4
+
+========================
+First Level Nodes - PMIC
+========================
+
+- compatible
+ Usage: required
+ Value type: <string>
+ Definition: Must be one of: "qcom,pm8998-rpmh-regulators",
+ "qcom,pmi8998-rpmh-regulators" or
+ "qcom,pm8005-rpmh-regulators".
+
+- qcom,pmic-id
+ Usage: required
+ Value type: <string>
+ Definition: RPMh resource name suffix used for the regulators found on
+ this PMIC. Typical values: "a", "b", "c", "d", "e", "f".
+
+- vdd-s1-supply
+- vdd-s2-supply
+- vdd-s3-supply
+- vdd-s4-supply
+ Usage: optional (PM8998 and PM8005 only)
+ Value type: <phandle>
+ Definition: phandle of the parent supply regulator of one or more of the
+ regulators for this PMIC.
+
+- vdd-s5-supply
+- vdd-s6-supply
+- vdd-s7-supply
+- vdd-s8-supply
+- vdd-s9-supply
+- vdd-s10-supply
+- vdd-s11-supply
+- vdd-s12-supply
+- vdd-s13-supply
+- vdd-l1-l27-supply
+- vdd-l2-l8-l17-supply
+- vdd-l3-l11-supply
+- vdd-l4-l5-supply
+- vdd-l6-supply
+- vdd-l7-l12-l14-l15-supply
+- vdd-l9-supply
+- vdd-l10-l23-l25-supply
+- vdd-l13-l19-l21-supply
+- vdd-l16-l28-supply
+- vdd-l18-l22-supply
+- vdd-l20-l24-supply
+- vdd-l26-supply
+- vin-lvs-1-2-supply
+ Usage: optional (PM8998 only)
+ Value type: <phandle>
+ Definition: phandle of the parent supply regulator of one or more of the
+ regulators for this PMIC.
+
+- vdd-bob-supply
+ Usage: optional (PMI8998 only)
+ Value type: <phandle>
+ Definition: BOB regulator parent supply phandle
+
+===============================
+Second Level Nodes - Regulators
+===============================
+
+- qcom,regulator-initial-microvolt
+ Usage: optional; VRM regulators only
+ Value type: <u32>
+ Definition: Specifies the initial voltage in microvolts to request for a
+ VRM regulator.
+
+- regulator-initial-mode
+ Usage: optional; VRM regulators only
+ Value type: <u32>
+ Definition: Specifies the initial mode to request for a VRM regulator.
+ Supported values are RPMH_REGULATOR_MODE_* which are defined
+ in [1] (i.e. 0 to 3). This property may be specified even
+ if the regulator-allow-set-load property is not specified.
+
+- qcom,allowed-drms-modes
+ Usage: required if regulator-allow-set-load is specified;
+ VRM regulators only
+ Value type: <prop-encoded-array>
+ Definition: A list of integers specifying the PMIC regulator modes which
+ can be configured at runtime based upon consumer load needs.
+ Supported values are RPMH_REGULATOR_MODE_* which are defined
+ in [1] (i.e. 0 to 3).
+
+- qcom,drms-mode-max-microamps
+ Usage: required if regulator-allow-set-load is specified;
+ VRM regulators only
+ Value type: <prop-encoded-array>
+ Definition: A list of integers specifying the maximum allowed load
+ current in microamps for each of the modes listed in
+ qcom,allowed-drms-modes (matched 1-to-1 in order). Elements
+ must be specified in order from lowest to highest value.
+
+- qcom,headroom-microvolt
+ Usage: optional; VRM regulators only
+ Value type: <u32>
+ Definition: Specifies the headroom voltage in microvolts to request for
+ a VRM regulator. RPMh hardware automatically ensures that
+ the parent of this regulator outputs a voltage high enough
+ to satisfy the requested headroom. Supported values are
+ 0 to 511000.
+
+- qcom,always-wait-for-ack
+ Usage: optional
+ Value type: <empty>
+ Definition: Boolean flag which indicates that the application processor
+ must wait for an ACK or a NACK from RPMh for every request
+ sent for this regulator including those which are for a
+ strictly lower power state.
+
+Other properties defined in Documentation/devicetree/bindings/regulator.txt
+may also be used.
+
+[1] include/dt-bindings/regulator/qcom,rpmh-regulator.h
+
+========
+Examples
+========
+
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+
+&apps_rsc {
+ pm8998-rpmh-regulators {
+ compatible = "qcom,pm8998-rpmh-regulators";
+ qcom,pmic-id = "a";
+
+ vdd-l7-l12-l14-l15-supply = <&pm8998_s5>;
+
+ smps2 {
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ qcom,regulator-initial-microvolt = <1100000>;
+ };
+
+ pm8998_s5: smps5 {
+ regulator-min-microvolt = <1904000>;
+ regulator-max-microvolt = <2040000>;
+ qcom,regulator-initial-microvolt = <1904000>;
+ };
+
+ ldo7 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ qcom,regulator-initial-microvolt = <1800000>;
+ qcom,headroom-microvolt = <56000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_LPM>;
+ regulator-allowed-modes =
+ <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ qcom,allowed-drms-modes =
+ <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ qcom,drms-mode-max-microamps = <10000 1000000>;
+ };
+
+ lvs1 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+ };
+
+ pmi8998-rpmh-regulators {
+ compatible = "qcom,pmi8998-rpmh-regulators";
+ qcom,pmic-id = "b";
+
+ bob {
+ regulator-min-microvolt = <3312000>;
+ regulator-max-microvolt = <3600000>;
+ qcom,regulator-initial-microvolt = <3312000>;
+ regulator-allowed-modes =
+ <RPMH_REGULATOR_MODE_AUTO
+ RPMH_REGULATOR_MODE_HPM>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_AUTO>;
+ };
+ };
+};
diff --git a/include/dt-bindings/regulator/qcom,rpmh-regulator.h b/include/dt-bindings/regulator/qcom,rpmh-regulator.h
new file mode 100644
index 0000000..4378c4b
--- /dev/null
+++ b/include/dt-bindings/regulator/qcom,rpmh-regulator.h
@@ -0,0 +1,36 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (c) 2018, The Linux Foundation. All rights reserved. */
+
+#ifndef __QCOM_RPMH_REGULATOR_H
+#define __QCOM_RPMH_REGULATOR_H
+
+/*
+ * These mode constants may be used for regulator-initial-mode and
+ * qcom,allowed-drms-modes properties of an RPMh regulator device tree node.
+ * Each type of regulator supports a subset of the possible modes.
+ *
+ * %RPMH_REGULATOR_MODE_RET: Retention mode in which only an extremely small
+ * load current is allowed. This mode is supported
+ * by LDO and SMPS type regulators.
+ * %RPMH_REGULATOR_MODE_LPM: Low power mode in which a small load current is
+ * allowed. This mode corresponds to PFM for SMPS
+ * and BOB type regulators. This mode is supported
+ * by LDO, HFSMPS, BOB, and PMIC4 FTSMPS type
+ * regulators.
+ * %RPMH_REGULATOR_MODE_AUTO: Auto mode in which the regulator hardware
+ * automatically switches between LPM and HPM based
+ * upon the real-time load current. This mode is
+ * supported by HFSMPS, BOB, and PMIC4 FTSMPS type
+ * regulators.
+ * %RPMH_REGULATOR_MODE_HPM: High power mode in which the full rated current
+ * of the regulator is allowed. This mode
+ * corresponds to PWM for SMPS and BOB type
+ * regulators. This mode is supported by all types
+ * of regulators.
+ */
+#define RPMH_REGULATOR_MODE_RET 0
+#define RPMH_REGULATOR_MODE_LPM 1
+#define RPMH_REGULATOR_MODE_AUTO 2
+#define RPMH_REGULATOR_MODE_HPM 3
+
+#endif
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH v3 0/2] regulator: add QCOM RPMh regulator driver
From: David Collins @ 2018-05-12 2:28 UTC (permalink / raw)
To: broonie, lgirdwood, robh+dt, mark.rutland
Cc: devicetree, rnayak, David Collins, sboyd, linux-arm-msm,
linux-kernel, dianders, linux-arm-kernel
This patch series adds a driver and device tree binding documentation for
PMIC regulator control via Resource Power Manager-hardened (RPMh) on some
Qualcomm Technologies, Inc. SoCs such as SDM845. RPMh is a hardware block
which contains several accelerators which are used to manage various
hardware resources that are shared between the processors of the SoC. The
final hardware state of a regulator is determined within RPMh by performing
max aggregation of the requests made by all of the processors.
The RPMh regulator driver depends upon the RPMh driver [1] and command DB
driver [2] which are both still undergoing review. It also depends upon
two recent of_regulator changes: [3] and [4].
Changes since v2 [5]:
- Replaced '_' with '-' in device tree supply property names
- Renamed qcom_rpmh-regulator.c to be qcom-rpmh-regulator.c
- Updated various DT property names to use "microvolt" and "microamp"
- Moved allowed modes constraint specification out of the driver [4]
- Replaced rpmh_client with device pointer to match new RPMh API [1]
- Corrected drms mode threshold checking
- Initialized voltage_selector to -EINVAL when not specified in DT
- Added constants for PMIC regulator hardware modes
- Corrected type sign of mode mapping tables
- Made variable names for mode arrays plural
- Simplified Kconfig depends on
- Removed unnecessary constants and struct fields
- Added some descriptive comments
Changes since v1 [6]:
- Addressed review feedback from Doug, Mark, and Stephen
- Replaced set_voltage()/get_voltage() callbacks with set_voltage_sel()/
get_voltage_sel()
- Added set_bypass()/get_bypass() callbacks for BOB pass-through mode
control
- Removed top-level PMIC data structures
- Removed initialization variables from structs and passed them as
function parameters
- Removed various comments and error messages
- Simplified mode handling
- Refactored per-PMIC rpmh-regulator data specification
- Simplified probe function
- Moved header into DT patch
- Removed redundant property listings from DT binding documentation
[1]: https://lkml.org/lkml/2018/5/9/729
[2]: https://lkml.org/lkml/2018/4/10/714
[3]: https://patchwork.kernel.org/patch/10348629
[4]: https://lkml.org/lkml/2018/5/11/696
[5]: https://lkml.org/lkml/2018/4/13/687
[6]: https://lkml.org/lkml/2018/3/16/1431
David Collins (2):
regulator: dt-bindings: add QCOM RPMh regulator bindings
regulator: add QCOM RPMh regulator driver
.../bindings/regulator/qcom,rpmh-regulator.txt | 208 +++++
drivers/regulator/Kconfig | 9 +
drivers/regulator/Makefile | 1 +
drivers/regulator/qcom-rpmh-regulator.c | 925 +++++++++++++++++++++
.../dt-bindings/regulator/qcom,rpmh-regulator.h | 36 +
5 files changed, 1179 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
create mode 100644 drivers/regulator/qcom-rpmh-regulator.c
create mode 100644 include/dt-bindings/regulator/qcom,rpmh-regulator.h
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 2/2] regulator: of: add support for allowed modes configuration
From: David Collins @ 2018-05-12 1:46 UTC (permalink / raw)
To: broonie, lgirdwood, robh+dt, mark.rutland
Cc: David Collins, linux-arm-msm, linux-arm-kernel, devicetree,
linux-kernel, rnayak, sboyd, dianders
In-Reply-To: <cover.1526088289.git.collinsd@codeaurora.org>
Add support for configuring the machine constraints
valid_modes_mask element based on a list of allowed modes
specified via a device tree property.
Signed-off-by: David Collins <collinsd@codeaurora.org>
---
drivers/regulator/of_regulator.c | 29 ++++++++++++++++++++++++++++-
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index 0d3f73e..d61fed2 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -32,7 +32,7 @@ static void of_get_regulation_constraints(struct device_node *np,
struct regulator_state *suspend_state;
struct device_node *suspend_np;
unsigned int mode;
- int ret, i;
+ int ret, i, len;
u32 pval;
constraints->name = of_get_property(np, "regulator-name", NULL);
@@ -136,6 +136,33 @@ static void of_get_regulation_constraints(struct device_node *np,
}
}
+ len = of_property_count_elems_of_size(np, "regulator-allowed-modes",
+ sizeof(u32));
+ if (len > 0) {
+ if (desc && desc->of_map_mode) {
+ for (i = 0; i < len; i++) {
+ ret = of_property_read_u32_index(np,
+ "regulator-allowed-modes", i, &pval);
+ if (ret) {
+ pr_err("%s: couldn't read allowed modes index %d, ret=%d\n",
+ np->name, i, ret);
+ break;
+ }
+ mode = desc->of_map_mode(pval);
+ if (mode == REGULATOR_MODE_INVALID)
+ pr_err("%s: invalid regulator-allowed-modes element %u\n",
+ np->name, pval);
+ else
+ constraints->valid_modes_mask |= mode;
+ }
+ if (constraints->valid_modes_mask)
+ constraints->valid_ops_mask
+ |= REGULATOR_CHANGE_MODE;
+ } else {
+ pr_warn("%s: mode mapping not defined\n", np->name);
+ }
+ }
+
if (!of_property_read_u32(np, "regulator-system-load", &pval))
constraints->system_load = pval;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH 1/2] regulator: of: add property for allowed modes specification
From: David Collins @ 2018-05-12 1:46 UTC (permalink / raw)
To: broonie, lgirdwood, robh+dt, mark.rutland
Cc: David Collins, linux-arm-msm, linux-arm-kernel, devicetree,
linux-kernel, rnayak, sboyd, dianders
In-Reply-To: <cover.1526088289.git.collinsd@codeaurora.org>
Add a common device tree property for regulator nodes to support
the specification of allowed operating modes.
Signed-off-by: David Collins <collinsd@codeaurora.org>
---
Documentation/devicetree/bindings/regulator/regulator.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt
index 2babe15b..c627aa0 100644
--- a/Documentation/devicetree/bindings/regulator/regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -59,6 +59,11 @@ Optional properties:
- regulator-initial-mode: initial operating mode. The set of possible operating
modes depends on the capabilities of every hardware so each device binding
documentation explains which values the regulator supports.
+- regulator-allowed-modes: list of operating modes that software is allowed to
+ configure for the regulator at run-time. Elements may be specified in any
+ order. The set of possible operating modes depends on the capabilities of
+ every hardware so each device binding document explains which values the
+ regulator supports.
- regulator-system-load: Load in uA present on regulator that is not captured by
any consumer request.
- regulator-pull-down: Enable pull down resistor when the regulator is disabled.
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH 0/2] regulator: of: add device tree property for allowed modes
From: David Collins @ 2018-05-12 1:46 UTC (permalink / raw)
To: broonie, lgirdwood, robh+dt, mark.rutland
Cc: David Collins, linux-arm-msm, linux-arm-kernel, devicetree,
linux-kernel, rnayak, sboyd, dianders
There is currently no accepted way to configure constraints->valid_modes_mask
for regulators defined in device tree. This patch series defines a new
common regulator device tree property, regulator-allowed-modes, which can be
used to specify the set of modes that the regulator is allowed to use.
It also implements parsing for this new property inside of the
of_get_regulation_constraints() function.
David Collins (2):
regulator: of: add property for allowed modes specification
regulator: of: add support for allowed modes configuration
.../devicetree/bindings/regulator/regulator.txt | 5 ++++
drivers/regulator/of_regulator.c | 29 +++++++++++++++++++++-
2 files changed, 33 insertions(+), 1 deletion(-)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* 答复: [PATCH v3 2/2] arm64: dts: hi3660: Add pcie msi interrupt attribute
From: songxiaowei @ 2018-05-12 0:52 UTC (permalink / raw)
To: xuwei (O), chenyao (F), Wangbinghui, lorenzo.pieralisi@arm.com,
bhelgaas@google.com, robh+dt@kernel.org, mark.rutland@arm.com,
catalin.marinas@arm.com, will.deacon@arm.com,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
Cc: Suzhuangluan, dimitrysh@google.com, guodong.xu@linaro.org,
Kongfei
In-Reply-To: <5AF5A411.4010507@hisilicon.com>
Hi Wei,
Thanks a lot.
Xiaowei.
> -----邮件原件-----
> 发件人: xuwei (O)
> 发送时间: 2018年5月11日 22:09
> 收件人: chenyao (F) <chenyao11@huawei.com>; songxiaowei
> <songxiaowei@hisilicon.com>; Wangbinghui <wangbinghui@hisilicon.com>;
> lorenzo.pieralisi@arm.com; bhelgaas@google.com; robh+dt@kernel.org;
> mark.rutland@arm.com; catalin.marinas@arm.com; will.deacon@arm.com;
> linux-pci@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org
> 抄送: dimitrysh@google.com; guodong.xu@linaro.org; Suzhuangluan
> <suzhuangluan@hisilicon.com>; Kongfei <kongfei@hisilicon.com>; xuwei (O)
> <xuwei5@huawei.com>
> 主题: Re: [PATCH v3 2/2] arm64: dts: hi3660: Add pcie msi interrupt attribute
>
> Hi Yao,
>
> On 2018/5/11 10:15, Yao Chen wrote:
> > Add pcie msi interrupt attribute for hi3660 SOC.
> >
> > Signed-off-by: Yao Chen <chenyao11@huawei.com>
>
> Applied patch 2 into the hisilicon dt tree.
> Thanks!
>
> BR,
> Wei
>
> > ---
> > arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> > index ec3eb8e..2cef8f4 100644
> > --- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> > +++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> > @@ -872,6 +872,8 @@
> > 0x0 0x02000000>;
> > num-lanes = <1>;
> > #interrupt-cells = <1>;
> > + interrupts = <0 283 4>;
> > + interrupt-names = "msi";
> > interrupt-map-mask = <0xf800 0 0 7>;
> > interrupt-map = <0x0 0 0 1
> > &gic GIC_SPI 282 IRQ_TYPE_LEVEL_HIGH>,
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 11/13] dt-bindings: power: add PX30 SoCs header for power-domain
From: Heiko Stuebner @ 2018-05-11 22:11 UTC (permalink / raw)
To: Elaine Zhang
Cc: robh+dt, mark.rutland, devicetree, rjw, khilman, ulf.hansson,
linux-pm, linux-arm-kernel, linux-rockchip, linux-kernel, wxt,
xxx, xf, huangtao, Finley Xiao
In-Reply-To: <1526009672-2097-1-git-send-email-zhangqing@rock-chips.com>
Hi Elaine,
Am Freitag, 11. Mai 2018, 05:34:32 CEST schrieb Elaine Zhang:
> According to a description from TRM, add all the power domains.
>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
that's a bit ambigous, having the Signed-offs like above.
Either you are the author+sender of the patch, then Finley's
Signed-off should go away ... or Finley is the author and you
are the sender, then the author of the patch should be set
correctly (--author option for git) and the Signed-offs should
switch places (= Finley first, then yours). Please fix.
This seems to be true for most patches in this series.
> ---
> include/dt-bindings/power/px30-power.h | 32 ++++++++++++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
> create mode 100644 include/dt-bindings/power/px30-power.h
>
> diff --git a/include/dt-bindings/power/px30-power.h b/include/dt-bindings/power/px30-power.h
> new file mode 100644
> index 000000000000..4ed482e80950
> --- /dev/null
> +++ b/include/dt-bindings/power/px30-power.h
Here I have a naming question. When looking at the vendor kernel
it looks like the px30 is largely related to the rk3326.
(rk3326.dtsi includeing the px30.dtsi)
What is the reason for basing the naming on the px30 this time? And could
we possibly keep to rkXXXX names for the basic things in the kernel, thus
keeping the pxXX as second name, like with the other px-variants before?
Thanks
Heiko
^ permalink raw reply
* [PATCH 2/2] soc: bcm: brcmstb: Add missing DDR MEMC compatible strings
From: Florian Fainelli @ 2018-05-11 22:02 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Florian Fainelli, Rob Herring, Mark Rutland, Brian Norris,
Gregory Fong, maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE,
Doug Berger, Justin Chen,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <20180511220242.837-1-f.fainelli@gmail.com>
We would not be matching the following chip/compatible strings
combinations, which would lead to not setting the warm boot flag
correctly, fix that:
7260A0/B0: brcm,brcmstb-memc-ddr-rev-b.2.1
7255A0: brcm,brcmstb-memc-ddr-rev-b.2.3
7278Bx: brcm,brcmstb-memc-ddr-rev-b.3.1
The B2.1 core (which is in 7260 A0 and B0) doesn't have the
SHIMPHY_ADDR_CNTL_0_DDR_PAD_CNTRL setup in the memsys init code, nor
does it have the warm boot flag re-definition on entry. Those changes
were for B2.2 and later MEMSYS cores. Fall back to the previous S2/S3
entry method for these specific chips.
Fixes: 0b741b8234c8 ("soc: bcm: brcmstb: Add support for S2/S3/S5 suspend states (ARM)")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt | 3 +++
drivers/soc/bcm/brcmstb/pm/pm-arm.c | 12 ++++++++++++
2 files changed, 15 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt b/Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt
index fb762059e68e..104cc9b41df4 100644
--- a/Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt
@@ -189,8 +189,11 @@ Power-Down (SRPD), among other things.
Required properties:
- compatible : should contain one of these
+ "brcm,brcmstb-memc-ddr-rev-b.2.1"
"brcm,brcmstb-memc-ddr-rev-b.2.2"
+ "brcm,brcmstb-memc-ddr-rev-b.2.3"
"brcm,brcmstb-memc-ddr-rev-b.3.0"
+ "brcm,brcmstb-memc-ddr-rev-b.3.1"
"brcm,brcmstb-memc-ddr"
- reg : the MEMC DDR register range
diff --git a/drivers/soc/bcm/brcmstb/pm/pm-arm.c b/drivers/soc/bcm/brcmstb/pm/pm-arm.c
index ade724677238..a5577dd5eb08 100644
--- a/drivers/soc/bcm/brcmstb/pm/pm-arm.c
+++ b/drivers/soc/bcm/brcmstb/pm/pm-arm.c
@@ -627,14 +627,26 @@ static const struct of_device_id ddr_shimphy_dt_ids[] = {
};
static const struct of_device_id brcmstb_memc_of_match[] = {
+ {
+ .compatible = "brcm,brcmstb-memc-ddr-rev-b.2.1",
+ .data = &ddr_seq,
+ },
{
.compatible = "brcm,brcmstb-memc-ddr-rev-b.2.2",
.data = &ddr_seq_b22,
},
+ {
+ .compatible = "brcm,brcmstb-memc-ddr-rev-b.2.3",
+ .data = &ddr_seq_b22,
+ },
{
.compatible = "brcm,brcmstb-memc-ddr-rev-b.3.0",
.data = &ddr_seq_b22,
},
+ {
+ .compatible = "brcm,brcmstb-memc-ddr-rev-b.3.1",
+ .data = &ddr_seq_b22,
+ },
{
.compatible = "brcm,brcmstb-memc-ddr",
.data = &ddr_seq,
--
2.14.1
^ permalink raw reply related
* [PATCH 1/2] soc: bcm: brcmstb: pm: Add support for newer rev B3.0 controllers
From: Florian Fainelli @ 2018-05-11 22:02 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Doug Berger, Florian Fainelli, Rob Herring, Mark Rutland,
Brian Norris, Gregory Fong,
maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE, Justin Chen,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <20180511220242.837-1-f.fainelli@gmail.com>
From: Doug Berger <opendmb@gmail.com>
Update the Device Tree binding document and add a matching entry for the
MEMC DDR controller revision B3.0 which is found on chips like 7278A0
and newer.
Signed-off-by: Doug Berger <opendmb@gmail.com>
[florian: tweak commit message, make it apply to upstream kernel]
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt | 1 +
drivers/soc/bcm/brcmstb/pm/pm-arm.c | 4 ++++
2 files changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt b/Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt
index c052caad36e8..fb762059e68e 100644
--- a/Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt
@@ -190,6 +190,7 @@ Power-Down (SRPD), among other things.
Required properties:
- compatible : should contain one of these
"brcm,brcmstb-memc-ddr-rev-b.2.2"
+ "brcm,brcmstb-memc-ddr-rev-b.3.0"
"brcm,brcmstb-memc-ddr"
- reg : the MEMC DDR register range
diff --git a/drivers/soc/bcm/brcmstb/pm/pm-arm.c b/drivers/soc/bcm/brcmstb/pm/pm-arm.c
index dcf8c8065508..ade724677238 100644
--- a/drivers/soc/bcm/brcmstb/pm/pm-arm.c
+++ b/drivers/soc/bcm/brcmstb/pm/pm-arm.c
@@ -631,6 +631,10 @@ static const struct of_device_id brcmstb_memc_of_match[] = {
.compatible = "brcm,brcmstb-memc-ddr-rev-b.2.2",
.data = &ddr_seq_b22,
},
+ {
+ .compatible = "brcm,brcmstb-memc-ddr-rev-b.3.0",
+ .data = &ddr_seq_b22,
+ },
{
.compatible = "brcm,brcmstb-memc-ddr",
.data = &ddr_seq,
--
2.14.1
^ permalink raw reply related
* [PATCH 0/2] soc: bcm: brcmstb: Updates to support newer controllers
From: Florian Fainelli @ 2018-05-11 22:02 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Florian Fainelli, Rob Herring, Mark Rutland, Brian Norris,
Gregory Fong, maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE,
Doug Berger, Justin Chen,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
Hi all,
This patch series adds support for newer reveisions of the memory controller
which is necessary to make sure we do use the right programming sequence to
enter S2 and S3 suspend/resume modes.
Doug Berger (1):
soc: bcm: brcmstb: pm: Add support for newer rev B3.0 controllers
Florian Fainelli (1):
soc: bcm: brcmstb: Add missing DDR MEMC compatible strings
.../devicetree/bindings/arm/bcm/brcm,brcmstb.txt | 4 ++++
drivers/soc/bcm/brcmstb/pm/pm-arm.c | 16 ++++++++++++++++
2 files changed, 20 insertions(+)
--
2.14.1
^ permalink raw reply
* Re: [PATCH v5 14/14] staging: typec: tcpci: move tcpci driver out of staging
From: Mats Karrman @ 2018-05-11 21:37 UTC (permalink / raw)
To: Li Jun, robh+dt, gregkh, heikki.krogerus, linux
Cc: a.hajda, cw00.choi, shufan_lee, peter.chen, gsomlo, devicetree,
linux-usb, linux-imx
In-Reply-To: <1525307094-27402-15-git-send-email-jun.li@nxp.com>
Hi Li Jun,
This patch takes away building the entire staging/typec tree but this is still
not empty after your patch, another driver "tcpci_rt1711h" is there.
Better just remove tcpci from staging/typec/{Kconfig,Makefile}
// Mats
On 2018-05-03 02:24, Li Jun wrote:
> Move TCPCI(Typec port controller interface) driver out of staging.
>
> Signed-off-by: Li Jun <jun.li@nxp.com>
> ---
> drivers/staging/Kconfig | 2 --
> drivers/staging/Makefile | 1 -
> drivers/staging/typec/TODO | 5 -----
> drivers/usb/typec/Kconfig | 7 +++++++
> drivers/usb/typec/Makefile | 1 +
> drivers/{staging => usb}/typec/tcpci.c | 0
> drivers/{staging => usb}/typec/tcpci.h | 0
> 7 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
> index d5926f0..d83ff66 100644
> --- a/drivers/staging/Kconfig
> +++ b/drivers/staging/Kconfig
> @@ -112,8 +112,6 @@ source "drivers/staging/greybus/Kconfig"
>
> source "drivers/staging/vc04_services/Kconfig"
>
> -source "drivers/staging/typec/Kconfig"
> -
> source "drivers/staging/vboxvideo/Kconfig"
>
> source "drivers/staging/pi433/Kconfig"
> diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
> index 919753c..a71ec1f 100644
> --- a/drivers/staging/Makefile
> +++ b/drivers/staging/Makefile
> @@ -2,7 +2,6 @@
> # Makefile for staging directory
>
> obj-y += media/
> -obj-y += typec/
> obj-$(CONFIG_IPX) += ipx/
> obj-$(CONFIG_NCP_FS) += ncpfs/
> obj-$(CONFIG_PRISM2_USB) += wlan-ng/
> diff --git a/drivers/staging/typec/TODO b/drivers/staging/typec/TODO
> deleted file mode 100644
> index 53fe2f7..0000000
> --- a/drivers/staging/typec/TODO
> +++ /dev/null
> @@ -1,5 +0,0 @@
> -tcpci:
> -- Test with real hardware
> -
> -Please send patches to Guenter Roeck <linux@roeck-us.net> and copy
> -Heikki Krogerus <heikki.krogerus@linux.intel.com>.
> diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
> index 2c8eab1..0a862fc 100644
> --- a/drivers/usb/typec/Kconfig
> +++ b/drivers/usb/typec/Kconfig
> @@ -56,6 +56,13 @@ config TYPEC_TCPM
>
> if TYPEC_TCPM
>
> +config TYPEC_TCPCI
> + tristate "Type-C Port Controller Interface driver"
> + depends on I2C
> + select REGMAP_I2C
> + help
> + Type-C Port Controller driver for TCPCI-compliant controller.
> +
> source "drivers/usb/typec/fusb302/Kconfig"
>
> config TYPEC_WCOVE
> diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
> index 1f599a6..02758a1 100644
> --- a/drivers/usb/typec/Makefile
> +++ b/drivers/usb/typec/Makefile
> @@ -7,3 +7,4 @@ obj-$(CONFIG_TYPEC_WCOVE) += typec_wcove.o
> obj-$(CONFIG_TYPEC_UCSI) += ucsi/
> obj-$(CONFIG_TYPEC_TPS6598X) += tps6598x.o
> obj-$(CONFIG_TYPEC) += mux/
> +obj-$(CONFIG_TYPEC_TCPCI) += tcpci.o
> diff --git a/drivers/staging/typec/tcpci.c b/drivers/usb/typec/tcpci.c
> similarity index 100%
> rename from drivers/staging/typec/tcpci.c
> rename to drivers/usb/typec/tcpci.c
> diff --git a/drivers/staging/typec/tcpci.h b/drivers/usb/typec/tcpci.h
> similarity index 100%
> rename from drivers/staging/typec/tcpci.h
> rename to drivers/usb/typec/tcpci.h
^ permalink raw reply
* Re: [PATCH v3 5/8] MIPS: jz4740: dts: Add bindings for the jz4740-wdt driver
From: Guenter Roeck @ 2018-05-11 21:30 UTC (permalink / raw)
To: James Hogan
Cc: Paul Cercueil, Wim Van Sebroeck, Mathieu Malaterre, Mark Rutland,
Rob Herring, linux-kernel, devicetree, linux-watchdog,
Ralf Baechle, linux-mips
In-Reply-To: <20180511211554.GA20264@jamesdev>
On Fri, May 11, 2018 at 10:15:55PM +0100, James Hogan wrote:
> On Fri, May 11, 2018 at 02:14:16PM -0700, Guenter Roeck wrote:
> > On Fri, May 11, 2018 at 09:54:14PM +0100, James Hogan wrote:
> > > On Fri, May 11, 2018 at 01:17:04PM -0300, Paul Cercueil wrote:
> > > > Le 11 mai 2018 11:52, James Hogan <jhogan@kernel.org> a écrit :
> > > > > Otherwise
> > > > > Acked-by: James Hogan <jhogan@kernel.org>
> > > > >
> > > > > I'm happy to apply for 4.18 with that change if you want it to go
> > > > > through the MIPS tree.
> > > >
> > > > Yes please!
> > >
> > > Done
> > >
> > Does that include the watchdog changes ? No problem with it, just asking to make
> > sure that those don't get lost.
>
> Yes, I suppose I was taking your reviewed-by as an ack.
>
Ok.
Thanks,
Guenter
^ permalink raw reply
* [PATCH] mtd: nand: Add support for reading ooblayout from device tree
From: Paul Cercueil @ 2018-05-11 21:29 UTC (permalink / raw)
To: David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut,
Richard Weinberger, Rob Herring, Mark Rutland
Cc: linux-mtd, devicetree, linux-kernel, Paul Cercueil
By specifying the properties "mtd-oob-ecc" and "mtd-oob-free", it is
now possible to specify from devicetree where the ECC data is located
inside the OOB region.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
---
Documentation/devicetree/bindings/mtd/nand.txt | 7 +++++
drivers/mtd/nand/raw/nand_base.c | 42 ++++++++++++++++++++++++++
2 files changed, 49 insertions(+)
diff --git a/Documentation/devicetree/bindings/mtd/nand.txt b/Documentation/devicetree/bindings/mtd/nand.txt
index 8bb11d809429..118ea92787cb 100644
--- a/Documentation/devicetree/bindings/mtd/nand.txt
+++ b/Documentation/devicetree/bindings/mtd/nand.txt
@@ -45,6 +45,13 @@ Optional NAND chip properties:
as reliable as possible.
- nand-rb: shall contain the native Ready/Busy ids.
+- nand-oob-ecc: <offset, length> couples of integers, specifying the offset
+ and length of the ECC data in the OOB region. There can be more
+ than one couple.
+- nand-oob-free: <offset, length> couples of integers, specifying the offset
+ and length of a free-to-use area in the OOB region. There can be
+ more than one couple.
+
The ECC strength and ECC step size properties define the correction capability
of a controller. Together, they say a controller can correct "{strength} bit
errors per {size} bytes".
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 72f3a89da513..c905531effb0 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -213,6 +213,43 @@ static const struct mtd_ooblayout_ops nand_ooblayout_lp_hamming_ops = {
.free = nand_ooblayout_free_lp_hamming,
};
+static int nand_oob_of(struct device_node *np, int section,
+ struct mtd_oob_region *oobregion, const char *prop)
+{
+ int ret = of_property_read_u32_index(np, prop,
+ section * 2, &oobregion->offset);
+ if (ret == -EOVERFLOW)
+ return -ERANGE; /* We're done */
+ if (ret)
+ return ret;
+
+ ret = of_property_read_u32_index(np, prop,
+ section * 2 + 1, &oobregion->length);
+ if (ret == -EOVERFLOW)
+ return -EINVAL; /* We must have an even number of integers */
+
+ return ret;
+}
+
+static int nand_ooblayout_ecc_of(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *oobregion)
+{
+ return nand_oob_of(mtd->dev.of_node, section,
+ oobregion, "nand-oob-ecc");
+}
+
+static int nand_ooblayout_free_of(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *oobregion)
+{
+ return nand_oob_of(mtd->dev.of_node, section,
+ oobregion, "nand-oob-free");
+}
+
+static const struct mtd_ooblayout_ops nand_ooblayout_of_ops = {
+ .ecc = nand_ooblayout_ecc_of,
+ .free = nand_ooblayout_free_of,
+};
+
static int check_offs_len(struct mtd_info *mtd,
loff_t ofs, uint64_t len)
{
@@ -5843,6 +5880,11 @@ static int nand_dt_init(struct nand_chip *chip)
if (of_property_read_bool(dn, "nand-ecc-maximize"))
chip->ecc.options |= NAND_ECC_MAXIMIZE;
+ if (!chip->mtd.ooblayout &&
+ of_property_read_bool(dn, "nand-oob-ecc") &&
+ of_property_read_bool(dn, "nand-oob-free"))
+ chip->mtd.ooblayout = &nand_ooblayout_of_ops;
+
return 0;
}
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v3 5/8] MIPS: jz4740: dts: Add bindings for the jz4740-wdt driver
From: James Hogan @ 2018-05-11 21:15 UTC (permalink / raw)
To: Guenter Roeck
Cc: Paul Cercueil, Wim Van Sebroeck, Mathieu Malaterre, Mark Rutland,
Rob Herring, linux-kernel, devicetree, linux-watchdog,
Ralf Baechle, linux-mips
In-Reply-To: <20180511211416.GA10947@roeck-us.net>
[-- Attachment #1: Type: text/plain, Size: 702 bytes --]
On Fri, May 11, 2018 at 02:14:16PM -0700, Guenter Roeck wrote:
> On Fri, May 11, 2018 at 09:54:14PM +0100, James Hogan wrote:
> > On Fri, May 11, 2018 at 01:17:04PM -0300, Paul Cercueil wrote:
> > > Le 11 mai 2018 11:52, James Hogan <jhogan@kernel.org> a écrit :
> > > > Otherwise
> > > > Acked-by: James Hogan <jhogan@kernel.org>
> > > >
> > > > I'm happy to apply for 4.18 with that change if you want it to go
> > > > through the MIPS tree.
> > >
> > > Yes please!
> >
> > Done
> >
> Does that include the watchdog changes ? No problem with it, just asking to make
> sure that those don't get lost.
Yes, I suppose I was taking your reviewed-by as an ack.
Cheers
James
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 5/8] MIPS: jz4740: dts: Add bindings for the jz4740-wdt driver
From: Guenter Roeck @ 2018-05-11 21:14 UTC (permalink / raw)
To: James Hogan
Cc: Paul Cercueil, Wim Van Sebroeck, Mathieu Malaterre, Mark Rutland,
Rob Herring, linux-kernel, devicetree, linux-watchdog,
Ralf Baechle, linux-mips
In-Reply-To: <20180511205413.GA18694@jamesdev>
On Fri, May 11, 2018 at 09:54:14PM +0100, James Hogan wrote:
> On Fri, May 11, 2018 at 01:17:04PM -0300, Paul Cercueil wrote:
> > Le 11 mai 2018 11:52, James Hogan <jhogan@kernel.org> a écrit :
> > > Otherwise
> > > Acked-by: James Hogan <jhogan@kernel.org>
> > >
> > > I'm happy to apply for 4.18 with that change if you want it to go
> > > through the MIPS tree.
> >
> > Yes please!
>
> Done
>
Does that include the watchdog changes ? No problem with it, just asking to make
sure that those don't get lost.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v3 5/8] MIPS: jz4740: dts: Add bindings for the jz4740-wdt driver
From: James Hogan @ 2018-05-11 20:54 UTC (permalink / raw)
To: Paul Cercueil
Cc: Wim Van Sebroeck, Mathieu Malaterre, Mark Rutland, Rob Herring,
linux-kernel, Guenter Roeck, devicetree, linux-watchdog,
Ralf Baechle, linux-mips
In-Reply-To: <5af5c20f.1c69fb81.e968b.17c0SMTPIN_ADDED_MISSING@mx.google.com>
[-- Attachment #1: Type: text/plain, Size: 346 bytes --]
On Fri, May 11, 2018 at 01:17:04PM -0300, Paul Cercueil wrote:
> Le 11 mai 2018 11:52, James Hogan <jhogan@kernel.org> a écrit :
> > Otherwise
> > Acked-by: James Hogan <jhogan@kernel.org>
> >
> > I'm happy to apply for 4.18 with that change if you want it to go
> > through the MIPS tree.
>
> Yes please!
Done
Thanks
James
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v5 1/2] dt: bindings: lm3601x: Introduce the lm3601x driver
From: Jacek Anaszewski @ 2018-05-11 20:27 UTC (permalink / raw)
To: Dan Murphy, Pavel Machek
Cc: robh+dt, mark.rutland, afd, devicetree, linux-kernel, linux-leds
In-Reply-To: <10ab412f-7206-2a01-9876-2a8beeec2287@ti.com>
Dan,
On 05/11/2018 02:12 PM, Dan Murphy wrote:
> Jacek
>
> Thanks for the review
>
> On 05/10/2018 03:17 PM, Jacek Anaszewski wrote:
>> Hi Dan,
>>
>> On 05/10/2018 09:10 PM, Dan Murphy wrote:
>>> On 05/10/2018 02:06 PM, Dan Murphy wrote:
>>>> Pavel
>>>>
>>>> On 05/10/2018 01:54 PM, Pavel Machek wrote:
>>>>> Hi!
>>>>>
>>>>>> Introduce the device tree bindings for the lm3601x
>>>>>> family of LED torch, flash and IR drivers.
>>>>>>
>>>>>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>>>>>
>>>>> Better, thanks.
>>>>>> +++ b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
>>>>>> @@ -0,0 +1,50 @@
>>>>>> +* Texas Instruments - lm3601x Single-LED Flash Driver
>>>>>
>>>>> Ok, so is it single-LED driver, or can it driver ir & white LEDs at
>>>>> the same time?
>>>>
>>>> It is a single LED driver. It can drive a Torch white LED or IR LED indefinitely or if the driver
>>>> is programmed to strobe mode the driver will drive the configured LED for the flash timeout specified.
>>>>
>>>> Basically a flash and a flash light. IR or White LED.
>>>>
>>>>
>>>>>
>>>>>> +Example:
>>>>>> +led-controller@64 {
>>>>>> + compatible = "ti,lm36010";
>>>>>> + #address-cells = <1>;
>>>>>> + #size-cells = <0>;
>>>>>> + reg = <0x64>;
>>>>>> +
>>>>>> + led@0 {
>>>>>> + reg = <0>;
>>>>>> + label = "white:torch";
>>>>>> + led-max-microamp = <10000>;
>>>>>> + };
>>>>>> +
>>>>>> + led@1 {
>>>>>> + reg = <1>;
>>>>>> + label = "white:flash";
>>>>>> + flash-max-microamp = <10000>;
>>>>>> + flash-max-timeout-us = <800>;
>>>>>> + };
>>>>>
>>>>> Is this realistic config? I'd expect flash to use more power than
>>>>> torch, and would expect longer timeout than 0.8msec.
>>>>
>>>> Timeout in the spreadsheet is ms I will update this example and code
>>>> Current in the spreadsheet is mA I will update this example and code
>>>>
>>>>>
>>>>> Also.. if this is physically one white LED, it should not be
>>>>> spread over reg = <0> and reg = <1>...
>>>>
>>>> If the torch LED and strobe LED are the same LED how do I expose them both to the user.
>>>> It is up to consumer to configure the required interfaces they want to expose to the filesystem.
>>
>> LED flash class interface is prepared for it.
>> led_clasdev_flash_register() internally calls led_classdev_register(),
>> so there is brightness file available for torch related operations.
>
> Yes the flash class may handle this and expose the brightness node but the HW has two different registers to set the
> corresponding brightness so one set brightness node does not work.
> There is no way to differentiate between the strobe brightness (register 4) and the torch brightness (register 3).
Hmm? There is brightness file (with brightness_set{_blocking} op) from
LED class and flash_brightness file (with flash_brightness_set op) from
LED class flash.
I've only now realized that you're not using flash_brightness_set op for
the "strobe_node" in your driver. I assume that you overlooked it.
Please don't introduce "strobe_brightness" naming convention - we
already have "flash_brightness" for that.
> When the enable register is written the driver will read the corresponding register and set
> the current for the LED.
>
> This is why I separated out the strobe from the torch into 2 different LED nodes.
>
> I cannot seem to find the data sheet on line for the max77693 so I cannot verify that the device only has
> a single brightness register for both torch and strobe.
It wasn't openly available at least at the time when I had an access
to it.
But - please look at the functions max77693_set_torch_current() and
max77693_set_flash_current(). The device has separate registers
for torch and flash brightnesses.
>>>> Maybe they don't want the strobe feature and just want LED on/off and switch between IR and White.
>>>>
>>>> The IR is driven via a different output pin.
>>>
>>> Correction. There is only one LED drive pin. The mode selected determines how the device will drive the
>>> LED. So you may have one device to drive a Torch and another device to drive the LED.
>>
>> But only one type of LED can be soldered on the board at a time, right?
>> If yes, then this is clearly a DT related configuration, and only
>> one child DT node should be defined for given board.
>
> But see above. There is not a clean way to expose the torch/ir and strobe separately.
>
> Dan
>
>
>>
>>> Strobe is available in either case but not always required if strobe is not desired by the customer hence
>>> why I have a separate DT node for it.
>>>
>>> Dan
>>>
>>>>
>>>> Dan
>>>>
>>>>>
>>>>> Best regards,
>>>>> Pavel
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* Re: [PATCH v5 2/2] leds: lm3601x: Introduce the lm3601x LED driver
From: Jacek Anaszewski @ 2018-05-11 20:26 UTC (permalink / raw)
To: Dan Murphy, robh+dt, mark.rutland, pavel, afd
Cc: devicetree, linux-kernel, linux-leds
In-Reply-To: <17630aca-1225-df61-7a5d-a921ecd9c78c@ti.com>
Hi Dan,
On 05/11/2018 01:56 PM, Dan Murphy wrote:
> Jacek
>
> Thanks for the review
>
> On 05/10/2018 03:48 PM, Jacek Anaszewski wrote:
>> Hi Dan,
>>
>> Thank you for the patch.
>>
>> On 05/10/2018 07:47 PM, Dan Murphy wrote:
>>> Introduce the family of LED devices that can
>>> drive a torch, strobe or IR LED.
>>>
>>> The LED driver can be configured with a strobe
>>> timer to execute a strobe flash. The IR LED
>>> brightness is controlled via the torch brightness
>>> register.
>>>
>>> The data sheet for each the LM36010 and LM36011
>>> LED drivers can be found here:
>>> http://www.ti.com/product/LM36010
>>> http://www.ti.com/product/LM36011
>>>
>>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>>> ---
>>>
>>> v5 - Fixed magic numbers, change reg cache type, added of_put_node to release
>>> the dt node ref, and I did not change the remove function to leave the LED in its
>>> state on driver removal - https://patchwork.kernel.org/patch/10391741/
>>>
>>> v4 - Fixed Cocci issue using ARRAY_SIZE - https://patchwork.kernel.org/patch/10389259/
>>> v3 - removed wildcard dt compatible, fixed copyright, fixed struct doc, removed
>>> RO registers from default, added regmap volatile for FLAGS_REG, updated regmap cache type,
>>> fixed unlock and extra semi colon in strobe_set, removed unnecessary out label
>>> in led register and fixed checking of the ret in brightness_set - https://patchwork.kernel.org/patch/10386243/
>>> v2 - Fixed kbuild issue and removed unused cdev_strobe - https://patchwork.kernel.org/patch/10384585/
>>>
>>>
>>> drivers/leds/Kconfig | 9 +
>>> drivers/leds/Makefile | 1 +
>>> drivers/leds/leds-lm3601x.c | 622 ++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 632 insertions(+)
>>> create mode 100644 drivers/leds/leds-lm3601x.c
>>>
>>> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
>>> index 2c896c0e69e1..50ae536f343f 100644
>>> --- a/drivers/leds/Kconfig
>>> +++ b/drivers/leds/Kconfig
>>> @@ -145,6 +145,15 @@ config LEDS_LM3692X
>>> This option enables support for the TI LM3692x family
>>> of white LED string drivers used for backlighting.
>>> +config LEDS_LM3601X
>>> + tristate "LED support for LM3601x Chips"
>>> + depends on LEDS_CLASS && I2C && OF
>>> + depends on LEDS_CLASS_FLASH
>>> + select REGMAP_I2C
>>> + help
>>> + This option enables support for the TI LM3601x family
>>> + of flash, torch and indicator classes.
>>> +
>>> config LEDS_LOCOMO
>>> tristate "LED Support for Locomo device"
>>> depends on LEDS_CLASS
>>> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
>>> index 91eca81cae82..b79807fe1b67 100644
>>> --- a/drivers/leds/Makefile
>>> +++ b/drivers/leds/Makefile
>>> @@ -76,6 +76,7 @@ obj-$(CONFIG_LEDS_MLXREG) += leds-mlxreg.o
>>> obj-$(CONFIG_LEDS_NIC78BX) += leds-nic78bx.o
>>> obj-$(CONFIG_LEDS_MT6323) += leds-mt6323.o
>>> obj-$(CONFIG_LEDS_LM3692X) += leds-lm3692x.o
>>> +obj-$(CONFIG_LEDS_LM3601X) += leds-lm3601x.o
>>> # LED SPI Drivers
>>> obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
>>> diff --git a/drivers/leds/leds-lm3601x.c b/drivers/leds/leds-lm3601x.c
>>> new file mode 100644
>>> index 000000000000..3c00886fbc7a
>>> --- /dev/null
>>> +++ b/drivers/leds/leds-lm3601x.c
>>> @@ -0,0 +1,622 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * Flash and torch driver for Texas Instruments LM3601X LED
>>> + * Flash driver chip family
>>> + * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
>>> + */
>>
>> Please use uniform "//" comment style here.
>
> Is this a LEDs only requirement because I checked a few other files and this is
> how the license and header is presented.
>
> Unless I missed some new change to source code headers. And the documentation
> does not dictate any change to this.
I started to require this since mixed comment styles look just
awkward to me. Moreover Linus also suggested it in [0]:
"And yes, feel free to replace block comments with // while at it."
Also grep shows the same approach at least in the sound subsystem :-)
>>
>>> +#include <linux/delay.h>
>>> +#include <linux/i2c.h>
>>> +#include <linux/leds.h>
>>> +#include <linux/led-class-flash.h>
>>> +#include <linux/module.h>
>>> +#include <linux/regmap.h>
>>> +#include <linux/slab.h>
>>> +#include <uapi/linux/uleds.h>
>>> +
>>> +#define LM3601X_LED_TORCH 0x0
>>> +#define LM3601X_LED_STROBE 0x1
>>> +#define LM3601X_LED_IR 0x2
>>> +
>>> +/* Registers */
>>> +#define LM3601X_ENABLE_REG 0x01
>>> +#define LM3601X_CFG_REG 0x02
>>> +#define LM3601X_LED_FLASH_REG 0x03
>>> +#define LM3601X_LED_TORCH_REG 0x04
>>> +#define LM3601X_FLAGS_REG 0x05
>>> +#define LM3601X_DEV_ID_REG 0x06
>>> +
>>> +#define LM3601X_SW_RESET BIT(7)
>>> +
>>> +/* Enable Mode bits */
>>> +#define LM3601X_MODE_STANDBY 0x00
>>> +#define LM3601X_MODE_IR_DRV BIT(0)
>>> +#define LM3601X_MODE_TORCH BIT(1)
>>> +#define LM3601X_MODE_STROBE (BIT(0) | BIT(1))
>>> +#define LM3601X_STRB_EN BIT(2)
>>> +#define LM3601X_STRB_LVL_TRIG ~BIT(3)
>>> +#define LM3601X_STRB_EDGE_TRIG BIT(3)
>>> +#define LM3601X_IVFM_EN BIT(4)
>>> +
>>> +#define LM36010_BOOST_LIMIT_19 ~BIT(5)
>>> +#define LM36010_BOOST_LIMIT_28 BIT(5)
>>> +#define LM36010_BOOST_FREQ_2MHZ ~BIT(6)
>>> +#define LM36010_BOOST_FREQ_4MHZ BIT(6)
>>> +#define LM36010_BOOST_MODE_NORM ~BIT(7)
>>> +#define LM36010_BOOST_MODE_PASS BIT(7)
>>> +
>>> +/* Flag Mask */
>>> +#define LM3601X_FLASH_TIME_OUT BIT(0)
>>> +#define LM3601X_UVLO_FAULT BIT(1)
>>> +#define LM3601X_THERM_SHUTDOWN BIT(2)
>>> +#define LM3601X_THERM_CURR BIT(3)
>>> +#define LM36010_CURR_LIMIT BIT(4)
>>> +#define LM3601X_SHORT_FAULT BIT(5)
>>> +#define LM3601X_IVFM_TRIP BIT(6)
>>> +#define LM36010_OVP_FAULT BIT(7)
>>> +
>>> +#define LM3601X_MIN_TORCH_I_UA 2400
>>> +#define LM3601X_MIN_STROBE_I_MA 11
>>> +
>>> +#define LM3601X_TIMEOUT_MASK 0x1e
>>> +#define LM3601X_ENABLE_MASK 0x03
>>> +
>>> +enum lm3601x_type {
>>> + CHIP_LM36010 = 0,
>>> + CHIP_LM36011,
>>> +};
>>> +
>>> +/**
>>> + * struct lm3601x_max_timeouts -
>>> + * @timeout: timeout value in ms
>>> + * @regval: the value of the register to write
>>> + */
>>> +struct lm3601x_max_timeouts {
>>> + int timeout;
>>> + int reg_val;
>>> +};
>>> +
>>> +/**
>>> + * struct lm3601x_led -
>>> + * @lock: Lock for reading/writing the device
>>> + * @regmap: Devices register map
>>> + * @client: Pointer to the I2C client
>>> + * @cdev_torch: led class device pointer for the torch
>>> + * @cdev_ir: led class device pointer for infrared
>>> + * @fled_cdev: flash led class device pointer
>>> + * @strobe_node: DT device node for the strobe
>>> + * @torch: LED label for the torch
>>> + * @strobe: LED label for the strobe
>>> + * @ir: LED label for the infrared
>>> + * @last_flag: last known flags register value
>>> + * @strobe_timeout: the timeout for the strobe
>>> + * @torch_current_max: maximum current for the torch
>>> + * @strobe_current_max: maximum current for the strobe
>>> + * @max_strobe_timeout: maximum timeout for the strobe
>>> + */
>>> +struct lm3601x_led {
>>> + struct mutex lock;
>>> + struct regmap *regmap;
>>> + struct i2c_client *client;
>>> +
>>> + struct led_classdev cdev_torch;
>>> + struct led_classdev cdev_ir;
>>> +
>>> + struct led_classdev_flash fled_cdev;
>>> +
>>> + struct device_node *strobe_node;
>>> + struct device_node *torch_node;
>>> + struct device_node *ir_node;
>>> +
>>> + char torch[LED_MAX_NAME_SIZE];
>>> + char strobe[LED_MAX_NAME_SIZE];
>>> + char ir[LED_MAX_NAME_SIZE];
>>> +
>>> + unsigned int last_flag;
>>> + unsigned int strobe_timeout;
>>> +
>>> + u32 torch_current_max;
>>> + u32 strobe_current_max;
>>> + u32 max_strobe_timeout;
>>> +};
>>> +
>>> +static const struct lm3601x_max_timeouts strobe_timeouts[] = {
>>> + { 40, 0x00 },
>>> + { 80, 0x01 },
>>> + { 120, 0x02 },
>>> + { 160, 0x03 },
>>> + { 200, 0x04 },
>>> + { 240, 0x05 },
>>> + { 280, 0x06 },
>>> + { 320, 0x07 },
>>> + { 360, 0x08 },
>>> + { 400, 0x09 },
>>> + { 600, 0x0a },
>>> + { 800, 0x0b },
>>> + { 1000, 0x0c },
>>> + { 1200, 0x0d },
>>> + { 1400, 0x0e },
>>> + { 1600, 0x0f },
>>> +};
>>> +
>>> +static const struct reg_default lm3601x_regmap_defs[] = {
>>> + { LM3601X_ENABLE_REG, 0x20 },
>>> + { LM3601X_CFG_REG, 0x15 },
>>> + { LM3601X_LED_FLASH_REG, 0x00 },
>>> + { LM3601X_LED_TORCH_REG, 0x00 },
>>> +};
>>> +
>>> +static bool lm3601x_volatile_reg(struct device *dev, unsigned int reg)
>>> +{
>>> + switch (reg) {
>>> + case LM3601X_FLAGS_REG:
>>> + return true;
>>> + default:
>>> + return false;
>>> + }
>>> +}
>>> +
>>> +static const struct regmap_config lm3601x_regmap = {
>>> + .reg_bits = 8,
>>> + .val_bits = 8,
>>> +
>>> + .max_register = LM3601X_DEV_ID_REG,
>>> + .reg_defaults = lm3601x_regmap_defs,
>>> + .num_reg_defaults = ARRAY_SIZE(lm3601x_regmap_defs),
>>> + .cache_type = REGCACHE_RBTREE,
>>> + .volatile_reg = lm3601x_volatile_reg,
>>> +};
>>> +
>>> +static struct lm3601x_led *fled_cdev_to_led(
>>> + struct led_classdev_flash *fled_cdev)
>>> +{
>>> + return container_of(fled_cdev, struct lm3601x_led, fled_cdev);
>>> +}
>>> +
>>> +static int lm3601x_read_faults(struct lm3601x_led *led)
>>> +{
>>> + int flags_val;
>>> + int ret;
>>> +
>>> + ret = regmap_read(led->regmap, LM3601X_FLAGS_REG, &flags_val);
>>> + if (ret < 0)
>>> + return -EIO;
>>> +
>>> + led->last_flag = flags_val;
>>> +
>>> + return led->last_flag;
>>> +}
>>> +
>>> +static int lm3601x_torch_brightness_set(struct led_classdev *cdev,
>>> + enum led_brightness brightness)
>>> +{
>>> + struct lm3601x_led *led =
>>> + container_of(cdev, struct lm3601x_led, cdev_torch);
>>> + int ret;
>>> + u8 brightness_val;
>>> +
>>> + mutex_lock(&led->lock);
>>> +
>>> + ret = lm3601x_read_faults(led);
>>> + if (ret < 0)
>>> + goto out;
>>> +
>>> + if (brightness == LED_OFF) {
>>> + ret = regmap_update_bits(led->regmap, LM3601X_ENABLE_REG,
>>> + LM3601X_MODE_TORCH, LED_OFF);
>>> + goto out;
>>> + }
>>> +
>>> + if (brightness == LED_ON)
>>> + brightness_val = LED_ON;
>>> + else
>>> + brightness_val = (brightness/2);
>>> +
>>> + ret = regmap_write(led->regmap, LM3601X_LED_TORCH_REG, brightness_val);
>>> + if (ret < 0)
>>> + goto out;
>>> +
>>> + ret = regmap_update_bits(led->regmap, LM3601X_ENABLE_REG,
>>> + LM3601X_MODE_TORCH,
>>> + LM3601X_MODE_TORCH);
>>> +
>>> +out:
>>> + mutex_unlock(&led->lock);
>>> + return ret;
>>> +}
>>> +
>>> +static int lm3601x_strobe_set(struct led_classdev_flash *fled_cdev,
>>> + bool state)
>>> +{
>>> + struct lm3601x_led *led = fled_cdev_to_led(fled_cdev);
>>> + int ret;
>>> + int current_timeout;
>>> + int reg_count;
>>> + int i;
>>> + int timeout_reg_val = 0;
>>> +
>>> + mutex_lock(&led->lock);
>>> +
>>> + ret = regmap_read(led->regmap, LM3601X_CFG_REG, ¤t_timeout);
>>> + if (ret < 0)
>>> + goto out;
>>> +
>>> + reg_count = ARRAY_SIZE(strobe_timeouts);
>>> + for (i = 0; i < reg_count; i++) {
>>> + if (led->strobe_timeout > strobe_timeouts[i].timeout)
>>> + continue;
>>> +
>>> + if (led->strobe_timeout <= strobe_timeouts[i].timeout) {
>>> + timeout_reg_val = (strobe_timeouts[i].reg_val << 1);
>>> + break;
>>> + }
>>> +
>>> + ret = -EINVAL;
>>> + goto out;
>>> + }
>>> +
>>> + if (led->strobe_timeout != current_timeout)
>>> + ret = regmap_update_bits(led->regmap, LM3601X_CFG_REG,
>>> + LM3601X_TIMEOUT_MASK, timeout_reg_val);
>>> +
>>> + if (state)
>>> + ret = regmap_update_bits(led->regmap, LM3601X_ENABLE_REG,
>>> + LM3601X_MODE_STROBE,
>>> + LM3601X_MODE_STROBE);
>>> + else
>>> + ret = regmap_update_bits(led->regmap, LM3601X_ENABLE_REG,
>>> + LM3601X_MODE_STROBE, LED_OFF);
>>> +
>>> + ret = lm3601x_read_faults(led);
>>> +out:
>>> + mutex_unlock(&led->lock);
>>> + return ret;
>>> +}
>>> +
>>> +static int lm3601x_strobe_brightness_set(struct led_classdev *cdev,
>>> + enum led_brightness brightness)
>>> +{
>>> + struct led_classdev_flash *fled_cdev = lcdev_to_flcdev(cdev);
>>> + struct lm3601x_led *led = fled_cdev_to_led(fled_cdev);
>>> + int ret;
>>> + u8 brightness_val;
>>> +
>>> + mutex_lock(&led->lock);
>>> + ret = lm3601x_read_faults(led);
>>> + if (ret < 0)
>>> + goto out;
>>> +
>>> + if (brightness == LED_OFF) {
>>> + ret = regmap_update_bits(led->regmap, LM3601X_ENABLE_REG,
>>> + LM3601X_MODE_STROBE, LED_OFF);
>>> + goto out;
>>> + }
>>> +
>>> + if (brightness == LED_ON)
>>> + brightness_val = LED_ON;
>>> + else
>>> + brightness_val = (brightness/2);
>>> +
>>> + ret = regmap_write(led->regmap, LM3601X_LED_FLASH_REG, brightness_val);
>>> +
>>> +out:
>>> + mutex_unlock(&led->lock);
>>> + return ret;
>>> +}
>>> +
>>> +static int lm3601x_strobe_timeout_set(struct led_classdev_flash *fled_cdev,
>>> + u32 timeout)
>>> +{
>>> + struct lm3601x_led *led = fled_cdev_to_led(fled_cdev);
>>> + int ret = 0;
>>> +
>>> + mutex_lock(&led->lock);
>>> +
>>> + if (timeout > led->max_strobe_timeout)
>>> + ret = -EINVAL;
>>
>> LED flash core takes care of clamping timeout setting
>> according to the defined constraints.
>
> OK
>
>>
>>> + else
>>> + led->strobe_timeout = timeout;
>>> +
>>> + mutex_unlock(&led->lock);
>>> +
>>> + return ret;
>>> +}
>>> +
>>> +static int lm3601x_strobe_get(struct led_classdev_flash *fled_cdev,
>>> + bool *state)
>>> +{
>>> + struct lm3601x_led *led = fled_cdev_to_led(fled_cdev);
>>> + int ret;
>>> + int strobe_state;
>>> +
>>> + mutex_lock(&led->lock);
>>> +
>>> + ret = regmap_read(led->regmap, LM3601X_ENABLE_REG, &strobe_state);
>>> + if (ret < 0)
>>> + goto out;
>>> +
>>> + *state = strobe_state & LM3601X_MODE_STROBE;
>>> +
>>> +out:
>>> + mutex_unlock(&led->lock);
>>> + return ret;
>>> +}
>>> +
>>> +static int lm3601x_ir_brightness_set(struct led_classdev *cdev,
>>> + enum led_brightness brightness)
>>> +{
>>> + struct lm3601x_led *led =
>>> + container_of(cdev, struct lm3601x_led, cdev_ir);
>>> + int ret;
>>> + u8 brightness_val;
>>> +
>>> + mutex_lock(&led->lock);
>>> + ret = lm3601x_read_faults(led);
>>> + if (ret < 0)
>>> + goto out;
>>> +
>>> + if (brightness == LED_OFF) {
>>> + ret = regmap_update_bits(led->regmap, LM3601X_ENABLE_REG,
>>> + LM3601X_LED_IR,
>>> + LED_OFF);
>>> + goto out;
>>> + }
>>> +
>>> + if (brightness == LED_ON)
>>> + brightness_val = LED_ON;
>>> + else
>>> + brightness_val = (brightness/2);
>>> +
>>> + ret = regmap_write(led->regmap, LM3601X_LED_FLASH_REG, brightness_val);
>>> + if (ret < 0)
>>> + goto out;
>>> +
>>> + ret = regmap_update_bits(led->regmap, LM3601X_ENABLE_REG,
>>> + LM3601X_MODE_IR_DRV,
>>> + LM3601X_MODE_IR_DRV);
>>> +
>>> +out:
>>> + mutex_unlock(&led->lock);
>>> + return ret;
>>> +}
>>> +
>>> +static int lm3601x_strobe_fault_get(struct led_classdev_flash *fled_cdev,
>>> + u32 *fault)
>>
>> Does the device report only strobe related faults?
>
> No. It has under/over voltage and thermal.
I'd remove "strobe" from the function name then.
>>> +{
>>> + struct lm3601x_led *led = fled_cdev_to_led(fled_cdev);
>>> +
>>> + lm3601x_read_faults(led);
>>> +
>>> + *fault = led->last_flag;
>>
>> You should translate device specific faults to LED_FAULT* flags.
>> Please compare e.g. drivers/leds/leds-max77693.c or
>> driver/leds/leds-as3645a.c.
>
> Hmm. This code is in the max77693.c. I think the translation should be in the
> read_faults function in this file and not here.
Correct.
> I will add that translation above
>
>>
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static const struct led_flash_ops strobe_ops = {
>>> + .strobe_set = lm3601x_strobe_set,
>>> + .strobe_get = lm3601x_strobe_get,
>>> + .timeout_set = lm3601x_strobe_timeout_set,
>>> + .fault_get = lm3601x_strobe_fault_get,
>>> +};
>>> +
>>> +static int lm3601x_register_leds(struct lm3601x_led *led)
>>> +{
>>> + struct led_classdev_flash *fled_cdev;
>>> + struct led_classdev *led_cdev;
>>> + int err = -ENODEV;
>>> +
>>> + if (led->torch_node) {
>>> + led->cdev_torch.name = led->torch;
>>> + led->cdev_torch.max_brightness = LED_FULL;
>>> + led->cdev_torch.brightness_set_blocking = lm3601x_torch_brightness_set;
>>> + err = devm_led_classdev_register(&led->client->dev,
>>> + &led->cdev_torch);
>>> + if (err < 0)
>>> + return err;
>>> + }
>>> +
>>> + if (led->strobe_node) {
>>> + fled_cdev = &led->fled_cdev;
>>> + fled_cdev->ops = &strobe_ops;
>>> +
>>> + led_cdev = &fled_cdev->led_cdev;
>>> + led_cdev->name = led->strobe;
>>> + led_cdev->max_brightness = LED_FULL;
>>> + led_cdev->brightness_set_blocking = lm3601x_strobe_brightness_set;
>>> + led_cdev->flags |= LED_DEV_CAP_FLASH;
>>> +
>>> + err = led_classdev_flash_register(&led->client->dev,
>>> + fled_cdev);
>>> + if (err < 0)
>>> + return err;
>>> + }
>>> +
>>> + if (led->ir_node) {
>>> + led->cdev_ir.name = led->ir;
>>> + led->cdev_ir.max_brightness = LED_FULL;
>>> + led->cdev_ir.brightness_set_blocking =
>>> + lm3601x_ir_brightness_set;
>>> +
>>> + err = devm_led_classdev_register(&led->client->dev,
>>> + &led->cdev_ir);
>>> + }
>>> +
>>> + return err;
>>> +}
>>> +
>>> +static void lm3601x_init_flash_timeout(struct lm3601x_led *led)
>>> +{
>>> + struct led_flash_setting *setting;
>>> +
>>> + setting = &led->fled_cdev.timeout;
>>> + setting->min = strobe_timeouts[0].timeout;
>>> + setting->max = led->max_strobe_timeout;
>>> + setting->step = 40;
>>> + setting->val = led->max_strobe_timeout;
>>> +}
>>> +
>>> +static int lm3601x_parse_node(struct lm3601x_led *led,
>>> + struct device_node *node)
>>> +{
>>> + struct device_node *child_node;
>>> + const char *name;
>>> + int ret = -ENODEV;
>>> +
>>> + for_each_available_child_of_node(node, child_node) {
>>> + u32 id = 0;
>>> +
>>> + of_property_read_u32(child_node, "reg", &id);
>>> +
>>> + switch (id) {
>>> + case LM3601X_LED_TORCH:
>>> + led->torch_node = of_node_get(child_node);
>>> + break;
>>> + case LM3601X_LED_STROBE:
>>> + led->strobe_node = of_node_get(child_node);
>>> + break;
>>> + case LM3601X_LED_IR:
>>> + led->ir_node = of_node_get(child_node);
>>> + break;
>>> + default:
>>> + dev_warn(&led->client->dev,
>>> + "unknown LED %u encountered, ignoring\n", id);
>>> + break;
>>> + }
>>> + }
>>> +
>>> + if (led->torch_node) {
>>> + ret = of_property_read_string(led->torch_node, "label", &name);
>>> + if (!ret)
>>> + snprintf(led->torch, sizeof(led->torch),
>>> + "%s:%s", led->torch_node->name, name);
>>> + else
>>> + snprintf(led->torch, sizeof(led->torch),
>>> + "%s:torch", led->torch_node->name);
>>> + ret = of_property_read_u32(led->torch_node, "led-max-microamp",
>>> + &led->torch_current_max);
>>> + if (ret < 0) {
>>> + led->torch_current_max = LM3601X_MIN_TORCH_I_UA;
>>> + dev_warn(&led->client->dev,
>>> + "led-max-microamp DT property missing\n");
>>> + }
>>> +
>>> + of_node_put(led->torch_node);
>>> + }
>>> +
>>> + if (led->strobe_node) {
>>> + ret = of_property_read_string(led->strobe_node, "label", &name);
>>> + if (!ret)
>>> + snprintf(led->strobe, sizeof(led->strobe),
>>> + "%s:%s", led->strobe_node->name, name);
>>> + else
>>> + snprintf(led->strobe, sizeof(led->strobe),
>>> + "%s::strobe", led->strobe_node->name);
>>> +
>>> + ret = of_property_read_u32(led->strobe_node,
>>> + "flash-max-microamp",
>>> + &led->strobe_current_max);
>>> + if (ret < 0) {
>>> + led->strobe_current_max = LM3601X_MIN_STROBE_I_MA;
>>> + dev_warn(&led->client->dev,
>>> + "flash-max-microamp DT property missing\n");
>>> + }
>>> +
>>> + ret = of_property_read_u32(led->strobe_node,
>>> + "flash-max-timeout-us",
>>> + &led->max_strobe_timeout);
>>> + if (ret < 0) {
>>> + led->max_strobe_timeout = strobe_timeouts[0].reg_val;
>>> + dev_warn(&led->client->dev,
>>> + "flash-max-timeout-us DT property missing\n");
>>> + }
>>
>> Common LED bindings state that flash-max-microamp and
>> flash-max-timeout-us properties are mandatory.
>
> OK.
>
>>
>>> +
>>> + lm3601x_init_flash_timeout(led);
>>> +
>>> + of_node_put(led->strobe_node);
>>> + }
>>> +
>>> + if (led->ir_node) {
>>> + ret = of_property_read_string(led->ir_node, "label", &name);
>>> + if (!ret)
>>> + snprintf(led->ir, sizeof(led->ir),
>>> + "%s:%s", led->ir_node->name, name);
>>> + else
>>> + snprintf(led->ir, sizeof(led->ir),
>>> + "%s::infrared", led->ir_node->name);
>>> +
>>> + of_node_put(led->ir_node);
>>> + }
>>> +
>>> + return ret;
>>> +}
>>> +
>>> +static int lm3601x_probe(struct i2c_client *client,
>>> + const struct i2c_device_id *id)
>>> +{
>>> + struct lm3601x_led *led;
>>> + int err;
>>> +
>>> + led = devm_kzalloc(&client->dev,
>>> + sizeof(struct lm3601x_led), GFP_KERNEL);
>>> + if (!led)
>>> + return -ENOMEM;
>>> +
>>> + err = lm3601x_parse_node(led, client->dev.of_node);
>>> + if (err < 0)
>>> + return -ENODEV;
>>> +
>>> + led->client = client;
>>> + led->regmap = devm_regmap_init_i2c(client, &lm3601x_regmap);
>>> + if (IS_ERR(led->regmap)) {
>>> + err = PTR_ERR(led->regmap);
>>> + dev_err(&client->dev,
>>> + "Failed to allocate register map: %d\n", err);
>>> + return err;
>>> + }
>>> +
>>> + mutex_init(&led->lock);
>>> + i2c_set_clientdata(client, led);
>>> + err = lm3601x_register_leds(led);
>>> +
>>> + return err;
>>> +}
>>> +
>>> +static int lm3601x_remove(struct i2c_client *client)
>>> +{
>>> + struct lm3601x_led *led = i2c_get_clientdata(client);
>>> +
>>> + regmap_update_bits(led->regmap, LM3601X_ENABLE_REG,
>>> + LM3601X_ENABLE_MASK,
>>> + LM3601X_MODE_STANDBY);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static const struct i2c_device_id lm3601x_id[] = {
>>> + { "LM36010", CHIP_LM36010 },
>>> + { "LM36011", CHIP_LM36011 },
>>> + { },
>>> +};
>>> +MODULE_DEVICE_TABLE(i2c, lm3601x_id);
>>> +
>>> +static const struct of_device_id of_lm3601x_leds_match[] = {
>>> + { .compatible = "ti,lm36010", },
>>> + { .compatible = "ti,lm36011", },
>>> + {},
>>> +};
>>> +MODULE_DEVICE_TABLE(of, of_lm3601x_leds_match);
>>> +
>>> +static struct i2c_driver lm3601x_i2c_driver = {
>>> + .driver = {
>>> + .name = "lm3601x",
>>> + .of_match_table = of_lm3601x_leds_match,
>>> + },
>>> + .probe = lm3601x_probe,
>>> + .remove = lm3601x_remove,
>>> + .id_table = lm3601x_id,
>>> +};
>>> +module_i2c_driver(lm3601x_i2c_driver);
>>> +
>>> +MODULE_DESCRIPTION("Texas Instruments Flash Lighting driver for LM3601X");
>>> +MODULE_AUTHOR("Dan Murphy <dmurphy@ti.com>");
>>> +MODULE_LICENSE("GPL v2");
>>>
>>
>
>
[0] https://lkml.org/lkml/2017/11/2/715
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* [PATCH 2/2] arm64: dts: renesas: r8a77980: disable EtherAVB
From: Sergei Shtylyov @ 2018-05-11 20:23 UTC (permalink / raw)
To: Simon Horman, Rob Herring, Catalin Marinas, Will Deacon,
linux-renesas-soc, devicetree
Cc: Mark Rutland, Magnus Damm, linux-arm-kernel
In-Reply-To: <5844eef7-0f5e-6366-4d3d-a3a658e7f988@cogentembedded.com>
When adding the R8A77980 EtherAVB device I failed to notice that it does
not have the usual "status" property disabling the described devices in
anticipation that the board device trees enable the devices according to
their needs. This causes the EtherAVB driver to successfully probe despite
e.g. the needed pins not having been configured -- luckily, "eth<n>" device
can't be opened anyway...
Fixes: bf6f90832f81 ("arm64: dts: renesas: r8a77980: add EtherAVB support")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 1 +
1 file changed, 1 insertion(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -244,6 +244,7 @@
phy-mode = "rgmii";
#address-cells = <1>;
#size-cells = <0>;
+ status = "disabled";
};
scif0: serial@e6e60000 {
^ permalink raw reply
* [PATCH 1/2] arm64: dts: renesas: r8a77970: disable EtherAVB
From: Sergei Shtylyov @ 2018-05-11 20:21 UTC (permalink / raw)
To: Simon Horman, Rob Herring, Catalin Marinas, Will Deacon,
linux-renesas-soc, devicetree
Cc: Mark Rutland, Magnus Damm, linux-arm-kernel
In-Reply-To: <5844eef7-0f5e-6366-4d3d-a3a658e7f988@cogentembedded.com>
When adding the R8A77970 EtherAVB device I failed to notice that it does
not have the usual "status" property disabling the described devices in
anticipation that the board device trees enable the devices according to
their needs. This causes the EtherAVB driver to successfully probe despite
e.g. the needed pins not having been configured -- luckily, "eth<n>" device
can't be opened anyway...
Fixes: bea2ab136eaa ("arm64: dts: renesas: r8a77970: add EtherAVB support")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm64/boot/dts/renesas/r8a77970.dtsi | 1 +
1 file changed, 1 insertion(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77970.dtsi
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77970.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77970.dtsi
@@ -473,6 +473,7 @@
iommus = <&ipmmu_rt 3>;
#address-cells = <1>;
#size-cells = <0>;
+ status = "disabled";
};
scif0: serial@e6e60000 {
^ permalink raw reply
* [PATCH 0/2] Disable EtherAVB by default on R8A779{7|8}0 SoCs
From: Sergei Shtylyov @ 2018-05-11 20:18 UTC (permalink / raw)
To: Simon Horman, Rob Herring, Catalin Marinas, Will Deacon,
linux-renesas-soc, devicetree
Cc: Mark Rutland, Magnus Damm, linux-arm-kernel
Hello!
Here's the set of 2 patches against Simon Horman's 'renesas.git' repo's
'renesas-devel-20180511-v4.17-rc4' tag. I'm fixing the issue in the EtherAVB
device nodes in the R8A779{7|8}0 device trees that missed the "status" prop,
usually disabling the SoC devices in anticipation that the board device trees
enable the devices according to their needs. There should be no issues with
the current R8A779{7|8}0 board device trees, as all of them use EtherAVB
anyway, so I'm sending the patches generated against the 'devel' branch...
[1/2] arm64: dts: renesas: r8a77970: disable EtherAVB
[2/2] arm64: dts: renesas: r8a77980: disable EtherAVB
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 00/12] introduce support for early platform drivers
From: Rob Herring @ 2018-05-11 20:13 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Mark Rutland, Rich Felker, Michael Turquette, Sekhar Nori,
Frank Rowand, open list:GENERIC INCLUDE/ASM HEADER FILES,
Yoshinori Sato, Kevin Hilman, Rafael J . Wysocki, Magnus Damm,
Andy Shevchenko, Geert Uytterhoeven, Jiri Slaby, devicetree,
David Lechner, Arnd Bergmann, Marc Zyngier, Johan Hovold,
Thomas Gleixner,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Daniel Lezcano
In-Reply-To: <20180511162028.20616-1-brgl@bgdev.pl>
On Fri, May 11, 2018 at 11:20 AM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> This series is a follow-up to the RFC[1] posted a couple days ago.
>
> NOTE: this series applies on top of my recent patches[2] that move the previous
> implementation of early platform devices to arch/sh.
>
> Problem:
>
> Certain class of devices, such as timers, certain clock drivers and irq chip
> drivers need to be probed early in the boot sequence. The currently preferred
> approach is using one of the OF_DECLARE() macros. This however does not create
> a platform device which has many drawbacks - such as not being able to use
> devres routines, dev_ log functions or no way of deferring the init OF function
> if some other resources are missing.
I skimmed though this and it doesn't look horrible (how's that for
positive feedback? ;) ). But before going into the details, I think
first there needs to be agreement this is the right direction.
The question does remain though as to whether this class of devices
should be platform drivers. They can't be modules. They can't be
hotplugged. Can they be runtime-pm enabled? So the advantage is ...
I assume that the clock maintainers had some reason to move clocks to
be platform drivers. It's just not clear to me what that was.
> For drivers that use both platform drivers and OF_DECLARE the situation is even
> more complicated as the code needs to take into account that there can possibly
> be no struct device present. For a specific use case that we're having problems
> with, please refer to the recent DaVinci common-clock conversion patches and
> the nasty workaround that this problem implies[3].
So devm_kzalloc will work with this solution? Why did we need
devm_kzalloc in the first place? The clocks can never be removed and
cleaning up on error paths is kind of pointless. The system would be
hosed, right?
> We also used to have an early platform drivers implementation but they were not
> integrated with the linux device model at all - they merely used the same data
> structures. The users could not use devres, defer probe and the early devices
> never became actual platform devices later on.
>
> Proposed solution:
>
> This series aims at solving this problem by (re-)introducing the concept of
> early platform drivers and devices - this time however in a way that seamlessly
> integrates with the existing platform drivers and also offers device-tree
> support.
>
> The idea is to provide a way for users to probe devices early, while already
> being able to use devres, devices resources and properties and also deferred
> probing.
>
> New structures are introduced: the early platform driver contains the
> early_probe callback which has the same signature as regular platform_device
> probe. This callback is called early on. The user can have both the early and
> regular probe speficied or only one of them and they both receive the same
> platform device object as argument. Any device data allocated early will be
> carried over to the normal probe.
>
> The architecture code is responsible for calling early_platform_start() in
> which the early drivers will be registered and devices populated from DT.
Can we really do this in one spot for different devices (clk, timers,
irq). The sequence is all very carefully crafted. Platform specific
hooks is another thing to consider.
> Once the device and kobject mechanisms are ready, all early drivers and devices
> will be converted into real platform drivers and devices. Also: if any of the
> early platform registration functions will be called once early initialization
> is done, these functions will work like regular platform_device/driver ones.
This could leave devices in a weird state. They've successfully probed
early, but then are on the deferred list for normal probe for example.
Rob
^ permalink raw reply
* Re: [PATCH] dt-bindings: net: ravb: Add support for r8a77990 SoC
From: David Miller @ 2018-05-11 19:59 UTC (permalink / raw)
To: yoshihiro.shimoda.uh
Cc: netdev, linux-renesas-soc, robh+dt, mark.rutland, sergei.shtylyov,
devicetree
In-Reply-To: <1526008736-26496-1-git-send-email-yoshihiro.shimoda.uh@renesas.com>
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date: Fri, 11 May 2018 12:18:56 +0900
> Add documentation for r8a77990 compatible string to renesas ravb device
> tree bindings documentation.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
I'm assuming this isn't targetted at one of my trees. Just FYI.
^ permalink raw reply
* Re: [PATCH v5 05/14] usb: typec: add API to get typec basic port power and data config
From: Mats Karrman @ 2018-05-11 19:55 UTC (permalink / raw)
To: Li Jun, robh+dt, gregkh, heikki.krogerus, linux
Cc: a.hajda, cw00.choi, shufan_lee, peter.chen, gsomlo, devicetree,
linux-usb, linux-imx
In-Reply-To: <1525307094-27402-6-git-send-email-jun.li@nxp.com>
Hi Li Jun,
On 2018-05-03 02:24, Li Jun wrote:
> This patch adds 3 APIs to get the typec port power and data type,
> and preferred power role by its name string.
>
> Signed-off-by: Li Jun <jun.li@nxp.com>
> ---
> drivers/usb/typec/class.c | 52 +++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/usb/typec.h | 3 +++
> 2 files changed, 55 insertions(+)
>
> diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
> index 53df10d..5981e18 100644
> --- a/drivers/usb/typec/class.c
> +++ b/drivers/usb/typec/class.c
> @@ -9,6 +9,7 @@
> #include <linux/device.h>
> #include <linux/module.h>
> #include <linux/mutex.h>
> +#include <linux/property.h>
> #include <linux/slab.h>
> #include <linux/usb/typec.h>
> #include <linux/usb/typec_mux.h>
> @@ -802,6 +803,12 @@ static const char * const typec_port_types[] = {
> [TYPEC_PORT_DRP] = "dual",
> };
>
> +static const char * const typec_data_types[] = {
> + [TYPEC_PORT_DFP] = "host",
> + [TYPEC_PORT_UFP] = "device",
> + [TYPEC_PORT_DRD] = "dual",
> +};
> +
> static const char * const typec_port_types_drp[] = {
> [TYPEC_PORT_SRC] = "dual [source] sink",
> [TYPEC_PORT_SNK] = "dual source [sink]",
> @@ -1252,6 +1259,51 @@ void typec_set_pwr_opmode(struct typec_port *port,
> }
> EXPORT_SYMBOL_GPL(typec_set_pwr_opmode);
>
> +/**
> + * typec_find_power_type - Get the typec port power type
Why is this function called typec_find_power_type() and not typec_find_port_type()?
It's called port_type in sysfs, having different names just adds confusion.
(Otherwise I agree power_type is a better name but...)
> + * @name: port type string
> + *
> + * This routine is used to find the typec_port_type by its string name.
> + *
> + * Returns typec_port_type if success, otherwise negative error code.
> + */
> +int typec_find_power_type(const char *name)
> +{
> + return match_string(typec_port_types, ARRAY_SIZE(typec_port_types),
> + name);
> +}
> +EXPORT_SYMBOL_GPL(typec_find_power_type);
> +
> +/**
> + * typec_find_preferred_role - Find the typec drp port preferred power role
Why typec_find_preferred_role()? Could be used for any power_role so
why not typec_find_power_role()?
BR // Mats
> + * @name: power role string
> + *
> + * This routine is used to find the typec_role by its string name of
> + * preferred power role(Try.SRC or Try.SNK).
> + *
> + * Returns typec_role if success, otherwise negative error code.
> + */
> +int typec_find_preferred_role(const char *name)
> +{
> + return match_string(typec_roles, ARRAY_SIZE(typec_roles), name);
> +}
> +EXPORT_SYMBOL_GPL(typec_find_preferred_role);
> +
> +/**
> + * typec_find_data_type - Get the typec port data capability
> + * @name: data type string
> + *
> + * This routine is used to find the typec_port_data by its string name.
> + *
> + * Returns typec_port_data if success, otherwise negative error code.
> + */
> +int typec_find_data_type(const char *name)
> +{
> + return match_string(typec_data_types, ARRAY_SIZE(typec_data_types),
> + name);
> +}
> +EXPORT_SYMBOL_GPL(typec_find_data_type);
> +
> /* ------------------------------------------ */
> /* API for Multiplexer/DeMultiplexer Switches */
>
> diff --git a/include/linux/usb/typec.h b/include/linux/usb/typec.h
> index 672b39b..00c93e7 100644
> --- a/include/linux/usb/typec.h
> +++ b/include/linux/usb/typec.h
> @@ -267,4 +267,7 @@ int typec_set_orientation(struct typec_port *port,
> enum typec_orientation orientation);
> int typec_set_mode(struct typec_port *port, int mode);
>
> +int typec_find_power_type(const char *name);
> +int typec_find_preferred_role(const char *name);
> +int typec_find_data_type(const char *name);
> #endif /* __LINUX_USB_TYPEC_H */
>
^ permalink raw reply
* Re: [PATCH v5 03/14] staging: typec: tcpci: add compatible string for nxp ptn5110
From: Mats Karrman @ 2018-05-11 19:51 UTC (permalink / raw)
To: Li Jun, robh+dt, gregkh, heikki.krogerus, linux
Cc: a.hajda, cw00.choi, shufan_lee, peter.chen, gsomlo, devicetree,
linux-usb, linux-imx
In-Reply-To: <1525307094-27402-4-git-send-email-jun.li@nxp.com>
Hi Li Jun,
On 2018-05-03 02:24, Li Jun wrote:
> Add nxp ptn5110 typec controller compatible string: usb-tcpci,ptn5110,
> which is a standard tcpci chip with power delivery support.
>
> Signed-off-by: Li Jun <jun.li@nxp.com>
> ---
> drivers/staging/typec/tcpci.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
> index 076d97e..741a80a 100644
> --- a/drivers/staging/typec/tcpci.c
> +++ b/drivers/staging/typec/tcpci.c
> @@ -576,6 +576,7 @@ MODULE_DEVICE_TABLE(i2c, tcpci_id);
> #ifdef CONFIG_OF
> static const struct of_device_id tcpci_of_match[] = {
> { .compatible = "usb,tcpci", },
Either this line should go away, or a "generic TCPCI controller" line should be
added to the DT documentation.
BR // Mats
> + { .compatible = "nxp,ptn5110", },
> {},
> };
> MODULE_DEVICE_TABLE(of, tcpci_of_match);
>
^ 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