[PATCH v2 2/2] dt: Add bindings for IDT VersaClock 5P49V5925

[Vladimir Barinov]

From: Vladimir Barinov <vladimir.barinov+rene...@cogentembedded.com>

IDT VersaClock 5 5P49V5925 has 5 clock outputs, 4 fractional dividers.
Input clock source can be taken only from external reference clock.

Signed-off-by: Vladimir Barinov <vladimir.barinov+rene...@cogentembedded.com>
---
Changes in version 2:
- fixed typo in patch header: VC5 has 5 clock outputs
- rebased against patch:
  [V3,7/8] clk: vc5: Add bindings for IDT VersaClock 5P49V6901

 Documentation/devicetree/bindings/clock/idt,versaclock5.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.txt 
b/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
index 66ef0a0..05a245c 100644
--- a/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
+++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
@@ -8,6 +8,7 @@ generators providing from 3 to 12 output clocks.
 Required properties:
 - compatible:  shall be one of
"idt,5p49v5923"
+   "idt,5p49v5925"
"idt,5p49v5933"
"idt,5p49v5935"
"idt,5p49v6901"
@@ -15,6 +16,7 @@ Required properties:
 - #clock-cells:from common clock binding; shall be set to 1.
 - clocks:  from common clock binding; list of parent clock handles,
- 5p49v5923 and
+ 5p49v5925 and
  5p49v6901: (required) either or both of XTAL or CLKIN
reference clock.
- 5p49v5933 and
@@ -23,6 +25,7 @@ Required properties:
clock.
 - clock-names: from common clock binding; clock input names, can be
- 5p49v5923 and
+ 5p49v5925 and
  5p49v6901: (required) either or both of "xin", "clkin".
- 5p49v5933 and
- 5p49v5935: (optional) property not present or "clkin".
@@ -42,6 +45,7 @@ clock specifier, the following mapping applies:
1 -- OUT1
2 -- OUT4
 
+5P49V5925 and
 5P49V5935:
0 -- OUT0_SEL_I2CB
1 -- OUT1
-- 
1.9.1

[PATCH v2 1/2] clk: vc5: Add support for IDT VersaClock 5P49V5925

[Vladimir Barinov]

From: Vladimir Barinov <vladimir.barinov+rene...@cogentembedded.com>

Update IDT VersaClock 5 driver to support 5P49V5925. This chip has only
external clock input, four fractional dividers (FODs) and five clock
outputs (four universal clock outputs and one reference clock output at
OUT0_SELB_I2C).

Signed-off-by: Vladimir Barinov <vladimir.barinov+rene...@cogentembedded.com>
Reviewed-by: Marek Vasut <marek.va...@gmail.com>
---
Changes in version 2:
- rebased against patch:
  [V3,8/8] clk: vc5: Add support for IDT VersaClock 5P49V6901

 drivers/clk/clk-versaclock5.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c
