Re: [PATCH] backlight: qcom-wled: Use sink_addr for sync toggle

[kgunda]

On 2021-03-15 17:51, Daniel Thompson wrote:

On Sun, Mar 14, 2021 at 11:11:10AM +0100, Marijn Suijten wrote:

From: Obeida Shamoun 

WLED3_SINK_REG_SYNC is, as the name implies, a sink register offset.
Therefore, use the sink address as base instead of the ctrl address.

This fixes the sync toggle on wled4, which can be observed by the fact
that adjusting brightness now works.

It has no effect on wled3 because sink and ctrl base addresses are the
same.  This allows adjusting the brightness without having to disable
then reenable the module.

Signed-off-by: Obeida Shamoun 
Signed-off-by: Konrad Dybcio 
Signed-off-by: Marijn Suijten 


LGTM, although an acked-by from Kiran would be nice to have:
Reviewed-by: Daniel Thompson 


Daniel.



Acked-by: Kiran Gunda 


---
 drivers/video/backlight/qcom-wled.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/backlight/qcom-wled.c 
b/drivers/video/backlight/qcom-wled.c

index 091f07e7c145..fc8b443d10fd 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -336,13 +336,13 @@ static int wled3_sync_toggle(struct wled *wled)
unsigned int mask = GENMASK(wled->max_string_count - 1, 0);

rc = regmap_update_bits(wled->regmap,
-   wled->ctrl_addr + WLED3_SINK_REG_SYNC,
+   wled->sink_addr + WLED3_SINK_REG_SYNC,
mask, mask);
if (rc < 0)
return rc;

rc = regmap_update_bits(wled->regmap,
-   wled->ctrl_addr + WLED3_SINK_REG_SYNC,
+   wled->sink_addr + WLED3_SINK_REG_SYNC,
mask, WLED3_SINK_REG_SYNC_CLEAR);

return rc;
--
2.30.2

Re: [PATCH V3 2/2] backlight: qcom-wled: Correct the sync_toggle sequence

[kgunda]

On 2021-03-01 15:32, Daniel Thompson wrote:

On Mon, Mar 01, 2021 at 02:58:36PM +0530, Kiran Gunda wrote:

As per the current implementation, after FSC (Full Scale Current)
and brightness update the sync bits are transitioned from 
set-then-clear.


This does not makes sense since there are too many verbs. Set and clear
are both verbs so in this context: "the code will set the bit and then
the code will clear the bit".

Either:

s/transitioned from set-then-clear/set-then-cleared/.

Or:

s/transitioned from set-then-clear/using a set-then-clear approach/.


But, the FSC and brightness sync takes place during a clear-then-set
transition of the sync bits.


Likewise this no longer makes sense and had also become misleading.
Two changes of state, clear and then set, do not usually result in a
single transition.

Either:

s/clear-then-set/0 to 1/

Alternatively, if you want to stick exclusively to the set/clear
terminology then replace the whole quoted section with:

  But, the FSC and brightness sync takes place when the sync bits are
  set (e.g. on a rising edge).



So the hardware team recommends a
clear-then-set approach in order to guarantee such a transition
regardless of the previous register state.

Signed-off-by: Kiran Gunda 


With one of each of the changes proposed above:
Reviewed-by: Daniel Thompson 


Daniel.


Apologies for the mistake. I have corrected and submitted the
V4 series with the "reviewed-by" tag.



---
 drivers/video/backlight/qcom-wled.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/video/backlight/qcom-wled.c 
b/drivers/video/backlight/qcom-wled.c

index aef52b9..19f83ac 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -337,13 +337,13 @@ static int wled3_sync_toggle(struct wled *wled)

rc = regmap_update_bits(wled->regmap,
wled->ctrl_addr + WLED3_SINK_REG_SYNC,
-   mask, mask);
+   mask, WLED3_SINK_REG_SYNC_CLEAR);
if (rc < 0)
return rc;

rc = regmap_update_bits(wled->regmap,
wled->ctrl_addr + WLED3_SINK_REG_SYNC,
-   mask, WLED3_SINK_REG_SYNC_CLEAR);
+   mask, mask);

return rc;
 }
@@ -353,17 +353,17 @@ static int wled5_mod_sync_toggle(struct wled 
*wled)

int rc;
u8 val;

-   val = (wled->cfg.mod_sel == MOD_A) ? WLED5_SINK_REG_SYNC_MOD_A_BIT :
-WLED5_SINK_REG_SYNC_MOD_B_BIT;
rc = regmap_update_bits(wled->regmap,
wled->sink_addr + WLED5_SINK_REG_MOD_SYNC_BIT,
-   WLED5_SINK_REG_SYNC_MASK, val);
+   WLED5_SINK_REG_SYNC_MASK, 0);
if (rc < 0)
return rc;

+   val = (wled->cfg.mod_sel == MOD_A) ? WLED5_SINK_REG_SYNC_MOD_A_BIT :
+WLED5_SINK_REG_SYNC_MOD_B_BIT;
return regmap_update_bits(wled->regmap,
  wled->sink_addr + WLED5_SINK_REG_MOD_SYNC_BIT,
- WLED5_SINK_REG_SYNC_MASK, 0);
+ WLED5_SINK_REG_SYNC_MASK, val);
 }

 static int wled_ovp_fault_status(struct wled *wled, bool *fault_set)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,

 a Linux Foundation Collaborative Project

Re: [PATCH V2 2/2] backlight: qcom-wled: Correct the sync_toggle sequence

[kgunda]

On 2021-02-26 22:56, Daniel Thompson wrote:

On Fri, Feb 26, 2021 at 05:42:24PM +0530, Kiran Gunda wrote:

As per the current implementation, after FSC (Full Scale Current)
and brightness update the sync bits are transitioned from 1 to 0.


This still seems to incorrectly describe the current behaviour.

Surely in most cases (i.e. every time except the first) the value of 
the

sync bit is 0 when the function is called and we get both a 0 to 1
and then a 1 to 0 transition.

That is why I recommended set-then-clear terminology to describe the
current behaviour. It is concise and correct.


Daniel.



Okay. Actually I have mentioned the "clear-and-set" in explaining the 
fix.

Let me modify the same terminology in explaining the problem case also.


But, the FSC and brightness sync takes place during a 0 to 1
transition of the sync bits. So the hardware team recommends a
clear-then-set approach in order to guarantee such a transition
regardless of the previous register state.

Signed-off-by: Kiran Gunda 
---
 drivers/video/backlight/qcom-wled.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/video/backlight/qcom-wled.c 
b/drivers/video/backlight/qcom-wled.c

index aef52b9..19f83ac 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -337,13 +337,13 @@ static int wled3_sync_toggle(struct wled *wled)

rc = regmap_update_bits(wled->regmap,
wled->ctrl_addr + WLED3_SINK_REG_SYNC,
-   mask, mask);
+   mask, WLED3_SINK_REG_SYNC_CLEAR);
if (rc < 0)
return rc;

rc = regmap_update_bits(wled->regmap,
wled->ctrl_addr + WLED3_SINK_REG_SYNC,
-   mask, WLED3_SINK_REG_SYNC_CLEAR);
+   mask, mask);

return rc;
 }
@@ -353,17 +353,17 @@ static int wled5_mod_sync_toggle(struct wled 
*wled)

int rc;
u8 val;

-   val = (wled->cfg.mod_sel == MOD_A) ? WLED5_SINK_REG_SYNC_MOD_A_BIT :
-WLED5_SINK_REG_SYNC_MOD_B_BIT;
rc = regmap_update_bits(wled->regmap,
wled->sink_addr + WLED5_SINK_REG_MOD_SYNC_BIT,
-   WLED5_SINK_REG_SYNC_MASK, val);
+   WLED5_SINK_REG_SYNC_MASK, 0);
if (rc < 0)
return rc;

+   val = (wled->cfg.mod_sel == MOD_A) ? WLED5_SINK_REG_SYNC_MOD_A_BIT :
+WLED5_SINK_REG_SYNC_MOD_B_BIT;
return regmap_update_bits(wled->regmap,
  wled->sink_addr + WLED5_SINK_REG_MOD_SYNC_BIT,
- WLED5_SINK_REG_SYNC_MASK, 0);
+ WLED5_SINK_REG_SYNC_MASK, val);
 }

 static int wled_ovp_fault_status(struct wled *wled, bool *fault_set)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,

 a Linux Foundation Collaborative Project

Re: [PATCH V1 2/2] backlight: qcom-wled: Correct the sync_toggle sequence

[kgunda]

On 2021-02-24 16:56, Daniel Thompson wrote:

On Wed, Feb 24, 2021 at 09:20:48AM +0530, Kiran Gunda wrote:

Currently the FSC SYNC_BIT and MOD_SYNC_BIT are toggled
from 1 to 0 to update the FSC and brightenss settings.
Change this sequence form 0 to 1 as per the hardware team
recommendation to update the FSC and brightness correctly.


Again... this patch description feels somewhat rushed. A patch
description is there to support code reviewer and to go on the version
history to assist with future maintainance. They matter!

Anyhow I don't recognise the "from 1 to 0" in the code since both 
before

an after the change it goes "from 0 to 1" and "from 1 to 0" but in a
different order. Doesn't the code actually currently implement "set 
then

clear"? If so then, likewise the new code is adopting "clear then set".


I would have used "set" and "clear" instead of "0" and "1".
Yes. The current code implementation is "set" all SYN bits and then 
"clear"
all SYNC bits. The new code is modified to change the sequence from 
"clear"

first and then "set" to ensure both FSC and brightness are updated.


As with patch 1, the sync bits modified by wled3_sync_toggle singular
or plural?

It is plural. We have to "clear" and "set" all sync bits.


Finally a description that is more sympathetic to the reviewer would be
welcome.  For example the following (if my guess is right and it is
true) makes things much easier for the reviewer:
Sure. I will update the documentation and patch description clearly.
  "The sync takes place during a 0 to 1 transition of the sync
  bits so the hardware team recommends a clear-then-set approach in
  order to guarantee such a transition regardless of the previous
  register state".


Daniel.




Signed-off-by: Kiran Gunda 
---
 drivers/video/backlight/qcom-wled.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/video/backlight/qcom-wled.c 
b/drivers/video/backlight/qcom-wled.c

index aef52b9..19f83ac 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -337,13 +337,13 @@ static int wled3_sync_toggle(struct wled *wled)

rc = regmap_update_bits(wled->regmap,
wled->ctrl_addr + WLED3_SINK_REG_SYNC,
-   mask, mask);
+   mask, WLED3_SINK_REG_SYNC_CLEAR);
if (rc < 0)
return rc;

rc = regmap_update_bits(wled->regmap,
wled->ctrl_addr + WLED3_SINK_REG_SYNC,
-   mask, WLED3_SINK_REG_SYNC_CLEAR);
+   mask, mask);

return rc;
 }
@@ -353,17 +353,17 @@ static int wled5_mod_sync_toggle(struct wled 
*wled)

int rc;
u8 val;

-   val = (wled->cfg.mod_sel == MOD_A) ? WLED5_SINK_REG_SYNC_MOD_A_BIT :
-WLED5_SINK_REG_SYNC_MOD_B_BIT;
rc = regmap_update_bits(wled->regmap,
wled->sink_addr + WLED5_SINK_REG_MOD_SYNC_BIT,
-   WLED5_SINK_REG_SYNC_MASK, val);
+   WLED5_SINK_REG_SYNC_MASK, 0);
if (rc < 0)
return rc;

+   val = (wled->cfg.mod_sel == MOD_A) ? WLED5_SINK_REG_SYNC_MOD_A_BIT :
+WLED5_SINK_REG_SYNC_MOD_B_BIT;
return regmap_update_bits(wled->regmap,
  wled->sink_addr + WLED5_SINK_REG_MOD_SYNC_BIT,
- WLED5_SINK_REG_SYNC_MASK, 0);
+ WLED5_SINK_REG_SYNC_MASK, val);
 }

 static int wled_ovp_fault_status(struct wled *wled, bool *fault_set)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,

 a Linux Foundation Collaborative Project

Re: [PATCH V1 1/2] backlight: qcom-wled: Fix FSC update issue for WLED5

[kgunda]

On 2021-02-24 16:45, Daniel Thompson wrote:

On Wed, Feb 24, 2021 at 09:20:47AM +0530, Kiran Gunda wrote:

Currently, for WLED5, after FSC register update MOD_SYNC_BIT
is toggled instead of SYNC_BIT. MOD_SYNC_BIT has to be toggled
after the brightness update and SYNC_BIT has to be toggled after
FSC update for WLED5. Fix it.


Code looks fine but the description is a difficult to read (which makes
mining the history difficult).

Basically the descriptions here are very hard to read without the
context in PATCH 0/2. Since PATCH 0/2 won't enter the version history
that means these descriptions need to integrate some of the text from
what is currently PATCH 0/2.

I would expect this to be more like. It is basically joining together
text from PATCH 0 and PATCH 1 (I also switched to plural form for SYNC
bits... the code in the driver has mask generation based on the number
of strings, is that right?):

Sorry for the trouble. Yes, you are correct. The mask generation is
based on the number of strings defined in the device tree and only those
strings are enabled. However, there is no issue if the SYNC bits of all
the strings are cleared/set. The SYNC takes place only for enabled 
strings.



~~~
Currently, for WLED5, the FSC (Full scale current) setting is not
updated properly due to driver toggling the wrong register after an FSC
update.

On WLED5 we should only toggle the MOD_SYNC bit after a brightness
update. For an FSC update we need to toggle the SYNC bits instead.

Fix it by adopting the common wled3_sync_toggle() for WLED5 and
introducing new code to the brightness update path to
compensate.
~~~
I will update the Documentation/patch description clearly

as suggested.


Daniel.





Signed-off-by: Kiran Gunda 
---
 drivers/video/backlight/qcom-wled.c | 25 +++--
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/video/backlight/qcom-wled.c 
b/drivers/video/backlight/qcom-wled.c

index 3bc7800..aef52b9 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -348,7 +348,7 @@ static int wled3_sync_toggle(struct wled *wled)
return rc;
 }

-static int wled5_sync_toggle(struct wled *wled)
+static int wled5_mod_sync_toggle(struct wled *wled)
 {
int rc;
u8 val;
@@ -445,10 +445,23 @@ static int wled_update_status(struct 
backlight_device *bl)

goto unlock_mutex;
}

-   rc = wled->wled_sync_toggle(wled);
-   if (rc < 0) {
-   dev_err(wled->dev, "wled sync failed rc:%d\n", rc);
-   goto unlock_mutex;
+   if (wled->version < 5) {
+   rc = wled->wled_sync_toggle(wled);
+   if (rc < 0) {
+   dev_err(wled->dev, "wled sync failed rc:%d\n", 
rc);
+   goto unlock_mutex;
+   }
+   } else {
+   /*
+* For WLED5 toggling the MOD_SYNC_BIT updates the
+* brightness
+*/
+   rc = wled5_mod_sync_toggle(wled);
+   if (rc < 0) {
+   dev_err(wled->dev, "wled mod sync failed 
rc:%d\n",
+   rc);
+   goto unlock_mutex;
+   }
}
}

@@ -1459,7 +1472,7 @@ static int wled_configure(struct wled *wled)
size = ARRAY_SIZE(wled5_opts);
*cfg = wled5_config_defaults;
wled->wled_set_brightness = wled5_set_brightness;
-   wled->wled_sync_toggle = wled5_sync_toggle;
+   wled->wled_sync_toggle = wled3_sync_toggle;
wled->wled_cabc_config = wled5_cabc_config;
wled->wled_ovp_delay = wled5_ovp_delay;
wled->wled_auto_detection_required =
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,

 a Linux Foundation Collaborative Project

Re: [PATCH V1 0/2] Fix WLED FSC Sync and brightness Sync settings

[kgunda]

On 2021-02-19 23:38, Pavel Machek wrote:

Hi!

The FSC (Full scale current) setting is not updated properly due to 
the
wrong register toggling for WLED5. Also the ILED_SYNC toggle and 
MOD_SYNC
toggle sequence is updated as per the hardware team recommendation to 
fix

the FSC update and brightness update issue.


If this is phone hardware, it might make sense to cc:
phone-devel@vger...


Yes. it is for phone hardware. Will cc the email.

Best regards,
Pavel

Re: [PATCH V5 1/2] mfd: qcom-spmi-pmic: Convert bindings to .yaml format

[kgunda]

On 2021-01-12 03:12, Rob Herring wrote:

On Wed, Dec 30, 2020 at 05:26:22PM +0530, Kiran Gunda wrote:

Convert the bindings from .txt to .yaml format.

Signed-off-by: Kiran Gunda 
---
 .../devicetree/bindings/mfd/qcom,spmi-pmic.txt |  80 
--
 .../devicetree/bindings/mfd/qcom,spmi-pmic.yaml| 117 
+

 2 files changed, 117 insertions(+), 80 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt
 create mode 100644 
Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml


diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml 
b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml

new file mode 100644
index 000..b753bdb
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
@@ -0,0 +1,117 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/qcom,spmi-pmic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SPMI PMICs multi-function device bindings
+
+maintainers:
+  - Stephen Boyd 
+  - Kiran Gunda 
+
+description: |
+  The Qualcomm SPMI PMICs use a QPNP scheme through SPMI interface.
+  QPNP is effectively a partitioning scheme for dividing the SPMI 
extended

+  register space up into logical pieces, and set of fixed register
+  locations/definitions within these regions, with some of these 
regions

+  specifically used for interrupt handling.
+
+  The QPNP PMICs are used with the Qualcomm Snapdragon series SoCs, 
and are
+  interfaced to the chip via the SPMI (System Power Management 
Interface) bus.
+  Support for multiple independent functions are implemented by 
splitting the
+  16-bit SPMI slave address space into 256 smaller fixed-size 
regions, 256 bytes
+  each. A function can consume one or more of these fixed-size 
register regions.

+
+properties:
+  spmi_bus:
+type: object
+description: SPMI bus node


This is outside the scope of this binding.


+
+patternProperties:
+  "^pmic@[0-9]$":
+description: Child PMIC nodes
+type: object


You've defined spmi_bus and pmic@... as siblings. I assume you meant
parent/child instead. You'd need to indent all this 4 more spaces.

However, this is also outside the scope of the binding and should be
removed.


+
+properties:
+  compatible:


So this needs to be at the top level. 'compatible' is also how we 
decide

to apply a schema to a node. What you did here will never be applied.
Introduce an error to the example and see.


+items:
+  - enum:
+  # Sorted based on subtype ID the device reports
+  - qcom,pm8941
+  - qcom,pm8841
+  - qcom,pma8084
+  - qcom,pm8019
+  - qcom,pm8226
+  - qcom,pm8110
+  - qcom,pma8084
+  - qcom,pmi8962
+  - qcom,pmd9635
+  - qcom,pm8994
+  - qcom,pmi8994
+  - qcom,pm8916
+  - qcom,pm8004
+  - qcom,pm8909
+  - qcom,pm8950
+  - qcom,pmi8950
+  - qcom,pm8998
+  - qcom,pmi8998
+  - qcom,pm8005
+  - qcom,pm660l
+  - qcom,pm660
+
+  - enum:
+  - qcom,spmi-pmic


You can use 'const' here instead of enum.


Okay. I can address the above comments.

+
+  reg:
+maxItems: 1
+description:
+  Specifies the SPMI USID slave address for this device.
+  For more information see bindings/spmi/spmi.txt
+
+patternProperties:
+  "^[a-zA-Z0-9]$":
+description:
+  Each child node of SPMI slave id represents a function of 
the PMIC.
+  In the example below the rtc device node represents a 
peripheral of
+  pm8941 SID = 0. The regulator device node represents a 
peripheral of

+  pm8941 SID = 1.
+type: object


No, you need to define all the child nodes. This may mean you need to
split to several schemas if each PMIC has different sub devices.

Currently all the different child node bindings have not been converted 
to .yaml.
That means probably I can't convert this to .yaml unless all the child 
schemas are available?