index c894db2..1808a55 100644
--- a/drivers/clk/clk-versaclock5.c
+++ b/drivers/clk/clk-versaclock5.c
@@ -129,6 +129,7 @@
 /* Supported IDT VC5 models. */
 enum vc5_model {
IDT_VC5_5P49V5923,
+   IDT_VC5_5P49V5925,
IDT_VC5_5P49V5933,
IDT_VC5_5P49V5935,
IDT_VC6_5P49V6901,
@@ -686,6 +687,7 @@ static int vc5_map_index_to_output(const enum vc5_model 
model,
case IDT_VC5_5P49V5933:
return (n == 0) ? 0 : 3;
case IDT_VC5_5P49V5923:
+   case IDT_VC5_5P49V5925:
case IDT_VC5_5P49V5935:
case IDT_VC6_5P49V6901:
default:
@@ -911,6 +913,13 @@ static int vc5_remove(struct i2c_client *client)
.flags = 0,
 };
 
+static const struct vc5_chip_info idt_5p49v5925_info = {
+   .model = IDT_VC5_5P49V5925,
+   .clk_fod_cnt = 4,
+   .clk_out_cnt = 5,
+   .flags = 0,
+};
+
 static const struct vc5_chip_info idt_5p49v5933_info = {
.model = IDT_VC5_5P49V5933,
.clk_fod_cnt = 2,
@@ -934,6 +943,7 @@ static int vc5_remove(struct i2c_client *client)
 
 static const struct i2c_device_id vc5_id[] = {
{ "5p49v5923", .driver_data = IDT_VC5_5P49V5923 },
+   { "5p49v5925", .driver_data = IDT_VC5_5P49V5925 },
{ "5p49v5933", .driver_data = IDT_VC5_5P49V5933 },
{ "5p49v5935", .driver_data = IDT_VC5_5P49V5935 },
{ "5p49v6901", .driver_data = IDT_VC6_5P49V6901 },
@@ -943,6 +953,7 @@ static int vc5_remove(struct i2c_client *client)
 
 static const struct of_device_id clk_vc5_of_match[] = {
{ .compatible = "idt,5p49v5923", .data = _5p49v5923_info },
+   { .compatible = "idt,5p49v5925", .data = _5p49v5925_info },
{ .compatible = "idt,5p49v5933", .data = _5p49v5933_info },
{ .compatible = "idt,5p49v5935", .data = _5p49v5935_info },
{ .compatible = "idt,5p49v6901", .data = _5p49v6901_info },
-- 
1.9.1

[PATCH v2 2/2] dt: Add bindings for IDT VersaClock 5P49V5925

[Vladimir Barinov]

From: Vladimir Barinov 

IDT VersaClock 5 5P49V5925 has 5 clock outputs, 4 fractional dividers.
Input clock source can be taken only from external reference clock.

Signed-off-by: Vladimir Barinov 
---
Changes in version 2:
- fixed typo in patch header: VC5 has 5 clock outputs
- rebased against patch:
  [V3,7/8] clk: vc5: Add bindings for IDT VersaClock 5P49V6901

 Documentation/devicetree/bindings/clock/idt,versaclock5.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.txt 
b/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
index 66ef0a0..05a245c 100644
--- a/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
+++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
@@ -8,6 +8,7 @@ generators providing from 3 to 12 output clocks.
 Required properties:
 - compatible:  shall be one of
"idt,5p49v5923"
+   "idt,5p49v5925"
"idt,5p49v5933"
"idt,5p49v5935"
"idt,5p49v6901"
@@ -15,6 +16,7 @@ Required properties:
 - #clock-cells:from common clock binding; shall be set to 1.
 - clocks:  from common clock binding; list of parent clock handles,
- 5p49v5923 and
+ 5p49v5925 and
  5p49v6901: (required) either or both of XTAL or CLKIN
reference clock.
- 5p49v5933 and
@@ -23,6 +25,7 @@ Required properties:
clock.
 - clock-names: from common clock binding; clock input names, can be
- 5p49v5923 and
+ 5p49v5925 and
  5p49v6901: (required) either or both of "xin", "clkin".
- 5p49v5933 and
- 5p49v5935: (optional) property not present or "clkin".
@@ -42,6 +45,7 @@ clock specifier, the following mapping applies:
1 -- OUT1
2 -- OUT4
 
+5P49V5925 and
 5P49V5935:
0 -- OUT0_SEL_I2CB
1 -- OUT1
-- 
1.9.1

[PATCH v2 1/2] clk: vc5: Add support for IDT VersaClock 5P49V5925

[Vladimir Barinov]

From: Vladimir Barinov 

Update IDT VersaClock 5 driver to support 5P49V5925. This chip has only
external clock input, four fractional dividers (FODs) and five clock
outputs (four universal clock outputs and one reference clock output at
OUT0_SELB_I2C).

Signed-off-by: Vladimir Barinov 
Reviewed-by: Marek Vasut 
---
Changes in version 2:
- rebased against patch:
  [V3,8/8] clk: vc5: Add support for IDT VersaClock 5P49V6901

 drivers/clk/clk-versaclock5.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c
index c894db2..1808a55 100644
--- a/drivers/clk/clk-versaclock5.c
+++ b/drivers/clk/clk-versaclock5.c
@@ -129,6 +129,7 @@
 /* Supported IDT VC5 models. */
 enum vc5_model {
IDT_VC5_5P49V5923,
+   IDT_VC5_5P49V5925,
IDT_VC5_5P49V5933,
IDT_VC5_5P49V5935,
IDT_VC6_5P49V6901,
@@ -686,6 +687,7 @@ static int vc5_map_index_to_output(const enum vc5_model 
model,
case IDT_VC5_5P49V5933:
return (n == 0) ? 0 : 3;
case IDT_VC5_5P49V5923:
+   case IDT_VC5_5P49V5925:
case IDT_VC5_5P49V5935:
case IDT_VC6_5P49V6901:
default:
@@ -911,6 +913,13 @@ static int vc5_remove(struct i2c_client *client)
.flags = 0,
 };
 
+static const struct vc5_chip_info idt_5p49v5925_info = {
+   .model = IDT_VC5_5P49V5925,
+   .clk_fod_cnt = 4,
+   .clk_out_cnt = 5,
+   .flags = 0,
+};
+
 static const struct vc5_chip_info idt_5p49v5933_info = {
.model = IDT_VC5_5P49V5933,
.clk_fod_cnt = 2,
@@ -934,6 +943,7 @@ static int vc5_remove(struct i2c_client *client)
 
 static const struct i2c_device_id vc5_id[] = {
{ "5p49v5923", .driver_data = IDT_VC5_5P49V5923 },
+   { "5p49v5925", .driver_data = IDT_VC5_5P49V5925 },
{ "5p49v5933", .driver_data = IDT_VC5_5P49V5933 },
{ "5p49v5935", .driver_data = IDT_VC5_5P49V5935 },
{ "5p49v6901", .driver_data = IDT_VC6_5P49V6901 },
@@ -943,6 +953,7 @@ static int vc5_remove(struct i2c_client *client)
 
 static const struct of_device_id clk_vc5_of_match[] = {
{ .compatible = "idt,5p49v5923", .data = _5p49v5923_info },
+   { .compatible = "idt,5p49v5925", .data = _5p49v5925_info },
{ .compatible = "idt,5p49v5933", .data = _5p49v5933_info },
{ .compatible = "idt,5p49v5935", .data = _5p49v5935_info },
{ .compatible = "idt,5p49v6901", .data = _5p49v6901_info },
-- 
1.9.1

[PATCH v2 0/2] clk: vc5: Add IDT VersaClock 5P49V5925

[Vladimir Barinov]

Hello,

This adds the folowing:
- Update IDT VersaClock 5 driver to support 5P49V5925
- Add bindings for IDT VersaClock 5P49V5925

This has the following dependency:
- [V3,7/8] clk: vc5: Add bindings for IDT VersaClock 5P49V6901
- [V3,8/8] clk: vc5: Add support for IDT VersaClock 5P49V6901

Vladimir Barinov (2):
[1/2] clk: vc5: Add support for IDT VersaClock 5P49V5925
[2/2] dt: Add bindings for IDT VersaClock 5P49V5925

---
This patchset is against the 'kernel/git/torvalds/linux.git' repo.

 Documentation/devicetree/bindings/clock/idt,versaclock5.txt |   11 +++
 drivers/clk/clk-versaclock5.c   |   11 +++
 2 files changed, 18 insertions(+), 4 deletions(-)

[PATCH v2 0/2] clk: vc5: Add IDT VersaClock 5P49V5925

[Vladimir Barinov]

Hello,

This adds the folowing:
- Update IDT VersaClock 5 driver to support 5P49V5925
- Add bindings for IDT VersaClock 5P49V5925

This has the following dependency:
- [V3,7/8] clk: vc5: Add bindings for IDT VersaClock 5P49V6901
- [V3,8/8] clk: vc5: Add support for IDT VersaClock 5P49V6901

Vladimir Barinov (2):
[1/2] clk: vc5: Add support for IDT VersaClock 5P49V5925
[2/2] dt: Add bindings for IDT VersaClock 5P49V5925

---
This patchset is against the 'kernel/git/torvalds/linux.git' repo.

 Documentation/devicetree/bindings/clock/idt,versaclock5.txt |   11 +++
 drivers/clk/clk-versaclock5.c   |   11 +++
 2 files changed, 18 insertions(+), 4 deletions(-)

Re: [PATCH 2/2] dt: Add bindings for IDT VersaClock 5P49V5925

[Vladimir Barinov]

On 09.07.2017 16:31, Marek Vasut wrote:

On 07/07/2017 03:57 AM, Vladimir Barinov wrote:

From: Vladimir Barinov <vladimir.barinov+rene...@cogentembedded.com>

IDT VersaClock 5 5P49V5925 has 4 clock outputs

In 1/2 you said it has 4 FODs and 5 outputs (and it does have 5 outputs,
4 from FODs and 1 I2C_OUTB).

That was a copy typo. Thank you for pointing to this.




, 4 fractional dividers.
Input clock source can be taken only from external reference clock.

Signed-off-by: Vladimir Barinov <vladimir.barinov+rene...@cogentembedded.com>

You might want to rebase this on top of and retest against [1], there
are 8 patches in total fixing some stuff and adding VC6 support.

[1] https://patchwork.kernel.org/patch/9831797/


I've  tested your patch series with ULCB board and HDMI display.
I will rebase 5P49V5925 patches on top of them.

Regards,
Vladimir

Re: [PATCH 2/2] dt: Add bindings for IDT VersaClock 5P49V5925

[Vladimir Barinov]

On 09.07.2017 16:31, Marek Vasut wrote:

On 07/07/2017 03:57 AM, Vladimir Barinov wrote:

From: Vladimir Barinov 

IDT VersaClock 5 5P49V5925 has 4 clock outputs

In 1/2 you said it has 4 FODs and 5 outputs (and it does have 5 outputs,
4 from FODs and 1 I2C_OUTB).

That was a copy typo. Thank you for pointing to this.




, 4 fractional dividers.
Input clock source can be taken only from external reference clock.

Signed-off-by: Vladimir Barinov 

You might want to rebase this on top of and retest against [1], there
are 8 patches in total fixing some stuff and adding VC6 support.

[1] https://patchwork.kernel.org/patch/9831797/


I've  tested your patch series with ULCB board and HDMI display.
I will rebase 5P49V5925 patches on top of them.

Regards,
Vladimir

[PATCH 2/2] dt: Add bindings for IDT VersaClock 5P49V5925

[Vladimir Barinov]

From: Vladimir Barinov <vladimir.barinov+rene...@cogentembedded.com>

IDT VersaClock 5 5P49V5925 has 4 clock outputs, 4 fractional dividers.
Input clock source can be taken only from external reference clock.

Signed-off-by: Vladimir Barinov <vladimir.barinov+rene...@cogentembedded.com>
---
 Documentation/devicetree/bindings/clock/idt,versaclock5.txt | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.txt 
b/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
index 53d7e50..a1ad9e0 100644
--- a/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
+++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
@@ -6,19 +6,21 @@ from 3 to 12 output clocks.
 ==I2C device node==
 
 Required properties:
-- compatible:  shall be one of "idt,5p49v5923" , "idt,5p49v5933" ,
-   "idt,5p49v5935".
+- compatible:  shall be one of "idt,5p49v5923" , "idt,5p49v5925" ,
+   "idt,5p49v5933", "idt,5p49v5935".
 - reg: i2c device address, shall be 0x68 or 0x6a.
 - #clock-cells:from common clock binding; shall be set to 1.
 - clocks:  from common clock binding; list of parent clock handles,
-   - 5p49v5923: (required) either or both of XTAL or CLKIN
+   - 5p49v5923 and
+   - 5p49v5925: (required) either or both of XTAL or CLKIN
reference clock.
- 5p49v5933 and
- 5p49v5935: (optional) property not present (internal
Xtal used) or CLKIN reference
clock.
 - clock-names: from common clock binding; clock input names, can be
-   - 5p49v5923: (required) either or both of "xin", "clkin".
+   - 5p49v5923 and
+   - 5p49v5925: (required) either or both of "xin", "clkin".
- 5p49v5933 and
- 5p49v5935: (optional) property not present or "clkin".
 
@@ -37,6 +39,7 @@ clock specifier, the following mapping applies:
1 -- OUT1
2 -- OUT4
 
+5P49V5925 and
 5P49V5935:
0 -- OUT0_SEL_I2CB
1 -- OUT1
-- 
1.9.1

[PATCH 2/2] dt: Add bindings for IDT VersaClock 5P49V5925

[Vladimir Barinov]

From: Vladimir Barinov 

IDT VersaClock 5 5P49V5925 has 4 clock outputs, 4 fractional dividers.
Input clock source can be taken only from external reference clock.

Signed-off-by: Vladimir Barinov 
---
 Documentation/devicetree/bindings/clock/idt,versaclock5.txt | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.txt 
b/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
index 53d7e50..a1ad9e0 100644
--- a/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
+++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
@@ -6,19 +6,21 @@ from 3 to 12 output clocks.
 ==I2C device node==
 
 Required properties:
-- compatible:  shall be one of "idt,5p49v5923" , "idt,5p49v5933" ,
-   "idt,5p49v5935".
+- compatible:  shall be one of "idt,5p49v5923" , "idt,5p49v5925" ,
+   "idt,5p49v5933", "idt,5p49v5935".
 - reg: i2c device address, shall be 0x68 or 0x6a.
 - #clock-cells:from common clock binding; shall be set to 1.
 - clocks:  from common clock binding; list of parent clock handles,
-   - 5p49v5923: (required) either or both of XTAL or CLKIN
+   - 5p49v5923 and
+   - 5p49v5925: (required) either or both of XTAL or CLKIN
reference clock.
- 5p49v5933 and
- 5p49v5935: (optional) property not present (internal
Xtal used) or CLKIN reference
clock.
 - clock-names: from common clock binding; clock input names, can be
-   - 5p49v5923: (required) either or both of "xin", "clkin".
+   - 5p49v5923 and
+   - 5p49v5925: (required) either or both of "xin", "clkin".
- 5p49v5933 and
- 5p49v5935: (optional) property not present or "clkin".
 
@@ -37,6 +39,7 @@ clock specifier, the following mapping applies:
1 -- OUT1
2 -- OUT4
 
+5P49V5925 and
 5P49V5935:
0 -- OUT0_SEL_I2CB
1 -- OUT1
-- 
1.9.1

[PATCH 1/2] clk: vc5: Add support for IDT VersaClock 5P49V5925

[Vladimir Barinov]

From: Vladimir Barinov <vladimir.barinov+rene...@cogentembedded.com>

Update IDT VersaClock 5 driver to support 5P49V5925. This chip has only
external clock input, four fractional dividers (FODs) and five clock
outputs (four universal clock outputs and one reference clock output at
OUT0_SELB_I2C).

Signed-off-by: Vladimir Barinov <vladimir.barinov+rene...@cogentembedded.com>
---
 drivers/clk/clk-versaclock5.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c
index ea7d552..88b749d 100644
--- a/drivers/clk/clk-versaclock5.c
+++ b/drivers/clk/clk-versaclock5.c
@@ -126,6 +126,7 @@
 /* Supported IDT VC5 models. */
 enum vc5_model {
IDT_VC5_5P49V5923,
+   IDT_VC5_5P49V5925,
IDT_VC5_5P49V5933,
IDT_VC5_5P49V5935,
 };
@@ -595,6 +596,7 @@ static int vc5_map_index_to_output(const enum vc5_model 
model,
case IDT_VC5_5P49V5933:
return (n == 0) ? 0 : 3;
case IDT_VC5_5P49V5923:
+   case IDT_VC5_5P49V5925:
case IDT_VC5_5P49V5935:
default:
return n;
@@ -785,6 +787,13 @@ static int vc5_remove(struct i2c_client *client)
.flags = 0,
 };
 
+static const struct vc5_chip_info idt_5p49v5925_info = {
+   .model = IDT_VC5_5P49V5925,
+   .clk_fod_cnt = 4,
+   .clk_out_cnt = 5,
+   .flags = 0,
+};
+
 static const struct vc5_chip_info idt_5p49v5933_info = {
.model = IDT_VC5_5P49V5933,
.clk_fod_cnt = 2,
@@ -801,6 +810,7 @@ static int vc5_remove(struct i2c_client *client)
 
 static const struct i2c_device_id vc5_id[] = {
{ "5p49v5923", .driver_data = IDT_VC5_5P49V5923 },
+   { "5p49v5925", .driver_data = IDT_VC5_5P49V5925 },
{ "5p49v5933", .driver_data = IDT_VC5_5P49V5933 },
{ "5p49v5935", .driver_data = IDT_VC5_5P49V5935 },
{ }
@@ -809,6 +819,7 @@ static int vc5_remove(struct i2c_client *client)
 
 static const struct of_device_id clk_vc5_of_match[] = {
{ .compatible = "idt,5p49v5923", .data = _5p49v5923_info },
+   { .compatible = "idt,5p49v5925", .data = _5p49v5925_info },
{ .compatible = "idt,5p49v5933", .data = _5p49v5933_info },
{ .compatible = "idt,5p49v5935", .data = _5p49v5935_info },
{ },
-- 
1.9.1

[PATCH 1/2] clk: vc5: Add support for IDT VersaClock 5P49V5925

[Vladimir Barinov]

From: Vladimir Barinov 

Update IDT VersaClock 5 driver to support 5P49V5925. This chip has only
external clock input, four fractional dividers (FODs) and five clock
outputs (four universal clock outputs and one reference clock output at
OUT0_SELB_I2C).

Signed-off-by: Vladimir Barinov 
---
 drivers/clk/clk-versaclock5.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c
index ea7d552..88b749d 100644
--- a/drivers/clk/clk-versaclock5.c
+++ b/drivers/clk/clk-versaclock5.c
@@ -126,6 +126,7 @@
 /* Supported IDT VC5 models. */
 enum vc5_model {
IDT_VC5_5P49V5923,
+   IDT_VC5_5P49V5925,
IDT_VC5_5P49V5933,
IDT_VC5_5P49V5935,
 };
@@ -595,6 +596,7 @@ static int vc5_map_index_to_output(const enum vc5_model 
model,
case IDT_VC5_5P49V5933:
return (n == 0) ? 0 : 3;
case IDT_VC5_5P49V5923:
+   case IDT_VC5_5P49V5925:
case IDT_VC5_5P49V5935:
default:
return n;
@@ -785,6 +787,13 @@ static int vc5_remove(struct i2c_client *client)
.flags = 0,
 };
 
+static const struct vc5_chip_info idt_5p49v5925_info = {
+   .model = IDT_VC5_5P49V5925,
+   .clk_fod_cnt = 4,
+   .clk_out_cnt = 5,
+   .flags = 0,
+};
+
 static const struct vc5_chip_info idt_5p49v5933_info = {
.model = IDT_VC5_5P49V5933,
.clk_fod_cnt = 2,
@@ -801,6 +810,7 @@ static int vc5_remove(struct i2c_client *client)
 
 static const struct i2c_device_id vc5_id[] = {
{ "5p49v5923", .driver_data = IDT_VC5_5P49V5923 },
+   { "5p49v5925", .driver_data = IDT_VC5_5P49V5925 },
{ "5p49v5933", .driver_data = IDT_VC5_5P49V5933 },
{ "5p49v5935", .driver_data = IDT_VC5_5P49V5935 },
{ }
@@ -809,6 +819,7 @@ static int vc5_remove(struct i2c_client *client)
 
 static const struct of_device_id clk_vc5_of_match[] = {
{ .compatible = "idt,5p49v5923", .data = _5p49v5923_info },
+   { .compatible = "idt,5p49v5925", .data = _5p49v5925_info },
{ .compatible = "idt,5p49v5933", .data = _5p49v5933_info },
{ .compatible = "idt,5p49v5935", .data = _5p49v5935_info },
{ },
-- 
1.9.1

[PATCH 0/2] clk: vc5: Add IDT VersaClock 5P49V5925

[Vladimir Barinov]

Hello,

This adds the folowing:
- Update IDT VersaClock 5 driver to support 5P49V5925
- Add bindings for IDT VersaClock 5P49V5925

Vladimir Barinov (2):
[1/2] clk: vc5: Add support for IDT VersaClock 5P49V5925
[2/2] dt: Add bindings for IDT VersaClock 5P49V5925

---
This patchset is against the 'kernel/git/torvalds/linux.git' repo.

 Documentation/devicetree/bindings/clock/idt,versaclock5.txt |   11 +++
 drivers/clk/clk-versaclock5.c   |   11 +++
 2 files changed, 18 insertions(+), 4 deletions(-)

[PATCH 0/2] clk: vc5: Add IDT VersaClock 5P49V5925

[Vladimir Barinov]

Hello,

This adds the folowing:
- Update IDT VersaClock 5 driver to support 5P49V5925
- Add bindings for IDT VersaClock 5P49V5925

Vladimir Barinov (2):
[1/2] clk: vc5: Add support for IDT VersaClock 5P49V5925
[2/2] dt: Add bindings for IDT VersaClock 5P49V5925

---
This patchset is against the 'kernel/git/torvalds/linux.git' repo.

 Documentation/devicetree/bindings/clock/idt,versaclock5.txt |   11 +++
 drivers/clk/clk-versaclock5.c   |   11 +++
 2 files changed, 18 insertions(+), 4 deletions(-)

Re: [PATCH 4/4] iio: hi8435: cleanup reset gpio

[Vladimir Barinov]

On 23.05.2017 11:18, Nikita Yushchenko wrote:

Reset GPIO is active low.

Currently driver uses gpiod_set_value(1) to clean reset, which depends
on device tree to contain GPIO_ACTIVE_HIGH - that does not match reality.

This fixes driver to use _raw version of gpiod_set_value() to enforce
active-low semantics despite of what's written in device tree. Allowing
device tree to override that only opens possibility for errors and does
not add any value.

Additionally, use _cansleep version to make things work with i2c-gpio
and other sleeping gpio drivers.

The reset gpio comes from platform hence it should be handled by DTS.

In driver the gpio should not be raw.

Even the hi8435 is active low but platform may invert signal (f.e. by
adding trigger on the circuit path).

I see.  However - isn't this pure theoretic?  Does such case exist?

I assure you that this is frequently used.

Simply search google for "simple voltage level shifter"
It might be on PNP or NPN transistor, hence logic might be inverted.



In vast majority of cases, GPIO polarity is chip-specific, not
chip-use-specific.  Thus this knowlege belongs to driver and not to
device tree describing particular chip usage.  Having this always
defined at usage side is IMO major source of errors.

GPIO comes from SoC then "circuit path" and finally chip reset input.

What do you propose if h/w circuit path has simple voltage level shifter 
on transistor. How to differentiate PNP and NPN cases?


Regards,
Vladimir

Re: [PATCH 4/4] iio: hi8435: cleanup reset gpio

[Vladimir Barinov]

On 23.05.2017 11:18, Nikita Yushchenko wrote:

Reset GPIO is active low.

Currently driver uses gpiod_set_value(1) to clean reset, which depends
on device tree to contain GPIO_ACTIVE_HIGH - that does not match reality.

This fixes driver to use _raw version of gpiod_set_value() to enforce
active-low semantics despite of what's written in device tree. Allowing
device tree to override that only opens possibility for errors and does
not add any value.

Additionally, use _cansleep version to make things work with i2c-gpio
and other sleeping gpio drivers.

The reset gpio comes from platform hence it should be handled by DTS.

In driver the gpio should not be raw.

Even the hi8435 is active low but platform may invert signal (f.e. by
adding trigger on the circuit path).

I see.  However - isn't this pure theoretic?  Does such case exist?

I assure you that this is frequently used.

Simply search google for "simple voltage level shifter"
It might be on PNP or NPN transistor, hence logic might be inverted.



In vast majority of cases, GPIO polarity is chip-specific, not
chip-use-specific.  Thus this knowlege belongs to driver and not to
device tree describing particular chip usage.  Having this always
defined at usage side is IMO major source of errors.

GPIO comes from SoC then "circuit path" and finally chip reset input.

What do you propose if h/w circuit path has simple voltage level shifter 
on transistor. How to differentiate PNP and NPN cases?


Regards,
Vladimir

Re: [PATCH 2/4] iio: hi8435: avoid garbage event at first enable

[Vladimir Barinov]

Hi Nikita,

On 19.05.2017 17:48, Nikita Yushchenko wrote:

Currently, driver generates events for channels if new reading differs
from previous one. This "previous value" is initialized to zero, which
results into event if value is constant-one.

Fix that by initializing "previous value" by reading at event enable
time.

This provides reliable sequence for userspace:
- enable event,
- AFTER THAT read current value,
- AFTER THAT each event will correspond to change.

Signed-off-by: Nikita Yushchenko 
---
  drivers/iio/adc/hi8435.c | 15 +--
  1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/adc/hi8435.c b/drivers/iio/adc/hi8435.c
index cb8e6342eddf..45a92e3e8f2b 100644
--- a/drivers/iio/adc/hi8435.c
+++ b/drivers/iio/adc/hi8435.c
@@ -141,10 +141,21 @@ static int hi8435_write_event_config(struct iio_dev *idev,
 enum iio_event_direction dir, int state)
  {
struct hi8435_priv *priv = iio_priv(idev);
+   int ret;
+   u32 tmp;
+
+   if (state) {
+   ret = hi8435_readl(priv, HI8435_SO31_0_REG, );
+   if (ret < 0)
+   return ret;
+   if (tmp & BIT(chan->channel))
+   priv->event_prev_val |= BIT(chan->channel);
+   else
+   priv->event_prev_val &= ~BIT(chan->channel);
  
-	priv->event_scan_mask &= ~BIT(chan->channel);

-   if (state)
priv->event_scan_mask |= BIT(chan->channel);
+   } else
+   priv->event_scan_mask &= ~BIT(chan->channel);
  


This will race with hi8435_iio_push_event for priv->event_scan_mask.

Since you adding raw access then it is reasonable to initialize 
priv->event_prev_val in hi8435_read_raw.

Then use the following sequence for your application:
1. read raw value
2. enable events

Regards,
Vladimir

Re: [PATCH 2/4] iio: hi8435: avoid garbage event at first enable

[Vladimir Barinov]

Hi Nikita,

On 19.05.2017 17:48, Nikita Yushchenko wrote:

Currently, driver generates events for channels if new reading differs
from previous one. This "previous value" is initialized to zero, which
results into event if value is constant-one.

Fix that by initializing "previous value" by reading at event enable
time.

This provides reliable sequence for userspace:
- enable event,
- AFTER THAT read current value,
- AFTER THAT each event will correspond to change.

Signed-off-by: Nikita Yushchenko 
---
  drivers/iio/adc/hi8435.c | 15 +--
  1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/adc/hi8435.c b/drivers/iio/adc/hi8435.c
index cb8e6342eddf..45a92e3e8f2b 100644
--- a/drivers/iio/adc/hi8435.c
+++ b/drivers/iio/adc/hi8435.c
@@ -141,10 +141,21 @@ static int hi8435_write_event_config(struct iio_dev *idev,
 enum iio_event_direction dir, int state)
  {
struct hi8435_priv *priv = iio_priv(idev);
+   int ret;
+   u32 tmp;
+
+   if (state) {
+   ret = hi8435_readl(priv, HI8435_SO31_0_REG, );
+   if (ret < 0)
+   return ret;
+   if (tmp & BIT(chan->channel))
+   priv->event_prev_val |= BIT(chan->channel);
+   else
+   priv->event_prev_val &= ~BIT(chan->channel);
  
-	priv->event_scan_mask &= ~BIT(chan->channel);

-   if (state)
priv->event_scan_mask |= BIT(chan->channel);
+   } else
+   priv->event_scan_mask &= ~BIT(chan->channel);
  


This will race with hi8435_iio_push_event for priv->event_scan_mask.

Since you adding raw access then it is reasonable to initialize 
priv->event_prev_val in hi8435_read_raw.

Then use the following sequence for your application:
1. read raw value
2. enable events

Regards,
Vladimir

Re: [PATCH 1/4] iio: hi8435: add raw access

[Vladimir Barinov]

On 20.05.2017 19:33, Jonathan Cameron wrote:

On 19/05/17 15:47, Nikita Yushchenko wrote:

With current event-only driver, it is not possible for user space
application to know current senses if they don't change since
application starts.

Address that by adding raw access to channels.

Signed-off-by: Nikita Yushchenko <nikita.yo...@cogentembedded.com>

Ideally I'd like Vladimir's ack on these, but I am going to guess
that he is fine with this and rely on him shouting if not ;)

Acked-by: Vladimir Barinov <vladimir.bari...@cogentembedded.com>

Originally it was a part of the patch for HI8435 buffer interface but 
removed during migration to event interface:

http://marc.info/?l=linux-iio=143817462614547=4

This is a case when raw access is needed.

Re: [PATCH 1/4] iio: hi8435: add raw access

[Vladimir Barinov]

On 20.05.2017 19:33, Jonathan Cameron wrote:

On 19/05/17 15:47, Nikita Yushchenko wrote:

With current event-only driver, it is not possible for user space
application to know current senses if they don't change since
application starts.

Address that by adding raw access to channels.

Signed-off-by: Nikita Yushchenko 

Ideally I'd like Vladimir's ack on these, but I am going to guess
that he is fine with this and rely on him shouting if not ;)

Acked-by: Vladimir Barinov 

Originally it was a part of the patch for HI8435 buffer interface but 
removed during migration to event interface:

http://marc.info/?l=linux-iio=143817462614547=4

This is a case when raw access is needed.

Re: [PATCH v7 4/5] iio: trigger: Introduce IIO hrtimer based trigger

[Vladimir Barinov]

Hi Lars,

On 31.08.2015 17:57, Lars-Peter Clausen wrote:

On 08/17/2015 02:45 PM, Vladimir Barinov wrote:

Hello Daniel,

I've verified that your hrtimer trigger works.

I have minor suggestions.

Will not it be useful to have ability to stop/start hrtimer polling
not only during attach/detach trigger.

f.e. writing 0 to sampling_frequency will hrtimer_cancel
and writing any valid frequency will hrtimer_start.

What's the use case for this?

Setting sampling frequency to 0 Hz.

I do agree that 0Hz is meaningless and the same effect
is achieved by removing trigger from iio device,
but having 0 Hz frequency could probably be more consecutive
for this trigger instead of returning EINVAL.

Regards,
Vladimir

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 4/5] iio: trigger: Introduce IIO hrtimer based trigger

[Vladimir Barinov]

Hi Lars,

On 31.08.2015 17:57, Lars-Peter Clausen wrote:

On 08/17/2015 02:45 PM, Vladimir Barinov wrote:

Hello Daniel,

I've verified that your hrtimer trigger works.

I have minor suggestions.

Will not it be useful to have ability to stop/start hrtimer polling
not only during attach/detach trigger.

f.e. writing 0 to sampling_frequency will hrtimer_cancel
and writing any valid frequency will hrtimer_start.

What's the use case for this?

Setting sampling frequency to 0 Hz.

I do agree that 0Hz is meaningless and the same effect
is achieved by removing trigger from iio device,
but having 0 Hz frequency could probably be more consecutive
for this trigger instead of returning EINVAL.

Regards,
Vladimir

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 2/2] dt: Document Holt HI-8435 bindings

[Vladimir Barinov]

These bindings can be used to register Holt HI-8435 threshold detector

Signed-off-by: Vladimir Barinov 
---
Changes in version 2:
- renamed file name hi-843x.txt to hi8435.txt
- removed hi-8436,hi-8436,hi-8437
- removed holt,debounce-soft field
- renamed holt,debounc-soft-delay to holt,debounce-interval
- renamed mr-gpio to reset-gpios
Changes in version 3:
- none
Changes in version 4:
- removed debounce_interval property
- removed reset-gpios to use GPIO descriptor API
Changes in version 5:
- none

 .../devicetree/bindings/iio/adc/hi8435.txt  | 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/hi8435.txt

diff --git a/Documentation/devicetree/bindings/iio/adc/hi8435.txt 
b/Documentation/devicetree/bindings/iio/adc/hi8435.txt
new file mode 100644
index 000..3b0348c
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/hi8435.txt
@@ -0,0 +1,21 @@
+Holt Integrated Circuits HI-8435 threshold detector bindings
+
+Required properties:
+ - compatible: should be "holt,hi8435"
+ - reg: spi chip select number for the device
+
+Recommended properties:
+ - spi-max-frequency: definition as per
+   Documentation/devicetree/bindings/spi/spi-bus.txt
+
+Optional properties:
+ - gpios: GPIO used for controlling the reset pin
+
+Example:
+sensor@0 {
+   compatible = "holt,hi8435";
+   reg = <0>;
+   gpios = < 1 0>;
+
+   spi-max-frequency = <100>;
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 1/2] iio: adc: hi8435: Holt HI-8435 threshold detector

[Vladimir Barinov]

Add Holt threshold detector driver for HI-8435 chip

Signed-off-by: Vladimir Barinov 
---
Changes in version 2:
- Added file sysfs-bus-iio-adc-hi8435
- Changed naming from "discrete ADC" to "threshold detector"
- Replaced swab16p/swab32p with be16_to_cpup/be32_to_cpup
- Made *_show and *_store functions static
- moved out from iio buffers to iio events
- removed hi8436/hi8437 chips from the driver
- moved from debounce_soft_delay/enable to debounce_interval via
  IIO_CHAN_INFO_DEBOUNCE_TIME
- added name extention "comparator"
- moved threshold/hysteresis setup via generic iio event sysfs
- added software mask/unmask channel events
- added programming sensor outputs while in test mode via
  IIO_CHAN_INFO_RAW
- added channels .ext_info for programming sensing mode
Changes in version 3:
- fixed typos
- moved  to match alphabetic order
- fixed missed */event/* prefix in the ABI description
- added missed colon in sysfs-bus-iio-adc-hi8435 file after "What"
- moved in_voltageY_comparator_thresh_either_en and debounce_time
  to sysfs-bus-iio file
- added error checking for hi8435_write[b|w]
Changes in version 4:
- removed software debounce logic
- fixed typo in comment s/threshold/thresholds
- removed test_enable sysfs entry
- removed *_raw entries
- removed extended_name
- switched to GPIO descriptor API
- added comment describing the need of thresholds initialization
- added debugfs_reg_access
Changes in version 5:
- added ABI description about falling/rising thresholds automatic
 adjustment that avoids odd hysteresis
- changed reg_buffer[] size to 3 instead of 4
- modified if/else logic in hi8435_read_event_value function
- modified if/else logic in hi8435_write_event_value function
- modified if/else logic in hi8435_iio_push_event function

 Documentation/ABI/testing/sysfs-bus-iio|   1 +
 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 |  43 ++
 drivers/iio/adc/Kconfig|  11 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/hi8435.c   | 531 +
 5 files changed, 587 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
 create mode 100644 drivers/iio/adc/hi8435.c

diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
b/Documentation/ABI/testing/sysfs-bus-iio
index 42d360f..20312a0 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -581,6 +581,7 @@ What:   
/sys/.../iio:deviceX/events/in_voltageY_supply_thresh_rising_en
 What:  /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_falling_en
 What:  /sys/.../iio:deviceX/events/in_voltageY_thresh_rising_en
 What:  /sys/.../iio:deviceX/events/in_voltageY_thresh_falling_en
+What:  /sys/.../iio:deviceX/events/in_voltageY_thresh_either_en
 What:  /sys/.../iio:deviceX/events/in_tempY_thresh_rising_en
 What:  /sys/.../iio:deviceX/events/in_tempY_thresh_falling_en
 KernelVersion: 2.6.37
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 
b/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
new file mode 100644
index 000..f30b4c4
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
@@ -0,0 +1,43 @@
+What:  /sys/bus/iio/devices/iio:deviceX/in_voltageY_sensing_mode
+Date:  August 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Program sensor type for threshold detector inputs.
+   Could be either "GND-Open" or "Supply-Open" mode. Y is a
+   threshold detector input channel. Channels 0..7, 8..15, 16..23
+   and 24..31 has common sensor types.
+
+What:  
/sys/bus/iio/devices/iio:deviceX/events/in_voltageY_thresh_falling_value
+Date:  August 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Channel Y low voltage threshold. If sensor input voltage goes 
lower then
+   this value then the threshold falling event is pushed.
+   Depending on in_voltageY_sensing_mode the low voltage threshold
+   is separately set for "GND-Open" and "Supply-Open" modes.
+   Channels 0..31 have common low threshold values, but could have 
different
+   sensing_modes.
+   The low voltage threshold range is between 2..21V.
+   Hysteresis between low and high thresholds can not be lower 
then 2 and
+   can not be odd.
+   If falling threshold results hysteresis to odd value then rising
+   threshold is automatically subtracted by one.
+
+What:  
/sys/bus/iio/devices/iio:deviceX/events/in_voltageY_thresh_rising_value
+Date:  August 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+ 

[PATCH v5 0/2] iio: adc: hi8435: Add Holt HI-8435 threshold detector

[Vladimir Barinov]

Hello,

This adds the folowing:
- Holt threshold detector driver for HI-8435 chip
- Document HI-8435 DT bindings

PDF file can be found here:
http://www.holtic.com/products/3081-hi-8435.aspx

Vladimir Barinov (2):
[1/2] iio: adc: hi8435: Holt HI-8435 threshold detector
[2/2] dt: Document Holt HI-8435 bindings

---
This patchset is against the 'kernel/git/jic23/iio.git' repo, 'togreg' branch.

 Documentation/ABI/testing/sysfs-bus-iio  |1 
 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435   |   43 +
 Documentation/devicetree/bindings/iio/adc/hi8435.txt |   21 
 drivers/iio/adc/Kconfig  |   11 
 drivers/iio/adc/Makefile |1 
 drivers/iio/adc/hi8435.c |  531 +++
 6 files changed, 608 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
 create mode 100644 Documentation/devicetree/bindings/iio/adc/hi8435.txt
 create mode 100644 drivers/iio/adc/hi8435.c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 1/2] iio: adc: hi8435: Holt HI-8435 threshold detector

[Vladimir Barinov]

Add Holt threshold detector driver for HI-8435 chip

Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
---
Changes in version 2:
- Added file sysfs-bus-iio-adc-hi8435
- Changed naming from discrete ADC to threshold detector
- Replaced swab16p/swab32p with be16_to_cpup/be32_to_cpup
- Made *_show and *_store functions static
- moved out from iio buffers to iio events
- removed hi8436/hi8437 chips from the driver
- moved from debounce_soft_delay/enable to debounce_interval via
  IIO_CHAN_INFO_DEBOUNCE_TIME
- added name extention comparator
- moved threshold/hysteresis setup via generic iio event sysfs
- added software mask/unmask channel events
- added programming sensor outputs while in test mode via
  IIO_CHAN_INFO_RAW
- added channels .ext_info for programming sensing mode
Changes in version 3:
- fixed typos
- moved linux/interrupt.h to match alphabetic order
- fixed missed */event/* prefix in the ABI description
- added missed colon in sysfs-bus-iio-adc-hi8435 file after What
- moved in_voltageY_comparator_thresh_either_en and debounce_time
  to sysfs-bus-iio file
- added error checking for hi8435_write[b|w]
Changes in version 4:
- removed software debounce logic
- fixed typo in comment s/threshold/thresholds
- removed test_enable sysfs entry
- removed *_raw entries
- removed extended_name
- switched to GPIO descriptor API
- added comment describing the need of thresholds initialization
- added debugfs_reg_access
Changes in version 5:
- added ABI description about falling/rising thresholds automatic
 adjustment that avoids odd hysteresis
- changed reg_buffer[] size to 3 instead of 4
- modified if/else logic in hi8435_read_event_value function
- modified if/else logic in hi8435_write_event_value function
- modified if/else logic in hi8435_iio_push_event function

 Documentation/ABI/testing/sysfs-bus-iio|   1 +
 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 |  43 ++
 drivers/iio/adc/Kconfig|  11 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/hi8435.c   | 531 +
 5 files changed, 587 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
 create mode 100644 drivers/iio/adc/hi8435.c

diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
b/Documentation/ABI/testing/sysfs-bus-iio
index 42d360f..20312a0 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -581,6 +581,7 @@ What:   
/sys/.../iio:deviceX/events/in_voltageY_supply_thresh_rising_en
 What:  /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_falling_en
 What:  /sys/.../iio:deviceX/events/in_voltageY_thresh_rising_en
 What:  /sys/.../iio:deviceX/events/in_voltageY_thresh_falling_en
+What:  /sys/.../iio:deviceX/events/in_voltageY_thresh_either_en
 What:  /sys/.../iio:deviceX/events/in_tempY_thresh_rising_en
 What:  /sys/.../iio:deviceX/events/in_tempY_thresh_falling_en
 KernelVersion: 2.6.37
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 
b/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
new file mode 100644
index 000..f30b4c4
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
@@ -0,0 +1,43 @@
+What:  /sys/bus/iio/devices/iio:deviceX/in_voltageY_sensing_mode
+Date:  August 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Program sensor type for threshold detector inputs.
+   Could be either GND-Open or Supply-Open mode. Y is a
+   threshold detector input channel. Channels 0..7, 8..15, 16..23
+   and 24..31 has common sensor types.
+
+What:  
/sys/bus/iio/devices/iio:deviceX/events/in_voltageY_thresh_falling_value
+Date:  August 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Channel Y low voltage threshold. If sensor input voltage goes 
lower then
+   this value then the threshold falling event is pushed.
+   Depending on in_voltageY_sensing_mode the low voltage threshold
+   is separately set for GND-Open and Supply-Open modes.
+   Channels 0..31 have common low threshold values, but could have 
different
+   sensing_modes.
+   The low voltage threshold range is between 2..21V.
+   Hysteresis between low and high thresholds can not be lower 
then 2 and
+   can not be odd.
+   If falling threshold results hysteresis to odd value then rising
+   threshold is automatically subtracted by one.
+
+What:  
/sys/bus/iio/devices/iio:deviceX/events/in_voltageY_thresh_rising_value
+Date:  August 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Channel Y high voltage threshold. If sensor input

[PATCH v5 2/2] dt: Document Holt HI-8435 bindings

[Vladimir Barinov]

These bindings can be used to register Holt HI-8435 threshold detector

Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
---
Changes in version 2:
- renamed file name hi-843x.txt to hi8435.txt
- removed hi-8436,hi-8436,hi-8437
- removed holt,debounce-soft field
- renamed holt,debounc-soft-delay to holt,debounce-interval
- renamed mr-gpio to reset-gpios
Changes in version 3:
- none
Changes in version 4:
- removed debounce_interval property
- removed reset-gpios to use GPIO descriptor API
Changes in version 5:
- none

 .../devicetree/bindings/iio/adc/hi8435.txt  | 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/hi8435.txt

diff --git a/Documentation/devicetree/bindings/iio/adc/hi8435.txt 
b/Documentation/devicetree/bindings/iio/adc/hi8435.txt
new file mode 100644
index 000..3b0348c
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/hi8435.txt
@@ -0,0 +1,21 @@
+Holt Integrated Circuits HI-8435 threshold detector bindings
+
+Required properties:
+ - compatible: should be holt,hi8435
+ - reg: spi chip select number for the device
+
+Recommended properties:
+ - spi-max-frequency: definition as per
+   Documentation/devicetree/bindings/spi/spi-bus.txt
+
+Optional properties:
+ - gpios: GPIO used for controlling the reset pin
+
+Example:
+sensor@0 {
+   compatible = holt,hi8435;
+   reg = 0;
+   gpios = gpio6 1 0;
+
+   spi-max-frequency = 100;
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 0/2] iio: adc: hi8435: Add Holt HI-8435 threshold detector

[Vladimir Barinov]

Hello,

This adds the folowing:
- Holt threshold detector driver for HI-8435 chip
- Document HI-8435 DT bindings

PDF file can be found here:
http://www.holtic.com/products/3081-hi-8435.aspx

Vladimir Barinov (2):
[1/2] iio: adc: hi8435: Holt HI-8435 threshold detector
[2/2] dt: Document Holt HI-8435 bindings

---
This patchset is against the 'kernel/git/jic23/iio.git' repo, 'togreg' branch.

 Documentation/ABI/testing/sysfs-bus-iio  |1 
 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435   |   43 +
 Documentation/devicetree/bindings/iio/adc/hi8435.txt |   21 
 drivers/iio/adc/Kconfig  |   11 
 drivers/iio/adc/Makefile |1 
 drivers/iio/adc/hi8435.c |  531 +++
 6 files changed, 608 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
 create mode 100644 Documentation/devicetree/bindings/iio/adc/hi8435.txt
 create mode 100644 drivers/iio/adc/hi8435.c
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 1/4] iio: Support triggered events

[Vladimir Barinov]

Verified event and buffer polling works concurrently on the same trigger 
with hi-8435.

The buffer interface part for hi-8435 was not sent.

On 20.08.2015 22:37, Vladimir Barinov wrote:

Support triggered events.

This is useful for chips that don't have their own interrupt sources.
It allows to use generic/standalone iio triggers for those drivers.

Signed-off-by: Vladimir Barinov 
---
Changes in version 2:
- initially added
Changes in version 3:
- fixed grammar in patch description
- changed license header to match "GNU Public License v2 or later"
Changes in version 4:
- added pollfunc_event to separate triggering buffer and event
interfaces. This allows runnig both from the same trigger
- removed 'currentmode' for triggered buffer since useless
- renamed parameters of iio_triggered_event_setup

  drivers/iio/Kconfig|  6 +++
  drivers/iio/Makefile   |  1 +
  drivers/iio/industrialio-core.c|  4 +-
  drivers/iio/industrialio-trigger.c | 12 +-
  drivers/iio/industrialio-triggered-event.c | 68 ++
  include/linux/iio/iio.h|  3 ++
  include/linux/iio/triggered_event.h| 11 +
  7 files changed, 101 insertions(+), 4 deletions(-)
  create mode 100644 drivers/iio/industrialio-triggered-event.c
  create mode 100644 include/linux/iio/triggered_event.h

diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 4011eff..8fcc92f 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -58,6 +58,12 @@ config IIO_CONSUMERS_PER_TRIGGER
This value controls the maximum number of consumers that a
given trigger may handle. Default is 2.
  
+config IIO_TRIGGERED_EVENT

+   tristate
+   select IIO_TRIGGER
+   help
+ Provides helper functions for setting up triggered events.
+
  source "drivers/iio/accel/Kconfig"
  source "drivers/iio/adc/Kconfig"
  source "drivers/iio/amplifiers/Kconfig"
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 698afc2..40dc13e 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -9,6 +9,7 @@ industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
  industrialio-$(CONFIG_IIO_BUFFER_CB) += buffer_cb.o
  
  obj-$(CONFIG_IIO_TRIGGERED_BUFFER) += industrialio-triggered-buffer.o

+obj-$(CONFIG_IIO_TRIGGERED_EVENT) += industrialio-triggered-event.o
  obj-$(CONFIG_IIO_KFIFO_BUF) += kfifo_buf.o
  
  obj-y += accel/

diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index b3fcc2c..2c3b6a1 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -962,7 +962,7 @@ static void iio_device_unregister_sysfs(struct iio_dev 
*indio_dev)
  static void iio_dev_release(struct device *device)
  {
struct iio_dev *indio_dev = dev_to_iio_dev(device);
-   if (indio_dev->modes & INDIO_BUFFER_TRIGGERED)
+   if (indio_dev->modes & (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
iio_device_unregister_trigger_consumer(indio_dev);
iio_device_unregister_eventset(indio_dev);
iio_device_unregister_sysfs(indio_dev);
@@ -1241,7 +1241,7 @@ int iio_device_register(struct iio_dev *indio_dev)
"Failed to register event set\n");
goto error_free_sysfs;
}
-   if (indio_dev->modes & INDIO_BUFFER_TRIGGERED)
+   if (indio_dev->modes & (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
iio_device_register_trigger_consumer(indio_dev);
  
  	if ((indio_dev->modes & INDIO_ALL_BUFFER_MODES) &&

diff --git a/drivers/iio/industrialio-trigger.c 
b/drivers/iio/industrialio-trigger.c
index 570606c..ae2806a 100644
--- a/drivers/iio/industrialio-trigger.c
+++ b/drivers/iio/industrialio-trigger.c
@@ -366,10 +366,18 @@ static ssize_t iio_trigger_write_current(struct device 
*dev,
  
  	indio_dev->trig = trig;
  
-	if (oldtrig)

+   if (oldtrig) {
+   if (indio_dev->modes & INDIO_EVENT_TRIGGERED)
+   iio_trigger_detach_poll_func(oldtrig,
+indio_dev->pollfunc_event);
iio_trigger_put(oldtrig);
-   if (indio_dev->trig)
+   }
+   if (indio_dev->trig) {
iio_trigger_get(indio_dev->trig);
+   if (indio_dev->modes & INDIO_EVENT_TRIGGERED)
+   iio_trigger_attach_poll_func(indio_dev->trig,
+indio_dev->pollfunc_event);
+   }
  
  	return len;

  }
diff --git a/drivers/iio/industrialio-triggered-event.c 
b/drivers/iio/industrialio-triggered-event.c
new file mode 100644
index 000..8cc254f
--- /dev/null
+++ b/drivers/iio/industrialio-triggered-event.c
@@ -0,0 +1,68 @@
+/*
+ * Copyright (C) 2015 Cogent Embedded, Inc.
+ *
+ * This program is free software;

[PATCH v4 3/4] iio: adc: hi8435: Holt HI-8435 threshold detector

[Vladimir Barinov]

Add Holt threshold detector driver for HI-8435 chip

Signed-off-by: Vladimir Barinov 
---
Changes in version 2:
- Added file sysfs-bus-iio-adc-hi8435
- Changed naming from "discrete ADC" to "threshold detector"
- Replaced swab16p/swab32p with be16_to_cpup/be32_to_cpup
- Made *_show and *_store functions static
- moved out from iio buffers to iio events
- removed hi8436/hi8437 chips from the driver
- moved from debounce_soft_delay/enable to debounce_interval via
  IIO_CHAN_INFO_DEBOUNCE_TIME
- added name extention "comparator"
- moved threshold/hysteresis setup via generic iio event sysfs
- added software mask/unmask channel events
- added programming sensor outputs while in test mode via
  IIO_CHAN_INFO_RAW
- added channels .ext_info for programming sensing mode
Changes in version 3:
- fixed typos
- moved  to match alphabetic order
- fixed missed */event/* prefix in the ABI description
- added missed colon in sysfs-bus-iio-adc-hi8435 file after "What"
- moved in_voltageY_comparator_thresh_either_en and debounce_time
  to sysfs-bus-iio file
- added error checking for hi8435_write[b|w]
Changes in version 4:
- removed software debounce logic
- fixed typo in comment s/threshold/thresholds
- removed test_enable sysfs entry
- removed *_raw entries
- removed extended_name
- switched to GPIO descriptor API
- added comment describing the need of thresholds initialization
- added debugfs_reg_access

 Documentation/ABI/testing/sysfs-bus-iio|   1 +
 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 |  39 ++
 drivers/iio/adc/Kconfig|  11 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/hi8435.c   | 535 +
 5 files changed, 587 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
 create mode 100644 drivers/iio/adc/hi8435.c

diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
b/Documentation/ABI/testing/sysfs-bus-iio
index 42d360f..20312a0 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -581,6 +581,7 @@ What:   
/sys/.../iio:deviceX/events/in_voltageY_supply_thresh_rising_en
 What:  /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_falling_en
 What:  /sys/.../iio:deviceX/events/in_voltageY_thresh_rising_en
 What:  /sys/.../iio:deviceX/events/in_voltageY_thresh_falling_en
+What:  /sys/.../iio:deviceX/events/in_voltageY_thresh_either_en
 What:  /sys/.../iio:deviceX/events/in_tempY_thresh_rising_en
 What:  /sys/.../iio:deviceX/events/in_tempY_thresh_falling_en
 KernelVersion: 2.6.37
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 
b/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
new file mode 100644
index 000..e3f1943
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
@@ -0,0 +1,39 @@
+What:  /sys/bus/iio/devices/iio:deviceX/in_voltageY_sensing_mode
+Date:  August 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Program sensor type for threshold detector inputs.
+   Could be either "GND-Open" or "Supply-Open" mode. Y is a
+   threshold detector input channel. Channels 0..7, 8..15, 16..23
+   and 24..31 has common sensor types.
+
+What:  
/sys/bus/iio/devices/iio:deviceX/events/in_voltageY_thresh_falling_value
+Date:  August 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Channel Y low voltage threshold. If sensor input voltage goes 
lower then
+   this value then the threshold falling event is pushed.
+   Depending on in_voltageY_sensing_mode the low voltage threshold
+   is separately set for "GND-Open" and "Supply-Open" modes.
+   Channels 0..31 have common low threshold values, but could have 
different
+   sensing_modes.
+   The low voltage threshold range is between 2..21V.
+   Hysteresis between low and high thresholds can not be lower 
then 2 and
+   can not be odd.
+
+What:  
/sys/bus/iio/devices/iio:deviceX/events/in_voltageY_thresh_rising_value
+Date:  August 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Channel Y high voltage threshold. If sensor input voltage goes 
higher then
+   this value then the threshold rising event is pushed.
+   Depending on in_voltageY_sensing_mode the high voltage threshold
+   is separately set for "GND-Open" and "Supply-Open" modes.
+   Channels 0..31 have common high threshold values, but could 
have different
+   sensing_modes.
+   The high voltage threshold range is

[PATCH v4 2/4] dt: Add vendor prefix 'holt'

[Vladimir Barinov]

Add Holt Integrated Circuits, Inc. to the list of device tree vendor
prefixes

Signed-off-by: Vladimir Barinov 
---
Changes in version 2:
- none
Changes in version 3:
- none
Changes in version 4:
- none

 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index d444757..bc64cc9 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -99,6 +99,7 @@ himax Himax Technologies, Inc.
 hisilicon  Hisilicon Limited.
 hitHitachi Ltd.
 hitex  Hitex Development Tools
+holt   Holt Integrated Circuits, Inc.
 honeywell  Honeywell
 hp Hewlett Packard
 i2se   I2SE GmbH
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 4/4] dt: Document Holt HI-8435 bindings

[Vladimir Barinov]

These bindings can be used to register Holt HI-8435 threshold detector

Signed-off-by: Vladimir Barinov 
---
Changes in version 2:
- renamed file name hi-843x.txt to hi8435.txt
- removed hi-8436,hi-8436,hi-8437
- removed holt,debounce-soft field
- renamed holt,debounc-soft-delay to holt,debounce-interval
- renamed mr-gpio to reset-gpios
Changes in version 3:
- none
Changes in version 4:
- removed debounce_interval property
- removed reset-gpios to use GPIO descriptor API

 .../devicetree/bindings/iio/adc/hi8435.txt  | 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/hi8435.txt

diff --git a/Documentation/devicetree/bindings/iio/adc/hi8435.txt 
b/Documentation/devicetree/bindings/iio/adc/hi8435.txt
new file mode 100644
index 000..3b0348c
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/hi8435.txt
@@ -0,0 +1,21 @@
+Holt Integrated Circuits HI-8435 threshold detector bindings
+
+Required properties:
+ - compatible: should be "holt,hi8435"
+ - reg: spi chip select number for the device
+
+Recommended properties:
+ - spi-max-frequency: definition as per
+   Documentation/devicetree/bindings/spi/spi-bus.txt
+
+Optional properties:
+ - gpios: GPIO used for controlling the reset pin
+
+Example:
+sensor@0 {
+   compatible = "holt,hi8435";
+   reg = <0>;
+   gpios = < 1 0>;
+
+   spi-max-frequency = <100>;
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 1/4] iio: Support triggered events

[Vladimir Barinov]

Support triggered events.

This is useful for chips that don't have their own interrupt sources.
It allows to use generic/standalone iio triggers for those drivers.

Signed-off-by: Vladimir Barinov 
---
Changes in version 2:
- initially added
Changes in version 3:
- fixed grammar in patch description
- changed license header to match "GNU Public License v2 or later"
Changes in version 4:
- added pollfunc_event to separate triggering buffer and event
interfaces. This allows runnig both from the same trigger
- removed 'currentmode' for triggered buffer since useless
- renamed parameters of iio_triggered_event_setup

 drivers/iio/Kconfig|  6 +++
 drivers/iio/Makefile   |  1 +
 drivers/iio/industrialio-core.c|  4 +-
 drivers/iio/industrialio-trigger.c | 12 +-
 drivers/iio/industrialio-triggered-event.c | 68 ++
 include/linux/iio/iio.h|  3 ++
 include/linux/iio/triggered_event.h| 11 +
 7 files changed, 101 insertions(+), 4 deletions(-)
 create mode 100644 drivers/iio/industrialio-triggered-event.c
 create mode 100644 include/linux/iio/triggered_event.h

diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 4011eff..8fcc92f 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -58,6 +58,12 @@ config IIO_CONSUMERS_PER_TRIGGER
This value controls the maximum number of consumers that a
given trigger may handle. Default is 2.
 
+config IIO_TRIGGERED_EVENT
+   tristate
+   select IIO_TRIGGER
+   help
+ Provides helper functions for setting up triggered events.
+
 source "drivers/iio/accel/Kconfig"
 source "drivers/iio/adc/Kconfig"
 source "drivers/iio/amplifiers/Kconfig"
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 698afc2..40dc13e 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -9,6 +9,7 @@ industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
 industrialio-$(CONFIG_IIO_BUFFER_CB) += buffer_cb.o
 
 obj-$(CONFIG_IIO_TRIGGERED_BUFFER) += industrialio-triggered-buffer.o
+obj-$(CONFIG_IIO_TRIGGERED_EVENT) += industrialio-triggered-event.o
 obj-$(CONFIG_IIO_KFIFO_BUF) += kfifo_buf.o
 
 obj-y += accel/
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index b3fcc2c..2c3b6a1 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -962,7 +962,7 @@ static void iio_device_unregister_sysfs(struct iio_dev 
*indio_dev)
 static void iio_dev_release(struct device *device)
 {
struct iio_dev *indio_dev = dev_to_iio_dev(device);
-   if (indio_dev->modes & INDIO_BUFFER_TRIGGERED)
+   if (indio_dev->modes & (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
iio_device_unregister_trigger_consumer(indio_dev);
iio_device_unregister_eventset(indio_dev);
iio_device_unregister_sysfs(indio_dev);
@@ -1241,7 +1241,7 @@ int iio_device_register(struct iio_dev *indio_dev)
"Failed to register event set\n");
goto error_free_sysfs;
}
-   if (indio_dev->modes & INDIO_BUFFER_TRIGGERED)
+   if (indio_dev->modes & (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
iio_device_register_trigger_consumer(indio_dev);
 
if ((indio_dev->modes & INDIO_ALL_BUFFER_MODES) &&
diff --git a/drivers/iio/industrialio-trigger.c 
b/drivers/iio/industrialio-trigger.c
index 570606c..ae2806a 100644
--- a/drivers/iio/industrialio-trigger.c
+++ b/drivers/iio/industrialio-trigger.c
@@ -366,10 +366,18 @@ static ssize_t iio_trigger_write_current(struct device 
*dev,
 
indio_dev->trig = trig;
 
-   if (oldtrig)
+   if (oldtrig) {
+   if (indio_dev->modes & INDIO_EVENT_TRIGGERED)
+   iio_trigger_detach_poll_func(oldtrig,
+indio_dev->pollfunc_event);
iio_trigger_put(oldtrig);
-   if (indio_dev->trig)
+   }
+   if (indio_dev->trig) {
iio_trigger_get(indio_dev->trig);
+   if (indio_dev->modes & INDIO_EVENT_TRIGGERED)
+   iio_trigger_attach_poll_func(indio_dev->trig,
+indio_dev->pollfunc_event);
+   }
 
return len;
 }
diff --git a/drivers/iio/industrialio-triggered-event.c 
b/drivers/iio/industrialio-triggered-event.c
new file mode 100644
index 000..8cc254f
--- /dev/null
+++ b/drivers/iio/industrialio-triggered-event.c
@@ -0,0 +1,68 @@
+/*
+ * Copyright (C) 2015 Cogent Embedded, Inc.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of 

[PATCH v4 0/4] iio: adc: hi8435: Add Holt HI-8435 threshold detector

[Vladimir Barinov]

Hello,

This adds the folowing:
- Support triggered events
- Add Holt vendor prefix
- Holt threshold detector driver for HI-8435 chip
- Document HI-8435 DT bindings

PDF file can be found here:
http://www.holtic.com/products/3081-hi-8435.aspx

Vladimir Barinov (4):
[1/4] iio: Support triggered events
[2/4] dt: Add vendor prefix 'holt'
[3/4] iio: adc: hi8435: Holt HI-8435 threshold detector
[4/4] dt: Document Holt HI-8435 bindings

---
This patchset is against the 'kernel/git/jic23/iio.git' repo, 'togreg' branch.

 Documentation/ABI/testing/sysfs-bus-iio   |1 
 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435|   39 +
 Documentation/devicetree/bindings/iio/adc/hi8435.txt  |   21 
 Documentation/devicetree/bindings/vendor-prefixes.txt |1 
 drivers/iio/Kconfig   |6 
 drivers/iio/Makefile  |1 
 drivers/iio/adc/Kconfig   |   11 
 drivers/iio/adc/Makefile  |1 
 drivers/iio/adc/hi8435.c  |  535 ++
 drivers/iio/industrialio-core.c   |4 
 drivers/iio/industrialio-trigger.c|   12 
 drivers/iio/industrialio-triggered-event.c|   68 ++
 include/linux/iio/iio.h   |3 
 include/linux/iio/triggered_event.h   |   11 
 14 files changed, 710 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
 create mode 100644 Documentation/devicetree/bindings/iio/adc/hi8435.txt
 create mode 100644 drivers/iio/adc/hi8435.c
 create mode 100644 drivers/iio/industrialio-triggered-event.c
 create mode 100644 include/linux/iio/triggered_event.h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 1/4] iio: Support triggered events

[Vladimir Barinov]

Support triggered events.

This is useful for chips that don't have their own interrupt sources.
It allows to use generic/standalone iio triggers for those drivers.

Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
---
Changes in version 2:
- initially added
Changes in version 3:
- fixed grammar in patch description
- changed license header to match GNU Public License v2 or later
Changes in version 4:
- added pollfunc_event to separate triggering buffer and event
interfaces. This allows runnig both from the same trigger
- removed 'currentmode' for triggered buffer since useless
- renamed parameters of iio_triggered_event_setup

 drivers/iio/Kconfig|  6 +++
 drivers/iio/Makefile   |  1 +
 drivers/iio/industrialio-core.c|  4 +-
 drivers/iio/industrialio-trigger.c | 12 +-
 drivers/iio/industrialio-triggered-event.c | 68 ++
 include/linux/iio/iio.h|  3 ++
 include/linux/iio/triggered_event.h| 11 +
 7 files changed, 101 insertions(+), 4 deletions(-)
 create mode 100644 drivers/iio/industrialio-triggered-event.c
 create mode 100644 include/linux/iio/triggered_event.h

diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 4011eff..8fcc92f 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -58,6 +58,12 @@ config IIO_CONSUMERS_PER_TRIGGER
This value controls the maximum number of consumers that a
given trigger may handle. Default is 2.
 
+config IIO_TRIGGERED_EVENT
+   tristate
+   select IIO_TRIGGER
+   help
+ Provides helper functions for setting up triggered events.
+
 source drivers/iio/accel/Kconfig
 source drivers/iio/adc/Kconfig
 source drivers/iio/amplifiers/Kconfig
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 698afc2..40dc13e 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -9,6 +9,7 @@ industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
 industrialio-$(CONFIG_IIO_BUFFER_CB) += buffer_cb.o
 
 obj-$(CONFIG_IIO_TRIGGERED_BUFFER) += industrialio-triggered-buffer.o
+obj-$(CONFIG_IIO_TRIGGERED_EVENT) += industrialio-triggered-event.o
 obj-$(CONFIG_IIO_KFIFO_BUF) += kfifo_buf.o
 
 obj-y += accel/
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index b3fcc2c..2c3b6a1 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -962,7 +962,7 @@ static void iio_device_unregister_sysfs(struct iio_dev 
*indio_dev)
 static void iio_dev_release(struct device *device)
 {
struct iio_dev *indio_dev = dev_to_iio_dev(device);
-   if (indio_dev-modes  INDIO_BUFFER_TRIGGERED)
+   if (indio_dev-modes  (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
iio_device_unregister_trigger_consumer(indio_dev);
iio_device_unregister_eventset(indio_dev);
iio_device_unregister_sysfs(indio_dev);
@@ -1241,7 +1241,7 @@ int iio_device_register(struct iio_dev *indio_dev)
Failed to register event set\n);
goto error_free_sysfs;
}
-   if (indio_dev-modes  INDIO_BUFFER_TRIGGERED)
+   if (indio_dev-modes  (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
iio_device_register_trigger_consumer(indio_dev);
 
if ((indio_dev-modes  INDIO_ALL_BUFFER_MODES) 
diff --git a/drivers/iio/industrialio-trigger.c 
b/drivers/iio/industrialio-trigger.c
index 570606c..ae2806a 100644
--- a/drivers/iio/industrialio-trigger.c
+++ b/drivers/iio/industrialio-trigger.c
@@ -366,10 +366,18 @@ static ssize_t iio_trigger_write_current(struct device 
*dev,
 
indio_dev-trig = trig;
 
-   if (oldtrig)
+   if (oldtrig) {
+   if (indio_dev-modes  INDIO_EVENT_TRIGGERED)
+   iio_trigger_detach_poll_func(oldtrig,
+indio_dev-pollfunc_event);
iio_trigger_put(oldtrig);
-   if (indio_dev-trig)
+   }
+   if (indio_dev-trig) {
iio_trigger_get(indio_dev-trig);
+   if (indio_dev-modes  INDIO_EVENT_TRIGGERED)
+   iio_trigger_attach_poll_func(indio_dev-trig,
+indio_dev-pollfunc_event);
+   }
 
return len;
 }
diff --git a/drivers/iio/industrialio-triggered-event.c 
b/drivers/iio/industrialio-triggered-event.c
new file mode 100644
index 000..8cc254f
--- /dev/null
+++ b/drivers/iio/industrialio-triggered-event.c
@@ -0,0 +1,68 @@
+/*
+ * Copyright (C) 2015 Cogent Embedded, Inc.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include linux/kernel.h
+#include linux/export.h
+#include linux/module.h
+#include linux/iio

[PATCH v4 4/4] dt: Document Holt HI-8435 bindings

[Vladimir Barinov]

These bindings can be used to register Holt HI-8435 threshold detector

Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
---
Changes in version 2:
- renamed file name hi-843x.txt to hi8435.txt
- removed hi-8436,hi-8436,hi-8437
- removed holt,debounce-soft field
- renamed holt,debounc-soft-delay to holt,debounce-interval
- renamed mr-gpio to reset-gpios
Changes in version 3:
- none
Changes in version 4:
- removed debounce_interval property
- removed reset-gpios to use GPIO descriptor API

 .../devicetree/bindings/iio/adc/hi8435.txt  | 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/hi8435.txt

diff --git a/Documentation/devicetree/bindings/iio/adc/hi8435.txt 
b/Documentation/devicetree/bindings/iio/adc/hi8435.txt
new file mode 100644
index 000..3b0348c
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/hi8435.txt
@@ -0,0 +1,21 @@
+Holt Integrated Circuits HI-8435 threshold detector bindings
+
+Required properties:
+ - compatible: should be holt,hi8435
+ - reg: spi chip select number for the device
+
+Recommended properties:
+ - spi-max-frequency: definition as per
+   Documentation/devicetree/bindings/spi/spi-bus.txt
+
+Optional properties:
+ - gpios: GPIO used for controlling the reset pin
+
+Example:
+sensor@0 {
+   compatible = holt,hi8435;
+   reg = 0;
+   gpios = gpio6 1 0;
+
+   spi-max-frequency = 100;
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 3/4] iio: adc: hi8435: Holt HI-8435 threshold detector

[Vladimir Barinov]

Add Holt threshold detector driver for HI-8435 chip

Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
---
Changes in version 2:
- Added file sysfs-bus-iio-adc-hi8435
- Changed naming from discrete ADC to threshold detector
- Replaced swab16p/swab32p with be16_to_cpup/be32_to_cpup
- Made *_show and *_store functions static
- moved out from iio buffers to iio events
- removed hi8436/hi8437 chips from the driver
- moved from debounce_soft_delay/enable to debounce_interval via
  IIO_CHAN_INFO_DEBOUNCE_TIME
- added name extention comparator
- moved threshold/hysteresis setup via generic iio event sysfs
- added software mask/unmask channel events
- added programming sensor outputs while in test mode via
  IIO_CHAN_INFO_RAW
- added channels .ext_info for programming sensing mode
Changes in version 3:
- fixed typos
- moved linux/interrupt.h to match alphabetic order
- fixed missed */event/* prefix in the ABI description
- added missed colon in sysfs-bus-iio-adc-hi8435 file after What
- moved in_voltageY_comparator_thresh_either_en and debounce_time
  to sysfs-bus-iio file
- added error checking for hi8435_write[b|w]
Changes in version 4:
- removed software debounce logic
- fixed typo in comment s/threshold/thresholds
- removed test_enable sysfs entry
- removed *_raw entries
- removed extended_name
- switched to GPIO descriptor API
- added comment describing the need of thresholds initialization
- added debugfs_reg_access

 Documentation/ABI/testing/sysfs-bus-iio|   1 +
 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 |  39 ++
 drivers/iio/adc/Kconfig|  11 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/hi8435.c   | 535 +
 5 files changed, 587 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
 create mode 100644 drivers/iio/adc/hi8435.c

diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
b/Documentation/ABI/testing/sysfs-bus-iio
index 42d360f..20312a0 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -581,6 +581,7 @@ What:   
/sys/.../iio:deviceX/events/in_voltageY_supply_thresh_rising_en
 What:  /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_falling_en
 What:  /sys/.../iio:deviceX/events/in_voltageY_thresh_rising_en
 What:  /sys/.../iio:deviceX/events/in_voltageY_thresh_falling_en
+What:  /sys/.../iio:deviceX/events/in_voltageY_thresh_either_en
 What:  /sys/.../iio:deviceX/events/in_tempY_thresh_rising_en
 What:  /sys/.../iio:deviceX/events/in_tempY_thresh_falling_en
 KernelVersion: 2.6.37
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 
b/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
new file mode 100644
index 000..e3f1943
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
@@ -0,0 +1,39 @@
+What:  /sys/bus/iio/devices/iio:deviceX/in_voltageY_sensing_mode
+Date:  August 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Program sensor type for threshold detector inputs.
+   Could be either GND-Open or Supply-Open mode. Y is a
+   threshold detector input channel. Channels 0..7, 8..15, 16..23
+   and 24..31 has common sensor types.
+
+What:  
/sys/bus/iio/devices/iio:deviceX/events/in_voltageY_thresh_falling_value
+Date:  August 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Channel Y low voltage threshold. If sensor input voltage goes 
lower then
+   this value then the threshold falling event is pushed.
+   Depending on in_voltageY_sensing_mode the low voltage threshold
+   is separately set for GND-Open and Supply-Open modes.
+   Channels 0..31 have common low threshold values, but could have 
different
+   sensing_modes.
+   The low voltage threshold range is between 2..21V.
+   Hysteresis between low and high thresholds can not be lower 
then 2 and
+   can not be odd.
+
+What:  
/sys/bus/iio/devices/iio:deviceX/events/in_voltageY_thresh_rising_value
+Date:  August 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Channel Y high voltage threshold. If sensor input voltage goes 
higher then
+   this value then the threshold rising event is pushed.
+   Depending on in_voltageY_sensing_mode the high voltage threshold
+   is separately set for GND-Open and Supply-Open modes.
+   Channels 0..31 have common high threshold values, but could 
have different
+   sensing_modes.
+   The high voltage threshold range is between 3..22V.
+   Hysteresis between low and high thresholds can

[PATCH v4 2/4] dt: Add vendor prefix 'holt'

[Vladimir Barinov]

Add Holt Integrated Circuits, Inc. to the list of device tree vendor
prefixes

Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
---
Changes in version 2:
- none
Changes in version 3:
- none
Changes in version 4:
- none

 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index d444757..bc64cc9 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -99,6 +99,7 @@ himax Himax Technologies, Inc.
 hisilicon  Hisilicon Limited.
 hitHitachi Ltd.
 hitex  Hitex Development Tools
+holt   Holt Integrated Circuits, Inc.
 honeywell  Honeywell
 hp Hewlett Packard
 i2se   I2SE GmbH
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 1/4] iio: Support triggered events

[Vladimir Barinov]

Verified event and buffer polling works concurrently on the same trigger 
with hi-8435.

The buffer interface part for hi-8435 was not sent.

On 20.08.2015 22:37, Vladimir Barinov wrote:

Support triggered events.

This is useful for chips that don't have their own interrupt sources.
It allows to use generic/standalone iio triggers for those drivers.

Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
---
Changes in version 2:
- initially added
Changes in version 3:
- fixed grammar in patch description
- changed license header to match GNU Public License v2 or later
Changes in version 4:
- added pollfunc_event to separate triggering buffer and event
interfaces. This allows runnig both from the same trigger
- removed 'currentmode' for triggered buffer since useless
- renamed parameters of iio_triggered_event_setup

  drivers/iio/Kconfig|  6 +++
  drivers/iio/Makefile   |  1 +
  drivers/iio/industrialio-core.c|  4 +-
  drivers/iio/industrialio-trigger.c | 12 +-
  drivers/iio/industrialio-triggered-event.c | 68 ++
  include/linux/iio/iio.h|  3 ++
  include/linux/iio/triggered_event.h| 11 +
  7 files changed, 101 insertions(+), 4 deletions(-)
  create mode 100644 drivers/iio/industrialio-triggered-event.c
  create mode 100644 include/linux/iio/triggered_event.h

diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 4011eff..8fcc92f 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -58,6 +58,12 @@ config IIO_CONSUMERS_PER_TRIGGER
This value controls the maximum number of consumers that a
given trigger may handle. Default is 2.
  
+config IIO_TRIGGERED_EVENT

+   tristate
+   select IIO_TRIGGER
+   help
+ Provides helper functions for setting up triggered events.
+
  source drivers/iio/accel/Kconfig
  source drivers/iio/adc/Kconfig
  source drivers/iio/amplifiers/Kconfig
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 698afc2..40dc13e 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -9,6 +9,7 @@ industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
  industrialio-$(CONFIG_IIO_BUFFER_CB) += buffer_cb.o
  
  obj-$(CONFIG_IIO_TRIGGERED_BUFFER) += industrialio-triggered-buffer.o

+obj-$(CONFIG_IIO_TRIGGERED_EVENT) += industrialio-triggered-event.o
  obj-$(CONFIG_IIO_KFIFO_BUF) += kfifo_buf.o
  
  obj-y += accel/

diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index b3fcc2c..2c3b6a1 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -962,7 +962,7 @@ static void iio_device_unregister_sysfs(struct iio_dev 
*indio_dev)
  static void iio_dev_release(struct device *device)
  {
struct iio_dev *indio_dev = dev_to_iio_dev(device);
-   if (indio_dev-modes  INDIO_BUFFER_TRIGGERED)
+   if (indio_dev-modes  (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
iio_device_unregister_trigger_consumer(indio_dev);
iio_device_unregister_eventset(indio_dev);
iio_device_unregister_sysfs(indio_dev);
@@ -1241,7 +1241,7 @@ int iio_device_register(struct iio_dev *indio_dev)
Failed to register event set\n);
goto error_free_sysfs;
}
-   if (indio_dev-modes  INDIO_BUFFER_TRIGGERED)
+   if (indio_dev-modes  (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
iio_device_register_trigger_consumer(indio_dev);
  
  	if ((indio_dev-modes  INDIO_ALL_BUFFER_MODES) 

diff --git a/drivers/iio/industrialio-trigger.c 
b/drivers/iio/industrialio-trigger.c
index 570606c..ae2806a 100644
--- a/drivers/iio/industrialio-trigger.c
+++ b/drivers/iio/industrialio-trigger.c
@@ -366,10 +366,18 @@ static ssize_t iio_trigger_write_current(struct device 
*dev,
  
  	indio_dev-trig = trig;
  
-	if (oldtrig)

+   if (oldtrig) {
+   if (indio_dev-modes  INDIO_EVENT_TRIGGERED)
+   iio_trigger_detach_poll_func(oldtrig,
+indio_dev-pollfunc_event);
iio_trigger_put(oldtrig);
-   if (indio_dev-trig)
+   }
+   if (indio_dev-trig) {
iio_trigger_get(indio_dev-trig);
+   if (indio_dev-modes  INDIO_EVENT_TRIGGERED)
+   iio_trigger_attach_poll_func(indio_dev-trig,
+indio_dev-pollfunc_event);
+   }
  
  	return len;

  }
diff --git a/drivers/iio/industrialio-triggered-event.c 
b/drivers/iio/industrialio-triggered-event.c
new file mode 100644
index 000..8cc254f
--- /dev/null
+++ b/drivers/iio/industrialio-triggered-event.c
@@ -0,0 +1,68 @@
+/*
+ * Copyright (C) 2015 Cogent Embedded, Inc.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free

[PATCH v4 0/4] iio: adc: hi8435: Add Holt HI-8435 threshold detector

[Vladimir Barinov]

Hello,

This adds the folowing:
- Support triggered events
- Add Holt vendor prefix
- Holt threshold detector driver for HI-8435 chip
- Document HI-8435 DT bindings

PDF file can be found here:
http://www.holtic.com/products/3081-hi-8435.aspx

Vladimir Barinov (4):
[1/4] iio: Support triggered events
[2/4] dt: Add vendor prefix 'holt'
[3/4] iio: adc: hi8435: Holt HI-8435 threshold detector
[4/4] dt: Document Holt HI-8435 bindings

---
This patchset is against the 'kernel/git/jic23/iio.git' repo, 'togreg' branch.

 Documentation/ABI/testing/sysfs-bus-iio   |1 
 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435|   39 +
 Documentation/devicetree/bindings/iio/adc/hi8435.txt  |   21 
 Documentation/devicetree/bindings/vendor-prefixes.txt |1 
 drivers/iio/Kconfig   |6 
 drivers/iio/Makefile  |1 
 drivers/iio/adc/Kconfig   |   11 
 drivers/iio/adc/Makefile  |1 
 drivers/iio/adc/hi8435.c  |  535 ++
 drivers/iio/industrialio-core.c   |4 
 drivers/iio/industrialio-trigger.c|   12 
 drivers/iio/industrialio-triggered-event.c|   68 ++
 include/linux/iio/iio.h   |3 
 include/linux/iio/triggered_event.h   |   11 
 14 files changed, 710 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
 create mode 100644 Documentation/devicetree/bindings/iio/adc/hi8435.txt
 create mode 100644 drivers/iio/adc/hi8435.c
 create mode 100644 drivers/iio/industrialio-triggered-event.c
 create mode 100644 include/linux/iio/triggered_event.h
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 4/5] iio: trigger: Introduce IIO hrtimer based trigger

[Vladimir Barinov]

Hello Daniel,

I've verified that your hrtimer trigger works.

I have minor suggestions.

Will not it be useful to have ability to stop/start hrtimer polling
not only during attach/detach trigger.

f.e. writing 0 to sampling_frequency will hrtimer_cancel
and writing any valid frequency will hrtimer_start.

Regards,
Vladimir

On 11.08.2015 01:42, Daniel Baluta wrote:

This patch registers a new IIO software trigger interrupt source
based on high resolution timers.

Notice that if configfs is enabled we create sampling_frequency
attribute allowing users to change hrtimer period (1/sampling_frequency).

The IIO hrtimer trigger has a long history, this patch is based on
an older version from Marten and Lars-Peter.

Signed-off-by: Marten Svanfeldt 
Signed-off-by: Lars-Peter Clausen 
Signed-off-by: Daniel Baluta 
---
  drivers/iio/trigger/Kconfig|  10 ++
  drivers/iio/trigger/Makefile   |   2 +
  drivers/iio/trigger/iio-trig-hrtimer.c | 193 +
  3 files changed, 205 insertions(+)
  create mode 100644 drivers/iio/trigger/iio-trig-hrtimer.c

diff --git a/drivers/iio/trigger/Kconfig b/drivers/iio/trigger/Kconfig
index 7999612..4505281 100644
--- a/drivers/iio/trigger/Kconfig
+++ b/drivers/iio/trigger/Kconfig
@@ -5,6 +5,16 @@
  
  menu "Triggers - standalone"
  
+config IIO_HRTIMER_TRIGGER

+   tristate "High resolution timer trigger"
+   select IIO_SW_TRIGGER
+   help
+ Provides a frequency based IIO trigger using high resolution
+ timers as interrupt source.
+
+ To compile this driver as a module, choose M here: the
+ module will be called iio-trig-hrtimer.
+
  config IIO_INTERRUPT_TRIGGER
tristate "Generic interrupt trigger"
help
diff --git a/drivers/iio/trigger/Makefile b/drivers/iio/trigger/Makefile
index 0694dae..fe06eb5 100644
--- a/drivers/iio/trigger/Makefile
+++ b/drivers/iio/trigger/Makefile
@@ -3,5 +3,7 @@
  #
  
  # When adding new entries keep the list in alphabetical order

+
+obj-$(CONFIG_IIO_HRTIMER_TRIGGER) += iio-trig-hrtimer.o
  obj-$(CONFIG_IIO_INTERRUPT_TRIGGER) += iio-trig-interrupt.o
  obj-$(CONFIG_IIO_SYSFS_TRIGGER) += iio-trig-sysfs.o
diff --git a/drivers/iio/trigger/iio-trig-hrtimer.c 
b/drivers/iio/trigger/iio-trig-hrtimer.c
new file mode 100644
index 000..4631c7a
--- /dev/null
+++ b/drivers/iio/trigger/iio-trig-hrtimer.c
@@ -0,0 +1,193 @@
+/**
+ * The industrial I/O periodic hrtimer trigger driver
+ *
+ * Copyright (C) Intuitive Aerial AB
+ * Written by Marten Svanfeldt, mar...@intuitiveaerial.com
+ * Copyright (C) 2012, Analog Device Inc.
+ * Author: Lars-Peter Clausen 
+ * Copyright (C) 2015, Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ */
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+/* default sampling frequency - 100Hz */
+#define HRTIMER_DEFAULT_SAMPLING_FREQUENCY 100
+
+struct iio_hrtimer_info {
+   struct iio_sw_trigger swt;
+   struct hrtimer timer;
+   unsigned long sampling_frequency;
+   ktime_t period;
+};
+
+static struct config_item_type iio_hrtimer_type = {
+   .ct_owner = THIS_MODULE,
+};
+
+static
+ssize_t iio_hrtimer_show_sampling_frequency(struct device *dev,
+   struct device_attribute *attr,
+   char *buf)
+{
+   struct iio_trigger *trig = to_iio_trigger(dev);
+   struct iio_hrtimer_info *info = iio_trigger_get_drvdata(trig);
+
+   return snprintf(buf, PAGE_SIZE, "%lu\n", info->sampling_frequency);
+}
+
+static
+ssize_t iio_hrtimer_store_sampling_frequency(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t len)
+{
+   struct iio_trigger *trig = to_iio_trigger(dev);
+   struct iio_hrtimer_info *info = iio_trigger_get_drvdata(trig);
+   unsigned long val;
+   int ret;
+
+   ret = kstrtoul(buf, 10, );
+   if (ret)
+   return ret;
+
+   if (!val || val > NSEC_PER_SEC)
+   return -EINVAL;
+
+   info->sampling_frequency = val;
+   info->period = ktime_set(0, NSEC_PER_SEC / val);
+
+   return len;
+}
+
+static DEVICE_ATTR(sampling_frequency, S_IRUGO | S_IWUSR,
+  iio_hrtimer_show_sampling_frequency,
+  iio_hrtimer_store_sampling_frequency);
+
+static struct attribute *iio_hrtimer_attrs[] = {
+   _attr_sampling_frequency.attr,
+   NULL
+};
+
+static const struct attribute_group iio_hrtimer_attr_group = {
+   .attrs = iio_hrtimer_attrs,
+};
+
+static const struct attribute_group *iio_hrtimer_attr_groups[] = {
+   _hrtimer_attr_group,
+   NULL
+};
+
+static enum hrtimer_restart iio_hrtimer_trig_handler(struct hrtimer *timer)
+{

Re: [PATCH v7 5/5] iio: Documentation: Add IIO configfs documentation

[Vladimir Barinov]

Hi Daniel,

Find minor comments.

Regards,
Vladimir

On 11.08.2015 01:42, Daniel Baluta wrote:

Signed-off-by: Daniel Baluta 
---
  Documentation/ABI/testing/configfs-iio | 20 
  Documentation/iio/iio_configfs.txt | 57 ++
  2 files changed, 77 insertions(+)
  create mode 100644 Documentation/ABI/testing/configfs-iio
  create mode 100644 Documentation/iio/iio_configfs.txt

diff --git a/Documentation/ABI/testing/configfs-iio 
b/Documentation/ABI/testing/configfs-iio
new file mode 100644
index 000..1fd7cf4
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-iio
@@ -0,0 +1,20 @@
+What:  /config/iio
+Date:  May 2015
+KernelVersion: 4.2
+Contact:   linux-...@vger.kernel.org
+Description:
+   This represents Industrial IO configuration entry point
+   directory. It contains sub-groups corresponding to IIO
+   objects.
+
+What:  /config/iio/triggers
+Date:  August 2015
+KernelVersion: 4.2
+Description:
+   Industrial IO software triggers directory.
+
+What:  /config/iio/triggers/hrtimer
+Date:  August 2015
+KernelVersion: 4.2
+Description:
+   Industrial IO hrtimer based software triggers directory.
diff --git a/Documentation/iio/iio_configfs.txt 
b/Documentation/iio/iio_configfs.txt
new file mode 100644
index 000..7c56997
--- /dev/null
+++ b/Documentation/iio/iio_configfs.txt
@@ -0,0 +1,57 @@
+Industrial IIO configfs support
+
+1. Overview
+
+Configfs is a filesystem-based manager of kernel objects. IIO uses some
+objects that could be easily configured using configfs (e.g.: devices,
+triggers).
+
+See Documentation/filesystems/configfs/configfs.txt for more information
+about how configfs works.
+
+2. Usage
+
+In order to use configfs support in IIO we need to select it at compile
+time via CONFIG_IIO_CONFIGFS config option.
+
+Then, mount the configfs filesystem (usually under /config directory):
+
+$ mkdir /config
+$ mount -t configfs none /config
+
+At this point, all default IIO groups will be created and can be accessed
+under /config/iio. Next chapters will describe available IIO configuration
+objects.
+
+3. Software triggers
+
+One of the IIO default configfs groups is the "triggers" groups. It is
+automagically accessible when the configfs is mounted and can be found
+under /config/iio/triggers.
+
+Software triggers are created under /config/iio/triggers directory. There
+must exist an associated kernel module that implements a software trigger type.
+
+We support now the following software trigger types:
+   * hrtimer, uses high resolution timers as interrupt source implemened
+   by the iio-trig-hrtimer.c module.
+
+3.1 Software triggers creation and destruction
+
+As simply as:
+
+$ insmod iio-trig-hrtimer.ko
+$ ls /config/triggers

ls /config/iio/triggers/


+hrtimer
+$ mkdir /config/triggers/hrtimer/trig1

mkdir /config/iio/triggers/hrtimer/trig1

This is confusing:
$ cat /sys/bus//iio/devices/trigger0/name
trig1

How may I know that this is a hrtimer trigger in case I've enabled
couple of triggers or when sw_trigger support extends with other
then hrtimer trigger?


+
+$ rmdir /config/triggers/hrtimer/trig1

ditto



+$ rmmod iio-trig-hrtimer
+
+Each trigger can have one or more attributes specific to the trigger type.
+
+3.2 "hrtimer" trigger types attributes
+
+"hrtimer" trigger type doesn't have any configurable attribute from /config 
dir,
+but hrtimer triggers have the sampling_frequency attribute under 
/sys/bus/iio/devices/triggerX
+directory.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 3/5] iio: core: Introduce IIO software triggers

[Vladimir Barinov]

Hi Daniel,

Minor comments since I need your hrtimer trigger support.

1) The drivers/iio/industrialio-sw-trigger.c should probably
come to drivers/iio/trigger/ folder which is under ifdef condition
in drivers/iio/Kconfig

2) it breaks compilation
enabling IIO_HRTIMER_TRIGGER selects IIO_SW_TRIGGER.
But IIO_SW_TRIGGER fail to compile without IIO_CONFIGFS

3) Probably the IIO_SW_TRIGGER should be tristate like other
standalone triggers

I will report test results when I try hrtimer trigger.

Regards,
Vladimir

On 11.08.2015 01:42, Daniel Baluta wrote:

A software trigger associates an IIO device trigger with a software
interrupt source (e.g: timer, sysfs). This patch adds the generic
infrastructure for handling software triggers.

Software interrupts sources are kept in a iio_trigger_types_list and
registered separately when the associated kernel module is loaded.

Software triggers can be created directly from drivers or from user
space via configfs interface.

Signed-off-by: Daniel Baluta 
---
  drivers/iio/Kconfig   |   8 +++
  drivers/iio/Makefile  |   1 +
  drivers/iio/industrialio-configfs.c   |  49 ++
  drivers/iio/industrialio-sw-trigger.c | 119 ++
  include/linux/iio/sw_trigger.h|  99 
  5 files changed, 276 insertions(+)
  create mode 100644 drivers/iio/industrialio-sw-trigger.c
  create mode 100644 include/linux/iio/sw_trigger.h

diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index f2b0d77..117c05a 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -66,6 +66,14 @@ config IIO_CONSUMERS_PER_TRIGGER
This value controls the maximum number of consumers that a
given trigger may handle. Default is 2.
  
+config IIO_SW_TRIGGER

+   bool "Enable software triggers support"
+   depends on IIO_TRIGGER
+   help
+Provides IIO core support for software triggers. A software
+trigger can be created via configfs or directly by a driver
+using the API provided.
+
  source "drivers/iio/accel/Kconfig"
  source "drivers/iio/adc/Kconfig"
  source "drivers/iio/amplifiers/Kconfig"
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index dbf5f9a..31aead3 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_IIO) += industrialio.o
  industrialio-y := industrialio-core.o industrialio-event.o inkern.o
  industrialio-$(CONFIG_IIO_BUFFER) += industrialio-buffer.o
  industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
+industrialio-$(CONFIG_IIO_SW_TRIGGER) += industrialio-sw-trigger.o
  industrialio-$(CONFIG_IIO_BUFFER_CB) += buffer_cb.o
  
  obj-$(CONFIG_IIO_TRIGGERED_BUFFER) += industrialio-triggered-buffer.o

diff --git a/drivers/iio/industrialio-configfs.c 
b/drivers/iio/industrialio-configfs.c
index 3edee90..ced7115 100644
--- a/drivers/iio/industrialio-configfs.c
+++ b/drivers/iio/industrialio-configfs.c
@@ -15,6 +15,40 @@
  #include 
  
  #include 

+#include 
+
+static struct config_group *trigger_make_group(struct config_group *group,
+  const char *name)
+{
+   struct iio_sw_trigger *t;
+
+   t = iio_sw_trigger_create(group->cg_item.ci_name, name);
+   if (IS_ERR(t))
+   return ERR_CAST(t);
+
+   config_item_set_name(>group.cg_item, name);
+
+   return >group;
+}
+
+static void trigger_drop_group(struct config_group *group,
+  struct config_item *item)
+{
+   struct iio_sw_trigger *t = to_iio_sw_trigger(item);
+
+   iio_sw_trigger_destroy(t);
+   config_item_put(item);
+}
+
+static struct configfs_group_operations trigger_ops = {
+   .make_group = _make_group,
+   .drop_item  = _drop_group,
+};
+
+static struct config_item_type iio_trigger_type_group_type = {
+   .ct_group_ops = _ops,
+   .ct_owner   = THIS_MODULE,
+};
  
  static struct config_item_type iio_triggers_group_type = {

.ct_owner = THIS_MODULE,
@@ -47,6 +81,21 @@ static struct configfs_subsystem iio_configfs_subsys = {
.su_mutex = __MUTEX_INITIALIZER(iio_configfs_subsys.su_mutex),
  };
  
+int iio_sw_trigger_type_configfs_register(struct iio_sw_trigger_type *tt)

+{
+   config_group_init_type_name(>group, tt->name,
+   _trigger_type_group_type);
+
+   return configfs_register_group(_triggers_group, >group);
+}
+EXPORT_SYMBOL_GPL(iio_sw_trigger_type_configfs_register);
+
+void iio_sw_trigger_type_configfs_unregister(struct iio_sw_trigger_type *tt)
+{
+   configfs_unregister_group(>group);
+}
+EXPORT_SYMBOL_GPL(iio_sw_trigger_type_configfs_unregister);
+
  static int __init iio_configfs_init(void)
  {
config_group_init(_triggers_group);
diff --git a/drivers/iio/industrialio-sw-trigger.c 
b/drivers/iio/industrialio-sw-trigger.c
new file mode 100644
index 000..761418e
--- /dev/null
+++ b/drivers/iio/industrialio-sw-trigger.c
@@ -0,0 

Re: [PATCH v7 5/5] iio: Documentation: Add IIO configfs documentation

[Vladimir Barinov]

Hi Daniel,

Find minor comments.

Regards,
Vladimir

On 11.08.2015 01:42, Daniel Baluta wrote:

Signed-off-by: Daniel Baluta daniel.bal...@intel.com
---
  Documentation/ABI/testing/configfs-iio | 20 
  Documentation/iio/iio_configfs.txt | 57 ++
  2 files changed, 77 insertions(+)
  create mode 100644 Documentation/ABI/testing/configfs-iio
  create mode 100644 Documentation/iio/iio_configfs.txt

diff --git a/Documentation/ABI/testing/configfs-iio 
b/Documentation/ABI/testing/configfs-iio
new file mode 100644
index 000..1fd7cf4
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-iio
@@ -0,0 +1,20 @@
+What:  /config/iio
+Date:  May 2015
+KernelVersion: 4.2
+Contact:   linux-...@vger.kernel.org
+Description:
+   This represents Industrial IO configuration entry point
+   directory. It contains sub-groups corresponding to IIO
+   objects.
+
+What:  /config/iio/triggers
+Date:  August 2015
+KernelVersion: 4.2
+Description:
+   Industrial IO software triggers directory.
+
+What:  /config/iio/triggers/hrtimer
+Date:  August 2015
+KernelVersion: 4.2
+Description:
+   Industrial IO hrtimer based software triggers directory.
diff --git a/Documentation/iio/iio_configfs.txt 
b/Documentation/iio/iio_configfs.txt
new file mode 100644
index 000..7c56997
--- /dev/null
+++ b/Documentation/iio/iio_configfs.txt
@@ -0,0 +1,57 @@
+Industrial IIO configfs support
+
+1. Overview
+
+Configfs is a filesystem-based manager of kernel objects. IIO uses some
+objects that could be easily configured using configfs (e.g.: devices,
+triggers).
+
+See Documentation/filesystems/configfs/configfs.txt for more information
+about how configfs works.
+
+2. Usage
+
+In order to use configfs support in IIO we need to select it at compile
+time via CONFIG_IIO_CONFIGFS config option.
+
+Then, mount the configfs filesystem (usually under /config directory):
+
+$ mkdir /config
+$ mount -t configfs none /config
+
+At this point, all default IIO groups will be created and can be accessed
+under /config/iio. Next chapters will describe available IIO configuration
+objects.
+
+3. Software triggers
+
+One of the IIO default configfs groups is the triggers groups. It is
+automagically accessible when the configfs is mounted and can be found
+under /config/iio/triggers.
+
+Software triggers are created under /config/iio/triggers directory. There
+must exist an associated kernel module that implements a software trigger type.
+
+We support now the following software trigger types:
+   * hrtimer, uses high resolution timers as interrupt source implemened
+   by the iio-trig-hrtimer.c module.
+
+3.1 Software triggers creation and destruction
+
+As simply as:
+
+$ insmod iio-trig-hrtimer.ko
+$ ls /config/triggers

ls /config/iio/triggers/


+hrtimer
+$ mkdir /config/triggers/hrtimer/trig1

mkdir /config/iio/triggers/hrtimer/trig1

This is confusing:
$ cat /sys/bus//iio/devices/trigger0/name
trig1

How may I know that this is a hrtimer trigger in case I've enabled
couple of triggers or when sw_trigger support extends with other
then hrtimer trigger?


+
+$ rmdir /config/triggers/hrtimer/trig1

ditto



+$ rmmod iio-trig-hrtimer
+
+Each trigger can have one or more attributes specific to the trigger type.
+
+3.2 hrtimer trigger types attributes
+
+hrtimer trigger type doesn't have any configurable attribute from /config 
dir,
+but hrtimer triggers have the sampling_frequency attribute under 
/sys/bus/iio/devices/triggerX
+directory.


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 3/5] iio: core: Introduce IIO software triggers

[Vladimir Barinov]

Hi Daniel,

Minor comments since I need your hrtimer trigger support.

1) The drivers/iio/industrialio-sw-trigger.c should probably
come to drivers/iio/trigger/ folder which is under ifdef condition
in drivers/iio/Kconfig

2) it breaks compilation
enabling IIO_HRTIMER_TRIGGER selects IIO_SW_TRIGGER.
But IIO_SW_TRIGGER fail to compile without IIO_CONFIGFS

3) Probably the IIO_SW_TRIGGER should be tristate like other
standalone triggers

I will report test results when I try hrtimer trigger.

Regards,
Vladimir

On 11.08.2015 01:42, Daniel Baluta wrote:

A software trigger associates an IIO device trigger with a software
interrupt source (e.g: timer, sysfs). This patch adds the generic
infrastructure for handling software triggers.

Software interrupts sources are kept in a iio_trigger_types_list and
registered separately when the associated kernel module is loaded.

Software triggers can be created directly from drivers or from user
space via configfs interface.

Signed-off-by: Daniel Baluta daniel.bal...@intel.com
---
  drivers/iio/Kconfig   |   8 +++
  drivers/iio/Makefile  |   1 +
  drivers/iio/industrialio-configfs.c   |  49 ++
  drivers/iio/industrialio-sw-trigger.c | 119 ++
  include/linux/iio/sw_trigger.h|  99 
  5 files changed, 276 insertions(+)
  create mode 100644 drivers/iio/industrialio-sw-trigger.c
  create mode 100644 include/linux/iio/sw_trigger.h

diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index f2b0d77..117c05a 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -66,6 +66,14 @@ config IIO_CONSUMERS_PER_TRIGGER
This value controls the maximum number of consumers that a
given trigger may handle. Default is 2.
  
+config IIO_SW_TRIGGER

+   bool Enable software triggers support
+   depends on IIO_TRIGGER
+   help
+Provides IIO core support for software triggers. A software
+trigger can be created via configfs or directly by a driver
+using the API provided.
+
  source drivers/iio/accel/Kconfig
  source drivers/iio/adc/Kconfig
  source drivers/iio/amplifiers/Kconfig
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index dbf5f9a..31aead3 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_IIO) += industrialio.o
  industrialio-y := industrialio-core.o industrialio-event.o inkern.o
  industrialio-$(CONFIG_IIO_BUFFER) += industrialio-buffer.o
  industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
+industrialio-$(CONFIG_IIO_SW_TRIGGER) += industrialio-sw-trigger.o
  industrialio-$(CONFIG_IIO_BUFFER_CB) += buffer_cb.o
  
  obj-$(CONFIG_IIO_TRIGGERED_BUFFER) += industrialio-triggered-buffer.o

diff --git a/drivers/iio/industrialio-configfs.c 
b/drivers/iio/industrialio-configfs.c
index 3edee90..ced7115 100644
--- a/drivers/iio/industrialio-configfs.c
+++ b/drivers/iio/industrialio-configfs.c
@@ -15,6 +15,40 @@
  #include linux/slab.h
  
  #include linux/iio/iio.h

+#include linux/iio/sw_trigger.h
+
+static struct config_group *trigger_make_group(struct config_group *group,
+  const char *name)
+{
+   struct iio_sw_trigger *t;
+
+   t = iio_sw_trigger_create(group-cg_item.ci_name, name);
+   if (IS_ERR(t))
+   return ERR_CAST(t);
+
+   config_item_set_name(t-group.cg_item, name);
+
+   return t-group;
+}
+
+static void trigger_drop_group(struct config_group *group,
+  struct config_item *item)
+{
+   struct iio_sw_trigger *t = to_iio_sw_trigger(item);
+
+   iio_sw_trigger_destroy(t);
+   config_item_put(item);
+}
+
+static struct configfs_group_operations trigger_ops = {
+   .make_group = trigger_make_group,
+   .drop_item  = trigger_drop_group,
+};
+
+static struct config_item_type iio_trigger_type_group_type = {
+   .ct_group_ops = trigger_ops,
+   .ct_owner   = THIS_MODULE,
+};
  
  static struct config_item_type iio_triggers_group_type = {

.ct_owner = THIS_MODULE,
@@ -47,6 +81,21 @@ static struct configfs_subsystem iio_configfs_subsys = {
.su_mutex = __MUTEX_INITIALIZER(iio_configfs_subsys.su_mutex),
  };
  
+int iio_sw_trigger_type_configfs_register(struct iio_sw_trigger_type *tt)

+{
+   config_group_init_type_name(tt-group, tt-name,
+   iio_trigger_type_group_type);
+
+   return configfs_register_group(iio_triggers_group, tt-group);
+}
+EXPORT_SYMBOL_GPL(iio_sw_trigger_type_configfs_register);
+
+void iio_sw_trigger_type_configfs_unregister(struct iio_sw_trigger_type *tt)
+{
+   configfs_unregister_group(tt-group);
+}
+EXPORT_SYMBOL_GPL(iio_sw_trigger_type_configfs_unregister);
+
  static int __init iio_configfs_init(void)
  {
config_group_init(iio_triggers_group);
diff --git a/drivers/iio/industrialio-sw-trigger.c 
b/drivers/iio/industrialio-sw-trigger.c
new file mode 

Re: [PATCH v7 4/5] iio: trigger: Introduce IIO hrtimer based trigger

[Vladimir Barinov]

Hello Daniel,

I've verified that your hrtimer trigger works.

I have minor suggestions.

Will not it be useful to have ability to stop/start hrtimer polling
not only during attach/detach trigger.

f.e. writing 0 to sampling_frequency will hrtimer_cancel
and writing any valid frequency will hrtimer_start.

Regards,
Vladimir

On 11.08.2015 01:42, Daniel Baluta wrote:

This patch registers a new IIO software trigger interrupt source
based on high resolution timers.

Notice that if configfs is enabled we create sampling_frequency
attribute allowing users to change hrtimer period (1/sampling_frequency).

The IIO hrtimer trigger has a long history, this patch is based on
an older version from Marten and Lars-Peter.

Signed-off-by: Marten Svanfeldt mar...@intuitiveaerial.com
Signed-off-by: Lars-Peter Clausen l...@metafoo.de
Signed-off-by: Daniel Baluta daniel.bal...@intel.com
---
  drivers/iio/trigger/Kconfig|  10 ++
  drivers/iio/trigger/Makefile   |   2 +
  drivers/iio/trigger/iio-trig-hrtimer.c | 193 +
  3 files changed, 205 insertions(+)
  create mode 100644 drivers/iio/trigger/iio-trig-hrtimer.c

diff --git a/drivers/iio/trigger/Kconfig b/drivers/iio/trigger/Kconfig
index 7999612..4505281 100644
--- a/drivers/iio/trigger/Kconfig
+++ b/drivers/iio/trigger/Kconfig
@@ -5,6 +5,16 @@
  
  menu Triggers - standalone
  
+config IIO_HRTIMER_TRIGGER

+   tristate High resolution timer trigger
+   select IIO_SW_TRIGGER
+   help
+ Provides a frequency based IIO trigger using high resolution
+ timers as interrupt source.
+
+ To compile this driver as a module, choose M here: the
+ module will be called iio-trig-hrtimer.
+
  config IIO_INTERRUPT_TRIGGER
tristate Generic interrupt trigger
help
diff --git a/drivers/iio/trigger/Makefile b/drivers/iio/trigger/Makefile
index 0694dae..fe06eb5 100644
--- a/drivers/iio/trigger/Makefile
+++ b/drivers/iio/trigger/Makefile
@@ -3,5 +3,7 @@
  #
  
  # When adding new entries keep the list in alphabetical order

+
+obj-$(CONFIG_IIO_HRTIMER_TRIGGER) += iio-trig-hrtimer.o
  obj-$(CONFIG_IIO_INTERRUPT_TRIGGER) += iio-trig-interrupt.o
  obj-$(CONFIG_IIO_SYSFS_TRIGGER) += iio-trig-sysfs.o
diff --git a/drivers/iio/trigger/iio-trig-hrtimer.c 
b/drivers/iio/trigger/iio-trig-hrtimer.c
new file mode 100644
index 000..4631c7a
--- /dev/null
+++ b/drivers/iio/trigger/iio-trig-hrtimer.c
@@ -0,0 +1,193 @@
+/**
+ * The industrial I/O periodic hrtimer trigger driver
+ *
+ * Copyright (C) Intuitive Aerial AB
+ * Written by Marten Svanfeldt, mar...@intuitiveaerial.com
+ * Copyright (C) 2012, Analog Device Inc.
+ * Author: Lars-Peter Clausen l...@metafoo.de
+ * Copyright (C) 2015, Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ */
+#include linux/kernel.h
+#include linux/slab.h
+#include linux/hrtimer.h
+
+#include linux/iio/iio.h
+#include linux/iio/trigger.h
+#include linux/iio/sw_trigger.h
+
+/* default sampling frequency - 100Hz */
+#define HRTIMER_DEFAULT_SAMPLING_FREQUENCY 100
+
+struct iio_hrtimer_info {
+   struct iio_sw_trigger swt;
+   struct hrtimer timer;
+   unsigned long sampling_frequency;
+   ktime_t period;
+};
+
+static struct config_item_type iio_hrtimer_type = {
+   .ct_owner = THIS_MODULE,
+};
+
+static
+ssize_t iio_hrtimer_show_sampling_frequency(struct device *dev,
+   struct device_attribute *attr,
+   char *buf)
+{
+   struct iio_trigger *trig = to_iio_trigger(dev);
+   struct iio_hrtimer_info *info = iio_trigger_get_drvdata(trig);
+
+   return snprintf(buf, PAGE_SIZE, %lu\n, info-sampling_frequency);
+}
+
+static
+ssize_t iio_hrtimer_store_sampling_frequency(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t len)
+{
+   struct iio_trigger *trig = to_iio_trigger(dev);
+   struct iio_hrtimer_info *info = iio_trigger_get_drvdata(trig);
+   unsigned long val;
+   int ret;
+
+   ret = kstrtoul(buf, 10, val);
+   if (ret)
+   return ret;
+
+   if (!val || val  NSEC_PER_SEC)
+   return -EINVAL;
+
+   info-sampling_frequency = val;
+   info-period = ktime_set(0, NSEC_PER_SEC / val);
+
+   return len;
+}
+
+static DEVICE_ATTR(sampling_frequency, S_IRUGO | S_IWUSR,
+  iio_hrtimer_show_sampling_frequency,
+  iio_hrtimer_store_sampling_frequency);
+
+static struct attribute *iio_hrtimer_attrs[] = {
+   dev_attr_sampling_frequency.attr,
+   NULL
+};
+
+static const struct attribute_group iio_hrtimer_attr_group = {
+   .attrs = iio_hrtimer_attrs,
+};
+
+static const struct 

Re: [PATCH v3 5/7] iio: Support triggered events

[Vladimir Barinov]

Hi Jonathan,

Thank you for review.
Find some comments below.

Regards,
Vladimir

On 16.08.2015 12:20, Jonathan Cameron wrote:

On 29/07/15 13:57, Vladimir Barinov wrote:

Support triggered events.

This is useful for chips that don't have their own interrupt sources.
It allows to use generic/standalone iio triggers for those drivers.

As we have concluded this is a good thing to have, I've take a closer
look at it.

I think we need to slightly separate the buffer and event uses of
triggers as it's entirely plausible both might be enabled at the same
time.  Don't think this should be hard however.

I can concieve of weird restrictions from certain hardware (particularly
where hardware buffers are concerned) in which events are not monitored
when we are reading through the buffer but we can tackle that when we
actually need to.

Anyhow, few bits inline.  Thanks for your persistence with this!

Jonathan


Signed-off-by: Vladimir Barinov 
---
Changes in version 2:
- initially added
Changes in version 3:
- fixed grammar in patch description
- changed license header to match "GNU Public License v2 or later"

  drivers/iio/Kconfig|  6 +++
  drivers/iio/Makefile   |  1 +
  drivers/iio/industrialio-core.c|  4 +-
  drivers/iio/industrialio-trigger.c | 12 +-
  drivers/iio/industrialio-triggered-event.c | 68 ++
  include/linux/iio/iio.h|  1 +
  include/linux/iio/triggered_event.h| 11 +
  7 files changed, 99 insertions(+), 4 deletions(-)
  create mode 100644 drivers/iio/industrialio-triggered-event.c
  create mode 100644 include/linux/iio/triggered_event.h

diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 4011eff..8fcc92f 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -58,6 +58,12 @@ config IIO_CONSUMERS_PER_TRIGGER
This value controls the maximum number of consumers that a
given trigger may handle. Default is 2.
  
+config IIO_TRIGGERED_EVENT

+   tristate
+   select IIO_TRIGGER
+   help
+ Provides helper functions for setting up triggered events.
+
  source "drivers/iio/accel/Kconfig"
  source "drivers/iio/adc/Kconfig"
  source "drivers/iio/amplifiers/Kconfig"
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 698afc2..40dc13e 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -9,6 +9,7 @@ industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
  industrialio-$(CONFIG_IIO_BUFFER_CB) += buffer_cb.o
  
  obj-$(CONFIG_IIO_TRIGGERED_BUFFER) += industrialio-triggered-buffer.o

+obj-$(CONFIG_IIO_TRIGGERED_EVENT) += industrialio-triggered-event.o
  obj-$(CONFIG_IIO_KFIFO_BUF) += kfifo_buf.o
  
  obj-y += accel/

diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 3524b0d..54d71ea 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -948,7 +948,7 @@ static void iio_device_unregister_sysfs(struct iio_dev 
*indio_dev)
  static void iio_dev_release(struct device *device)
  {
struct iio_dev *indio_dev = dev_to_iio_dev(device);
-   if (indio_dev->modes & INDIO_BUFFER_TRIGGERED)
+   if (indio_dev->modes & (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
iio_device_unregister_trigger_consumer(indio_dev);
iio_device_unregister_eventset(indio_dev);
iio_device_unregister_sysfs(indio_dev);
@@ -1218,7 +1218,7 @@ int iio_device_register(struct iio_dev *indio_dev)
"Failed to register event set\n");
goto error_free_sysfs;
}
-   if (indio_dev->modes & INDIO_BUFFER_TRIGGERED)
+   if (indio_dev->modes & (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
iio_device_register_trigger_consumer(indio_dev);
  
  	if ((indio_dev->modes & INDIO_ALL_BUFFER_MODES) &&

diff --git a/drivers/iio/industrialio-trigger.c 
b/drivers/iio/industrialio-trigger.c
index d31098e..72b63e7 100644
--- a/drivers/iio/industrialio-trigger.c
+++ b/drivers/iio/industrialio-trigger.c
@@ -345,10 +345,18 @@ static ssize_t iio_trigger_write_current(struct device 
*dev,
  
  	indio_dev->trig = trig;
  
-	if (oldtrig)

+   if (oldtrig) {
+   if (indio_dev->currentmode == INDIO_EVENT_TRIGGERED)
+   iio_trigger_detach_poll_func(oldtrig,
+indio_dev->pollfunc);
iio_trigger_put(oldtrig);
-   if (indio_dev->trig)
+   }
+   if (indio_dev->trig) {
iio_trigger_get(indio_dev->trig);
+   if (indio_dev->currentmode == INDIO_EVENT_TRIGGERED)
+   iio_trigger_attach_poll_func(indio_dev->trig,
+indio_dev->pollfunc);
+   }
  
  	return len;

  }
diff --g

Re: [PATCH v3 1/7] iio: adc: hi8435: Holt HI-8435 threshold detector

[Vladimir Barinov]

Hi Jonathan,

On 16.08.2015 12:00, Jonathan Cameron wrote:

On 11/08/15 15:37, Vladimir Barinov wrote:

Hi Jonathan,

Thank you for the review.

Sorry I was being so indecisive.  Always take a while when something
'new' turns up to gather opinions and select the best option.  You
are just the unlucky guy who happened to hit the question first!

Anyhow, I'm basically happy (now) with the events approach though
I would suggest some modifications to how exactly it is done
(see inline).

Nice to hear!
I've got some light in the tunnel :)

Thank you for dealing with this stuff.
Please find one minor questions below.

Regards,
Vladimir



Jonathan

On 08.08.2015 20:56, Jonathan Cameron wrote:

On 29/07/15 13:56, Vladimir Barinov wrote:

Add Holt threshold detector driver for HI-8435 chip

Signed-off-by: Vladimir Barinov 

Because it usually reads better that way, I review from the bottom.
Might make more sense if you read the comments that way around ;)

I did try to match this way.
At some places the comments below the code, but in other places the comments 
are above the code :)

Yeah, I've never been consistent ;)

I'm going to guess that the typical usecase for this device is in realtime
systems where polling gives a nice predictable timing (hence the lack of any
interrupt support).  These typically operate as 'scanning' devices
(e.g. you update all state at approximately the same time, by reading
one input after another in some predefined order).

Probably you are right about 8435 h/w design or there were other
reason why this functionality was dropped in comparison to 8429
chip. The Holt chip hi-8429 has both hardware interrupt and hardware
debounce enable lines, but it has less amount of sensors (just 8
outputs).

Does the use of events actually map well to this use case?  You are taking
something that (other than the results being a bit different) is basically
a digital I/O interface and mapping it (sort of) to an interrupt chip
when it isn't nothing of the sort.

a) Using hardware point of view.

I was thinking that it matches the events a little bit more then
buffer, because the chip senses for threshold changes (passing
threshold high or threshold low margins) and then notifies the upper
layer. The bad point here is that the chip does not have interrupt
line for sensor state change (i.e. threshold passing).

If it would have the interrupt line for sensor state changes then the
event interface map this case best way.

Agreed.  I'm coming round to the argument Lars made that we should end
up with the interface being the same whether or not there is an interrupt
there.  Actually I suspect in the long run we will end up with both
a buffered interface and an event interface as they simply have different
usecases for the same hardware (which is why we are having these lengthy
discussions in the first place!)


b) Using s/w point of view

I answer relying on current iio stack implementation. I do understand
that the 8435 chip is not the common/usual iio client like
adc/dac/light/others, so I'm trying to match the existent iio stack.

Yes.  It's certainly throwing up lots of questions!

 From s/w point of view it does not matter much difference between
event or buffer interface for this chip because in provides 1-bit
change and does not have it's own interrupt source line.

Yes, just requires the userspace side to track the state if it wants
to know.  Actually the one nasty is initialization. When the events
are first enabled I guess we fire them all once (if any limits are currently
breached).  That way the state can always be known.

The event interface has generic interface to fill in falling/rising
thresholds but buffer interface does not.

We can always add more ABI.


The buffer interface has already has the trigger poll func support
but event interface does not. So I've tried to implement the
triggered event in iio stack. BTW: Doesn't the triggered event
support match the usecase with iio_interrupt_trigger? Or it does not
make sense to have triggered events (even with irqtrig) at all?

Initially I was unsure about this, but Lars and you have convinced me.
I'm happy having that in the subsystem.  Can also be used for devices
which have an interrupt but which didn't get wired for some reason rather
than having them have some internal poll loop (as we have done up to now).

  

I'd like more opinions on this, but my gut reaction is that we would
be better making the normal buffered infrastructure handle this data
properly rather than pushing it through the events intrastructure.

Your solution is neat and tidy in someways but feels like it is mashing
data into a particular format.

Probably that's all because the chip lacks smth from buffer interface
approach (the data should diferent the 1-bit) and smth from event
interface approach (lack of h/w interrupt line)

Agreed.

To add to the complexity we could have debounce logic.  If we mapped to a
fill the buffer with a scan mode, how would we handle

Re: [PATCH v3 1/7] iio: adc: hi8435: Holt HI-8435 threshold detector

[Vladimir Barinov]

Hi Jonathan,

On 16.08.2015 12:00, Jonathan Cameron wrote:

On 11/08/15 15:37, Vladimir Barinov wrote:

Hi Jonathan,

Thank you for the review.

Sorry I was being so indecisive.  Always take a while when something
'new' turns up to gather opinions and select the best option.  You
are just the unlucky guy who happened to hit the question first!

Anyhow, I'm basically happy (now) with the events approach though
I would suggest some modifications to how exactly it is done
(see inline).

Nice to hear!
I've got some light in the tunnel :)

Thank you for dealing with this stuff.
Please find one minor questions below.

Regards,
Vladimir



Jonathan

On 08.08.2015 20:56, Jonathan Cameron wrote:

On 29/07/15 13:56, Vladimir Barinov wrote:

Add Holt threshold detector driver for HI-8435 chip

Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com

Because it usually reads better that way, I review from the bottom.
Might make more sense if you read the comments that way around ;)

I did try to match this way.
At some places the comments below the code, but in other places the comments 
are above the code :)

Yeah, I've never been consistent ;)

I'm going to guess that the typical usecase for this device is in realtime
systems where polling gives a nice predictable timing (hence the lack of any
interrupt support).  These typically operate as 'scanning' devices
(e.g. you update all state at approximately the same time, by reading
one input after another in some predefined order).

Probably you are right about 8435 h/w design or there were other
reason why this functionality was dropped in comparison to 8429
chip. The Holt chip hi-8429 has both hardware interrupt and hardware
debounce enable lines, but it has less amount of sensors (just 8
outputs).

Does the use of events actually map well to this use case?  You are taking
something that (other than the results being a bit different) is basically
a digital I/O interface and mapping it (sort of) to an interrupt chip
when it isn't nothing of the sort.

a) Using hardware point of view.

I was thinking that it matches the events a little bit more then
buffer, because the chip senses for threshold changes (passing
threshold high or threshold low margins) and then notifies the upper
layer. The bad point here is that the chip does not have interrupt
line for sensor state change (i.e. threshold passing).

If it would have the interrupt line for sensor state changes then the
event interface map this case best way.

Agreed.  I'm coming round to the argument Lars made that we should end
up with the interface being the same whether or not there is an interrupt
there.  Actually I suspect in the long run we will end up with both
a buffered interface and an event interface as they simply have different
usecases for the same hardware (which is why we are having these lengthy
discussions in the first place!)


b) Using s/w point of view

I answer relying on current iio stack implementation. I do understand
that the 8435 chip is not the common/usual iio client like
adc/dac/light/others, so I'm trying to match the existent iio stack.

Yes.  It's certainly throwing up lots of questions!

 From s/w point of view it does not matter much difference between
event or buffer interface for this chip because in provides 1-bit
change and does not have it's own interrupt source line.

Yes, just requires the userspace side to track the state if it wants
to know.  Actually the one nasty is initialization. When the events
are first enabled I guess we fire them all once (if any limits are currently
breached).  That way the state can always be known.

The event interface has generic interface to fill in falling/rising
thresholds but buffer interface does not.

We can always add more ABI.


The buffer interface has already has the trigger poll func support
but event interface does not. So I've tried to implement the
triggered event in iio stack. BTW: Doesn't the triggered event
support match the usecase with iio_interrupt_trigger? Or it does not
make sense to have triggered events (even with irqtrig) at all?

Initially I was unsure about this, but Lars and you have convinced me.
I'm happy having that in the subsystem.  Can also be used for devices
which have an interrupt but which didn't get wired for some reason rather
than having them have some internal poll loop (as we have done up to now).

  

I'd like more opinions on this, but my gut reaction is that we would
be better making the normal buffered infrastructure handle this data
properly rather than pushing it through the events intrastructure.

Your solution is neat and tidy in someways but feels like it is mashing
data into a particular format.

Probably that's all because the chip lacks smth from buffer interface
approach (the data should diferent the 1-bit) and smth from event
interface approach (lack of h/w interrupt line)

Agreed.

To add to the complexity we could have debounce logic.  If we mapped to a
fill the buffer

Re: [PATCH v3 5/7] iio: Support triggered events

[Vladimir Barinov]

Hi Jonathan,

Thank you for review.
Find some comments below.

Regards,
Vladimir

On 16.08.2015 12:20, Jonathan Cameron wrote:

On 29/07/15 13:57, Vladimir Barinov wrote:

Support triggered events.

This is useful for chips that don't have their own interrupt sources.
It allows to use generic/standalone iio triggers for those drivers.

As we have concluded this is a good thing to have, I've take a closer
look at it.

I think we need to slightly separate the buffer and event uses of
triggers as it's entirely plausible both might be enabled at the same
time.  Don't think this should be hard however.

I can concieve of weird restrictions from certain hardware (particularly
where hardware buffers are concerned) in which events are not monitored
when we are reading through the buffer but we can tackle that when we
actually need to.

Anyhow, few bits inline.  Thanks for your persistence with this!

Jonathan


Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
---
Changes in version 2:
- initially added
Changes in version 3:
- fixed grammar in patch description
- changed license header to match GNU Public License v2 or later

  drivers/iio/Kconfig|  6 +++
  drivers/iio/Makefile   |  1 +
  drivers/iio/industrialio-core.c|  4 +-
  drivers/iio/industrialio-trigger.c | 12 +-
  drivers/iio/industrialio-triggered-event.c | 68 ++
  include/linux/iio/iio.h|  1 +
  include/linux/iio/triggered_event.h| 11 +
  7 files changed, 99 insertions(+), 4 deletions(-)
  create mode 100644 drivers/iio/industrialio-triggered-event.c
  create mode 100644 include/linux/iio/triggered_event.h

diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 4011eff..8fcc92f 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -58,6 +58,12 @@ config IIO_CONSUMERS_PER_TRIGGER
This value controls the maximum number of consumers that a
given trigger may handle. Default is 2.
  
+config IIO_TRIGGERED_EVENT

+   tristate
+   select IIO_TRIGGER
+   help
+ Provides helper functions for setting up triggered events.
+
  source drivers/iio/accel/Kconfig
  source drivers/iio/adc/Kconfig
  source drivers/iio/amplifiers/Kconfig
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 698afc2..40dc13e 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -9,6 +9,7 @@ industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
  industrialio-$(CONFIG_IIO_BUFFER_CB) += buffer_cb.o
  
  obj-$(CONFIG_IIO_TRIGGERED_BUFFER) += industrialio-triggered-buffer.o

+obj-$(CONFIG_IIO_TRIGGERED_EVENT) += industrialio-triggered-event.o
  obj-$(CONFIG_IIO_KFIFO_BUF) += kfifo_buf.o
  
  obj-y += accel/

diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 3524b0d..54d71ea 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -948,7 +948,7 @@ static void iio_device_unregister_sysfs(struct iio_dev 
*indio_dev)
  static void iio_dev_release(struct device *device)
  {
struct iio_dev *indio_dev = dev_to_iio_dev(device);
-   if (indio_dev-modes  INDIO_BUFFER_TRIGGERED)
+   if (indio_dev-modes  (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
iio_device_unregister_trigger_consumer(indio_dev);
iio_device_unregister_eventset(indio_dev);
iio_device_unregister_sysfs(indio_dev);
@@ -1218,7 +1218,7 @@ int iio_device_register(struct iio_dev *indio_dev)
Failed to register event set\n);
goto error_free_sysfs;
}
-   if (indio_dev-modes  INDIO_BUFFER_TRIGGERED)
+   if (indio_dev-modes  (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
iio_device_register_trigger_consumer(indio_dev);
  
  	if ((indio_dev-modes  INDIO_ALL_BUFFER_MODES) 

diff --git a/drivers/iio/industrialio-trigger.c 
b/drivers/iio/industrialio-trigger.c
index d31098e..72b63e7 100644
--- a/drivers/iio/industrialio-trigger.c
+++ b/drivers/iio/industrialio-trigger.c
@@ -345,10 +345,18 @@ static ssize_t iio_trigger_write_current(struct device 
*dev,
  
  	indio_dev-trig = trig;
  
-	if (oldtrig)

+   if (oldtrig) {
+   if (indio_dev-currentmode == INDIO_EVENT_TRIGGERED)
+   iio_trigger_detach_poll_func(oldtrig,
+indio_dev-pollfunc);
iio_trigger_put(oldtrig);
-   if (indio_dev-trig)
+   }
+   if (indio_dev-trig) {
iio_trigger_get(indio_dev-trig);
+   if (indio_dev-currentmode == INDIO_EVENT_TRIGGERED)
+   iio_trigger_attach_poll_func(indio_dev-trig,
+indio_dev-pollfunc);
+   }
  
  	return len;

  }
diff --git a/drivers/iio/industrialio-triggered-event.c 
b/drivers/iio/industrialio-triggered-event.c
new file mode 100644
index

Re: [PATCH v3 1/7] iio: adc: hi8435: Holt HI-8435 threshold detector

[Vladimir Barinov]

Hi Jonathan,

Thank you for the review.

On 08.08.2015 20:56, Jonathan Cameron wrote:

On 29/07/15 13:56, Vladimir Barinov wrote:

Add Holt threshold detector driver for HI-8435 chip

Signed-off-by: Vladimir Barinov 

Because it usually reads better that way, I review from the bottom.
Might make more sense if you read the comments that way around ;)

I did try to match this way.
At some places the comments below the code, but in other places the 
comments are above the code :)


I'm going to guess that the typical usecase for this device is in realtime
systems where polling gives a nice predictable timing (hence the lack of any
interrupt support).  These typically operate as 'scanning' devices
(e.g. you update all state at approximately the same time, by reading
one input after another in some predefined order).
Probably you are right about 8435 h/w design or there were other reason 
why this functionality was dropped in comparison to 8429 chip.
The Holt chip hi-8429 has both hardware interrupt and hardware debounce 
enable lines, but it has less amount of sensors (just 8 outputs).




Does the use of events actually map well to this use case?  You are taking
something that (other than the results being a bit different) is basically
a digital I/O interface and mapping it (sort of) to an interrupt chip
when it isn't nothing of the sort.

a) Using hardware point of view.

I was thinking that it matches the events a little bit more then buffer, 
because the chip senses for threshold changes
(passing threshold high or threshold low margins) and then notifies the 
upper layer.
The bad point here is that the chip does not have interrupt line for 
sensor state change (i.e. threshold passing).


If it would have the interrupt line for sensor state changes then the 
event interface map this case best way.


b) Using s/w point of view

I answer relying on current iio stack implementation.
I do understand that the  8435 chip is not the common/usual iio client 
like adc/dac/light/others, so I'm trying to

match the existent iio stack.

From s/w point of view it does not matter much difference between event 
or buffer interface for this chip because

in provides 1-bit change and does not have it's own interrupt source line.

The event interface has generic interface to fill in falling/rising 
thresholds but buffer interface does not.


The buffer interface has already has the trigger poll func support but 
event interface does not.

So I've tried to implement the triggered event in iio stack.
BTW: Doesn't the triggered event support match the usecase with 
iio_interrupt_trigger? Or it does not make sense to have triggered 
events (even with irqtrig) at all?




I'd like more opinions on this, but my gut reaction is that we would
be better making the normal buffered infrastructure handle this data
properly rather than pushing it through the events intrastructure.

Your solution is neat and tidy in someways but feels like it is mashing
data into a particular format.
Probably that's all because the chip lacks smth from buffer interface 
approach (the data should diferent the 1-bit) and

smth from event interface approach (lack of h/w interrupt line)



To add to the complexity we could have debounce logic.  If we mapped to a
fill the buffer with a scan mode, how would we handle this?
My guess is that it would simply delay transistions.  Perhaps we even
support reading both the value right now and the debounced value if that
is possible?
I did handle it in the driver the same way in both cases (buffer and 
event interfaces):
event/buffer trigger issues interrupt and then the driver checks value 
right now and after delay (debounce_interval).


If we do not plan to put debounced values to buffer then we may cache 
during debouncing procedure and then
return via IIO_CHAN_INFO_DEBOUNCE_VALUE (or other info name). Probably 
even with timestamp.




However, here the debounce is all software.  To my mind, move this into
userspace entirely. We aren't dealing with big data here so it's hardly
going to be particularly challenging.
I will drop it on your demand in favour to encourage chipmakers to 
provide h/w debounce,

but this was much easy/efficient to have it in kernel space, since
during run generic_buffer sample (or other) we got the new data and then 
we have to start timer, then timer expires
and we read raw values from sysfs manually to compare the one that came 
from buffer and one after debounce

delay.



So my gut feeling is definitely we need to make the buffer infrastructure
handle 1 bit values (in groups) then push this data out that way.

I will wait for your final decision.



Still I would like other opinions on this!

Jonathan


---
Changes in version 2:
- Added file sysfs-bus-iio-adc-hi8435
- Changed naming from "discrete ADC" to "threshold detector"
- Replaced swab16p/swab32p with be16_to_cpup/be32_to_cpup
- Made *_show and *_store functions static
- moved out from iio buffers to iio eve

Re: [PATCH v3 1/7] iio: adc: hi8435: Holt HI-8435 threshold detector

[Vladimir Barinov]

Hi Jonathan,

Thank you for the review.

On 08.08.2015 20:56, Jonathan Cameron wrote:

On 29/07/15 13:56, Vladimir Barinov wrote:

Add Holt threshold detector driver for HI-8435 chip

Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com

Because it usually reads better that way, I review from the bottom.
Might make more sense if you read the comments that way around ;)

I did try to match this way.
At some places the comments below the code, but in other places the 
comments are above the code :)


I'm going to guess that the typical usecase for this device is in realtime
systems where polling gives a nice predictable timing (hence the lack of any
interrupt support).  These typically operate as 'scanning' devices
(e.g. you update all state at approximately the same time, by reading
one input after another in some predefined order).
Probably you are right about 8435 h/w design or there were other reason 
why this functionality was dropped in comparison to 8429 chip.
The Holt chip hi-8429 has both hardware interrupt and hardware debounce 
enable lines, but it has less amount of sensors (just 8 outputs).




Does the use of events actually map well to this use case?  You are taking
something that (other than the results being a bit different) is basically
a digital I/O interface and mapping it (sort of) to an interrupt chip
when it isn't nothing of the sort.

a) Using hardware point of view.

I was thinking that it matches the events a little bit more then buffer, 
because the chip senses for threshold changes
(passing threshold high or threshold low margins) and then notifies the 
upper layer.
The bad point here is that the chip does not have interrupt line for 
sensor state change (i.e. threshold passing).


If it would have the interrupt line for sensor state changes then the 
event interface map this case best way.


b) Using s/w point of view

I answer relying on current iio stack implementation.
I do understand that the  8435 chip is not the common/usual iio client 
like adc/dac/light/others, so I'm trying to

match the existent iio stack.

From s/w point of view it does not matter much difference between event 
or buffer interface for this chip because

in provides 1-bit change and does not have it's own interrupt source line.

The event interface has generic interface to fill in falling/rising 
thresholds but buffer interface does not.


The buffer interface has already has the trigger poll func support but 
event interface does not.

So I've tried to implement the triggered event in iio stack.
BTW: Doesn't the triggered event support match the usecase with 
iio_interrupt_trigger? Or it does not make sense to have triggered 
events (even with irqtrig) at all?




I'd like more opinions on this, but my gut reaction is that we would
be better making the normal buffered infrastructure handle this data
properly rather than pushing it through the events intrastructure.

Your solution is neat and tidy in someways but feels like it is mashing
data into a particular format.
Probably that's all because the chip lacks smth from buffer interface 
approach (the data should diferent the 1-bit) and