+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+
+spmi_bus {
+compatible = "qcom,spmi-pmic-arb";
+#address-cells = <2>;
+#size-cells = <0>;
+
+pmic@0 {
+ compatible = "qcom,pm8941";
+ reg = <0x0 SPMI_USID>;
+
+ rtc {
+   compatible = "qcom,rtc";


Not documented nor used anywhere.


+   interrupts = <0x0 0x61 0x1 0x1>;
+   interrupt-names = "alarm";
+  };
+};
+
+pmic@1 {
+ compatible = "qcom,pm8941";
+ reg = <0x1 SPMI_USID>;
+
+ regulator {
+   compatible = "qcom,regulator";


Same here.


+   

Re: [PATCH V4 1/2] mfd: qcom-spmi-pmic: Convert bindings to .yaml format

[kgunda]

On 2020-12-20 05:17, Stephen Boyd wrote:

Quoting Kiran Gunda (2020-12-18 00:14:51)

Convert the bindings from .txt to .yaml format.

Signed-off-by: Kiran Gunda 
---
 .../devicetree/bindings/mfd/qcom,spmi-pmic.txt |  80 
-
 .../devicetree/bindings/mfd/qcom,spmi-pmic.yaml| 127 
+

 2 files changed, 127 insertions(+), 80 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt
 create mode 100644 
Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml


diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt 
b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt

deleted file mode 100644
index 79367a4..000
--- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt
+++ /dev/null
@@ -1,80 +0,0 @@
-  Qualcomm SPMI PMICs multi-function device bindings
-
-The Qualcomm SPMI series presently includes PM8941, PM8841 and 
PMA8084

-PMICs.  These PMICs use a QPNP scheme through SPMI interface.
-QPNP is effectively a partitioning scheme for dividing the SPMI 
extended

-register space up into logical pieces, and set of fixed register
-locations/definitions within these regions, with some of these 
regions

-specifically used for interrupt handling.
-
-The QPNP PMICs are used with the Qualcomm Snapdragon series SoCs, and 
are
-interfaced to the chip via the SPMI (System Power Management 
Interface) bus.
-Support for multiple independent functions are implemented by 
splitting the
-16-bit SPMI slave address space into 256 smaller fixed-size regions, 
256 bytes
-each. A function can consume one or more of these fixed-size register 
regions.

-
-Required properties:
-- compatible:  Should contain one of:
-   "qcom,pm8941",
-   "qcom,pm8841",
-   "qcom,pma8084",
-   "qcom,pm8019",
-   "qcom,pm8226",
-   "qcom,pm8110",
-   "qcom,pma8084",
-   "qcom,pmi8962",
-   "qcom,pmd9635",
-   "qcom,pm8994",
-   "qcom,pmi8994",
-   "qcom,pm8916",
-   "qcom,pm8004",
-   "qcom,pm8909",
-   "qcom,pm8950",
-   "qcom,pmi8950",
-   "qcom,pm8998",
-   "qcom,pmi8998",
-   "qcom,pm8005",
-   or generalized "qcom,spmi-pmic".
-- reg: Specifies the SPMI USID slave address for this 
device.

-   For more information see:
-   Documentation/devicetree/bindings/spmi/spmi.yaml
-
-Required properties for peripheral child nodes:
-- compatible:  Should contain "qcom,xxx", where "xxx" is a 
peripheral name.

-
-Optional properties for peripheral child nodes:
-- interrupts:  Interrupts are specified as a 4-tuple. For more 
information

-   see:
-   
Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
-- interrupt-names: Corresponding interrupt name to the interrupts 
property

-
-Each child node of SPMI slave id represents a function of the PMIC. 
In the

-example below the rtc device node represents a peripheral of pm8941
-SID = 0. The regulator device node represents a peripheral of pm8941 
SID = 1.

-
-Example:
-
-   spmi {
-   compatible = "qcom,spmi-pmic-arb";
-
-   pm8941@0 {
-   compatible = "qcom,pm8941", "qcom,spmi-pmic";
-   reg = <0x0 SPMI_USID>;
-
-   rtc {
-   compatible = "qcom,rtc";
-   interrupts = <0x0 0x61 0x1 
IRQ_TYPE_EDGE_RISING>;

-   interrupt-names = "alarm";
-   };
-   };
-
-   pm8941@1 {
-   compatible = "qcom,pm8941", "qcom,spmi-pmic";
-   reg = <0x1 SPMI_USID>;
-
-   regulator {
-   compatible = "qcom,regulator";
-   regulator-name = "8941_boost";
-   };
-   };
-   };
diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml 
b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml

new file mode 100644
index 000..e458dd1
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
@@ -0,0 +1,127 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/qcom,spmi-pmic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SPMI PMICs multi-function device bindings
+
+maintainers:
+  - Stephen Boyd 


Someone at Qualcomm should be the maintainer here. Maybe you?


+
+description: |
+  The Qualcomm SPMI PMICs use a QPNP scheme through SPMI interface.


What is QPNP?


Qualcomm Plug And Play.
+  QPNP is effectively a partitioning scheme for dividing the 

Re: [PATCH V4 1/2] mfd: qcom-spmi-pmic: Convert bindings to .yaml format

[kgunda]

On 2020-12-21 14:20, Lee Jones wrote:

On Fri, 18 Dec 2020, Kiran Gunda wrote:


Convert the bindings from .txt to .yaml format.

Signed-off-by: Kiran Gunda 
---
 .../devicetree/bindings/mfd/qcom,spmi-pmic.txt |  80 
-
 .../devicetree/bindings/mfd/qcom,spmi-pmic.yaml| 127 
+

 2 files changed, 127 insertions(+), 80 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt
 create mode 100644 
Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml


What are the other patches that I was not cc'ed on?

Generally it's a bad idea to send only some patches of a set to some
maintainers.  Best for everyone to have full visibility.


I ran the get_maintainer.pl script. Not sure how it is missed. Anyways
I will add you in the next post.


Also looks like you're missing a cover-letter [PATCH 0/4] which adds
to the opaqueness/confusion.
I have introduced the cover letter from V3 series. That's why the 
earlier

notes are missing from cover letter. Let me add them in next series.

Re: [PATCH V3 1/2] mfd: qcom-spmi-pmic: Convert bindings to .yaml format

[kgunda]

On 2020-10-03 03:15, Stephen Boyd wrote:

Quoting kgu...@codeaurora.org (2020-02-06 21:57:49)

On 2020-02-07 00:36, Stephen Boyd wrote:
> Quoting Kiran Gunda (2020-02-06 05:55:26)
>> Convert the bindings from .txt to .yaml format.
>>
>> Signed-off-by: Kiran Gunda 
>> ---
>
> Did something change? Is there a cover letter?
>
Other than converting the bindings to .yaml not much changed from the
previous post.
I will log the per patch changes in next post.


What happened to this series? It never got resent.
Couldn't get the chance to work on it. Will work on it and post the next 
patch in couple weeks.

Re: [PATCH V8 4/6] backlight: qcom-wled: Add support for WLED4 peripheral.

[kgunda]

On 2019-10-21 15:49, Daniel Thompson wrote:

On Fri, Oct 18, 2019 at 06:03:27PM +0530, Kiran Gunda wrote:

WLED4 peripheral is present on some PMICs like pmi8998 and
pm660l. It has a different register map and configurations
are also different. Add support for it.

Signed-off-by: Kiran Gunda 
Reviewed-by: Bjorn Andersson 


Reviewed-by: Daniel Thompson 


Thanks !

---
 drivers/video/backlight/qcom-wled.c | 255 
+++-

 1 file changed, 253 insertions(+), 2 deletions(-)

diff --git a/drivers/video/backlight/qcom-wled.c 
b/drivers/video/backlight/qcom-wled.c

index 45eeda4..5386ca9 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -17,7 +17,7 @@

 #define WLED3_SINK_REG_BRIGHT_MAX  0xFFF

-/* WLED3 control registers */
+/* WLED3/WLED4 control registers */
 #define WLED3_CTRL_REG_MOD_EN  0x46
 #define  WLED3_CTRL_REG_MOD_EN_MASKBIT(7)
 #define  WLED3_CTRL_REG_MOD_EN_SHIFT   7
@@ -31,7 +31,7 @@
 #define WLED3_CTRL_REG_ILIMIT  0x4e
 #define  WLED3_CTRL_REG_ILIMIT_MASKGENMASK(2, 0)

-/* WLED3 sink registers */
+/* WLED3/WLED4 sink registers */
 #define WLED3_SINK_REG_SYNC0x47
 #define  WLED3_SINK_REG_SYNC_CLEAR 0x00

@@ -56,6 +56,28 @@
 #define WLED3_SINK_REG_STR_CABC(n) (0x66 + (n * 0x10))
 #define  WLED3_SINK_REG_STR_CABC_MASK  BIT(7)

+/* WLED4 specific sink registers */
+#define WLED4_SINK_REG_CURR_SINK   0x46
+#define  WLED4_SINK_REG_CURR_SINK_MASK GENMASK(7, 4)
+#define  WLED4_SINK_REG_CURR_SINK_SHFT 4
+
+/* WLED4 specific per-'string' registers below */
+#define WLED4_SINK_REG_STR_MOD_EN(n)   (0x50 + (n * 0x10))
+#define  WLED4_SINK_REG_STR_MOD_MASK   BIT(7)
+
+#define WLED4_SINK_REG_STR_FULL_SCALE_CURR(n)  (0x52 + (n * 0x10))
+#define  WLED4_SINK_REG_STR_FULL_SCALE_CURR_MASK   GENMASK(3, 0)
+
+#define WLED4_SINK_REG_STR_MOD_SRC(n)  (0x53 + (n * 0x10))
+#define  WLED4_SINK_REG_STR_MOD_SRC_MASK   BIT(0)
+#define  WLED4_SINK_REG_STR_MOD_SRC_INT0x00
+#define  WLED4_SINK_REG_STR_MOD_SRC_EXT0x01
+
+#define WLED4_SINK_REG_STR_CABC(n) (0x56 + (n * 0x10))
+#define  WLED4_SINK_REG_STR_CABC_MASK  BIT(7)
+
+#define WLED4_SINK_REG_BRIGHT(n)   (0x57 + (n * 0x10))
+
 struct wled_var_cfg {
const u32 *values;
u32 (*fn)(u32);
@@ -90,6 +112,7 @@ struct wled {
struct device *dev;
struct regmap *regmap;
u16 ctrl_addr;
+   u16 sink_addr;
u16 max_string_count;
u32 brightness;
u32 max_brightness;
@@ -116,6 +139,29 @@ static int wled3_set_brightness(struct wled 
*wled, u16 brightness)

return 0;
 }

+static int wled4_set_brightness(struct wled *wled, u16 brightness)
+{
+   int rc, i;
+   u16 low_limit = wled->max_brightness * 4 / 1000;
+   u8 v[2];
+
+   /* WLED4's lower limit of operation is 0.4% */
+   if (brightness > 0 && brightness < low_limit)
+   brightness = low_limit;
+
+   v[0] = brightness & 0xff;
+   v[1] = (brightness >> 8) & 0xf;
+
+   for (i = 0;  i < wled->cfg.num_strings; ++i) {
+   rc = regmap_bulk_write(wled->regmap, wled->sink_addr +
+  WLED4_SINK_REG_BRIGHT(i), v, 2);
+   if (rc < 0)
+   return rc;
+   }
+
+   return 0;
+}
+
 static int wled_module_enable(struct wled *wled, int val)
 {
int rc;
@@ -267,6 +313,120 @@ static int wled3_setup(struct wled *wled)
.enabled_strings = {0, 1, 2, 3},
 };

+static int wled4_setup(struct wled *wled)
+{
+   int rc, temp, i, j;
+   u16 addr;
+   u8 sink_en = 0;
+   u32 sink_cfg = 0;
+
+   rc = regmap_update_bits(wled->regmap,
+   wled->ctrl_addr + WLED3_CTRL_REG_OVP,
+   WLED3_CTRL_REG_OVP_MASK, wled->cfg.ovp);
+   if (rc < 0)
+   return rc;
+
+   rc = regmap_update_bits(wled->regmap,
+   wled->ctrl_addr + WLED3_CTRL_REG_ILIMIT,
+   WLED3_CTRL_REG_ILIMIT_MASK,
+   wled->cfg.boost_i_limit);
+   if (rc < 0)
+   return rc;
+
+   rc = regmap_update_bits(wled->regmap,
+   wled->ctrl_addr + WLED3_CTRL_REG_FREQ,
+   WLED3_CTRL_REG_FREQ_MASK,
+   wled->cfg.switch_freq);
+   if (rc < 0)
+   return rc;
+
+   rc = regmap_read(wled->regmap, wled->sink_addr +
+WLED4_SINK_REG_CURR_SINK, _cfg);
+   if (rc < 0)
+   return rc;
+
+ 

Re: [PATCH V1] dt-bindings: pinctrl: qcom-pmic-gpio: Add support for pm6150/pm6150l

[kgunda]

On 2019-10-16 13:45, Vinod Koul wrote:

On 04-10-19, 16:50, Kiran Gunda wrote:

Add support for the PM6150 and PM6150L GPIO support to the
Qualcomm PMIC GPIO binding.

Signed-off-by: Kiran Gunda 
---
 Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt | 4 
 drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 2 ++
 2 files changed, 6 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt 
b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt

index c32bf32..2f48cca 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt
@@ -23,6 +23,8 @@ PMIC's from Qualcomm.
"qcom,pms405-gpio"
"qcom,pm8150-gpio"
"qcom,pm8150b-gpio"
+   "qcom,pm6150-gpio"
+   "qcom,pm6150l-gpio"

And must contain either "qcom,spmi-gpio" or "qcom,ssbi-gpio"
if the device is on an spmi bus or an ssbi bus respectively
@@ -100,6 +102,8 @@ to specify in a pin configuration subnode:
 and gpio8)
gpio1-gpio12 for pm8150b (holes on gpio3, gpio4, gpio7)
gpio1-gpio12 for pm8150l (hole on gpio7)
+   gpio1-gpio10 for pm6150
+   gpio1-gpio12 for pm6150l


No holes on these?


Yes. No holes.

Other than this:

Reviewed-by: Vinod Koul 



 - function:
Usage: required
diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c 
b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c

index f1fece5..387917c 100644
--- a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
+++ b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
@@ -1121,6 +1121,8 @@ static int pmic_gpio_remove(struct 
platform_device *pdev)

{ .compatible = "qcom,pm8150b-gpio", .data = (void *) 12 },
/* pm8150l has 12 GPIOs with holes on 7 */
{ .compatible = "qcom,pm8150l-gpio", .data = (void *) 12 },
+   { .compatible = "qcom,pm6150-gpio", .data = (void *) 10 },
+   { .compatible = "qcom,pm6150l-gpio", .data = (void *) 12 },
{ },
 };

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,

 a Linux Foundation Collaborative Project

Re: [PATCH v4 6/8] arm64: dts: qcom: sm8150-mtp: Add regulators

[kgunda]

On 2019-08-23 11:35, kgu...@codeaurora.org wrote:

On 2019-08-22 00:12, Vinod Koul wrote:
Add the regulators found in the mtp platform. This platform consists 
of

pmic PM8150, PM8150L and PM8009.

Signed-off-by: Vinod Koul 
Reviewed-by: Niklas Cassel 
---
 arch/arm64/boot/dts/qcom/sm8150-mtp.dts | 324 


 1 file changed, 324 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
b/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
index 6f5777f530ae..aa5de42fcae4 100644
--- a/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
@@ -6,6 +6,7 @@

 /dts-v1/;

+#include 
 #include "sm8150.dtsi"
 #include "pm8150.dtsi"
 #include "pm8150b.dtsi"
@@ -22,6 +23,329 @@
chosen {
stdout-path = "serial0:115200n8";
};
+
+   vph_pwr: vph-pwr-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vph_pwr";
+   regulator-min-microvolt = <370>;
+   regulator-max-microvolt = <370>;
+   };
+
+   /*
+* Apparently RPMh does not provide support for PM8150 S4 because it
+* is always-on; model it as a fixed regulator.
+*/
+   vreg_s4a_1p8: pm8150-s4 {
+   compatible = "regulator-fixed";
+   regulator-name = "vreg_s4a_1p8";
+
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+
+   regulator-always-on;
+   regulator-boot-on;
+
+   vin-supply = <_pwr>;
+   };
+};
+
+_rsc {
+   pm8150-rpmh-regulators {
+   compatible = "qcom,pm8150-rpmh-regulators";
+   qcom,pmic-id = "a";
+
+   vdd-s1-supply = <_pwr>;
+   vdd-s2-supply = <_pwr>;
+   vdd-s3-supply = <_pwr>;
+   vdd-s4-supply = <_pwr>;
+   vdd-s5-supply = <_pwr>;
+   vdd-s6-supply = <_pwr>;
+   vdd-s7-supply = <_pwr>;
+   vdd-s8-supply = <_pwr>;
+   vdd-s9-supply = <_pwr>;
+   vdd-s10-supply = <_pwr>;
+
+   vdd-l1-l8-l11-supply = <_s6a_0p9>;
+   vdd-l2-l10-supply = <_bob>;
+   vdd-l3-l4-l5-l18-supply = <_s6a_0p9>;

You no need to vote for the parent supply from the Linux driver. The
parent/child dependency is completely taken care by the
AOP/RPMh. Voting on the parent will create unnecessary additional RPMh
transactions, which may degrade the performance.

+   vdd-l6-l9-supply = <_s8c_1p3>;
+   vdd-l7-l12-l14-l15-supply = <_s5a_2p0>;
+   vdd-l13-l16-l17-supply = <_bob>;
+
+   vreg_s5a_2p0: smps5 {
+   regulator-min-microvolt = <1904000>;
+   regulator-max-microvolt = <200>;
+   };
+
+   vreg_s6a_0p9: smps6 {
+   regulator-min-microvolt = <92>;
+   regulator-max-microvolt = <1128000>;
+   };
+
+   vdda_wcss_pll:
+   vreg_l1a_0p75: ldo1 {
+   regulator-min-microvolt = <752000>;
+   regulator-max-microvolt = <752000>;
+   regulator-initial-mode = ;
+   };
+
+   vdd_pdphy:
+   vdda_usb_hs_3p1:
+   vreg_l2a_3p1: ldo2 {
+   regulator-min-microvolt = <3072000>;
+   regulator-max-microvolt = <3072000>;
+   regulator-initial-mode = ;
+   };
+
+   vreg_l3a_0p8: ldo3 {
+   regulator-min-microvolt = <48>;
+   regulator-max-microvolt = <932000>;
+   regulator-initial-mode = ;
+   };
+
+   vdd_usb_hs_core:
+   vdda_csi_0_0p9:
+   vdda_csi_1_0p9:
+   vdda_csi_2_0p9:
+   vdda_csi_3_0p9:
+   vdda_dsi_0_0p9:
+   vdda_dsi_1_0p9:
+   vdda_dsi_0_pll_0p9:
+   vdda_dsi_1_pll_0p9:
+   vdda_pcie_1ln_core:
+   vdda_pcie_2ln_core:
+   vdda_pll_hv_cc_ebi01:
+   vdda_pll_hv_cc_ebi23:
+   vdda_qrefs_0p875_5:
+   vdda_sp_sensor:
+   vdda_ufs_2ln_core_1:
+   vdda_ufs_2ln_core_2:
+   vdda_usb_ss_dp_core_1:
+   vdda_usb_ss_dp_core_2:
+   vdda_qlink_lv:
+   vdda_qlink_lv_ck:
Why few LDOs doesn't have the consumer names (handles) mentioned, while 
few LDOs have them.

Can you have them for all LDOs?

+   vreg_l5a_0p875: ldo5 {
+   regulator-min-microvolt = <88>;
+   regulator-max-microvolt = <88>;
+   regulator-initial-mode = ;
+   };
+
+   vreg_l6a_1p2: ldo6 {
+   regulator-min-microvolt = 

Re: [PATCH v4 6/8] arm64: dts: qcom: sm8150-mtp: Add regulators

[kgunda]

On 2019-08-22 00:12, Vinod Koul wrote:

Add the regulators found in the mtp platform. This platform consists of
pmic PM8150, PM8150L and PM8009.

Signed-off-by: Vinod Koul 
Reviewed-by: Niklas Cassel 
---
 arch/arm64/boot/dts/qcom/sm8150-mtp.dts | 324 
 1 file changed, 324 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
b/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
index 6f5777f530ae..aa5de42fcae4 100644
--- a/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
@@ -6,6 +6,7 @@

 /dts-v1/;

+#include 
 #include "sm8150.dtsi"
 #include "pm8150.dtsi"
 #include "pm8150b.dtsi"
@@ -22,6 +23,329 @@
chosen {
stdout-path = "serial0:115200n8";
};
+
+   vph_pwr: vph-pwr-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vph_pwr";
+   regulator-min-microvolt = <370>;
+   regulator-max-microvolt = <370>;
+   };
+
+   /*
+* Apparently RPMh does not provide support for PM8150 S4 because it
+* is always-on; model it as a fixed regulator.
+*/
+   vreg_s4a_1p8: pm8150-s4 {
+   compatible = "regulator-fixed";
+   regulator-name = "vreg_s4a_1p8";
+
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+
+   regulator-always-on;
+   regulator-boot-on;
+
+   vin-supply = <_pwr>;
+   };
+};
+
+_rsc {
+   pm8150-rpmh-regulators {
+   compatible = "qcom,pm8150-rpmh-regulators";
+   qcom,pmic-id = "a";
+
+   vdd-s1-supply = <_pwr>;
+   vdd-s2-supply = <_pwr>;
+   vdd-s3-supply = <_pwr>;
+   vdd-s4-supply = <_pwr>;
+   vdd-s5-supply = <_pwr>;
+   vdd-s6-supply = <_pwr>;
+   vdd-s7-supply = <_pwr>;
+   vdd-s8-supply = <_pwr>;
+   vdd-s9-supply = <_pwr>;
+   vdd-s10-supply = <_pwr>;
+
+   vdd-l1-l8-l11-supply = <_s6a_0p9>;
+   vdd-l2-l10-supply = <_bob>;
+   vdd-l3-l4-l5-l18-supply = <_s6a_0p9>;
You no need to vote for the parent supply from the Linux driver. The 
parent/child dependency is completely taken care by the
AOP/RPMh. Voting on the parent will create unnecessary additional RPMh 
transactions, which may degrade the performance.

+   vdd-l6-l9-supply = <_s8c_1p3>;
+   vdd-l7-l12-l14-l15-supply = <_s5a_2p0>;
+   vdd-l13-l16-l17-supply = <_bob>;
+
+   vreg_s5a_2p0: smps5 {
+   regulator-min-microvolt = <1904000>;
+   regulator-max-microvolt = <200>;
+   };
+
+   vreg_s6a_0p9: smps6 {
+   regulator-min-microvolt = <92>;
+   regulator-max-microvolt = <1128000>;
+   };
+
+   vdda_wcss_pll:
+   vreg_l1a_0p75: ldo1 {
+   regulator-min-microvolt = <752000>;
+   regulator-max-microvolt = <752000>;
+   regulator-initial-mode = ;
+   };
+
+   vdd_pdphy:
+   vdda_usb_hs_3p1:
+   vreg_l2a_3p1: ldo2 {
+   regulator-min-microvolt = <3072000>;
+   regulator-max-microvolt = <3072000>;
+   regulator-initial-mode = ;
+   };
+
+   vreg_l3a_0p8: ldo3 {
+   regulator-min-microvolt = <48>;
+   regulator-max-microvolt = <932000>;
+   regulator-initial-mode = ;
+   };
+
+   vdd_usb_hs_core:
+   vdda_csi_0_0p9:
+   vdda_csi_1_0p9:
+   vdda_csi_2_0p9:
+   vdda_csi_3_0p9:
+   vdda_dsi_0_0p9:
+   vdda_dsi_1_0p9:
+   vdda_dsi_0_pll_0p9:
+   vdda_dsi_1_pll_0p9:
+   vdda_pcie_1ln_core:
+   vdda_pcie_2ln_core:
+   vdda_pll_hv_cc_ebi01:
+   vdda_pll_hv_cc_ebi23:
+   vdda_qrefs_0p875_5:
+   vdda_sp_sensor:
+   vdda_ufs_2ln_core_1:
+   vdda_ufs_2ln_core_2:
+   vdda_usb_ss_dp_core_1:
+   vdda_usb_ss_dp_core_2:
+   vdda_qlink_lv:
+   vdda_qlink_lv_ck:
+   vreg_l5a_0p875: ldo5 {
+   regulator-min-microvolt = <88>;
+   regulator-max-microvolt = <88>;
+   regulator-initial-mode = ;
+   };
+
+   vreg_l6a_1p2: ldo6 {
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <120>;
+   regulator-initial-mode = ;
+   };
+
+   vreg_l7a_1p8: ldo7 {
+   

Re: [PATCH V3 6/7] backlight: qcom-wled: add support for short circuit handling

[kgunda]

On 2018-06-20 11:17, Vinod wrote:

On 19-06-18, 16:43, Kiran Gunda wrote:


 struct wled {
const char *name;
struct device *dev;
struct regmap *regmap;
+   struct mutex lock;  /* Lock to avoid race from ISR */


the comment is wrong as you avoid race with thread handler and not the
main ISR. The ISR runs in atomic context so you cant use a mutex but 
you

may do so with a thread handler


Will fix the comment in the next series.

+#define WLED_SHORT_DLY_MS  20
+#define WLED_SHORT_CNT_MAX 5
+#define WLED_SHORT_RESET_CNT_DLY_USUSEC_PER_SEC


an empty line after defines would be better


Will add it in the next series.

+static int wled_configure_short_irq(struct wled *wled,
+   struct platform_device *pdev)
+{
+   int rc = 0, short_irq;


superfluous initialization of rc

Will remove the initialization in next series.

Re: [PATCH V3 6/7] backlight: qcom-wled: add support for short circuit handling

[kgunda]

On 2018-06-20 11:17, Vinod wrote:

On 19-06-18, 16:43, Kiran Gunda wrote:


 struct wled {
const char *name;
struct device *dev;
struct regmap *regmap;
+   struct mutex lock;  /* Lock to avoid race from ISR */


the comment is wrong as you avoid race with thread handler and not the
main ISR. The ISR runs in atomic context so you cant use a mutex but 
you

may do so with a thread handler


Will fix the comment in the next series.

+#define WLED_SHORT_DLY_MS  20
+#define WLED_SHORT_CNT_MAX 5
+#define WLED_SHORT_RESET_CNT_DLY_USUSEC_PER_SEC


an empty line after defines would be better


Will add it in the next series.

+static int wled_configure_short_irq(struct wled *wled,
+   struct platform_device *pdev)
+{
+   int rc = 0, short_irq;


superfluous initialization of rc

Will remove the initialization in next series.

Re: [PATCH V1 2/5] backlight: qcom-wled: Add support for WLED4 peripheral

[kgunda]

On 2018-05-17 18:01, Rob Herring wrote:

On Thu, May 17, 2018 at 4:47 AM,   wrote:

On 2018-05-08 15:55, kgu...@codeaurora.org wrote:


On 2018-05-07 21:50, Bjorn Andersson wrote:


On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:


WLED4 peripheral is present on some PMICs like pmi8998
and pm660l. It has a different register map and also
configurations are different. Add support for it.



Several things are going on in this patch, it needs to be split to
not hide the functional changes from the structural/renames.


Ok. I will split it in the next series.


Signed-off-by: Kiran Gunda 
---
 .../bindings/leds/backlight/qcom-wled.txt  | 172 -
 drivers/video/backlight/qcom-wled.c| 749
+++--
 2 files changed, 696 insertions(+), 225 deletions(-)

diff --git
a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
index fb39e32..0ceffa1 100644
--- 
a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
+++ 
b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt

@@ -1,30 +1,129 @@
 Binding for Qualcomm Technologies, Inc. WLED driver

-Required properties:
-- compatible: should be "qcom,pm8941-wled"
-- reg: slave address
-
-Optional properties:
-- default-brightness: brightness value on boot, value from: 0-4095
-   default: 2048
-- label: The name of the backlight device
-- qcom,cs-out: bool; enable current sink output
-- qcom,cabc: bool; enable content adaptive backlight control
-- qcom,ext-gen: bool; use externally generated modulator signal to 
dim
-- qcom,current-limit: mA; per-string current limit; value from 0 
to 25

-   default: 20mA
-- qcom,current-boost-limit: mA; boost current limit; one of:
-   105, 385, 525, 805, 980, 1260, 1400, 1680
-   default: 805mA
-- qcom,switching-freq: kHz; switching frequency; one of:
-   600, 640, 685, 738, 800, 872, 960, 1066, 1200, 1371,
-   1600, 1920, 2400, 3200, 4800, 9600,
-   default: 1600kHz
-- qcom,ovp: V; Over-voltage protection limit; one of:
-   27, 29, 32, 35
-   default: 29V
-- qcom,num-strings: #; number of led strings attached; value from 
1 to

3
-   default: 2
+WLED (White Light Emitting Diode) driver is used for controlling
display
+backlight that is part of PMIC on Qualcomm Technologies, Inc. 
reference
+platforms. The PMIC is connected to the host processor via SPMI 
bus.

+
+- compatible
+   Usage:required
+   Value type:   
+   Definition:   should be "qcom,pm8941-wled" or
"qcom,pmi8998-wled".
+ or "qcom,pm660l-wled".



Better written as

should be one of:
X
Y
Z


Will do it in the next series.


+
+- reg
+   Usage:required
+   Value type:   
+   Definition:   Base address of the WLED modules.
+
+- interrupts
+   Usage:optional
+   Value type:   
+   Definition:   Interrupts associated with WLED. Interrupts 
can be

+ specified as per the encoding listed under
+ Documentation/devicetree/bindings/spmi/
+ qcom,spmi-pmic-arb.txt.



Better to describe that this should be the "short" and "ovp" 
interrupts

in this property than in the interrupt-names.


Ok. I will do it in the next series.


+
+- interrupt-names
+   Usage:optional
+   Value type:   
+   Definition:   Interrupt names associated with the 
interrupts.

+ Must be "short" and "ovp". The short circuit
detection
+ is not supported for PM8941.
+
+- label
+   Usage:required
+   Value type:   
+   Definition:   The name of the backlight device
+
+- default-brightness
+   Usage:optional
+   Value type:   
+   Definition:   brightness value on boot, value from: 0-4095
+ Default: 2048
+
+- qcom,current-limit
+   Usage:optional
+   Value type:   
+   Definition:   uA; per-string current limit



You can't change unit on an existing property, that breaks any 
existing

dts using the qcom,pm8941-wled compatible.




+ value:
+ For pm8941: from 0 to 25000 with 5000 ua step
+ Default 2 uA
+ For pmi8998: from 0 to 3 with 5000 ua 
step

+  Default 25000 uA.



These values could be described just as well in mA, so keep the 
original

unit - in particular since the boot-limit is in mA...


Ok. Will keep the original as is in the next series.


Here, I may have to go with the approach as in "qcom,ovp". Because for
pm8941
the current step is 1 mA (I have wrongly mentioned as 5000uA here) and 
for

PMI8998
the current step is 2.5 mA. Hence, I will add another variable
"qcom,current-limit-ua"
just 

Re: [PATCH V1 2/5] backlight: qcom-wled: Add support for WLED4 peripheral

[kgunda]

On 2018-05-17 18:01, Rob Herring wrote:

On Thu, May 17, 2018 at 4:47 AM,   wrote:

On 2018-05-08 15:55, kgu...@codeaurora.org wrote:


On 2018-05-07 21:50, Bjorn Andersson wrote:


On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:


WLED4 peripheral is present on some PMICs like pmi8998
and pm660l. It has a different register map and also
configurations are different. Add support for it.



Several things are going on in this patch, it needs to be split to
not hide the functional changes from the structural/renames.


Ok. I will split it in the next series.


Signed-off-by: Kiran Gunda 
---
 .../bindings/leds/backlight/qcom-wled.txt  | 172 -
 drivers/video/backlight/qcom-wled.c| 749
+++--
 2 files changed, 696 insertions(+), 225 deletions(-)

diff --git
a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
index fb39e32..0ceffa1 100644
--- 
a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
+++ 
b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt

@@ -1,30 +1,129 @@
 Binding for Qualcomm Technologies, Inc. WLED driver

-Required properties:
-- compatible: should be "qcom,pm8941-wled"
-- reg: slave address
-
-Optional properties:
-- default-brightness: brightness value on boot, value from: 0-4095
-   default: 2048
-- label: The name of the backlight device
-- qcom,cs-out: bool; enable current sink output
-- qcom,cabc: bool; enable content adaptive backlight control
-- qcom,ext-gen: bool; use externally generated modulator signal to 
dim
-- qcom,current-limit: mA; per-string current limit; value from 0 
to 25

-   default: 20mA
-- qcom,current-boost-limit: mA; boost current limit; one of:
-   105, 385, 525, 805, 980, 1260, 1400, 1680
-   default: 805mA
-- qcom,switching-freq: kHz; switching frequency; one of:
-   600, 640, 685, 738, 800, 872, 960, 1066, 1200, 1371,
-   1600, 1920, 2400, 3200, 4800, 9600,
-   default: 1600kHz
-- qcom,ovp: V; Over-voltage protection limit; one of:
-   27, 29, 32, 35
-   default: 29V
-- qcom,num-strings: #; number of led strings attached; value from 
1 to

3
-   default: 2
+WLED (White Light Emitting Diode) driver is used for controlling
display
+backlight that is part of PMIC on Qualcomm Technologies, Inc. 
reference
+platforms. The PMIC is connected to the host processor via SPMI 
bus.

+
+- compatible
+   Usage:required
+   Value type:   
+   Definition:   should be "qcom,pm8941-wled" or
"qcom,pmi8998-wled".
+ or "qcom,pm660l-wled".



Better written as

should be one of:
X
Y
Z


Will do it in the next series.


+
+- reg
+   Usage:required
+   Value type:   
+   Definition:   Base address of the WLED modules.
+
+- interrupts
+   Usage:optional
+   Value type:   
+   Definition:   Interrupts associated with WLED. Interrupts 
can be

+ specified as per the encoding listed under
+ Documentation/devicetree/bindings/spmi/
+ qcom,spmi-pmic-arb.txt.



Better to describe that this should be the "short" and "ovp" 
interrupts

in this property than in the interrupt-names.


Ok. I will do it in the next series.


+
+- interrupt-names
+   Usage:optional
+   Value type:   
+   Definition:   Interrupt names associated with the 
interrupts.

+ Must be "short" and "ovp". The short circuit
detection
+ is not supported for PM8941.
+
+- label
+   Usage:required
+   Value type:   
+   Definition:   The name of the backlight device
+
+- default-brightness
+   Usage:optional
+   Value type:   
+   Definition:   brightness value on boot, value from: 0-4095
+ Default: 2048
+
+- qcom,current-limit
+   Usage:optional
+   Value type:   
+   Definition:   uA; per-string current limit



You can't change unit on an existing property, that breaks any 
existing

dts using the qcom,pm8941-wled compatible.




+ value:
+ For pm8941: from 0 to 25000 with 5000 ua step
+ Default 2 uA
+ For pmi8998: from 0 to 3 with 5000 ua 
step

+  Default 25000 uA.



These values could be described just as well in mA, so keep the 
original

unit - in particular since the boot-limit is in mA...


Ok. Will keep the original as is in the next series.


Here, I may have to go with the approach as in "qcom,ovp". Because for
pm8941
the current step is 1 mA (I have wrongly mentioned as 5000uA here) and 
for

PMI8998
the current step is 2.5 mA. Hence, I will add another variable
"qcom,current-limit-ua"
just like "qcom,ovp-mv".


Use unit suffixes defined 

Re: [PATCH V1 2/5] backlight: qcom-wled: Add support for WLED4 peripheral

[kgunda]

On 2018-05-08 15:55, kgu...@codeaurora.org wrote:

On 2018-05-07 21:50, Bjorn Andersson wrote:

On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:


WLED4 peripheral is present on some PMICs like pmi8998
and pm660l. It has a different register map and also
configurations are different. Add support for it.



Several things are going on in this patch, it needs to be split to
not hide the functional changes from the structural/renames.


Ok. I will split it in the next series.

Signed-off-by: Kiran Gunda 
---
 .../bindings/leds/backlight/qcom-wled.txt  | 172 -
 drivers/video/backlight/qcom-wled.c| 749 
+++--

 2 files changed, 696 insertions(+), 225 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt 
b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt

index fb39e32..0ceffa1 100644
--- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
+++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
@@ -1,30 +1,129 @@
 Binding for Qualcomm Technologies, Inc. WLED driver

-Required properties:
-- compatible: should be "qcom,pm8941-wled"
-- reg: slave address
-
-Optional properties:
-- default-brightness: brightness value on boot, value from: 0-4095
-   default: 2048
-- label: The name of the backlight device
-- qcom,cs-out: bool; enable current sink output
-- qcom,cabc: bool; enable content adaptive backlight control
-- qcom,ext-gen: bool; use externally generated modulator signal to 
dim
-- qcom,current-limit: mA; per-string current limit; value from 0 to 
25

-   default: 20mA
-- qcom,current-boost-limit: mA; boost current limit; one of:
-   105, 385, 525, 805, 980, 1260, 1400, 1680
-   default: 805mA
-- qcom,switching-freq: kHz; switching frequency; one of:
-   600, 640, 685, 738, 800, 872, 960, 1066, 1200, 1371,
-   1600, 1920, 2400, 3200, 4800, 9600,
-   default: 1600kHz
-- qcom,ovp: V; Over-voltage protection limit; one of:
-   27, 29, 32, 35
-   default: 29V
-- qcom,num-strings: #; number of led strings attached; value from 1 
to 3

-   default: 2
+WLED (White Light Emitting Diode) driver is used for controlling 
display
+backlight that is part of PMIC on Qualcomm Technologies, Inc. 
reference

+platforms. The PMIC is connected to the host processor via SPMI bus.
+
+- compatible
+   Usage:required
+   Value type:   
+   Definition:   should be "qcom,pm8941-wled" or "qcom,pmi8998-wled".
+ or "qcom,pm660l-wled".


Better written as

should be one of:
X
Y
Z


Will do it in the next series.

+
+- reg
+   Usage:required
+   Value type:   
+   Definition:   Base address of the WLED modules.
+
+- interrupts
+   Usage:optional
+   Value type:   
+   Definition:   Interrupts associated with WLED. Interrupts can be
+ specified as per the encoding listed under
+ Documentation/devicetree/bindings/spmi/
+ qcom,spmi-pmic-arb.txt.


Better to describe that this should be the "short" and "ovp" 
interrupts

in this property than in the interrupt-names.


Ok. I will do it in the next series.

+
+- interrupt-names
+   Usage:optional
+   Value type:   
+   Definition:   Interrupt names associated with the interrupts.
+ Must be "short" and "ovp". The short circuit detection
+ is not supported for PM8941.
+
+- label
+   Usage:required
+   Value type:   
+   Definition:   The name of the backlight device
+
+- default-brightness
+   Usage:optional
+   Value type:   
+   Definition:   brightness value on boot, value from: 0-4095
+ Default: 2048
+
+- qcom,current-limit
+   Usage:optional
+   Value type:   
+   Definition:   uA; per-string current limit


You can't change unit on an existing property, that breaks any 
existing

dts using the qcom,pm8941-wled compatible.




+ value:
+ For pm8941: from 0 to 25000 with 5000 ua step
+ Default 2 uA
+ For pmi8998: from 0 to 3 with 5000 ua step
+  Default 25000 uA.


These values could be described just as well in mA, so keep the 
original

unit - in particular since the boot-limit is in mA...


Ok. Will keep the original as is in the next series.
Here, I may have to go with the approach as in "qcom,ovp". Because for 
pm8941
the current step is 1 mA (I have wrongly mentioned as 5000uA here) and 
for PMI8998
the current step is 2.5 mA. Hence, I will add another variable 
"qcom,current-limit-ua"

just like "qcom,ovp-mv".

+
+- qcom,current-boost-limit
+   Usage:optional
+   Value type:   
+   

Re: [PATCH V1 2/5] backlight: qcom-wled: Add support for WLED4 peripheral

[kgunda]

On 2018-05-08 15:55, kgu...@codeaurora.org wrote:

On 2018-05-07 21:50, Bjorn Andersson wrote:

On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:


WLED4 peripheral is present on some PMICs like pmi8998
and pm660l. It has a different register map and also
configurations are different. Add support for it.



Several things are going on in this patch, it needs to be split to
not hide the functional changes from the structural/renames.


Ok. I will split it in the next series.

Signed-off-by: Kiran Gunda 
---
 .../bindings/leds/backlight/qcom-wled.txt  | 172 -
 drivers/video/backlight/qcom-wled.c| 749 
+++--

 2 files changed, 696 insertions(+), 225 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt 
b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt

index fb39e32..0ceffa1 100644
--- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
+++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
@@ -1,30 +1,129 @@
 Binding for Qualcomm Technologies, Inc. WLED driver

-Required properties:
-- compatible: should be "qcom,pm8941-wled"
-- reg: slave address
-
-Optional properties:
-- default-brightness: brightness value on boot, value from: 0-4095
-   default: 2048
-- label: The name of the backlight device
-- qcom,cs-out: bool; enable current sink output
-- qcom,cabc: bool; enable content adaptive backlight control
-- qcom,ext-gen: bool; use externally generated modulator signal to 
dim
-- qcom,current-limit: mA; per-string current limit; value from 0 to 
25

-   default: 20mA
-- qcom,current-boost-limit: mA; boost current limit; one of:
-   105, 385, 525, 805, 980, 1260, 1400, 1680
-   default: 805mA
-- qcom,switching-freq: kHz; switching frequency; one of:
-   600, 640, 685, 738, 800, 872, 960, 1066, 1200, 1371,
-   1600, 1920, 2400, 3200, 4800, 9600,
-   default: 1600kHz
-- qcom,ovp: V; Over-voltage protection limit; one of:
-   27, 29, 32, 35
-   default: 29V
-- qcom,num-strings: #; number of led strings attached; value from 1 
to 3

-   default: 2
+WLED (White Light Emitting Diode) driver is used for controlling 
display
+backlight that is part of PMIC on Qualcomm Technologies, Inc. 
reference

+platforms. The PMIC is connected to the host processor via SPMI bus.
+
+- compatible
+   Usage:required
+   Value type:   
+   Definition:   should be "qcom,pm8941-wled" or "qcom,pmi8998-wled".
+ or "qcom,pm660l-wled".


Better written as

should be one of:
X
Y
Z


Will do it in the next series.

+
+- reg
+   Usage:required
+   Value type:   
+   Definition:   Base address of the WLED modules.
+
+- interrupts
+   Usage:optional
+   Value type:   
+   Definition:   Interrupts associated with WLED. Interrupts can be
+ specified as per the encoding listed under
+ Documentation/devicetree/bindings/spmi/
+ qcom,spmi-pmic-arb.txt.


Better to describe that this should be the "short" and "ovp" 
interrupts

in this property than in the interrupt-names.


Ok. I will do it in the next series.

+
+- interrupt-names
+   Usage:optional
+   Value type:   
+   Definition:   Interrupt names associated with the interrupts.
+ Must be "short" and "ovp". The short circuit detection
+ is not supported for PM8941.
+
+- label
+   Usage:required
+   Value type:   
+   Definition:   The name of the backlight device
+
+- default-brightness
+   Usage:optional
+   Value type:   
+   Definition:   brightness value on boot, value from: 0-4095
+ Default: 2048
+
+- qcom,current-limit
+   Usage:optional
+   Value type:   
+   Definition:   uA; per-string current limit


You can't change unit on an existing property, that breaks any 
existing

dts using the qcom,pm8941-wled compatible.




+ value:
+ For pm8941: from 0 to 25000 with 5000 ua step
+ Default 2 uA
+ For pmi8998: from 0 to 3 with 5000 ua step
+  Default 25000 uA.


These values could be described just as well in mA, so keep the 
original

unit - in particular since the boot-limit is in mA...


Ok. Will keep the original as is in the next series.
Here, I may have to go with the approach as in "qcom,ovp". Because for 
pm8941
the current step is 1 mA (I have wrongly mentioned as 5000uA here) and 
for PMI8998
the current step is 2.5 mA. Hence, I will add another variable 
"qcom,current-limit-ua"

just like "qcom,ovp-mv".

+
+- qcom,current-boost-limit
+   Usage:optional
+   Value type:   
+   Definition:   mA; boost current 

Re: [PATCH V1 2/5] backlight: qcom-wled: Add support for WLED4 peripheral

[kgunda]

On 2018-05-14 22:27, Pavel Machek wrote:

Hi!


WLED4 peripheral is present on some PMICs like pmi8998
and pm660l. It has a different register map and also
configurations are different. Add support for it.

Signed-off-by: Kiran Gunda 
---
 .../bindings/leds/backlight/qcom-wled.txt  | 172 -
 drivers/video/backlight/qcom-wled.c| 749 
+++--

 2 files changed, 696 insertions(+), 225 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt 
b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt

index fb39e32..0ceffa1 100644
--- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
+++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
@@ -1,30 +1,129 @@
 Binding for Qualcomm Technologies, Inc. WLED driver

-Required properties:
-- compatible: should be "qcom,pm8941-wled"
-- reg: slave address
-
-Optional properties:
-- default-brightness: brightness value on boot, value from: 0-4095
-   default: 2048
+- compatible
+   Usage:required
+   Value type:   
+   Definition:   should be "qcom,pm8941-wled" or "qcom,pmi8998-wled".
+ or "qcom,pm660l-wled".
+
+- reg
+   Usage:required
+   Value type:   
+   Definition:   Base address of the WLED modules.


I'm not sure if this change of format is good idea here...

Pavel
--
This format is clean and easily readable. That's why I have moved to 
this format.
To avoid confusion, I will move out the existing properties 
(pm8941-wled.c) to other

patch. So that it will be easy to review.

To unsubscribe from this list: send the line "unsubscribe 
linux-arm-msm" in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V1 2/5] backlight: qcom-wled: Add support for WLED4 peripheral

[kgunda]

On 2018-05-14 22:27, Pavel Machek wrote:

Hi!


WLED4 peripheral is present on some PMICs like pmi8998
and pm660l. It has a different register map and also
configurations are different. Add support for it.

Signed-off-by: Kiran Gunda 
---
 .../bindings/leds/backlight/qcom-wled.txt  | 172 -
 drivers/video/backlight/qcom-wled.c| 749 
+++--

 2 files changed, 696 insertions(+), 225 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt 
b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt

index fb39e32..0ceffa1 100644
--- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
+++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
@@ -1,30 +1,129 @@
 Binding for Qualcomm Technologies, Inc. WLED driver

-Required properties:
-- compatible: should be "qcom,pm8941-wled"
-- reg: slave address
-
-Optional properties:
-- default-brightness: brightness value on boot, value from: 0-4095
-   default: 2048
+- compatible
+   Usage:required
+   Value type:   
+   Definition:   should be "qcom,pm8941-wled" or "qcom,pmi8998-wled".
+ or "qcom,pm660l-wled".
+
+- reg
+   Usage:required
+   Value type:   
+   Definition:   Base address of the WLED modules.


I'm not sure if this change of format is good idea here...

Pavel
--
This format is clean and easily readable. That's why I have moved to 
this format.
To avoid confusion, I will move out the existing properties 
(pm8941-wled.c) to other

patch. So that it will be easy to review.

To unsubscribe from this list: send the line "unsubscribe 
linux-arm-msm" in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V1 5/5] backlight: qcom-wled: Add auto string detection logic

[kgunda]

On 2018-05-14 22:32, Bjorn Andersson wrote:

On Wed 09 May 00:14 PDT 2018, kgu...@codeaurora.org wrote:


On 2018-05-07 23:40, Bjorn Andersson wrote:
> On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:
>
> [..]
> > +
> > +#define WLED_AUTO_DETECT_OVP_COUNT   5
> > +#define WLED_AUTO_DETECT_CNT_DLY_US  HZ /* 1 second */
> > +static bool wled_auto_detection_required(struct wled *wled)
>
> So cfg.auto_detection_enabled is set, but we didn't have a fault during
> wled_auto_detection_at_init(), which I presume indicates that the boot
> loader configured the strings appropriately (or didn't enable the BL).
> Then first time we try to enable the backlight we will hit the ovp irq,
> which will  enter here a few times to figure out that the strings are
> incorrectly configured and then we will do the same thing that would
> have been done if we probed with a fault.
>
> This is convoluted!
>
> If auto-detection is a feature allowing the developer to omit the string
> configuration then just do the auto detection explicitly in probe when
> the developer did so and then never do it again.
>
As explained in the previous patch, the auto-detection is needed 
later,
because are also cases where one/more of the connected LED string of 
the
display-backlight is malfunctioning (because of damage) and requires 
the
damaged string to be turned off to prevent the complete panel and/or 
board

from being damaged.


Okay, that sounds very reasonable. Please ensure that it's clearly
described in the commit message, so that we have this documented if
someone wonders in the future.

Regards,
Bjorn
--

Thanks for that ! Sure I will describe it in the commit message.
To unsubscribe from this list: send the line "unsubscribe 
linux-arm-msm" in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V1 5/5] backlight: qcom-wled: Add auto string detection logic

[kgunda]

On 2018-05-14 22:32, Bjorn Andersson wrote:

On Wed 09 May 00:14 PDT 2018, kgu...@codeaurora.org wrote:


On 2018-05-07 23:40, Bjorn Andersson wrote:
> On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:
>
> [..]
> > +
> > +#define WLED_AUTO_DETECT_OVP_COUNT   5
> > +#define WLED_AUTO_DETECT_CNT_DLY_US  HZ /* 1 second */
> > +static bool wled_auto_detection_required(struct wled *wled)
>
> So cfg.auto_detection_enabled is set, but we didn't have a fault during
> wled_auto_detection_at_init(), which I presume indicates that the boot
> loader configured the strings appropriately (or didn't enable the BL).
> Then first time we try to enable the backlight we will hit the ovp irq,
> which will  enter here a few times to figure out that the strings are
> incorrectly configured and then we will do the same thing that would
> have been done if we probed with a fault.
>
> This is convoluted!
>
> If auto-detection is a feature allowing the developer to omit the string
> configuration then just do the auto detection explicitly in probe when
> the developer did so and then never do it again.
>
As explained in the previous patch, the auto-detection is needed 
later,
because are also cases where one/more of the connected LED string of 
the
display-backlight is malfunctioning (because of damage) and requires 
the
damaged string to be turned off to prevent the complete panel and/or 
board

from being damaged.


Okay, that sounds very reasonable. Please ensure that it's clearly
described in the commit message, so that we have this documented if
someone wonders in the future.

Regards,
Bjorn
--

Thanks for that ! Sure I will describe it in the commit message.
To unsubscribe from this list: send the line "unsubscribe 
linux-arm-msm" in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V1 5/5] backlight: qcom-wled: Add auto string detection logic

[kgunda]

On 2018-05-07 23:40, Bjorn Andersson wrote:

On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:

[..]

+
+#define WLED_AUTO_DETECT_OVP_COUNT 5
+#define WLED_AUTO_DETECT_CNT_DLY_USHZ /* 1 second */
+static bool wled_auto_detection_required(struct wled *wled)


So cfg.auto_detection_enabled is set, but we didn't have a fault during
wled_auto_detection_at_init(), which I presume indicates that the boot
loader configured the strings appropriately (or didn't enable the BL).
Then first time we try to enable the backlight we will hit the ovp irq,
which will  enter here a few times to figure out that the strings are
incorrectly configured and then we will do the same thing that would
have been done if we probed with a fault.

This is convoluted!

If auto-detection is a feature allowing the developer to omit the 
string

configuration then just do the auto detection explicitly in probe when
the developer did so and then never do it again.


As explained in the previous patch, the auto-detection is needed later,
because are also cases where one/more of the connected LED string of the
display-backlight is malfunctioning (because of damage) and requires the
damaged string to be turned off to prevent the complete panel and/or 
board

from being damaged.

+{
+   s64 elapsed_time_us;
+
+   if (*wled->version == WLED_PM8941)
+   return false;
+   /*
+* Check if the OVP fault was an occasional one
+* or if it's firing continuously, the latter qualifies
+* for an auto-detection check.
+*/
+   if (!wled->auto_detection_ovp_count) {
+   wled->start_ovp_fault_time = ktime_get();
+   wled->auto_detection_ovp_count++;
+   } else {
+   elapsed_time_us = ktime_us_delta(ktime_get(),
+wled->start_ovp_fault_time);
+   if (elapsed_time_us > WLED_AUTO_DETECT_CNT_DLY_US)
+   wled->auto_detection_ovp_count = 0;
+   else
+   wled->auto_detection_ovp_count++;
+
+   if (wled->auto_detection_ovp_count >=
+   WLED_AUTO_DETECT_OVP_COUNT) {
+   wled->auto_detection_ovp_count = 0;
+   return true;
+   }
+   }
+
+   return false;
+}
+
+static int wled_auto_detection_at_init(struct wled *wled)
+{
+   int rc;
+   u32 fault_status = 0, rt_status = 0;
+
+   if (*wled->version == WLED_PM8941)
+   return 0;


cfg.auto_detection_enabled will be false in this case, so there's no
need for the extra check.


Ok. I will remove it in the next series.

+
+   if (!wled->cfg.auto_detection_enabled)
+   return 0;
+
+   rc = regmap_read(wled->regmap,
+wled->ctrl_addr + WLED3_CTRL_REG_INT_RT_STS,
+_status);
+   if (rc < 0) {
+   pr_err("Failed to read RT status rc=%d\n", rc);
+   return rc;
+   }
+
+   rc = regmap_read(wled->regmap,
+wled->ctrl_addr + WLED3_CTRL_REG_FAULT_STATUS,
+_status);
+   if (rc < 0) {
+   pr_err("Failed to read fault status rc=%d\n", rc);
+   return rc;
+   }
+
+   if ((rt_status & WLED3_CTRL_REG_OVP_FAULT_STATUS) ||
+   (fault_status & WLED3_CTRL_REG_OVP_FAULT_BIT)) {


So this would only happen if the boot loader set an invalid string
configuration, as we have yet to enable the module here?


Yes.

+   mutex_lock(>lock);
+   rc = wled_auto_string_detection(wled);
+   if (!rc)
+   wled->auto_detection_done = true;
+   mutex_unlock(>lock);
+   }
+
+   return rc;
+}
+
+static void handle_ovp_fault(struct wled *wled)
+{
+   if (!wled->cfg.auto_detection_enabled)


As this is the only reason for requesting the ovp_irq, how about just
not requesting it in this case?


This is also needed for information purpose if there is any other reason
and also discussing with HW systems what needs to do if the OVP keep on 
triggering.

+   return;
+
+   mutex_lock(>lock);
+   if (wled->ovp_irq > 0 && !wled->ovp_irq_disabled) {


The logic here is unnecessary, the only way handle_ovp_fault() is ever
executed is if wled_ovp_irq_handler() was called, which is a really 
good

indication that ovp_irq is valid and !ovp_irq_disabled. So this is
always going to be entered.


Ok. I will remove this logic in the next series.

+   disable_irq_nosync(wled->ovp_irq);
+   wled->ovp_irq_disabled = true;
+   }
+
+   if (wled_auto_detection_required(wled))
+   wled_auto_string_detection(wled);
+
+   if (wled->ovp_irq > 0 && wled->ovp_irq_disabled) {


Again, ovp_irq is valid and we entered the function with either
ovp_irq_disabled = true due to some bug or it was set to true above. 

Re: [PATCH V1 5/5] backlight: qcom-wled: Add auto string detection logic

[kgunda]

On 2018-05-07 23:40, Bjorn Andersson wrote:

On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:

[..]

+
+#define WLED_AUTO_DETECT_OVP_COUNT 5
+#define WLED_AUTO_DETECT_CNT_DLY_USHZ /* 1 second */
+static bool wled_auto_detection_required(struct wled *wled)


So cfg.auto_detection_enabled is set, but we didn't have a fault during
wled_auto_detection_at_init(), which I presume indicates that the boot
loader configured the strings appropriately (or didn't enable the BL).
Then first time we try to enable the backlight we will hit the ovp irq,
which will  enter here a few times to figure out that the strings are
incorrectly configured and then we will do the same thing that would
have been done if we probed with a fault.

This is convoluted!

If auto-detection is a feature allowing the developer to omit the 
string

configuration then just do the auto detection explicitly in probe when
the developer did so and then never do it again.


As explained in the previous patch, the auto-detection is needed later,
because are also cases where one/more of the connected LED string of the
display-backlight is malfunctioning (because of damage) and requires the
damaged string to be turned off to prevent the complete panel and/or 
board

from being damaged.

+{
+   s64 elapsed_time_us;
+
+   if (*wled->version == WLED_PM8941)
+   return false;
+   /*
+* Check if the OVP fault was an occasional one
+* or if it's firing continuously, the latter qualifies
+* for an auto-detection check.
+*/
+   if (!wled->auto_detection_ovp_count) {
+   wled->start_ovp_fault_time = ktime_get();
+   wled->auto_detection_ovp_count++;
+   } else {
+   elapsed_time_us = ktime_us_delta(ktime_get(),
+wled->start_ovp_fault_time);
+   if (elapsed_time_us > WLED_AUTO_DETECT_CNT_DLY_US)
+   wled->auto_detection_ovp_count = 0;
+   else
+   wled->auto_detection_ovp_count++;
+
+   if (wled->auto_detection_ovp_count >=
+   WLED_AUTO_DETECT_OVP_COUNT) {
+   wled->auto_detection_ovp_count = 0;
+   return true;
+   }
+   }
+
+   return false;
+}
+
+static int wled_auto_detection_at_init(struct wled *wled)
+{
+   int rc;
+   u32 fault_status = 0, rt_status = 0;
+
+   if (*wled->version == WLED_PM8941)
+   return 0;


cfg.auto_detection_enabled will be false in this case, so there's no
need for the extra check.


Ok. I will remove it in the next series.

+
+   if (!wled->cfg.auto_detection_enabled)
+   return 0;
+
+   rc = regmap_read(wled->regmap,
+wled->ctrl_addr + WLED3_CTRL_REG_INT_RT_STS,
+_status);
+   if (rc < 0) {
+   pr_err("Failed to read RT status rc=%d\n", rc);
+   return rc;
+   }
+
+   rc = regmap_read(wled->regmap,
+wled->ctrl_addr + WLED3_CTRL_REG_FAULT_STATUS,
+_status);
+   if (rc < 0) {
+   pr_err("Failed to read fault status rc=%d\n", rc);
+   return rc;
+   }
+
+   if ((rt_status & WLED3_CTRL_REG_OVP_FAULT_STATUS) ||
+   (fault_status & WLED3_CTRL_REG_OVP_FAULT_BIT)) {


So this would only happen if the boot loader set an invalid string
configuration, as we have yet to enable the module here?


Yes.

+   mutex_lock(>lock);
+   rc = wled_auto_string_detection(wled);
+   if (!rc)
+   wled->auto_detection_done = true;
+   mutex_unlock(>lock);
+   }
+
+   return rc;
+}
+
+static void handle_ovp_fault(struct wled *wled)
+{
+   if (!wled->cfg.auto_detection_enabled)


As this is the only reason for requesting the ovp_irq, how about just
not requesting it in this case?


This is also needed for information purpose if there is any other reason
and also discussing with HW systems what needs to do if the OVP keep on 
triggering.

+   return;
+
+   mutex_lock(>lock);
+   if (wled->ovp_irq > 0 && !wled->ovp_irq_disabled) {


The logic here is unnecessary, the only way handle_ovp_fault() is ever
executed is if wled_ovp_irq_handler() was called, which is a really 
good

indication that ovp_irq is valid and !ovp_irq_disabled. So this is
always going to be entered.


Ok. I will remove this logic in the next series.

+   disable_irq_nosync(wled->ovp_irq);
+   wled->ovp_irq_disabled = true;
+   }
+
+   if (wled_auto_detection_required(wled))
+   wled_auto_string_detection(wled);
+
+   if (wled->ovp_irq > 0 && wled->ovp_irq_disabled) {


Again, ovp_irq is valid and we entered the function with either
ovp_irq_disabled = true due to some bug or it was set to true above. 

Re: [PATCH V1 4/5] backlight: qcom-wled: Add support for OVP interrupt handling

[kgunda]

On 2018-05-09 10:36, kgu...@codeaurora.org wrote:

On 2018-05-08 22:49, Bjorn Andersson wrote:

On Tue 08 May 05:26 PDT 2018, kgu...@codeaurora.org wrote:


On 2018-05-07 22:51, Bjorn Andersson wrote:
> On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:

[..]

> > @@ -220,7 +255,12 @@ static int wled_module_enable(struct wled
> > *wled, int val)
> >   WLED3_CTRL_REG_MOD_EN,
> >   WLED3_CTRL_REG_MOD_EN_MASK,
> >   WLED3_CTRL_REG_MOD_EN_MASK);
> > - return rc;
> > + if (rc < 0)
> > + return rc;
> > +
> > + schedule_delayed_work(>ovp_work, WLED_SOFT_START_DLY_US);
>
> Do you really want to delay the work on disable?
>
> Wouldn't it be better to use a delay worker for the enablement and in
> the disable case you cancel the work and just disable_irq() directly
> here.
>
Sure. Will do it in the next series.
> But more importantly, if this is only related to auto detection, do you
> really want to enable/disable the ovp_irq after you have detected the
> string configuration?
>
Ok. This is used for the genuine OVP detection and for the auto 
detection as

well.


What is the expected outcome of detecting an OVP condition, outside 
auto

detection?

Ok... Out side auto detection, it is used for information purpose. I 
think it is

okay to ignore enable/disable the ovp_irq after auto detection is done.


I am taking back the above comment. The OVP irq is needed even after the 
auto detection is done.
Because there are also cases where one/more of the connected LED string 
of the display-backlight
is malfunctioning (due to damage) and requires the damaged string to be 
turned off to prevent the
complete panel and/or board from being damaged by running the auto 
detection again.


currently we are not resetting "auto_detection_done" flag once it set to 
true. I will fix it in
the next series to run the auto detection again (If the OVP condition is 
met) because of the

above mentioned reason.

We are going to discuss the HW systems to check if the OVP keep on 
occurring due to some other
reason, other then the string issue, what needs to do (disable the 
module ?).



Regards,
Bjorn

--
To unsubscribe from this list: send the line "unsubscribe 
linux-arm-msm" in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V1 4/5] backlight: qcom-wled: Add support for OVP interrupt handling

[kgunda]

On 2018-05-09 10:36, kgu...@codeaurora.org wrote:

On 2018-05-08 22:49, Bjorn Andersson wrote:

On Tue 08 May 05:26 PDT 2018, kgu...@codeaurora.org wrote:


On 2018-05-07 22:51, Bjorn Andersson wrote:
> On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:

[..]

> > @@ -220,7 +255,12 @@ static int wled_module_enable(struct wled
> > *wled, int val)
> >   WLED3_CTRL_REG_MOD_EN,
> >   WLED3_CTRL_REG_MOD_EN_MASK,
> >   WLED3_CTRL_REG_MOD_EN_MASK);
> > - return rc;
> > + if (rc < 0)
> > + return rc;
> > +
> > + schedule_delayed_work(>ovp_work, WLED_SOFT_START_DLY_US);
>
> Do you really want to delay the work on disable?
>
> Wouldn't it be better to use a delay worker for the enablement and in
> the disable case you cancel the work and just disable_irq() directly
> here.
>
Sure. Will do it in the next series.
> But more importantly, if this is only related to auto detection, do you
> really want to enable/disable the ovp_irq after you have detected the
> string configuration?
>
Ok. This is used for the genuine OVP detection and for the auto 
detection as

well.


What is the expected outcome of detecting an OVP condition, outside 
auto

detection?

Ok... Out side auto detection, it is used for information purpose. I 
think it is

okay to ignore enable/disable the ovp_irq after auto detection is done.


I am taking back the above comment. The OVP irq is needed even after the 
auto detection is done.
Because there are also cases where one/more of the connected LED string 
of the display-backlight
is malfunctioning (due to damage) and requires the damaged string to be 
turned off to prevent the
complete panel and/or board from being damaged by running the auto 
detection again.


currently we are not resetting "auto_detection_done" flag once it set to 
true. I will fix it in
the next series to run the auto detection again (If the OVP condition is 
met) because of the

above mentioned reason.

We are going to discuss the HW systems to check if the OVP keep on 
occurring due to some other
reason, other then the string issue, what needs to do (disable the 
module ?).



Regards,
Bjorn

--
To unsubscribe from this list: send the line "unsubscribe 
linux-arm-msm" in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 3/5] backlight: qcom-wled: Add support for short circuit handling

[kgunda]

On 2018-05-08 16:05, Daniel Thompson wrote:

On Thu, May 03, 2018 at 03:42:30PM +0530, Kiran Gunda wrote:

Handle the short circuit interrupt and check if the short circuit
interrupt is valid. Re-enable the module to check if it goes
away. Disable the module altogether if the short circuit event
persists.

Signed-off-by: Kiran Gunda 
---
 drivers/video/backlight/qcom-wled.c | 134 
++--

 1 file changed, 130 insertions(+), 4 deletions(-)

diff --git a/drivers/video/backlight/qcom-wled.c 
b/drivers/video/backlight/qcom-wled.c

index be8b8d3..2cfba77 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -10,6 +10,9 @@
  * GNU General Public License for more details.
  */

+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -23,7 +26,9 @@

 #define WLED3_SINK_REG_BRIGHT_MAX  0xFFF

-/* Control registers */
+/* WLED3 Control registers */
+#define WLED3_CTRL_REG_FAULT_STATUS0x08
+
 #define WLED3_CTRL_REG_MOD_EN  0x46
 #define  WLED3_CTRL_REG_MOD_EN_MASKBIT(7)

@@ -36,7 +41,17 @@
 #define WLED3_CTRL_REG_ILIMIT  0x4e
 #define  WLED3_CTRL_REG_ILIMIT_MASKGENMASK(2, 0)

-/* sink registers */
+/* WLED4 control registers */
+#define WLED4_CTRL_REG_SHORT_PROTECT   0x5e
+#define  WLED4_CTRL_REG_SHORT_EN_MASK  BIT(7)
+
+#define WLED4_CTRL_REG_SEC_ACCESS  0xd0
+#define  WLED4_CTRL_REG_SEC_UNLOCK 0xa5
+
+#define WLED4_CTRL_REG_TEST1   0xe2
+#define  WLED4_CTRL_REG_TEST1_EXT_FET_DTEST2   0x09
+
+/* WLED3 sink registers */
 #define WLED3_SINK_REG_SYNC0x47
 #define  WLED3_SINK_REG_SYNC_MASK  GENMASK(2, 0)
 #define  WLED4_SINK_REG_SYNC_MASK  GENMASK(3, 0)
@@ -130,17 +145,23 @@ struct wled_config {
bool cs_out_en;
bool ext_gen;
bool cabc;
+   bool external_pfet;
 };

 struct wled {
const char *name;
struct device *dev;
struct regmap *regmap;
+   struct mutex lock;  /* Lock to avoid race from ISR */
+   ktime_t last_short_event;
u16 ctrl_addr;
u16 sink_addr;
u32 brightness;
u32 max_brightness;
+   u32 short_count;
const int *version;
+   int short_irq;
+   bool force_mod_disable;

struct wled_config cfg;
int (*wled_set_brightness)(struct wled *wled, u16 brightness);
@@ -192,6 +213,9 @@ static int wled_module_enable(struct wled *wled, 
int val)

 {
int rc;

+   if (wled->force_mod_disable)
+   return 0;
+
rc = regmap_update_bits(wled->regmap, wled->ctrl_addr +
WLED3_CTRL_REG_MOD_EN,
WLED3_CTRL_REG_MOD_EN_MASK,
@@ -248,12 +272,13 @@ static int wled_update_status(struct 
backlight_device *bl)

bl->props.state & BL_CORE_FBBLANK)
brightness = 0;

+   mutex_lock(>lock);
if (brightness) {
rc = wled->wled_set_brightness(wled, brightness);
if (rc < 0) {
dev_err(wled->dev, "wled failed to set brightness 
rc:%d\n",
rc);
-   return rc;
+   goto unlock_mutex;
}

rc = wled->wled_sync_toggle(wled);
@@ -267,15 +292,60 @@ static int wled_update_status(struct 
backlight_device *bl)

rc = wled_module_enable(wled, !!brightness);
if (rc < 0) {
dev_err(wled->dev, "wled enable failed rc:%d\n", rc);
-   return rc;
+   goto unlock_mutex;
}
}

wled->brightness = brightness;

+unlock_mutex:
+   mutex_unlock(>lock);
+
return rc;
 }

+#define WLED_SHORT_DLY_MS  20
+#define WLED_SHORT_CNT_MAX 5
+#define WLED_SHORT_RESET_CNT_DLY_USHZ


So we think a short report every quarter second is harmless?


Yes. We wait for the short to report 5 times with in this time. If the 
short
still persists, we go and disable the WLED module to avoid the damage. 
This is

suggested by the HW team.


+static irqreturn_t wled_short_irq_handler(int irq, void *_wled)
+{
+   struct wled *wled = _wled;
+   int rc;
+   s64 elapsed_time;
+
+   wled->short_count++;
+   mutex_lock(>lock);
+   rc = wled_module_enable(wled, false);
+   if (rc < 0) {
+   dev_err(wled->dev, "wled disable failed rc:%d\n", rc);
+   goto unlock_mutex;
+   }
+
+   elapsed_time = ktime_us_delta(ktime_get(),
+ wled->last_short_event);
+   if (elapsed_time > WLED_SHORT_RESET_CNT_DLY_US)
+   

Re: [PATCH V2 3/5] backlight: qcom-wled: Add support for short circuit handling

[kgunda]

On 2018-05-08 16:05, Daniel Thompson wrote:

On Thu, May 03, 2018 at 03:42:30PM +0530, Kiran Gunda wrote:

Handle the short circuit interrupt and check if the short circuit
interrupt is valid. Re-enable the module to check if it goes
away. Disable the module altogether if the short circuit event
persists.

Signed-off-by: Kiran Gunda 
---
 drivers/video/backlight/qcom-wled.c | 134 
++--

 1 file changed, 130 insertions(+), 4 deletions(-)

diff --git a/drivers/video/backlight/qcom-wled.c 
b/drivers/video/backlight/qcom-wled.c

index be8b8d3..2cfba77 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -10,6 +10,9 @@
  * GNU General Public License for more details.
  */

+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -23,7 +26,9 @@

 #define WLED3_SINK_REG_BRIGHT_MAX  0xFFF

-/* Control registers */
+/* WLED3 Control registers */
+#define WLED3_CTRL_REG_FAULT_STATUS0x08
+
 #define WLED3_CTRL_REG_MOD_EN  0x46
 #define  WLED3_CTRL_REG_MOD_EN_MASKBIT(7)

@@ -36,7 +41,17 @@
 #define WLED3_CTRL_REG_ILIMIT  0x4e
 #define  WLED3_CTRL_REG_ILIMIT_MASKGENMASK(2, 0)

-/* sink registers */
+/* WLED4 control registers */
+#define WLED4_CTRL_REG_SHORT_PROTECT   0x5e
+#define  WLED4_CTRL_REG_SHORT_EN_MASK  BIT(7)
+
+#define WLED4_CTRL_REG_SEC_ACCESS  0xd0
+#define  WLED4_CTRL_REG_SEC_UNLOCK 0xa5
+
+#define WLED4_CTRL_REG_TEST1   0xe2
+#define  WLED4_CTRL_REG_TEST1_EXT_FET_DTEST2   0x09
+
+/* WLED3 sink registers */
 #define WLED3_SINK_REG_SYNC0x47
 #define  WLED3_SINK_REG_SYNC_MASK  GENMASK(2, 0)
 #define  WLED4_SINK_REG_SYNC_MASK  GENMASK(3, 0)
@@ -130,17 +145,23 @@ struct wled_config {
bool cs_out_en;
bool ext_gen;
bool cabc;
+   bool external_pfet;
 };

 struct wled {
const char *name;
struct device *dev;
struct regmap *regmap;
+   struct mutex lock;  /* Lock to avoid race from ISR */
+   ktime_t last_short_event;
u16 ctrl_addr;
u16 sink_addr;
u32 brightness;
u32 max_brightness;
+   u32 short_count;
const int *version;
+   int short_irq;
+   bool force_mod_disable;

struct wled_config cfg;
int (*wled_set_brightness)(struct wled *wled, u16 brightness);
@@ -192,6 +213,9 @@ static int wled_module_enable(struct wled *wled, 
int val)

 {
int rc;

+   if (wled->force_mod_disable)
+   return 0;
+
rc = regmap_update_bits(wled->regmap, wled->ctrl_addr +
WLED3_CTRL_REG_MOD_EN,
WLED3_CTRL_REG_MOD_EN_MASK,
@@ -248,12 +272,13 @@ static int wled_update_status(struct 
backlight_device *bl)

bl->props.state & BL_CORE_FBBLANK)
brightness = 0;

+   mutex_lock(>lock);
if (brightness) {
rc = wled->wled_set_brightness(wled, brightness);
if (rc < 0) {
dev_err(wled->dev, "wled failed to set brightness 
rc:%d\n",
rc);
-   return rc;
+   goto unlock_mutex;
}

rc = wled->wled_sync_toggle(wled);
@@ -267,15 +292,60 @@ static int wled_update_status(struct 
backlight_device *bl)

rc = wled_module_enable(wled, !!brightness);
if (rc < 0) {
dev_err(wled->dev, "wled enable failed rc:%d\n", rc);
-   return rc;
+   goto unlock_mutex;
}
}

wled->brightness = brightness;

+unlock_mutex:
+   mutex_unlock(>lock);
+
return rc;
 }

+#define WLED_SHORT_DLY_MS  20
+#define WLED_SHORT_CNT_MAX 5
+#define WLED_SHORT_RESET_CNT_DLY_USHZ


So we think a short report every quarter second is harmless?


Yes. We wait for the short to report 5 times with in this time. If the 
short
still persists, we go and disable the WLED module to avoid the damage. 
This is

suggested by the HW team.


+static irqreturn_t wled_short_irq_handler(int irq, void *_wled)
+{
+   struct wled *wled = _wled;
+   int rc;
+   s64 elapsed_time;
+
+   wled->short_count++;
+   mutex_lock(>lock);
+   rc = wled_module_enable(wled, false);
+   if (rc < 0) {
+   dev_err(wled->dev, "wled disable failed rc:%d\n", rc);
+   goto unlock_mutex;
+   }
+
+   elapsed_time = ktime_us_delta(ktime_get(),
+ wled->last_short_event);
+   if (elapsed_time > WLED_SHORT_RESET_CNT_DLY_US)
+   wled->short_count = 0;
+
+   

Re: [PATCH V2 4/5] backlight: qcom-wled: Add support for OVP interrupt handling

[kgunda]

On 2018-05-08 16:09, Daniel Thompson wrote:

On Thu, May 03, 2018 at 03:42:31PM +0530, Kiran Gunda wrote:

WLED peripheral has over voltage protection(OVP) circuitry and the OVP
fault is notified through an interrupt. Though this fault condition 
rising
is due to an incorrect hardware configuration is mitigated in the 
hardware,

it still needs to be detected and handled. Add support for it.


Why detect and handle it? The interrupt handler doesn't appear to do
anything other than clear the interrupt... and it appears that the
interrupt can be masked.


Planing to squash this patch with the auto-string-detection patch in the 
next series,

where the OVP is used for the right string detection.
When WLED module is enabled, keep OVP fault interrupt disabled for 10 
ms to

account for soft start delay.

Signed-off-by: Kiran Gunda 
---
 drivers/video/backlight/qcom-wled.c | 118 
+++-

 1 file changed, 116 insertions(+), 2 deletions(-)

diff --git a/drivers/video/backlight/qcom-wled.c 
b/drivers/video/backlight/qcom-wled.c

index 2cfba77..80ae084 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -23,14 +23,20 @@

 /* From DT binding */
 #define WLED_DEFAULT_BRIGHTNESS2048
-
+#define WLED_SOFT_START_DLY_US 1
 #define WLED3_SINK_REG_BRIGHT_MAX  0xFFF

 /* WLED3 Control registers */
 #define WLED3_CTRL_REG_FAULT_STATUS0x08
+#define  WLED3_CTRL_REG_ILIM_FAULT_BIT BIT(0)
+#define  WLED3_CTRL_REG_OVP_FAULT_BIT  BIT(1)
+#define  WLED4_CTRL_REG_SC_FAULT_BIT   BIT(2)
+
+#define WLED3_CTRL_REG_INT_RT_STS  0x10

 #define WLED3_CTRL_REG_MOD_EN  0x46
 #define  WLED3_CTRL_REG_MOD_EN_MASKBIT(7)
+#define  WLED3_CTRL_REG_MOD_EN_BIT BIT(7)

 #define WLED3_CTRL_REG_FREQ0x4c
 #define  WLED3_CTRL_REG_FREQ_MASK  GENMASK(3, 0)
@@ -161,9 +167,12 @@ struct wled {
u32 short_count;
const int *version;
int short_irq;
+   int ovp_irq;
bool force_mod_disable;
+   bool ovp_irq_disabled;

struct wled_config cfg;
+   struct delayed_work ovp_work;
int (*wled_set_brightness)(struct wled *wled, u16 brightness);
int (*wled_sync_toggle)(struct wled *wled);
 };
@@ -209,6 +218,32 @@ static int wled4_set_brightness(struct wled 
*wled, u16 brightness)

return 0;
 }

+static void wled_ovp_work(struct work_struct *work)
+{
+   u32 val;
+   int rc;
+
+   struct wled *wled = container_of(work,
+struct wled, ovp_work.work);
+
+	rc = regmap_read(wled->regmap, wled->ctrl_addr + 
WLED3_CTRL_REG_MOD_EN,

+);
+   if (rc < 0)
+   return;
+
+   if (val & WLED3_CTRL_REG_MOD_EN_BIT) {
+   if (wled->ovp_irq > 0 && wled->ovp_irq_disabled) {
+   enable_irq(wled->ovp_irq);
+   wled->ovp_irq_disabled = false;
+   }
+   } else {
+   if (wled->ovp_irq > 0 && !wled->ovp_irq_disabled) {
+   disable_irq(wled->ovp_irq);
+   wled->ovp_irq_disabled = true;
+   }
+   }
+}
+
 static int wled_module_enable(struct wled *wled, int val)
 {
int rc;
@@ -220,7 +255,12 @@ static int wled_module_enable(struct wled *wled, 
int val)

WLED3_CTRL_REG_MOD_EN,
WLED3_CTRL_REG_MOD_EN_MASK,
WLED3_CTRL_REG_MOD_EN_MASK);
-   return rc;
+   if (rc < 0)
+   return rc;
+
+   schedule_delayed_work(>ovp_work, WLED_SOFT_START_DLY_US);
+
+   return 0;
 }

 static int wled3_sync_toggle(struct wled *wled)
@@ -346,6 +386,36 @@ static irqreturn_t wled_short_irq_handler(int 
irq, void *_wled)

return IRQ_HANDLED;
 }

+static irqreturn_t wled_ovp_irq_handler(int irq, void *_wled)
+{
+   struct wled *wled = _wled;
+   int rc;
+   u32 int_sts, fault_sts;
+
+   rc = regmap_read(wled->regmap,
+wled->ctrl_addr + WLED3_CTRL_REG_INT_RT_STS, _sts);
+   if (rc < 0) {
+   dev_err(wled->dev, "Error in reading WLED3_INT_RT_STS rc=%d\n",
+   rc);
+   return IRQ_HANDLED;
+   }
+
+   rc = regmap_read(wled->regmap, wled->ctrl_addr +
+WLED3_CTRL_REG_FAULT_STATUS, _sts);
+   if (rc < 0) {
+   dev_err(wled->dev, "Error in reading WLED_FAULT_STATUS rc=%d\n",
+   rc);
+   return IRQ_HANDLED;
+   }
+
+   if (fault_sts &
+   (WLED3_CTRL_REG_OVP_FAULT_BIT | WLED3_CTRL_REG_ILIM_FAULT_BIT))
+		dev_dbg(wled->dev, "WLED OVP fault detected, 

Re: [PATCH V2 4/5] backlight: qcom-wled: Add support for OVP interrupt handling

[kgunda]

On 2018-05-08 16:09, Daniel Thompson wrote:

On Thu, May 03, 2018 at 03:42:31PM +0530, Kiran Gunda wrote:

WLED peripheral has over voltage protection(OVP) circuitry and the OVP
fault is notified through an interrupt. Though this fault condition 
rising
is due to an incorrect hardware configuration is mitigated in the 
hardware,

it still needs to be detected and handled. Add support for it.


Why detect and handle it? The interrupt handler doesn't appear to do
anything other than clear the interrupt... and it appears that the
interrupt can be masked.


Planing to squash this patch with the auto-string-detection patch in the 
next series,

where the OVP is used for the right string detection.
When WLED module is enabled, keep OVP fault interrupt disabled for 10 
ms to

account for soft start delay.

Signed-off-by: Kiran Gunda 
---
 drivers/video/backlight/qcom-wled.c | 118 
+++-

 1 file changed, 116 insertions(+), 2 deletions(-)

diff --git a/drivers/video/backlight/qcom-wled.c 
b/drivers/video/backlight/qcom-wled.c

index 2cfba77..80ae084 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -23,14 +23,20 @@

 /* From DT binding */
 #define WLED_DEFAULT_BRIGHTNESS2048
-
+#define WLED_SOFT_START_DLY_US 1
 #define WLED3_SINK_REG_BRIGHT_MAX  0xFFF

 /* WLED3 Control registers */
 #define WLED3_CTRL_REG_FAULT_STATUS0x08
+#define  WLED3_CTRL_REG_ILIM_FAULT_BIT BIT(0)
+#define  WLED3_CTRL_REG_OVP_FAULT_BIT  BIT(1)
+#define  WLED4_CTRL_REG_SC_FAULT_BIT   BIT(2)
+
+#define WLED3_CTRL_REG_INT_RT_STS  0x10

 #define WLED3_CTRL_REG_MOD_EN  0x46
 #define  WLED3_CTRL_REG_MOD_EN_MASKBIT(7)
+#define  WLED3_CTRL_REG_MOD_EN_BIT BIT(7)

 #define WLED3_CTRL_REG_FREQ0x4c
 #define  WLED3_CTRL_REG_FREQ_MASK  GENMASK(3, 0)
@@ -161,9 +167,12 @@ struct wled {
u32 short_count;
const int *version;
int short_irq;
+   int ovp_irq;
bool force_mod_disable;
+   bool ovp_irq_disabled;

struct wled_config cfg;
+   struct delayed_work ovp_work;
int (*wled_set_brightness)(struct wled *wled, u16 brightness);
int (*wled_sync_toggle)(struct wled *wled);
 };
@@ -209,6 +218,32 @@ static int wled4_set_brightness(struct wled 
*wled, u16 brightness)

return 0;
 }

+static void wled_ovp_work(struct work_struct *work)
+{
+   u32 val;
+   int rc;
+
+   struct wled *wled = container_of(work,
+struct wled, ovp_work.work);
+
+	rc = regmap_read(wled->regmap, wled->ctrl_addr + 
WLED3_CTRL_REG_MOD_EN,

+);
+   if (rc < 0)
+   return;
+
+   if (val & WLED3_CTRL_REG_MOD_EN_BIT) {
+   if (wled->ovp_irq > 0 && wled->ovp_irq_disabled) {
+   enable_irq(wled->ovp_irq);
+   wled->ovp_irq_disabled = false;
+   }
+   } else {
+   if (wled->ovp_irq > 0 && !wled->ovp_irq_disabled) {
+   disable_irq(wled->ovp_irq);
+   wled->ovp_irq_disabled = true;
+   }
+   }
+}
+
 static int wled_module_enable(struct wled *wled, int val)
 {
int rc;
@@ -220,7 +255,12 @@ static int wled_module_enable(struct wled *wled, 
int val)

WLED3_CTRL_REG_MOD_EN,
WLED3_CTRL_REG_MOD_EN_MASK,
WLED3_CTRL_REG_MOD_EN_MASK);
-   return rc;
+   if (rc < 0)
+   return rc;
+
+   schedule_delayed_work(>ovp_work, WLED_SOFT_START_DLY_US);
+
+   return 0;
 }

 static int wled3_sync_toggle(struct wled *wled)
@@ -346,6 +386,36 @@ static irqreturn_t wled_short_irq_handler(int 
irq, void *_wled)

return IRQ_HANDLED;
 }

+static irqreturn_t wled_ovp_irq_handler(int irq, void *_wled)
+{
+   struct wled *wled = _wled;
+   int rc;
+   u32 int_sts, fault_sts;
+
+   rc = regmap_read(wled->regmap,
+wled->ctrl_addr + WLED3_CTRL_REG_INT_RT_STS, _sts);
+   if (rc < 0) {
+   dev_err(wled->dev, "Error in reading WLED3_INT_RT_STS rc=%d\n",
+   rc);
+   return IRQ_HANDLED;
+   }
+
+   rc = regmap_read(wled->regmap, wled->ctrl_addr +
+WLED3_CTRL_REG_FAULT_STATUS, _sts);
+   if (rc < 0) {
+   dev_err(wled->dev, "Error in reading WLED_FAULT_STATUS rc=%d\n",
+   rc);
+   return IRQ_HANDLED;
+   }
+
+   if (fault_sts &
+   (WLED3_CTRL_REG_OVP_FAULT_BIT | WLED3_CTRL_REG_ILIM_FAULT_BIT))
+		dev_dbg(wled->dev, "WLED OVP fault detected, int_sts=%x fault_sts= 

Re: [PATCH V1 2/5] backlight: qcom-wled: Add support for WLED4 peripheral

[kgunda]

On 2018-05-08 22:47, Bjorn Andersson wrote:

On Tue 08 May 03:25 PDT 2018, kgu...@codeaurora.org wrote:


On 2018-05-07 21:50, Bjorn Andersson wrote:
> On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:

[..]

> > +- qcom,ovp
> > + Usage:optional
> > + Value type:   
> > + Definition:   mV; Over-voltage protection limit;
>
> The existing users of qcom,pm8941-wled depends on this being in V, so
> you can't change the unit. I suggest that you add a new "qcom,ovp-mv"
> property and make the driver fall back to looking for qcom,ovp if that
> isn't specified.
>
> PS. This is a very good example of why it is a good idea to not
> restructure and make changes at the same time - I almost missed this.
>
Actually I have checked the current kernel and none of the properties 
are
being configured from the device tree node. Hence, i thought it is the 
right

time modify the units to mV to support the PMI8998.



arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts does.


You still want to have the qcom,ovp-mv, even though it is not being
configured from device tree ?


Yes, please.


Sure.

> > +   For pm8941:  one of 27000, 29000, 32000, 35000
> > +   Default: 29000 mV
> > +   For pmi8998: one of 18100, 19600, 29600, 31100
> > +   Default: 29600 mV
> > +


Regards,
Bjorn

Re: [PATCH V1 2/5] backlight: qcom-wled: Add support for WLED4 peripheral

[kgunda]

On 2018-05-08 22:47, Bjorn Andersson wrote:

On Tue 08 May 03:25 PDT 2018, kgu...@codeaurora.org wrote:


On 2018-05-07 21:50, Bjorn Andersson wrote:
> On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:

[..]

> > +- qcom,ovp
> > + Usage:optional
> > + Value type:   
> > + Definition:   mV; Over-voltage protection limit;
>
> The existing users of qcom,pm8941-wled depends on this being in V, so
> you can't change the unit. I suggest that you add a new "qcom,ovp-mv"
> property and make the driver fall back to looking for qcom,ovp if that
> isn't specified.
>
> PS. This is a very good example of why it is a good idea to not
> restructure and make changes at the same time - I almost missed this.
>
Actually I have checked the current kernel and none of the properties 
are
being configured from the device tree node. Hence, i thought it is the 
right

time modify the units to mV to support the PMI8998.



arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts does.


You still want to have the qcom,ovp-mv, even though it is not being
configured from device tree ?


Yes, please.


Sure.

> > +   For pm8941:  one of 27000, 29000, 32000, 35000
> > +   Default: 29000 mV
> > +   For pmi8998: one of 18100, 19600, 29600, 31100
> > +   Default: 29600 mV
> > +


Regards,
Bjorn

Re: [PATCH V1 4/5] backlight: qcom-wled: Add support for OVP interrupt handling

[kgunda]

On 2018-05-08 22:49, Bjorn Andersson wrote:

On Tue 08 May 05:26 PDT 2018, kgu...@codeaurora.org wrote:


On 2018-05-07 22:51, Bjorn Andersson wrote:
> On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:

[..]

> > @@ -220,7 +255,12 @@ static int wled_module_enable(struct wled
> > *wled, int val)
> >   WLED3_CTRL_REG_MOD_EN,
> >   WLED3_CTRL_REG_MOD_EN_MASK,
> >   WLED3_CTRL_REG_MOD_EN_MASK);
> > - return rc;
> > + if (rc < 0)
> > + return rc;
> > +
> > + schedule_delayed_work(>ovp_work, WLED_SOFT_START_DLY_US);
>
> Do you really want to delay the work on disable?
>
> Wouldn't it be better to use a delay worker for the enablement and in
> the disable case you cancel the work and just disable_irq() directly
> here.
>
Sure. Will do it in the next series.
> But more importantly, if this is only related to auto detection, do you
> really want to enable/disable the ovp_irq after you have detected the
> string configuration?
>
Ok. This is used for the genuine OVP detection and for the auto 
detection as

well.


What is the expected outcome of detecting an OVP condition, outside 
auto

detection?

Ok... Out side auto detection, it is used for information purpose. I 
think it is

okay to ignore enable/disable the ovp_irq after auto detection is done.

Regards,
Bjorn

Re: [PATCH V1 4/5] backlight: qcom-wled: Add support for OVP interrupt handling

[kgunda]

On 2018-05-08 22:49, Bjorn Andersson wrote:

On Tue 08 May 05:26 PDT 2018, kgu...@codeaurora.org wrote:


On 2018-05-07 22:51, Bjorn Andersson wrote:
> On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:

[..]

> > @@ -220,7 +255,12 @@ static int wled_module_enable(struct wled
> > *wled, int val)
> >   WLED3_CTRL_REG_MOD_EN,
> >   WLED3_CTRL_REG_MOD_EN_MASK,
> >   WLED3_CTRL_REG_MOD_EN_MASK);
> > - return rc;
> > + if (rc < 0)
> > + return rc;
> > +
> > + schedule_delayed_work(>ovp_work, WLED_SOFT_START_DLY_US);
>
> Do you really want to delay the work on disable?
>
> Wouldn't it be better to use a delay worker for the enablement and in
> the disable case you cancel the work and just disable_irq() directly
> here.
>
Sure. Will do it in the next series.
> But more importantly, if this is only related to auto detection, do you
> really want to enable/disable the ovp_irq after you have detected the
> string configuration?
>
Ok. This is used for the genuine OVP detection and for the auto 
detection as

well.


What is the expected outcome of detecting an OVP condition, outside 
auto

detection?

Ok... Out side auto detection, it is used for information purpose. I 
think it is

okay to ignore enable/disable the ovp_irq after auto detection is done.

Regards,
Bjorn

Re: [PATCH V1 4/5] backlight: qcom-wled: Add support for OVP interrupt handling

[kgunda]

On 2018-05-07 22:51, Bjorn Andersson wrote:

On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:


WLED peripheral has over voltage protection(OVP) circuitry and the OVP
fault is notified through an interrupt. Though this fault condition 
rising
is due to an incorrect hardware configuration is mitigated in the 
hardware,

it still needs to be detected and handled. Add support for it.

When WLED module is enabled, keep OVP fault interrupt disabled for 10 
ms to

account for soft start delay.

Signed-off-by: Kiran Gunda 
---
 drivers/video/backlight/qcom-wled.c | 118 
+++-

 1 file changed, 116 insertions(+), 2 deletions(-)

diff --git a/drivers/video/backlight/qcom-wled.c 
b/drivers/video/backlight/qcom-wled.c

index 2cfba77..80ae084 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -23,14 +23,20 @@

 /* From DT binding */
 #define WLED_DEFAULT_BRIGHTNESS2048
-
+#define WLED_SOFT_START_DLY_US 1
 #define WLED3_SINK_REG_BRIGHT_MAX  0xFFF

 /* WLED3 Control registers */
 #define WLED3_CTRL_REG_FAULT_STATUS0x08
+#define  WLED3_CTRL_REG_ILIM_FAULT_BIT BIT(0)
+#define  WLED3_CTRL_REG_OVP_FAULT_BIT  BIT(1)
+#define  WLED4_CTRL_REG_SC_FAULT_BIT   BIT(2)
+
+#define WLED3_CTRL_REG_INT_RT_STS  0x10

 #define WLED3_CTRL_REG_MOD_EN  0x46
 #define  WLED3_CTRL_REG_MOD_EN_MASKBIT(7)
+#define  WLED3_CTRL_REG_MOD_EN_BIT BIT(7)


"BIT(7)" is not a "bit" it's a "mask", so perhaps you could use the
define with that name...which has the same value?


Sure. I will change it in next series.


 #define WLED3_CTRL_REG_FREQ0x4c
 #define  WLED3_CTRL_REG_FREQ_MASK  GENMASK(3, 0)
@@ -161,9 +167,12 @@ struct wled {
u32 short_count;
const int *version;
int short_irq;
+   int ovp_irq;
bool force_mod_disable;
+   bool ovp_irq_disabled;

struct wled_config cfg;
+   struct delayed_work ovp_work;
int (*wled_set_brightness)(struct wled *wled, u16 brightness);
int (*wled_sync_toggle)(struct wled *wled);
 };
@@ -209,6 +218,32 @@ static int wled4_set_brightness(struct wled 
*wled, u16 brightness)

return 0;
 }

+static void wled_ovp_work(struct work_struct *work)
+{
+   u32 val;
+   int rc;
+
+   struct wled *wled = container_of(work,
+struct wled, ovp_work.work);
+
+	rc = regmap_read(wled->regmap, wled->ctrl_addr + 
WLED3_CTRL_REG_MOD_EN,

+);
+   if (rc < 0)
+   return;
+
+   if (val & WLED3_CTRL_REG_MOD_EN_BIT) {
+   if (wled->ovp_irq > 0 && wled->ovp_irq_disabled) {
+   enable_irq(wled->ovp_irq);
+   wled->ovp_irq_disabled = false;
+   }
+   } else {
+   if (wled->ovp_irq > 0 && !wled->ovp_irq_disabled) {
+   disable_irq(wled->ovp_irq);
+   wled->ovp_irq_disabled = true;
+   }
+   }
+}
+
 static int wled_module_enable(struct wled *wled, int val)
 {
int rc;
@@ -220,7 +255,12 @@ static int wled_module_enable(struct wled *wled, 
int val)

WLED3_CTRL_REG_MOD_EN,
WLED3_CTRL_REG_MOD_EN_MASK,
WLED3_CTRL_REG_MOD_EN_MASK);
-   return rc;
+   if (rc < 0)
+   return rc;
+
+   schedule_delayed_work(>ovp_work, WLED_SOFT_START_DLY_US);


Do you really want to delay the work on disable?

Wouldn't it be better to use a delay worker for the enablement and in
the disable case you cancel the work and just disable_irq() directly
here.


Sure. Will do it in the next series.

But more importantly, if this is only related to auto detection, do you
really want to enable/disable the ovp_irq after you have detected the
string configuration?

Ok. This is used for the genuine OVP detection and for the auto 
detection as well.

+
+   return 0;
 }

 static int wled3_sync_toggle(struct wled *wled)
@@ -346,6 +386,36 @@ static irqreturn_t wled_short_irq_handler(int 
irq, void *_wled)

return IRQ_HANDLED;
 }

+static irqreturn_t wled_ovp_irq_handler(int irq, void *_wled)
+{
+   struct wled *wled = _wled;
+   int rc;
+   u32 int_sts, fault_sts;
+
+   rc = regmap_read(wled->regmap,
+wled->ctrl_addr + WLED3_CTRL_REG_INT_RT_STS, _sts);
+   if (rc < 0) {
+   dev_err(wled->dev, "Error in reading WLED3_INT_RT_STS rc=%d\n",
+   rc);
+   return IRQ_HANDLED;
+   }
+
+   rc = regmap_read(wled->regmap, wled->ctrl_addr +
+WLED3_CTRL_REG_FAULT_STATUS, _sts);
+

Re: [PATCH V1 4/5] backlight: qcom-wled: Add support for OVP interrupt handling

[kgunda]

On 2018-05-07 22:51, Bjorn Andersson wrote:

On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:


WLED peripheral has over voltage protection(OVP) circuitry and the OVP
fault is notified through an interrupt. Though this fault condition 
rising
is due to an incorrect hardware configuration is mitigated in the 
hardware,

it still needs to be detected and handled. Add support for it.

When WLED module is enabled, keep OVP fault interrupt disabled for 10 
ms to

account for soft start delay.

Signed-off-by: Kiran Gunda 
---
 drivers/video/backlight/qcom-wled.c | 118 
+++-

 1 file changed, 116 insertions(+), 2 deletions(-)

diff --git a/drivers/video/backlight/qcom-wled.c 
b/drivers/video/backlight/qcom-wled.c

index 2cfba77..80ae084 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -23,14 +23,20 @@

 /* From DT binding */
 #define WLED_DEFAULT_BRIGHTNESS2048
-
+#define WLED_SOFT_START_DLY_US 1
 #define WLED3_SINK_REG_BRIGHT_MAX  0xFFF

 /* WLED3 Control registers */
 #define WLED3_CTRL_REG_FAULT_STATUS0x08
+#define  WLED3_CTRL_REG_ILIM_FAULT_BIT BIT(0)
+#define  WLED3_CTRL_REG_OVP_FAULT_BIT  BIT(1)
+#define  WLED4_CTRL_REG_SC_FAULT_BIT   BIT(2)
+
+#define WLED3_CTRL_REG_INT_RT_STS  0x10

 #define WLED3_CTRL_REG_MOD_EN  0x46
 #define  WLED3_CTRL_REG_MOD_EN_MASKBIT(7)
+#define  WLED3_CTRL_REG_MOD_EN_BIT BIT(7)


"BIT(7)" is not a "bit" it's a "mask", so perhaps you could use the
define with that name...which has the same value?


Sure. I will change it in next series.


 #define WLED3_CTRL_REG_FREQ0x4c
 #define  WLED3_CTRL_REG_FREQ_MASK  GENMASK(3, 0)
@@ -161,9 +167,12 @@ struct wled {
u32 short_count;
const int *version;
int short_irq;
+   int ovp_irq;
bool force_mod_disable;
+   bool ovp_irq_disabled;

struct wled_config cfg;
+   struct delayed_work ovp_work;
int (*wled_set_brightness)(struct wled *wled, u16 brightness);
int (*wled_sync_toggle)(struct wled *wled);
 };
@@ -209,6 +218,32 @@ static int wled4_set_brightness(struct wled 
*wled, u16 brightness)

return 0;
 }

+static void wled_ovp_work(struct work_struct *work)
+{
+   u32 val;
+   int rc;
+
+   struct wled *wled = container_of(work,
+struct wled, ovp_work.work);
+
+	rc = regmap_read(wled->regmap, wled->ctrl_addr + 
WLED3_CTRL_REG_MOD_EN,

+);
+   if (rc < 0)
+   return;
+
+   if (val & WLED3_CTRL_REG_MOD_EN_BIT) {
+   if (wled->ovp_irq > 0 && wled->ovp_irq_disabled) {
+   enable_irq(wled->ovp_irq);
+   wled->ovp_irq_disabled = false;
+   }
+   } else {
+   if (wled->ovp_irq > 0 && !wled->ovp_irq_disabled) {
+   disable_irq(wled->ovp_irq);
+   wled->ovp_irq_disabled = true;
+   }
+   }
+}
+
 static int wled_module_enable(struct wled *wled, int val)
 {
int rc;
@@ -220,7 +255,12 @@ static int wled_module_enable(struct wled *wled, 
int val)

WLED3_CTRL_REG_MOD_EN,
WLED3_CTRL_REG_MOD_EN_MASK,
WLED3_CTRL_REG_MOD_EN_MASK);
-   return rc;
+   if (rc < 0)
+   return rc;
+
+   schedule_delayed_work(>ovp_work, WLED_SOFT_START_DLY_US);


Do you really want to delay the work on disable?

Wouldn't it be better to use a delay worker for the enablement and in
the disable case you cancel the work and just disable_irq() directly
here.


Sure. Will do it in the next series.

But more importantly, if this is only related to auto detection, do you
really want to enable/disable the ovp_irq after you have detected the
string configuration?

Ok. This is used for the genuine OVP detection and for the auto 
detection as well.

+
+   return 0;
 }

 static int wled3_sync_toggle(struct wled *wled)
@@ -346,6 +386,36 @@ static irqreturn_t wled_short_irq_handler(int 
irq, void *_wled)

return IRQ_HANDLED;
 }

+static irqreturn_t wled_ovp_irq_handler(int irq, void *_wled)
+{
+   struct wled *wled = _wled;
+   int rc;
+   u32 int_sts, fault_sts;
+
+   rc = regmap_read(wled->regmap,
+wled->ctrl_addr + WLED3_CTRL_REG_INT_RT_STS, _sts);
+   if (rc < 0) {
+   dev_err(wled->dev, "Error in reading WLED3_INT_RT_STS rc=%d\n",
+   rc);
+   return IRQ_HANDLED;
+   }
+
+   rc = regmap_read(wled->regmap, wled->ctrl_addr +
+WLED3_CTRL_REG_FAULT_STATUS, _sts);
+   if (rc < 0) {
+ 

Re: [PATCH V1 3/5] backlight: qcom-wled: Add support for short circuit handling

[kgunda]

On 2018-05-07 22:36, Bjorn Andersson wrote:

On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:


Handle the short circuit interrupt and check if the short circuit
interrupt is valid. Re-enable the module to check if it goes
away. Disable the module altogether if the short circuit event
persists.

Signed-off-by: Kiran Gunda 
---
 drivers/video/backlight/qcom-wled.c | 134 
++--

 1 file changed, 130 insertions(+), 4 deletions(-)

diff --git a/drivers/video/backlight/qcom-wled.c 
b/drivers/video/backlight/qcom-wled.c

index be8b8d3..2cfba77 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -10,6 +10,9 @@
  * GNU General Public License for more details.
  */

+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -23,7 +26,9 @@

 #define WLED3_SINK_REG_BRIGHT_MAX  0xFFF

-/* Control registers */
+/* WLED3 Control registers */


Minor nit, please move the change of this comment to the previous 
patch.



Ok. Will do it the next series.

+#define WLED3_CTRL_REG_FAULT_STATUS0x08


Unused.


Will remove it in the next series.

+
 #define WLED3_CTRL_REG_MOD_EN  0x46
 #define  WLED3_CTRL_REG_MOD_EN_MASKBIT(7)

@@ -36,7 +41,17 @@
 #define WLED3_CTRL_REG_ILIMIT  0x4e
 #define  WLED3_CTRL_REG_ILIMIT_MASKGENMASK(2, 0)

-/* sink registers */


Please move comment change to previous commit.


Will remove it in the next series.

+/* WLED4 control registers */
+#define WLED4_CTRL_REG_SHORT_PROTECT   0x5e
+#define  WLED4_CTRL_REG_SHORT_EN_MASK  BIT(7)
+
+#define WLED4_CTRL_REG_SEC_ACCESS  0xd0
+#define  WLED4_CTRL_REG_SEC_UNLOCK 0xa5
+
+#define WLED4_CTRL_REG_TEST1   0xe2
+#define  WLED4_CTRL_REG_TEST1_EXT_FET_DTEST2   0x09
+
+/* WLED3 sink registers */
 #define WLED3_SINK_REG_SYNC0x47
 #define  WLED3_SINK_REG_SYNC_MASK  GENMASK(2, 0)
 #define  WLED4_SINK_REG_SYNC_MASK  GENMASK(3, 0)
@@ -130,17 +145,23 @@ struct wled_config {
bool cs_out_en;
bool ext_gen;
bool cabc;
+   bool external_pfet;
 };

 struct wled {
const char *name;
struct device *dev;
struct regmap *regmap;
+   struct mutex lock;  /* Lock to avoid race from ISR */
+   ktime_t last_short_event;
u16 ctrl_addr;
u16 sink_addr;
u32 brightness;
u32 max_brightness;
+   u32 short_count;
const int *version;
+   int short_irq;
+   bool force_mod_disable;


"bool disabled_by_short" would describe what's going on better.


Will rename it in the next series.


struct wled_config cfg;
int (*wled_set_brightness)(struct wled *wled, u16 brightness);
@@ -192,6 +213,9 @@ static int wled_module_enable(struct wled *wled, 
int val)

 {
int rc;

+   if (wled->force_mod_disable)
+   return 0;
+


I don't fancy the idea of not telling user space that it's request to
turn on the backlight is ignored. Can we return some error here so that
it's possible for something to do something about this problem?


Sure. Will do it in the next series.

rc = regmap_update_bits(wled->regmap, wled->ctrl_addr +
WLED3_CTRL_REG_MOD_EN,
WLED3_CTRL_REG_MOD_EN_MASK,
@@ -248,12 +272,13 @@ static int wled_update_status(struct 
backlight_device *bl)

bl->props.state & BL_CORE_FBBLANK)
brightness = 0;

+   mutex_lock(>lock);
if (brightness) {
rc = wled->wled_set_brightness(wled, brightness);
if (rc < 0) {
dev_err(wled->dev, "wled failed to set brightness 
rc:%d\n",
rc);
-   return rc;
+   goto unlock_mutex;
}

rc = wled->wled_sync_toggle(wled);
@@ -267,15 +292,60 @@ static int wled_update_status(struct 
backlight_device *bl)

rc = wled_module_enable(wled, !!brightness);
if (rc < 0) {
dev_err(wled->dev, "wled enable failed rc:%d\n", rc);
-   return rc;
+   goto unlock_mutex;
}
}

wled->brightness = brightness;

+unlock_mutex:
+   mutex_unlock(>lock);
+
return rc;
 }

+#define WLED_SHORT_DLY_MS  20
+#define WLED_SHORT_CNT_MAX 5
+#define WLED_SHORT_RESET_CNT_DLY_USHZ


HZ is in the unit of jiffies, not micro seconds.


Will address in next series.

+static irqreturn_t wled_short_irq_handler(int irq, void *_wled)
+{
+   struct wled *wled = _wled;
+   int rc;
+   s64 elapsed_time;
+
+   

Re: [PATCH V1 3/5] backlight: qcom-wled: Add support for short circuit handling

[kgunda]

On 2018-05-07 22:36, Bjorn Andersson wrote:

On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:


Handle the short circuit interrupt and check if the short circuit
interrupt is valid. Re-enable the module to check if it goes
away. Disable the module altogether if the short circuit event
persists.

Signed-off-by: Kiran Gunda 
---
 drivers/video/backlight/qcom-wled.c | 134 
++--

 1 file changed, 130 insertions(+), 4 deletions(-)

diff --git a/drivers/video/backlight/qcom-wled.c 
b/drivers/video/backlight/qcom-wled.c

index be8b8d3..2cfba77 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -10,6 +10,9 @@
  * GNU General Public License for more details.
  */

+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -23,7 +26,9 @@

 #define WLED3_SINK_REG_BRIGHT_MAX  0xFFF

-/* Control registers */
+/* WLED3 Control registers */


Minor nit, please move the change of this comment to the previous 
patch.



Ok. Will do it the next series.

+#define WLED3_CTRL_REG_FAULT_STATUS0x08


Unused.


Will remove it in the next series.

+
 #define WLED3_CTRL_REG_MOD_EN  0x46
 #define  WLED3_CTRL_REG_MOD_EN_MASKBIT(7)

@@ -36,7 +41,17 @@
 #define WLED3_CTRL_REG_ILIMIT  0x4e
 #define  WLED3_CTRL_REG_ILIMIT_MASKGENMASK(2, 0)

-/* sink registers */


Please move comment change to previous commit.


Will remove it in the next series.

+/* WLED4 control registers */
+#define WLED4_CTRL_REG_SHORT_PROTECT   0x5e
+#define  WLED4_CTRL_REG_SHORT_EN_MASK  BIT(7)
+
+#define WLED4_CTRL_REG_SEC_ACCESS  0xd0
+#define  WLED4_CTRL_REG_SEC_UNLOCK 0xa5
+
+#define WLED4_CTRL_REG_TEST1   0xe2
+#define  WLED4_CTRL_REG_TEST1_EXT_FET_DTEST2   0x09
+
+/* WLED3 sink registers */
 #define WLED3_SINK_REG_SYNC0x47
 #define  WLED3_SINK_REG_SYNC_MASK  GENMASK(2, 0)
 #define  WLED4_SINK_REG_SYNC_MASK  GENMASK(3, 0)
@@ -130,17 +145,23 @@ struct wled_config {
bool cs_out_en;
bool ext_gen;
bool cabc;
+   bool external_pfet;
 };

 struct wled {
const char *name;
struct device *dev;
struct regmap *regmap;
+   struct mutex lock;  /* Lock to avoid race from ISR */
+   ktime_t last_short_event;
u16 ctrl_addr;
u16 sink_addr;
u32 brightness;
u32 max_brightness;
+   u32 short_count;
const int *version;
+   int short_irq;
+   bool force_mod_disable;


"bool disabled_by_short" would describe what's going on better.


Will rename it in the next series.


struct wled_config cfg;
int (*wled_set_brightness)(struct wled *wled, u16 brightness);
@@ -192,6 +213,9 @@ static int wled_module_enable(struct wled *wled, 
int val)

 {
int rc;

+   if (wled->force_mod_disable)
+   return 0;
+


I don't fancy the idea of not telling user space that it's request to
turn on the backlight is ignored. Can we return some error here so that
it's possible for something to do something about this problem?


Sure. Will do it in the next series.

rc = regmap_update_bits(wled->regmap, wled->ctrl_addr +
WLED3_CTRL_REG_MOD_EN,
WLED3_CTRL_REG_MOD_EN_MASK,
@@ -248,12 +272,13 @@ static int wled_update_status(struct 
backlight_device *bl)

bl->props.state & BL_CORE_FBBLANK)
brightness = 0;

+   mutex_lock(>lock);
if (brightness) {
rc = wled->wled_set_brightness(wled, brightness);
if (rc < 0) {
dev_err(wled->dev, "wled failed to set brightness 
rc:%d\n",
rc);
-   return rc;
+   goto unlock_mutex;
}

rc = wled->wled_sync_toggle(wled);
@@ -267,15 +292,60 @@ static int wled_update_status(struct 
backlight_device *bl)

rc = wled_module_enable(wled, !!brightness);
if (rc < 0) {
dev_err(wled->dev, "wled enable failed rc:%d\n", rc);
-   return rc;
+   goto unlock_mutex;
}
}

wled->brightness = brightness;

+unlock_mutex:
+   mutex_unlock(>lock);
+
return rc;
 }

+#define WLED_SHORT_DLY_MS  20
+#define WLED_SHORT_CNT_MAX 5
+#define WLED_SHORT_RESET_CNT_DLY_USHZ


HZ is in the unit of jiffies, not micro seconds.


Will address in next series.

+static irqreturn_t wled_short_irq_handler(int irq, void *_wled)
+{
+   struct wled *wled = _wled;
+   int rc;
+   s64 elapsed_time;
+
+   wled->short_count++;
+   

Re: [PATCH V2 1/5] backlight: qcom-wled: Rename pm8941-wled.c to qcom-wled.c

[kgunda]

On 2018-05-07 22:10, Rob Herring wrote:

On Thu, May 03, 2018 at 03:42:28PM +0530, Kiran Gunda wrote:

pm8941-wled.c driver is supporting the WLED peripheral
on pm8941. Rename it to qcom-wled.c so that it can support
WLED on multiple PMICs.

Signed-off-by: Kiran Gunda 
---
 .../bindings/leds/backlight/{pm8941-wled.txt => qcom-wled.txt}| 2 
+-


Please split DT bindings from driver patches.


Sure. Will do that in the next series.
 drivers/video/backlight/Kconfig   | 8 

 drivers/video/backlight/Makefile  | 2 
+-

 drivers/video/backlight/{pm8941-wled.c => qcom-wled.c}| 0
 4 files changed, 6 insertions(+), 6 deletions(-)
 rename 
Documentation/devicetree/bindings/leds/backlight/{pm8941-wled.txt => 
qcom-wled.txt} (95%)

 rename drivers/video/backlight/{pm8941-wled.c => qcom-wled.c} (100%)

--
To unsubscribe from this list: send the line "unsubscribe 
linux-arm-msm" in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/5] backlight: qcom-wled: Rename pm8941-wled.c to qcom-wled.c

[kgunda]

On 2018-05-07 22:10, Rob Herring wrote:

On Thu, May 03, 2018 at 03:42:28PM +0530, Kiran Gunda wrote:

pm8941-wled.c driver is supporting the WLED peripheral
on pm8941. Rename it to qcom-wled.c so that it can support
WLED on multiple PMICs.

Signed-off-by: Kiran Gunda 
---
 .../bindings/leds/backlight/{pm8941-wled.txt => qcom-wled.txt}| 2 
+-


Please split DT bindings from driver patches.


Sure. Will do that in the next series.
 drivers/video/backlight/Kconfig   | 8 

 drivers/video/backlight/Makefile  | 2 
+-

 drivers/video/backlight/{pm8941-wled.c => qcom-wled.c}| 0
 4 files changed, 6 insertions(+), 6 deletions(-)
 rename 
Documentation/devicetree/bindings/leds/backlight/{pm8941-wled.txt => 
qcom-wled.txt} (95%)

 rename drivers/video/backlight/{pm8941-wled.c => qcom-wled.c} (100%)

--
To unsubscribe from this list: send the line "unsubscribe 
linux-arm-msm" in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V1 2/5] backlight: qcom-wled: Add support for WLED4 peripheral

[kgunda]

On 2018-05-07 21:50, Bjorn Andersson wrote:

On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:


WLED4 peripheral is present on some PMICs like pmi8998
and pm660l. It has a different register map and also
configurations are different. Add support for it.



Several things are going on in this patch, it needs to be split to
not hide the functional changes from the structural/renames.


Ok. I will split it in the next series.

Signed-off-by: Kiran Gunda 
---
 .../bindings/leds/backlight/qcom-wled.txt  | 172 -
 drivers/video/backlight/qcom-wled.c| 749 
+++--

 2 files changed, 696 insertions(+), 225 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt 
b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt

index fb39e32..0ceffa1 100644
--- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
+++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
@@ -1,30 +1,129 @@
 Binding for Qualcomm Technologies, Inc. WLED driver

-Required properties:
-- compatible: should be "qcom,pm8941-wled"
-- reg: slave address
-
-Optional properties:
-- default-brightness: brightness value on boot, value from: 0-4095
-   default: 2048
-- label: The name of the backlight device
-- qcom,cs-out: bool; enable current sink output
-- qcom,cabc: bool; enable content adaptive backlight control
-- qcom,ext-gen: bool; use externally generated modulator signal to 
dim
-- qcom,current-limit: mA; per-string current limit; value from 0 to 
25

-   default: 20mA
-- qcom,current-boost-limit: mA; boost current limit; one of:
-   105, 385, 525, 805, 980, 1260, 1400, 1680
-   default: 805mA
-- qcom,switching-freq: kHz; switching frequency; one of:
-   600, 640, 685, 738, 800, 872, 960, 1066, 1200, 1371,
-   1600, 1920, 2400, 3200, 4800, 9600,
-   default: 1600kHz
-- qcom,ovp: V; Over-voltage protection limit; one of:
-   27, 29, 32, 35
-   default: 29V
-- qcom,num-strings: #; number of led strings attached; value from 1 
to 3

-   default: 2
+WLED (White Light Emitting Diode) driver is used for controlling 
display
+backlight that is part of PMIC on Qualcomm Technologies, Inc. 
reference

+platforms. The PMIC is connected to the host processor via SPMI bus.
+
+- compatible
+   Usage:required
+   Value type:   
+   Definition:   should be "qcom,pm8941-wled" or "qcom,pmi8998-wled".
+ or "qcom,pm660l-wled".


Better written as

should be one of:
X
Y
Z


Will do it in the next series.

+
+- reg
+   Usage:required
+   Value type:   
+   Definition:   Base address of the WLED modules.
+
+- interrupts
+   Usage:optional
+   Value type:   
+   Definition:   Interrupts associated with WLED. Interrupts can be
+ specified as per the encoding listed under
+ Documentation/devicetree/bindings/spmi/
+ qcom,spmi-pmic-arb.txt.


Better to describe that this should be the "short" and "ovp" interrupts
in this property than in the interrupt-names.


Ok. I will do it in the next series.

+
+- interrupt-names
+   Usage:optional
+   Value type:   
+   Definition:   Interrupt names associated with the interrupts.
+ Must be "short" and "ovp". The short circuit detection
+ is not supported for PM8941.
+
+- label
+   Usage:required
+   Value type:   
+   Definition:   The name of the backlight device
+
+- default-brightness
+   Usage:optional
+   Value type:   
+   Definition:   brightness value on boot, value from: 0-4095
+ Default: 2048
+
+- qcom,current-limit
+   Usage:optional
+   Value type:   
+   Definition:   uA; per-string current limit


You can't change unit on an existing property, that breaks any existing
dts using the qcom,pm8941-wled compatible.




+ value:
+ For pm8941: from 0 to 25000 with 5000 ua step
+ Default 2 uA
+ For pmi8998: from 0 to 3 with 5000 ua step
+  Default 25000 uA.


These values could be described just as well in mA, so keep the 
original

unit - in particular since the boot-limit is in mA...


Ok. Will keep the original as is in the next series.

+
+- qcom,current-boost-limit
+   Usage:optional
+   Value type:   
+   Definition:   mA; boost current limit.
+ For pm8941: one of: 105, 385, 525, 805, 980, 1260, 1400,
+1680. Default: 805 mA
+ For pmi8998: one of: 105, 280, 450, 620, 970, 1150, 1300,
+ 1500. Default: 970 mA
+
+- qcom,switching-freq
+   

Re: [PATCH V1 2/5] backlight: qcom-wled: Add support for WLED4 peripheral

[kgunda]

On 2018-05-07 21:50, Bjorn Andersson wrote:

On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:


WLED4 peripheral is present on some PMICs like pmi8998
and pm660l. It has a different register map and also
configurations are different. Add support for it.



Several things are going on in this patch, it needs to be split to
not hide the functional changes from the structural/renames.


Ok. I will split it in the next series.

Signed-off-by: Kiran Gunda 
---
 .../bindings/leds/backlight/qcom-wled.txt  | 172 -
 drivers/video/backlight/qcom-wled.c| 749 
+++--

 2 files changed, 696 insertions(+), 225 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt 
b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt

index fb39e32..0ceffa1 100644
--- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
+++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
@@ -1,30 +1,129 @@
 Binding for Qualcomm Technologies, Inc. WLED driver

-Required properties:
-- compatible: should be "qcom,pm8941-wled"
-- reg: slave address
-
-Optional properties:
-- default-brightness: brightness value on boot, value from: 0-4095
-   default: 2048
-- label: The name of the backlight device
-- qcom,cs-out: bool; enable current sink output
-- qcom,cabc: bool; enable content adaptive backlight control
-- qcom,ext-gen: bool; use externally generated modulator signal to 
dim
-- qcom,current-limit: mA; per-string current limit; value from 0 to 
25

-   default: 20mA
-- qcom,current-boost-limit: mA; boost current limit; one of:
-   105, 385, 525, 805, 980, 1260, 1400, 1680
-   default: 805mA
-- qcom,switching-freq: kHz; switching frequency; one of:
-   600, 640, 685, 738, 800, 872, 960, 1066, 1200, 1371,
-   1600, 1920, 2400, 3200, 4800, 9600,
-   default: 1600kHz
-- qcom,ovp: V; Over-voltage protection limit; one of:
-   27, 29, 32, 35
-   default: 29V
-- qcom,num-strings: #; number of led strings attached; value from 1 
to 3

-   default: 2
+WLED (White Light Emitting Diode) driver is used for controlling 
display
+backlight that is part of PMIC on Qualcomm Technologies, Inc. 
reference

+platforms. The PMIC is connected to the host processor via SPMI bus.
+
+- compatible
+   Usage:required
+   Value type:   
+   Definition:   should be "qcom,pm8941-wled" or "qcom,pmi8998-wled".
+ or "qcom,pm660l-wled".


Better written as

should be one of:
X
Y
Z


Will do it in the next series.

+
+- reg
+   Usage:required
+   Value type:   
+   Definition:   Base address of the WLED modules.
+
+- interrupts
+   Usage:optional
+   Value type:   
+   Definition:   Interrupts associated with WLED. Interrupts can be
+ specified as per the encoding listed under
+ Documentation/devicetree/bindings/spmi/
+ qcom,spmi-pmic-arb.txt.


Better to describe that this should be the "short" and "ovp" interrupts
in this property than in the interrupt-names.


Ok. I will do it in the next series.

+
+- interrupt-names
+   Usage:optional
+   Value type:   
+   Definition:   Interrupt names associated with the interrupts.
+ Must be "short" and "ovp". The short circuit detection
+ is not supported for PM8941.
+
+- label
+   Usage:required
+   Value type:   
+   Definition:   The name of the backlight device
+
+- default-brightness
+   Usage:optional
+   Value type:   
+   Definition:   brightness value on boot, value from: 0-4095
+ Default: 2048
+
+- qcom,current-limit
+   Usage:optional
+   Value type:   
+   Definition:   uA; per-string current limit


You can't change unit on an existing property, that breaks any existing
dts using the qcom,pm8941-wled compatible.




+ value:
+ For pm8941: from 0 to 25000 with 5000 ua step
+ Default 2 uA
+ For pmi8998: from 0 to 3 with 5000 ua step
+  Default 25000 uA.


These values could be described just as well in mA, so keep the 
original

unit - in particular since the boot-limit is in mA...


Ok. Will keep the original as is in the next series.

+
+- qcom,current-boost-limit
+   Usage:optional
+   Value type:   
+   Definition:   mA; boost current limit.
+ For pm8941: one of: 105, 385, 525, 805, 980, 1260, 1400,
+1680. Default: 805 mA
+ For pmi8998: one of: 105, 280, 450, 620, 970, 1150, 1300,
+ 1500. Default: 970 mA
+
+- qcom,switching-freq
+   Usage:optional

Re: [PATCH V2 2/5] backlight: qcom-wled: Add support for WLED4 peripheral

[kgunda]

On 2018-05-07 22:15, Rob Herring wrote:

On Thu, May 03, 2018 at 03:42:29PM +0530, Kiran Gunda wrote:

WLED4 peripheral is present on some PMICs like pmi8998
and pm660l. It has a different register map and also
configurations are different. Add support for it.

Signed-off-by: Kiran Gunda 
---
 .../bindings/leds/backlight/qcom-wled.txt  | 172 -


Please split bindings to a separate patch.

This is also a whole lot of churn re-formatting. That is fine, but 
don't

mix actual changes to the binding with re-formatting. You can do 2
patches in this case:

- move and reformat (as long as the move shows up as a move
and not a remove and add)
- additions for new chips


Sure. I will do it in the next series.
 drivers/video/backlight/qcom-wled.c| 749 
+++--

 2 files changed, 696 insertions(+), 225 deletions(-)

Re: [PATCH V2 2/5] backlight: qcom-wled: Add support for WLED4 peripheral

[kgunda]

On 2018-05-07 22:15, Rob Herring wrote:

On Thu, May 03, 2018 at 03:42:29PM +0530, Kiran Gunda wrote:

WLED4 peripheral is present on some PMICs like pmi8998
and pm660l. It has a different register map and also
configurations are different. Add support for it.

Signed-off-by: Kiran Gunda 
---
 .../bindings/leds/backlight/qcom-wled.txt  | 172 -


Please split bindings to a separate patch.

This is also a whole lot of churn re-formatting. That is fine, but 
don't

mix actual changes to the binding with re-formatting. You can do 2
patches in this case:

- move and reformat (as long as the move shows up as a move
and not a remove and add)
- additions for new chips


Sure. I will do it in the next series.
 drivers/video/backlight/qcom-wled.c| 749 
+++--

 2 files changed, 696 insertions(+), 225 deletions(-)

Re: [PATCH V2 1/5] backlight: qcom-wled: Rename pm8941-wled.c to qcom-wled.c

[kgunda]

On 2018-05-08 14:06, Daniel Thompson wrote:

On Mon, May 07, 2018 at 11:26:59AM +0530, kgu...@codeaurora.org wrote:

Hi Jingoo Han,
Thanks for the response.

Thanks,
Kiran
On 2018-05-04 21:25, Jingoo Han wrote:
> On Thursday, May 3, 2018 6:12 AM, Kiran Gunda wrote:
>
> If you really want someone to review your patch, please add more
> detailed
> explanations.
>
> 1. Please add 0th patch.
I have already added the 0th patch (cover letter). Following is the 
subject

for the same.
forwarding the same to you.
[PATCH V2 0/5] backlight: qcom-wled: Support for QCOM wled driver


Perhaps you should interpret Jingoo's comment as a request to improve
the To: and Cc: list on the 0th patch the next time you circulate it.

Many maintainers configure their mailers to give patches where they are
in the To: or Cc: list special treatment so it confusing when a series
arrives with a spartan set of recipients for the 0th patch (and doubly
confusing when every patch in the set targets the same driver).


Daniel.
Ok. Got it. Not sure how the To: Cc: list on the 0th patch got shrink, 
while I was
using the To: Cc: list same for all the patches. Anyways, will double 
check of it while

circulating the next series.

Re: [PATCH V2 1/5] backlight: qcom-wled: Rename pm8941-wled.c to qcom-wled.c

[kgunda]

On 2018-05-08 14:06, Daniel Thompson wrote:

On Mon, May 07, 2018 at 11:26:59AM +0530, kgu...@codeaurora.org wrote:

Hi Jingoo Han,
Thanks for the response.

Thanks,
Kiran
On 2018-05-04 21:25, Jingoo Han wrote:
> On Thursday, May 3, 2018 6:12 AM, Kiran Gunda wrote:
>
> If you really want someone to review your patch, please add more
> detailed
> explanations.
>
> 1. Please add 0th patch.
I have already added the 0th patch (cover letter). Following is the 
subject

for the same.
forwarding the same to you.
[PATCH V2 0/5] backlight: qcom-wled: Support for QCOM wled driver


Perhaps you should interpret Jingoo's comment as a request to improve
the To: and Cc: list on the 0th patch the next time you circulate it.

Many maintainers configure their mailers to give patches where they are
in the To: or Cc: list special treatment so it confusing when a series
arrives with a spartan set of recipients for the 0th patch (and doubly
confusing when every patch in the set targets the same driver).


Daniel.
Ok. Got it. Not sure how the To: Cc: list on the 0th patch got shrink, 
while I was
using the To: Cc: list same for all the patches. Anyways, will double 
check of it while

circulating the next series.

Re: [PATCH V1 3/5] backlight: qcom-wled: Add support for short circuit handling

[kgunda]

On 2018-05-07 13:36, Dan Carpenter wrote:

Hi Kiran,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on backlight/for-backlight-next]
[also build test WARNING on v4.17-rc3 next-20180504]
[if your patch is applied to the wrong git tree, please drop us a note
to help improve the system]

url:
https://github.com/0day-ci/linux/commits/Kiran-Gunda/backlight-qcom-wled-Support-for-QCOM-wled-driver/20180504-011042
base:
https://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight.git
for-backlight-next

smatch warnings:
drivers/video/backlight/qcom-wled.c:304 wled_update_status() warn:
inconsistent returns 'mutex:>lock'.
  Locked on:   line 287
  Unlocked on: line 304


Will fix it in the next series.

#
https://github.com/0day-ci/linux/commit/3856199804123df89ef9a712f0740978ec71ddf6
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 3856199804123df89ef9a712f0740978ec71ddf6
vim +304 drivers/video/backlight/qcom-wled.c

18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03  
263

18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 264  static int wled_update_status(struct backlight_device *bl)
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03  
265  {

18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 266struct wled *wled = bl_get_data(bl);
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 267u16 brightness = bl->props.brightness;
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 268int rc = 0;
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03  
269

18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 270if (bl->props.power != FB_BLANK_UNBLANK ||
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 271bl->props.fb_blank != FB_BLANK_UNBLANK ||
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 272bl->props.state & BL_CORE_FBBLANK)
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 273brightness = 0;
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03  
274

38561998 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 275mutex_lock(>lock);
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 276if (brightness) {
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 277rc = wled->wled_set_brightness(wled, brightness);
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 278if (rc < 0) {
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 279dev_err(wled->dev, "wled failed to set brightness 
rc:%d\n",
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 280rc);
38561998 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 281goto unlock_mutex;
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03  
282  		}
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03  
283

18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 284rc = wled->wled_sync_toggle(wled);
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 285if (rc < 0) {
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 286dev_err(wled->dev, "wled sync failed rc:%d\n", rc);
93c64f1e drivers/leds/leds-pm8941-wled.c Courtney Cavin 2015-03-12
 287return rc;
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03  
288  		}
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03  
289  	}
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03  
290

18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 291if (!!brightness != !!wled->brightness) {
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 292rc = wled_module_enable(wled, !!brightness);
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 293if (rc < 0) {
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 294dev_err(wled->dev, "wled enable failed rc:%d\n", rc);
38561998 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 295goto unlock_mutex;
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03  
296  		}
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03  
297  	}
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03  
298

18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 299wled->brightness = brightness;
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03  
300

Re: [PATCH V1 3/5] backlight: qcom-wled: Add support for short circuit handling

[kgunda]

On 2018-05-07 13:36, Dan Carpenter wrote:

Hi Kiran,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on backlight/for-backlight-next]
[also build test WARNING on v4.17-rc3 next-20180504]
[if your patch is applied to the wrong git tree, please drop us a note
to help improve the system]

url:
https://github.com/0day-ci/linux/commits/Kiran-Gunda/backlight-qcom-wled-Support-for-QCOM-wled-driver/20180504-011042
base:
https://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight.git
for-backlight-next

smatch warnings:
drivers/video/backlight/qcom-wled.c:304 wled_update_status() warn:
inconsistent returns 'mutex:>lock'.
  Locked on:   line 287
  Unlocked on: line 304


Will fix it in the next series.

#
https://github.com/0day-ci/linux/commit/3856199804123df89ef9a712f0740978ec71ddf6
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 3856199804123df89ef9a712f0740978ec71ddf6
vim +304 drivers/video/backlight/qcom-wled.c

18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03  
263

18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 264  static int wled_update_status(struct backlight_device *bl)
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03  
265  {

18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 266struct wled *wled = bl_get_data(bl);
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 267u16 brightness = bl->props.brightness;
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 268int rc = 0;
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03  
269

18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 270if (bl->props.power != FB_BLANK_UNBLANK ||
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 271bl->props.fb_blank != FB_BLANK_UNBLANK ||
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 272bl->props.state & BL_CORE_FBBLANK)
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 273brightness = 0;
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03  
274

38561998 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 275mutex_lock(>lock);
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 276if (brightness) {
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 277rc = wled->wled_set_brightness(wled, brightness);
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 278if (rc < 0) {
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 279dev_err(wled->dev, "wled failed to set brightness 
rc:%d\n",
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 280rc);
38561998 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 281goto unlock_mutex;
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03  
282  		}
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03  
283

18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 284rc = wled->wled_sync_toggle(wled);
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 285if (rc < 0) {
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 286dev_err(wled->dev, "wled sync failed rc:%d\n", rc);
93c64f1e drivers/leds/leds-pm8941-wled.c Courtney Cavin 2015-03-12
 287return rc;
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03  
288  		}
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03  
289  	}
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03  
290

18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 291if (!!brightness != !!wled->brightness) {
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 292rc = wled_module_enable(wled, !!brightness);
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 293if (rc < 0) {
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 294dev_err(wled->dev, "wled enable failed rc:%d\n", rc);
38561998 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 295goto unlock_mutex;
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03  
296  		}
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03  
297  	}
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03  
298

18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03
 299wled->brightness = brightness;
18e7abb8 drivers/video/backlight/qcom-wled.c Kiran Gunda2018-05-03  
300

Re: [PATCH V2 1/5] backlight: qcom-wled: Rename pm8941-wled.c to qcom-wled.c

[kgunda]

Hi Jingoo Han,
Thanks for the response.

Thanks,
Kiran
On 2018-05-04 21:25, Jingoo Han wrote:

On Thursday, May 3, 2018 6:12 AM, Kiran Gunda wrote:

If you really want someone to review your patch, please add more 
detailed

explanations.

1. Please add 0th patch.
I have already added the 0th patch (cover letter). Following is the 
subject for the same.

forwarding the same to you.
[PATCH V2 0/5] backlight: qcom-wled: Support for QCOM wled driver


2. Please add what the difference is between V1 and V2 patches.

Already added the difference between V1 and V2 in the cover letter (0th 
patch).
Please let me know if you are looking for any other info. Following is 
the difference

added between v1 and v2.



changes from v1:
Fixed the commit message for
backlight: qcom-wled: Rename pm8941-wled.c to qcom-wled.c

If you cannot understand what I am saying, just ask another person who 
have

an experience to send patches to Linux mailing-list.

Best regards,
Jingoo Han



pm8941-wled.c driver is supporting the WLED peripheral
on pm8941. Rename it to qcom-wled.c so that it can support
WLED on multiple PMICs.

Signed-off-by: Kiran Gunda 
---
 .../bindings/leds/backlight/{pm8941-wled.txt => qcom-wled.txt}| 2 
+-

 drivers/video/backlight/Kconfig   | 8


 drivers/video/backlight/Makefile  | 2 
+-

 drivers/video/backlight/{pm8941-wled.c => qcom-wled.c}| 0
 4 files changed, 6 insertions(+), 6 deletions(-)
 rename 
Documentation/devicetree/bindings/leds/backlight/{pm8941-wled.txt

=> qcom-wled.txt} (95%)
 rename drivers/video/backlight/{pm8941-wled.c => qcom-wled.c} (100%)

diff --git a/Documentation/devicetree/bindings/leds/backlight/pm8941-
wled.txt 
b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt

similarity index 95%
rename from Documentation/devicetree/bindings/leds/backlight/pm8941-
wled.txt
rename to 
Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt

index e5b294d..fb39e32 100644
--- a/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt
+++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
@@ -1,4 +1,4 @@
-Binding for Qualcomm PM8941 WLED driver
+Binding for Qualcomm Technologies, Inc. WLED driver

 Required properties:
 - compatible: should be "qcom,pm8941-wled"
diff --git a/drivers/video/backlight/Kconfig
b/drivers/video/backlight/Kconfig
index 4e1d2ad..8c095e3 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -299,12 +299,12 @@ config BACKLIGHT_TOSA
  If you have an Sharp SL-6000 Zaurus say Y to enable a driver
  for its backlight

-config BACKLIGHT_PM8941_WLED
-   tristate "Qualcomm PM8941 WLED Driver"
+config BACKLIGHT_QCOM_WLED
+   tristate "Qualcomm PMIC WLED Driver"
select REGMAP
help
- If you have the Qualcomm PM8941, say Y to enable a driver for the
- WLED block.
+ If you have the Qualcomm PMIC, say Y to enable a driver for the
+ WLED block. Currently it supports PM8941 and PMI8998.

 config BACKLIGHT_SAHARA
tristate "Tabletkiosk Sahara Touch-iT Backlight Driver"
diff --git a/drivers/video/backlight/Makefile
b/drivers/video/backlight/Makefile
index 5e28f01..6fd76ef 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -49,8 +49,8 @@ obj-$(CONFIG_BACKLIGHT_OMAP1) +=

omap1_bl.o

 obj-$(CONFIG_BACKLIGHT_OT200)  += ot200_bl.o
 obj-$(CONFIG_BACKLIGHT_PANDORA)+= pandora_bl.o
 obj-$(CONFIG_BACKLIGHT_PCF50633)   += pcf50633-backlight.o
-obj-$(CONFIG_BACKLIGHT_PM8941_WLED)+= pm8941-wled.o
 obj-$(CONFIG_BACKLIGHT_PWM)+= pwm_bl.o
+obj-$(CONFIG_BACKLIGHT_QCOM_WLED)  += qcom-wled.o
 obj-$(CONFIG_BACKLIGHT_SAHARA) += kb3886_bl.o
 obj-$(CONFIG_BACKLIGHT_SKY81452)   += sky81452-backlight.o
 obj-$(CONFIG_BACKLIGHT_TOSA)   += tosa_bl.o
diff --git a/drivers/video/backlight/pm8941-wled.c
b/drivers/video/backlight/qcom-wled.c
similarity index 100%
rename from drivers/video/backlight/pm8941-wled.c
rename to drivers/video/backlight/qcom-wled.c
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,

 a Linux Foundation Collaborative Project

Re: [PATCH V2 1/5] backlight: qcom-wled: Rename pm8941-wled.c to qcom-wled.c

[kgunda]

Hi Jingoo Han,
Thanks for the response.

Thanks,
Kiran
On 2018-05-04 21:25, Jingoo Han wrote:

On Thursday, May 3, 2018 6:12 AM, Kiran Gunda wrote:

If you really want someone to review your patch, please add more 
detailed

explanations.

1. Please add 0th patch.
I have already added the 0th patch (cover letter). Following is the 
subject for the same.

forwarding the same to you.
[PATCH V2 0/5] backlight: qcom-wled: Support for QCOM wled driver


2. Please add what the difference is between V1 and V2 patches.

Already added the difference between V1 and V2 in the cover letter (0th 
patch).
Please let me know if you are looking for any other info. Following is 
the difference

added between v1 and v2.



changes from v1:
Fixed the commit message for
backlight: qcom-wled: Rename pm8941-wled.c to qcom-wled.c

If you cannot understand what I am saying, just ask another person who 
have

an experience to send patches to Linux mailing-list.

Best regards,
Jingoo Han



pm8941-wled.c driver is supporting the WLED peripheral
on pm8941. Rename it to qcom-wled.c so that it can support
WLED on multiple PMICs.

Signed-off-by: Kiran Gunda 
---
 .../bindings/leds/backlight/{pm8941-wled.txt => qcom-wled.txt}| 2 
+-

 drivers/video/backlight/Kconfig   | 8


 drivers/video/backlight/Makefile  | 2 
+-

 drivers/video/backlight/{pm8941-wled.c => qcom-wled.c}| 0
 4 files changed, 6 insertions(+), 6 deletions(-)
 rename 
Documentation/devicetree/bindings/leds/backlight/{pm8941-wled.txt

=> qcom-wled.txt} (95%)
 rename drivers/video/backlight/{pm8941-wled.c => qcom-wled.c} (100%)

diff --git a/Documentation/devicetree/bindings/leds/backlight/pm8941-
wled.txt 
b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt

similarity index 95%
rename from Documentation/devicetree/bindings/leds/backlight/pm8941-
wled.txt
rename to 
Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt

index e5b294d..fb39e32 100644
--- a/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt
+++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
@@ -1,4 +1,4 @@
-Binding for Qualcomm PM8941 WLED driver
+Binding for Qualcomm Technologies, Inc. WLED driver

 Required properties:
 - compatible: should be "qcom,pm8941-wled"
diff --git a/drivers/video/backlight/Kconfig
b/drivers/video/backlight/Kconfig
index 4e1d2ad..8c095e3 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -299,12 +299,12 @@ config BACKLIGHT_TOSA
  If you have an Sharp SL-6000 Zaurus say Y to enable a driver
  for its backlight

-config BACKLIGHT_PM8941_WLED
-   tristate "Qualcomm PM8941 WLED Driver"
+config BACKLIGHT_QCOM_WLED
+   tristate "Qualcomm PMIC WLED Driver"
select REGMAP
help
- If you have the Qualcomm PM8941, say Y to enable a driver for the
- WLED block.
+ If you have the Qualcomm PMIC, say Y to enable a driver for the
+ WLED block. Currently it supports PM8941 and PMI8998.

 config BACKLIGHT_SAHARA
tristate "Tabletkiosk Sahara Touch-iT Backlight Driver"
diff --git a/drivers/video/backlight/Makefile
b/drivers/video/backlight/Makefile
index 5e28f01..6fd76ef 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -49,8 +49,8 @@ obj-$(CONFIG_BACKLIGHT_OMAP1) +=

omap1_bl.o

 obj-$(CONFIG_BACKLIGHT_OT200)  += ot200_bl.o
 obj-$(CONFIG_BACKLIGHT_PANDORA)+= pandora_bl.o
 obj-$(CONFIG_BACKLIGHT_PCF50633)   += pcf50633-backlight.o
-obj-$(CONFIG_BACKLIGHT_PM8941_WLED)+= pm8941-wled.o
 obj-$(CONFIG_BACKLIGHT_PWM)+= pwm_bl.o
+obj-$(CONFIG_BACKLIGHT_QCOM_WLED)  += qcom-wled.o
 obj-$(CONFIG_BACKLIGHT_SAHARA) += kb3886_bl.o
 obj-$(CONFIG_BACKLIGHT_SKY81452)   += sky81452-backlight.o
 obj-$(CONFIG_BACKLIGHT_TOSA)   += tosa_bl.o
diff --git a/drivers/video/backlight/pm8941-wled.c
b/drivers/video/backlight/qcom-wled.c
similarity index 100%
rename from drivers/video/backlight/pm8941-wled.c
rename to drivers/video/backlight/qcom-wled.c
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,

 a Linux Foundation Collaborative Project

Re: [PATCH V1 4/4] qcom: spmi-wled: Add auto-calibration logic support

[kgunda]

On 2018-04-20 21:33, Bjorn Andersson wrote:

On Thu 19 Apr 22:43 PDT 2018, kgu...@codeaurora.org wrote:


On 2018-04-19 21:28, Bjorn Andersson wrote:
> On Thu 19 Apr 03:45 PDT 2018, kgu...@codeaurora.org wrote:
> > On 2017-12-05 11:10, Bjorn Andersson wrote:

[..]

> > > When is this feature needed?
> > >
> > This feature is needed if the string configuration is given wrong in
> > the DT node by the user.
>
> DT describes the hardware and for all other nodes it must do so
> accurately.
>
But the user may not be aware of the strings present on the display 
panel or
may be using the same software on different devices which have 
different

strings present.


Swapping display board would still require an update to the DTS, to
support the new panel. But I think that if you're implementing auto
string detection, it should be used as the mechanism to detect the
strings, not something that is run at some later point in time when we
detect a failure.

Ok. got your point. Yes, the detection is done during the boot-up 
itself,

not later point.

> For cases where the hardware supports auto detection of functionality we
> remove information from DT and rely on that logic to figure out the
> hardware. We do not use it to reconfigure the hardware once we detect an
> error. So when auto-detection is enabled it should always be used to
> probe the hardware.
>
The auto string detection is not supported in any qcom hardware and i 
don't

think there is a plan to introduce in new hardware also.



Sorry, I don't follow. Who is using auto string detection then?

I mean to say. The HW doesn't handle the auto-detection completely in 
the HW

without having the S/W intervention, which we are using now.


Regards,
Bjorn


> Regards,
> Bjorn
>
> > > > Signed-off-by: Kiran Gunda 
> > > > ---
> > > >  .../bindings/leds/backlight/qcom-spmi-wled.txt |   5 +
> > > >  drivers/video/backlight/qcom-spmi-wled.c   | 304
> > > > -
> > > >  2 files changed, 306 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
> > > > b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
> > > > index d39ee93..f06c0cd 100644
> > > > ---
> > > > a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
> > > > +++
> > > > b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
> > > > @@ -94,6 +94,11 @@ The PMIC is connected to the host processor via
> > > > SPMI bus.
> > > > Definition: Interrupt names associated with the interrupts.
> > > > Currently supported interrupts are "sc-irq" and 
"ovp-irq".
> > > >
> > > > +- qcom,auto-calibration
> > >
> > > qcom,auto-string-detect?
> > >
> > ok. Will address in the next patch.
> > > > +   Usage:  optional
> > > > +   Value type: 
> > > > +   Definition: Enables auto-calibration of the WLED sink configuration.
> > > > +
> > > >  Example:
> > > >
> > > >  qcom-wled@d800 {
> > > > diff --git a/drivers/video/backlight/qcom-spmi-wled.c
> > > > b/drivers/video/backlight/qcom-spmi-wled.c
> > > > index 8b2a77a..aee5c56 100644
> > > > --- a/drivers/video/backlight/qcom-spmi-wled.c
> > > > +++ b/drivers/video/backlight/qcom-spmi-wled.c
> > > > @@ -38,11 +38,14 @@
> > > >  #define  QCOM_WLED_CTRL_SC_FAULT_BIT   BIT(2)
> > > >
> > > >  #define QCOM_WLED_CTRL_INT_RT_STS  0x10
> > > > +#define  QCOM_WLED_CTRL_OVP_FLT_RT_STS_BIT BIT(1)
> > >
> > > The use of BIT() makes this a mask and not a bit number, so if you just
> > > drop that you can afford to spell out the "FAULT" like the data sheet
> > > does. Perhaps even making it QCOM_WLED_CTRL_OVP_FAULT_STATUS ?
> > >
> > ok. Will change it in the next series.
> > > >
> > > >  #define QCOM_WLED_CTRL_MOD_ENABLE  0x46
> > > >  #define  QCOM_WLED_CTRL_MOD_EN_MASKBIT(7)
> > > >  #define  QCOM_WLED_CTRL_MODULE_EN_SHIFT7
> > > >
> > > > +#define QCOM_WLED_CTRL_FDBK_OP 0x48
> > >
> > > This is called WLED_CTRL_FEEDBACK_CONTROL, why the need to make it
> > > unreadable?
> > >
> > Ok. Will address it in next series.
> > > > +
> > > >  #define QCOM_WLED_CTRL_SWITCH_FREQ 0x4c
> > > >  #define  QCOM_WLED_CTRL_SWITCH_FREQ_MASK   GENMASK(3, 0)
> > > >
> > > > @@ -99,6 +102,7 @@ struct qcom_wled_config {
> > > > int ovp_irq;
> > > > bool en_cabc;
> > > > bool ext_pfet_sc_pro_en;
> > > > +   bool auto_calib_enabled;
> > > >  };
> > > >
> > > >  struct qcom_wled {
> > > > @@ -108,18 +112,25 @@ struct qcom_wled {
> > > > struct mutex lock;
> > > > struct qcom_wled_config cfg;
> > > > ktime_t last_sc_event_time;
> > > > +   ktime_t start_ovp_fault_time;
> > > > u16 sink_addr;
> > > > u16 ctrl_addr;
> > > > +   u16 auto_calibration_ovp_count;
> > > > u32 brightness;
> > > > u32 sc_count;
> > > > bool prev_state;
> > > > bool ovp_irq_disabled;
> > > > +   bool 

Re: [PATCH V1 4/4] qcom: spmi-wled: Add auto-calibration logic support

[kgunda]

On 2018-04-20 21:33, Bjorn Andersson wrote:

On Thu 19 Apr 22:43 PDT 2018, kgu...@codeaurora.org wrote:


On 2018-04-19 21:28, Bjorn Andersson wrote:
> On Thu 19 Apr 03:45 PDT 2018, kgu...@codeaurora.org wrote:
> > On 2017-12-05 11:10, Bjorn Andersson wrote:

[..]

> > > When is this feature needed?
> > >
> > This feature is needed if the string configuration is given wrong in
> > the DT node by the user.
>
> DT describes the hardware and for all other nodes it must do so
> accurately.
>
But the user may not be aware of the strings present on the display 
panel or
may be using the same software on different devices which have 
different

strings present.


Swapping display board would still require an update to the DTS, to
support the new panel. But I think that if you're implementing auto
string detection, it should be used as the mechanism to detect the
strings, not something that is run at some later point in time when we
detect a failure.

Ok. got your point. Yes, the detection is done during the boot-up 
itself,

not later point.

> For cases where the hardware supports auto detection of functionality we
> remove information from DT and rely on that logic to figure out the
> hardware. We do not use it to reconfigure the hardware once we detect an
> error. So when auto-detection is enabled it should always be used to
> probe the hardware.
>
The auto string detection is not supported in any qcom hardware and i 
don't

think there is a plan to introduce in new hardware also.



Sorry, I don't follow. Who is using auto string detection then?

I mean to say. The HW doesn't handle the auto-detection completely in 
the HW

without having the S/W intervention, which we are using now.


Regards,
Bjorn


> Regards,
> Bjorn
>
> > > > Signed-off-by: Kiran Gunda 
> > > > ---
> > > >  .../bindings/leds/backlight/qcom-spmi-wled.txt |   5 +
> > > >  drivers/video/backlight/qcom-spmi-wled.c   | 304
> > > > -
> > > >  2 files changed, 306 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
> > > > b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
> > > > index d39ee93..f06c0cd 100644
> > > > ---
> > > > a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
> > > > +++
> > > > b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
> > > > @@ -94,6 +94,11 @@ The PMIC is connected to the host processor via
> > > > SPMI bus.
> > > > Definition: Interrupt names associated with the interrupts.
> > > > Currently supported interrupts are "sc-irq" and 
"ovp-irq".
> > > >
> > > > +- qcom,auto-calibration
> > >
> > > qcom,auto-string-detect?
> > >
> > ok. Will address in the next patch.
> > > > +   Usage:  optional
> > > > +   Value type: 
> > > > +   Definition: Enables auto-calibration of the WLED sink configuration.
> > > > +
> > > >  Example:
> > > >
> > > >  qcom-wled@d800 {
> > > > diff --git a/drivers/video/backlight/qcom-spmi-wled.c
> > > > b/drivers/video/backlight/qcom-spmi-wled.c
> > > > index 8b2a77a..aee5c56 100644
> > > > --- a/drivers/video/backlight/qcom-spmi-wled.c
> > > > +++ b/drivers/video/backlight/qcom-spmi-wled.c
> > > > @@ -38,11 +38,14 @@
> > > >  #define  QCOM_WLED_CTRL_SC_FAULT_BIT   BIT(2)
> > > >
> > > >  #define QCOM_WLED_CTRL_INT_RT_STS  0x10
> > > > +#define  QCOM_WLED_CTRL_OVP_FLT_RT_STS_BIT BIT(1)
> > >
> > > The use of BIT() makes this a mask and not a bit number, so if you just
> > > drop that you can afford to spell out the "FAULT" like the data sheet
> > > does. Perhaps even making it QCOM_WLED_CTRL_OVP_FAULT_STATUS ?
> > >
> > ok. Will change it in the next series.
> > > >
> > > >  #define QCOM_WLED_CTRL_MOD_ENABLE  0x46
> > > >  #define  QCOM_WLED_CTRL_MOD_EN_MASKBIT(7)
> > > >  #define  QCOM_WLED_CTRL_MODULE_EN_SHIFT7
> > > >
> > > > +#define QCOM_WLED_CTRL_FDBK_OP 0x48
> > >
> > > This is called WLED_CTRL_FEEDBACK_CONTROL, why the need to make it
> > > unreadable?
> > >
> > Ok. Will address it in next series.
> > > > +
> > > >  #define QCOM_WLED_CTRL_SWITCH_FREQ 0x4c
> > > >  #define  QCOM_WLED_CTRL_SWITCH_FREQ_MASK   GENMASK(3, 0)
> > > >
> > > > @@ -99,6 +102,7 @@ struct qcom_wled_config {
> > > > int ovp_irq;
> > > > bool en_cabc;
> > > > bool ext_pfet_sc_pro_en;
> > > > +   bool auto_calib_enabled;
> > > >  };
> > > >
> > > >  struct qcom_wled {
> > > > @@ -108,18 +112,25 @@ struct qcom_wled {
> > > > struct mutex lock;
> > > > struct qcom_wled_config cfg;
> > > > ktime_t last_sc_event_time;
> > > > +   ktime_t start_ovp_fault_time;
> > > > u16 sink_addr;
> > > > u16 ctrl_addr;
> > > > +   u16 auto_calibration_ovp_count;
> > > > u32 brightness;
> > > > u32 sc_count;
> > > > bool prev_state;
> > > > bool ovp_irq_disabled;
> > > > +   bool auto_calib_done;
> > > > +   

Re: [PATCH V1 4/4] qcom: spmi-wled: Add auto-calibration logic support

[kgunda]

On 2018-04-20 11:13, kgu...@codeaurora.org wrote:

On 2018-04-19 21:28, Bjorn Andersson wrote:

On Thu 19 Apr 03:45 PDT 2018, kgu...@codeaurora.org wrote:



On 2017-12-05 11:10, Bjorn Andersson wrote:
> On Thu 16 Nov 04:18 PST 2017, Kiran Gunda wrote:
>
> > The auto-calibration algorithm checks if the current WLED sink
> > configuration is valid. It tries enabling every sink and checks
> > if the OVP fault is observed. Based on this information it
> > detects and enables the valid sink configuration. Auto calibration
> > will be triggered when the OVP fault interrupts are seen frequently
> > thereby it tries to fix the sink configuration.
> >
>
> So it's not auto "calibration" it's auto "detection" of strings?
>
Hi Bjorn,
Sorry for late response. Please find my answers.



No worries, happy to hear back from you!


Thanks!

Correct. This is the auto detection, This is the name given by the
HW/systems team.


I think the name should be considered a "hardware bug", that we can 
work
around in software (give it a useful name and document what the 
original

name was).


I don't think this is the "hardware bug". Rather we can say HW doesn't
support it.
Hence, we are implementing it as a SW feature to detect the strings
present on the
display panel, if the user fails to give the correct strings. As you
suggested I will
rename this to "auto detection" instead of "auto calibration".


> When is this feature needed?
>
This feature is needed if the string configuration is given wrong in
the DT node by the user.


DT describes the hardware and for all other nodes it must do so
accurately.

But the user may not be aware of the strings present on the display 
panel or
may be using the same software on different devices which have 
different strings

present.
For cases where the hardware supports auto detection of functionality 
we

remove information from DT and rely on that logic to figure out the
hardware. We do not use it to reconfigure the hardware once we detect 
an

error. So when auto-detection is enabled it should always be used to
probe the hardware.

The auto string detection is not supported in any qcom hardware and i 
don't

think there is a plan to introduce in new hardware also.


Regards,
Bjorn


> > Signed-off-by: Kiran Gunda 
> > ---
> >  .../bindings/leds/backlight/qcom-spmi-wled.txt |   5 +
> >  drivers/video/backlight/qcom-spmi-wled.c   | 304
> > -
> >  2 files changed, 306 insertions(+), 3 deletions(-)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
> > b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
> > index d39ee93..f06c0cd 100644
> > ---
> > a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
> > +++
> > b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
> > @@ -94,6 +94,11 @@ The PMIC is connected to the host processor via
> > SPMI bus.
> >   Definition: Interrupt names associated with the interrupts.
> >   Currently supported interrupts are "sc-irq" and "ovp-irq".
> >
> > +- qcom,auto-calibration
>
> qcom,auto-string-detect?
>
ok. Will address in the next patch.
> > + Usage:  optional
> > + Value type: 
> > + Definition: Enables auto-calibration of the WLED sink configuration.
> > +
> >  Example:
> >
> >  qcom-wled@d800 {
> > diff --git a/drivers/video/backlight/qcom-spmi-wled.c
> > b/drivers/video/backlight/qcom-spmi-wled.c
> > index 8b2a77a..aee5c56 100644
> > --- a/drivers/video/backlight/qcom-spmi-wled.c
> > +++ b/drivers/video/backlight/qcom-spmi-wled.c
> > @@ -38,11 +38,14 @@
> >  #define  QCOM_WLED_CTRL_SC_FAULT_BIT BIT(2)
> >
> >  #define QCOM_WLED_CTRL_INT_RT_STS0x10
> > +#define  QCOM_WLED_CTRL_OVP_FLT_RT_STS_BIT   BIT(1)
>
> The use of BIT() makes this a mask and not a bit number, so if you just
> drop that you can afford to spell out the "FAULT" like the data sheet
> does. Perhaps even making it QCOM_WLED_CTRL_OVP_FAULT_STATUS ?
>
ok. Will change it in the next series.
> >
> >  #define QCOM_WLED_CTRL_MOD_ENABLE0x46
> >  #define  QCOM_WLED_CTRL_MOD_EN_MASK  BIT(7)
> >  #define  QCOM_WLED_CTRL_MODULE_EN_SHIFT  7
> >
> > +#define QCOM_WLED_CTRL_FDBK_OP   0x48
>
> This is called WLED_CTRL_FEEDBACK_CONTROL, why the need to make it
> unreadable?
>
Ok. Will address it in next series.
> > +
> >  #define QCOM_WLED_CTRL_SWITCH_FREQ   0x4c
> >  #define  QCOM_WLED_CTRL_SWITCH_FREQ_MASK GENMASK(3, 0)
> >
> > @@ -99,6 +102,7 @@ struct qcom_wled_config {
> >   int ovp_irq;
> >   bool en_cabc;
> >   bool ext_pfet_sc_pro_en;
> > + bool auto_calib_enabled;
> >  };
> >
> >  struct qcom_wled {
> > @@ -108,18 +112,25 @@ struct qcom_wled {
> >   struct mutex lock;
> >   struct qcom_wled_config cfg;
> >   ktime_t last_sc_event_time;
> > + ktime_t start_ovp_fault_time;
> >   u16 sink_addr;
> 

Re: [PATCH V1 4/4] qcom: spmi-wled: Add auto-calibration logic support

[kgunda]

On 2018-04-20 11:13, kgu...@codeaurora.org wrote:

On 2018-04-19 21:28, Bjorn Andersson wrote:

On Thu 19 Apr 03:45 PDT 2018, kgu...@codeaurora.org wrote:



On 2017-12-05 11:10, Bjorn Andersson wrote:
> On Thu 16 Nov 04:18 PST 2017, Kiran Gunda wrote:
>
> > The auto-calibration algorithm checks if the current WLED sink
> > configuration is valid. It tries enabling every sink and checks
> > if the OVP fault is observed. Based on this information it
> > detects and enables the valid sink configuration. Auto calibration
> > will be triggered when the OVP fault interrupts are seen frequently
> > thereby it tries to fix the sink configuration.
> >
>
> So it's not auto "calibration" it's auto "detection" of strings?
>
Hi Bjorn,
Sorry for late response. Please find my answers.



No worries, happy to hear back from you!


Thanks!

Correct. This is the auto detection, This is the name given by the
HW/systems team.


I think the name should be considered a "hardware bug", that we can 
work
around in software (give it a useful name and document what the 
original

name was).


I don't think this is the "hardware bug". Rather we can say HW doesn't
support it.
Hence, we are implementing it as a SW feature to detect the strings
present on the
display panel, if the user fails to give the correct strings. As you
suggested I will
rename this to "auto detection" instead of "auto calibration".


> When is this feature needed?
>
This feature is needed if the string configuration is given wrong in
the DT node by the user.


DT describes the hardware and for all other nodes it must do so
accurately.

But the user may not be aware of the strings present on the display 
panel or
may be using the same software on different devices which have 
different strings

present.
For cases where the hardware supports auto detection of functionality 
we

remove information from DT and rely on that logic to figure out the
hardware. We do not use it to reconfigure the hardware once we detect 
an

error. So when auto-detection is enabled it should always be used to
probe the hardware.

The auto string detection is not supported in any qcom hardware and i 
don't

think there is a plan to introduce in new hardware also.


Regards,
Bjorn


> > Signed-off-by: Kiran Gunda 
> > ---
> >  .../bindings/leds/backlight/qcom-spmi-wled.txt |   5 +
> >  drivers/video/backlight/qcom-spmi-wled.c   | 304
> > -
> >  2 files changed, 306 insertions(+), 3 deletions(-)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
> > b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
> > index d39ee93..f06c0cd 100644
> > ---
> > a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
> > +++
> > b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
> > @@ -94,6 +94,11 @@ The PMIC is connected to the host processor via
> > SPMI bus.
> >   Definition: Interrupt names associated with the interrupts.
> >   Currently supported interrupts are "sc-irq" and "ovp-irq".
> >
> > +- qcom,auto-calibration
>
> qcom,auto-string-detect?
>
ok. Will address in the next patch.
> > + Usage:  optional
> > + Value type: 
> > + Definition: Enables auto-calibration of the WLED sink configuration.
> > +
> >  Example:
> >
> >  qcom-wled@d800 {
> > diff --git a/drivers/video/backlight/qcom-spmi-wled.c
> > b/drivers/video/backlight/qcom-spmi-wled.c
> > index 8b2a77a..aee5c56 100644
> > --- a/drivers/video/backlight/qcom-spmi-wled.c
> > +++ b/drivers/video/backlight/qcom-spmi-wled.c
> > @@ -38,11 +38,14 @@
> >  #define  QCOM_WLED_CTRL_SC_FAULT_BIT BIT(2)
> >
> >  #define QCOM_WLED_CTRL_INT_RT_STS0x10
> > +#define  QCOM_WLED_CTRL_OVP_FLT_RT_STS_BIT   BIT(1)
>
> The use of BIT() makes this a mask and not a bit number, so if you just
> drop that you can afford to spell out the "FAULT" like the data sheet
> does. Perhaps even making it QCOM_WLED_CTRL_OVP_FAULT_STATUS ?
>
ok. Will change it in the next series.
> >
> >  #define QCOM_WLED_CTRL_MOD_ENABLE0x46
> >  #define  QCOM_WLED_CTRL_MOD_EN_MASK  BIT(7)
> >  #define  QCOM_WLED_CTRL_MODULE_EN_SHIFT  7
> >
> > +#define QCOM_WLED_CTRL_FDBK_OP   0x48
>
> This is called WLED_CTRL_FEEDBACK_CONTROL, why the need to make it
> unreadable?
>
Ok. Will address it in next series.
> > +
> >  #define QCOM_WLED_CTRL_SWITCH_FREQ   0x4c
> >  #define  QCOM_WLED_CTRL_SWITCH_FREQ_MASK GENMASK(3, 0)
> >
> > @@ -99,6 +102,7 @@ struct qcom_wled_config {
> >   int ovp_irq;
> >   bool en_cabc;
> >   bool ext_pfet_sc_pro_en;
> > + bool auto_calib_enabled;
> >  };
> >
> >  struct qcom_wled {
> > @@ -108,18 +112,25 @@ struct qcom_wled {
> >   struct mutex lock;
> >   struct qcom_wled_config cfg;
> >   ktime_t last_sc_event_time;
> > + ktime_t start_ovp_fault_time;
> >   u16 sink_addr;
> >   u16 ctrl_addr;

Re: [PATCH V1 4/4] qcom: spmi-wled: Add auto-calibration logic support

[kgunda]

On 2018-04-19 21:28, Bjorn Andersson wrote:

On Thu 19 Apr 03:45 PDT 2018, kgu...@codeaurora.org wrote:



On 2017-12-05 11:10, Bjorn Andersson wrote:
> On Thu 16 Nov 04:18 PST 2017, Kiran Gunda wrote:
>
> > The auto-calibration algorithm checks if the current WLED sink
> > configuration is valid. It tries enabling every sink and checks
> > if the OVP fault is observed. Based on this information it
> > detects and enables the valid sink configuration. Auto calibration
> > will be triggered when the OVP fault interrupts are seen frequently
> > thereby it tries to fix the sink configuration.
> >
>
> So it's not auto "calibration" it's auto "detection" of strings?
>
Hi Bjorn,
Sorry for late response. Please find my answers.



No worries, happy to hear back from you!


Thanks!

Correct. This is the auto detection, This is the name given by the
HW/systems team.


I think the name should be considered a "hardware bug", that we can 
work
around in software (give it a useful name and document what the 
original

name was).

I don't think this is the "hardware bug". Rather we can say HW doesn't 
support it.
Hence, we are implementing it as a SW feature to detect the strings 
present on the
display panel, if the user fails to give the correct strings. As you 
suggested I will

rename this to "auto detection" instead of "auto calibration".


> When is this feature needed?
>
This feature is needed if the string configuration is given wrong in
the DT node by the user.


DT describes the hardware and for all other nodes it must do so
accurately.

But the user may not be aware of the strings present on the display 
panel or
may be using the same software on different devices which have different 
strings

present.
For cases where the hardware supports auto detection of functionality 
we

remove information from DT and rely on that logic to figure out the
hardware. We do not use it to reconfigure the hardware once we detect 
an

error. So when auto-detection is enabled it should always be used to
probe the hardware.

The auto string detection is not supported in any qcom hardware and i 
don't

think there is a plan to introduce in new hardware also.


Regards,
Bjorn


> > Signed-off-by: Kiran Gunda 
> > ---
> >  .../bindings/leds/backlight/qcom-spmi-wled.txt |   5 +
> >  drivers/video/backlight/qcom-spmi-wled.c   | 304
> > -
> >  2 files changed, 306 insertions(+), 3 deletions(-)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
> > b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
> > index d39ee93..f06c0cd 100644
> > ---
> > a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
> > +++
> > b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
> > @@ -94,6 +94,11 @@ The PMIC is connected to the host processor via
> > SPMI bus.
> >   Definition: Interrupt names associated with the interrupts.
> >   Currently supported interrupts are "sc-irq" and "ovp-irq".
> >
> > +- qcom,auto-calibration
>
> qcom,auto-string-detect?
>
ok. Will address in the next patch.
> > + Usage:  optional
> > + Value type: 
> > + Definition: Enables auto-calibration of the WLED sink configuration.
> > +
> >  Example:
> >
> >  qcom-wled@d800 {
> > diff --git a/drivers/video/backlight/qcom-spmi-wled.c
> > b/drivers/video/backlight/qcom-spmi-wled.c
> > index 8b2a77a..aee5c56 100644
> > --- a/drivers/video/backlight/qcom-spmi-wled.c
> > +++ b/drivers/video/backlight/qcom-spmi-wled.c
> > @@ -38,11 +38,14 @@
> >  #define  QCOM_WLED_CTRL_SC_FAULT_BIT BIT(2)
> >
> >  #define QCOM_WLED_CTRL_INT_RT_STS0x10
> > +#define  QCOM_WLED_CTRL_OVP_FLT_RT_STS_BIT   BIT(1)
>
> The use of BIT() makes this a mask and not a bit number, so if you just
> drop that you can afford to spell out the "FAULT" like the data sheet
> does. Perhaps even making it QCOM_WLED_CTRL_OVP_FAULT_STATUS ?
>
ok. Will change it in the next series.
> >
> >  #define QCOM_WLED_CTRL_MOD_ENABLE0x46
> >  #define  QCOM_WLED_CTRL_MOD_EN_MASK  BIT(7)
> >  #define  QCOM_WLED_CTRL_MODULE_EN_SHIFT  7
> >
> > +#define QCOM_WLED_CTRL_FDBK_OP   0x48
>
> This is called WLED_CTRL_FEEDBACK_CONTROL, why the need to make it
> unreadable?
>
Ok. Will address it in next series.
> > +
> >  #define QCOM_WLED_CTRL_SWITCH_FREQ   0x4c
> >  #define  QCOM_WLED_CTRL_SWITCH_FREQ_MASK GENMASK(3, 0)
> >
> > @@ -99,6 +102,7 @@ struct qcom_wled_config {
> >   int ovp_irq;
> >   bool en_cabc;
> >   bool ext_pfet_sc_pro_en;
> > + bool auto_calib_enabled;
> >  };
> >
> >  struct qcom_wled {
> > @@ -108,18 +112,25 @@ struct qcom_wled {
> >   struct mutex lock;
> >   struct qcom_wled_config cfg;
> >   ktime_t last_sc_event_time;
> > + ktime_t start_ovp_fault_time;
> >   u16 sink_addr;
> >   u16 ctrl_addr;
> > + u16 

Re: [PATCH V1 4/4] qcom: spmi-wled: Add auto-calibration logic support

[kgunda]

On 2018-04-19 21:28, Bjorn Andersson wrote:

On Thu 19 Apr 03:45 PDT 2018, kgu...@codeaurora.org wrote:



On 2017-12-05 11:10, Bjorn Andersson wrote:
> On Thu 16 Nov 04:18 PST 2017, Kiran Gunda wrote:
>
> > The auto-calibration algorithm checks if the current WLED sink
> > configuration is valid. It tries enabling every sink and checks
> > if the OVP fault is observed. Based on this information it
> > detects and enables the valid sink configuration. Auto calibration
> > will be triggered when the OVP fault interrupts are seen frequently
> > thereby it tries to fix the sink configuration.
> >
>
> So it's not auto "calibration" it's auto "detection" of strings?
>
Hi Bjorn,
Sorry for late response. Please find my answers.



No worries, happy to hear back from you!


Thanks!

Correct. This is the auto detection, This is the name given by the
HW/systems team.


I think the name should be considered a "hardware bug", that we can 
work
around in software (give it a useful name and document what the 
original

name was).

I don't think this is the "hardware bug". Rather we can say HW doesn't 
support it.
Hence, we are implementing it as a SW feature to detect the strings 
present on the
display panel, if the user fails to give the correct strings. As you 
suggested I will

rename this to "auto detection" instead of "auto calibration".


> When is this feature needed?
>
This feature is needed if the string configuration is given wrong in
the DT node by the user.


DT describes the hardware and for all other nodes it must do so
accurately.

But the user may not be aware of the strings present on the display 
panel or
may be using the same software on different devices which have different 
strings

present.
For cases where the hardware supports auto detection of functionality 
we

remove information from DT and rely on that logic to figure out the
hardware. We do not use it to reconfigure the hardware once we detect 
an

error. So when auto-detection is enabled it should always be used to
probe the hardware.

The auto string detection is not supported in any qcom hardware and i 
don't

think there is a plan to introduce in new hardware also.


Regards,
Bjorn


> > Signed-off-by: Kiran Gunda 
> > ---
> >  .../bindings/leds/backlight/qcom-spmi-wled.txt |   5 +
> >  drivers/video/backlight/qcom-spmi-wled.c   | 304
> > -
> >  2 files changed, 306 insertions(+), 3 deletions(-)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
> > b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
> > index d39ee93..f06c0cd 100644
> > ---
> > a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
> > +++
> > b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
> > @@ -94,6 +94,11 @@ The PMIC is connected to the host processor via
> > SPMI bus.
> >   Definition: Interrupt names associated with the interrupts.
> >   Currently supported interrupts are "sc-irq" and "ovp-irq".
> >
> > +- qcom,auto-calibration
>
> qcom,auto-string-detect?
>
ok. Will address in the next patch.
> > + Usage:  optional
> > + Value type: 
> > + Definition: Enables auto-calibration of the WLED sink configuration.
> > +
> >  Example:
> >
> >  qcom-wled@d800 {
> > diff --git a/drivers/video/backlight/qcom-spmi-wled.c
> > b/drivers/video/backlight/qcom-spmi-wled.c
> > index 8b2a77a..aee5c56 100644
> > --- a/drivers/video/backlight/qcom-spmi-wled.c
> > +++ b/drivers/video/backlight/qcom-spmi-wled.c
> > @@ -38,11 +38,14 @@
> >  #define  QCOM_WLED_CTRL_SC_FAULT_BIT BIT(2)
> >
> >  #define QCOM_WLED_CTRL_INT_RT_STS0x10
> > +#define  QCOM_WLED_CTRL_OVP_FLT_RT_STS_BIT   BIT(1)
>
> The use of BIT() makes this a mask and not a bit number, so if you just
> drop that you can afford to spell out the "FAULT" like the data sheet
> does. Perhaps even making it QCOM_WLED_CTRL_OVP_FAULT_STATUS ?
>
ok. Will change it in the next series.
> >
> >  #define QCOM_WLED_CTRL_MOD_ENABLE0x46
> >  #define  QCOM_WLED_CTRL_MOD_EN_MASK  BIT(7)
> >  #define  QCOM_WLED_CTRL_MODULE_EN_SHIFT  7
> >
> > +#define QCOM_WLED_CTRL_FDBK_OP   0x48
>
> This is called WLED_CTRL_FEEDBACK_CONTROL, why the need to make it
> unreadable?
>
Ok. Will address it in next series.
> > +
> >  #define QCOM_WLED_CTRL_SWITCH_FREQ   0x4c
> >  #define  QCOM_WLED_CTRL_SWITCH_FREQ_MASK GENMASK(3, 0)
> >
> > @@ -99,6 +102,7 @@ struct qcom_wled_config {
> >   int ovp_irq;
> >   bool en_cabc;
> >   bool ext_pfet_sc_pro_en;
> > + bool auto_calib_enabled;
> >  };
> >
> >  struct qcom_wled {
> > @@ -108,18 +112,25 @@ struct qcom_wled {
> >   struct mutex lock;
> >   struct qcom_wled_config cfg;
> >   ktime_t last_sc_event_time;
> > + ktime_t start_ovp_fault_time;
> >   u16 sink_addr;
> >   u16 ctrl_addr;
> > + u16 auto_calibration_ovp_count;
> >   

Re: [PATCH V1 4/4] qcom: spmi-wled: Add auto-calibration logic support

[kgunda]

On 2017-12-05 11:10, Bjorn Andersson wrote:

On Thu 16 Nov 04:18 PST 2017, Kiran Gunda wrote:


The auto-calibration algorithm checks if the current WLED sink
configuration is valid. It tries enabling every sink and checks
if the OVP fault is observed. Based on this information it
detects and enables the valid sink configuration. Auto calibration
will be triggered when the OVP fault interrupts are seen frequently
thereby it tries to fix the sink configuration.



So it's not auto "calibration" it's auto "detection" of strings?


Hi Bjorn,
Sorry for late response. Please find my answers.

Correct. This is the auto detection, This is the name given by the 
HW/systems team.

When is this feature needed?

This feature is needed if the string configuration is given wrong in the 
DT node by the

user.

Signed-off-by: Kiran Gunda 
---
 .../bindings/leds/backlight/qcom-spmi-wled.txt |   5 +
 drivers/video/backlight/qcom-spmi-wled.c   | 304 
-

 2 files changed, 306 insertions(+), 3 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt 
b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt

index d39ee93..f06c0cd 100644
--- 
a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
+++ 
b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
@@ -94,6 +94,11 @@ The PMIC is connected to the host processor via 
SPMI bus.

Definition: Interrupt names associated with the interrupts.
Currently supported interrupts are "sc-irq" and "ovp-irq".

+- qcom,auto-calibration


qcom,auto-string-detect?


ok. Will address in the next patch.

+   Usage:  optional
+   Value type: 
+   Definition: Enables auto-calibration of the WLED sink configuration.
+
 Example:

 qcom-wled@d800 {
diff --git a/drivers/video/backlight/qcom-spmi-wled.c 
b/drivers/video/backlight/qcom-spmi-wled.c

index 8b2a77a..aee5c56 100644
--- a/drivers/video/backlight/qcom-spmi-wled.c
+++ b/drivers/video/backlight/qcom-spmi-wled.c
@@ -38,11 +38,14 @@
 #define  QCOM_WLED_CTRL_SC_FAULT_BIT   BIT(2)

 #define QCOM_WLED_CTRL_INT_RT_STS  0x10
+#define  QCOM_WLED_CTRL_OVP_FLT_RT_STS_BIT BIT(1)


The use of BIT() makes this a mask and not a bit number, so if you just
drop that you can afford to spell out the "FAULT" like the data sheet
does. Perhaps even making it QCOM_WLED_CTRL_OVP_FAULT_STATUS ?


ok. Will change it in the next series.


 #define QCOM_WLED_CTRL_MOD_ENABLE  0x46
 #define  QCOM_WLED_CTRL_MOD_EN_MASKBIT(7)
 #define  QCOM_WLED_CTRL_MODULE_EN_SHIFT7

+#define QCOM_WLED_CTRL_FDBK_OP 0x48


This is called WLED_CTRL_FEEDBACK_CONTROL, why the need to make it
unreadable?


Ok. Will address it in next series.

+
 #define QCOM_WLED_CTRL_SWITCH_FREQ 0x4c
 #define  QCOM_WLED_CTRL_SWITCH_FREQ_MASK   GENMASK(3, 0)

@@ -99,6 +102,7 @@ struct qcom_wled_config {
int ovp_irq;
bool en_cabc;
bool ext_pfet_sc_pro_en;
+   bool auto_calib_enabled;
 };

 struct qcom_wled {
@@ -108,18 +112,25 @@ struct qcom_wled {
struct mutex lock;
struct qcom_wled_config cfg;
ktime_t last_sc_event_time;
+   ktime_t start_ovp_fault_time;
u16 sink_addr;
u16 ctrl_addr;
+   u16 auto_calibration_ovp_count;
u32 brightness;
u32 sc_count;
bool prev_state;
bool ovp_irq_disabled;
+   bool auto_calib_done;
+   bool force_mod_disable;
 };

 static int qcom_wled_module_enable(struct qcom_wled *wled, int val)
 {
int rc;

+   if (wled->force_mod_disable)
+   return 0;
+
rc = regmap_update_bits(wled->regmap, wled->ctrl_addr +
QCOM_WLED_CTRL_MOD_ENABLE, QCOM_WLED_CTRL_MOD_EN_MASK,
val << QCOM_WLED_CTRL_MODULE_EN_SHIFT);
@@ -187,12 +198,10 @@ static int qcom_wled_set_brightness(struct 
qcom_wled *wled, u16 brightness)

v[1] = (brightness >> 8) & 0xf;

for (i = 0; (string_cfg >> i) != 0; i++) {
-   if (string_cfg & BIT(i)) {


Why was this check here in the first place, if it's now fine to
configure the brightness of all strings?

Also, a single-string config of 0b0001 will only set brightness on the
first string, while 0b1000 will set brightness on all strings.


I will correct/remove it next series.

rc = regmap_bulk_write(wled->regmap, wled->sink_addr +
QCOM_WLED_SINK_BRIGHT_LSB_REG(i), v, 2);
if (rc < 0)
return rc;
-   }
}

return 0;
@@ -294,6 +303,262 @@ static irqreturn_t qcom_wled_sc_irq_handler(int 
irq, void *_wled)

return IRQ_HANDLED;
 }

+#define AUTO_CALIB_BRIGHTNESS  200
+static int qcom_wled_auto_calibrate(struct qcom_wled *wled)
+{
+ 

Re: [PATCH V1 4/4] qcom: spmi-wled: Add auto-calibration logic support

[kgunda]

On 2017-12-05 11:10, Bjorn Andersson wrote:

On Thu 16 Nov 04:18 PST 2017, Kiran Gunda wrote:


The auto-calibration algorithm checks if the current WLED sink
configuration is valid. It tries enabling every sink and checks
if the OVP fault is observed. Based on this information it
detects and enables the valid sink configuration. Auto calibration
will be triggered when the OVP fault interrupts are seen frequently
thereby it tries to fix the sink configuration.



So it's not auto "calibration" it's auto "detection" of strings?


Hi Bjorn,
Sorry for late response. Please find my answers.

Correct. This is the auto detection, This is the name given by the 
HW/systems team.

When is this feature needed?

This feature is needed if the string configuration is given wrong in the 
DT node by the

user.

Signed-off-by: Kiran Gunda 
---
 .../bindings/leds/backlight/qcom-spmi-wled.txt |   5 +
 drivers/video/backlight/qcom-spmi-wled.c   | 304 
-

 2 files changed, 306 insertions(+), 3 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt 
b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt

index d39ee93..f06c0cd 100644
--- 
a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
+++ 
b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
@@ -94,6 +94,11 @@ The PMIC is connected to the host processor via 
SPMI bus.

Definition: Interrupt names associated with the interrupts.
Currently supported interrupts are "sc-irq" and "ovp-irq".

+- qcom,auto-calibration


qcom,auto-string-detect?


ok. Will address in the next patch.

+   Usage:  optional
+   Value type: 
+   Definition: Enables auto-calibration of the WLED sink configuration.
+
 Example:

 qcom-wled@d800 {
diff --git a/drivers/video/backlight/qcom-spmi-wled.c 
b/drivers/video/backlight/qcom-spmi-wled.c

index 8b2a77a..aee5c56 100644
--- a/drivers/video/backlight/qcom-spmi-wled.c
+++ b/drivers/video/backlight/qcom-spmi-wled.c
@@ -38,11 +38,14 @@
 #define  QCOM_WLED_CTRL_SC_FAULT_BIT   BIT(2)

 #define QCOM_WLED_CTRL_INT_RT_STS  0x10
+#define  QCOM_WLED_CTRL_OVP_FLT_RT_STS_BIT BIT(1)


The use of BIT() makes this a mask and not a bit number, so if you just
drop that you can afford to spell out the "FAULT" like the data sheet
does. Perhaps even making it QCOM_WLED_CTRL_OVP_FAULT_STATUS ?


ok. Will change it in the next series.


 #define QCOM_WLED_CTRL_MOD_ENABLE  0x46
 #define  QCOM_WLED_CTRL_MOD_EN_MASKBIT(7)
 #define  QCOM_WLED_CTRL_MODULE_EN_SHIFT7

+#define QCOM_WLED_CTRL_FDBK_OP 0x48


This is called WLED_CTRL_FEEDBACK_CONTROL, why the need to make it
unreadable?


Ok. Will address it in next series.

+
 #define QCOM_WLED_CTRL_SWITCH_FREQ 0x4c
 #define  QCOM_WLED_CTRL_SWITCH_FREQ_MASK   GENMASK(3, 0)

@@ -99,6 +102,7 @@ struct qcom_wled_config {
int ovp_irq;
bool en_cabc;
bool ext_pfet_sc_pro_en;
+   bool auto_calib_enabled;
 };

 struct qcom_wled {
@@ -108,18 +112,25 @@ struct qcom_wled {
struct mutex lock;
struct qcom_wled_config cfg;
ktime_t last_sc_event_time;
+   ktime_t start_ovp_fault_time;
u16 sink_addr;
u16 ctrl_addr;
+   u16 auto_calibration_ovp_count;
u32 brightness;
u32 sc_count;
bool prev_state;
bool ovp_irq_disabled;
+   bool auto_calib_done;
+   bool force_mod_disable;
 };

 static int qcom_wled_module_enable(struct qcom_wled *wled, int val)
 {
int rc;

+   if (wled->force_mod_disable)
+   return 0;
+
rc = regmap_update_bits(wled->regmap, wled->ctrl_addr +
QCOM_WLED_CTRL_MOD_ENABLE, QCOM_WLED_CTRL_MOD_EN_MASK,
val << QCOM_WLED_CTRL_MODULE_EN_SHIFT);
@@ -187,12 +198,10 @@ static int qcom_wled_set_brightness(struct 
qcom_wled *wled, u16 brightness)

v[1] = (brightness >> 8) & 0xf;

for (i = 0; (string_cfg >> i) != 0; i++) {
-   if (string_cfg & BIT(i)) {


Why was this check here in the first place, if it's now fine to
configure the brightness of all strings?

Also, a single-string config of 0b0001 will only set brightness on the
first string, while 0b1000 will set brightness on all strings.


I will correct/remove it next series.

rc = regmap_bulk_write(wled->regmap, wled->sink_addr +
QCOM_WLED_SINK_BRIGHT_LSB_REG(i), v, 2);
if (rc < 0)
return rc;
-   }
}

return 0;
@@ -294,6 +303,262 @@ static irqreturn_t qcom_wled_sc_irq_handler(int 
irq, void *_wled)

return IRQ_HANDLED;
 }

+#define AUTO_CALIB_BRIGHTNESS  200
+static int qcom_wled_auto_calibrate(struct qcom_wled *wled)
+{
+   int rc = 0, i;
+ 

Re: [PATCH V1 3/4] qcom: spmi-wled: Add support for OVP interrupt handling

[kgunda]

On 2017-12-05 10:15, Bjorn Andersson wrote:

On Thu 16 Nov 04:18 PST 2017, Kiran Gunda wrote:


WLED peripheral has over voltage protection(OVP) circuitry and the OVP
fault is notified through an interrupt. Though this fault condition 
rising
is due to an incorrect hardware configuration is mitigated in the 
hardware,

it still needs to be detected and handled. Add support for it.

When WLED module is enabled, keep OVP fault interrupt disabled for 10 
ms to

account for soft start delay.

Signed-off-by: Kiran Gunda 
---
 .../bindings/leds/backlight/qcom-spmi-wled.txt |  7 +-
 drivers/video/backlight/qcom-spmi-wled.c   | 83 
++

 2 files changed, 87 insertions(+), 3 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt 
b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt

index 768608c..d39ee93 100644
--- 
a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
+++ 
b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
@@ -92,7 +92,7 @@ The PMIC is connected to the host processor via SPMI 
bus.

Usage:  optional
Value type: 
Definition: Interrupt names associated with the interrupts.
-   Must be "sc-irq".
+   Currently supported interrupts are "sc-irq" and "ovp-irq".



As before, we know this is an IRQ, so omit the -irq from the name.

[..]

Sure. Will change it in the next series.
diff --git a/drivers/video/backlight/qcom-spmi-wled.c 
b/drivers/video/backlight/qcom-spmi-wled.c

[..]
@@ -115,6 +123,28 @@ static int qcom_wled_module_enable(struct 
qcom_wled *wled, int val)

rc = regmap_update_bits(wled->regmap, wled->ctrl_addr +
QCOM_WLED_CTRL_MOD_ENABLE, QCOM_WLED_CTRL_MOD_EN_MASK,
val << QCOM_WLED_CTRL_MODULE_EN_SHIFT);
+   if (rc < 0)
+   return rc;
+   /*
+* Wait for at least 10ms before enabling OVP fault interrupt after
+* enabling the module so that soft start is completed. Keep the OVP
+* interrupt disabled when the module is disabled.
+*/
+   if (val) {
+   usleep_range(QCOM_WLED_SOFT_START_DLY_US,
+   QCOM_WLED_SOFT_START_DLY_US + 1000);


This is sleeping in the brightness/enable code path, can you
schedule_delayed_work() instead to not block this code path
unnecessarily?


Sure. Will change it in the next series.

+
+   if (wled->cfg.ovp_irq > 0 && wled->ovp_irq_disabled) {
+   enable_irq(wled->cfg.ovp_irq);
+   wled->ovp_irq_disabled = false;
+   }
+   } else {
+   if (wled->cfg.ovp_irq > 0 && !wled->ovp_irq_disabled) {
+   disable_irq(wled->cfg.ovp_irq);
+   wled->ovp_irq_disabled = true;
+   }
+   }
+
return rc;
 }

@@ -264,12 +294,42 @@ static irqreturn_t qcom_wled_sc_irq_handler(int 
irq, void *_wled)

return IRQ_HANDLED;
 }

+static irqreturn_t qcom_wled_ovp_irq_handler(int irq, void *_wled)
+{
+   struct qcom_wled *wled = _wled;
+   int rc;
+   u32 int_sts, fault_sts;
+
+   rc = regmap_read(wled->regmap,
+   wled->ctrl_addr + QCOM_WLED_CTRL_INT_RT_STS, _sts);
+   if (rc < 0) {
+   pr_err("Error in reading WLED_INT_RT_STS rc=%d\n", rc);
+   return IRQ_HANDLED;
+   }
+
+   rc = regmap_read(wled->regmap, wled->ctrl_addr +
+   QCOM_WLED_CTRL_FAULT_STATUS, _sts);
+   if (rc < 0) {
+   pr_err("Error in reading WLED_FAULT_STATUS rc=%d\n", rc);
+   return IRQ_HANDLED;
+   }
+
+   if (fault_sts &
+   (QCOM_WLED_CTRL_OVP_FAULT_BIT | QCOM_WLED_CTRL_ILIM_FAULT_BIT))
+   pr_err("WLED OVP fault detected, int_sts=%x fault_sts= %x\n",
+   int_sts, fault_sts);


All this function does is print things to the log. When is this
information consumed and by whom? dev_dbg() instead?


Sure. Will change it in the next series.

+
+   return IRQ_HANDLED;
+}
+
 static int qcom_wled_setup(struct qcom_wled *wled)
 {
int rc, temp, i;
u8 sink_en = 0;
+   u32 val;
u8 string_cfg = wled->cfg.string_cfg;
int sc_irq = wled->cfg.sc_irq;
+   int ovp_irq = wled->cfg.ovp_irq;

rc = regmap_update_bits(wled->regmap,
wled->ctrl_addr + QCOM_WLED_CTRL_OVP,
@@ -367,6 +427,25 @@ static int qcom_wled_setup(struct qcom_wled 
*wled)

}
}

+   if (ovp_irq >= 0) {


As with the previous patch.

[..]

Sure. Will change it in the next series.
@@ -539,6 +618,10 @@ static int qcom_wled_configure(struct qcom_wled 
*wled, struct device *dev)

[..]

+   wled->cfg.ovp_irq = platform_get_irq_byname(wled->pdev, "ovp-irq");
+   if (wled->cfg.ovp_irq < 0)
+   

Re: [PATCH V1 3/4] qcom: spmi-wled: Add support for OVP interrupt handling

[kgunda]

On 2017-12-05 10:15, Bjorn Andersson wrote:

On Thu 16 Nov 04:18 PST 2017, Kiran Gunda wrote:


WLED peripheral has over voltage protection(OVP) circuitry and the OVP
fault is notified through an interrupt. Though this fault condition 
rising
is due to an incorrect hardware configuration is mitigated in the 
hardware,

it still needs to be detected and handled. Add support for it.

When WLED module is enabled, keep OVP fault interrupt disabled for 10 
ms to

account for soft start delay.

Signed-off-by: Kiran Gunda 
---
 .../bindings/leds/backlight/qcom-spmi-wled.txt |  7 +-
 drivers/video/backlight/qcom-spmi-wled.c   | 83 
++

 2 files changed, 87 insertions(+), 3 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt 
b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt

index 768608c..d39ee93 100644
--- 
a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
+++ 
b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
@@ -92,7 +92,7 @@ The PMIC is connected to the host processor via SPMI 
bus.

Usage:  optional
Value type: 
Definition: Interrupt names associated with the interrupts.
-   Must be "sc-irq".
+   Currently supported interrupts are "sc-irq" and "ovp-irq".



As before, we know this is an IRQ, so omit the -irq from the name.

[..]

Sure. Will change it in the next series.
diff --git a/drivers/video/backlight/qcom-spmi-wled.c 
b/drivers/video/backlight/qcom-spmi-wled.c

[..]
@@ -115,6 +123,28 @@ static int qcom_wled_module_enable(struct 
qcom_wled *wled, int val)

rc = regmap_update_bits(wled->regmap, wled->ctrl_addr +
QCOM_WLED_CTRL_MOD_ENABLE, QCOM_WLED_CTRL_MOD_EN_MASK,
val << QCOM_WLED_CTRL_MODULE_EN_SHIFT);
+   if (rc < 0)
+   return rc;
+   /*
+* Wait for at least 10ms before enabling OVP fault interrupt after
+* enabling the module so that soft start is completed. Keep the OVP
+* interrupt disabled when the module is disabled.
+*/
+   if (val) {
+   usleep_range(QCOM_WLED_SOFT_START_DLY_US,
+   QCOM_WLED_SOFT_START_DLY_US + 1000);


This is sleeping in the brightness/enable code path, can you
schedule_delayed_work() instead to not block this code path
unnecessarily?


Sure. Will change it in the next series.

+
+   if (wled->cfg.ovp_irq > 0 && wled->ovp_irq_disabled) {
+   enable_irq(wled->cfg.ovp_irq);
+   wled->ovp_irq_disabled = false;
+   }
+   } else {
+   if (wled->cfg.ovp_irq > 0 && !wled->ovp_irq_disabled) {
+   disable_irq(wled->cfg.ovp_irq);
+   wled->ovp_irq_disabled = true;
+   }
+   }
+
return rc;
 }

@@ -264,12 +294,42 @@ static irqreturn_t qcom_wled_sc_irq_handler(int 
irq, void *_wled)

return IRQ_HANDLED;
 }

+static irqreturn_t qcom_wled_ovp_irq_handler(int irq, void *_wled)
+{
+   struct qcom_wled *wled = _wled;
+   int rc;
+   u32 int_sts, fault_sts;
+
+   rc = regmap_read(wled->regmap,
+   wled->ctrl_addr + QCOM_WLED_CTRL_INT_RT_STS, _sts);
+   if (rc < 0) {
+   pr_err("Error in reading WLED_INT_RT_STS rc=%d\n", rc);
+   return IRQ_HANDLED;
+   }
+
+   rc = regmap_read(wled->regmap, wled->ctrl_addr +
+   QCOM_WLED_CTRL_FAULT_STATUS, _sts);
+   if (rc < 0) {
+   pr_err("Error in reading WLED_FAULT_STATUS rc=%d\n", rc);
+   return IRQ_HANDLED;
+   }
+
+   if (fault_sts &
+   (QCOM_WLED_CTRL_OVP_FAULT_BIT | QCOM_WLED_CTRL_ILIM_FAULT_BIT))
+   pr_err("WLED OVP fault detected, int_sts=%x fault_sts= %x\n",
+   int_sts, fault_sts);


All this function does is print things to the log. When is this
information consumed and by whom? dev_dbg() instead?


Sure. Will change it in the next series.

+
+   return IRQ_HANDLED;
+}
+
 static int qcom_wled_setup(struct qcom_wled *wled)
 {
int rc, temp, i;
u8 sink_en = 0;
+   u32 val;
u8 string_cfg = wled->cfg.string_cfg;
int sc_irq = wled->cfg.sc_irq;
+   int ovp_irq = wled->cfg.ovp_irq;

rc = regmap_update_bits(wled->regmap,
wled->ctrl_addr + QCOM_WLED_CTRL_OVP,
@@ -367,6 +427,25 @@ static int qcom_wled_setup(struct qcom_wled 
*wled)

}
}

+   if (ovp_irq >= 0) {


As with the previous patch.

[..]

Sure. Will change it in the next series.
@@ -539,6 +618,10 @@ static int qcom_wled_configure(struct qcom_wled 
*wled, struct device *dev)

[..]

+   wled->cfg.ovp_irq = platform_get_irq_byname(wled->pdev, "ovp-irq");
+   if (wled->cfg.ovp_irq < 0)
+   dev_dbg(>pdev->dev, 

Re: [PATCH V1 2/4] qcom: spmi-wled: Add support for short circuit handling

[kgunda]

On 2017-12-05 10:05, Bjorn Andersson wrote:

On Thu 16 Nov 04:18 PST 2017, Kiran Gunda wrote:


Handle the short circuit(SC) interrupt and check if the SC interrupt
is valid. Re-enable the module to check if it goes away. Disable the
module altogether if the SC event persists.

Signed-off-by: Kiran Gunda 
---
 .../bindings/leds/backlight/qcom-spmi-wled.txt |  22 
 drivers/video/backlight/qcom-spmi-wled.c   | 126 
-

 2 files changed, 142 insertions(+), 6 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt 
b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt

index f1ea25b..768608c 100644
--- 
a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
+++ 
b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
@@ -74,6 +74,26 @@ The PMIC is connected to the host processor via 
SPMI bus.

Definition: Specify if cabc (content adaptive backlight control) is
needed.

+- qcom,ext-pfet-sc-pro-en


Please use readable names, rather than a bunch of abbreviations.


Ok. Will address it in next series.

+   Usage:  optional
+   Value type: 
+   Definition: Specify if external PFET control for short circuit
+   protection is needed.


What does this mean? At least change the wording to "...protection is
used".


Ok. Will address it in next series.

+
+- interrupts
+   Usage:  optional
+   Value type: 
+   Definition: Interrupts associated with WLED. Interrupts can be
+   specified as per the encoding listed under
+   Documentation/devicetree/bindings/spmi/
+   qcom,spmi-pmic-arb.txt.
+
+- interrupt-names
+   Usage:  optional
+   Value type: 
+   Definition: Interrupt names associated with the interrupts.
+   Must be "sc-irq".


This is obviously an irq, so no need to include that in the name. I
would also prefer if you use the name "short" to make this easier to
read.


Ok. Will address it in next series.

+
 Example:

 qcom-wled@d800 {
@@ -82,6 +102,8 @@ qcom-wled@d800 {
reg-names = "qcom-wled-ctrl-base", "qcom-wled-sink-base";
label = "backlight";

+   interrupts = <0x3 0xd8 0x2 IRQ_TYPE_EDGE_RISING>;


We tend to write these on the form , 
please

follow this.


Ok. Will address it in next series.

+   interrupt-names = "sc-irq";
qcom,fs-current-limit = <25000>;
qcom,current-boost-limit = <970>;
qcom,switching-freq = <800>;
diff --git a/drivers/video/backlight/qcom-spmi-wled.c 
b/drivers/video/backlight/qcom-spmi-wled.c

index 14c3adc..7dbaaa7 100644
--- a/drivers/video/backlight/qcom-spmi-wled.c
+++ b/drivers/video/backlight/qcom-spmi-wled.c
@@ -11,6 +11,9 @@
  * GNU General Public License for more details.
  */

+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -23,7 +26,13 @@
 #define QCOM_WLED_DEFAULT_BRIGHTNESS   2048
 #define  QCOM_WLED_MAX_BRIGHTNESS  4095

+#define QCOM_WLED_SC_DLY_MS20
+#define QCOM_WLED_SC_CNT_MAX   5
+#define QCOM_WLED_SC_RESET_CNT_DLY_US  100


With times of this ballpark you can just use jiffies, with this just
being HZ.


Ok. Will address it in next series.

+
 /* WLED control registers */
+#define QCOM_WLED_CTRL_FAULT_STATUS0x08
+
 #define QCOM_WLED_CTRL_MOD_ENABLE  0x46
 #define  QCOM_WLED_CTRL_MOD_EN_MASKBIT(7)
 #define  QCOM_WLED_CTRL_MODULE_EN_SHIFT7
@@ -37,6 +46,15 @@
 #define QCOM_WLED_CTRL_ILIM0x4e
 #define  QCOM_WLED_CTRL_ILIM_MASK  GENMASK(2, 0)

+#define QCOM_WLED_CTRL_SHORT_PROTECT   0x5e
+#define  QCOM_WLED_CTRL_SHORT_EN_MASK  BIT(7)
+
+#define QCOM_WLED_CTRL_SEC_ACCESS  0xd0
+#define  QCOM_WLED_CTRL_SEC_UNLOCK 0xa5
+
+#define QCOM_WLED_CTRL_TEST1   0xe2
+#define  QCOM_WLED_EXT_FET_DTEST2  0x09
+
 /* WLED sink registers */
 #define QCOM_WLED_SINK_CURR_SINK_EN0x46
 #define  QCOM_WLED_SINK_CURR_SINK_MASK GENMASK(7, 4)
@@ -71,19 +89,23 @@ struct qcom_wled_config {
u32 switch_freq;
u32 fs_current;
u32 string_cfg;
+   int sc_irq;


Keep data parsed directly from DT in the config and move this to
qcom_wled.


Ok. Will address it in next series.

bool en_cabc;
+   bool ext_pfet_sc_pro_en;


This name is long and hard to parse. "external_pfet" would be much
easier to read.


Ok. Will address it in next series.

 };

 struct qcom_wled {
const char *name;
struct platform_device *pdev;
struct regmap *regmap;
+   struct mutex lock;
+   struct qcom_wled_config cfg;
+   ktime_t last_sc_event_time;
u16 sink_addr;
u16 ctrl_addr;
u32 brightness;
+   u32 

Re: [PATCH V1 2/4] qcom: spmi-wled: Add support for short circuit handling

[kgunda]

On 2017-12-05 10:05, Bjorn Andersson wrote:

On Thu 16 Nov 04:18 PST 2017, Kiran Gunda wrote:


Handle the short circuit(SC) interrupt and check if the SC interrupt
is valid. Re-enable the module to check if it goes away. Disable the
module altogether if the SC event persists.

Signed-off-by: Kiran Gunda 
---
 .../bindings/leds/backlight/qcom-spmi-wled.txt |  22 
 drivers/video/backlight/qcom-spmi-wled.c   | 126 
-

 2 files changed, 142 insertions(+), 6 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt 
b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt

index f1ea25b..768608c 100644
--- 
a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
+++ 
b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
@@ -74,6 +74,26 @@ The PMIC is connected to the host processor via 
SPMI bus.

Definition: Specify if cabc (content adaptive backlight control) is
needed.

+- qcom,ext-pfet-sc-pro-en


Please use readable names, rather than a bunch of abbreviations.


Ok. Will address it in next series.

+   Usage:  optional
+   Value type: 
+   Definition: Specify if external PFET control for short circuit
+   protection is needed.


What does this mean? At least change the wording to "...protection is
used".


Ok. Will address it in next series.

+
+- interrupts
+   Usage:  optional
+   Value type: 
+   Definition: Interrupts associated with WLED. Interrupts can be
+   specified as per the encoding listed under
+   Documentation/devicetree/bindings/spmi/
+   qcom,spmi-pmic-arb.txt.
+
+- interrupt-names
+   Usage:  optional
+   Value type: 
+   Definition: Interrupt names associated with the interrupts.
+   Must be "sc-irq".


This is obviously an irq, so no need to include that in the name. I
would also prefer if you use the name "short" to make this easier to
read.


Ok. Will address it in next series.

+
 Example:

 qcom-wled@d800 {
@@ -82,6 +102,8 @@ qcom-wled@d800 {
reg-names = "qcom-wled-ctrl-base", "qcom-wled-sink-base";
label = "backlight";

+   interrupts = <0x3 0xd8 0x2 IRQ_TYPE_EDGE_RISING>;


We tend to write these on the form , 
please

follow this.


Ok. Will address it in next series.

+   interrupt-names = "sc-irq";
qcom,fs-current-limit = <25000>;
qcom,current-boost-limit = <970>;
qcom,switching-freq = <800>;
diff --git a/drivers/video/backlight/qcom-spmi-wled.c 
b/drivers/video/backlight/qcom-spmi-wled.c

index 14c3adc..7dbaaa7 100644
--- a/drivers/video/backlight/qcom-spmi-wled.c
+++ b/drivers/video/backlight/qcom-spmi-wled.c
@@ -11,6 +11,9 @@
  * GNU General Public License for more details.
  */

+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -23,7 +26,13 @@
 #define QCOM_WLED_DEFAULT_BRIGHTNESS   2048
 #define  QCOM_WLED_MAX_BRIGHTNESS  4095

+#define QCOM_WLED_SC_DLY_MS20
+#define QCOM_WLED_SC_CNT_MAX   5
+#define QCOM_WLED_SC_RESET_CNT_DLY_US  100


With times of this ballpark you can just use jiffies, with this just
being HZ.


Ok. Will address it in next series.

+
 /* WLED control registers */
+#define QCOM_WLED_CTRL_FAULT_STATUS0x08
+
 #define QCOM_WLED_CTRL_MOD_ENABLE  0x46
 #define  QCOM_WLED_CTRL_MOD_EN_MASKBIT(7)
 #define  QCOM_WLED_CTRL_MODULE_EN_SHIFT7
@@ -37,6 +46,15 @@
 #define QCOM_WLED_CTRL_ILIM0x4e
 #define  QCOM_WLED_CTRL_ILIM_MASK  GENMASK(2, 0)

+#define QCOM_WLED_CTRL_SHORT_PROTECT   0x5e
+#define  QCOM_WLED_CTRL_SHORT_EN_MASK  BIT(7)
+
+#define QCOM_WLED_CTRL_SEC_ACCESS  0xd0
+#define  QCOM_WLED_CTRL_SEC_UNLOCK 0xa5
+
+#define QCOM_WLED_CTRL_TEST1   0xe2
+#define  QCOM_WLED_EXT_FET_DTEST2  0x09
+
 /* WLED sink registers */
 #define QCOM_WLED_SINK_CURR_SINK_EN0x46
 #define  QCOM_WLED_SINK_CURR_SINK_MASK GENMASK(7, 4)
@@ -71,19 +89,23 @@ struct qcom_wled_config {
u32 switch_freq;
u32 fs_current;
u32 string_cfg;
+   int sc_irq;


Keep data parsed directly from DT in the config and move this to
qcom_wled.


Ok. Will address it in next series.

bool en_cabc;
+   bool ext_pfet_sc_pro_en;


This name is long and hard to parse. "external_pfet" would be much
easier to read.


Ok. Will address it in next series.

 };

 struct qcom_wled {
const char *name;
struct platform_device *pdev;
struct regmap *regmap;
+   struct mutex lock;
+   struct qcom_wled_config cfg;
+   ktime_t last_sc_event_time;
u16 sink_addr;
u16 ctrl_addr;
u32 brightness;
+   u32 sc_count;
bool prev_state;
-
-   struct 

Re: [PATCH V1 1/4] qcom: spmi-wled: Add support for qcom wled driver

[kgunda]

On 2017-12-05 07:31, Bjorn Andersson wrote:

On Thu 16 Nov 04:18 PST 2017, Kiran Gunda wrote:


WLED driver provides the interface to the display driver to
adjust the brightness of the display backlight.

Signed-off-by: Kiran Gunda 
---
 .../bindings/leds/backlight/qcom-spmi-wled.txt |  90 
 drivers/video/backlight/Kconfig|   9 +
 drivers/video/backlight/Makefile   |   1 +
 drivers/video/backlight/qcom-spmi-wled.c   | 504 
+

 4 files changed, 604 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt

 create mode 100644 drivers/video/backlight/qcom-spmi-wled.c

diff --git 
a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt 
b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt

new file mode 100644
index 000..f1ea25b
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt

@@ -0,0 +1,90 @@
+Binding for Qualcomm WLED driver
+


This binding document quite well describe the pm8941 as well, so please
improve the existing binding (changing to this style is preferable).

Sure. Will do it in the next series, where I will re-use pm8941 driver 
for

PMI8998 as well.
+WLED (White Light Emitting Diode) driver is used for controlling 
display
+backlight that is part of PMIC on Qualcomm Technologies reference 
platforms.

+The PMIC is connected to the host processor via SPMI bus.
+
+- compatible
+   Usage:  required
+   Value type: 
+   Definition: should be "qcom,pm8998-spmi-wled".


There's no WLED in the pm8998, so please make this pmi8998. This pmic 
is

SPMI only, so there's no need to keep "spmi" in the compatible.


Sure. Will change it.

+
+- reg
+   Usage:  required
+   Value type: 
+   Definition:  Base address and size of the WLED modules.
+
+- reg-names
+   Usage:  required
+   Value type: 
+   Definition:  Names associated with base addresses. should be
+"qcom-wled-ctrl-base", "qcom-wled-sink-base".
+
+- label
+   Usage:  required
+   Value type: 
+   Definition: The name of the backlight device.
+
+- default-brightness
+   Usage:  optional
+   Value type: 
+   Definition: brightness value on boot, value from: 0-4095
+   default: 2048
+
+- qcom,fs-current-limit
+   Usage:  optional
+   Value type: 
+   Definition: per-string full scale current limit in uA. value from
+   0 to 3 with 5000 uA resolution. default: 25000 uA


"in steps of 5mA"


Will address it in next series.

+
+- qcom,current-boost-limit
+   Usage:  optional
+   Value type: 
+	Definition: ILIM threshold in mA. values are 105, 280, 450, 620, 
970,

+   1150, 1300, 1500. default: 970 mA
+
+- qcom,switching-freq
+   Usage:  optional
+   Value type: 
+   Definition: Switching frequency in KHz. values are
+   600, 640, 685, 738, 800, 872, 960, 1066, 1200, 1371,
+   1600, 1920, 2400, 3200, 4800, 9600.
+   default: 800 KHz
+
+- qcom,ovp
+   Usage:  optional
+   Value type: 
+   Definition: Over-voltage protection limit in mV. values are 31100,
+   29600, 19600, 18100.
+   default: 29600 mV
+
+- qcom,string-cfg
+   Usage:  optional
+   Value type: 
+	Definition: Bit mask of the wled strings. Bit 0 to 3 indicates 
strings

+   0 to 3 respectively. Wled module has four strings of leds
+   numbered from 0 to 3. Each string of leds are operated
+   individually. Specify the strings using the bit mask. Any
+   combination of led strings can be used.
+   default value is 15 (b).


Please try to avoid expressing things as bitmasks in DT.

The only difference from 8941 here is that there's one additional
string, so please start off by expressing this as the existing binding.

If you really need this flexibility you can follow up with an addition
of a property like this, but name it something like
"qcom,enabled-strings" and make this support available for pm8941 as
well.


Sure. Will address it.

+
+- qcom,en-cabc


No need for the "en", the presence of a bool property means that it's
enabled.


Will address it in next series.

+   Usage:  optional
+   Value type: 
+   Definition: Specify if cabc (content adaptive backlight control) is
+   needed.


I presume cabc isn't ever "needed", just make the description "Enable
content adaptive backlight control".


Will address it in next series.

+
+Example:
+
+qcom-wled@d800 {
+   compatible = "qcom,pm8998-spmi-wled";
+   reg = <0xd800 0xd900>;
+   reg-names = "qcom-wled-ctrl-base", "qcom-wled-sink-base";
+   label = "backlight";
+
+   qcom,fs-current-limit = 

Re: [PATCH V1 1/4] qcom: spmi-wled: Add support for qcom wled driver

[kgunda]

On 2017-12-05 07:31, Bjorn Andersson wrote:

On Thu 16 Nov 04:18 PST 2017, Kiran Gunda wrote:


WLED driver provides the interface to the display driver to
adjust the brightness of the display backlight.

Signed-off-by: Kiran Gunda 
---
 .../bindings/leds/backlight/qcom-spmi-wled.txt |  90 
 drivers/video/backlight/Kconfig|   9 +
 drivers/video/backlight/Makefile   |   1 +
 drivers/video/backlight/qcom-spmi-wled.c   | 504 
+

 4 files changed, 604 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt

 create mode 100644 drivers/video/backlight/qcom-spmi-wled.c

diff --git 
a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt 
b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt

new file mode 100644
index 000..f1ea25b
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt

@@ -0,0 +1,90 @@
+Binding for Qualcomm WLED driver
+


This binding document quite well describe the pm8941 as well, so please
improve the existing binding (changing to this style is preferable).

Sure. Will do it in the next series, where I will re-use pm8941 driver 
for

PMI8998 as well.
+WLED (White Light Emitting Diode) driver is used for controlling 
display
+backlight that is part of PMIC on Qualcomm Technologies reference 
platforms.

+The PMIC is connected to the host processor via SPMI bus.
+
+- compatible
+   Usage:  required
+   Value type: 
+   Definition: should be "qcom,pm8998-spmi-wled".


There's no WLED in the pm8998, so please make this pmi8998. This pmic 
is

SPMI only, so there's no need to keep "spmi" in the compatible.


Sure. Will change it.

+
+- reg
+   Usage:  required
+   Value type: 
+   Definition:  Base address and size of the WLED modules.
+
+- reg-names
+   Usage:  required
+   Value type: 
+   Definition:  Names associated with base addresses. should be
+"qcom-wled-ctrl-base", "qcom-wled-sink-base".
+
+- label
+   Usage:  required
+   Value type: 
+   Definition: The name of the backlight device.
+
+- default-brightness
+   Usage:  optional
+   Value type: 
+   Definition: brightness value on boot, value from: 0-4095
+   default: 2048
+
+- qcom,fs-current-limit
+   Usage:  optional
+   Value type: 
+   Definition: per-string full scale current limit in uA. value from
+   0 to 3 with 5000 uA resolution. default: 25000 uA


"in steps of 5mA"


Will address it in next series.

+
+- qcom,current-boost-limit
+   Usage:  optional
+   Value type: 
+	Definition: ILIM threshold in mA. values are 105, 280, 450, 620, 
970,

+   1150, 1300, 1500. default: 970 mA
+
+- qcom,switching-freq
+   Usage:  optional
+   Value type: 
+   Definition: Switching frequency in KHz. values are
+   600, 640, 685, 738, 800, 872, 960, 1066, 1200, 1371,
+   1600, 1920, 2400, 3200, 4800, 9600.
+   default: 800 KHz
+
+- qcom,ovp
+   Usage:  optional
+   Value type: 
+   Definition: Over-voltage protection limit in mV. values are 31100,
+   29600, 19600, 18100.
+   default: 29600 mV
+
+- qcom,string-cfg
+   Usage:  optional
+   Value type: 
+	Definition: Bit mask of the wled strings. Bit 0 to 3 indicates 
strings

+   0 to 3 respectively. Wled module has four strings of leds
+   numbered from 0 to 3. Each string of leds are operated
+   individually. Specify the strings using the bit mask. Any
+   combination of led strings can be used.
+   default value is 15 (b).


Please try to avoid expressing things as bitmasks in DT.

The only difference from 8941 here is that there's one additional
string, so please start off by expressing this as the existing binding.

If you really need this flexibility you can follow up with an addition
of a property like this, but name it something like
"qcom,enabled-strings" and make this support available for pm8941 as
well.


Sure. Will address it.

+
+- qcom,en-cabc


No need for the "en", the presence of a bool property means that it's
enabled.


Will address it in next series.

+   Usage:  optional
+   Value type: 
+   Definition: Specify if cabc (content adaptive backlight control) is
+   needed.


I presume cabc isn't ever "needed", just make the description "Enable
content adaptive backlight control".


Will address it in next series.

+
+Example:
+
+qcom-wled@d800 {
+   compatible = "qcom,pm8998-spmi-wled";
+   reg = <0xd800 0xd900>;
+   reg-names = "qcom-wled-ctrl-base", "qcom-wled-sink-base";
+   label = "backlight";
+
+   qcom,fs-current-limit = <25000>;
+   

Re: [PATCH V1 2/4] qcom: spmi-wled: Add support for short circuit handling

[kgunda]

On 2017-11-18 02:00, Rob Herring wrote:

On Thu, Nov 16, 2017 at 05:48:35PM +0530, Kiran Gunda wrote:

Handle the short circuit(SC) interrupt and check if the SC interrupt
is valid. Re-enable the module to check if it goes away. Disable the
module altogether if the SC event persists.

Signed-off-by: Kiran Gunda 
---
 .../bindings/leds/backlight/qcom-spmi-wled.txt |  22 


... and also put all the binding in one patch. I want to review the 
full

view of the h/w, not piecemeal.


Sure. Will send the next series with the changes suggested.
 drivers/video/backlight/qcom-spmi-wled.c   | 126 
-

 2 files changed, 142 insertions(+), 6 deletions(-)

Re: [PATCH V1 2/4] qcom: spmi-wled: Add support for short circuit handling

[kgunda]

On 2017-11-18 02:00, Rob Herring wrote:

On Thu, Nov 16, 2017 at 05:48:35PM +0530, Kiran Gunda wrote:

Handle the short circuit(SC) interrupt and check if the SC interrupt
is valid. Re-enable the module to check if it goes away. Disable the
module altogether if the SC event persists.

Signed-off-by: Kiran Gunda 
---
 .../bindings/leds/backlight/qcom-spmi-wled.txt |  22 


... and also put all the binding in one patch. I want to review the 
full

view of the h/w, not piecemeal.


Sure. Will send the next series with the changes suggested.
 drivers/video/backlight/qcom-spmi-wled.c   | 126 
-

 2 files changed, 142 insertions(+), 6 deletions(-)

Re: [PATCH V1 1/4] qcom: spmi-wled: Add support for qcom wled driver

[kgunda]

On 2017-11-17 14:03, Lee Jones wrote:

On Thu, 16 Nov 2017, Bjorn Andersson wrote:


On Thu 16 Nov 22:36 PST 2017, kgu...@codeaurora.org wrote:

> On 2017-11-16 22:25, Bjorn Andersson wrote:
> > On Thu 16 Nov 04:18 PST 2017, Kiran Gunda wrote:
> >
> > > WLED driver provides the interface to the display driver to
> > > adjust the brightness of the display backlight.
> > >
> >
> > Hi Kiran,
> >
> > This driver has a lot in common with the already upstream pm8941-wled.c,
> > because it's just a new revision of the same block.
> >
> > Please extend the existing driver rather than providing a new one
> > (and yes, renaming the file is okay).
> >
> > Regards,
> > Bjorn
>
> Hi Bjorn,
>
> Yes this driver design is similar to pm8941, however the WLED HW block
> has undergone quite a few changes in analog and digital from PM8941 to
> PM8998.

I can see that, looking at the documentation.

> Few of them include splitting one module into wled-ctrl and wled-sink
> peripherals, changes in the register offsets and the bit
> interpretation.

This is typical and something we need to handle in all these drivers, 
to

avoid having one driver per platform.

> Hence we concluded that it was better to have a new driver to support
> this new gen WELD module and decouple it from the pm8941.

Okay, I can see how it's easier to not have to case about anything but
pmi8998 in this driver, but where do you add the support for other 
WLED

versions? What about PMI8994? Will there not be similar differences
(registers that has moved around) in the future?

> Also, going forward this driver will support AMOLED AVDD rail (not
> supported by pm8941) touching a few more registers/configuration and
> newer PMICs.

Is this a feature that was introduced in PMI8998? Will this support 
not

be dependent on the pmic version?

> So spinning off a new driver would make it cleaner and easier to
> extend further.
>

It's for sure easier at this point in time, but your argumentation
implies that PMI8998+1 should go into it's own driver as well.

I suspect that if you're going to reuse this driver for future PMIC
versions you will have to deal with register layout differences and 
new
feature set, and as such I'm not convinced that a new driver is 
needed.


Can you give any concrete examples of where it is not possible or
undesirable to maintain the pm8941 support in the same driver?


I agree with Bjorn.  If you can support multiple devices in a single
driver with a couple of simple ddata struct differences and a slightly
different regmap, you should.


Hi Lee,
Thanks for the feedback! The regmap difference is not confined to couple 
of registers.
Except the one register all the registers have some difference in offset 
or bitmap or
config values as compared to the pm8941. Below is the table for the 
reference. The below
table covers only the registers those exist in the pm8941 driver, if we 
keep adding the
other features the changes may be huge. Apart from this I have mentioned 
other feature
differences between pm8941 and pm8998 as well in response to Bjorn. 
Please refer that

as well.

Register Compatibility between 8998 Vs 8941
 
===
WLED_MODULE_ENABLE	   Register address offset is same and config 
values match
WLED1_ILED_SYNC_BIT	   Register address offset and config values not 
matching.
WLED1_SWITCHING_FREQUENCY  Register address offset and config values 
are matching.
   But there is an extra override bit in 
pm8998.
WLED1_WLED_OVP	   Register address offset same. But config 
values are not matching.
WLED1_WLED_ILIM	   Register address offset is same. But 
config values are not matching
WLED1_EN_CURRENT_SINK	   Both register address offset and config 
values are not matching.
WLED1_LED1_MODULATOR_EN	   Both register address offset and config 
values are not matching.
WLED1_LED1_FULL_SCALE_CURRENT  Both register address offset and config 
values are not matching.
WLED1_LED1_MODULATOR_SRC_SERegister address offset not matching, but 
the config values are matching
WLED1_LED1_CABC_EN	   Register address offset not matching, but the 
config values are not matching.


Thanks,
Kiran

Re: [PATCH V1 1/4] qcom: spmi-wled: Add support for qcom wled driver

[kgunda]

On 2017-11-17 14:03, Lee Jones wrote:

On Thu, 16 Nov 2017, Bjorn Andersson wrote:


On Thu 16 Nov 22:36 PST 2017, kgu...@codeaurora.org wrote:

> On 2017-11-16 22:25, Bjorn Andersson wrote:
> > On Thu 16 Nov 04:18 PST 2017, Kiran Gunda wrote:
> >
> > > WLED driver provides the interface to the display driver to
> > > adjust the brightness of the display backlight.
> > >
> >
> > Hi Kiran,
> >
> > This driver has a lot in common with the already upstream pm8941-wled.c,
> > because it's just a new revision of the same block.
> >
> > Please extend the existing driver rather than providing a new one
> > (and yes, renaming the file is okay).
> >
> > Regards,
> > Bjorn
>
> Hi Bjorn,
>
> Yes this driver design is similar to pm8941, however the WLED HW block
> has undergone quite a few changes in analog and digital from PM8941 to
> PM8998.

I can see that, looking at the documentation.

> Few of them include splitting one module into wled-ctrl and wled-sink
> peripherals, changes in the register offsets and the bit
> interpretation.

This is typical and something we need to handle in all these drivers, 
to

avoid having one driver per platform.

> Hence we concluded that it was better to have a new driver to support
> this new gen WELD module and decouple it from the pm8941.

Okay, I can see how it's easier to not have to case about anything but
pmi8998 in this driver, but where do you add the support for other 
WLED

versions? What about PMI8994? Will there not be similar differences
(registers that has moved around) in the future?

> Also, going forward this driver will support AMOLED AVDD rail (not
> supported by pm8941) touching a few more registers/configuration and
> newer PMICs.

Is this a feature that was introduced in PMI8998? Will this support 
not

be dependent on the pmic version?

> So spinning off a new driver would make it cleaner and easier to
> extend further.
>

It's for sure easier at this point in time, but your argumentation
implies that PMI8998+1 should go into it's own driver as well.

I suspect that if you're going to reuse this driver for future PMIC
versions you will have to deal with register layout differences and 
new
feature set, and as such I'm not convinced that a new driver is 
needed.


Can you give any concrete examples of where it is not possible or
undesirable to maintain the pm8941 support in the same driver?


I agree with Bjorn.  If you can support multiple devices in a single
driver with a couple of simple ddata struct differences and a slightly
different regmap, you should.


Hi Lee,
Thanks for the feedback! The regmap difference is not confined to couple 
of registers.
Except the one register all the registers have some difference in offset 
or bitmap or
config values as compared to the pm8941. Below is the table for the 
reference. The below
table covers only the registers those exist in the pm8941 driver, if we 
keep adding the
other features the changes may be huge. Apart from this I have mentioned 
other feature
differences between pm8941 and pm8998 as well in response to Bjorn. 
Please refer that

as well.

Register Compatibility between 8998 Vs 8941
 
===
WLED_MODULE_ENABLE	   Register address offset is same and config 
values match
WLED1_ILED_SYNC_BIT	   Register address offset and config values not 
matching.
WLED1_SWITCHING_FREQUENCY  Register address offset and config values 
are matching.
   But there is an extra override bit in 
pm8998.
WLED1_WLED_OVP	   Register address offset same. But config 
values are not matching.
WLED1_WLED_ILIM	   Register address offset is same. But 
config values are not matching
WLED1_EN_CURRENT_SINK	   Both register address offset and config 
values are not matching.
WLED1_LED1_MODULATOR_EN	   Both register address offset and config 
values are not matching.
WLED1_LED1_FULL_SCALE_CURRENT  Both register address offset and config 
values are not matching.
WLED1_LED1_MODULATOR_SRC_SERegister address offset not matching, but 
the config values are matching
WLED1_LED1_CABC_EN	   Register address offset not matching, but the 
config values are not matching.


Thanks,
Kiran

Re: [PATCH V1 1/4] qcom: spmi-wled: Add support for qcom wled driver

[kgunda]

On 2017-11-17 12:26, Bjorn Andersson wrote:

On Thu 16 Nov 22:36 PST 2017, kgu...@codeaurora.org wrote:


On 2017-11-16 22:25, Bjorn Andersson wrote:
> On Thu 16 Nov 04:18 PST 2017, Kiran Gunda wrote:
>
> > WLED driver provides the interface to the display driver to
> > adjust the brightness of the display backlight.
> >
>
> Hi Kiran,
>
> This driver has a lot in common with the already upstream pm8941-wled.c,
> because it's just a new revision of the same block.
>
> Please extend the existing driver rather than providing a new one
> (and yes, renaming the file is okay).
>
> Regards,
> Bjorn

Hi Bjorn,

Yes this driver design is similar to pm8941, however the WLED HW block
has undergone quite a few changes in analog and digital from PM8941 to
PM8998.


I can see that, looking at the documentation.


Few of them include splitting one module into wled-ctrl and wled-sink
peripherals, changes in the register offsets and the bit
interpretation.


This is typical and something we need to handle in all these drivers, 
to

avoid having one driver per platform.


Hence we concluded that it was better to have a new driver to support
this new gen WELD module and decouple it from the pm8941.


Okay, I can see how it's easier to not have to case about anything but
pmi8998 in this driver, but where do you add the support for other WLED
versions? What about PMI8994? Will there not be similar differences
(registers that has moved around) in the future?


Also, going forward this driver will support AMOLED AVDD rail (not
supported by pm8941) touching a few more registers/configuration and
newer PMICs.


Is this a feature that was introduced in PMI8998? Will this support not
be dependent on the pmic version?


So spinning off a new driver would make it cleaner and easier to
extend further.



It's for sure easier at this point in time, but your argumentation
implies that PMI8998+1 should go into it's own driver as well.

I suspect that if you're going to reuse this driver for future PMIC
versions you will have to deal with register layout differences and new
feature set, and as such I'm not convinced that a new driver is needed.


Can you give any concrete examples of where it is not possible or
undesirable to maintain the pm8941 support in the same driver?

Regards,
Bjorn


Hi Bjorn,

Thanks for the inputs! Following are the reasons to go for the new 
driver

and this driver can support 5 PMICs.

1.Majority of  register, offsets and config values don’t match  up  
between

 PMI8998 and PM8941
2.Feature such as – SC protection handling in SW cannot be done for 8941 
as

there is no SC event/irq, AMOELD AVDD cannot supported by PM8941
3.Feature such as – string auto-calibration even if common will have to 
use

different offsets/registers in the same SW logic
4.PMI8998, PMI8994, PMI8950 and PM660 all of them have this same WLED 
module

(and register map) with very minor changes unlike 8941.

Thanks,
Kiran



--
To unsubscribe from this list: send the line "unsubscribe 
linux-arm-msm" in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V1 1/4] qcom: spmi-wled: Add support for qcom wled driver

[kgunda]

On 2017-11-17 12:26, Bjorn Andersson wrote:

On Thu 16 Nov 22:36 PST 2017, kgu...@codeaurora.org wrote:


On 2017-11-16 22:25, Bjorn Andersson wrote:
> On Thu 16 Nov 04:18 PST 2017, Kiran Gunda wrote:
>
> > WLED driver provides the interface to the display driver to
> > adjust the brightness of the display backlight.
> >
>
> Hi Kiran,
>
> This driver has a lot in common with the already upstream pm8941-wled.c,
> because it's just a new revision of the same block.
>
> Please extend the existing driver rather than providing a new one
> (and yes, renaming the file is okay).
>
> Regards,
> Bjorn

Hi Bjorn,

Yes this driver design is similar to pm8941, however the WLED HW block
has undergone quite a few changes in analog and digital from PM8941 to
PM8998.


I can see that, looking at the documentation.


Few of them include splitting one module into wled-ctrl and wled-sink
peripherals, changes in the register offsets and the bit
interpretation.


This is typical and something we need to handle in all these drivers, 
to

avoid having one driver per platform.


Hence we concluded that it was better to have a new driver to support
this new gen WELD module and decouple it from the pm8941.


Okay, I can see how it's easier to not have to case about anything but
pmi8998 in this driver, but where do you add the support for other WLED
versions? What about PMI8994? Will there not be similar differences
(registers that has moved around) in the future?


Also, going forward this driver will support AMOLED AVDD rail (not
supported by pm8941) touching a few more registers/configuration and
newer PMICs.


Is this a feature that was introduced in PMI8998? Will this support not
be dependent on the pmic version?


So spinning off a new driver would make it cleaner and easier to
extend further.



It's for sure easier at this point in time, but your argumentation
implies that PMI8998+1 should go into it's own driver as well.

I suspect that if you're going to reuse this driver for future PMIC
versions you will have to deal with register layout differences and new
feature set, and as such I'm not convinced that a new driver is needed.


Can you give any concrete examples of where it is not possible or
undesirable to maintain the pm8941 support in the same driver?

Regards,
Bjorn


Hi Bjorn,

Thanks for the inputs! Following are the reasons to go for the new 
driver

and this driver can support 5 PMICs.

1.Majority of  register, offsets and config values don’t match  up  
between

 PMI8998 and PM8941
2.Feature such as – SC protection handling in SW cannot be done for 8941 
as

there is no SC event/irq, AMOELD AVDD cannot supported by PM8941
3.Feature such as – string auto-calibration even if common will have to 
use

different offsets/registers in the same SW logic
4.PMI8998, PMI8994, PMI8950 and PM660 all of them have this same WLED 
module

(and register map) with very minor changes unlike 8941.

Thanks,
Kiran



--
To unsubscribe from this list: send the line "unsubscribe 
linux-arm-msm" in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V1 1/4] qcom: spmi-wled: Add support for qcom wled driver

[kgunda]

On 2017-11-16 22:25, Bjorn Andersson wrote:

On Thu 16 Nov 04:18 PST 2017, Kiran Gunda wrote:


WLED driver provides the interface to the display driver to
adjust the brightness of the display backlight.



Hi Kiran,

This driver has a lot in common with the already upstream 
pm8941-wled.c,

because it's just a new revision of the same block.

Please extend the existing driver rather than providing a new one
(and yes, renaming the file is okay).

Regards,
Bjorn


Hi Bjorn,

Yes this driver design is similar to pm8941, however the WLED HW block 
has undergone quite a few changes in
analog and digital from PM8941 to PM8998. Few of them include splitting 
one module into wled-ctrl
and wled-sink peripherals, changes in the register offsets and the bit 
interpretation. Hence we
concluded that it was better to have a new driver to support this new 
gen WELD module and decouple
it from the pm8941. Also, going forward this driver will support AMOLED 
AVDD rail (not supported by pm8941)
touching a few more registers/configuration and newer PMICs. So spinning 
off a new driver would make it

cleaner and easier to extend further.

Thanks,
Kiran


--
To unsubscribe from this list: send the line "unsubscribe 
linux-arm-msm" in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V1 1/4] qcom: spmi-wled: Add support for qcom wled driver

[kgunda]

On 2017-11-16 22:25, Bjorn Andersson wrote:

On Thu 16 Nov 04:18 PST 2017, Kiran Gunda wrote:


WLED driver provides the interface to the display driver to
adjust the brightness of the display backlight.



Hi Kiran,

This driver has a lot in common with the already upstream 
pm8941-wled.c,

because it's just a new revision of the same block.

Please extend the existing driver rather than providing a new one
(and yes, renaming the file is okay).

Regards,
Bjorn


Hi Bjorn,

Yes this driver design is similar to pm8941, however the WLED HW block 
has undergone quite a few changes in
analog and digital from PM8941 to PM8998. Few of them include splitting 
one module into wled-ctrl
and wled-sink peripherals, changes in the register offsets and the bit 
interpretation. Hence we
concluded that it was better to have a new driver to support this new 
gen WELD module and decouple
it from the pm8941. Also, going forward this driver will support AMOLED 
AVDD rail (not supported by pm8941)
touching a few more registers/configuration and newer PMICs. So spinning 
off a new driver would make it

cleaner and easier to extend further.

Thanks,
Kiran


--
To unsubscribe from this list: send the line "unsubscribe 
linux-arm-msm" in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V1] thermal: qcom-spmi-temp-alarm: add support for GEN2 PMIC peripherals

[kgunda]

On 2017-08-26 04:49, Stephen Boyd wrote:

On 08/25, Zhang Rui wrote:

On Thu, 2017-08-17 at 13:12 +0530, kgu...@codeaurora.org wrote:
> On 2017-08-16 17:53, kgu...@codeaurora.org wrote:
> >
> > On 2017-08-08 13:42, Zhang Rui wrote:
> > >
> > > On Thu, 2017-07-13 at 17:39 +0530, Kiran Gunda wrote:
> > > >
> > > > From: David Collins 
> > > >
> > > > Add support for the TEMP_ALARM GEN2 PMIC peripheral
> > > > subtype.  The
> > > > GEN2 subtype defines an over temperature state with hysteresis
> > > > instead of stage in the status register.  There are two GEN2
> > > > states corresponding to stages 1 and 2.
> > > >
> > > > Signed-off-by: David Collins 
> > > > Signed-off-by: Kiran Gunda 
> > > Ivan,
> > >
> > > can you please review this patch and let me know your opinion?
> > >
> > > thanks,
> > > rui
> > Ivan,
> > Could you please review this patch ?
> >
> > Thanks,
> > Kiran
> Looks like Ivan is no more reviewing the patches for qcom.
> Adding Bjorn and Stephen Boyd for the review.
>
Given this is a platform specific change, I will queue it for next
merge window, and let's see if there is any problem reported.



Thanks for that !


FWIW,

Reviewed-by: Stephen Boyd 

Re: [PATCH V1] thermal: qcom-spmi-temp-alarm: add support for GEN2 PMIC peripherals

[kgunda]

On 2017-08-26 04:49, Stephen Boyd wrote:

On 08/25, Zhang Rui wrote:

On Thu, 2017-08-17 at 13:12 +0530, kgu...@codeaurora.org wrote:
> On 2017-08-16 17:53, kgu...@codeaurora.org wrote:
> >
> > On 2017-08-08 13:42, Zhang Rui wrote:
> > >
> > > On Thu, 2017-07-13 at 17:39 +0530, Kiran Gunda wrote:
> > > >
> > > > From: David Collins 
> > > >
> > > > Add support for the TEMP_ALARM GEN2 PMIC peripheral
> > > > subtype.  The
> > > > GEN2 subtype defines an over temperature state with hysteresis
> > > > instead of stage in the status register.  There are two GEN2
> > > > states corresponding to stages 1 and 2.
> > > >
> > > > Signed-off-by: David Collins 
> > > > Signed-off-by: Kiran Gunda 
> > > Ivan,
> > >
> > > can you please review this patch and let me know your opinion?
> > >
> > > thanks,
> > > rui
> > Ivan,
> > Could you please review this patch ?
> >
> > Thanks,
> > Kiran
> Looks like Ivan is no more reviewing the patches for qcom.
> Adding Bjorn and Stephen Boyd for the review.
>
Given this is a platform specific change, I will queue it for next
merge window, and let's see if there is any problem reported.



Thanks for that !


FWIW,

Reviewed-by: Stephen Boyd 

Re: [PATCH V2] spmi: pmic-arb: Enforce the ownership check optionally

[kgunda]

On 2017-08-23 02:01, Stephen Boyd wrote:

On 08/22, Shawn Guo wrote:

On Mon, Aug 21, 2017 at 04:18:58PM -0700, Stephen Boyd wrote:
> On 08/18/2017 08:28 AM, Kiran Gunda wrote:
> > The peripheral ownership check is not necessary on single master
> > platforms. Hence, enforce the peripheral ownership check optionally.
> >
> > Signed-off-by: Kiran Gunda 
> > Tested-by: Shawn Guo 
> > ---
>
> This sounds like a band-aid. Isn't the gpio driver going to keep probing
> all the pins that are not supposed to be accessed due to security
> constraints? What exactly is failing in the gpio case?

There is a platform_irq_count() call in pinctrl-spmi-gpio probe
function.  Due to the owner check in spmi-pmic-arb IRQ domain
qpnpint_irq_domain_dt_translate() function, the call will return irq
number as zero and cause pmic_gpio_probe() fail with -EINVAL error.

[1.608516] [] 
qpnpint_irq_domain_dt_translate+0x168/0x194
[1.613557] [] 
irq_create_fwspec_mapping+0x17c/0x2d8

[1.620672] [] irq_create_of_mapping+0x64/0x74
[1.627008] [] of_irq_get+0x54/0x64
[1.633169] [] platform_get_irq+0x20/0x150
[1.638117] [] platform_irq_count+0x28/0x44
[1.643850] [] pmic_gpio_probe+0x50/0x544



Hmm. Ok. I guess platform_irq_count() has to go and create irq
mappings if they haven't been created yet and that then causes us
to check if we can even get the interrupt for this particular
irq? There are some interrupt lines that are not routed to the
application processor in the system, so the irq_ee (irq execution
environment) is different. This check is there to avoid creating
flow handlers for irqs that can't be triggered.

I can see how trying to request that irq doesn't make sense,
because it won't ever happen. But preventing that from being
translated is confusing. Perhaps we can move the check for irq_ee
to the irq_request_resources() callback in the irqchip? That way,
we can fail installing the flow handler for the interrupt we
can't ever receive, but otherwise translate the interrupt number
so we can keep counting them.


Hi Stephen,
The idea to move the ownership check to irq_request_resources sounds 
good.
I am dropping this patch and sent the new patch to move the irq 
ownership to

irq_request_resource. Following is the patchwork link.

Shawn, can you please give a try with it?
https://patchwork.kernel.org/patch/9917315/


Also, I see that on v4.13-rc series the read/write checks are
causing the led driver to fail in a different way:

spmi spmi-0: error: impermissible write to peripheral sid:0 
addr:0xc040

qcom-spmi-gpio 200f000.spmi:pm8916@0:gpios@c000: write 0x40 failed
leds-gpio soc:leds: Error applying setting, reverse things back
spmi spmi-0: error: impermissible write to peripheral sid:0 
addr:0xc041

qcom-spmi-gpio 200f000.spmi:pm8916@0:gpios@c000: write 0x41 failed
leds-gpio: probe of soc:leds failed with error -1

Are you seeing similar behavior?
With the new patch series these errors will go away, as we are removing 
the ownership

checks from the read/write path.

Re: [PATCH V2] spmi: pmic-arb: Enforce the ownership check optionally

[kgunda]

On 2017-08-23 02:01, Stephen Boyd wrote:

On 08/22, Shawn Guo wrote:

On Mon, Aug 21, 2017 at 04:18:58PM -0700, Stephen Boyd wrote:
> On 08/18/2017 08:28 AM, Kiran Gunda wrote:
> > The peripheral ownership check is not necessary on single master
> > platforms. Hence, enforce the peripheral ownership check optionally.
> >
> > Signed-off-by: Kiran Gunda 
> > Tested-by: Shawn Guo 
> > ---
>
> This sounds like a band-aid. Isn't the gpio driver going to keep probing
> all the pins that are not supposed to be accessed due to security
> constraints? What exactly is failing in the gpio case?

There is a platform_irq_count() call in pinctrl-spmi-gpio probe
function.  Due to the owner check in spmi-pmic-arb IRQ domain
qpnpint_irq_domain_dt_translate() function, the call will return irq
number as zero and cause pmic_gpio_probe() fail with -EINVAL error.

[1.608516] [] 
qpnpint_irq_domain_dt_translate+0x168/0x194
[1.613557] [] 
irq_create_fwspec_mapping+0x17c/0x2d8

[1.620672] [] irq_create_of_mapping+0x64/0x74
[1.627008] [] of_irq_get+0x54/0x64
[1.633169] [] platform_get_irq+0x20/0x150
[1.638117] [] platform_irq_count+0x28/0x44
[1.643850] [] pmic_gpio_probe+0x50/0x544



Hmm. Ok. I guess platform_irq_count() has to go and create irq
mappings if they haven't been created yet and that then causes us
to check if we can even get the interrupt for this particular
irq? There are some interrupt lines that are not routed to the
application processor in the system, so the irq_ee (irq execution
environment) is different. This check is there to avoid creating
flow handlers for irqs that can't be triggered.

I can see how trying to request that irq doesn't make sense,
because it won't ever happen. But preventing that from being
translated is confusing. Perhaps we can move the check for irq_ee
to the irq_request_resources() callback in the irqchip? That way,
we can fail installing the flow handler for the interrupt we
can't ever receive, but otherwise translate the interrupt number
so we can keep counting them.


Hi Stephen,
The idea to move the ownership check to irq_request_resources sounds 
good.
I am dropping this patch and sent the new patch to move the irq 
ownership to

irq_request_resource. Following is the patchwork link.

Shawn, can you please give a try with it?
https://patchwork.kernel.org/patch/9917315/


Also, I see that on v4.13-rc series the read/write checks are
causing the led driver to fail in a different way:

spmi spmi-0: error: impermissible write to peripheral sid:0 
addr:0xc040

qcom-spmi-gpio 200f000.spmi:pm8916@0:gpios@c000: write 0x40 failed
leds-gpio soc:leds: Error applying setting, reverse things back
spmi spmi-0: error: impermissible write to peripheral sid:0 
addr:0xc041

qcom-spmi-gpio 200f000.spmi:pm8916@0:gpios@c000: write 0x41 failed
leds-gpio: probe of soc:leds failed with error -1

Are you seeing similar behavior?
With the new patch series these errors will go away, as we are removing 
the ownership

checks from the read/write path.

Re: [PATCH V2 11/12] spmi: pmic-arb: add support for HW version 5

[kgunda]

On 2017-08-18 16:43, kgu...@codeaurora.org wrote:

On 2017-08-17 17:58, Shawn Guo wrote:

On Thu, Aug 17, 2017 at 03:38:30PM +0530, kgu...@codeaurora.org wrote:

The intention of this check is to avoid the access to the
peripherals those are
not owned by the current EE (APSS) and it is expected to return a
failure if the
peripheral that is not owned by the current EE is trying to be 
accessed.


Thanks for the background of this check.


Looks like you trying to access the GPIOs 0xc000 and 0xc100,
which are owned by modem subsystem but not the APSS. That is why you
seeing the failure for that.
Please change the ownership of those GPIOs to APSS (id '0') if you
are working on a non-modem device (APQ).


Yes, it's device apq8016-sbc, and the error message is like below.

[1.317186] spmi spmi-0: PMIC arbiter version v2 (0x2001)
[1.324784] spmi spmi-0: failed to xlate sid = 0x0, periph = 0xc0,
irq = 0: ee=0 but owner=2
[1.329430] spmi spmi-0: failed to xlate sid = 0x0, periph = 0xc0,
irq = 0: ee=0 but owner=2
[1.337626] qcom-spmi-gpio: probe of
200f000.spmi:pm8916@0:gpios@c000 failed with error -22

I see that 'qcom,ee' property of spmi_bus is already <0>.  Is that 
what

you mean by ownership of those GPIOs?

I do not mean that. The SPMI arbiter ownership register is programmed by 
the boot-loader,
where the actual ownership is set. The same is shown in the above logs 
as owner = 2.



The pm8916_gpio is working fine on apq8016-sbc device with the current
mainline kernel.  It's not good to break the existing device without
a very good.  IMO, we should get this fixed before the patch is 
merged.


Shawn
--


From the logs the ownership for these GPIOs is not assigned to the
application processor but to another master. Considering this is a
(apq8016-sbc) APSS only platform ideally the fix for this would be to
update the ownership table in the boot loader. The other option would
be to make the  existing ownership check in SW optional for a platform
via DT. I will push a patch shortly for this. Could you please give
that a try.

Thanks,
Kiran
To unsubscribe from this list: send the line "unsubscribe 
linux-arm-msm" in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe 
linux-arm-msm" in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 11/12] spmi: pmic-arb: add support for HW version 5

[kgunda]

On 2017-08-18 16:43, kgu...@codeaurora.org wrote:

On 2017-08-17 17:58, Shawn Guo wrote:

On Thu, Aug 17, 2017 at 03:38:30PM +0530, kgu...@codeaurora.org wrote:

The intention of this check is to avoid the access to the
peripherals those are
not owned by the current EE (APSS) and it is expected to return a
failure if the
peripheral that is not owned by the current EE is trying to be 
accessed.


Thanks for the background of this check.


Looks like you trying to access the GPIOs 0xc000 and 0xc100,
which are owned by modem subsystem but not the APSS. That is why you
seeing the failure for that.
Please change the ownership of those GPIOs to APSS (id '0') if you
are working on a non-modem device (APQ).


Yes, it's device apq8016-sbc, and the error message is like below.

[1.317186] spmi spmi-0: PMIC arbiter version v2 (0x2001)
[1.324784] spmi spmi-0: failed to xlate sid = 0x0, periph = 0xc0,
irq = 0: ee=0 but owner=2
[1.329430] spmi spmi-0: failed to xlate sid = 0x0, periph = 0xc0,
irq = 0: ee=0 but owner=2
[1.337626] qcom-spmi-gpio: probe of
200f000.spmi:pm8916@0:gpios@c000 failed with error -22

I see that 'qcom,ee' property of spmi_bus is already <0>.  Is that 
what

you mean by ownership of those GPIOs?

I do not mean that. The SPMI arbiter ownership register is programmed by 
the boot-loader,
where the actual ownership is set. The same is shown in the above logs 
as owner = 2.



The pm8916_gpio is working fine on apq8016-sbc device with the current
mainline kernel.  It's not good to break the existing device without
a very good.  IMO, we should get this fixed before the patch is 
merged.


Shawn
--


From the logs the ownership for these GPIOs is not assigned to the
application processor but to another master. Considering this is a
(apq8016-sbc) APSS only platform ideally the fix for this would be to
update the ownership table in the boot loader. The other option would
be to make the  existing ownership check in SW optional for a platform
via DT. I will push a patch shortly for this. Could you please give
that a try.

Thanks,
Kiran
To unsubscribe from this list: send the line "unsubscribe 
linux-arm-msm" in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe 
linux-arm-msm" in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 11/12] spmi: pmic-arb: add support for HW version 5

[kgunda]

On 2017-08-17 17:58, Shawn Guo wrote:

On Thu, Aug 17, 2017 at 03:38:30PM +0530, kgu...@codeaurora.org wrote:

The intention of this check is to avoid the access to the
peripherals those are
not owned by the current EE (APSS) and it is expected to return a
failure if the
peripheral that is not owned by the current EE is trying to be 
accessed.


Thanks for the background of this check.


Looks like you trying to access the GPIOs 0xc000 and 0xc100,
which are owned by modem subsystem but not the APSS. That is why you
seeing the failure for that.
Please change the ownership of those GPIOs to APSS (id '0') if you
are working on a non-modem device (APQ).


Yes, it's device apq8016-sbc, and the error message is like below.

[1.317186] spmi spmi-0: PMIC arbiter version v2 (0x2001)
[1.324784] spmi spmi-0: failed to xlate sid = 0x0, periph = 0xc0,
irq = 0: ee=0 but owner=2
[1.329430] spmi spmi-0: failed to xlate sid = 0x0, periph = 0xc0,
irq = 0: ee=0 but owner=2
[1.337626] qcom-spmi-gpio: probe of
200f000.spmi:pm8916@0:gpios@c000 failed with error -22

I see that 'qcom,ee' property of spmi_bus is already <0>.  Is that what
you mean by ownership of those GPIOs?

The pm8916_gpio is working fine on apq8016-sbc device with the current
mainline kernel.  It's not good to break the existing device without
a very good.  IMO, we should get this fixed before the patch is merged.

Shawn
--


From the logs the ownership for these GPIOs is not assigned to the 
application processor but to another master. Considering this is a 
(apq8016-sbc) APSS only platform ideally the fix for this would be to 
update the ownership table in the boot loader. The other option would be 
to make the  existing ownership check in SW optional for a platform via 
DT. I will push a patch shortly for this. Could you please give that a 
try.


Thanks,
Kiran
To unsubscribe from this list: send the line "unsubscribe 
linux-arm-msm" in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 11/12] spmi: pmic-arb: add support for HW version 5

[kgunda]

On 2017-08-17 17:58, Shawn Guo wrote:

On Thu, Aug 17, 2017 at 03:38:30PM +0530, kgu...@codeaurora.org wrote:

The intention of this check is to avoid the access to the
peripherals those are
not owned by the current EE (APSS) and it is expected to return a
failure if the
peripheral that is not owned by the current EE is trying to be 
accessed.


Thanks for the background of this check.


Looks like you trying to access the GPIOs 0xc000 and 0xc100,
which are owned by modem subsystem but not the APSS. That is why you
seeing the failure for that.
Please change the ownership of those GPIOs to APSS (id '0') if you
are working on a non-modem device (APQ).


Yes, it's device apq8016-sbc, and the error message is like below.

[1.317186] spmi spmi-0: PMIC arbiter version v2 (0x2001)
[1.324784] spmi spmi-0: failed to xlate sid = 0x0, periph = 0xc0,
irq = 0: ee=0 but owner=2
[1.329430] spmi spmi-0: failed to xlate sid = 0x0, periph = 0xc0,
irq = 0: ee=0 but owner=2
[1.337626] qcom-spmi-gpio: probe of
200f000.spmi:pm8916@0:gpios@c000 failed with error -22

I see that 'qcom,ee' property of spmi_bus is already <0>.  Is that what
you mean by ownership of those GPIOs?

The pm8916_gpio is working fine on apq8016-sbc device with the current
mainline kernel.  It's not good to break the existing device without
a very good.  IMO, we should get this fixed before the patch is merged.

Shawn
--


From the logs the ownership for these GPIOs is not assigned to the 
application processor but to another master. Considering this is a 
(apq8016-sbc) APSS only platform ideally the fix for this would be to 
update the ownership table in the boot loader. The other option would be 
to make the  existing ownership check in SW optional for a platform via 
DT. I will push a patch shortly for this. Could you please give that a 
try.


Thanks,
Kiran
To unsubscribe from this list: send the line "unsubscribe 
linux-arm-msm" in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 11/12] spmi: pmic-arb: add support for HW version 5

[kgunda]

On 2017-08-17 13:11, Shawn Guo wrote:

Hi Kiran,

On Fri, Jul 28, 2017 at 12:40:46PM +0530, Kiran Gunda wrote:

From: David Collins 

Add support for version 5 of the SPMI PMIC arbiter.  It utilizes
different offsets for registers than those found on version 3.
Also, the procedure to determine if writing and IRQ access is
allowed for a given PPID changes for version 5.

Signed-off-by: David Collins 
Signed-off-by: Kiran Gunda 
Reviewed-by: Stephen Boyd 
---
 drivers/spmi/spmi-pmic-arb.c | 236 
+++

 1 file changed, 214 insertions(+), 22 deletions(-)

diff --git a/drivers/spmi/spmi-pmic-arb.c 
b/drivers/spmi/spmi-pmic-arb.c

index bc68e08..3f46445 100644
--- a/drivers/spmi/spmi-pmic-arb.c
+++ b/drivers/spmi/spmi-pmic-arb.c




@@ -680,12 +701,19 @@ static int 
qpnpint_irq_domain_dt_translate(struct irq_domain *d,

ppid = intspec[0] << 8 | intspec[1];
rc = pmic_arb->ver_ops->ppid_to_apid(pmic_arb, ppid);
if (rc < 0) {
-		dev_err(_arb->spmic->dev, "failed to xlate sid = 0x%x, periph 
= 0x%x, irq = %x rc = %d\n",
+		dev_err(_arb->spmic->dev, "failed to xlate sid = %#x, periph = 
%#x, irq = %u rc = %d\n",

intspec[0], intspec[1], intspec[2], rc);
return rc;
}

apid = rc;
+   if (pmic_arb->apid_data[apid].irq_ee != pmic_arb->ee) {
+		dev_err(_arb->spmic->dev, "failed to xlate sid = %#x, periph = 
%#x, irq = %u: ee=%u but owner=%u\n",

+   intspec[0], intspec[1], intspec[2], pmic_arb->ee,
+   pmic_arb->apid_data[apid].irq_ee);
+   return -ENODEV;
+   }
+


It seems to me that this check breaks pm8916_gpios on db410c.  It 
causes

the failure of pinctrl-spmi-gpio driver probing, because npins returned
from platform_irq_count() call is 0.

Shawn


Hi Shawn,
The intention of this check is to avoid the access to the peripherals 
those are
not owned by the current EE (APSS) and it is expected to return a 
failure if the

peripheral that is not owned by the current EE is trying to be accessed.

Looks like you trying to access the GPIOs 0xc000 and 0xc100,
which are owned by modem subsystem but not the APSS. That is why you 
seeing the failure for that.
Please change the ownership of those GPIOs to APSS (id '0') if you are 
working on a non-modem device (APQ).


Thanks,
Kiran
 	/* Keep track of {max,min}_apid for bounding search during interrupt 
*/

if (apid > pmic_arb->max_apid)
pmic_arb->max_apid = apid;

--
To unsubscribe from this list: send the line "unsubscribe 
linux-arm-msm" in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 11/12] spmi: pmic-arb: add support for HW version 5

[kgunda]

On 2017-08-17 13:11, Shawn Guo wrote:

Hi Kiran,

On Fri, Jul 28, 2017 at 12:40:46PM +0530, Kiran Gunda wrote:

From: David Collins 

Add support for version 5 of the SPMI PMIC arbiter.  It utilizes
different offsets for registers than those found on version 3.
Also, the procedure to determine if writing and IRQ access is
allowed for a given PPID changes for version 5.

Signed-off-by: David Collins 
Signed-off-by: Kiran Gunda 
Reviewed-by: Stephen Boyd 
---
 drivers/spmi/spmi-pmic-arb.c | 236 
+++

 1 file changed, 214 insertions(+), 22 deletions(-)

diff --git a/drivers/spmi/spmi-pmic-arb.c 
b/drivers/spmi/spmi-pmic-arb.c

index bc68e08..3f46445 100644
--- a/drivers/spmi/spmi-pmic-arb.c
+++ b/drivers/spmi/spmi-pmic-arb.c




@@ -680,12 +701,19 @@ static int 
qpnpint_irq_domain_dt_translate(struct irq_domain *d,

ppid = intspec[0] << 8 | intspec[1];
rc = pmic_arb->ver_ops->ppid_to_apid(pmic_arb, ppid);
if (rc < 0) {
-		dev_err(_arb->spmic->dev, "failed to xlate sid = 0x%x, periph 
= 0x%x, irq = %x rc = %d\n",
+		dev_err(_arb->spmic->dev, "failed to xlate sid = %#x, periph = 
%#x, irq = %u rc = %d\n",

intspec[0], intspec[1], intspec[2], rc);
return rc;
}

apid = rc;
+   if (pmic_arb->apid_data[apid].irq_ee != pmic_arb->ee) {
+		dev_err(_arb->spmic->dev, "failed to xlate sid = %#x, periph = 
%#x, irq = %u: ee=%u but owner=%u\n",

+   intspec[0], intspec[1], intspec[2], pmic_arb->ee,
+   pmic_arb->apid_data[apid].irq_ee);
+   return -ENODEV;
+   }
+


It seems to me that this check breaks pm8916_gpios on db410c.  It 
causes

the failure of pinctrl-spmi-gpio driver probing, because npins returned
from platform_irq_count() call is 0.

Shawn


Hi Shawn,
The intention of this check is to avoid the access to the peripherals 
those are
not owned by the current EE (APSS) and it is expected to return a 
failure if the

peripheral that is not owned by the current EE is trying to be accessed.

Looks like you trying to access the GPIOs 0xc000 and 0xc100,
which are owned by modem subsystem but not the APSS. That is why you 
seeing the failure for that.
Please change the ownership of those GPIOs to APSS (id '0') if you are 
working on a non-modem device (APQ).


Thanks,
Kiran
 	/* Keep track of {max,min}_apid for bounding search during interrupt 
*/

if (apid > pmic_arb->max_apid)
pmic_arb->max_apid = apid;

--
To unsubscribe from this list: send the line "unsubscribe 
linux-arm-msm" in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V1] thermal: qcom-spmi-temp-alarm: add support for GEN2 PMIC peripherals

[kgunda]

On 2017-08-16 17:53, kgu...@codeaurora.org wrote:

On 2017-08-08 13:42, Zhang Rui wrote:

On Thu, 2017-07-13 at 17:39 +0530, Kiran Gunda wrote:

From: David Collins 

Add support for the TEMP_ALARM GEN2 PMIC peripheral subtype.  The
GEN2 subtype defines an over temperature state with hysteresis
instead of stage in the status register.  There are two GEN2
states corresponding to stages 1 and 2.

Signed-off-by: David Collins 
Signed-off-by: Kiran Gunda 


Ivan,

can you please review this patch and let me know your opinion?

thanks,
rui


Ivan,
Could you please review this patch ?

Thanks,
Kiran


Looks like Ivan is no more reviewing the patches for qcom.
Adding Bjorn and Stephen Boyd for the review.

Thanks,
Kiran

---
 drivers/thermal/qcom-spmi-temp-alarm.c | 92
++
 1 file changed, 71 insertions(+), 21 deletions(-)

diff --git a/drivers/thermal/qcom-spmi-temp-alarm.c
b/drivers/thermal/qcom-spmi-temp-alarm.c
index f502419..a5e17ba 100644
--- a/drivers/thermal/qcom-spmi-temp-alarm.c
+++ b/drivers/thermal/qcom-spmi-temp-alarm.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2011-2015, The Linux Foundation. All rights
reserved.
+ * Copyright (c) 2011-2015, 2017, The Linux Foundation. All rights
reserved.
  *
  * This program is free software; you can redistribute it and/or
modify
  * it under the terms of the GNU General Public License version 2
and
@@ -11,6 +11,7 @@
  * GNU General Public License for more details.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -29,13 +30,17 @@
 #define QPNP_TM_REG_ALARM_CTRL 0x46
 
 #define QPNP_TM_TYPE   0x09
-#define QPNP_TM_SUBTYPE0x08
+#define QPNP_TM_SUBTYPE_GEN1   0x08
+#define QPNP_TM_SUBTYPE_GEN2   0x09
 
-#define STATUS_STAGE_MASK  0x03
+#define STATUS_GEN1_STAGE_MASK GENMASK(1, 0)
+#define STATUS_GEN2_STATE_MASK GENMASK(6, 4)
+#define STATUS_GEN2_STATE_SHIFT4
 
-#define SHUTDOWN_CTRL1_THRESHOLD_MASK  0x03
+#define SHUTDOWN_CTRL1_OVERRIDE_MASK   GENMASK(7, 6)
+#define SHUTDOWN_CTRL1_THRESHOLD_MASK  GENMASK(1, 0)
 
-#define ALARM_CTRL_FORCE_ENABLE0x80
+#define ALARM_CTRL_FORCE_ENABLEBIT(7)
 
 /*
  * Trip point values based on threshold control
@@ -58,6 +63,7 @@
 struct qpnp_tm_chip {
    struct regmap   *map;
    struct thermal_zone_device  *tz_dev;
+   unsigned intsubtype;
    longtemp;
    unsigned intthresh;
    unsigned intstage;
@@ -66,6 +72,9 @@ struct qpnp_tm_chip {
    struct iio_channel  *adc;
 };
 
+/* This array maps from GEN2 alarm state to GEN1 alarm stage */
+static const unsigned int alarm_state_map[8] = {0, 1, 1, 2, 2, 3, 3,
3};
+
 static int qpnp_tm_read(struct qpnp_tm_chip *chip, u16 addr, u8
*data)
 {
    unsigned int val;
@@ -84,30 +93,59 @@ static int qpnp_tm_write(struct qpnp_tm_chip
*chip, u16 addr, u8 data)
    return regmap_write(chip->map, chip->base + addr, data);
 }
 
+/**
+ * qpnp_tm_get_temp_stage() - return over-temperature stage
+ * @chip:  Pointer to the qpnp_tm chip
+ *
+ * Return: stage (GEN1) or state (GEN2) on success, or errno on
failure.
+ */
+static int qpnp_tm_get_temp_stage(struct qpnp_tm_chip *chip)
+{
+   int ret;
+   u8 reg = 0;
+
+   ret = qpnp_tm_read(chip, QPNP_TM_REG_STATUS, );
+   if (ret < 0)
+   return ret;
+
+   if (chip->subtype == QPNP_TM_SUBTYPE_GEN1)
+   ret = reg & STATUS_GEN1_STAGE_MASK;
+   else
+   ret = (reg & STATUS_GEN2_STATE_MASK) >>
STATUS_GEN2_STATE_SHIFT;
+
+   return ret;
+}
+
 /*
  * This function updates the internal temp value based on the
  * current thermal stage and threshold as well as the previous stage
  */
 static int qpnp_tm_update_temp_no_adc(struct qpnp_tm_chip *chip)
 {
-   unsigned int stage;
+   unsigned int stage, stage_new, stage_old;
    int ret;
-   u8 reg = 0;
 
-   ret = qpnp_tm_read(chip, QPNP_TM_REG_STATUS, );
+   ret = qpnp_tm_get_temp_stage(chip);
    if (ret < 0)
    return ret;
+   stage = ret;
 
-   stage = reg & STATUS_STAGE_MASK;
+   if (chip->subtype == QPNP_TM_SUBTYPE_GEN1) {
+   stage_new = stage;
+   stage_old = chip->stage;
+   } else {
+   stage_new = alarm_state_map[stage];
+   stage_old = alarm_state_map[chip->stage];
+   }
 
-   if (stage > chip->stage) {
+   if (stage_new > stage_old) {
    /* increasing stage, use lower bound */
-   chip->temp = (stage - 1) * TEMP_STAGE_STEP +
+   chip->temp = (stage_new - 1) * TEMP_STAGE_STEP +
     chip->thresh * TEMP_THRESH_STEP +
     TEMP_STAGE_HYSTERESIS +

Re: [PATCH V1] thermal: qcom-spmi-temp-alarm: add support for GEN2 PMIC peripherals

[kgunda]

On 2017-08-16 17:53, kgu...@codeaurora.org wrote:

On 2017-08-08 13:42, Zhang Rui wrote:

On Thu, 2017-07-13 at 17:39 +0530, Kiran Gunda wrote:

From: David Collins 

Add support for the TEMP_ALARM GEN2 PMIC peripheral subtype.  The
GEN2 subtype defines an over temperature state with hysteresis
instead of stage in the status register.  There are two GEN2
states corresponding to stages 1 and 2.

Signed-off-by: David Collins 
Signed-off-by: Kiran Gunda 


Ivan,

can you please review this patch and let me know your opinion?

thanks,
rui


Ivan,
Could you please review this patch ?

Thanks,
Kiran


Looks like Ivan is no more reviewing the patches for qcom.
Adding Bjorn and Stephen Boyd for the review.

Thanks,
Kiran

---
 drivers/thermal/qcom-spmi-temp-alarm.c | 92
++
 1 file changed, 71 insertions(+), 21 deletions(-)

diff --git a/drivers/thermal/qcom-spmi-temp-alarm.c
b/drivers/thermal/qcom-spmi-temp-alarm.c
index f502419..a5e17ba 100644
--- a/drivers/thermal/qcom-spmi-temp-alarm.c
+++ b/drivers/thermal/qcom-spmi-temp-alarm.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2011-2015, The Linux Foundation. All rights
reserved.
+ * Copyright (c) 2011-2015, 2017, The Linux Foundation. All rights
reserved.
  *
  * This program is free software; you can redistribute it and/or
modify
  * it under the terms of the GNU General Public License version 2
and
@@ -11,6 +11,7 @@
  * GNU General Public License for more details.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -29,13 +30,17 @@
 #define QPNP_TM_REG_ALARM_CTRL 0x46
 
 #define QPNP_TM_TYPE   0x09
-#define QPNP_TM_SUBTYPE0x08
+#define QPNP_TM_SUBTYPE_GEN1   0x08
+#define QPNP_TM_SUBTYPE_GEN2   0x09
 
-#define STATUS_STAGE_MASK  0x03
+#define STATUS_GEN1_STAGE_MASK GENMASK(1, 0)
+#define STATUS_GEN2_STATE_MASK GENMASK(6, 4)
+#define STATUS_GEN2_STATE_SHIFT4
 
-#define SHUTDOWN_CTRL1_THRESHOLD_MASK  0x03
+#define SHUTDOWN_CTRL1_OVERRIDE_MASK   GENMASK(7, 6)
+#define SHUTDOWN_CTRL1_THRESHOLD_MASK  GENMASK(1, 0)
 
-#define ALARM_CTRL_FORCE_ENABLE0x80
+#define ALARM_CTRL_FORCE_ENABLEBIT(7)
 
 /*
  * Trip point values based on threshold control
@@ -58,6 +63,7 @@
 struct qpnp_tm_chip {
    struct regmap   *map;
    struct thermal_zone_device  *tz_dev;
+   unsigned intsubtype;
    longtemp;
    unsigned intthresh;
    unsigned intstage;
@@ -66,6 +72,9 @@ struct qpnp_tm_chip {
    struct iio_channel  *adc;
 };
 
+/* This array maps from GEN2 alarm state to GEN1 alarm stage */
+static const unsigned int alarm_state_map[8] = {0, 1, 1, 2, 2, 3, 3,
3};
+
 static int qpnp_tm_read(struct qpnp_tm_chip *chip, u16 addr, u8
*data)
 {
    unsigned int val;
@@ -84,30 +93,59 @@ static int qpnp_tm_write(struct qpnp_tm_chip
*chip, u16 addr, u8 data)
    return regmap_write(chip->map, chip->base + addr, data);
 }
 
+/**
+ * qpnp_tm_get_temp_stage() - return over-temperature stage
+ * @chip:  Pointer to the qpnp_tm chip
+ *
+ * Return: stage (GEN1) or state (GEN2) on success, or errno on
failure.
+ */
+static int qpnp_tm_get_temp_stage(struct qpnp_tm_chip *chip)
+{
+   int ret;
+   u8 reg = 0;
+
+   ret = qpnp_tm_read(chip, QPNP_TM_REG_STATUS, );
+   if (ret < 0)
+   return ret;
+
+   if (chip->subtype == QPNP_TM_SUBTYPE_GEN1)
+   ret = reg & STATUS_GEN1_STAGE_MASK;
+   else
+   ret = (reg & STATUS_GEN2_STATE_MASK) >>
STATUS_GEN2_STATE_SHIFT;
+
+   return ret;
+}
+
 /*
  * This function updates the internal temp value based on the
  * current thermal stage and threshold as well as the previous stage
  */
 static int qpnp_tm_update_temp_no_adc(struct qpnp_tm_chip *chip)
 {
-   unsigned int stage;
+   unsigned int stage, stage_new, stage_old;
    int ret;
-   u8 reg = 0;
 
-   ret = qpnp_tm_read(chip, QPNP_TM_REG_STATUS, );
+   ret = qpnp_tm_get_temp_stage(chip);
    if (ret < 0)
    return ret;
+   stage = ret;
 
-   stage = reg & STATUS_STAGE_MASK;
+   if (chip->subtype == QPNP_TM_SUBTYPE_GEN1) {
+   stage_new = stage;
+   stage_old = chip->stage;
+   } else {
+   stage_new = alarm_state_map[stage];
+   stage_old = alarm_state_map[chip->stage];
+   }
 
-   if (stage > chip->stage) {
+   if (stage_new > stage_old) {
    /* increasing stage, use lower bound */
-   chip->temp = (stage - 1) * TEMP_STAGE_STEP +
+   chip->temp = (stage_new - 1) * TEMP_STAGE_STEP +
     chip->thresh * TEMP_THRESH_STEP +
     TEMP_STAGE_HYSTERESIS +
TEMP_THRESH_MIN;
-   } else if (stage < chip->stage) {
+   } 

Re: [PATCH V1] thermal: qcom-spmi-temp-alarm: add support for GEN2 PMIC peripherals

[kgunda]

On 2017-08-08 13:42, Zhang Rui wrote:

On Thu, 2017-07-13 at 17:39 +0530, Kiran Gunda wrote:

From: David Collins 

Add support for the TEMP_ALARM GEN2 PMIC peripheral subtype.  The
GEN2 subtype defines an over temperature state with hysteresis
instead of stage in the status register.  There are two GEN2
states corresponding to stages 1 and 2.

Signed-off-by: David Collins 
Signed-off-by: Kiran Gunda 


Ivan,

can you please review this patch and let me know your opinion?

thanks,
rui


Ivan,
Could you please review this patch ?

Thanks,
Kiran

---
 drivers/thermal/qcom-spmi-temp-alarm.c | 92
++
 1 file changed, 71 insertions(+), 21 deletions(-)

diff --git a/drivers/thermal/qcom-spmi-temp-alarm.c
b/drivers/thermal/qcom-spmi-temp-alarm.c
index f502419..a5e17ba 100644
--- a/drivers/thermal/qcom-spmi-temp-alarm.c
+++ b/drivers/thermal/qcom-spmi-temp-alarm.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2011-2015, The Linux Foundation. All rights
reserved.
+ * Copyright (c) 2011-2015, 2017, The Linux Foundation. All rights
reserved.
  *
  * This program is free software; you can redistribute it and/or
modify
  * it under the terms of the GNU General Public License version 2
and
@@ -11,6 +11,7 @@
  * GNU General Public License for more details.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -29,13 +30,17 @@
 #define QPNP_TM_REG_ALARM_CTRL 0x46
 
 #define QPNP_TM_TYPE   0x09
-#define QPNP_TM_SUBTYPE0x08
+#define QPNP_TM_SUBTYPE_GEN1   0x08
+#define QPNP_TM_SUBTYPE_GEN2   0x09
 
-#define STATUS_STAGE_MASK  0x03
+#define STATUS_GEN1_STAGE_MASK GENMASK(1, 0)
+#define STATUS_GEN2_STATE_MASK GENMASK(6, 4)
+#define STATUS_GEN2_STATE_SHIFT4
 
-#define SHUTDOWN_CTRL1_THRESHOLD_MASK  0x03
+#define SHUTDOWN_CTRL1_OVERRIDE_MASK   GENMASK(7, 6)
+#define SHUTDOWN_CTRL1_THRESHOLD_MASK  GENMASK(1, 0)
 
-#define ALARM_CTRL_FORCE_ENABLE0x80
+#define ALARM_CTRL_FORCE_ENABLEBIT(7)
 
 /*
  * Trip point values based on threshold control
@@ -58,6 +63,7 @@
 struct qpnp_tm_chip {
    struct regmap   *map;
    struct thermal_zone_device  *tz_dev;
+   unsigned intsubtype;
    longtemp;
    unsigned intthresh;
    unsigned intstage;
@@ -66,6 +72,9 @@ struct qpnp_tm_chip {
    struct iio_channel  *adc;
 };
 
+/* This array maps from GEN2 alarm state to GEN1 alarm stage */
+static const unsigned int alarm_state_map[8] = {0, 1, 1, 2, 2, 3, 3,
3};
+
 static int qpnp_tm_read(struct qpnp_tm_chip *chip, u16 addr, u8
*data)
 {
    unsigned int val;
@@ -84,30 +93,59 @@ static int qpnp_tm_write(struct qpnp_tm_chip
*chip, u16 addr, u8 data)
    return regmap_write(chip->map, chip->base + addr, data);
 }
 
+/**
+ * qpnp_tm_get_temp_stage() - return over-temperature stage
+ * @chip:  Pointer to the qpnp_tm chip
+ *
+ * Return: stage (GEN1) or state (GEN2) on success, or errno on
failure.
+ */
+static int qpnp_tm_get_temp_stage(struct qpnp_tm_chip *chip)
+{
+   int ret;
+   u8 reg = 0;
+
+   ret = qpnp_tm_read(chip, QPNP_TM_REG_STATUS, );
+   if (ret < 0)
+   return ret;
+
+   if (chip->subtype == QPNP_TM_SUBTYPE_GEN1)
+   ret = reg & STATUS_GEN1_STAGE_MASK;
+   else
+   ret = (reg & STATUS_GEN2_STATE_MASK) >>
STATUS_GEN2_STATE_SHIFT;
+
+   return ret;
+}
+
 /*
  * This function updates the internal temp value based on the
  * current thermal stage and threshold as well as the previous stage
  */
 static int qpnp_tm_update_temp_no_adc(struct qpnp_tm_chip *chip)
 {
-   unsigned int stage;
+   unsigned int stage, stage_new, stage_old;
    int ret;
-   u8 reg = 0;
 
-   ret = qpnp_tm_read(chip, QPNP_TM_REG_STATUS, );
+   ret = qpnp_tm_get_temp_stage(chip);
    if (ret < 0)
    return ret;
+   stage = ret;
 
-   stage = reg & STATUS_STAGE_MASK;
+   if (chip->subtype == QPNP_TM_SUBTYPE_GEN1) {
+   stage_new = stage;
+   stage_old = chip->stage;
+   } else {
+   stage_new = alarm_state_map[stage];
+   stage_old = alarm_state_map[chip->stage];
+   }
 
-   if (stage > chip->stage) {
+   if (stage_new > stage_old) {
    /* increasing stage, use lower bound */
-   chip->temp = (stage - 1) * TEMP_STAGE_STEP +
+   chip->temp = (stage_new - 1) * TEMP_STAGE_STEP +
     chip->thresh * TEMP_THRESH_STEP +
     TEMP_STAGE_HYSTERESIS +
TEMP_THRESH_MIN;
-   } else if (stage < chip->stage) {
+   } else if (stage_new < stage_old) {
    /* decreasing stage, use upper bound */
- 

Re: [PATCH V1] thermal: qcom-spmi-temp-alarm: add support for GEN2 PMIC peripherals

[kgunda]

On 2017-08-08 13:42, Zhang Rui wrote:

On Thu, 2017-07-13 at 17:39 +0530, Kiran Gunda wrote:

From: David Collins 

Add support for the TEMP_ALARM GEN2 PMIC peripheral subtype.  The
GEN2 subtype defines an over temperature state with hysteresis
instead of stage in the status register.  There are two GEN2
states corresponding to stages 1 and 2.

Signed-off-by: David Collins 
Signed-off-by: Kiran Gunda 


Ivan,

can you please review this patch and let me know your opinion?

thanks,
rui


Ivan,
Could you please review this patch ?

Thanks,
Kiran

---
 drivers/thermal/qcom-spmi-temp-alarm.c | 92
++
 1 file changed, 71 insertions(+), 21 deletions(-)

diff --git a/drivers/thermal/qcom-spmi-temp-alarm.c
b/drivers/thermal/qcom-spmi-temp-alarm.c
index f502419..a5e17ba 100644
--- a/drivers/thermal/qcom-spmi-temp-alarm.c
+++ b/drivers/thermal/qcom-spmi-temp-alarm.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2011-2015, The Linux Foundation. All rights
reserved.
+ * Copyright (c) 2011-2015, 2017, The Linux Foundation. All rights
reserved.
  *
  * This program is free software; you can redistribute it and/or
modify
  * it under the terms of the GNU General Public License version 2
and
@@ -11,6 +11,7 @@
  * GNU General Public License for more details.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -29,13 +30,17 @@
 #define QPNP_TM_REG_ALARM_CTRL 0x46
 
 #define QPNP_TM_TYPE   0x09
-#define QPNP_TM_SUBTYPE0x08
+#define QPNP_TM_SUBTYPE_GEN1   0x08
+#define QPNP_TM_SUBTYPE_GEN2   0x09
 
-#define STATUS_STAGE_MASK  0x03
+#define STATUS_GEN1_STAGE_MASK GENMASK(1, 0)
+#define STATUS_GEN2_STATE_MASK GENMASK(6, 4)
+#define STATUS_GEN2_STATE_SHIFT4
 
-#define SHUTDOWN_CTRL1_THRESHOLD_MASK  0x03
+#define SHUTDOWN_CTRL1_OVERRIDE_MASK   GENMASK(7, 6)
+#define SHUTDOWN_CTRL1_THRESHOLD_MASK  GENMASK(1, 0)
 
-#define ALARM_CTRL_FORCE_ENABLE0x80
+#define ALARM_CTRL_FORCE_ENABLEBIT(7)
 
 /*
  * Trip point values based on threshold control
@@ -58,6 +63,7 @@
 struct qpnp_tm_chip {
    struct regmap   *map;
    struct thermal_zone_device  *tz_dev;
+   unsigned intsubtype;
    longtemp;
    unsigned intthresh;
    unsigned intstage;
@@ -66,6 +72,9 @@ struct qpnp_tm_chip {
    struct iio_channel  *adc;
 };
 
+/* This array maps from GEN2 alarm state to GEN1 alarm stage */
+static const unsigned int alarm_state_map[8] = {0, 1, 1, 2, 2, 3, 3,
3};
+
 static int qpnp_tm_read(struct qpnp_tm_chip *chip, u16 addr, u8
*data)
 {
    unsigned int val;
@@ -84,30 +93,59 @@ static int qpnp_tm_write(struct qpnp_tm_chip
*chip, u16 addr, u8 data)
    return regmap_write(chip->map, chip->base + addr, data);
 }
 
+/**
+ * qpnp_tm_get_temp_stage() - return over-temperature stage
+ * @chip:  Pointer to the qpnp_tm chip
+ *
+ * Return: stage (GEN1) or state (GEN2) on success, or errno on
failure.
+ */
+static int qpnp_tm_get_temp_stage(struct qpnp_tm_chip *chip)
+{
+   int ret;
+   u8 reg = 0;
+
+   ret = qpnp_tm_read(chip, QPNP_TM_REG_STATUS, );
+   if (ret < 0)
+   return ret;
+
+   if (chip->subtype == QPNP_TM_SUBTYPE_GEN1)
+   ret = reg & STATUS_GEN1_STAGE_MASK;
+   else
+   ret = (reg & STATUS_GEN2_STATE_MASK) >>
STATUS_GEN2_STATE_SHIFT;
+
+   return ret;
+}
+
 /*
  * This function updates the internal temp value based on the
  * current thermal stage and threshold as well as the previous stage
  */
 static int qpnp_tm_update_temp_no_adc(struct qpnp_tm_chip *chip)
 {
-   unsigned int stage;
+   unsigned int stage, stage_new, stage_old;
    int ret;
-   u8 reg = 0;
 
-   ret = qpnp_tm_read(chip, QPNP_TM_REG_STATUS, );
+   ret = qpnp_tm_get_temp_stage(chip);
    if (ret < 0)
    return ret;
+   stage = ret;
 
-   stage = reg & STATUS_STAGE_MASK;
+   if (chip->subtype == QPNP_TM_SUBTYPE_GEN1) {
+   stage_new = stage;
+   stage_old = chip->stage;
+   } else {
+   stage_new = alarm_state_map[stage];
+   stage_old = alarm_state_map[chip->stage];
+   }
 
-   if (stage > chip->stage) {
+   if (stage_new > stage_old) {
    /* increasing stage, use lower bound */
-   chip->temp = (stage - 1) * TEMP_STAGE_STEP +
+   chip->temp = (stage_new - 1) * TEMP_STAGE_STEP +
     chip->thresh * TEMP_THRESH_STEP +
     TEMP_STAGE_HYSTERESIS +
TEMP_THRESH_MIN;
-   } else if (stage < chip->stage) {
+   } else if (stage_new < stage_old) {
    /* decreasing stage, use upper bound */
-   chip->temp = stage * TEMP_STAGE_STEP +
+   chip->temp = 

Re: [PATCH V2 00/12]: spmi: pmic-arb: Support for HW v5 and other fixes

[kgunda]

On 2017-07-28 12:40, Kiran Gunda wrote:

v2:

* [PATCH V2 04/12] spmi: pmic-arb: optimize qpnpint_irq_set_type 
function

  Added Stephen's Reviewed-by tag.

* [PATCH V2 05/12] spmi: pmic-arb: fix memory allocation for 
mapping_table

  Added Fixes tag and Stephen's Reviewed-by tag.

* [PATCH V2 02/12] spmi: pmic-arb: rename pa_xx to pmic_arb_xx and 
other cleanup

  Added Stephen's Reviewed-by tag.

* [PATCH V2 06/12] spmi: pmic-arb: replace the writel_relaxed with 
__raw_writel

  Added Fixes tag.

* [PATCH V2 03/12] spmi: pmic-arb: clean up pmic_arb_find_apid function
  Fixed alignement issue and added Stephen's reviewed-by tag.

Now all the patches in this series are reviewed and acked by Stephen
boyd and are ready
for merge.

v1:

* This patch series add the support for pmic arbiter hardware v5 along 
with

  the few bug fixes and code cleanup.

* This new series is the combined series of
  [PATCH V3 0/5]: spmi: pmic-arb: Fixup patches and
  [PATCH V4 0/4]: spmi: pmic-arb: support for V5 HW and bug fixes, 
which are

  being reviewed by Stephen Boyd.

* This series depends on the below patch uploaded by Stephen Boyd
  https://patchwork.kernel.org/patch/9810723/.

David Collins (1):
  spmi: pmic-arb: add support for HW version 5

Fenglin Wu (1):
  spmi: pmic-arb: Remove checking opc value not less than 0

Kiran Gunda (10):
  spmi: pmic-arb: remove the read/write access checks
  spmi: pmic-arb: rename pa_xx to pmic_arb_xx and other cleanup
  spmi: pmic-arb: clean up pmic_arb_find_apid function
  spmi: pmic-arb: optimize qpnpint_irq_set_type function
  spmi: pmic-arb: fix memory allocation for mapping_table
  spmi: pmic-arb: replace the writel_relaxed with __raw_writel
  spmi: pmic-arb: return the value instead of passing by pointer
  spmi: pmic-arb: use irq_chip callback to set spmi irq wakeup
capability
  spmi: pmic-arb: return __iomem pointer instead of offset
  spmi: pmic-arb: fix a possible null pointer dereference

 drivers/spmi/spmi-pmic-arb.c | 825 
+--

 1 file changed, 481 insertions(+), 344 deletions(-)

Hi Greg,
Could you please pull this patch series in to your tree? All these 
patches

are reviewed and acked by Stephen boyd.

Re: [PATCH V2 00/12]: spmi: pmic-arb: Support for HW v5 and other fixes

[kgunda]

On 2017-07-28 12:40, Kiran Gunda wrote:

v2:

* [PATCH V2 04/12] spmi: pmic-arb: optimize qpnpint_irq_set_type 
function

  Added Stephen's Reviewed-by tag.

* [PATCH V2 05/12] spmi: pmic-arb: fix memory allocation for 
mapping_table

  Added Fixes tag and Stephen's Reviewed-by tag.

* [PATCH V2 02/12] spmi: pmic-arb: rename pa_xx to pmic_arb_xx and 
other cleanup

  Added Stephen's Reviewed-by tag.

* [PATCH V2 06/12] spmi: pmic-arb: replace the writel_relaxed with 
__raw_writel

  Added Fixes tag.

* [PATCH V2 03/12] spmi: pmic-arb: clean up pmic_arb_find_apid function
  Fixed alignement issue and added Stephen's reviewed-by tag.

Now all the patches in this series are reviewed and acked by Stephen
boyd and are ready
for merge.

v1:

* This patch series add the support for pmic arbiter hardware v5 along 
with

  the few bug fixes and code cleanup.

* This new series is the combined series of
  [PATCH V3 0/5]: spmi: pmic-arb: Fixup patches and
  [PATCH V4 0/4]: spmi: pmic-arb: support for V5 HW and bug fixes, 
which are

  being reviewed by Stephen Boyd.

* This series depends on the below patch uploaded by Stephen Boyd
  https://patchwork.kernel.org/patch/9810723/.

David Collins (1):
  spmi: pmic-arb: add support for HW version 5

Fenglin Wu (1):
  spmi: pmic-arb: Remove checking opc value not less than 0

Kiran Gunda (10):
  spmi: pmic-arb: remove the read/write access checks
  spmi: pmic-arb: rename pa_xx to pmic_arb_xx and other cleanup
  spmi: pmic-arb: clean up pmic_arb_find_apid function
  spmi: pmic-arb: optimize qpnpint_irq_set_type function
  spmi: pmic-arb: fix memory allocation for mapping_table
  spmi: pmic-arb: replace the writel_relaxed with __raw_writel
  spmi: pmic-arb: return the value instead of passing by pointer
  spmi: pmic-arb: use irq_chip callback to set spmi irq wakeup
capability
  spmi: pmic-arb: return __iomem pointer instead of offset
  spmi: pmic-arb: fix a possible null pointer dereference

 drivers/spmi/spmi-pmic-arb.c | 825 
+--

 1 file changed, 481 insertions(+), 344 deletions(-)

Hi Greg,
Could you please pull this patch series in to your tree? All these 
patches

are reviewed and acked by Stephen boyd.

Re: [PATCH V1 02/12] spmi: pmic-arb: rename pa_xx to pmic_arb_xx and other cleanup

[kgunda]

On 2017-07-28 05:30, Stephen Boyd wrote:

On 07/20, Kiran Gunda wrote:

This patch cleans up the following.

- Rename the "pa" to "pmic_arb".
- Rename the spmi_pmic_arb *dev to spmi_pmic_arb *pmic_arb.
- Rename the pa_{read,write}_data() functions to
  pmic_arb_{read,write}_data().
- Rename channel to APID.
- Rename the HWIRQ_*() macros to hwirq_to_*().

Signed-off-by: Kiran Gunda 
---


Reviewed-by: Stephen Boyd 

Thanks. objdiff doesn't show any diff anymore so I'm much more
confident this doesn't change any functionality.

Thanks for introducing me a nice tool !

Re: [PATCH V1 02/12] spmi: pmic-arb: rename pa_xx to pmic_arb_xx and other cleanup

[kgunda]

On 2017-07-28 05:30, Stephen Boyd wrote:

On 07/20, Kiran Gunda wrote:

This patch cleans up the following.

- Rename the "pa" to "pmic_arb".
- Rename the spmi_pmic_arb *dev to spmi_pmic_arb *pmic_arb.
- Rename the pa_{read,write}_data() functions to
  pmic_arb_{read,write}_data().
- Rename channel to APID.
- Rename the HWIRQ_*() macros to hwirq_to_*().

Signed-off-by: Kiran Gunda 
---


Reviewed-by: Stephen Boyd 

Thanks. objdiff doesn't show any diff anymore so I'm much more
confident this doesn't change any functionality.

Thanks for introducing me a nice tool !

Re: [PATCH V1 06/12] spmi: pmic-arb: replace the writel_relaxed with __raw_writel

[kgunda]

On 2017-07-28 05:31, Stephen Boyd wrote:

On 07/20, Kiran Gunda wrote:

Replace the writel_relaxed with __raw_writel to avoid byte swapping
in pmic_arb_write_data() function. That way the code is independent
of the CPU endianness.

Signed-off-by: Kiran Gunda 
Reviewed-by: Stephen Boyd 


This also needs a Fixes tag.

Fixes: 111a10bf3e53 ("spmi: pmic-arb: rename spmi_pmic_arb_dev to
spmi_pmic_arb")

Sure. will add the tag and send the patch.

Re: [PATCH V1 06/12] spmi: pmic-arb: replace the writel_relaxed with __raw_writel

[kgunda]

On 2017-07-28 05:31, Stephen Boyd wrote:

On 07/20, Kiran Gunda wrote:

Replace the writel_relaxed with __raw_writel to avoid byte swapping
in pmic_arb_write_data() function. That way the code is independent
of the CPU endianness.

Signed-off-by: Kiran Gunda 
Reviewed-by: Stephen Boyd 


This also needs a Fixes tag.

Fixes: 111a10bf3e53 ("spmi: pmic-arb: rename spmi_pmic_arb_dev to
spmi_pmic_arb")

Sure. will add the tag and send the patch.

Re: [PATCH V1 03/12] spmi: pmic-arb: clean up pmic_arb_find_apid function

[kgunda]

On 2017-07-28 06:48, Stephen Boyd wrote:

On 07/20, Kiran Gunda wrote:

Clean up the pmic_arb_find_apid() by using the local
variables to improve the code readability.

Signed-off-by: Kiran Gunda 
---


Reviewed-by: Stephen Boyd 

One nit below:


break;

regval = readl_relaxed(pmic_arb->cnfg +
- SPMI_OWNERSHIP_TABLE_REG(apid));
-   pmic_arb->apid_data[apid].owner =
-   SPMI_OWNERSHIP_PERIPH2OWNER(regval);
+   SPMI_OWNERSHIP_TABLE_REG(apid));


This should be 7 spaces and not a tab? Originally looks like it
was 6 spaces

Will fix it and send the next patch.

Re: [PATCH V1 03/12] spmi: pmic-arb: clean up pmic_arb_find_apid function

[kgunda]

On 2017-07-28 06:48, Stephen Boyd wrote:

On 07/20, Kiran Gunda wrote:

Clean up the pmic_arb_find_apid() by using the local
variables to improve the code readability.

Signed-off-by: Kiran Gunda 
---


Reviewed-by: Stephen Boyd 

One nit below:


break;

regval = readl_relaxed(pmic_arb->cnfg +
- SPMI_OWNERSHIP_TABLE_REG(apid));
-   pmic_arb->apid_data[apid].owner =
-   SPMI_OWNERSHIP_PERIPH2OWNER(regval);
+   SPMI_OWNERSHIP_TABLE_REG(apid));


This should be 7 spaces and not a tab? Originally looks like it
was 6 spaces

Will fix it and send the next patch.

Re: [PATCH V1 05/12] spmi: pmic-arb: fix memory allocation for mapping_table

[kgunda]

On 2017-07-28 05:19, Stephen Boyd wrote:

On 07/20, Kiran Gunda wrote:

Allocate the correct memory size (max_pmic_peripherals) for the
mapping_table that holds the apid to ppid mapping. Also use a local
variable for mapping_table for better alignment of the code.

Signed-off-by: Kiran Gunda 


This needs a

Fixes: 987a9f128b8a ("spmi: pmic-arb: Support more than 128 
peripherals")


right?

Yes. I will keep the tag and send it again.

Re: [PATCH V1 05/12] spmi: pmic-arb: fix memory allocation for mapping_table

[kgunda]

On 2017-07-28 05:19, Stephen Boyd wrote:

On 07/20, Kiran Gunda wrote:

Allocate the correct memory size (max_pmic_peripherals) for the
mapping_table that holds the apid to ppid mapping. Also use a local
variable for mapping_table for better alignment of the code.

Signed-off-by: Kiran Gunda 


This needs a

Fixes: 987a9f128b8a ("spmi: pmic-arb: Support more than 128 
peripherals")


right?

Yes. I will keep the tag and send it again.

Re: [PATCH V4 0/4]: spmi: pmic-arb: support for V5 HW and bug fixes

[kgunda]

On 2017-07-19 03:47, Stephen Boyd wrote:

On 07/18, Kiran Gunda wrote:

v4:
* spmi: pmic-arb: add support for HW version 5
  Clean-up as per Stephen's comments

v3:
* spmi: pmic-arb: add support for HW version 5
Modified #define INVALID (-1) to
#define INVALID_EE0xFF.

v2:
* spmi: pmic-arb: return __iomem pointer instead of offset
  Added Stephen's reviewed-by tag.

* spmi: pmic-arb: fix a possible null pointer dereference
  Added Stephen's reviewed-by tag.

* spmi: pmic-arb: add support for HW version 5
  Modified the pmic_arb_offset_v5 function to return the offset 
instead

  of passed by a pointer.

* spmi: pmic-arb: Remove checking opc value not less than 0
  Added Stephen's reviewed-by tag.
  Added my sign-off tag.

v1:

This patch series add the support for pmic arbiter hardware v5 along 
with

the few bug fixes and code cleanup.

This patch series is dependent on the below patches and can be merged
cleanly only after picking the below patches in to the tree.


Can you combine the two series? It's really confusing why there
are two patch series from you for the same driver. Presumably one
of the series needs to be applied before the other, so putting
them into one series makes that clear what the order is.
I had two series just to give the information about the fix-up patches 
for the
previously merged patches and other new patches. Anyways, having a 
single series will

be easy and clear to everyone. Will combine them.

Re: [PATCH V4 0/4]: spmi: pmic-arb: support for V5 HW and bug fixes

[kgunda]

On 2017-07-19 03:47, Stephen Boyd wrote:

On 07/18, Kiran Gunda wrote:

v4:
* spmi: pmic-arb: add support for HW version 5
  Clean-up as per Stephen's comments

v3:
* spmi: pmic-arb: add support for HW version 5
Modified #define INVALID (-1) to
#define INVALID_EE0xFF.

v2:
* spmi: pmic-arb: return __iomem pointer instead of offset
  Added Stephen's reviewed-by tag.

* spmi: pmic-arb: fix a possible null pointer dereference
  Added Stephen's reviewed-by tag.

* spmi: pmic-arb: add support for HW version 5
  Modified the pmic_arb_offset_v5 function to return the offset 
instead

  of passed by a pointer.

* spmi: pmic-arb: Remove checking opc value not less than 0
  Added Stephen's reviewed-by tag.
  Added my sign-off tag.

v1:

This patch series add the support for pmic arbiter hardware v5 along 
with

the few bug fixes and code cleanup.

This patch series is dependent on the below patches and can be merged
cleanly only after picking the below patches in to the tree.


Can you combine the two series? It's really confusing why there
are two patch series from you for the same driver. Presumably one
of the series needs to be applied before the other, so putting
them into one series makes that clear what the order is.
I had two series just to give the information about the fix-up patches 
for the
previously merged patches and other new patches. Anyways, having a 
single series will

be easy and clear to everyone. Will combine them.