smth from event interface approach (lack of h/w interrupt line)



To add to the complexity we could have debounce logic.  If we mapped to a
fill the buffer with a scan mode, how would we handle this?
My guess is that it would simply delay transistions.  Perhaps we even
support reading both the value right now and the debounced value if that
is possible?
I did handle it in the driver the same way in both cases (buffer and 
event interfaces):
event/buffer trigger issues interrupt and then the driver checks value 
right now and after delay (debounce_interval).


If we do not plan to put debounced values to buffer then we may cache 
during debouncing procedure and then
return via IIO_CHAN_INFO_DEBOUNCE_VALUE (or other info name). Probably 
even with timestamp.




However, here the debounce is all software.  To my mind, move this into
userspace entirely. We aren't dealing with big data here so it's hardly
going to be particularly challenging.
I will drop it on your demand in favour to encourage chipmakers to 
provide h/w debounce,

but this was much easy/efficient to have it in kernel space, since
during run generic_buffer sample (or other) we got the new data and then 
we have to start timer, then timer expires
and we read raw values from sysfs manually to compare the one that came 
from buffer and one after debounce

delay.



So my gut feeling is definitely we need to make the buffer infrastructure
handle 1 bit values (in groups) then push this data out that way.

I will wait for your final decision.



Still I would like other opinions on this!

Jonathan


---
Changes in version 2:
- Added file sysfs-bus-iio-adc-hi8435
- Changed naming from discrete ADC to threshold detector
- Replaced swab16p/swab32p with be16_to_cpup/be32_to_cpup
- Made *_show and *_store functions static
- moved out from iio buffers

Re: [PATCH v3 5/7] iio: Support triggered events

[Vladimir Barinov]

Hi Lars,

On 07.08.2015 16:45, Lars-Peter Clausen wrote:

Hi,

On 07/29/2015 02:57 PM, Vladimir Barinov wrote:

Support triggered events.

This is useful for chips that don't have their own interrupt sources.
It allows to use generic/standalone iio triggers for those drivers.


Thanks for the patch. Can you describe in more detail how
INDIO_EVENT_TRIGGERED differs from the INDIO_BUFFER_TRIGGERED. By just
looking at the source code I don't understand quite why it is necessary.
This is needed for the case when iio buffer is not used and used only 
iio event.


The difference to INDIO_BUFFER_TRIGGERED is that for triggered buffer 
the trigger poll function is attached (using 
iio_trigger_attach_poll_func) only in
industrialio-buffer.c using number of steps/conditions starting by 
issuing 1 to buffer/enable sysfs path.


For chips that do not use iio buffer but use only iio events the 
iio_trigger_attach_poll_func never called.


In case of using INDIO_BUFFER_TRIGGERED the poll func is 
attached/detached via industrialio-buffer.c
In case of using INDIO_EVENT_TRIGGERED the poll func is 
attached/detached via industrialio-trigger.c during set/change the 
current trigger.


Regards,
Vladimir



Thanks,
- Lars



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 5/7] iio: Support triggered events

[Vladimir Barinov]

Hi Lars,

On 07.08.2015 16:45, Lars-Peter Clausen wrote:

Hi,

On 07/29/2015 02:57 PM, Vladimir Barinov wrote:

Support triggered events.

This is useful for chips that don't have their own interrupt sources.
It allows to use generic/standalone iio triggers for those drivers.


Thanks for the patch. Can you describe in more detail how
INDIO_EVENT_TRIGGERED differs from the INDIO_BUFFER_TRIGGERED. By just
looking at the source code I don't understand quite why it is necessary.
This is needed for the case when iio buffer is not used and used only 
iio event.


The difference to INDIO_BUFFER_TRIGGERED is that for triggered buffer 
the trigger poll function is attached (using 
iio_trigger_attach_poll_func) only in
industrialio-buffer.c using number of steps/conditions starting by 
issuing 1 to buffer/enable sysfs path.


For chips that do not use iio buffer but use only iio events the 
iio_trigger_attach_poll_func never called.


In case of using INDIO_BUFFER_TRIGGERED the poll func is 
attached/detached via industrialio-buffer.c
In case of using INDIO_EVENT_TRIGGERED the poll func is 
attached/detached via industrialio-trigger.c during set/change the 
current trigger.


Regards,
Vladimir



Thanks,
- Lars



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 7/7] iio: Fix typos in ABI documentation

[Vladimir Barinov]

Fix typos in ABI documentation

Signed-off-by: Vladimir Barinov 
---
Changes in version 3:
- initially added

 Documentation/ABI/testing/sysfs-bus-iio | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
b/Documentation/ABI/testing/sysfs-bus-iio
index 65bf49e..71a48b7 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -488,7 +488,7 @@ Contact:linux-...@vger.kernel.org
 Description:
Specifies the output powerdown mode.
DAC output stage is disconnected from the amplifier and
-   1kohm_to_gnd: connected to ground via an 1kOhm resistor,
+   1kohm_to_gnd: connected to ground via an 1kOhm resistor,
6kohm_to_gnd: connected to ground via a 6kOhm resistor,
20kohm_to_gnd: connected to ground via a 20kOhm resistor,
100kohm_to_gnd: connected to ground via an 100kOhm resistor,
@@ -498,9 +498,9 @@ Description:
outX_powerdown_mode_available. If Y is not present the
mode is shared across all outputs.
 
-What:  /sys/.../iio:deviceX/out_votlageY_powerdown_mode_available
+What:  /sys/.../iio:deviceX/out_voltageY_powerdown_mode_available
 What:  /sys/.../iio:deviceX/out_voltage_powerdown_mode_available
-What:  /sys/.../iio:deviceX/out_altvotlageY_powerdown_mode_available
+What:  /sys/.../iio:deviceX/out_altvoltageY_powerdown_mode_available
 What:  /sys/.../iio:deviceX/out_altvoltage_powerdown_mode_available
 KernelVersion: 2.6.38
 Contact:   linux-...@vger.kernel.org
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 5/7] iio: Support triggered events

[Vladimir Barinov]

Support triggered events.

This is useful for chips that don't have their own interrupt sources.
It allows to use generic/standalone iio triggers for those drivers.

Signed-off-by: Vladimir Barinov 
---
Changes in version 2:
- initially added
Changes in version 3:
- fixed grammar in patch description
- changed license header to match "GNU Public License v2 or later"

 drivers/iio/Kconfig|  6 +++
 drivers/iio/Makefile   |  1 +
 drivers/iio/industrialio-core.c|  4 +-
 drivers/iio/industrialio-trigger.c | 12 +-
 drivers/iio/industrialio-triggered-event.c | 68 ++
 include/linux/iio/iio.h|  1 +
 include/linux/iio/triggered_event.h| 11 +
 7 files changed, 99 insertions(+), 4 deletions(-)
 create mode 100644 drivers/iio/industrialio-triggered-event.c
 create mode 100644 include/linux/iio/triggered_event.h

diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 4011eff..8fcc92f 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -58,6 +58,12 @@ config IIO_CONSUMERS_PER_TRIGGER
This value controls the maximum number of consumers that a
given trigger may handle. Default is 2.
 
+config IIO_TRIGGERED_EVENT
+   tristate
+   select IIO_TRIGGER
+   help
+ Provides helper functions for setting up triggered events.
+
 source "drivers/iio/accel/Kconfig"
 source "drivers/iio/adc/Kconfig"
 source "drivers/iio/amplifiers/Kconfig"
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 698afc2..40dc13e 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -9,6 +9,7 @@ industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
 industrialio-$(CONFIG_IIO_BUFFER_CB) += buffer_cb.o
 
 obj-$(CONFIG_IIO_TRIGGERED_BUFFER) += industrialio-triggered-buffer.o
+obj-$(CONFIG_IIO_TRIGGERED_EVENT) += industrialio-triggered-event.o
 obj-$(CONFIG_IIO_KFIFO_BUF) += kfifo_buf.o
 
 obj-y += accel/
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 3524b0d..54d71ea 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -948,7 +948,7 @@ static void iio_device_unregister_sysfs(struct iio_dev 
*indio_dev)
 static void iio_dev_release(struct device *device)
 {
struct iio_dev *indio_dev = dev_to_iio_dev(device);
-   if (indio_dev->modes & INDIO_BUFFER_TRIGGERED)
+   if (indio_dev->modes & (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
iio_device_unregister_trigger_consumer(indio_dev);
iio_device_unregister_eventset(indio_dev);
iio_device_unregister_sysfs(indio_dev);
@@ -1218,7 +1218,7 @@ int iio_device_register(struct iio_dev *indio_dev)
"Failed to register event set\n");
goto error_free_sysfs;
}
-   if (indio_dev->modes & INDIO_BUFFER_TRIGGERED)
+   if (indio_dev->modes & (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
iio_device_register_trigger_consumer(indio_dev);
 
if ((indio_dev->modes & INDIO_ALL_BUFFER_MODES) &&
diff --git a/drivers/iio/industrialio-trigger.c 
b/drivers/iio/industrialio-trigger.c
index d31098e..72b63e7 100644
--- a/drivers/iio/industrialio-trigger.c
+++ b/drivers/iio/industrialio-trigger.c
@@ -345,10 +345,18 @@ static ssize_t iio_trigger_write_current(struct device 
*dev,
 
indio_dev->trig = trig;
 
-   if (oldtrig)
+   if (oldtrig) {
+   if (indio_dev->currentmode == INDIO_EVENT_TRIGGERED)
+   iio_trigger_detach_poll_func(oldtrig,
+indio_dev->pollfunc);
iio_trigger_put(oldtrig);
-   if (indio_dev->trig)
+   }
+   if (indio_dev->trig) {
iio_trigger_get(indio_dev->trig);
+   if (indio_dev->currentmode == INDIO_EVENT_TRIGGERED)
+   iio_trigger_attach_poll_func(indio_dev->trig,
+indio_dev->pollfunc);
+   }
 
return len;
 }
diff --git a/drivers/iio/industrialio-triggered-event.c 
b/drivers/iio/industrialio-triggered-event.c
new file mode 100644
index 000..1e5ad33
--- /dev/null
+++ b/drivers/iio/industrialio-triggered-event.c
@@ -0,0 +1,68 @@
+ /*
+ * Copyright (C) 2015 Cogent Embedded, Inc.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * iio_triggered_event_setup() - Setup pollfunc for triggered event
+ * @indio_dev: IIO device structure
+ * @pollfunc_bh:   Func

[PATCH v3 3/7] dt: Document Holt HI-8435 bindings

[Vladimir Barinov]

These bindings can be used to register Holt HI-8435 threshold detector

Signed-off-by: Vladimir Barinov 
---
Changes in version 2:
- renamed file name hi-843x.txt to hi8435.txt
- removed hi-8436,hi-8436,hi-8437
- removed holt,debounce-soft field
- renamed holt,debounc-soft-delay to holt,debounce-interval
- renamed mr-gpio to reset-gpios
Changes in version 3:
- none

 .../devicetree/bindings/iio/adc/hi8435.txt | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/hi8435.txt

diff --git a/Documentation/devicetree/bindings/iio/adc/hi8435.txt 
b/Documentation/devicetree/bindings/iio/adc/hi8435.txt
new file mode 100644
index 000..1d33ad0
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/hi8435.txt
@@ -0,0 +1,25 @@
+Holt Integrated Circuits HI-8435 threshold detector bindings
+
+Required properties:
+ - compatible: should be "holt,hi8435"
+ - reg: spi chip select number for the device
+
+Recommended properties:
+ - spi-max-frequency: definition as per
+   Documentation/devicetree/bindings/spi/spi-bus.txt
+
+Optional properties:
+ - holt,reset-gpios: GPIO used for controlling the reset pin
+ - holt,debounce-interval: software debounce interval in milliseconds
+
+Example:
+sensor@0 {
+   compatible = "holt,hi8435";
+   reg = <0>;
+
+   holt,reset-gpios = < 1 0>;
+
+   holt,debounce-interval = <100>;
+
+   spi-max-frequency = <100>;
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 4/7] iio: trigger: Add periodic polling to SYSFS trigger

[Vladimir Barinov]

Add periodic polling functionality to SYSFS trigger

Signed-off-by: Vladimir Barinov 
---
Changes in version 2:
- initially added
Changes in version 3:
- fixed typos in ABI description

 .../ABI/testing/sysfs-bus-iio-trigger-sysfs| 11 
 drivers/iio/trigger/iio-trig-sysfs.c   | 58 ++
 2 files changed, 69 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs 
b/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs
index 5235e6c..03c18eb 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs
+++ b/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs
@@ -9,3 +9,14 @@ Description:
automated testing or in situations, where other trigger methods
are not applicable. For example no RTC or spare GPIOs.
X is the IIO index of the trigger.
+
+What:  /sys/bus/iio/devices/triggerX/trigger_poll
+KernelVersion: 4.2.0
+Contact:   linux-...@vger.kernel.org
+Description:
+   This file is provided by the iio-trig-sysfs stand-alone trigger
+   driver. Writing this file with positive value (in milliseconds)
+   will start periodic event triggering of the driver, associated
+   with this trigger. Writing this file with 0 will stop periodic
+   triggering.
+   X is the IIO index of the trigger.
diff --git a/drivers/iio/trigger/iio-trig-sysfs.c 
b/drivers/iio/trigger/iio-trig-sysfs.c
index 3dfab2b..ea79311 100644
--- a/drivers/iio/trigger/iio-trig-sysfs.c
+++ b/drivers/iio/trigger/iio-trig-sysfs.c
@@ -18,6 +18,8 @@
 struct iio_sysfs_trig {
struct iio_trigger *trig;
struct irq_work work;
+   struct delayed_work poll_work;
+   unsigned int poll_interval; /* msec */
int id;
struct list_head l;
 };
@@ -110,10 +112,63 @@ static ssize_t iio_sysfs_trigger_poll(struct device *dev,
return count;
 }
 
+static void iio_sysfs_trigger_queue_poll_work(struct iio_sysfs_trig *trig)
+{
+   unsigned long delay;
+
+   delay = msecs_to_jiffies(trig->poll_interval);
+   if (delay >= HZ)
+   delay = round_jiffies_relative(delay);
+
+   queue_delayed_work(system_freezable_wq, >poll_work, delay);
+}
+
+static void iio_sysfs_trigger_poll_work(struct work_struct *work)
+{
+   struct iio_sysfs_trig *trig = container_of(work, struct iio_sysfs_trig,
+  poll_work.work);
+
+   irq_work_queue(>work);
+   iio_sysfs_trigger_queue_poll_work(trig);
+}
+
+static ssize_t iio_sysfs_trigger_get_poll(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct iio_trigger *trig = to_iio_trigger(dev);
+   struct iio_sysfs_trig *sysfs_trig = iio_trigger_get_drvdata(trig);
+
+   return sprintf(buf, "%d\n", sysfs_trig->poll_interval);
+}
+
+static ssize_t iio_sysfs_trigger_set_poll(struct device *dev,
+   struct device_attribute *attr, const char *buf, size_t count)
+{
+   struct iio_trigger *trig = to_iio_trigger(dev);
+   struct iio_sysfs_trig *sysfs_trig = iio_trigger_get_drvdata(trig);
+   unsigned int interval;
+   int err;
+
+   err = kstrtouint(buf, 0, );
+   if (err)
+   return err;
+
+   sysfs_trig->poll_interval = interval;
+
+   cancel_delayed_work_sync(_trig->poll_work);
+   if (sysfs_trig->poll_interval > 0)
+   iio_sysfs_trigger_queue_poll_work(sysfs_trig);
+
+   return count;
+}
+
 static DEVICE_ATTR(trigger_now, S_IWUSR, NULL, iio_sysfs_trigger_poll);
+static DEVICE_ATTR(trigger_poll, S_IRUGO | S_IWUSR, iio_sysfs_trigger_get_poll,
+   iio_sysfs_trigger_set_poll);
 
 static struct attribute *iio_sysfs_trigger_attrs[] = {
_attr_trigger_now.attr,
+   _attr_trigger_poll.attr,
NULL,
 };
 
@@ -164,6 +219,7 @@ static int iio_sysfs_trigger_probe(int id)
iio_trigger_set_drvdata(t->trig, t);
 
init_irq_work(>work, iio_sysfs_trigger_work);
+   INIT_DELAYED_WORK(>poll_work, iio_sysfs_trigger_poll_work);
 
ret = iio_trigger_register(t->trig);
if (ret)
@@ -198,6 +254,8 @@ static int iio_sysfs_trigger_remove(int id)
return -EINVAL;
}
 
+   cancel_delayed_work_sync(>poll_work);
+
iio_trigger_unregister(t->trig);
iio_trigger_free(t->trig);
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 2/7] dt: Add vendor prefix 'holt'

[Vladimir Barinov]

Add Holt Integrated Circuits, Inc. to the list of device tree vendor
prefixes

Signed-off-by: Vladimir Barinov 
---
Changes in version 2:
- none
Changes in version 3:
- none

 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index d444757..bc64cc9 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -99,6 +99,7 @@ himax Himax Technologies, Inc.
 hisilicon  Hisilicon Limited.
 hitHitachi Ltd.
 hitex  Hitex Development Tools
+holt   Holt Integrated Circuits, Inc.
 honeywell  Honeywell
 hp Hewlett Packard
 i2se   I2SE GmbH
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 6/7] iio: Add ABI documentation for debounce_time

[Vladimir Barinov]

Add ABI documentation for debounce_time

Signed-off-by: Vladimir Barinov 
---
Changes in version 3:
- initially added

 Documentation/ABI/testing/sysfs-bus-iio | 9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
b/Documentation/ABI/testing/sysfs-bus-iio
index 09eac44..65bf49e 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -539,6 +539,15 @@ Description:
specified and unique if the output corresponds to a single
channel.
 
+What:  /sys/bus/iio/devices/iio:deviceX/debounce_time
+Date:  July 2015
+KernelVersion: 4.2.0
+Contact:   linux-...@vger.kernel.org
+Description:
+   Specifies number of milliseconds in which we perform hardware or
+   software debouncing. If value is set to 0 then debouncing is
+   disabled.
+
 What:  /sys/bus/iio/devices/iio:deviceX/events
 KernelVersion: 2.6.35
 Contact:   linux-...@vger.kernel.org
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 1/7] iio: adc: hi8435: Holt HI-8435 threshold detector

[Vladimir Barinov]

Add Holt threshold detector driver for HI-8435 chip

Signed-off-by: Vladimir Barinov 
---
Changes in version 2:
- Added file sysfs-bus-iio-adc-hi8435
- Changed naming from "discrete ADC" to "threshold detector"
- Replaced swab16p/swab32p with be16_to_cpup/be32_to_cpup
- Made *_show and *_store functions static
- moved out from iio buffers to iio events
- removed hi8436/hi8437 chips from the driver
- moved from debounce_soft_delay/enable to debounce_interval via
  IIO_CHAN_INFO_DEBOUNCE_TIME
- added name extention "comparator"
- moved threshold/hysteresis setup via generic iio event sysfs
- added software mask/unmask channel events
- added programming sensor outputs while in test mode via
  IIO_CHAN_INFO_RAW
- added channels .ext_info for programming sensing mode
Changes in version 3:
- fixed typos
- moved  to match alphabetic order
- fixed missed */event/* prefix in the ABI description
- added missed colon in sysfs-bus-iio-adc-hi8435 file after "What"
- moved in_voltageY_comparator_thresh_either_en and debounce_time
  to sysfs-bus-iio file
- added error checking for hi8435_write[b|w]

 Documentation/ABI/testing/sysfs-bus-iio|   1 +
 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 |  61 ++
 drivers/iio/adc/Kconfig|  11 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/hi8435.c   | 659 +
 5 files changed, 742 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
 create mode 100644 drivers/iio/adc/hi8435.c

diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
b/Documentation/ABI/testing/sysfs-bus-iio
index 70c9b1a..09eac44 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -572,6 +572,7 @@ What:   
/sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_thresh_r
 What:  
/sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_thresh_falling_en
 What:  
/sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_thresh_rising_en
 What:  
/sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_thresh_falling_en
+What:  
/sys/.../iio:deviceX/events/in_voltageY_comparator_thresh_either_en
 What:  /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_rising_en
 What:  /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_falling_en
 What:  /sys/.../iio:deviceX/events/in_voltageY_thresh_rising_en
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 
b/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
new file mode 100644
index 000..c59d81d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
@@ -0,0 +1,61 @@
+What:  /sys/bus/iio/devices/iio:deviceX/in_voltageY_comparator_raw
+Date:  July 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Read value is a voltage threshold measurement from channel Y.
+   Could be either 0 if sensor voltage is lower then low voltage
+   threshold or 1 if sensor voltage is higher then high voltage
+   threshold.
+   Write value is a programmed sensor output while in self test
+   mode. Could be either 0 or 1. The programmed value will be read
+   back if /sys/bus/iio/devices/iio:deviceX/test_enable is set to 
1.
+
+What:  /sys/bus/iio/devices/iio:deviceX/test_enable
+Date:  July 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Enable/disable the HI-8435 self test mode.
+   If enabled the in_voltageY_comparator_raw should be read back
+   accordingly to written value to in_voltageY_comparator_raw.
+
+What:  
/sys/bus/iio/devices/iio:deviceX/in_voltageY_comparator_sensing_mode
+Date:  July 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Program sensor type for threshold detector inputs.
+   Could be either "GND-Open" or "Supply-Open" mode. Y is a
+   threshold detector input channel. Channels 0..7, 8..15, 16..23
+   and 24..31 has common sensor types.
+
+What:  
/sys/bus/iio/devices/iio:deviceX/events/in_voltageY_comparator_thresh_falling_value
+Date:  July 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Channel Y low voltage threshold. If sensor input voltage goes 
lower then
+   this value then the threshold falling event is pushed.
+   Depending on in_voltageY_comparator_sensing_mode the low 
voltage threshold
+   is separately set for "GND-Open" and "Supply-Open" modes.
+   Channels 0..31 have common low threshold values, but could have 
differen

[PATCH v3 0/7] iio: adc: hi8435: Add Holt HI-8435 threshold detector

[Vladimir Barinov]

Hello,

This adds the folowing:
- Holt threshold detector driver for HI-8435 chip
- Add Holt vendor prefix
- Document HI-8435 DT bindings
- Add periodic polling functionality to SYSFS trigger
- Support triggered events
- Add ABI documentation for debounce_time
- Fix typos in sysfs-bus-iio file

PDF file can be found here:
http://www.holtic.com/products/3081-hi-8435.aspx

Vladimir Barinov (7):
[1/7] iio: adc: hi8435: Holt HI-8435 threshold detector
[2/7] dt: Add vendor prefix 'holt'
[3/7] dt: Document Holt HI-8435 bindings
[4/7] iio: trigger: Add periodic polling to SYSFS trigger
[5/7] iio: Support triggered events
[6/7] iio: Add ABI documentation for debounce_time
[7/7] iio: Fix typos in ABI documentation

---
This patchset is against the 'kernel/git/torvalds/linux.git' repo.

 Documentation/ABI/testing/sysfs-bus-iio   |   16 
 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435|   61 +
 Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs |   11 
 Documentation/devicetree/bindings/iio/adc/hi8435.txt  |   25 
 Documentation/devicetree/bindings/vendor-prefixes.txt |1 
 drivers/iio/Kconfig   |6 
 drivers/iio/Makefile  |1 
 drivers/iio/adc/Kconfig   |   11 
 drivers/iio/adc/Makefile  |1 
 drivers/iio/adc/hi8435.c  |  659 ++
 drivers/iio/industrialio-core.c   |4 
 drivers/iio/industrialio-trigger.c|   12 
 drivers/iio/industrialio-triggered-event.c|   68 +
 drivers/iio/trigger/iio-trig-sysfs.c  |   58 +
 include/linux/iio/iio.h   |1 
 include/linux/iio/triggered_event.h   |   11 
 16 files changed, 939 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
 create mode 100644 Documentation/devicetree/bindings/iio/adc/hi8435.txt
 create mode 100644 drivers/iio/adc/hi8435.c
 create mode 100644 drivers/iio/industrialio-triggered-event.c
 create mode 100644 include/linux/iio/triggered_event.h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 1/7] iio: adc: hi8435: Holt HI-8435 threshold detector

[Vladimir Barinov]

Add Holt threshold detector driver for HI-8435 chip

Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
---
Changes in version 2:
- Added file sysfs-bus-iio-adc-hi8435
- Changed naming from discrete ADC to threshold detector
- Replaced swab16p/swab32p with be16_to_cpup/be32_to_cpup
- Made *_show and *_store functions static
- moved out from iio buffers to iio events
- removed hi8436/hi8437 chips from the driver
- moved from debounce_soft_delay/enable to debounce_interval via
  IIO_CHAN_INFO_DEBOUNCE_TIME
- added name extention comparator
- moved threshold/hysteresis setup via generic iio event sysfs
- added software mask/unmask channel events
- added programming sensor outputs while in test mode via
  IIO_CHAN_INFO_RAW
- added channels .ext_info for programming sensing mode
Changes in version 3:
- fixed typos
- moved linux/interrupt.h to match alphabetic order
- fixed missed */event/* prefix in the ABI description
- added missed colon in sysfs-bus-iio-adc-hi8435 file after What
- moved in_voltageY_comparator_thresh_either_en and debounce_time
  to sysfs-bus-iio file
- added error checking for hi8435_write[b|w]

 Documentation/ABI/testing/sysfs-bus-iio|   1 +
 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 |  61 ++
 drivers/iio/adc/Kconfig|  11 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/hi8435.c   | 659 +
 5 files changed, 742 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
 create mode 100644 drivers/iio/adc/hi8435.c

diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
b/Documentation/ABI/testing/sysfs-bus-iio
index 70c9b1a..09eac44 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -572,6 +572,7 @@ What:   
/sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_thresh_r
 What:  
/sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_thresh_falling_en
 What:  
/sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_thresh_rising_en
 What:  
/sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_thresh_falling_en
+What:  
/sys/.../iio:deviceX/events/in_voltageY_comparator_thresh_either_en
 What:  /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_rising_en
 What:  /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_falling_en
 What:  /sys/.../iio:deviceX/events/in_voltageY_thresh_rising_en
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 
b/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
new file mode 100644
index 000..c59d81d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
@@ -0,0 +1,61 @@
+What:  /sys/bus/iio/devices/iio:deviceX/in_voltageY_comparator_raw
+Date:  July 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Read value is a voltage threshold measurement from channel Y.
+   Could be either 0 if sensor voltage is lower then low voltage
+   threshold or 1 if sensor voltage is higher then high voltage
+   threshold.
+   Write value is a programmed sensor output while in self test
+   mode. Could be either 0 or 1. The programmed value will be read
+   back if /sys/bus/iio/devices/iio:deviceX/test_enable is set to 
1.
+
+What:  /sys/bus/iio/devices/iio:deviceX/test_enable
+Date:  July 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Enable/disable the HI-8435 self test mode.
+   If enabled the in_voltageY_comparator_raw should be read back
+   accordingly to written value to in_voltageY_comparator_raw.
+
+What:  
/sys/bus/iio/devices/iio:deviceX/in_voltageY_comparator_sensing_mode
+Date:  July 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Program sensor type for threshold detector inputs.
+   Could be either GND-Open or Supply-Open mode. Y is a
+   threshold detector input channel. Channels 0..7, 8..15, 16..23
+   and 24..31 has common sensor types.
+
+What:  
/sys/bus/iio/devices/iio:deviceX/events/in_voltageY_comparator_thresh_falling_value
+Date:  July 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Channel Y low voltage threshold. If sensor input voltage goes 
lower then
+   this value then the threshold falling event is pushed.
+   Depending on in_voltageY_comparator_sensing_mode the low 
voltage threshold
+   is separately set for GND-Open and Supply-Open modes.
+   Channels 0..31 have common low threshold values, but could have 
different
+   sensing_modes

[PATCH v3 4/7] iio: trigger: Add periodic polling to SYSFS trigger

[Vladimir Barinov]

Add periodic polling functionality to SYSFS trigger

Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
---
Changes in version 2:
- initially added
Changes in version 3:
- fixed typos in ABI description

 .../ABI/testing/sysfs-bus-iio-trigger-sysfs| 11 
 drivers/iio/trigger/iio-trig-sysfs.c   | 58 ++
 2 files changed, 69 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs 
b/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs
index 5235e6c..03c18eb 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs
+++ b/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs
@@ -9,3 +9,14 @@ Description:
automated testing or in situations, where other trigger methods
are not applicable. For example no RTC or spare GPIOs.
X is the IIO index of the trigger.
+
+What:  /sys/bus/iio/devices/triggerX/trigger_poll
+KernelVersion: 4.2.0
+Contact:   linux-...@vger.kernel.org
+Description:
+   This file is provided by the iio-trig-sysfs stand-alone trigger
+   driver. Writing this file with positive value (in milliseconds)
+   will start periodic event triggering of the driver, associated
+   with this trigger. Writing this file with 0 will stop periodic
+   triggering.
+   X is the IIO index of the trigger.
diff --git a/drivers/iio/trigger/iio-trig-sysfs.c 
b/drivers/iio/trigger/iio-trig-sysfs.c
index 3dfab2b..ea79311 100644
--- a/drivers/iio/trigger/iio-trig-sysfs.c
+++ b/drivers/iio/trigger/iio-trig-sysfs.c
@@ -18,6 +18,8 @@
 struct iio_sysfs_trig {
struct iio_trigger *trig;
struct irq_work work;
+   struct delayed_work poll_work;
+   unsigned int poll_interval; /* msec */
int id;
struct list_head l;
 };
@@ -110,10 +112,63 @@ static ssize_t iio_sysfs_trigger_poll(struct device *dev,
return count;
 }
 
+static void iio_sysfs_trigger_queue_poll_work(struct iio_sysfs_trig *trig)
+{
+   unsigned long delay;
+
+   delay = msecs_to_jiffies(trig-poll_interval);
+   if (delay = HZ)
+   delay = round_jiffies_relative(delay);
+
+   queue_delayed_work(system_freezable_wq, trig-poll_work, delay);
+}
+
+static void iio_sysfs_trigger_poll_work(struct work_struct *work)
+{
+   struct iio_sysfs_trig *trig = container_of(work, struct iio_sysfs_trig,
+  poll_work.work);
+
+   irq_work_queue(trig-work);
+   iio_sysfs_trigger_queue_poll_work(trig);
+}
+
+static ssize_t iio_sysfs_trigger_get_poll(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct iio_trigger *trig = to_iio_trigger(dev);
+   struct iio_sysfs_trig *sysfs_trig = iio_trigger_get_drvdata(trig);
+
+   return sprintf(buf, %d\n, sysfs_trig-poll_interval);
+}
+
+static ssize_t iio_sysfs_trigger_set_poll(struct device *dev,
+   struct device_attribute *attr, const char *buf, size_t count)
+{
+   struct iio_trigger *trig = to_iio_trigger(dev);
+   struct iio_sysfs_trig *sysfs_trig = iio_trigger_get_drvdata(trig);
+   unsigned int interval;
+   int err;
+
+   err = kstrtouint(buf, 0, interval);
+   if (err)
+   return err;
+
+   sysfs_trig-poll_interval = interval;
+
+   cancel_delayed_work_sync(sysfs_trig-poll_work);
+   if (sysfs_trig-poll_interval  0)
+   iio_sysfs_trigger_queue_poll_work(sysfs_trig);
+
+   return count;
+}
+
 static DEVICE_ATTR(trigger_now, S_IWUSR, NULL, iio_sysfs_trigger_poll);
+static DEVICE_ATTR(trigger_poll, S_IRUGO | S_IWUSR, iio_sysfs_trigger_get_poll,
+   iio_sysfs_trigger_set_poll);
 
 static struct attribute *iio_sysfs_trigger_attrs[] = {
dev_attr_trigger_now.attr,
+   dev_attr_trigger_poll.attr,
NULL,
 };
 
@@ -164,6 +219,7 @@ static int iio_sysfs_trigger_probe(int id)
iio_trigger_set_drvdata(t-trig, t);
 
init_irq_work(t-work, iio_sysfs_trigger_work);
+   INIT_DELAYED_WORK(t-poll_work, iio_sysfs_trigger_poll_work);
 
ret = iio_trigger_register(t-trig);
if (ret)
@@ -198,6 +254,8 @@ static int iio_sysfs_trigger_remove(int id)
return -EINVAL;
}
 
+   cancel_delayed_work_sync(t-poll_work);
+
iio_trigger_unregister(t-trig);
iio_trigger_free(t-trig);
 
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 5/7] iio: Support triggered events

[Vladimir Barinov]

Support triggered events.

This is useful for chips that don't have their own interrupt sources.
It allows to use generic/standalone iio triggers for those drivers.

Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
---
Changes in version 2:
- initially added
Changes in version 3:
- fixed grammar in patch description
- changed license header to match GNU Public License v2 or later

 drivers/iio/Kconfig|  6 +++
 drivers/iio/Makefile   |  1 +
 drivers/iio/industrialio-core.c|  4 +-
 drivers/iio/industrialio-trigger.c | 12 +-
 drivers/iio/industrialio-triggered-event.c | 68 ++
 include/linux/iio/iio.h|  1 +
 include/linux/iio/triggered_event.h| 11 +
 7 files changed, 99 insertions(+), 4 deletions(-)
 create mode 100644 drivers/iio/industrialio-triggered-event.c
 create mode 100644 include/linux/iio/triggered_event.h

diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 4011eff..8fcc92f 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -58,6 +58,12 @@ config IIO_CONSUMERS_PER_TRIGGER
This value controls the maximum number of consumers that a
given trigger may handle. Default is 2.
 
+config IIO_TRIGGERED_EVENT
+   tristate
+   select IIO_TRIGGER
+   help
+ Provides helper functions for setting up triggered events.
+
 source drivers/iio/accel/Kconfig
 source drivers/iio/adc/Kconfig
 source drivers/iio/amplifiers/Kconfig
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 698afc2..40dc13e 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -9,6 +9,7 @@ industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
 industrialio-$(CONFIG_IIO_BUFFER_CB) += buffer_cb.o
 
 obj-$(CONFIG_IIO_TRIGGERED_BUFFER) += industrialio-triggered-buffer.o
+obj-$(CONFIG_IIO_TRIGGERED_EVENT) += industrialio-triggered-event.o
 obj-$(CONFIG_IIO_KFIFO_BUF) += kfifo_buf.o
 
 obj-y += accel/
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 3524b0d..54d71ea 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -948,7 +948,7 @@ static void iio_device_unregister_sysfs(struct iio_dev 
*indio_dev)
 static void iio_dev_release(struct device *device)
 {
struct iio_dev *indio_dev = dev_to_iio_dev(device);
-   if (indio_dev-modes  INDIO_BUFFER_TRIGGERED)
+   if (indio_dev-modes  (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
iio_device_unregister_trigger_consumer(indio_dev);
iio_device_unregister_eventset(indio_dev);
iio_device_unregister_sysfs(indio_dev);
@@ -1218,7 +1218,7 @@ int iio_device_register(struct iio_dev *indio_dev)
Failed to register event set\n);
goto error_free_sysfs;
}
-   if (indio_dev-modes  INDIO_BUFFER_TRIGGERED)
+   if (indio_dev-modes  (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
iio_device_register_trigger_consumer(indio_dev);
 
if ((indio_dev-modes  INDIO_ALL_BUFFER_MODES) 
diff --git a/drivers/iio/industrialio-trigger.c 
b/drivers/iio/industrialio-trigger.c
index d31098e..72b63e7 100644
--- a/drivers/iio/industrialio-trigger.c
+++ b/drivers/iio/industrialio-trigger.c
@@ -345,10 +345,18 @@ static ssize_t iio_trigger_write_current(struct device 
*dev,
 
indio_dev-trig = trig;
 
-   if (oldtrig)
+   if (oldtrig) {
+   if (indio_dev-currentmode == INDIO_EVENT_TRIGGERED)
+   iio_trigger_detach_poll_func(oldtrig,
+indio_dev-pollfunc);
iio_trigger_put(oldtrig);
-   if (indio_dev-trig)
+   }
+   if (indio_dev-trig) {
iio_trigger_get(indio_dev-trig);
+   if (indio_dev-currentmode == INDIO_EVENT_TRIGGERED)
+   iio_trigger_attach_poll_func(indio_dev-trig,
+indio_dev-pollfunc);
+   }
 
return len;
 }
diff --git a/drivers/iio/industrialio-triggered-event.c 
b/drivers/iio/industrialio-triggered-event.c
new file mode 100644
index 000..1e5ad33
--- /dev/null
+++ b/drivers/iio/industrialio-triggered-event.c
@@ -0,0 +1,68 @@
+ /*
+ * Copyright (C) 2015 Cogent Embedded, Inc.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include linux/kernel.h
+#include linux/export.h
+#include linux/module.h
+#include linux/iio/iio.h
+#include linux/iio/triggered_event.h
+#include linux/iio/trigger_consumer.h
+
+/**
+ * iio_triggered_event_setup() - Setup pollfunc for triggered event
+ * @indio_dev: IIO device structure
+ * @pollfunc_bh:   Function which

[PATCH v3 3/7] dt: Document Holt HI-8435 bindings

[Vladimir Barinov]

These bindings can be used to register Holt HI-8435 threshold detector

Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
---
Changes in version 2:
- renamed file name hi-843x.txt to hi8435.txt
- removed hi-8436,hi-8436,hi-8437
- removed holt,debounce-soft field
- renamed holt,debounc-soft-delay to holt,debounce-interval
- renamed mr-gpio to reset-gpios
Changes in version 3:
- none

 .../devicetree/bindings/iio/adc/hi8435.txt | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/hi8435.txt

diff --git a/Documentation/devicetree/bindings/iio/adc/hi8435.txt 
b/Documentation/devicetree/bindings/iio/adc/hi8435.txt
new file mode 100644
index 000..1d33ad0
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/hi8435.txt
@@ -0,0 +1,25 @@
+Holt Integrated Circuits HI-8435 threshold detector bindings
+
+Required properties:
+ - compatible: should be holt,hi8435
+ - reg: spi chip select number for the device
+
+Recommended properties:
+ - spi-max-frequency: definition as per
+   Documentation/devicetree/bindings/spi/spi-bus.txt
+
+Optional properties:
+ - holt,reset-gpios: GPIO used for controlling the reset pin
+ - holt,debounce-interval: software debounce interval in milliseconds
+
+Example:
+sensor@0 {
+   compatible = holt,hi8435;
+   reg = 0;
+
+   holt,reset-gpios = gpio6 1 0;
+
+   holt,debounce-interval = 100;
+
+   spi-max-frequency = 100;
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 6/7] iio: Add ABI documentation for debounce_time

[Vladimir Barinov]

Add ABI documentation for debounce_time

Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
---
Changes in version 3:
- initially added

 Documentation/ABI/testing/sysfs-bus-iio | 9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
b/Documentation/ABI/testing/sysfs-bus-iio
index 09eac44..65bf49e 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -539,6 +539,15 @@ Description:
specified and unique if the output corresponds to a single
channel.
 
+What:  /sys/bus/iio/devices/iio:deviceX/debounce_time
+Date:  July 2015
+KernelVersion: 4.2.0
+Contact:   linux-...@vger.kernel.org
+Description:
+   Specifies number of milliseconds in which we perform hardware or
+   software debouncing. If value is set to 0 then debouncing is
+   disabled.
+
 What:  /sys/bus/iio/devices/iio:deviceX/events
 KernelVersion: 2.6.35
 Contact:   linux-...@vger.kernel.org
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 2/7] dt: Add vendor prefix 'holt'

[Vladimir Barinov]

Add Holt Integrated Circuits, Inc. to the list of device tree vendor
prefixes

Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
---
Changes in version 2:
- none
Changes in version 3:
- none

 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index d444757..bc64cc9 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -99,6 +99,7 @@ himax Himax Technologies, Inc.
 hisilicon  Hisilicon Limited.
 hitHitachi Ltd.
 hitex  Hitex Development Tools
+holt   Holt Integrated Circuits, Inc.
 honeywell  Honeywell
 hp Hewlett Packard
 i2se   I2SE GmbH
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 0/7] iio: adc: hi8435: Add Holt HI-8435 threshold detector

[Vladimir Barinov]

Hello,

This adds the folowing:
- Holt threshold detector driver for HI-8435 chip
- Add Holt vendor prefix
- Document HI-8435 DT bindings
- Add periodic polling functionality to SYSFS trigger
- Support triggered events
- Add ABI documentation for debounce_time
- Fix typos in sysfs-bus-iio file

PDF file can be found here:
http://www.holtic.com/products/3081-hi-8435.aspx

Vladimir Barinov (7):
[1/7] iio: adc: hi8435: Holt HI-8435 threshold detector
[2/7] dt: Add vendor prefix 'holt'
[3/7] dt: Document Holt HI-8435 bindings
[4/7] iio: trigger: Add periodic polling to SYSFS trigger
[5/7] iio: Support triggered events
[6/7] iio: Add ABI documentation for debounce_time
[7/7] iio: Fix typos in ABI documentation

---
This patchset is against the 'kernel/git/torvalds/linux.git' repo.

 Documentation/ABI/testing/sysfs-bus-iio   |   16 
 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435|   61 +
 Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs |   11 
 Documentation/devicetree/bindings/iio/adc/hi8435.txt  |   25 
 Documentation/devicetree/bindings/vendor-prefixes.txt |1 
 drivers/iio/Kconfig   |6 
 drivers/iio/Makefile  |1 
 drivers/iio/adc/Kconfig   |   11 
 drivers/iio/adc/Makefile  |1 
 drivers/iio/adc/hi8435.c  |  659 ++
 drivers/iio/industrialio-core.c   |4 
 drivers/iio/industrialio-trigger.c|   12 
 drivers/iio/industrialio-triggered-event.c|   68 +
 drivers/iio/trigger/iio-trig-sysfs.c  |   58 +
 include/linux/iio/iio.h   |1 
 include/linux/iio/triggered_event.h   |   11 
 16 files changed, 939 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
 create mode 100644 Documentation/devicetree/bindings/iio/adc/hi8435.txt
 create mode 100644 drivers/iio/adc/hi8435.c
 create mode 100644 drivers/iio/industrialio-triggered-event.c
 create mode 100644 include/linux/iio/triggered_event.h
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 7/7] iio: Fix typos in ABI documentation

[Vladimir Barinov]

Fix typos in ABI documentation

Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
---
Changes in version 3:
- initially added

 Documentation/ABI/testing/sysfs-bus-iio | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
b/Documentation/ABI/testing/sysfs-bus-iio
index 65bf49e..71a48b7 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -488,7 +488,7 @@ Contact:linux-...@vger.kernel.org
 Description:
Specifies the output powerdown mode.
DAC output stage is disconnected from the amplifier and
-   1kohm_to_gnd: connected to ground via an 1kOhm resistor,
+   1kohm_to_gnd: connected to ground via an 1kOhm resistor,
6kohm_to_gnd: connected to ground via a 6kOhm resistor,
20kohm_to_gnd: connected to ground via a 20kOhm resistor,
100kohm_to_gnd: connected to ground via an 100kOhm resistor,
@@ -498,9 +498,9 @@ Description:
outX_powerdown_mode_available. If Y is not present the
mode is shared across all outputs.
 
-What:  /sys/.../iio:deviceX/out_votlageY_powerdown_mode_available
+What:  /sys/.../iio:deviceX/out_voltageY_powerdown_mode_available
 What:  /sys/.../iio:deviceX/out_voltage_powerdown_mode_available
-What:  /sys/.../iio:deviceX/out_altvotlageY_powerdown_mode_available
+What:  /sys/.../iio:deviceX/out_altvoltageY_powerdown_mode_available
 What:  /sys/.../iio:deviceX/out_altvoltage_powerdown_mode_available
 KernelVersion: 2.6.38
 Contact:   linux-...@vger.kernel.org
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 5/5] iio: Support triggered events

[Vladimir Barinov]

Support triggered events.

This is useful for chips that has no it's own interrupt sources.
It allows to use generic/standalone iio triggeres for those drivers.

Signed-off-by: Vladimir Barinov 
---
Changes in version 2:
- initially added

 drivers/iio/Kconfig|  6 +++
 drivers/iio/Makefile   |  1 +
 drivers/iio/industrialio-core.c|  4 +-
 drivers/iio/industrialio-trigger.c | 12 +-
 drivers/iio/industrialio-triggered-event.c | 67 ++
 include/linux/iio/iio.h|  1 +
 include/linux/iio/triggered_event.h| 11 +
 7 files changed, 98 insertions(+), 4 deletions(-)
 create mode 100644 drivers/iio/industrialio-triggered-event.c
 create mode 100644 include/linux/iio/triggered_event.h

diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 4011eff..8fcc92f 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -58,6 +58,12 @@ config IIO_CONSUMERS_PER_TRIGGER
This value controls the maximum number of consumers that a
given trigger may handle. Default is 2.
 
+config IIO_TRIGGERED_EVENT
+   tristate
+   select IIO_TRIGGER
+   help
+ Provides helper functions for setting up triggered events.
+
 source "drivers/iio/accel/Kconfig"
 source "drivers/iio/adc/Kconfig"
 source "drivers/iio/amplifiers/Kconfig"
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 698afc2..40dc13e 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -9,6 +9,7 @@ industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
 industrialio-$(CONFIG_IIO_BUFFER_CB) += buffer_cb.o
 
 obj-$(CONFIG_IIO_TRIGGERED_BUFFER) += industrialio-triggered-buffer.o
+obj-$(CONFIG_IIO_TRIGGERED_EVENT) += industrialio-triggered-event.o
 obj-$(CONFIG_IIO_KFIFO_BUF) += kfifo_buf.o
 
 obj-y += accel/
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 3524b0d..54d71ea 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -948,7 +948,7 @@ static void iio_device_unregister_sysfs(struct iio_dev 
*indio_dev)
 static void iio_dev_release(struct device *device)
 {
struct iio_dev *indio_dev = dev_to_iio_dev(device);
-   if (indio_dev->modes & INDIO_BUFFER_TRIGGERED)
+   if (indio_dev->modes & (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
iio_device_unregister_trigger_consumer(indio_dev);
iio_device_unregister_eventset(indio_dev);
iio_device_unregister_sysfs(indio_dev);
@@ -1218,7 +1218,7 @@ int iio_device_register(struct iio_dev *indio_dev)
"Failed to register event set\n");
goto error_free_sysfs;
}
-   if (indio_dev->modes & INDIO_BUFFER_TRIGGERED)
+   if (indio_dev->modes & (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
iio_device_register_trigger_consumer(indio_dev);
 
if ((indio_dev->modes & INDIO_ALL_BUFFER_MODES) &&
diff --git a/drivers/iio/industrialio-trigger.c 
b/drivers/iio/industrialio-trigger.c
index d31098e..72b63e7 100644
--- a/drivers/iio/industrialio-trigger.c
+++ b/drivers/iio/industrialio-trigger.c
@@ -345,10 +345,18 @@ static ssize_t iio_trigger_write_current(struct device 
*dev,
 
indio_dev->trig = trig;
 
-   if (oldtrig)
+   if (oldtrig) {
+   if (indio_dev->currentmode == INDIO_EVENT_TRIGGERED)
+   iio_trigger_detach_poll_func(oldtrig,
+indio_dev->pollfunc);
iio_trigger_put(oldtrig);
-   if (indio_dev->trig)
+   }
+   if (indio_dev->trig) {
iio_trigger_get(indio_dev->trig);
+   if (indio_dev->currentmode == INDIO_EVENT_TRIGGERED)
+   iio_trigger_attach_poll_func(indio_dev->trig,
+indio_dev->pollfunc);
+   }
 
return len;
 }
diff --git a/drivers/iio/industrialio-triggered-event.c 
b/drivers/iio/industrialio-triggered-event.c
new file mode 100644
index 000..c434ce7
--- /dev/null
+++ b/drivers/iio/industrialio-triggered-event.c
@@ -0,0 +1,67 @@
+ /*
+ * Copyright (C) 2015 Cogent Embedded, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * iio_triggered_event_setup() - Setup pollfunc for triggered event
+ * @indio_dev: IIO device structure
+ * @pollfunc_bh:   Function which will be used as pollfunc bottom half
+ * @pollfunc_th:   Function which will be used as pollfunc top half
+ *
+ * This function combines some common tasks which will normally be performed
+ * when setting up a

[PATCH v2 1/5] iio: adc: hi8435: Holt HI-8435 threshold detector

[Vladimir Barinov]

Add Holt threshold detector driver for HI-8435 chip

Signed-off-by: Vladimir Barinov 
---
Changes in version 2:
- Added file sysfs-bus-iio-adc-hi8435
- Changed naming from "discrete ADC" to "threshold detector"
- Replaced swab16p/swab32p with be16_to_cpup/be32_to_cpup
- Made *_show and *_store functions static
- moved out from iio buffers to iio events
- removed hi8436/hi8437 chips from the driver
- moved from debounce_soft_delay/enable to debounce_interval via
  IIO_CHAN_INFO_DEBOUNCE_TIME
- added name extention "comparator"
- moved threshold/hysteresis setup via generic iio event sysfs
- added software mask/unmask channel events
- added programming sensor outputs while in test mode via
  IIO_CHAN_INFO_RAW
- added channels .ext_info for programming sensing mode

 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 |  76 +++
 drivers/iio/adc/Kconfig|  11 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/hi8435.c   | 659 +
 4 files changed, 747 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
 create mode 100644 drivers/iio/adc/hi8435.c

diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 
b/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
new file mode 100644
index 000..2ff5bb3
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
@@ -0,0 +1,76 @@
+What   /sys/bus/iio/devices/iio:deviceX/in_voltageY_comparator_raw
+Date:  July 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Read value is a voltage threshold measurement from channel Y.
+   Could be ether 0 if sensor voltage lower then low voltage
+   threshold or 1 if sensor votlage higher then high voltage
+   threshold.
+   Write value is a programmed sensor output while in self test
+   mode. Could be ether 0 or 1. The programmed value will be read
+   back if /sys/bus/iio/devices/iio:deviceX/test_enable is set to 1
+
+What   /sys/bus/iio/devices/iio:deviceX/test_enable
+Date:  July 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Enable/disable the HI-8435 self test mode.
+   If enabled the in_voltageY_comparator_raw should be read back
+   accordingly to written value to in_voltageY_comparator_raw
+
+What   /sys/bus/iio/devices/iio:deviceX/debounce_time
+Date:  July 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Software debounce interval in millliseconds. If value is
+   set to 0 then debouncing is disabled
+
+What   
/sys/bus/iio/devices/iio:deviceX/in_voltageY_comparator_sensing_mode
+Date:  July 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Program sensor type for threshold detector inputs.
+   Could be ether "GND-Open" or "Supply-Open" modes. Y is a
+   threshold detector input channel. Channels 0..7, 8..15, 16..23
+   and 24..31 has common sensor types.
+
+What   
/sys/bus/iio/devices/iio:deviceX/events/in_voltageY_comparator_thresh_either_en
+Date:  July 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Mask/unmask channel Y events
+
+What   
/sys/bus/iio/devices/iio:deviceX/in_voltageY_comparator_thresh_falling_value
+Date:  July 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Cahnnel Y low voltage threshold. If sensor input voltage goes 
lower then
+   this value then the threshold falling event is pushed.
+   Depending on in_voltageY_comparator_sensing_mode the low 
voltage threshold
+   is separately set for "GND-Open" and "Supply-Open" modes.
+   Channels 0..31 has common low threshold values, but could have 
different
+   sensing_modes.
+   The low voltage threshold range is between 2..21V.
+   Hysteresis between low and high thresholds can not be lower 
then 2 and
+   can not be odd.
+
+What   
/sys/bus/iio/devices/iio:deviceX/in_voltageY_comparator_thresh_rising_value
+Date:  July 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Cahnnel Y high voltage threshold. If sensor input voltage goes 
higher then
+   this value then the threshold rising event is pushed.
+   Depending on in_voltageY_comparator_sensing_mode the high 
voltage threshold
+   is separately set for "GND-Open" and "Supply-Open" modes.
+   Channels 0..31

[PATCH v2 4/5] iio: trigger: Add periodic polling to SYSFS trigger

[Vladimir Barinov]

Add periodic polling functionality to SYSFS trigger

Signed-off-by: Vladimir Barinov 
---
Changes in version 2:
- initially added

 .../ABI/testing/sysfs-bus-iio-trigger-sysfs| 11 
 drivers/iio/trigger/iio-trig-sysfs.c   | 58 ++
 2 files changed, 69 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs 
b/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs
index 5235e6c..49caff2 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs
+++ b/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs
@@ -9,3 +9,14 @@ Description:
automated testing or in situations, where other trigger methods
are not applicable. For example no RTC or spare GPIOs.
X is the IIO index of the trigger.
+
+What:  /sys/bus/iio/devices/triggerX/trigger_poll
+KernelVersion: 4.2.0
+Contact:   linux-...@vger.kernel.org
+Description:
+   This file is provided by the iio-trig-sysfs stand-alone trigger
+   driver. Writing this file with positive value (in milliseconds)
+   will start peroidic event triggereing of the driver, associated
+   with this trigger. Writing this file with 0 will stop perioding
+   triggering.
+   X is the IIO index of the trigger.
diff --git a/drivers/iio/trigger/iio-trig-sysfs.c 
b/drivers/iio/trigger/iio-trig-sysfs.c
index 3dfab2b..ea79311 100644
--- a/drivers/iio/trigger/iio-trig-sysfs.c
+++ b/drivers/iio/trigger/iio-trig-sysfs.c
@@ -18,6 +18,8 @@
 struct iio_sysfs_trig {
struct iio_trigger *trig;
struct irq_work work;
+   struct delayed_work poll_work;
+   unsigned int poll_interval; /* msec */
int id;
struct list_head l;
 };
@@ -110,10 +112,63 @@ static ssize_t iio_sysfs_trigger_poll(struct device *dev,
return count;
 }
 
+static void iio_sysfs_trigger_queue_poll_work(struct iio_sysfs_trig *trig)
+{
+   unsigned long delay;
+
+   delay = msecs_to_jiffies(trig->poll_interval);
+   if (delay >= HZ)
+   delay = round_jiffies_relative(delay);
+
+   queue_delayed_work(system_freezable_wq, >poll_work, delay);
+}
+
+static void iio_sysfs_trigger_poll_work(struct work_struct *work)
+{
+   struct iio_sysfs_trig *trig = container_of(work, struct iio_sysfs_trig,
+  poll_work.work);
+
+   irq_work_queue(>work);
+   iio_sysfs_trigger_queue_poll_work(trig);
+}
+
+static ssize_t iio_sysfs_trigger_get_poll(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct iio_trigger *trig = to_iio_trigger(dev);
+   struct iio_sysfs_trig *sysfs_trig = iio_trigger_get_drvdata(trig);
+
+   return sprintf(buf, "%d\n", sysfs_trig->poll_interval);
+}
+
+static ssize_t iio_sysfs_trigger_set_poll(struct device *dev,
+   struct device_attribute *attr, const char *buf, size_t count)
+{
+   struct iio_trigger *trig = to_iio_trigger(dev);
+   struct iio_sysfs_trig *sysfs_trig = iio_trigger_get_drvdata(trig);
+   unsigned int interval;
+   int err;
+
+   err = kstrtouint(buf, 0, );
+   if (err)
+   return err;
+
+   sysfs_trig->poll_interval = interval;
+
+   cancel_delayed_work_sync(_trig->poll_work);
+   if (sysfs_trig->poll_interval > 0)
+   iio_sysfs_trigger_queue_poll_work(sysfs_trig);
+
+   return count;
+}
+
 static DEVICE_ATTR(trigger_now, S_IWUSR, NULL, iio_sysfs_trigger_poll);
+static DEVICE_ATTR(trigger_poll, S_IRUGO | S_IWUSR, iio_sysfs_trigger_get_poll,
+   iio_sysfs_trigger_set_poll);
 
 static struct attribute *iio_sysfs_trigger_attrs[] = {
_attr_trigger_now.attr,
+   _attr_trigger_poll.attr,
NULL,
 };
 
@@ -164,6 +219,7 @@ static int iio_sysfs_trigger_probe(int id)
iio_trigger_set_drvdata(t->trig, t);
 
init_irq_work(>work, iio_sysfs_trigger_work);
+   INIT_DELAYED_WORK(>poll_work, iio_sysfs_trigger_poll_work);
 
ret = iio_trigger_register(t->trig);
if (ret)
@@ -198,6 +254,8 @@ static int iio_sysfs_trigger_remove(int id)
return -EINVAL;
}
 
+   cancel_delayed_work_sync(>poll_work);
+
iio_trigger_unregister(t->trig);
iio_trigger_free(t->trig);
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/5] dt: Add vendor prefix 'holt'

[Vladimir Barinov]

Add Holt Integrated Circuits, Inc. to the list of device tree vendor
prefixes

Signed-off-by: Vladimir Barinov 
---
Changes in version 2:
- none

 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index d444757..bc64cc9 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -99,6 +99,7 @@ himax Himax Technologies, Inc.
 hisilicon  Hisilicon Limited.
 hitHitachi Ltd.
 hitex  Hitex Development Tools
+holt   Holt Integrated Circuits, Inc.
 honeywell  Honeywell
 hp Hewlett Packard
 i2se   I2SE GmbH
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 3/5] dt: Document Holt HI-8435 bindings

[Vladimir Barinov]

These bindings can be used to register Holt HI-8435 threshold detector

Signed-off-by: Vladimir Barinov 
---
Changes in version 2:
- renamed file name hi-843x.txt to hi8435.txt
- removed hi-8436,hi-8436,hi-8437
- removed holt,debounce-soft field
- renamed holt,debounc-soft-delay to holt,debounce-interval
- renamed mr-gpio to reset-gpios

 .../devicetree/bindings/iio/adc/hi8435.txt | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/hi8435.txt

diff --git a/Documentation/devicetree/bindings/iio/adc/hi8435.txt 
b/Documentation/devicetree/bindings/iio/adc/hi8435.txt
new file mode 100644
index 000..1d33ad0
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/hi8435.txt
@@ -0,0 +1,25 @@
+Holt Integrated Circuits HI-8435 threshold detector bindings
+
+Required properties:
+ - compatible: should be "holt,hi8435"
+ - reg: spi chip select number for the device
+
+Recommended properties:
+ - spi-max-frequency: definition as per
+   Documentation/devicetree/bindings/spi/spi-bus.txt
+
+Optional properties:
+ - holt,reset-gpios: GPIO used for controlling the reset pin
+ - holt,debounce-interval: software debounce interval in milliseconds
+
+Example:
+sensor@0 {
+   compatible = "holt,hi8435";
+   reg = <0>;
+
+   holt,reset-gpios = < 1 0>;
+
+   holt,debounce-interval = <100>;
+
+   spi-max-frequency = <100>;
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 0/5] iio: adc: hi8435: Add Holt HI-8435 threshold detector

[Vladimir Barinov]

Hello,

This adds the folowing:
- Holt threshold detector driver for HI-8435 chip
- Add Holt vendor prefix
- Document HI-8435 DT bindings
- Add periodic polling functionality to SYSFS trigger
- Support triggered events

PDF file can be found here:
http://www.holtic.com/products/3081-hi-8435.aspx

Vladimir Barinov (3):
[1/5] iio: adc: hi8435: Holt HI-8435 threshold detector
[2/5] dt: Add vendor prefix 'holt'
[3/5] dt: Document Holt HI-8435 bindings
[4/5] iio: trigger: Add periodic polling to SYSFS trigger
[5/5] iio: Support triggered events

---
This patchset is against the 'kernel/git/torvalds/linux.git' repo.

 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435|   76 ++
 Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs |   11 
 Documentation/devicetree/bindings/iio/adc/hi8435.txt  |   25 
 Documentation/devicetree/bindings/vendor-prefixes.txt |1 
 drivers/iio/Kconfig   |6 
 drivers/iio/Makefile  |1 
 drivers/iio/adc/Kconfig   |   11 
 drivers/iio/adc/Makefile  |1 
 drivers/iio/adc/hi8435.c  |  659 ++
 drivers/iio/industrialio-core.c   |4 
 drivers/iio/industrialio-trigger.c|   12 
 drivers/iio/industrialio-triggered-event.c|   67 +
 drivers/iio/trigger/iio-trig-sysfs.c  |   58 +
 include/linux/iio/iio.h   |1 
 include/linux/iio/triggered_event.h   |   11 
 15 files changed, 940 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
 create mode 100644 drivers/iio/adc/hi8435.c
 create mode 100644 Documentation/devicetree/bindings/iio/adc/hi8435.txt
 create mode 100644 drivers/iio/industrialio-triggered-event.c
 create mode 100644 include/linux/iio/triggered_event.h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/5] iio: adc: hi8435: Holt HI-8435 threshold detector

[Vladimir Barinov]

Add Holt threshold detector driver for HI-8435 chip

Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
---
Changes in version 2:
- Added file sysfs-bus-iio-adc-hi8435
- Changed naming from discrete ADC to threshold detector
- Replaced swab16p/swab32p with be16_to_cpup/be32_to_cpup
- Made *_show and *_store functions static
- moved out from iio buffers to iio events
- removed hi8436/hi8437 chips from the driver
- moved from debounce_soft_delay/enable to debounce_interval via
  IIO_CHAN_INFO_DEBOUNCE_TIME
- added name extention comparator
- moved threshold/hysteresis setup via generic iio event sysfs
- added software mask/unmask channel events
- added programming sensor outputs while in test mode via
  IIO_CHAN_INFO_RAW
- added channels .ext_info for programming sensing mode

 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 |  76 +++
 drivers/iio/adc/Kconfig|  11 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/hi8435.c   | 659 +
 4 files changed, 747 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
 create mode 100644 drivers/iio/adc/hi8435.c

diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 
b/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
new file mode 100644
index 000..2ff5bb3
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
@@ -0,0 +1,76 @@
+What   /sys/bus/iio/devices/iio:deviceX/in_voltageY_comparator_raw
+Date:  July 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Read value is a voltage threshold measurement from channel Y.
+   Could be ether 0 if sensor voltage lower then low voltage
+   threshold or 1 if sensor votlage higher then high voltage
+   threshold.
+   Write value is a programmed sensor output while in self test
+   mode. Could be ether 0 or 1. The programmed value will be read
+   back if /sys/bus/iio/devices/iio:deviceX/test_enable is set to 1
+
+What   /sys/bus/iio/devices/iio:deviceX/test_enable
+Date:  July 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Enable/disable the HI-8435 self test mode.
+   If enabled the in_voltageY_comparator_raw should be read back
+   accordingly to written value to in_voltageY_comparator_raw
+
+What   /sys/bus/iio/devices/iio:deviceX/debounce_time
+Date:  July 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Software debounce interval in millliseconds. If value is
+   set to 0 then debouncing is disabled
+
+What   
/sys/bus/iio/devices/iio:deviceX/in_voltageY_comparator_sensing_mode
+Date:  July 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Program sensor type for threshold detector inputs.
+   Could be ether GND-Open or Supply-Open modes. Y is a
+   threshold detector input channel. Channels 0..7, 8..15, 16..23
+   and 24..31 has common sensor types.
+
+What   
/sys/bus/iio/devices/iio:deviceX/events/in_voltageY_comparator_thresh_either_en
+Date:  July 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Mask/unmask channel Y events
+
+What   
/sys/bus/iio/devices/iio:deviceX/in_voltageY_comparator_thresh_falling_value
+Date:  July 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Cahnnel Y low voltage threshold. If sensor input voltage goes 
lower then
+   this value then the threshold falling event is pushed.
+   Depending on in_voltageY_comparator_sensing_mode the low 
voltage threshold
+   is separately set for GND-Open and Supply-Open modes.
+   Channels 0..31 has common low threshold values, but could have 
different
+   sensing_modes.
+   The low voltage threshold range is between 2..21V.
+   Hysteresis between low and high thresholds can not be lower 
then 2 and
+   can not be odd.
+
+What   
/sys/bus/iio/devices/iio:deviceX/in_voltageY_comparator_thresh_rising_value
+Date:  July 2015
+KernelVersion: 4.2.0
+Contact:   sou...@cogentembedded.com
+Description:
+   Cahnnel Y high voltage threshold. If sensor input voltage goes 
higher then
+   this value then the threshold rising event is pushed.
+   Depending on in_voltageY_comparator_sensing_mode the high 
voltage threshold
+   is separately set for GND-Open and Supply-Open modes.
+   Channels 0..31 has common high threshold values, but could have 
different
+   sensing_modes

[PATCH v2 5/5] iio: Support triggered events

[Vladimir Barinov]

Support triggered events.

This is useful for chips that has no it's own interrupt sources.
It allows to use generic/standalone iio triggeres for those drivers.

Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
---
Changes in version 2:
- initially added

 drivers/iio/Kconfig|  6 +++
 drivers/iio/Makefile   |  1 +
 drivers/iio/industrialio-core.c|  4 +-
 drivers/iio/industrialio-trigger.c | 12 +-
 drivers/iio/industrialio-triggered-event.c | 67 ++
 include/linux/iio/iio.h|  1 +
 include/linux/iio/triggered_event.h| 11 +
 7 files changed, 98 insertions(+), 4 deletions(-)
 create mode 100644 drivers/iio/industrialio-triggered-event.c
 create mode 100644 include/linux/iio/triggered_event.h

diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 4011eff..8fcc92f 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -58,6 +58,12 @@ config IIO_CONSUMERS_PER_TRIGGER
This value controls the maximum number of consumers that a
given trigger may handle. Default is 2.
 
+config IIO_TRIGGERED_EVENT
+   tristate
+   select IIO_TRIGGER
+   help
+ Provides helper functions for setting up triggered events.
+
 source drivers/iio/accel/Kconfig
 source drivers/iio/adc/Kconfig
 source drivers/iio/amplifiers/Kconfig
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 698afc2..40dc13e 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -9,6 +9,7 @@ industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
 industrialio-$(CONFIG_IIO_BUFFER_CB) += buffer_cb.o
 
 obj-$(CONFIG_IIO_TRIGGERED_BUFFER) += industrialio-triggered-buffer.o
+obj-$(CONFIG_IIO_TRIGGERED_EVENT) += industrialio-triggered-event.o
 obj-$(CONFIG_IIO_KFIFO_BUF) += kfifo_buf.o
 
 obj-y += accel/
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 3524b0d..54d71ea 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -948,7 +948,7 @@ static void iio_device_unregister_sysfs(struct iio_dev 
*indio_dev)
 static void iio_dev_release(struct device *device)
 {
struct iio_dev *indio_dev = dev_to_iio_dev(device);
-   if (indio_dev-modes  INDIO_BUFFER_TRIGGERED)
+   if (indio_dev-modes  (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
iio_device_unregister_trigger_consumer(indio_dev);
iio_device_unregister_eventset(indio_dev);
iio_device_unregister_sysfs(indio_dev);
@@ -1218,7 +1218,7 @@ int iio_device_register(struct iio_dev *indio_dev)
Failed to register event set\n);
goto error_free_sysfs;
}
-   if (indio_dev-modes  INDIO_BUFFER_TRIGGERED)
+   if (indio_dev-modes  (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
iio_device_register_trigger_consumer(indio_dev);
 
if ((indio_dev-modes  INDIO_ALL_BUFFER_MODES) 
diff --git a/drivers/iio/industrialio-trigger.c 
b/drivers/iio/industrialio-trigger.c
index d31098e..72b63e7 100644
--- a/drivers/iio/industrialio-trigger.c
+++ b/drivers/iio/industrialio-trigger.c
@@ -345,10 +345,18 @@ static ssize_t iio_trigger_write_current(struct device 
*dev,
 
indio_dev-trig = trig;
 
-   if (oldtrig)
+   if (oldtrig) {
+   if (indio_dev-currentmode == INDIO_EVENT_TRIGGERED)
+   iio_trigger_detach_poll_func(oldtrig,
+indio_dev-pollfunc);
iio_trigger_put(oldtrig);
-   if (indio_dev-trig)
+   }
+   if (indio_dev-trig) {
iio_trigger_get(indio_dev-trig);
+   if (indio_dev-currentmode == INDIO_EVENT_TRIGGERED)
+   iio_trigger_attach_poll_func(indio_dev-trig,
+indio_dev-pollfunc);
+   }
 
return len;
 }
diff --git a/drivers/iio/industrialio-triggered-event.c 
b/drivers/iio/industrialio-triggered-event.c
new file mode 100644
index 000..c434ce7
--- /dev/null
+++ b/drivers/iio/industrialio-triggered-event.c
@@ -0,0 +1,67 @@
+ /*
+ * Copyright (C) 2015 Cogent Embedded, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/export.h
+#include linux/module.h
+#include linux/iio/iio.h
+#include linux/iio/triggered_event.h
+#include linux/iio/trigger_consumer.h
+
+/**
+ * iio_triggered_event_setup() - Setup pollfunc for triggered event
+ * @indio_dev: IIO device structure
+ * @pollfunc_bh:   Function which will be used as pollfunc bottom half
+ * @pollfunc_th:   Function which will be used as pollfunc top half
+ *
+ * This function combines some common tasks which will normally be performed
+ * when

[PATCH v2 2/5] dt: Add vendor prefix 'holt'

[Vladimir Barinov]

Add Holt Integrated Circuits, Inc. to the list of device tree vendor
prefixes

Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
---
Changes in version 2:
- none

 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index d444757..bc64cc9 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -99,6 +99,7 @@ himax Himax Technologies, Inc.
 hisilicon  Hisilicon Limited.
 hitHitachi Ltd.
 hitex  Hitex Development Tools
+holt   Holt Integrated Circuits, Inc.
 honeywell  Honeywell
 hp Hewlett Packard
 i2se   I2SE GmbH
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 3/5] dt: Document Holt HI-8435 bindings

[Vladimir Barinov]

These bindings can be used to register Holt HI-8435 threshold detector

Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
---
Changes in version 2:
- renamed file name hi-843x.txt to hi8435.txt
- removed hi-8436,hi-8436,hi-8437
- removed holt,debounce-soft field
- renamed holt,debounc-soft-delay to holt,debounce-interval
- renamed mr-gpio to reset-gpios

 .../devicetree/bindings/iio/adc/hi8435.txt | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/hi8435.txt

diff --git a/Documentation/devicetree/bindings/iio/adc/hi8435.txt 
b/Documentation/devicetree/bindings/iio/adc/hi8435.txt
new file mode 100644
index 000..1d33ad0
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/hi8435.txt
@@ -0,0 +1,25 @@
+Holt Integrated Circuits HI-8435 threshold detector bindings
+
+Required properties:
+ - compatible: should be holt,hi8435
+ - reg: spi chip select number for the device
+
+Recommended properties:
+ - spi-max-frequency: definition as per
+   Documentation/devicetree/bindings/spi/spi-bus.txt
+
+Optional properties:
+ - holt,reset-gpios: GPIO used for controlling the reset pin
+ - holt,debounce-interval: software debounce interval in milliseconds
+
+Example:
+sensor@0 {
+   compatible = holt,hi8435;
+   reg = 0;
+
+   holt,reset-gpios = gpio6 1 0;
+
+   holt,debounce-interval = 100;
+
+   spi-max-frequency = 100;
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 4/5] iio: trigger: Add periodic polling to SYSFS trigger

[Vladimir Barinov]

Add periodic polling functionality to SYSFS trigger

Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
---
Changes in version 2:
- initially added

 .../ABI/testing/sysfs-bus-iio-trigger-sysfs| 11 
 drivers/iio/trigger/iio-trig-sysfs.c   | 58 ++
 2 files changed, 69 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs 
b/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs
index 5235e6c..49caff2 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs
+++ b/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs
@@ -9,3 +9,14 @@ Description:
automated testing or in situations, where other trigger methods
are not applicable. For example no RTC or spare GPIOs.
X is the IIO index of the trigger.
+
+What:  /sys/bus/iio/devices/triggerX/trigger_poll
+KernelVersion: 4.2.0
+Contact:   linux-...@vger.kernel.org
+Description:
+   This file is provided by the iio-trig-sysfs stand-alone trigger
+   driver. Writing this file with positive value (in milliseconds)
+   will start peroidic event triggereing of the driver, associated
+   with this trigger. Writing this file with 0 will stop perioding
+   triggering.
+   X is the IIO index of the trigger.
diff --git a/drivers/iio/trigger/iio-trig-sysfs.c 
b/drivers/iio/trigger/iio-trig-sysfs.c
index 3dfab2b..ea79311 100644
--- a/drivers/iio/trigger/iio-trig-sysfs.c
+++ b/drivers/iio/trigger/iio-trig-sysfs.c
@@ -18,6 +18,8 @@
 struct iio_sysfs_trig {
struct iio_trigger *trig;
struct irq_work work;
+   struct delayed_work poll_work;
+   unsigned int poll_interval; /* msec */
int id;
struct list_head l;
 };
@@ -110,10 +112,63 @@ static ssize_t iio_sysfs_trigger_poll(struct device *dev,
return count;
 }
 
+static void iio_sysfs_trigger_queue_poll_work(struct iio_sysfs_trig *trig)
+{
+   unsigned long delay;
+
+   delay = msecs_to_jiffies(trig-poll_interval);
+   if (delay = HZ)
+   delay = round_jiffies_relative(delay);
+
+   queue_delayed_work(system_freezable_wq, trig-poll_work, delay);
+}
+
+static void iio_sysfs_trigger_poll_work(struct work_struct *work)
+{
+   struct iio_sysfs_trig *trig = container_of(work, struct iio_sysfs_trig,
+  poll_work.work);
+
+   irq_work_queue(trig-work);
+   iio_sysfs_trigger_queue_poll_work(trig);
+}
+
+static ssize_t iio_sysfs_trigger_get_poll(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct iio_trigger *trig = to_iio_trigger(dev);
+   struct iio_sysfs_trig *sysfs_trig = iio_trigger_get_drvdata(trig);
+
+   return sprintf(buf, %d\n, sysfs_trig-poll_interval);
+}
+
+static ssize_t iio_sysfs_trigger_set_poll(struct device *dev,
+   struct device_attribute *attr, const char *buf, size_t count)
+{
+   struct iio_trigger *trig = to_iio_trigger(dev);
+   struct iio_sysfs_trig *sysfs_trig = iio_trigger_get_drvdata(trig);
+   unsigned int interval;
+   int err;
+
+   err = kstrtouint(buf, 0, interval);
+   if (err)
+   return err;
+
+   sysfs_trig-poll_interval = interval;
+
+   cancel_delayed_work_sync(sysfs_trig-poll_work);
+   if (sysfs_trig-poll_interval  0)
+   iio_sysfs_trigger_queue_poll_work(sysfs_trig);
+
+   return count;
+}
+
 static DEVICE_ATTR(trigger_now, S_IWUSR, NULL, iio_sysfs_trigger_poll);
+static DEVICE_ATTR(trigger_poll, S_IRUGO | S_IWUSR, iio_sysfs_trigger_get_poll,
+   iio_sysfs_trigger_set_poll);
 
 static struct attribute *iio_sysfs_trigger_attrs[] = {
dev_attr_trigger_now.attr,
+   dev_attr_trigger_poll.attr,
NULL,
 };
 
@@ -164,6 +219,7 @@ static int iio_sysfs_trigger_probe(int id)
iio_trigger_set_drvdata(t-trig, t);
 
init_irq_work(t-work, iio_sysfs_trigger_work);
+   INIT_DELAYED_WORK(t-poll_work, iio_sysfs_trigger_poll_work);
 
ret = iio_trigger_register(t-trig);
if (ret)
@@ -198,6 +254,8 @@ static int iio_sysfs_trigger_remove(int id)
return -EINVAL;
}
 
+   cancel_delayed_work_sync(t-poll_work);
+
iio_trigger_unregister(t-trig);
iio_trigger_free(t-trig);
 
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 0/5] iio: adc: hi8435: Add Holt HI-8435 threshold detector

[Vladimir Barinov]

Hello,

This adds the folowing:
- Holt threshold detector driver for HI-8435 chip
- Add Holt vendor prefix
- Document HI-8435 DT bindings
- Add periodic polling functionality to SYSFS trigger
- Support triggered events

PDF file can be found here:
http://www.holtic.com/products/3081-hi-8435.aspx

Vladimir Barinov (3):
[1/5] iio: adc: hi8435: Holt HI-8435 threshold detector
[2/5] dt: Add vendor prefix 'holt'
[3/5] dt: Document Holt HI-8435 bindings
[4/5] iio: trigger: Add periodic polling to SYSFS trigger
[5/5] iio: Support triggered events

---
This patchset is against the 'kernel/git/torvalds/linux.git' repo.

 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435|   76 ++
 Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs |   11 
 Documentation/devicetree/bindings/iio/adc/hi8435.txt  |   25 
 Documentation/devicetree/bindings/vendor-prefixes.txt |1 
 drivers/iio/Kconfig   |6 
 drivers/iio/Makefile  |1 
 drivers/iio/adc/Kconfig   |   11 
 drivers/iio/adc/Makefile  |1 
 drivers/iio/adc/hi8435.c  |  659 ++
 drivers/iio/industrialio-core.c   |4 
 drivers/iio/industrialio-trigger.c|   12 
 drivers/iio/industrialio-triggered-event.c|   67 +
 drivers/iio/trigger/iio-trig-sysfs.c  |   58 +
 include/linux/iio/iio.h   |1 
 include/linux/iio/triggered_event.h   |   11 
 15 files changed, 940 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
 create mode 100644 drivers/iio/adc/hi8435.c
 create mode 100644 Documentation/devicetree/bindings/iio/adc/hi8435.txt
 create mode 100644 drivers/iio/industrialio-triggered-event.c
 create mode 100644 include/linux/iio/triggered_event.h
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] iio: adc: hi-843x: Holt HI-8435/8436/8437 descrete ADC

[Vladimir Barinov]

On 21.06.2015 17:14, Jonathan Cameron wrote:

I'd call this a threshold detector. The device seems to have two
comparators for each channel, one for the lower threshold, one for
the upper threshold. If the voltage level goes above the upper
threshold a FF is set, if it goes below the lower threshold the FF
is cleared. Both transitions happen asynchronously as soon has the
signal is below/above the threshold. And while converts a analog
signal to digital one this is not what you typically call a ADC.

Should this be a separate/new directory in the drivers/iio/ for such driver?

Given we could in theory have comparators for any type of channel it probably 
doesn't
make sense to have a whole new directory.  Perhaps a section in the config.

What the type of iio_chan_spec should I use instead of IIO_VOLTAGE?

I've been thinking about this.  Maybe we should use the same approach we already
use for 'computed' channel values such as root sum squared accelerations that 
turn
up occasionally and do this as a modifier.

So the channel type would be voltage, but with the modifier comparator 
(shortening
it would just get confusing).  This also maps nicely to devices that offer both
normal adc channels and comparators on the same pin (if that ever happens!)

Hence the attributes etc would be:
in_voltage0_comparator_raw

Do you think that would be clear / flexible enough?

yes

I wonder if we want to take this oportunity to add 1 bit packing to the
demux etc in the IIO core so we can have tighter packing on these
values.  Shouldn't be too hard to do and we probably do want it if we are
going to support these sorts of devices.

Will take a bit of shuffling to pack the relevant channels together if only
a subset are enabled and to notice when no repacking at all is needed.
This will probably first one implementing in the core and pushing out into
the dummy driver to allow for testing of corner cases.

Yeah, the bit shuffling gets quite cumbersome and potentially
expensive. I think we should try to avoid it if at least one of the
channels in the same bank is enabled all of them are read. And then
let userspace figure out which bits it wants to use.

But how exactly is the typical expect usage of this device. Like
how would a userspace application use it? Is buffered mode where
samples are taken in a continuous mode something that is really
needed?

I was expecting to use triggered buffer for this device:
1) setup threshold levels via sysfs
2) enable scan elements
3) setup trigger
4) grab data from triggered iio buffer like the
tools/iio/generic_buffer.c does, f.e. ./generic_buffer -n hi-8435 -t
irqtrig0 -l 100 -c 1000

Good, you are going about it the right way then.  Makes sense as this
is what you'd do for similar devices such as a logic analyzer.

Actually I understand that I can just read manually the
/sysfs/.../in_voltageXX_raw (or new/other name) values but using of
iio generic irq trigger would be very good.

What is generating the interrupt?   Are we looking at a 'dataready'
type interrupt or some other pseudo (or actual) fixed frequency, or
are we talking an interrupt on the state of one of the inputs changing?

If the second case, then an event based approach may make more sense
than using buffers.
Actually it is a interrupt that should occur on the state change of one 
of the inputs.


But hi8435 chip does not have it's own dedicated/hardware interrupt line 
for this purposes, so it
requires any kind of polling (hardware from pwm/gpio, or s/w polling 
inside the driver)


Probably I'm not right by trying to use "iio irq trigger" from external 
hardware line (like gpio/pwm)

and I have to implement polling inside driver.

Event based approach is good enough.

About bits shuffling/separating. I do think we can use banks byte
length for one iio channel instead of 1-bit length to avoid such
complexity. Then let user space separate bank's channels by itself.

On high channel count devices this could get nasty quickly.

I'd like to explore Lars' suggestion that we use shared scan_indexes
for a set of channels, and different shift / mask values.  I don't
think it would need any particularly substantial changes in kernel
and obviously only usespace code using this new type of device would
need to know about it.

I'd relax the suggestion he made to have it always sample all channels
in a given scan index, to say that it can if it makes sense.  We won't
bother masking them out, but if it is quicker for the device to not read
those that aren't enabled, then it is up to the device whether it does.

The issue is that if we let a device in now with the 8bits per bit
interface, we kind of commit to at least having userspace support that
long term which isn't nice (though not too bad I suppose as it is just
the least efficient case of what we are talking about doing anyway).


Ok, I see

Regards,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 

Re: [PATCH 1/3] iio: adc: hi-843x: Holt HI-8435/8436/8437 descrete ADC

[Vladimir Barinov]

On 21.06.2015 17:14, Jonathan Cameron wrote:

I'd call this a threshold detector. The device seems to have two
comparators for each channel, one for the lower threshold, one for
the upper threshold. If the voltage level goes above the upper
threshold a FF is set, if it goes below the lower threshold the FF
is cleared. Both transitions happen asynchronously as soon has the
signal is below/above the threshold. And while converts a analog
signal to digital one this is not what you typically call a ADC.

Should this be a separate/new directory in the drivers/iio/ for such driver?

Given we could in theory have comparators for any type of channel it probably 
doesn't
make sense to have a whole new directory.  Perhaps a section in the config.

What the type of iio_chan_spec should I use instead of IIO_VOLTAGE?

I've been thinking about this.  Maybe we should use the same approach we already
use for 'computed' channel values such as root sum squared accelerations that 
turn
up occasionally and do this as a modifier.

So the channel type would be voltage, but with the modifier comparator 
(shortening
it would just get confusing).  This also maps nicely to devices that offer both
normal adc channels and comparators on the same pin (if that ever happens!)

Hence the attributes etc would be:
in_voltage0_comparator_raw

Do you think that would be clear / flexible enough?

yes

I wonder if we want to take this oportunity to add 1 bit packing to the
demux etc in the IIO core so we can have tighter packing on these
values.  Shouldn't be too hard to do and we probably do want it if we are
going to support these sorts of devices.

Will take a bit of shuffling to pack the relevant channels together if only
a subset are enabled and to notice when no repacking at all is needed.
This will probably first one implementing in the core and pushing out into
the dummy driver to allow for testing of corner cases.

Yeah, the bit shuffling gets quite cumbersome and potentially
expensive. I think we should try to avoid it if at least one of the
channels in the same bank is enabled all of them are read. And then
let userspace figure out which bits it wants to use.

But how exactly is the typical expect usage of this device. Like
how would a userspace application use it? Is buffered mode where
samples are taken in a continuous mode something that is really
needed?

I was expecting to use triggered buffer for this device:
1) setup threshold levels via sysfs
2) enable scan elements
3) setup trigger
4) grab data from triggered iio buffer like the
tools/iio/generic_buffer.c does, f.e. ./generic_buffer -n hi-8435 -t
irqtrig0 -l 100 -c 1000

Good, you are going about it the right way then.  Makes sense as this
is what you'd do for similar devices such as a logic analyzer.

Actually I understand that I can just read manually the
/sysfs/.../in_voltageXX_raw (or new/other name) values but using of
iio generic irq trigger would be very good.

What is generating the interrupt?   Are we looking at a 'dataready'
type interrupt or some other pseudo (or actual) fixed frequency, or
are we talking an interrupt on the state of one of the inputs changing?

If the second case, then an event based approach may make more sense
than using buffers.
Actually it is a interrupt that should occur on the state change of one 
of the inputs.


But hi8435 chip does not have it's own dedicated/hardware interrupt line 
for this purposes, so it
requires any kind of polling (hardware from pwm/gpio, or s/w polling 
inside the driver)


Probably I'm not right by trying to use iio irq trigger from external 
hardware line (like gpio/pwm)

and I have to implement polling inside driver.

Event based approach is good enough.

About bits shuffling/separating. I do think we can use banks byte
length for one iio channel instead of 1-bit length to avoid such
complexity. Then let user space separate bank's channels by itself.

On high channel count devices this could get nasty quickly.

I'd like to explore Lars' suggestion that we use shared scan_indexes
for a set of channels, and different shift / mask values.  I don't
think it would need any particularly substantial changes in kernel
and obviously only usespace code using this new type of device would
need to know about it.

I'd relax the suggestion he made to have it always sample all channels
in a given scan index, to say that it can if it makes sense.  We won't
bother masking them out, but if it is quicker for the device to not read
those that aren't enabled, then it is up to the device whether it does.

The issue is that if we let a device in now with the 8bits per bit
interface, we kind of commit to at least having userspace support that
long term which isn't nice (though not too bad I suppose as it is just
the least efficient case of what we are talking about doing anyway).


Ok, I see

Regards,
Vladimir
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to 

Re: [PATCH 1/3] iio: adc: hi-843x: Holt HI-8435/8436/8437 descrete ADC

[Vladimir Barinov]

Hi Lars,

Thank you for the review.

On 18.06.2015 22:33, Lars-Peter Clausen wrote:

On 06/07/2015 06:11 PM, Jonathan Cameron wrote:

On 01/06/15 13:20, Vladimir Barinov wrote:

Add Holt descrete ADC driver for HI-8435/8436/8437 chips

Signed-off-by: Vladimir Barinov 

Hmm. The main issue here is one man's discrete ADC is another man's
configurable general purpose input device.


The term discrete ADC is a bit ambiguous and I'm not even sure if this 
is the right term for this kind of device.


I'd call this a threshold detector. The device seems to have two 
comparators for each channel, one for the lower threshold, one for the 
upper threshold. If the voltage level goes above the upper threshold a 
FF is set, if it goes below the lower threshold the FF is cleared. 
Both transitions happen asynchronously as soon has the signal is 
below/above the threshold. And while converts a analog signal to 
digital one this is not what you typically call a ADC.


Should this be a separate/new directory in the drivers/iio/ for such driver?
What the type of iio_chan_spec should I use instead of IIO_VOLTAGE?





I wonder if we want to take this oportunity to add 1 bit packing to the
demux etc in the IIO core so we can have tighter packing on these
values.  Shouldn't be too hard to do and we probably do want it if we 
are

going to support these sorts of devices.

Will take a bit of shuffling to pack the relevant channels together 
if only

a subset are enabled and to notice when no repacking at all is needed.
This will probably first one implementing in the core and pushing out 
into

the dummy driver to allow for testing of corner cases.


Yeah, the bit shuffling gets quite cumbersome and potentially 
expensive. I think we should try to avoid it if at least one of the 
channels in the same bank is enabled all of them are read. And then 
let userspace figure out which bits it wants to use.


But how exactly is the typical expect usage of this device. Like how 
would a userspace application use it? Is buffered mode where samples 
are taken in a continuous mode something that is really needed?

I was expecting to use triggered buffer for this device:
1) setup threshold levels via sysfs
2) enable scan elements
3) setup trigger
4) grab data from triggered iio buffer like the 
tools/iio/generic_buffer.c does, f.e.

./generic_buffer -n hi-8435 -t irqtrig0 -l 100 -c 1000

Actually I understand that I can just read manually the 
/sysfs/.../in_voltageXX_raw (or new/other name) values but using of iio 
generic irq trigger would be very good.


About bits shuffling/separating.  I do think we can use banks byte 
length for one iio channel instead of 1-bit length to avoid such complexity.

Then let user space separate bank's channels by itself.

Regards,
Vladimir

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] iio: adc: hi-843x: Holt HI-8435/8436/8437 descrete ADC

[Vladimir Barinov]

Hi Lars,

Thank you for the review.

On 18.06.2015 22:33, Lars-Peter Clausen wrote:

On 06/07/2015 06:11 PM, Jonathan Cameron wrote:

On 01/06/15 13:20, Vladimir Barinov wrote:

Add Holt descrete ADC driver for HI-8435/8436/8437 chips

Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com

Hmm. The main issue here is one man's discrete ADC is another man's
configurable general purpose input device.


The term discrete ADC is a bit ambiguous and I'm not even sure if this 
is the right term for this kind of device.


I'd call this a threshold detector. The device seems to have two 
comparators for each channel, one for the lower threshold, one for the 
upper threshold. If the voltage level goes above the upper threshold a 
FF is set, if it goes below the lower threshold the FF is cleared. 
Both transitions happen asynchronously as soon has the signal is 
below/above the threshold. And while converts a analog signal to 
digital one this is not what you typically call a ADC.


Should this be a separate/new directory in the drivers/iio/ for such driver?
What the type of iio_chan_spec should I use instead of IIO_VOLTAGE?





I wonder if we want to take this oportunity to add 1 bit packing to the
demux etc in the IIO core so we can have tighter packing on these
values.  Shouldn't be too hard to do and we probably do want it if we 
are

going to support these sorts of devices.

Will take a bit of shuffling to pack the relevant channels together 
if only

a subset are enabled and to notice when no repacking at all is needed.
This will probably first one implementing in the core and pushing out 
into

the dummy driver to allow for testing of corner cases.


Yeah, the bit shuffling gets quite cumbersome and potentially 
expensive. I think we should try to avoid it if at least one of the 
channels in the same bank is enabled all of them are read. And then 
let userspace figure out which bits it wants to use.


But how exactly is the typical expect usage of this device. Like how 
would a userspace application use it? Is buffered mode where samples 
are taken in a continuous mode something that is really needed?

I was expecting to use triggered buffer for this device:
1) setup threshold levels via sysfs
2) enable scan elements
3) setup trigger
4) grab data from triggered iio buffer like the 
tools/iio/generic_buffer.c does, f.e.

./generic_buffer -n hi-8435 -t irqtrig0 -l 100 -c 1000

Actually I understand that I can just read manually the 
/sysfs/.../in_voltageXX_raw (or new/other name) values but using of iio 
generic irq trigger would be very good.


About bits shuffling/separating.  I do think we can use banks byte 
length for one iio channel instead of 1-bit length to avoid such complexity.

Then let user space separate bank's channels by itself.

Regards,
Vladimir

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] iio: adc: hi-843x: Holt HI-8435/8436/8437 descrete ADC

[Vladimir Barinov]

Hi Paul,

On 03.06.2015 10:05, Paul Bolle wrote:

Just a nit, that I spotted while scanning for other issues.

On Mon, 2015-06-01 at 15:20 +0300, Vladimir Barinov wrote:

--- /dev/null
+++ b/drivers/iio/adc/hi-843x.c
+ssize_t hi843x_debounce_soft_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+   [...]
+}
+
+[...]
+
+ssize_t hi843x_threshold_socval_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+   [...]
+}

It seems all these *_show and *_store functions should be made static,
right?

Right. Thank you for pointing to this.

Regards,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] iio: adc: hi-843x: Holt HI-8435/8436/8437 descrete ADC

[Vladimir Barinov]

Hi Paul,

On 03.06.2015 10:05, Paul Bolle wrote:

Just a nit, that I spotted while scanning for other issues.

On Mon, 2015-06-01 at 15:20 +0300, Vladimir Barinov wrote:

--- /dev/null
+++ b/drivers/iio/adc/hi-843x.c
+ssize_t hi843x_debounce_soft_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+   [...]
+}
+
+[...]
+
+ssize_t hi843x_threshold_socval_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+   [...]
+}

It seems all these *_show and *_store functions should be made static,
right?

Right. Thank you for pointing to this.

Regards,
Vladimir
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] dt: Document Holt descrete ADC bindings

[Vladimir Barinov]

These bindings can be used to register Holt HI-8435/8436/8437 descrete ADC

Signed-off-by: Vladimir Barinov 
---
 .../devicetree/bindings/iio/adc/hi-843x.txt| 27 ++
 1 file changed, 27 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/hi-843x.txt

diff --git a/Documentation/devicetree/bindings/iio/adc/hi-843x.txt 
b/Documentation/devicetree/bindings/iio/adc/hi-843x.txt
new file mode 100644
index 000..872e801
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/hi-843x.txt
@@ -0,0 +1,27 @@
+Holt Integrated Circuits HI-8435/8436/8437 discrete ADC bindings
+
+Required properties:
+ - compatible: Should be "holt,hi-8435" or "holt,hi-8436" or "holt,hi-8437"
+ - reg: spi chip select number for the device
+
+Recommended properties:
+ - spi-max-frequency: Definition as per
+   Documentation/devicetree/bindings/spi/spi-bus.txt
+
+Optional properties:
+ - holt,mr-gpio: GPIO used for controlling the MR (chip reset) pin
+ - holt,debounce-soft: enable software debounce at startup
+ - holt,debounce-soft-delay: software debounce interval in milliseconds
+
+Example:
+adc@0 {
+   compatible = "holt,hi-8435";
+   reg = <0>;
+
+   holt,mr-gpio = < 1 0>;
+
+   holt,debounce-soft;
+   holt,debounce-soft-delay = <100>;
+
+   spi-max-frequency = <100>;
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] dt: Add vendor prefix 'holt'

[Vladimir Barinov]

Add Holt Integrated Circuits, Inc. to the list of device tree vendor prefixes

Signed-off-by: Vladimir Barinov 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 8033919..7101f400 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -93,6 +93,7 @@ haoyu Haoyu Microelectronic Co. Ltd.
 himax  Himax Technologies, Inc.
 hisilicon  Hisilicon Limited.
 hitHitachi Ltd.
+holt   Holt Integrated Circuits, Inc.
 honeywell  Honeywell
 hp Hewlett Packard
 i2se   I2SE GmbH
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] iio: adc: hi-843x: Holt HI-8435/8436/8437 descrete ADC

[Vladimir Barinov]

Add Holt descrete ADC driver for HI-8435/8436/8437 chips

Signed-off-by: Vladimir Barinov 
---
 drivers/iio/adc/Kconfig   |  12 +
 drivers/iio/adc/Makefile  |   1 +
 drivers/iio/adc/hi-843x.c | 777 ++
 3 files changed, 790 insertions(+)
 create mode 100644 drivers/iio/adc/hi-843x.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index e36a73e..71b0efc 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -164,6 +164,18 @@ config EXYNOS_ADC
  of SoCs for drivers such as the touchscreen and hwmon to use to share
  this resource.
 
+config HI_843X
+   tristate "Holt Integrated Circuits HI-8435/8436/8437"
+   select IIO_BUFFER
+   select IIO_TRIGGERED_BUFFER
+   depends on SPI
+   help
+ If you say yes here you get support for Holt Integrated Circuits
+ HI-8435/8436/8437 chip.
+
+ This driver can also be built as a module. If so, the module will be
+ called hi-843x.
+
 config LP8788_ADC
tristate "LP8788 ADC driver"
depends on MFD_LP8788
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 3930e63..65f54c2 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_AXP288_ADC) += axp288_adc.o
 obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
 obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
 obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
+obj-$(CONFIG_HI_843X) += hi-843x.o
 obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
 obj-$(CONFIG_MAX1027) += max1027.o
 obj-$(CONFIG_MAX1363) += max1363.o
diff --git a/drivers/iio/adc/hi-843x.c b/drivers/iio/adc/hi-843x.c
new file mode 100644
index 000..ccc46e7
--- /dev/null
+++ b/drivers/iio/adc/hi-843x.c
@@ -0,0 +1,777 @@
+/*
+ * Holt Integrated Circuits HI-8435/8436/8437 discrete ADC driver
+ *
+ * Copyright (C) 2015 Zodiac Inflight Innovations
+ * Copyright (C) 2015 Cogent Embedded, Inc.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define DRV_NAME "hi-843x"
+
+/* Register offsets for HI-843X */
+#define HI843X_CTRL_REG0x02
+#define HI843X_PSEN_REG0x04
+#define HI843X_TMDATA_REG  0x1E
+#define HI843X_GOCENHYS_REG0x3A
+#define HI843X_SOCENHYS_REG0x3C
+#define HI843X_SO7_0_REG   0x10
+#define HI843X_SO15_8_REG  0x12
+#define HI843X_SO23_16_REG 0x14
+#define HI843X_SO31_24_REG 0x16
+#define HI843X_SO31_0_REG  0x78
+
+#define HI843X_WRITE_OPCODE0x00
+#define HI843X_READ_OPCODE 0x80
+
+/* THRESHOLD mask */
+#define HI843X_THRESHOLD_MAX   0x3f
+#define HI843X_THRESHOLD_MASK  0xff
+
+/* CTRL register bits */
+#define HI843X_CTRL_TEST   0x01
+#define HI843X_CTRL_SRST   0x02
+
+#define HI843X_DEBOUNCE_SOFT_DELAY_MAX 1000/* ms */
+#define HI843X_DEBOUNCE_SOFT_DELAY_DEF 100 /* ms */
+
+struct hi843x_priv {
+   struct spi_device *spi;
+   struct mutex lock;
+   struct delayed_work work;
+
+   int mr_gpio;
+   bool debounce_soft;
+   int debounce_soft_delay;
+   int debounce_soft_val;
+
+   void *iio_buffer;
+   u8 reg_buffer[4] cacheline_aligned;
+};
+
+static int hi843x_readb(struct hi843x_priv *priv, u8 reg, u8 *val)
+{
+   reg |= HI843X_READ_OPCODE;
+   return spi_write_then_read(priv->spi, , 1, val, 1);
+}
+
+static int hi843x_readw(struct hi843x_priv *priv, u8 reg, u16 *val)
+{
+   int ret;
+
+   reg |= HI843X_READ_OPCODE;
+   ret = spi_write_then_read(priv->spi, , 1, val, 2);
+   *val = swab16p(val);
+
+   return ret;
+}
+
+static int hi843x_readl(struct hi843x_priv *priv, u8 reg, u32 *val)
+{
+   int ret;
+
+   reg |= HI843X_READ_OPCODE;
+   ret = spi_write_then_read(priv->spi, , 1, val, 4);
+   *val = swab32p(val);
+
+   return ret;
+}
+
+static int hi843x_writeb(struct hi843x_priv *priv, u8 reg, u8 val)
+{
+   priv->reg_buffer[0] = reg | HI843X_WRITE_OPCODE;
+   priv->reg_buffer[1] = val;
+
+   return spi_write(priv->spi, priv->reg_buffer, 2);
+}
+
+static int hi843x_writew(struct hi843x_priv *priv, u8 reg, u16 val)
+{
+   priv->reg_buffer[0] = reg | HI843X_WRITE_OPCODE;
+   priv->reg_buffer[1] = (val >> 8) & 0xff;
+   priv->reg_buffer[2] = val & 0xff;
+
+   return spi_write(priv->spi, priv->reg_buffer, 3);
+}
+
+ssize_t hi843x_debounce_soft_show(struct device *dev,
+

[PATCH 0/3] iio: adc: hi-843x: Add Holt HI-8435/8436/8437 descrete ADC

[Vladimir Barinov]

Hello,

This adds the folowing:
- Holt descrete ADC driver for HI-8435/8436/8437 chips
- Add vendor prefix
- Document DT bindings

Vladimir Barinov (3):
[1/3] iio: adc: hi-843x: Holt HI-8435/8436/8437 descrete ADC
[2/3] dt: Add vendor prefix 'holt'
[3/3] dt: Document Holt descrete ADC bindings

---
This patchset is against the 'kernel/git/torvalds/linux.git' repo.

 Documentation/devicetree/bindings/iio/adc/hi-843x.txt |   27 
 Documentation/devicetree/bindings/vendor-prefixes.txt |1 
 drivers/iio/adc/Kconfig   |   12 
 drivers/iio/adc/Makefile  |1 
 drivers/iio/adc/hi-843x.c |  777 ++
 5 files changed, 818 insertions(+)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] iio: adc: hi-843x: Holt HI-8435/8436/8437 descrete ADC

[Vladimir Barinov]

Add Holt descrete ADC driver for HI-8435/8436/8437 chips

Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
---
 drivers/iio/adc/Kconfig   |  12 +
 drivers/iio/adc/Makefile  |   1 +
 drivers/iio/adc/hi-843x.c | 777 ++
 3 files changed, 790 insertions(+)
 create mode 100644 drivers/iio/adc/hi-843x.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index e36a73e..71b0efc 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -164,6 +164,18 @@ config EXYNOS_ADC
  of SoCs for drivers such as the touchscreen and hwmon to use to share
  this resource.
 
+config HI_843X
+   tristate Holt Integrated Circuits HI-8435/8436/8437
+   select IIO_BUFFER
+   select IIO_TRIGGERED_BUFFER
+   depends on SPI
+   help
+ If you say yes here you get support for Holt Integrated Circuits
+ HI-8435/8436/8437 chip.
+
+ This driver can also be built as a module. If so, the module will be
+ called hi-843x.
+
 config LP8788_ADC
tristate LP8788 ADC driver
depends on MFD_LP8788
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 3930e63..65f54c2 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_AXP288_ADC) += axp288_adc.o
 obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
 obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
 obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
+obj-$(CONFIG_HI_843X) += hi-843x.o
 obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
 obj-$(CONFIG_MAX1027) += max1027.o
 obj-$(CONFIG_MAX1363) += max1363.o
diff --git a/drivers/iio/adc/hi-843x.c b/drivers/iio/adc/hi-843x.c
new file mode 100644
index 000..ccc46e7
--- /dev/null
+++ b/drivers/iio/adc/hi-843x.c
@@ -0,0 +1,777 @@
+/*
+ * Holt Integrated Circuits HI-8435/8436/8437 discrete ADC driver
+ *
+ * Copyright (C) 2015 Zodiac Inflight Innovations
+ * Copyright (C) 2015 Cogent Embedded, Inc.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include linux/delay.h
+#include linux/iio/buffer.h
+#include linux/iio/iio.h
+#include linux/iio/sysfs.h
+#include linux/iio/trigger.h
+#include linux/iio/trigger_consumer.h
+#include linux/iio/triggered_buffer.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/of_gpio.h
+#include linux/spi/spi.h
+#include linux/workqueue.h
+
+#include linux/interrupt.h
+
+#define DRV_NAME hi-843x
+
+/* Register offsets for HI-843X */
+#define HI843X_CTRL_REG0x02
+#define HI843X_PSEN_REG0x04
+#define HI843X_TMDATA_REG  0x1E
+#define HI843X_GOCENHYS_REG0x3A
+#define HI843X_SOCENHYS_REG0x3C
+#define HI843X_SO7_0_REG   0x10
+#define HI843X_SO15_8_REG  0x12
+#define HI843X_SO23_16_REG 0x14
+#define HI843X_SO31_24_REG 0x16
+#define HI843X_SO31_0_REG  0x78
+
+#define HI843X_WRITE_OPCODE0x00
+#define HI843X_READ_OPCODE 0x80
+
+/* THRESHOLD mask */
+#define HI843X_THRESHOLD_MAX   0x3f
+#define HI843X_THRESHOLD_MASK  0xff
+
+/* CTRL register bits */
+#define HI843X_CTRL_TEST   0x01
+#define HI843X_CTRL_SRST   0x02
+
+#define HI843X_DEBOUNCE_SOFT_DELAY_MAX 1000/* ms */
+#define HI843X_DEBOUNCE_SOFT_DELAY_DEF 100 /* ms */
+
+struct hi843x_priv {
+   struct spi_device *spi;
+   struct mutex lock;
+   struct delayed_work work;
+
+   int mr_gpio;
+   bool debounce_soft;
+   int debounce_soft_delay;
+   int debounce_soft_val;
+
+   void *iio_buffer;
+   u8 reg_buffer[4] cacheline_aligned;
+};
+
+static int hi843x_readb(struct hi843x_priv *priv, u8 reg, u8 *val)
+{
+   reg |= HI843X_READ_OPCODE;
+   return spi_write_then_read(priv-spi, reg, 1, val, 1);
+}
+
+static int hi843x_readw(struct hi843x_priv *priv, u8 reg, u16 *val)
+{
+   int ret;
+
+   reg |= HI843X_READ_OPCODE;
+   ret = spi_write_then_read(priv-spi, reg, 1, val, 2);
+   *val = swab16p(val);
+
+   return ret;
+}
+
+static int hi843x_readl(struct hi843x_priv *priv, u8 reg, u32 *val)
+{
+   int ret;
+
+   reg |= HI843X_READ_OPCODE;
+   ret = spi_write_then_read(priv-spi, reg, 1, val, 4);
+   *val = swab32p(val);
+
+   return ret;
+}
+
+static int hi843x_writeb(struct hi843x_priv *priv, u8 reg, u8 val)
+{
+   priv-reg_buffer[0] = reg | HI843X_WRITE_OPCODE;
+   priv-reg_buffer[1] = val;
+
+   return spi_write(priv-spi, priv-reg_buffer, 2);
+}
+
+static int hi843x_writew(struct hi843x_priv *priv, u8 reg, u16 val)
+{
+   priv-reg_buffer[0] = reg | HI843X_WRITE_OPCODE;
+   priv-reg_buffer[1] = (val  8)  0xff

[PATCH 2/3] dt: Add vendor prefix 'holt'

[Vladimir Barinov]

Add Holt Integrated Circuits, Inc. to the list of device tree vendor prefixes

Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 8033919..7101f400 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -93,6 +93,7 @@ haoyu Haoyu Microelectronic Co. Ltd.
 himax  Himax Technologies, Inc.
 hisilicon  Hisilicon Limited.
 hitHitachi Ltd.
+holt   Holt Integrated Circuits, Inc.
 honeywell  Honeywell
 hp Hewlett Packard
 i2se   I2SE GmbH
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/3] iio: adc: hi-843x: Add Holt HI-8435/8436/8437 descrete ADC

[Vladimir Barinov]

Hello,

This adds the folowing:
- Holt descrete ADC driver for HI-8435/8436/8437 chips
- Add vendor prefix
- Document DT bindings

Vladimir Barinov (3):
[1/3] iio: adc: hi-843x: Holt HI-8435/8436/8437 descrete ADC
[2/3] dt: Add vendor prefix 'holt'
[3/3] dt: Document Holt descrete ADC bindings

---
This patchset is against the 'kernel/git/torvalds/linux.git' repo.

 Documentation/devicetree/bindings/iio/adc/hi-843x.txt |   27 
 Documentation/devicetree/bindings/vendor-prefixes.txt |1 
 drivers/iio/adc/Kconfig   |   12 
 drivers/iio/adc/Makefile  |1 
 drivers/iio/adc/hi-843x.c |  777 ++
 5 files changed, 818 insertions(+)

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] dt: Document Holt descrete ADC bindings

[Vladimir Barinov]

These bindings can be used to register Holt HI-8435/8436/8437 descrete ADC

Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
---
 .../devicetree/bindings/iio/adc/hi-843x.txt| 27 ++
 1 file changed, 27 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/hi-843x.txt

diff --git a/Documentation/devicetree/bindings/iio/adc/hi-843x.txt 
b/Documentation/devicetree/bindings/iio/adc/hi-843x.txt
new file mode 100644
index 000..872e801
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/hi-843x.txt
@@ -0,0 +1,27 @@
+Holt Integrated Circuits HI-8435/8436/8437 discrete ADC bindings
+
+Required properties:
+ - compatible: Should be holt,hi-8435 or holt,hi-8436 or holt,hi-8437
+ - reg: spi chip select number for the device
+
+Recommended properties:
+ - spi-max-frequency: Definition as per
+   Documentation/devicetree/bindings/spi/spi-bus.txt
+
+Optional properties:
+ - holt,mr-gpio: GPIO used for controlling the MR (chip reset) pin
+ - holt,debounce-soft: enable software debounce at startup
+ - holt,debounce-soft-delay: software debounce interval in milliseconds
+
+Example:
+adc@0 {
+   compatible = holt,hi-8435;
+   reg = 0;
+
+   holt,mr-gpio = gpio6 1 0;
+
+   holt,debounce-soft;
+   holt,debounce-soft-delay = 100;
+
+   spi-max-frequency = 100;
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/3] power_supply: modelgauge_battery: Add Maxim ModelGauge ICs gauge

[Vladimir Barinov]

Hello Dmitry,

In accordance to this change you've taken the responsibility for power 
supply maintainership.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/MAINTAINERS?id=573189354b7c97cd2256b87cf083ee435584594e

It passed almost month and no answer from you.
Does it make sense to apply this patch series?

Regards,
Vladimir

On 02/02/2014 02:23 AM, Vladimir Barinov wrote:

Hello.

This adds the folowing:
- Maxim ModelGauge ICs gauge driver for MAX17040/41/43/44/48/49/58/59 chips
- Document DT bindings
- Remove superseded Maxim MAX17040 gauge driver

Vladimir Barinov (3):
  [1/3] power_supply: modelgauge_battery: Maxim ModelGauge ICs gauge
  [2/3] dt: Document ModelGauge gauge bindings
  [3/3] power_supply: modelgauge_battery: Remove Maxim MAX17040 gauge

---
This patchset is against the 'kernel/git/torvalds/linux.git' repo.

Changes since v1:
- switched to REGMAP API
- replaced request_threaded_irq with devm_request_threaded_irq
- replaced cancel_delayed_work with _sync version
- moved "empty_alert_threshold, soc_change_alert, hibernate_threshold,
   active_threshold, undervoltage, overvoltage, resetvoltage" parameters
   out from platform_data and DT
- removed unused parameters "empty_adjustment, empty_adjustment"
- added return value checks for of_property_read_XX functions
- removed irrelevant bindings
- fixed dt properties naming in documentation
- added binding size description in documentation
- removed satelite include file include/linux/max17040_battery.h

  Documentation/devicetree/bindings/power_supply/modelgauge_battery.txt |   61
  drivers/power/Kconfig |   17
  drivers/power/Makefile|2
  drivers/power/max17040_battery.c  |  297 
---
  drivers/power/modelgauge_battery.c|  838 
++
  include/linux/max17040_battery.h  |   19
  include/linux/platform_data/battery-modelgauge.h  |   31
  7 files changed, 940 insertions(+), 325 deletions(-)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/3] power_supply: modelgauge_battery: Add Maxim ModelGauge ICs gauge

[Vladimir Barinov]

Hello Dmitry,

In accordance to this change you've taken the responsibility for power 
supply maintainership.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/MAINTAINERS?id=573189354b7c97cd2256b87cf083ee435584594e

It passed almost month and no answer from you.
Does it make sense to apply this patch series?

Regards,
Vladimir

On 02/02/2014 02:23 AM, Vladimir Barinov wrote:

Hello.

This adds the folowing:
- Maxim ModelGauge ICs gauge driver for MAX17040/41/43/44/48/49/58/59 chips
- Document DT bindings
- Remove superseded Maxim MAX17040 gauge driver

Vladimir Barinov (3):
  [1/3] power_supply: modelgauge_battery: Maxim ModelGauge ICs gauge
  [2/3] dt: Document ModelGauge gauge bindings
  [3/3] power_supply: modelgauge_battery: Remove Maxim MAX17040 gauge

---
This patchset is against the 'kernel/git/torvalds/linux.git' repo.

Changes since v1:
- switched to REGMAP API
- replaced request_threaded_irq with devm_request_threaded_irq
- replaced cancel_delayed_work with _sync version
- moved empty_alert_threshold, soc_change_alert, hibernate_threshold,
   active_threshold, undervoltage, overvoltage, resetvoltage parameters
   out from platform_data and DT
- removed unused parameters empty_adjustment, empty_adjustment
- added return value checks for of_property_read_XX functions
- removed irrelevant bindings
- fixed dt properties naming in documentation
- added binding size description in documentation
- removed satelite include file include/linux/max17040_battery.h

  Documentation/devicetree/bindings/power_supply/modelgauge_battery.txt |   61
  drivers/power/Kconfig |   17
  drivers/power/Makefile|2
  drivers/power/max17040_battery.c  |  297 
---
  drivers/power/modelgauge_battery.c|  838 
++
  include/linux/max17040_battery.h  |   19
  include/linux/platform_data/battery-modelgauge.h  |   31
  7 files changed, 940 insertions(+), 325 deletions(-)


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V4 3/4] ARM: shmobile: koelsch: Add USBHS and internal PCI USB support

[Vladimir Barinov]

Hi Magnus,

On 02/24/2014 12:05 PM, Magnus Damm wrote:

Hi Vladimir,

On Mon, Feb 24, 2014 at 4:34 PM, Vladimir Barinov
  wrote:

Hello Magnus,

Thank you for the quick response.


On 02/24/2014 07:52 AM, Magnus Damm wrote:

+static int usbhs_hardware_init(struct platform_device *pdev)
+{
+   struct usbhs_private *priv = usbhs_get_priv(pdev);
+   struct usb_phy *phy;
+
+   phy = usb_get_phy_dev(>dev, 0);
+   if (IS_ERR(phy))
+   return PTR_ERR(phy);
+
+   priv->phy = phy;
+   return 0;
+}
+
+static int usbhs_hardware_exit(struct platform_device *pdev)
+{
+   struct usbhs_private *priv = usbhs_get_priv(pdev);
+
+   if (!priv->phy)
+   return 0;
+
+   usb_put_phy(priv->phy);
+   priv->phy = NULL;
+   return 0;
+}
+
+static int usbhs_get_id(struct platform_device *pdev)
+{
+   return USBHS_GADGET;
+}
Uhm, I sort of expected this place to be where you read out the ID pin
state from the MAX device.

Yes, I've seen your work for lager board.
I did differently then you beacause of problem in USBHS Host driver, hence
the need of setup PHY at initial stage to PCI USB and not to USBHS.

Yeah, I understand. But with the current patches I wonder, isn't there
risk for short circuit ? Say that a USB host cable is connected during
boot and the PCI USB host controller is hooked up, what is stopping us
from switching the cable and driving VBUS from two sides using a USB
function cable? So the current patches seem a bit unsafe to me.

Yes.
In case of such condition, when the usb cable changed after host device 
probe the

risk of VBUS collision is obvious.
The interrupt driven ID pin monitoring in board file could help?

Probably the separate driver for the MAX3355 should not be added since 
this provides

poor information, most significant is cable ID.



+static u32 koelsch_usbhs_pipe_type[] = {
+
+/* Add all available USB devices */
+static void __init koelsch_add_usb_devices(void)
+{
+   /* MAX3355E ID pin */
+   gpio_request_one(RCAR_GP_PIN(5, 31), GPIOF_IN, NULL);
+   if (!gpio_get_value(RCAR_GP_PIN(5, 31))) {
+   usbhs_phy_pdata.chan0_pci = 1; /* Channel 0 is PCI USB
host */
+   koelsch_add_usb0_host();
+   } else {
+   usbhs_phy_pdata.chan0_pci = 0; /* Channel 0 is USBHS */
+   koelsch_add_usb0_gadget();
+   }

I don't think we should perform this kind of check at boot-up. This
goes without saying, but normal USB supports hot-plug so we should
check the cable type when the cable insertion event happens. Please
see my comment above for USBHS-specific location.

I do however understand that according to your investigation you
cannot use USBHS in host mode. I believe further investigation is
needed in that area to determine what is the best way forward.
Regarding VBUS control, I believe it should be possible to drive the
USB0_VBUS as GPIO and manually control the power.

I see.

To control USB0_VBUS as GPIO you may need to adjust the PFC tables for
pinctrl. At some point, would it be possible for you to cook up some
prototype code to try to control the USB0_VBUS signal via GPIO? This
may be pointless if the USBHS hardware cannot operate in Host mode
though.
No need, there is a set_vbus callback in HSBHS platform code for this 
purpose.



Would it be possible for you to break out USB PCI support for USB1 and
resend that so we can begin by merging that?

Wouldn't you like me also add USBHS in gadget mode for USB0 with the similar
check like you did on lager (with ID pin),
since it does not need the gpio-rcar changes too.

Thanks for your offer. Yes, that would be nice. May I suggest doing it
on two levels:
1) Gadget-only support (is it possible to perform runtime check of ID
pin value at insert event and give error in case of Host?)
2) Incremental USBHS host patch

Using two incremental patches like above we can begin by merging 1)
and keep on working on 2).


Also if you'd like I can add the USBHS in Host mode with the ID pin check
like you suggested, but the usb0 host will not be stable.
Probably this could speed up the USBHS Host development/fixing.

Please add it as a separate incremental patch if possible. I'd like to
have some kind of stable level of support without any funky
dependencies as a first goal, then keep on trying to get USBHS
working.

I think PCI USB for the micro USB port can simply be dropped now and
only use USBHS.

Sure, will do.

Regards,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V4 3/4] ARM: shmobile: koelsch: Add USBHS and internal PCI USB support

[Vladimir Barinov]

Hi Magnus,

On 02/24/2014 12:05 PM, Magnus Damm wrote:

Hi Vladimir,

On Mon, Feb 24, 2014 at 4:34 PM, Vladimir Barinov
vladimir.bari...@cogentembedded.com  wrote:

Hello Magnus,

Thank you for the quick response.


On 02/24/2014 07:52 AM, Magnus Damm wrote:

+static int usbhs_hardware_init(struct platform_device *pdev)
+{
+   struct usbhs_private *priv = usbhs_get_priv(pdev);
+   struct usb_phy *phy;
+
+   phy = usb_get_phy_dev(pdev-dev, 0);
+   if (IS_ERR(phy))
+   return PTR_ERR(phy);
+
+   priv-phy = phy;
+   return 0;
+}
+
+static int usbhs_hardware_exit(struct platform_device *pdev)
+{
+   struct usbhs_private *priv = usbhs_get_priv(pdev);
+
+   if (!priv-phy)
+   return 0;
+
+   usb_put_phy(priv-phy);
+   priv-phy = NULL;
+   return 0;
+}
+
+static int usbhs_get_id(struct platform_device *pdev)
+{
+   return USBHS_GADGET;
+}
Uhm, I sort of expected this place to be where you read out the ID pin
state from the MAX device.

Yes, I've seen your work for lager board.
I did differently then you beacause of problem in USBHS Host driver, hence
the need of setup PHY at initial stage to PCI USB and not to USBHS.

Yeah, I understand. But with the current patches I wonder, isn't there
risk for short circuit ? Say that a USB host cable is connected during
boot and the PCI USB host controller is hooked up, what is stopping us
from switching the cable and driving VBUS from two sides using a USB
function cable? So the current patches seem a bit unsafe to me.

Yes.
In case of such condition, when the usb cable changed after host device 
probe the

risk of VBUS collision is obvious.
The interrupt driven ID pin monitoring in board file could help?

Probably the separate driver for the MAX3355 should not be added since 
this provides

poor information, most significant is cable ID.



+static u32 koelsch_usbhs_pipe_type[] = {
+
+/* Add all available USB devices */
+static void __init koelsch_add_usb_devices(void)
+{
+   /* MAX3355E ID pin */
+   gpio_request_one(RCAR_GP_PIN(5, 31), GPIOF_IN, NULL);
+   if (!gpio_get_value(RCAR_GP_PIN(5, 31))) {
+   usbhs_phy_pdata.chan0_pci = 1; /* Channel 0 is PCI USB
host */
+   koelsch_add_usb0_host();
+   } else {
+   usbhs_phy_pdata.chan0_pci = 0; /* Channel 0 is USBHS */
+   koelsch_add_usb0_gadget();
+   }

I don't think we should perform this kind of check at boot-up. This
goes without saying, but normal USB supports hot-plug so we should
check the cable type when the cable insertion event happens. Please
see my comment above for USBHS-specific location.

I do however understand that according to your investigation you
cannot use USBHS in host mode. I believe further investigation is
needed in that area to determine what is the best way forward.
Regarding VBUS control, I believe it should be possible to drive the
USB0_VBUS as GPIO and manually control the power.

I see.

To control USB0_VBUS as GPIO you may need to adjust the PFC tables for
pinctrl. At some point, would it be possible for you to cook up some
prototype code to try to control the USB0_VBUS signal via GPIO? This
may be pointless if the USBHS hardware cannot operate in Host mode
though.
No need, there is a set_vbus callback in HSBHS platform code for this 
purpose.



Would it be possible for you to break out USB PCI support for USB1 and
resend that so we can begin by merging that?

Wouldn't you like me also add USBHS in gadget mode for USB0 with the similar
check like you did on lager (with ID pin),
since it does not need the gpio-rcar changes too.

Thanks for your offer. Yes, that would be nice. May I suggest doing it
on two levels:
1) Gadget-only support (is it possible to perform runtime check of ID
pin value at insert event and give error in case of Host?)
2) Incremental USBHS host patch

Using two incremental patches like above we can begin by merging 1)
and keep on working on 2).


Also if you'd like I can add the USBHS in Host mode with the ID pin check
like you suggested, but the usb0 host will not be stable.
Probably this could speed up the USBHS Host development/fixing.

Please add it as a separate incremental patch if possible. I'd like to
have some kind of stable level of support without any funky
dependencies as a first goal, then keep on trying to get USBHS
working.

I think PCI USB for the micro USB port can simply be dropped now and
only use USBHS.

Sure, will do.

Regards,
Vladimir
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/