from:"maitysanchayan"

Hello Paul,

On 15-06-06 12:26:07, Paul Bolle wrote:
 On Fri, 2015-06-05 at 14:52 +0530, Sanchayan Maity wrote:
  --- /dev/null
  +++ b/drivers/soc/fsl/Kconfig
 
  +config SOC_BUS_VF610
  +  tristate SoC bus device for the Freescale Vybrid platform
  +  depends on SOC_VF610
  +  select SOC_BUS
  +  help
  +Include support for the SoC bus on the Freescale Vybrid platform
  +providing some sysfs information about the module variant.
 
  --- /dev/null
  +++ b/drivers/soc/fsl/Makefile
 
  +obj-$(CONFIG_SOC_BUS_VF610)+= soc-vf610.o
 
  --- /dev/null
  +++ b/drivers/soc/fsl/soc-vf610.c
  @@ -0,0 +1,166 @@
  +/*
  + * Copyright 2015 Toradex AG
  + *
  + * Author: Sanchayan Maity sanchayan.ma...@toradex.com
  + *
  + * 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/mfd/syscon.h
  +#include linux/of_platform.h
  +#include linux/regmap.h
  +#include linux/random.h
  +#include linux/slab.h
  +#include linux/sys_soc.h
  +
  +#define DRIVER_NAME vf610-soc-bus
  +
  +#define MSCM_CPxCOUNT_OFFSET   0x002C
  +#define MSCM_CPxCFG1_OFFSET0x0014
  +
  +struct vf610_soc {
  +   struct device *dev;
  +   struct soc_device_attribute *soc_dev_attr;
  +   struct soc_device *soc_dev;
  +};
  +
  +static int vf610_soc_probe(struct platform_device *pdev)
  +{
  +   struct vf610_soc *info;
  +   struct regmap *ocotp_regmap, *mscm_regmap, *rom_regmap;
  +   struct device *dev = pdev-dev;
  +   struct device_node *node = pdev-dev.of_node;
  +   struct device_node *soc_node;
  +   struct of_phandle_args pargs;
  +   char soc_type[] = xx0;
  +   u32 cfg0_offset, cfg1_offset, rom_rev_offset;
  +   u32 soc_id1, soc_id2, rom_rev;
  +   u32 cpxcount, cpxcfg1;
  +   u64 soc_id;
  +   int ret;
  +
  +   info = devm_kzalloc(pdev-dev, sizeof(struct vf610_soc), GFP_KERNEL);
  +   if (!info)
  +   return -ENOMEM;
  +
  +   info-dev = pdev-dev;
  +   platform_set_drvdata(pdev, info);
  +
  +   mscm_regmap = syscon_node_to_regmap(node);
  +   if (IS_ERR(mscm_regmap)) {
  +   dev_err(dev, regmap lookup for mscm failed\n);
  +   return PTR_ERR(mscm_regmap);
  +   }
  +
  +   soc_node = of_find_node_by_path(/soc);
  +
  +   ret = of_parse_phandle_with_fixed_args(soc_node,
  +   ocotp-cfg, 2, 0, pargs);
  +   if (ret) {
  +   dev_err(dev, lookup failed for ocotp-cfg node %d\n, ret);
  +   return ret;
  +   }
  +
  +   ocotp_regmap = syscon_node_to_regmap(pargs.np);
  +   if (IS_ERR(ocotp_regmap)) {
  +   of_node_put(pargs.np);
  +   dev_err(dev, regmap lookup for ocotp failed\n);
  +   return PTR_ERR(ocotp_regmap);
  +   }
  +
  +   cfg0_offset = pargs.args[0];
  +   cfg1_offset = pargs.args[1];
  +   of_node_put(pargs.np);
  +
  +   ret = of_parse_phandle_with_fixed_args(soc_node,
  +   rom-revision, 1, 0, pargs);
  +   if (ret) {
  +   dev_err(dev, lookup failed for rom-revision node %d\n, ret);
  +   return ret;
  +   }
  +
  +   rom_regmap = syscon_node_to_regmap(pargs.np);
  +   if (IS_ERR(rom_regmap)) {
  +   of_node_put(pargs.np);
  +   dev_err(dev, regmap lookup for ocrom failed\n);
  +   return PTR_ERR(rom_regmap);
  +   }
  +
  +   rom_rev_offset = pargs.args[0];
  +   of_node_put(pargs.np);
  +
  +   ret = regmap_read(ocotp_regmap, cfg0_offset, soc_id1);
  +   if (ret)
  +   return -ENODEV;
  +
  +   ret = regmap_read(ocotp_regmap, cfg1_offset, soc_id2);
  +   if (ret)
  +   return -ENODEV;
  +
  +   soc_id = (u64) soc_id1  32 | soc_id2;
  +   add_device_randomness(soc_id, sizeof(soc_id));
  +
  +   ret = regmap_read(mscm_regmap, MSCM_CPxCOUNT_OFFSET, cpxcount);
  +   if (ret)
  +   return -ENODEV;
  +
  +   ret = regmap_read(mscm_regmap, MSCM_CPxCFG1_OFFSET, cpxcfg1);
  +   if (ret)
  +   return -ENODEV;
  +
  +   soc_type[0] = cpxcount ? '6' : '5'; /* Dual Core = VF6x0 */
  +   soc_type[1] = cpxcfg1 ? '1' : '0'; /* L2 Cache = VFx10 */
  +
  +   ret = regmap_read(rom_regmap, rom_rev_offset, rom_rev);
  +   if (ret)
  +   return -ENODEV;
  +
  +   info-soc_dev_attr = devm_kzalloc(pdev-dev,
  +   sizeof(info-soc_dev_attr), GFP_KERNEL);
  +   if (!info-soc_dev_attr)
  +   return -ENOMEM;
  +
  +   info-soc_dev_attr-machine = devm_kasprintf(pdev-dev,
  +   GFP_KERNEL, Freescale Vybrid);
  +   info-soc_dev_attr-soc_id = devm_kasprintf(pdev-dev,
  +   GFP_KERNEL, %016llx, soc_id);
  +   info-soc_dev_attr-family = devm_kasprintf(pdev-dev,
  +   GFP_KERNEL, Freescale Vybrid VF%s,
  +   soc_type);
  +   info-soc_dev_attr-revision = devm_kasprintf(pdev-dev,
  +

Re: [PATCH v5 1/2] ARM: dts: vfxxx: Add OCOTP and OCROM nodes

Hello Maxime,

On 15-06-06 13:58:33, Maxime Ripard wrote:
 Hi,
 
 On Fri, Jun 05, 2015 at 02:52:37PM +0530, Sanchayan Maity wrote:
  Add a device tree node for the On-Chip One Time Programmable
  Controller (OCOTP) and the On-Chip ROM.
  
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
  ---
   arch/arm/boot/dts/vfxxx.dtsi | 12 
   1 file changed, 12 insertions(+)
  
  diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
  index 2f4b04d..ed9b6b8 100644
  --- a/arch/arm/boot/dts/vfxxx.dtsi
  +++ b/arch/arm/boot/dts/vfxxx.dtsi
  @@ -56,6 +56,13 @@
  compatible = simple-bus;
  interrupt-parent = mscm_ir;
  ranges;
  +   ocotp-cfg = ocotp 0x410 0x420;
  +   rom-revision = ocrom 0x80;
  +
  +   ocrom: ocrom {
  +   compatible = fsl,vf610-ocrom, syscon;
  +   reg = 0x 0x18000;
  +   };
 
 Shouldn't that use the new nvmem framework currently being discussed,
 instead of defining custom bindings?

I am aware of those nvmem framework patches by Srinivas, however from what
I can see that framework has not been merged yet atleast from the mail
chain that I see for v5 of the patchset so I have not properly looked into
that. Mark Brown did apply the regmap patches to his tree, but has the rest
of the framework been merged or is it expected to be merged?

If it is expected to be merged and if that framework is a fit for what we
are trying to do here and it seems so on a quick glance, then I can go with
that. However I still did like to hear from Arnd or have some more comments
before I go for that approach with the next respin.

- Sanchayan
--
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: [RFC PATCH v6 2/2] nvmem: Add Vybrid OCOTP and OCROM support

2015-06-23 Thread maitysanchayan

Hello Srinivas,

On 15-06-23 20:03:31, Srinivas Kandagatla wrote:
 Hi Sanchayan,
 
 
 On 23/06/15 14:44, Sanchayan Maity wrote:
 The patch adds support for the On Chip One Time Programmable Peripheral
 (OCOTP) and On Chip ROM (OCROM) support.
 
 On Vybrid OCOTP contain data like SoC ID, MAC address and OCROM has the
 revision ID.
 
 Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
 ---
   drivers/nvmem/Kconfig   | 11 +
   drivers/nvmem/Makefile  |  2 ++
   drivers/nvmem/vf610-ocotp.c | 60 
  +
   3 files changed, 73 insertions(+)
   create mode 100644 drivers/nvmem/vf610-ocotp.c
 
 
 Fantastic! diff is already looking good, when compared to v5 patches,
 drivers/soc/fsl/soc-vf610.c | 166
 +++

Yes :)

 
 I think, We could even do a better job by moving qfprom and this driver to a
 simple-mmio-nvmem provider, see below comments.
 
 diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
 index 17f1a57..557c1e0 100644
 --- a/drivers/nvmem/Kconfig
 +++ b/drivers/nvmem/Kconfig
 @@ -33,4 +33,15 @@ config NVMEM_SUNXI_SID
This driver can also be built as a module. If so, the module
will be called eeprom-sunxi-sid.
 
 +config NVMEM_VF610_OCOTP
 +tristate VF610 SoCs OCOTP support
 +depends on SOC_VF610
 +select REGMAP_MMIO
 +help
 +  This is a driver for the 'OCOTP' available on various Vybrid
 +  devices.
 +
 +  This driver can also be built as a module. If so, the module
 +  will be called nvmem-vf610-ocotp.
 +
   endif
 diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
 index cc46791..a9ed113 100644
 --- a/drivers/nvmem/Makefile
 +++ b/drivers/nvmem/Makefile
 @@ -11,3 +11,5 @@ obj-$(CONFIG_QCOM_QFPROM)  += nvmem_qfprom.o
   nvmem_qfprom-y := qfprom.o
   obj-$(CONFIG_NVMEM_SUNXI_SID)  += nvmem-sunxi-sid.o
   nvmem-sunxi-sid-y  := sunxi-sid.o
 +obj-$(CONFIG_NVMEM_VF610_OCOTP) += nvmem-vf610-ocotp.o
 +nvmem-vf610-ocotp-y := vf610-ocotp.o
 diff --git a/drivers/nvmem/vf610-ocotp.c b/drivers/nvmem/vf610-ocotp.c
 new file mode 100644
 index 000..d98772d
 --- /dev/null
 +++ b/drivers/nvmem/vf610-ocotp.c
 @@ -0,0 +1,60 @@
 +/*
 + * Copyright (C) 2015 Sanchayan Maity sanchayan.ma...@toradex.com
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 and
 + * only version 2 as published by the Free Software Foundation.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + */
 +
 +#include linux/module.h
 +#include linux/of.h
 +#include nvmem-mmio.h
 +
 +static struct regmap_config regmap_config = {
 +.reg_bits = 32,
 +.val_bits = 32,
 +.reg_stride = 4,
 
 Any particular reason why it cant support byte reads?
 
 This driver looks exactly same as qcom,qfprom driver, except the
 regmap_config.

It does support byte reads. This works as well

static struct regmap_config regmap_config = {
   .reg_bits = 32,
   .val_bits = 8,
   .reg_stride = 1,
};
}

Hmm can't recall why I went with that. Yes it is more or less the
same as qcom,qfprom driver, that's what I referred.

 
 +};
 +
 +static struct nvmem_config ocotp_config = {
 +.name = soc_id,
 +};
 +
 +static struct nvmem_config rom_config = {
 +.name = rom_rev,
 +};
 +
 +static struct nvmem_mmio_data ocotp_data = {
 +.nvmem_config = ocotp_config,
 +.regmap_config = regmap_config,
 +};
 +
 +static struct nvmem_mmio_data rom_data = {
 +.nvmem_config = rom_config,
 +.regmap_config = regmap_config,
 +};
 +
 +static const struct of_device_id ocotp_of_match[] = {
 +{ .compatible = fsl,vf610-ocotp, .data = ocotp_data},
 +{ .compatible = fsl,vf610-ocrom, .data = rom_data},
 +{/* sentinel */},
 +};
 +MODULE_DEVICE_TABLE(of, ocotp_of_match);
 +
 +static struct platform_driver vf610_ocotp_driver = {
 +.probe = nvmem_mmio_probe,
 +.remove = nvmem_mmio_remove,
 +.driver = {
 +.name = vf610-nvmem,
 +.of_match_table = ocotp_of_match,
 +},
 +};
 +module_platform_driver(vf610_ocotp_driver);
 +MODULE_AUTHOR(Sanchayan Maity sanchayan.ma...@toradex.com);
 +MODULE_DESCRIPTION(Vybrid NVMEM driver);
 +MODULE_LICENSE(GPL v2);
 
 
 
 I moved the nvmem_mmio to qfprom as I did not any other user for that in v6
 patches.
 
 Now that Vybrid can be another user I should probably put it back, or may be
 I should create a simple-mmio-nvmem driver which both qcom,qfprom and Vybrid
 can use.

Nice, then that would simplify things further from what I understand at the 
moment.

- Sanchayan.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to

Re: [RFC PATCH v6 2/2] nvmem: Add Vybrid OCOTP and OCROM support

2015-06-23 Thread maitysanchayan

On 15-06-23 21:31:41, Stefan Wahren wrote:
 Hi Sanchayan,
 
  Sanchayan Maity maitysancha...@gmail.com hat am 23. Juni 2015 um 15:44
  geschrieben:
 
 
  The patch adds support for the On Chip One Time Programmable Peripheral
  (OCOTP) and On Chip ROM (OCROM) support.
 
  On Vybrid OCOTP contain data like SoC ID, MAC address and OCROM has the
  revision ID.
 
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
  ---
  drivers/nvmem/Kconfig | 11 +
  drivers/nvmem/Makefile | 2 ++
  drivers/nvmem/vf610-ocotp.c | 60 
  +
  3 files changed, 73 insertions(+)
  create mode 100644 drivers/nvmem/vf610-ocotp.c
 
  diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
  index 17f1a57..557c1e0 100644
  --- a/drivers/nvmem/Kconfig
  +++ b/drivers/nvmem/Kconfig
  @@ -33,4 +33,15 @@ config NVMEM_SUNXI_SID
  This driver can also be built as a module. If so, the module
  will be called eeprom-sunxi-sid.
 
  +config NVMEM_VF610_OCOTP
  + tristate VF610 SoCs OCOTP support
  + depends on SOC_VF610
  + select REGMAP_MMIO
 
 how do you come to the conclusion that Vybrid On-Chip OTP is accessable via
 MMIO?

Frankly speaking I just changed the naming conventions and followed the qfrom
and sunxi sid examples in Srinivas's patches.

I just tested it without the select REGMAP_MMIO and it works just fine.

- Sanchayan.
--
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: [RFC PATCH v6 2/2] nvmem: Add Vybrid OCOTP and OCROM support

2015-06-24 Thread maitysanchayan

Hello Stefan,

On 15-06-24 11:56:14, Stefan Wahren wrote:
 Hi Sanchayan,
 
 Am 24.06.2015 um 07:19 schrieb maitysancha...@gmail.com:
  On 15-06-23 21:31:41, Stefan Wahren wrote:
  Hi Sanchayan,
 
  Sanchayan Maity maitysancha...@gmail.com hat am 23. Juni 2015 um 15:44
  geschrieben:
 
 
  The patch adds support for the On Chip One Time Programmable Peripheral
  (OCOTP) and On Chip ROM (OCROM) support.
 
  On Vybrid OCOTP contain data like SoC ID, MAC address and OCROM has the
  revision ID.
 
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
  ---
  drivers/nvmem/Kconfig | 11 +
  drivers/nvmem/Makefile | 2 ++
  drivers/nvmem/vf610-ocotp.c | 60 
  +
  3 files changed, 73 insertions(+)
  create mode 100644 drivers/nvmem/vf610-ocotp.c
 
  diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
  index 17f1a57..557c1e0 100644
  --- a/drivers/nvmem/Kconfig
  +++ b/drivers/nvmem/Kconfig
  @@ -33,4 +33,15 @@ config NVMEM_SUNXI_SID
  This driver can also be built as a module. If so, the module
  will be called eeprom-sunxi-sid.
 
  +config NVMEM_VF610_OCOTP
  + tristate VF610 SoCs OCOTP support
  + depends on SOC_VF610
  + select REGMAP_MMIO
  how do you come to the conclusion that Vybrid On-Chip OTP is accessable via
  MMIO?
  Frankly speaking I just changed the naming conventions and followed the 
  qfrom
  and sunxi sid examples in Srinivas's patches.
 
  I just tested it without the select REGMAP_MMIO and it works just fine.
 
  - Sanchayan.
 
 sorry for the confusion. My question refers to the whole driver
 implementation not only to the REGMAP_MMIO.
 
 According to
 
 Vybrid Reference Manual F-Series
 Document Number: VYBRIDRM
 Rev 7, 06/2014
 
 35.5 OCOTP memory map/register definition
 
 the memory region is organized in control and shadow registers. I'm very
 sceptical that using REGMAP_MMIO is the right way for accessing the OCOTP.

Sorry I am not well versed with the regmap stuff. Can you please tell me why
REGMAP_MMIO is not the right way for accessing the OCOTP?

If this is not the right way, I assume you are referring to the procedures
in section 35.3.1.5 and 35.3.1.6 for reading and writing from these areas?

 
 It possible that it works in your case. But in the case the lock bits
 are set the driver won't work correctly.

As such the previous implementations were very different.

Currently I only expect to provide a way for users to read the SoC ID from
the OCOTP block. My understanding was even if the lock bits are set, reading
from the registers will return 0xBADABADA.

For example, currently for three locations I see this from ocotp block

*
080 bada bada bada bada bada bada bada bada
*
500 bada bada bada bada bada bada bada bada
*
c80 bada bada bada bada bada bada bada bada
*

- Sanchayan.
--
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: [RFC PATCH v6 2/2] nvmem: Add Vybrid OCOTP and OCROM support

2015-06-24 Thread maitysanchayan

Hello Stefan,

On 15-06-24 13:52:28, Stefan Wahren wrote:
Hi Srinivas,

Am 24.06.2015 um 12:45 schrieb maitysancha...@gmail.com:
Hello Stefan,

On 15-06-24 11:56:14, Stefan Wahren wrote:
Hi Sanchayan,

Am 24.06.2015 um 07:19 schrieb maitysancha...@gmail.com:
On 15-06-23 21:31:41, Stefan Wahren wrote:
Hi Sanchayan,

Sanchayan Maity maitysancha...@gmail.com hat am 23. Juni 2015 um 15:44
geschrieben:

The patch adds support for the On Chip One Time Programmable Peripheral
(OCOTP) and On Chip ROM (OCROM) support.

On Vybrid OCOTP contain data like SoC ID, MAC address and OCROM has the
revision ID.

Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
---
drivers/nvmem/Kconfig | 11 +
drivers/nvmem/Makefile | 2 ++
drivers/nvmem/vf610-ocotp.c | 60
+
3 files changed, 73 insertions(+)
create mode 100644 drivers/nvmem/vf610-ocotp.c

diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 17f1a57..557c1e0 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -33,4 +33,15 @@ config NVMEM_SUNXI_SID
This driver can also be built as a module. If so, the module
will be called eeprom-sunxi-sid.

+config NVMEM_VF610_OCOTP
+ tristate VF610 SoCs OCOTP support
+ depends on SOC_VF610
+ select REGMAP_MMIO
how do you come to the conclusion that Vybrid On-Chip OTP is accessable
via
MMIO?
Frankly speaking I just changed the naming conventions and followed the
qfrom
and sunxi sid examples in Srinivas's patches.

I just tested it without the select REGMAP_MMIO and it works just fine.

- Sanchayan.
sorry for the confusion. My question refers to the whole driver
implementation not only to the REGMAP_MMIO.

According to

Vybrid Reference Manual F-Series
Document Number: VYBRIDRM
Rev 7, 06/2014

35.5 OCOTP memory map/register definition

the memory region is organized in control and shadow registers. I'm very
sceptical that using REGMAP_MMIO is the right way for accessing the OCOTP.
Sorry I am not well versed with the regmap stuff. Can you please tell me why
REGMAP_MMIO is not the right way for accessing the OCOTP?

i think the implementation of OCOTP driver should be more like this:

https://git.linaro.org/people/srinivas.kandagatla/linux.git/commit/b4c3ad253747767511233687436f20144e850d67

It uses REGMAP with a specialized read function.

Thank you very much for the link.

If this is not the right way, I assume you are referring to the procedures
in section 35.3.1.5 and 35.3.1.6 for reading and writing from these areas?

Yes. I think writing isn't needed. But the read function should check
at least for OCOTP_CTRL[BUSY] and OCOTP_CTRL[ERROR]. If one of the
bits is set, the read function should return with an error.

Understood. Will incoporate this in the v6 patch.

This is the same behavior of my OCOTP driver for MXS platform.

Unfortunately i haven't push the driver to my github account.

It possible that it works in your case. But in the case the lock bits
are set the driver won't work correctly.
As such the previous implementations were very different.

Currently I only expect to provide a way for users to read the SoC ID from
the OCOTP block. My understanding was even if the lock bits are set, reading
from the registers will return 0xBADABADA.

For example, currently for three locations I see this from ocotp block

*
080 bada bada bada bada bada bada bada bada
*
500 bada bada bada bada bada bada bada bada
*
c80 bada bada bada bada bada bada bada bada
*

- Sanchayan.

Until somebody comes to the idea to fetch the MAC address from the OCOTP
block ...

How about doing it right at this point, instead of fixing it later?

Of course. Thanks for the feedback Stefan.

- Sanchayan.
--
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 v5 06/11] nvmem: Add bindings for simple nvmem framework

2015-06-19 Thread maitysanchayan

Hello Srinivas,

On 15-05-21 17:44:12, Srinivas Kandagatla wrote:
 This patch adds bindings for simple nvmem framework which allows nvmem
 consumers to talk to nvmem providers to get access to nvmem cell data.
 
 Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
 [Maxime Ripard: intial version of eeprom framework]
 Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
 ---
  Documentation/devicetree/bindings/nvmem/nvmem.txt | 84 
 +++
  1 file changed, 84 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/nvmem/nvmem.txt
 
 diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.txt 
 b/Documentation/devicetree/bindings/nvmem/nvmem.txt
 new file mode 100644
 index 000..ecea654
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/nvmem/nvmem.txt
 @@ -0,0 +1,84 @@
 += NVMEM Data Device Tree Bindings =
 +
 +This binding is intended to represent the location of hardware
 +configuration data stored in NVMEMs.
 +
 +On a significant proportion of boards, the manufacturer has stored
 +some data on NVMEM, for the OS to be able to retrieve these information
 +and act upon it. Obviously, the OS has to know about where to retrieve
 +these data from, and where they are stored on the storage device.
 +
 +This document is here to document this.
 +
 += Data providers =
 +Contains bindings specific to provider drivers and data cells as children
 +to this node.
 +
 +Optional properties:
 + read-only: Mark the provider as read only.
 +
 += Data cells =
 +These are the child nodes of the provider which contain data cell
 +information like offset and size in nvmem provider.
 +
 +Required properties:
 +reg: specifies the offset in byte within that storage device, start bit
 + in the byte and the length in bits of the data we care about.
 + There could be more then one offset-length pairs in this property.
 +
 +Optional properties:
 +
 +bit-offset: specifies the offset in bit within the address range specified
 + by reg property. Can take values from 0-7.
 +nbits: specifies number of bits this cell occupies starting from bit-offset.
 +
 +For example:
 +
 + /* Provider */
 + qfprom: qfprom@0070 {
 + ...
 +
 + /* Data cells */
 + tsens_calibration: calib@404 {
 + reg = 0x404 0x10;
 + };
 +
 + tsens_calibration_bckp: calib_bckp@504 {
 + reg = 0x504 0x11;
 + bit-offset = 6;
 + nbits = 128;
 + };
 +
 + pvs_version: pvs-version@6 {
 + reg = 0x6 0x2
 + bit-offset = 7;
 + nbits = 2;
 + };
 +
 + speed_bin: speed-bin@c{
 + reg = 0xc 0x1;
 + bit-offset = 2;
 + nbits   = 3;
 +
 + };
 + ...
 + };

We have a need of exposing information like SoC ID, revision and such
which is what this nvmem framework proposes to be suitable for. Till
now I was trying a different approach for the same [1].

The On Chip One Time Programmable block on the Vybrid can be handled
nicely with this nvmem framework however I had a few queries with
regards to the framework after trying it on a Vybrid VF61 SoC. 

1. From what I understand, getting the information in hex is the only
way possible as of now? Would it be possible to expose the information
as strings from different paths under /sys/class/nvmem/*/nvmem/?

For example, if I have a sub node as below

ocotp: ocotp@400a5000 {
compatible = fsl,vf610-ocotp;
reg = 0x400a5000 0x1000;

ocotp_cfg0: cfg0@410 {
reg = 0x410 0x1;
};

ocotp_cfg1: cfg1@420 {
reg = 0x420 0x1;
};
};

The values from the above register locations represented by the two
sub nodes above can perhaps be exposed as strings? Even if they are
not exposed as strings, making them available in separate paths, is
that something which can be done? So depending on the sub node as
above, /sys/class/nvmem/ocotp0/nvmem/cfg0/ would give values from
the registers specified.

Basically the output of /sys/class/nvmem/*/nvmem being restricted
to only the subnodes specified is what I was hoping to get along
with separate paths.

2. What if the required information is scattered across different memory
regions? In my case, the SoC ID is available from one OCOTP peripheral
block, the revision is in a separate ROM area at the start of the memory
map and some CPU information I am interested in is in another memory
region. I am not sure what would be the right way to approach it with
the nvmem framework.

[1] https://lkml.org/lkml/2015/6/5/189

Thanks  Regards,
Sanchayan Maity.

snip
--
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

Re: [PATCH v1 1/2] iio: adc: Determine sampling frequencies by using minimum sample time

2015-06-17 Thread maitysanchayan

Hello,

On 15-06-14 12:16:07, Jonathan Cameron wrote:
 On 08/06/15 18:51, Rob Herring wrote:
  On Mon, Jun 8, 2015 at 12:42 AM, Sanchayan Maity
  maitysancha...@gmail.com wrote:
  The driver currently does not take into account the minimum sample time
  as per the Figure 6-8 Chapter 9.1.1 12-bit ADC electrical characteristics.
  We set a static amount of cycles instead of considering the sample time as
  a given value, which depends on hardware characteristics.
 
  Determine sampling frequencies by first reading the device tree property
  node and then calculating the required Long Sample Time Adder (LSTAdder)
  value based on the ADC clock frequency and sample time value obtained
  from the device tree, this LSTAdder value is then used for calculating
  the sampling frequencies possible.
 
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
  ---
   .../devicetree/bindings/iio/adc/vf610-adc.txt  |  6 ++
   drivers/iio/adc/vf610_adc.c| 74 
  --
   2 files changed, 76 insertions(+), 4 deletions(-)
 
  diff --git a/Documentation/devicetree/bindings/iio/adc/vf610-adc.txt 
  b/Documentation/devicetree/bindings/iio/adc/vf610-adc.txt
  index 3eb40e2..4419126 100644
  --- a/Documentation/devicetree/bindings/iio/adc/vf610-adc.txt
  +++ b/Documentation/devicetree/bindings/iio/adc/vf610-adc.txt
  @@ -17,6 +17,11 @@ Recommended properties:
 - Frequency in normal mode (ADLPC=0, ADHSC=0)
 - Frequency in high-speed mode (ADLPC=0, ADHSC=1)
 - Frequency in low-power mode (ADLPC=1, ADHSC=0)
  +  - fsl,min-sample-time: Minimum sampling time in nanoseconds. This value 
  has
  
  Add a -ns' suffix.
  
  Seems like this could be a common ADC property.
 Could be but so far this is a first I think... 
 
 Obviously there are constraints on when you'll get a 'good' answer from any
 ADC but often they are not so well defined in the datasheets as we have here.
 
 Having said that, certainly could turn up elsewhere so I've no problem with
 having it as normal (non vendor specific) property.

Will change this to a non vendor specific property and send v2.

Thanks for the review.

Regards,
Sanchayan.

  
  +to be chosen according to the conversion mode and the connected analog
  +source resistance (R_as) and capacitance (C_as). Refer the 
  datasheet's
  +operating requirements. A safe default across a wide range of 
  R_as and
  +C_as as well as conversion modes is 1000ns.
 
   Example:
   adc0: adc@4003b000 {
  @@ -27,5 +32,6 @@ adc0: adc@4003b000 {
  clock-names = adc;
  fsl,adck-max-frequency = 3000, 4000,
  2000;
  +   fsl,min-sample-time = 1000;
  vref-supply = reg_vcc_3v3_mcu;
   };
  diff --git a/drivers/iio/adc/vf610_adc.c b/drivers/iio/adc/vf610_adc.c
  index 480f335..bcae8fd 100644
  --- a/drivers/iio/adc/vf610_adc.c
  +++ b/drivers/iio/adc/vf610_adc.c
  @@ -68,6 +68,9 @@
   #define VF610_ADC_CLK_DIV8 0x60
   #define VF610_ADC_CLK_MASK 0x60
   #define VF610_ADC_ADLSMP_LONG  0x10
  +#define VF610_ADC_ADSTS_SHORT   0x100
  +#define VF610_ADC_ADSTS_NORMAL  0x200
  +#define VF610_ADC_ADSTS_LONG0x300
   #define VF610_ADC_ADSTS_MASK   0x300
   #define VF610_ADC_ADLPC_EN 0x80
   #define VF610_ADC_ADHSC_EN 0x400
  @@ -124,6 +127,17 @@ enum conversion_mode_sel {
  VF610_ADC_CONV_LOW_POWER,
   };
 
  +enum lst_adder_sel {
  +   VF610_ADCK_CYCLES_3,
  +   VF610_ADCK_CYCLES_5,
  +   VF610_ADCK_CYCLES_7,
  +   VF610_ADCK_CYCLES_9,
  +   VF610_ADCK_CYCLES_13,
  +   VF610_ADCK_CYCLES_17,
  +   VF610_ADCK_CYCLES_21,
  +   VF610_ADCK_CYCLES_25,
  +};
  +
   struct vf610_adc_feature {
  enum clk_selclk_sel;
  enum vol_refvol_ref;
  @@ -132,6 +146,8 @@ struct vf610_adc_feature {
  int clk_div;
  int sample_rate;
  int res_mode;
  +   u32 lst_adder_index;
  +   u32 default_sample_time;
 
  boolcalibration;
  boolovwren;
  @@ -155,11 +171,13 @@ struct vf610_adc {
   };
 
   static const u32 vf610_hw_avgs[] = { 1, 4, 8, 16, 32 };
  +static const u32 vf610_lst_adder[] = { 3, 5, 7, 9, 13, 17, 21, 25 };
 
   static inline void vf610_adc_calculate_rates(struct vf610_adc *info)
   {
  struct vf610_adc_feature *adc_feature = info-adc_feature;
  unsigned long adck_rate, ipg_rate = clk_get_rate(info-clk);
  +   u32 adck_period, lst_addr_min;
  int divisor, i;
 
  adck_rate = info-max_adck_rate[adc_feature-conv_mode];
  @@ -174,6 +192,19 @@ static inline void vf610_adc_calculate_rates(struct 
  vf610_adc *info)
  }
 
  /*
  +* Determine the long sample time adder value to be used based
  +* on the default minimum sample time provided.
  +*/
  +   adck_period = NSEC_PER_SEC / adck_rate;
  +   lst_addr_min =

Re: [PATCH v4 2/2] soc: Add driver for Freescale Vybrid Platform

2015-05-27 Thread maitysanchayan

Hello,

On 15-05-27 09:31:50, Paul Bolle wrote:
 On Tue, 2015-05-26 at 17:06 +0530, Sanchayan Maity wrote:
  --- /dev/null
  +++ b/drivers/soc/fsl/Kconfig
 
  +config SOC_VF610
  +  bool SoC bus device for the Freescale Vybrid platform
  +  select SOC_BUS
  +  help
  +Include support for the SoC bus on the Freescale Vybrid platform
  +providing some sysfs information about the module variant.
  \ No newline at end of file
 
 (That review comment is courtesy of git.)

Will fix it.

 
  --- /dev/null
  +++ b/drivers/soc/fsl/Makefile
 
  +obj-$(CONFIG_SOC_VF610)+= soc-vf610.o
 
  --- /dev/null
  +++ b/drivers/soc/fsl/soc-vf610.c
 
  +MODULE_DEVICE_TABLE(of, vf610_soc_bus_match);
 
  +module_platform_driver(vf610_soc_driver);
 
 (The series starting at https://lkml.org/lkml/2015/5/10/131 would allow
 to use builtin_platform_driver() for built-in only code.)

Thanks for bringing this to my attention. I am subscribed to the mailing
list however this skipped me.

 
  +MODULE_DESCRIPTION(Freescale VF610 SoC bus driver);
  +MODULE_LICENSE(GPL v2);
 
 I think soc-vf610.o can only be built-in. But its code contains a few
 module specific macros. Was it perhaps intended for SOC_VF610 to be
 tristate?

I too think that should be built-in. Did not have an intention of making
it tristate, however while using other drivers as references, the perhaps
unneccessary stuff crept in.

The MODULE_* references can be removed along with the corresponding header
file. However that series has not been merged yet, so I can't use builtin_*
yet?

@Arnd

Are you ok with the patch in general? I can take care of the above changes
and send a new version. And once the builtin_driver stuff gets merged, I
can send a minor patch to change this module one to builtin?

Regards,
Sanchayan.
--
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: [RFC PATCH v6 3/3] drivers: nvmem: Add Vybrid OCOTP support

2015-07-06 Thread maitysanchayan

Hello Stefan,

On 15-07-06 12:16:34, Stefan Wahren wrote:
 Hi Sanchayan,
 
  Sanchayan Maity maitysancha...@gmail.com hat am 29. Juni 2015 um 13:22
  geschrieben:
 
 
  The patch adds support for the On Chip One Time Programmable Peripheral
  (OCOTP) on the Vybrid platform.
 
 please provide a changelog in your cover letter and a new version after 
 changes.
 
 I think it's important to note that the driver only support read-only access.

Ok. Will mention this explicitly in the next version.

 
 
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
  ---
  drivers/nvmem/Kconfig | 10 ++
  drivers/nvmem/Makefile | 2 +
  drivers/nvmem/vf610-ocotp.c | 250 
  
  3 files changed, 262 insertions(+)
  create mode 100644 drivers/nvmem/vf610-ocotp.c
 
  diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
  index 17f1a57..84c830d 100644
  --- a/drivers/nvmem/Kconfig
  +++ b/drivers/nvmem/Kconfig
  @@ -33,4 +33,14 @@ config NVMEM_SUNXI_SID
  This driver can also be built as a module. If so, the module
  will be called eeprom-sunxi-sid.
 
  +config NVMEM_VF610_OCOTP
  + tristate VF610 SoCs OCOTP support
  + depends on SOC_VF610
  + help
  + This is a driver for the 'OCOTP' available on various Vybrid
  + devices.
 
 I don't know much about Vybrid. But this driver is specific for VF610, isn't 
 it?

Sorry. I only checked on VF50 and VF61. Will check if is it available with the
other Vybrid devices and change if it is not so.

 
  +
  + This driver can also be built as a module. If so, the module
  + will be called nvmem-vf610-ocotp.
  +
  endif
  diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
  index cc46791..a9ed113 100644
  --- a/drivers/nvmem/Makefile
  +++ b/drivers/nvmem/Makefile
  @@ -11,3 +11,5 @@ obj-$(CONFIG_QCOM_QFPROM) += nvmem_qfprom.o
  nvmem_qfprom-y := qfprom.o
  obj-$(CONFIG_NVMEM_SUNXI_SID) += nvmem-sunxi-sid.o
  nvmem-sunxi-sid-y := sunxi-sid.o
  +obj-$(CONFIG_NVMEM_VF610_OCOTP) += nvmem-vf610-ocotp.o
  +nvmem-vf610-ocotp-y := vf610-ocotp.o
  diff --git a/drivers/nvmem/vf610-ocotp.c b/drivers/nvmem/vf610-ocotp.c
  new file mode 100644
  index 000..b7a782c
  --- /dev/null
  +++ b/drivers/nvmem/vf610-ocotp.c
  @@ -0,0 +1,250 @@
  +/*
  + * Copyright (C) 2015 Sanchayan Maity sanchayan.ma...@toradex.com
  + *
  + * This program is free software; you can redistribute it and/or modify
  + * it under the terms of the GNU General Public License version 2 and
  + * only version 2 as published by the Free Software Foundation.
  + *
  + * This program is distributed in the hope that it will be useful,
  + * but WITHOUT ANY WARRANTY; without even the implied warranty of
  + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
  + * GNU General Public License for more details.
  + */
  +
  +#include linux/clk.h
  +#include linux/delay.h
  +#include linux/device.h
  +#include linux/nvmem-provider.h
  +#include linux/io.h
  +#include linux/module.h
  +#include linux/of.h
  +#include linux/platform_device.h
  +#include linux/regmap.h
  +#include linux/slab.h
  +
  +/* OCOTP Register Offsets */
  +#define OCOTP_CTRL_REG 0x00
  +#define OCOTP_CTRL_SET 0x04
  +#define OCOTP_CTRL_CLR 0x08
  +#define OCOTP_TIMING 0x10
  +#define OCOTP_DATA 0x20
  +#define OCOTP_READ_CTRL_REG 0x30
  +#define OCOTP_READ_FUSE_DATA 0x40
  +
  +/* OCOTP Register bits and masks */
  +#define OCOTP_CTRL_WR_UNLOCK 16
  +#define OCOTP_CTRL_WR_UNLOCK_KEY 0x3E77
  +#define OCOTP_CTRL_WR_UNLOCK_MASK 0x
  +#define OCOTP_CTRL_ADDR 0
  +#define OCOTP_CTRL_ADDR_MASK 0x7F
  +#define OCOTP_CTRL_RELOAD_SHADOWS (0x1  10)
  +#define OCOTP_CTRL_ERROR (0x1  9)
  +#define OCOTP_CTRL_BUSY (0x1  8)
 
 You can use the BIT() macro here.

Ok.

 
  +
  +#define OCOTP_TIMING_STROBE_READ 16
  +#define OCOTP_TIMING_STROBE_READ_MASK 0x003F
  +#define OCOTP_TIMING_RELAX 12
  +#define OCOTP_TIMING_RELAX_MASK 0xF000
  +#define OCOTP_TIMING_STROBE_PROG 0
  +#define OCOTP_TIMING_STROBE_PROG_MASK 0x0FFF
  +
  +#define OCOTP_READ_CTRL_READ_FUSE 0x1
  +
  +#define VF610_OCOTP_TIMEOUT 10
  +
  +#define BF(value, field) (((value)  field)  field##_MASK)
  +
  +#define DEF_RELAX 20
  +
  +struct vf610_ocotp_dev {
  + void __iomem *base;
  + struct clk *clk;
  + struct device *dev;
  + struct resource *res;
  + struct regmap *regmap;
  + struct nvmem_device *nvmem;
  +};
 
 Some member of this struct seems unnecessary to me. Please
 remove the unused one.
 
  +
  +static int ocotp_timing;
 
 How about storing the timings in struct above?

Ok.

 
  +
  +static u8 valid_fuse_addr[] = {
  + 0x00, 0x01, 0x02, 0x04, 0x0F, 0x20, 0x21, 0x22, 0x23, 0x24,
  + 0x25, 0x26, 0x27, 0x28, 0x2F, 0x38, 0x39, 0x3A, 0x3B, 0x3C,
  + 0x3D, 0x3E, 0x3F
  +};
 
 const?

Right.

 
  +
  +static int vf610_ocotp_wait_busy(void __iomem *base)
  +{
  + int timeout = VF610_OCOTP_TIMEOUT;
  +
  + while ((readl(base)  OCOTP_CTRL_BUSY)  --timeout)
  + udelay(10);
  +
  + if (!timeout) {
  +

Re: [PATCH v3 2/2] soc: Add driver for Freescale Vybrid Platform

2015-05-25 Thread maitysanchayan

Hello Arnd,

On 15-05-22 15:20:00, Arnd Bergmann wrote:
 On Friday 22 May 2015 14:02:52 Stefan Agner wrote:
   Can you use syscon_regmap_lookup_by_phandle instead, and put the
   phandles in the fsl,vf610-mscm-cpucfg node?
  
  Hm, with that we would wire up hardware modules which does nothing has
  to do with each other. We just happen to need a driver which collects
  information accross the SoC. I'm not sure we should put the modules
  required into the device tree.
  
  I don't think its nice to have the compatible strings in the source
  code, however it feels more appropriate than in the device tree, IMHO...
 
 I see. Another option would be to point directly to the registers
 you need:
 
   ocotp-cfg0 = ocotp 0x10;
   ocotp-cfg1 = ocotp 0x20;
   rom-revision = rom 0x80;
 
 We don't yet have an abstraction to access a register from a syscon
 reference like this, but you could either roll your own here, or 
 add a generic abstraction.

Can you tell me a little about how can I start implementing it? I am not
clear on how to approach this.

 
   Also, I'd argue that the mscm should not be a syscon device at all,
   but instead I'd use platform_get_resource()/devm_ioremap_resource()
   to get an __iomem pointer.
  
  We need to have mscm-cpucfg to be syscon because we need to get the CPU
  personality in the MSCM interrupt router driver (irq-vf610-mscm-ir.c). 
 
 It can be both at the same time now.
 
   Arnd

Regards,
Sanchayan.
--
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 2/2] soc: Add driver for Freescale Vybrid Platform

2015-05-22 Thread maitysanchayan

Hello Arnd,

On 15-05-22 13:11:46, Arnd Bergmann wrote:
 On Friday 22 May 2015 16:21:54 Sanchayan Maity wrote:
  +#define OCOTP_CFG0_OFFSET  0x0410
  +#define OCOTP_CFG1_OFFSET  0x0420
  +#define MSCM_CPxCOUNT_OFFSET   0x002C
  +#define MSCM_CPxCFG1_OFFSET0x0014
  +#define ROM_REVISION_OFFSET0x0080
  +
  +static const struct of_device_id vf610_soc_bus_match[] = {
  +   { .compatible = fsl,vf610-mscm-cpucfg, },
  +   { /* sentinel */ }
  +};
  +
  +static int __init vf610_soc_init(void)
  +{
  +   struct regmap *ocotp_regmap, *mscm_regmap, *rom_regmap;
  +   struct soc_device_attribute *soc_dev_attr;
  +   struct soc_device *soc_dev;
  +   struct device_node *np;
  +   char soc_type[] = xx0;
  +   u32 cpxcount, cpxcfg1;
  +   u32 soc_id1, soc_id2, rom_rev;
  +   u64 soc_id;
  +   int ret;
  +
  +   np = of_find_matching_node(NULL, vf610_soc_bus_match);
  +   if (!np)
  +   return -ENODEV;
  +
 
 Why not use module_platform_driver() and make this a probe function instead?

Had done that but after having a look at the existing integrator and versatile
platform implementation, I changed it. Will switch to using that.

 
  +   ocotp_regmap = syscon_regmap_lookup_by_compatible(fsl,vf610-ocotp);
  +   if (IS_ERR(ocotp_regmap)) {
  +   pr_err(regmap lookup for octop failed\n);
  +   return PTR_ERR(ocotp_regmap);
  +   }
  +
  +   mscm_regmap = 
  syscon_regmap_lookup_by_compatible(fsl,vf610-mscm-cpucfg);
  +   if (IS_ERR(mscm_regmap)) {
  +   pr_err(regmap lookup for mscm failed);
  +   return PTR_ERR(mscm_regmap);
  +   }
  +
  +   rom_regmap = syscon_regmap_lookup_by_compatible(fsl,vf610-ocrom);
  +   if (IS_ERR(rom_regmap)) {
  +   pr_err(regmap lookup for ocrom failed);
  +   return PTR_ERR(rom_regmap);
  +   }
 
 Can you use syscon_regmap_lookup_by_phandle instead, and put the
 phandles in the fsl,vf610-mscm-cpucfg node?

Ok. Will do so.

- Sanchayan.

 
 Also, I'd argue that the mscm should not be a syscon device at all,
 but instead I'd use platform_get_resource()/devm_ioremap_resource()
 to get an __iomem pointer.
 
   Arnd
--
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 3/4] touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50

2015-08-03 Thread maitysanchayan

Hello Dmitry,

On 15-07-21 10:20:44, Dmitry Torokhov wrote:
 Hi Stefan,
 
 On Tue, Jul 21, 2015 at 04:43:36PM +0200, Stefan Agner wrote:
  Hi Dmitry,
  
  As the original author of the driver I have some remarks to your review
  
  On 2015-07-18 01:42, Dmitry Torokhov wrote:
   +/*
   + * If touch pressure is too low, stop measuring and 
   reenable
   + * touch detection
   + */
   +if (val_p  min_pressure || val_p  2000)
   +break;
  
  This is where the modules touch pressure is used to stop the measurement
  process and switch back to interrupt mode. See my remarks at the end.
  
   +
   +/*
   + * The pressure may not be enough for the first x and 
   the
   + * second y measurement, but, the pressure is ok when 
   the
   + * driver is doing the third and fourth measurement. To
   + * take care of this, we drop the first measurement 
   always.
   + */
   +if (discard_val_on_start) {
   +discard_val_on_start = false;
   +} else {
   +/*
   + * Report touch position and sleep for
   + * next measurement
   + */
   +input_report_abs(vf50_ts-ts_input,
   +ABS_X, VF_ADC_MAX - val_x);
   +input_report_abs(vf50_ts-ts_input,
   +ABS_Y, VF_ADC_MAX - val_y);
   +input_report_abs(vf50_ts-ts_input,
   +ABS_PRESSURE, val_p);
   +input_report_key(vf50_ts-ts_input, BTN_TOUCH, 
   1);
   +input_sync(vf50_ts-ts_input);
   +}
   +
   +msleep(10);
   +}
   +
   +/* Report no more touch, reenable touch detection */
   +input_report_abs(vf50_ts-ts_input, ABS_PRESSURE, 0);
   +input_report_key(vf50_ts-ts_input, BTN_TOUCH, 0);
   +input_sync(vf50_ts-ts_input);
   +
   +vf50_ts_enable_touch_detection(vf50_ts);
   +
   +/* Wait for the pull-up to be stable on high */
   +msleep(10);
   +
   +/* Reenable IRQ to detect touch */
   +enable_irq(vf50_ts-pen_irq);
   +
   +dev_dbg(dev, Reenabled touch detection interrupt\n);
   +}
   +
   +static irqreturn_t vf50_ts_touched(int irq, void *dev_id)
   +{
   +struct vf50_touch_device *vf50_ts = (struct vf50_touch_device 
   *)dev_id;
   +struct device *dev = vf50_ts-pdev-dev;
   +
   +dev_dbg(dev, Touch detected, start worker thread\n);
   +
   +disable_irq_nosync(irq);
   +
   +/* Disable the touch detection plates */
   +gpiod_set_value(vf50_ts-gpio_ym, 0);
   +
   +/* Let the platform mux to default state in order to mux as ADC 
   */
   +pinctrl_pm_select_default_state(dev);
   +
   +queue_work(vf50_ts-ts_workqueue, vf50_ts-ts_work);
   
   If you convert this to a threaded interrupt you won't need to
   disable/reenable interrupt or queue work. You should also be able to use
   gpiod_set_value_cansleep() extending the range of ways the controller
   could be connected to systems.
   
  
  I'm not sure if a threaded interrupt is the right thing here. While the
  pen is on the touchscreen (which can be for several seconds)
  measurements have to be made in a continuous loop. Is it ok for a
  threaded interrupt to run that long?
 
 Yes, why not? Threaded interrupt is simply a kernel thread that is woken
 when hard interrupt handler tells it to wake up. Very similar to
 interrupt + work queue, except that the kernel manages interactions
 properly for you. There are several drivers in kernel that do that, for
 example auo-pixcir-ts.c or tsc2007.c
 
  
  I'm also not sure if it is really safe to _not_ disable the pen down
  GPIO interrupt. If we get a interrupt while measuring, we should ignore
  that interrupt.
 
 The interrupt management core (you'll have to annotate it as
 IRQF_ONESHOT) will make sure it stays masked properly until the threaded
 handler completes so you do not need to disable it explicitly.

After working some more on threaded irq implementation, if IRQ_ONESHOT
flag is used while requesting threaded irq, on entering the IRQ handler
the vf610_gpio_irq_mask is not called and vf610_gpio_irq_unmask is not
called on exiting the thread function, not something we expected.

In contrast, using explicit disable_irq_nosync and enable_irq in the IRQ
handler and thread respectively results in the respective mask and unmask
function being called.

The vf610_gpio_irq_*mask functions are in the gpio driver for Vybrid in
drivers/gpio/gpio-vf610.c.

Can you point me in the right direction?

Thanks  Regards,

Re: [PATCH v2] iio: adc: vf610: Add IIO buffer support for Vybrid ADC

2015-08-08 Thread maitysanchayan

Hello Jonathan,

On 15-08-08 15:29:47, Jonathan Cameron wrote:
 On 05/08/15 13:10, Sanchayan Maity wrote:
  This patch adds support for IIO buffer to the Vybrid ADC driver.
  IIO triggered buffer infrastructure along with iio sysfs trigger
  is used to leverage continuous sampling support provided by the
  ADC block.
 Looking good.  Just a couple more bits and pieces inline from me.
 One or two of which aren't corrected from Peter's review of v1.
 
 I will want Fugang Dong's ack / review tag on the final version
 before applying it however.

Sure.

 This driver is some distance form my area of expertise!

I doubt :).

 
 Jonathan
  
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
  ---
   drivers/iio/adc/Kconfig |   4 ++
   drivers/iio/adc/vf610_adc.c | 107 
  +---
   2 files changed, 105 insertions(+), 6 deletions(-)
  
  diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
  index 7c55658..4661241 100644
  --- a/drivers/iio/adc/Kconfig
  +++ b/drivers/iio/adc/Kconfig
  @@ -337,6 +337,10 @@ config TWL6030_GPADC
   config VF610_ADC
  tristate Freescale vf610 ADC driver
  depends on OF
  +   select IIO_BUFFER
  +   select IIO_TRIGGER
  +   select IIO_SYSFS_TRIGGER
 Unless I missed something there is no dependency on this particular
 trigger (it just happens to be the one you've been testing with I guess).
 Could be driven from a hardware trigger belonging to another device for
 example.

Yes right in a way. Right now we do not provide or there is no provision
for hardware triggers. On the Vybrid, the Peripheral Delay Block (PDB)
does the job of providing support for software and hardware triggers. PDB
support is not yet there in Linux however. 

There is also the question of where the Vybrid PDB driver would belong
to? In the TRM it is put in the timers but the kernel has no generic timer
framework that I am aware of. After some internal reviews we decided to
do a platform driver which provided functions ADC driver could called into.

I have a patchset ready which provides trigger support using PDB however
configuring the PDB properly has proven to be tricky. While it works but
not reliably with multiple channels and it would be a while before I get
that working and post that patchset. So kind of stalled there and just
because of two registers which need to be written with the correct value
:). For what it's worth if someone comes across this, some discussion
here [1] along with patches. (Note however those are a bit old patches
not exactly my new work).

Sorry for digressing from the topic. Anyways so the idea was to provide
sysfs triggers as default for using this continuous sampling. Later the
driver may provide additional triggers. So for now I added the sysfs
trigger as a select option so that a user won't have to recompile the
kernel for using the buffers with continuous sampling.

 
  +   select IIO_TRIGGERED_BUFFER
  help
Say yes here to support for Vybrid board analog-to-digital converter.
Since the IP is used for i.MX6SLX, the driver also support i.MX6SLX.
  diff --git a/drivers/iio/adc/vf610_adc.c b/drivers/iio/adc/vf610_adc.c
  index 23b8fb9..97cb2ed 100644
  --- a/drivers/iio/adc/vf610_adc.c
  +++ b/drivers/iio/adc/vf610_adc.c
  @@ -34,8 +34,11 @@
   #include linux/err.h
   
   #include linux/iio/iio.h
  +#include linux/iio/buffer.h
   #include linux/iio/sysfs.h
  -#include linux/iio/driver.h
  +#include linux/iio/trigger.h
  +#include linux/iio/trigger_consumer.h
  +#include linux/iio/triggered_buffer.h
   
   /* This will be the driver name the kernel reports */
   #define DRIVER_NAME vf610-adc
  @@ -170,6 +173,7 @@ struct vf610_adc {
  u32 sample_freq_avail[5];
   
  struct completion completion;
  +   u16 buffer[2];
 Note the requirements on the buffer provided to
 iio_push_to_buffers_with_timestamp
 Needs to be u16 buffer[8] to allow for the aligned 64bit (4 word) timestamp.
 
 Peter pointed this out in his follow up email and you said you'd implement
 it.. Guessing this got lost somewhere.

No, I meant to implement what Peter recommended but I guess I did not completely
grasp what he intended. Sorry about that. Will fix this and ask further if in
more doubts.

 
 
   };
   
   static const u32 vf610_hw_avgs[] = { 1, 4, 8, 16, 32 };
  @@ -505,12 +509,22 @@ static const struct iio_chan_spec_ext_info 
  vf610_ext_info[] = {
  .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) |  \
  BIT(IIO_CHAN_INFO_SAMP_FREQ),   \
  .ext_info = vf610_ext_info, \
  +   .address = (_idx),  \
  +   .scan_index = (_idx),   \
  +   .scan_type.sign = 'u',  \
  +   .scan_type.realbits = 12,   \
  +   .scan_type.storagebits = 16,\
   }
   
   #define VF610_ADC_TEMPERATURE_CHAN(_idx, _chan_type) { \
  .type = (_chan_type),   \
  .channel = (_idx),  \

Re: [PATCH v3 0/3] Add support for touchscreen on Colibri VF50

2015-08-13 Thread maitysanchayan

Hello,

Ping?

- Sanchayan.

On 15-08-05 14:25:48, Sanchayan Maity wrote:
 Hello,
 
 The patchset adds support for 4 wire touchscreen on Toradex Colibri
 VF50 modules. Patches are tested on top of shawn's for-next branch.
 
 Changes since v2:
 1. Fix pin multiplexing for pins in idle state. Configuration of the
 pen detect pull up viz. PTA19__GPIO_9 resulted in generation of pen
 irq's on a continuous basis.
 2. Fix pinmux of the ADC pins as per the recommended pinmux in TRM.
 3. Use a threaded irq handler instead of a irq handler plus workqueue
 approach.
 4. Use a low level trigger with oneshot flag specifier instead of the
 previous falling edge triggered irq's. This coupled with the fix in
 point 1 fixes the previous continuous spurious irq generation bug.
 5. Change/fix the TS measurement logic to account for the fact that
 iio_channel_read_raw might actually return an error. To be more
 specific use break instead of continue and take care to close the
 FET's in case of channel read error.
 6. Drop the first patch Add io-channel-cells property for ADC node
 as it has already been applied.
 7. Move the iio channel get call again at the start. Having it in
 the end resulted in crashes sometimes when iio was not probed and
 the ts device got probed and opened earlier.
 
 Changes since v1:
 1. Fix/drop comments
 2. Use an inline function for multiple gpiod_get calls in probe
 3. Remove the pull up in the pinmux specified in DT for touchctrl_gpios
 4. Add the io-channel-cells property before status property.
 5. Add GPIOLIB as dependency in the Kconfig file
 
 Version 2 of the patchset can be found here
 https://www.mail-archive.com/linux-input@vger.kernel.org/msg18090.html
 
 Version 1 of the patchset can be found here
 https://lkml.org/lkml/2015/6/30/103
 
 Thank you very much for the feedback till now.
 
 Regards,
 Sanchayan.
 
 Sanchayan Maity (3):
   ARM: dts: vf500-colibri: Add device tree node for touchscreen support
   input: Add DT binding documentation for Colibri VF50 touchscreen
   touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50
 
  .../bindings/input/touchscreen/colibri-vf50-ts.txt |  32 ++
  arch/arm/boot/dts/vf500-colibri-eval-v3.dts|   4 +
  arch/arm/boot/dts/vf500-colibri.dtsi   |  45 +++
  drivers/input/touchscreen/Kconfig  |  12 +
  drivers/input/touchscreen/Makefile |   1 +
  drivers/input/touchscreen/colibri-vf50-ts.c| 404 
 +
  6 files changed, 498 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt
  create mode 100644 drivers/input/touchscreen/colibri-vf50-ts.c
 
 -- 
 2.5.0
 
--
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] iio: adc: vf610: Add IIO buffer support for Vybrid ADC

2015-08-17 Thread maitysanchayan

Hello Jonathan,

On 15-08-15 21:24:01, Jonathan Cameron wrote:
 On 11/08/15 10:05, Sanchayan Maity wrote:
  This patch adds support for IIO buffer to the Vybrid ADC driver.
  IIO triggered buffer infrastructure along with iio sysfs trigger
  is used to leverage continuous sampling support provided by the
  ADC block.
  
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
 Hi Sanchayan,
 
 Very nearly there. One little point to do with the buffer handling.
 Basically I don't think you want anything in the preenable or
 postdisable hooks, just in the 'internal' ones.
 
 Jonathan
  ---
   drivers/iio/adc/Kconfig |   2 +
   drivers/iio/adc/vf610_adc.c | 102 
  +---
   2 files changed, 97 insertions(+), 7 deletions(-)
  
  diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
  index 7c55658..660f790 100644
  --- a/drivers/iio/adc/Kconfig
  +++ b/drivers/iio/adc/Kconfig
  @@ -337,6 +337,8 @@ config TWL6030_GPADC
   config VF610_ADC
  tristate Freescale vf610 ADC driver
  depends on OF
  +   select IIO_BUFFER
  +   select IIO_TRIGGERED_BUFFER
  help
Say yes here to support for Vybrid board analog-to-digital converter.
Since the IP is used for i.MX6SLX, the driver also support i.MX6SLX.
  diff --git a/drivers/iio/adc/vf610_adc.c b/drivers/iio/adc/vf610_adc.c
  index 23b8fb9..de62c48 100644
  --- a/drivers/iio/adc/vf610_adc.c
  +++ b/drivers/iio/adc/vf610_adc.c
  @@ -34,8 +34,11 @@
   #include linux/err.h
   
   #include linux/iio/iio.h
  +#include linux/iio/buffer.h
   #include linux/iio/sysfs.h
  -#include linux/iio/driver.h
  +#include linux/iio/trigger.h
  +#include linux/iio/trigger_consumer.h
  +#include linux/iio/triggered_buffer.h
   
   /* This will be the driver name the kernel reports */
   #define DRIVER_NAME vf610-adc
  @@ -170,6 +173,7 @@ struct vf610_adc {
  u32 sample_freq_avail[5];
   
  struct completion completion;
  +   u16 buffer[8];
   };
   
   static const u32 vf610_hw_avgs[] = { 1, 4, 8, 16, 32 };
  @@ -505,12 +509,24 @@ static const struct iio_chan_spec_ext_info 
  vf610_ext_info[] = {
  .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) |  \
  BIT(IIO_CHAN_INFO_SAMP_FREQ),   \
  .ext_info = vf610_ext_info, \
  +   .scan_index = (_idx),   \
  +   .scan_type = {  \
  +   .sign = 'u',\
  +   .realbits = 12, \
  +   .storagebits = 16,  \
  +   },  \
   }
   
   #define VF610_ADC_TEMPERATURE_CHAN(_idx, _chan_type) { \
  .type = (_chan_type),   \
  .channel = (_idx),  \
  .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED), \
  +   .scan_index = (_idx),   \
  +   .scan_type = {  \
  +   .sign = 'u',\
  +   .realbits = 12, \
  +   .storagebits = 16,  \
  +   },  \
   }
   
   static const struct iio_chan_spec vf610_adc_iio_channels[] = {
  @@ -531,6 +547,7 @@ static const struct iio_chan_spec 
  vf610_adc_iio_channels[] = {
  VF610_ADC_CHAN(14, IIO_VOLTAGE),
  VF610_ADC_CHAN(15, IIO_VOLTAGE),
  VF610_ADC_TEMPERATURE_CHAN(26, IIO_TEMP),
  +   IIO_CHAN_SOFT_TIMESTAMP(32),
  /* sentinel */
   };
   
  @@ -559,13 +576,20 @@ static int vf610_adc_read_data(struct vf610_adc *info)
   
   static irqreturn_t vf610_adc_isr(int irq, void *dev_id)
   {
  -   struct vf610_adc *info = (struct vf610_adc *)dev_id;
  +   struct iio_dev *indio_dev = (struct iio_dev *)dev_id;
  +   struct vf610_adc *info = iio_priv(indio_dev);
  int coco;
   
  coco = readl(info-regs + VF610_REG_ADC_HS);
  if (coco  VF610_ADC_HS_COCO0) {
  info-value = vf610_adc_read_data(info);
  -   complete(info-completion);
  +   if (iio_buffer_enabled(indio_dev)) {
  +   info-buffer[0] = info-value;
  +   iio_push_to_buffers_with_timestamp(indio_dev,
  +   info-buffer, iio_get_time_ns());
  +   iio_trigger_notify_done(indio_dev-trig);
  +   } else
  +   complete(info-completion);
  }
   
  return IRQ_HANDLED;
  @@ -613,8 +637,12 @@ static int vf610_read_raw(struct iio_dev *indio_dev,
  case IIO_CHAN_INFO_RAW:
  case IIO_CHAN_INFO_PROCESSED:
  mutex_lock(indio_dev-mlock);
  -   reinit_completion(info-completion);
  +   if (iio_buffer_enabled(indio_dev)) {
  +   mutex_unlock(indio_dev-mlock);
  +   return -EBUSY;
  +   }
   
  +   reinit_completion(info-completion);

Re: [PATCH] ARM: dts: vfxxx: Add iio_hwmon node for ADC temperature channel

2015-08-21 Thread maitysanchayan

Ping?

- Sanchayan.

On 15-08-06 21:28:22, Sanchayan Maity wrote:
 Add iio_hwmon node to expose the temperature channel on Vybrid
 as hardware monitor device using the iio_hwmon driver.
 
 Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
 ---
  arch/arm/boot/dts/vfxxx.dtsi | 5 +
  1 file changed, 5 insertions(+)
 
 diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
 index 39173bb..0993d66 100644
 --- a/arch/arm/boot/dts/vfxxx.dtsi
 +++ b/arch/arm/boot/dts/vfxxx.dtsi
 @@ -597,5 +597,10 @@
   status = disabled;
   };
   };
 +
 + iio_hwmon {
 + compatible = iio-hwmon;
 + io-channels = adc0 16;
 + };
   };
  };
 -- 
 2.5.0
 
--
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 2/3] input: Add DT binding documentation for Colibri VF50 touchscreen

On 15-08-22 18:36:54, Stefan Agner wrote:
 On 2015-08-21 06:26, Sanchayan Maity wrote:
  This adds device tree binding documentation for the Colibri VF50
  touchscreen driver.
  
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
  ---
   .../bindings/input/touchscreen/colibri-vf50-ts.txt | 36 
  ++
   1 file changed, 36 insertions(+)
   create mode 100644
  Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt
  
  diff --git
  a/Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt
  b/Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt
  new file mode 100644
  index 000..e615aa9
  --- /dev/null
  +++ 
  b/Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt
  @@ -0,0 +1,36 @@
  +* Toradex Colibri VF50 Touchscreen driver
  +
  +Required Properties:
  +- compatible must be toradex,vf50-touchscreen
  +- io-channels: adc channels being used by the Colibri VF50 module
  +- xp-gpios: FET gate driver for input of X+
  +- xm-gpios: FET gate driver for input of X-
  +- yp-gpios: FET gate driver for input of Y+
  +- ym-gpios: FET gate driver for input of Y-
  +- interrupt-parent: phandle for the interrupt controller
  +- interrupts: pen irq interrupt for touch detection
 
 I like the use of the interrupt interface for the touch detection pin.
 Maybe you can mention here that this is (typically) a GPIO...
 
  +- pinctrl-names: idle, default, gpios
  +- pinctrl-0: pinctrl node for idle state gpio pinmux
  +- pinctrl-1: pinctrl node for touch detection state pinmux
 
 touch detection for default is rather confusing or even wrong. The
 Idle state is used for pen/touch detection, default is used for X/Y and
 Pressure measurement (maybe better described as touch measurement).

Ok. Understood. I see how my wordings can create confusion or are
misleading. Will fix.

- Sanchayan.

 
  +- pinctrl-2: pinctrl node for gpios functioning as FET gate drivers
  +- vf50-ts-min-pressure: pressure level at which to stop measuring X/Y 
  values
  +
  +Example:
  +
  +   touchctrl: vf50_touchctrl {
  +   compatible = toradex,vf50-touchscreen;
  +   io-channels = adc1 0,adc0 0,
  +   adc0 1,adc1 2;
  +   xp-gpios = gpio0 13 GPIO_ACTIVE_LOW;
  +   xm-gpios = gpio2 29 GPIO_ACTIVE_HIGH;
  +   yp-gpios = gpio0 12 GPIO_ACTIVE_LOW;
  +   ym-gpios = gpio0 4 GPIO_ACTIVE_HIGH;
  +   interrupt-parent = gpio0;
  +   interrupts = 8 IRQ_TYPE_LEVEL_LOW;
  +   pinctrl-names = idle,default,gpios;
  +   pinctrl-0 = pinctrl_touchctrl_idle;
  +   pinctrl-1 = pinctrl_touchctrl_default;
  +   pinctrl-2 = pinctrl_touchctrl_gpios;
  +   vf50-ts-min-pressure = 200;
  +   status = disabled;
  +   };
 
 Otherwise I agree with 1 and 2:
 
 Acked-by: Stefan Agner ste...@agner.ch
 
 --
 Stefan
 
--
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/3] ARM: dts: vf500-colibri: Add device tree node for touchscreen support

On 15-08-22 18:54:28, Stefan Agner wrote:
 On 2015-08-21 06:26, Sanchayan Maity wrote:
  Add device tree node for touchscreen support on Colibri VF50. The
  touchscreen functionality on VF50 uses the ADC channels of Vybrid
  and some GPIOs. Also add pinctrl nodes for proper pinmux.
  
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
  ---
   arch/arm/boot/dts/vf500-colibri-eval-v3.dts |  4 +++
   arch/arm/boot/dts/vf500-colibri.dtsi| 47 
  +
   2 files changed, 51 insertions(+)
  
  diff --git a/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
  b/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
  index 7fc782c..14c0b00 100644
  --- a/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
  +++ b/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
  @@ -15,3 +15,7 @@
  model = Toradex Colibri VF50 on Colibri Evaluation Board;
  compatible = toradex,vf500-colibri_vf50-on-eval,
  toradex,vf500-colibri_vf50, fsl,vf500;
   };
  +
  +touchscreen {
  +   status = okay;
  +};
  diff --git a/arch/arm/boot/dts/vf500-colibri.dtsi
  b/arch/arm/boot/dts/vf500-colibri.dtsi
  index cee34a3..84f091d 100644
  --- a/arch/arm/boot/dts/vf500-colibri.dtsi
  +++ b/arch/arm/boot/dts/vf500-colibri.dtsi
  @@ -17,4 +17,51 @@
  memory {
  reg = 0x8000 0x800;
  };
  +
  +   touchscreen: vf50-touchscreen {
  +   compatible = toradex,vf50-touchscreen;
  +   io-channels = adc1 0,adc0 0,
  +   adc0 1,adc1 2;
  +   xp-gpios = gpio0 13 GPIO_ACTIVE_LOW;
  +   xm-gpios = gpio2 29 GPIO_ACTIVE_HIGH;
  +   yp-gpios = gpio0 12 GPIO_ACTIVE_LOW;
  +   ym-gpios = gpio0 4 GPIO_ACTIVE_HIGH;
  +   interrupt-parent = gpio0;
  +   interrupts = 8 IRQ_TYPE_LEVEL_LOW;
  +   pinctrl-names = idle,default,gpios;
  +   pinctrl-0 = pinctrl_touchctrl_idle;
  +   pinctrl-1 = pinctrl_touchctrl_default;
  +   pinctrl-2 = pinctrl_touchctrl_gpios;
  +   vf50-ts-min-pressure = 200;
 
 Since this is a touch screen related property, we even would want to
 have that in the board specific device-tree (vf500-colibri-eval-v3.dts).

So the same property specified again in vf500-colibri-eval-v3.dts? Ok will
include the same.

- Sanchayan.
--
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/3] touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50

On 15-08-22 18:52:28, Stefan Agner wrote:
 Hi Sanchayan,
 
 On 2015-08-21 06:26, Sanchayan Maity wrote:
  +static int vf50_ts_probe(struct platform_device *pdev)
  +{
  +   struct input_dev *input;
  +   struct iio_channel *channels;
  +   struct device *dev = pdev-dev;
  +   struct vf50_touch_device *touchdev;
  +   int error;
  +
  +   channels = iio_channel_get_all(dev);
  +   if (IS_ERR(channels))
  +   return PTR_ERR(channels);
 
 Hm, we expect here that four channels are returned, however a faulty
 device tree could contain less. Access to the fourth channel above would
 lead to a bug.
 
 Can you check the amount of channels returned? The returned list is
 explicitly terminated with a null entry, you can rely on that. Something
 similar to hwmon should do the job.
 http://lxr.free-electrons.com/source/drivers/hwmon/iio_hwmon.c#L86

I agree. It did be nice to have this error check. Thanks. I will add
this check so we can bail out if less channels are specified.

- Sanchayan.

 
 
 Otherwise, Acked-by: Stefan Agner ste...@agner.ch
 
 --
 Stefan
--
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] iio: adc: vf610: Add IIO buffer support for Vybrid ADC

2015-08-20 Thread maitysanchayan

Hello Fugang Duan,

Can I have your ACK if you are ok with the changes made by the
patch?

Thanks  Regards,
Sanchayan Maity.

On 15-08-17 21:21:40, Sanchayan Maity wrote:
 This patch adds support for IIO buffer to the Vybrid ADC driver.
 IIO triggered buffer infrastructure along with iio sysfs trigger
 is used to leverage continuous sampling support provided by the
 ADC block.
 
 Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
 ---
 
 Changes since v3:
 Fix iio_buffer_setup_ops for postenable and predisable functions
 to match pairwise. Before this the predisable work was being done
 in postdisable.
 
 Changes since v2:
 1. Fix the wrong buffer size for statically allocated buffer
 2. Drop the use of .address field from the iio_chan_spec
 3. Use iio_buffer_enabled call inside the lock
 4. Drop wrapper function around iio_trigered_* function calls
 5. Drop Kconfig select of sysfs trigger
 6. Drop Kconfig select IIO_TRIGGER as it is already selected by
 IIO_TRIGGERED_BUFFER
 
 Changes since v1:
 1. Use a fixed size buffer instead of kmalloc allocated during update
 scan mode
 2. Remove a write to read only register ADC_HS (COCO bit)
 
  drivers/iio/adc/Kconfig |   2 +
  drivers/iio/adc/vf610_adc.c | 105 
 +---
  2 files changed, 100 insertions(+), 7 deletions(-)
 
 diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
 index 7c55658..660f790 100644
 --- a/drivers/iio/adc/Kconfig
 +++ b/drivers/iio/adc/Kconfig
 @@ -337,6 +337,8 @@ config TWL6030_GPADC
  config VF610_ADC
   tristate Freescale vf610 ADC driver
   depends on OF
 + select IIO_BUFFER
 + select IIO_TRIGGERED_BUFFER
   help
 Say yes here to support for Vybrid board analog-to-digital converter.
 Since the IP is used for i.MX6SLX, the driver also support i.MX6SLX.
 diff --git a/drivers/iio/adc/vf610_adc.c b/drivers/iio/adc/vf610_adc.c
 index 23b8fb9..887a7ba 100644
 --- a/drivers/iio/adc/vf610_adc.c
 +++ b/drivers/iio/adc/vf610_adc.c
 @@ -34,8 +34,11 @@
  #include linux/err.h
  
  #include linux/iio/iio.h
 +#include linux/iio/buffer.h
  #include linux/iio/sysfs.h
 -#include linux/iio/driver.h
 +#include linux/iio/trigger.h
 +#include linux/iio/trigger_consumer.h
 +#include linux/iio/triggered_buffer.h
  
  /* This will be the driver name the kernel reports */
  #define DRIVER_NAME vf610-adc
 @@ -170,6 +173,7 @@ struct vf610_adc {
   u32 sample_freq_avail[5];
  
   struct completion completion;
 + u16 buffer[8];
  };
  
  static const u32 vf610_hw_avgs[] = { 1, 4, 8, 16, 32 };
 @@ -505,12 +509,24 @@ static const struct iio_chan_spec_ext_info 
 vf610_ext_info[] = {
   .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) |  \
   BIT(IIO_CHAN_INFO_SAMP_FREQ),   \
   .ext_info = vf610_ext_info, \
 + .scan_index = (_idx),   \
 + .scan_type = {  \
 + .sign = 'u',\
 + .realbits = 12, \
 + .storagebits = 16,  \
 + },  \
  }
  
  #define VF610_ADC_TEMPERATURE_CHAN(_idx, _chan_type) {   \
   .type = (_chan_type),   \
   .channel = (_idx),  \
   .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED), \
 + .scan_index = (_idx),   \
 + .scan_type = {  \
 + .sign = 'u',\
 + .realbits = 12, \
 + .storagebits = 16,  \
 + },  \
  }
  
  static const struct iio_chan_spec vf610_adc_iio_channels[] = {
 @@ -531,6 +547,7 @@ static const struct iio_chan_spec 
 vf610_adc_iio_channels[] = {
   VF610_ADC_CHAN(14, IIO_VOLTAGE),
   VF610_ADC_CHAN(15, IIO_VOLTAGE),
   VF610_ADC_TEMPERATURE_CHAN(26, IIO_TEMP),
 + IIO_CHAN_SOFT_TIMESTAMP(32),
   /* sentinel */
  };
  
 @@ -559,13 +576,20 @@ static int vf610_adc_read_data(struct vf610_adc *info)
  
  static irqreturn_t vf610_adc_isr(int irq, void *dev_id)
  {
 - struct vf610_adc *info = (struct vf610_adc *)dev_id;
 + struct iio_dev *indio_dev = (struct iio_dev *)dev_id;
 + struct vf610_adc *info = iio_priv(indio_dev);
   int coco;
  
   coco = readl(info-regs + VF610_REG_ADC_HS);
   if (coco  VF610_ADC_HS_COCO0) {
   info-value = vf610_adc_read_data(info);
 - complete(info-completion);
 + if (iio_buffer_enabled(indio_dev)) {
 + info-buffer[0] = info-value;
 + iio_push_to_buffers_with_timestamp(indio_dev,
 + info-buffer, iio_get_time_ns());
 + iio_trigger_notify_done(indio_dev-trig);
 +

Re: [PATCH v3 3/3] touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50

2015-08-19 Thread maitysanchayan

Hello Dmitry,

Will take care of all points with the next revision.

Thank you for the feedback.

- Sanchayan.

On 15-08-14 15:53:46, Dmitry Torokhov wrote:
 Hi Sanchayan,
 
 On Wed, Aug 05, 2015 at 02:25:51PM +0530, Sanchayan Maity wrote:
  The Colibri Vybrid VF50 module supports 4-wire touchscreens using
  FETs and ADC inputs. This driver uses the IIO consumer interface
  and relies on the vf610_adc driver based on the IIO framework.
  
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
  ---
   drivers/input/touchscreen/Kconfig   |  12 +
   drivers/input/touchscreen/Makefile  |   1 +
   drivers/input/touchscreen/colibri-vf50-ts.c | 404 
  
   3 files changed, 417 insertions(+)
   create mode 100644 drivers/input/touchscreen/colibri-vf50-ts.c
  
  diff --git a/drivers/input/touchscreen/Kconfig 
  b/drivers/input/touchscreen/Kconfig
  index 80f6386..28948ca 100644
  --- a/drivers/input/touchscreen/Kconfig
  +++ b/drivers/input/touchscreen/Kconfig
  @@ -1027,4 +1027,16 @@ config TOUCHSCREEN_ZFORCE
To compile this driver as a module, choose M here: the
module will be called zforce_ts.
   
  +config TOUCHSCREEN_COLIBRI_VF50
  +   tristate Toradex Colibri on board touchscreen driver
  +   depends on GPIOLIB  IIO  VF610_ADC
  +   help
  + Say Y here if you have a Colibri VF50 and plan to use
  + the on-board provided 4-wire touchscreen driver.
  +
  + If unsure, say N.
  +
  + To compile this driver as a module, choose M here: the
  + module will be called colibri_vf50_ts.
  +
   endif
  diff --git a/drivers/input/touchscreen/Makefile 
  b/drivers/input/touchscreen/Makefile
  index 44deea7..93746a0 100644
  --- a/drivers/input/touchscreen/Makefile
  +++ b/drivers/input/touchscreen/Makefile
  @@ -84,3 +84,4 @@ obj-$(CONFIG_TOUCHSCREEN_W90X900) += w90p910_ts.o
   obj-$(CONFIG_TOUCHSCREEN_SX8654)   += sx8654.o
   obj-$(CONFIG_TOUCHSCREEN_TPS6507X) += tps6507x-ts.o
   obj-$(CONFIG_TOUCHSCREEN_ZFORCE)   += zforce_ts.o
  +obj-$(CONFIG_TOUCHSCREEN_COLIBRI_VF50) += colibri-vf50-ts.o
  diff --git a/drivers/input/touchscreen/colibri-vf50-ts.c 
  b/drivers/input/touchscreen/colibri-vf50-ts.c
  new file mode 100644
  index 000..d7bc91a
  --- /dev/null
  +++ b/drivers/input/touchscreen/colibri-vf50-ts.c
  @@ -0,0 +1,404 @@
  +/* Copyright 2015 Toradex AG
  + *
  + * Toradex Colibri VF50 Touchscreen driver
  + *
  + * Originally authored by Stefan Agner for 3.0 kernel
  + *
  + * 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/err.h
  +#include linux/gpio.h
  +#include linux/iio/consumer.h
  +#include linux/iio/types.h
  +#include linux/input.h
  +#include linux/interrupt.h
  +#include linux/kernel.h
  +#include linux/module.h
  +#include linux/pinctrl/consumer.h
  +#include linux/platform_device.h
  +#include linux/slab.h
  +#include linux/types.h
  +
  +#define DRIVER_NAME colibri-vf50-ts
  +#define DRV_VERSION 1.0
  +
  +#define VF_ADC_MAX ((1  12) - 1)
  +
  +#define COLI_TOUCH_MIN_DELAY_US 1000
  +#define COLI_TOUCH_MAX_DELAY_US 2000
  +
  +static int min_pressure = 200;
  +
  +struct vf50_touch_device {
  +   struct platform_device  *pdev;
  +   struct input_dev*ts_input;
  +   struct iio_channel  *channels;
  +   struct gpio_desc *gpio_xp;
  +   struct gpio_desc *gpio_xm;
  +   struct gpio_desc *gpio_yp;
  +   struct gpio_desc *gpio_ym;
  +   struct gpio_desc *gpio_pen_detect;
  +   int pen_irq;
  +   bool stop_touchscreen;
  +};
  +
  +/*
  + * Enables given plates and measures touch parameters using ADC
  + */
  +static int adc_ts_measure(struct iio_channel *channel,
  + struct gpio_desc *plate_p, struct gpio_desc *plate_m)
  +{
  +   int i, value = 0, val = 0;
  +   int ret;
  +
  +   gpiod_set_value(plate_p, 1);
  +   gpiod_set_value(plate_m, 1);
  +
  +   usleep_range(COLI_TOUCH_MIN_DELAY_US, COLI_TOUCH_MAX_DELAY_US);
  +
  +   for (i = 0; i  5; i++) {
 
 Can we have a #define for 5?
 
  +   ret = iio_read_channel_raw(channel, val);
  +   if (ret  0) {
  +   value = ret;
  +   goto error_iio_read;
  +   }
  +
  +   value += val;
  +   }
  +
  +   value /= 5;
  +
  +error_iio_read:
  +   gpiod_set_value(plate_p, 0);
  +   gpiod_set_value(plate_m, 0);
  +
  +   return value;
  +}
  +
  +/*
  + * Enable touch detection using falling edge detection on XM
  + */
  +static void vf50_ts_enable_touch_detection(struct vf50_touch_device 
  *vf50_ts)
  +{
  +   /* Enable plate YM (needs to be strong GND, high active) */
  +   gpiod_set_value(vf50_ts-gpio_ym, 1);
  +
  +   /*
  +* Let the platform mux to idle state in order to enable
  +* Pull-Up on GPIO
  +*/
  +

Re: [PATCH v4 3/3] touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50

Hello Dmitry,

On 15-08-21 18:30:57, Dmitry Torokhov wrote:
 Hi Sanchayan,
 
 On Fri, Aug 21, 2015 at 06:56:32PM +0530, Sanchayan Maity wrote:
  The Colibri Vybrid VF50 module supports 4-wire touchscreens using
  FETs and ADC inputs. This driver uses the IIO consumer interface
  and relies on the vf610_adc driver based on the IIO framework.
  
 
 Thank you for making changes. I have a few comments still.

It has really improved with your comments. Thanks for your feedback.

 
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
  ---
   drivers/input/touchscreen/Kconfig   |  12 +
   drivers/input/touchscreen/Makefile  |   1 +
   drivers/input/touchscreen/colibri-vf50-ts.c | 370 
  
   3 files changed, 383 insertions(+)
   create mode 100644 drivers/input/touchscreen/colibri-vf50-ts.c
  
  diff --git a/drivers/input/touchscreen/Kconfig 
  b/drivers/input/touchscreen/Kconfig
  index 80f6386..28948ca 100644
  --- a/drivers/input/touchscreen/Kconfig
  +++ b/drivers/input/touchscreen/Kconfig
  @@ -1027,4 +1027,16 @@ config TOUCHSCREEN_ZFORCE
To compile this driver as a module, choose M here: the
module will be called zforce_ts.
   
  +config TOUCHSCREEN_COLIBRI_VF50
  +   tristate Toradex Colibri on board touchscreen driver
  +   depends on GPIOLIB  IIO  VF610_ADC
 
 Can we possibly add || COMPILE_TEST dependency? Will it compile
 without IIO or VF610_ADC enabled?

I will add and do the checks. It should compile without VF610_ADC
atleast, I don't see how it will without the others. I will check
once at my end also with other configs.

 
 
  +   help
  + Say Y here if you have a Colibri VF50 and plan to use
  + the on-board provided 4-wire touchscreen driver.
  +
  + If unsure, say N.
  +
  + To compile this driver as a module, choose M here: the
  + module will be called colibri_vf50_ts.
  +
   endif
  diff --git a/drivers/input/touchscreen/Makefile 
  b/drivers/input/touchscreen/Makefile
  index 44deea7..93746a0 100644
  --- a/drivers/input/touchscreen/Makefile
  +++ b/drivers/input/touchscreen/Makefile
  @@ -84,3 +84,4 @@ obj-$(CONFIG_TOUCHSCREEN_W90X900) += w90p910_ts.o
   obj-$(CONFIG_TOUCHSCREEN_SX8654)   += sx8654.o
   obj-$(CONFIG_TOUCHSCREEN_TPS6507X) += tps6507x-ts.o
   obj-$(CONFIG_TOUCHSCREEN_ZFORCE)   += zforce_ts.o
  +obj-$(CONFIG_TOUCHSCREEN_COLIBRI_VF50) += colibri-vf50-ts.o
  diff --git a/drivers/input/touchscreen/colibri-vf50-ts.c 
  b/drivers/input/touchscreen/colibri-vf50-ts.c
  new file mode 100644
  index 000..0793fdc
  --- /dev/null
  +++ b/drivers/input/touchscreen/colibri-vf50-ts.c
  @@ -0,0 +1,370 @@
  +/* Copyright 2015 Toradex AG
  + *
  + * Toradex Colibri VF50 Touchscreen driver
  + *
  + * Originally authored by Stefan Agner for 3.0 kernel
  + *
  + * 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/err.h
  +#include linux/gpio.h
  +#include linux/iio/consumer.h
  +#include linux/iio/types.h
  +#include linux/input.h
  +#include linux/interrupt.h
  +#include linux/kernel.h
  +#include linux/module.h
  +#include linux/pinctrl/consumer.h
 
 Don't you need gpio/consumer.h?

Yes.

 
  +#include linux/platform_device.h
  +#include linux/slab.h
  +#include linux/types.h
  +
  +#define DRIVER_NAME colibri-vf50-ts
  +#define DRV_VERSION 1.0
  +
  +#define VF_ADC_MAX ((1  12) - 1)
  +
  +#define COLI_TOUCH_MIN_DELAY_US 1000
  +#define COLI_TOUCH_MAX_DELAY_US 2000
  +#define COLI_TOUCH_NO_OF_AVGS  5
  +
  +struct vf50_touch_device {
  +   struct platform_device  *pdev;
  +   struct input_dev*ts_input;
  +   struct iio_channel  *channels;
  +   struct gpio_desc *gpio_xp;
  +   struct gpio_desc *gpio_xm;
  +   struct gpio_desc *gpio_yp;
  +   struct gpio_desc *gpio_ym;
  +   struct gpio_desc *gpio_pen_detect;
 
 I do not see gpio_pen_detect being used anymore.

Sorry. My mistake. It needs to be deleted. Will fix.

 
  +   int pen_irq;
  +   int min_pressure;
  +   bool stop_touchscreen;
  +};
  +
  +/*
  + * Enables given plates and measures touch parameters using ADC
  + */
  +static int adc_ts_measure(struct iio_channel *channel,
  + struct gpio_desc *plate_p, struct gpio_desc *plate_m)
  +{
  +   int i, value = 0, val = 0;
  +   int ret;
  +
  +   gpiod_set_value(plate_p, 1);
  +   gpiod_set_value(plate_m, 1);
  +
  +   usleep_range(COLI_TOUCH_MIN_DELAY_US, COLI_TOUCH_MAX_DELAY_US);
  +
  +   for (i = 0; i  COLI_TOUCH_NO_OF_AVGS; i++) {
  +   ret = iio_read_channel_raw(channel, val);
  +   if (ret  0) {
  +   value = ret;
  +   goto error_iio_read;
  +   }
  +
  +   value += val;
  +   }
  +
  +   value /= COLI_TOUCH_NO_OF_AVGS;
  +

Re: [PATCH v9 0/4] Implement OCOTP driver for Vybrid using NVMEM

2015-08-24 Thread maitysanchayan

Hello,

Ping? Any feedback? Is this good to be merged?

Thanks.

- Sanchayan.

On 15-08-12 18:49:17, Sanchayan Maity wrote:
 Hello,
 
 This patchset is based on top of v9 of Srinivas's NVMEM framework patches.
 Tested on Greg's tree char-misc-next branch along with Stefan's NAND driver
 patchset.
 
 Sample output on Colibri VF50
 
 root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# uname -a
 Linux colibri-vf 4.2.0-rc6-00130-g24fcfdc #3 SMP Wed Aug 12 18:31:24 IST 2015 
 armv7l GNU/Linux
 
 root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# hexdump nvmem
 000        
 *
 410 72a6 df64      
 420 11d4 2c14      
 430        
 *
 450 0280       
 460        
 *
 880 8f01       
 890        
 *
 8c0  1000      
 8d0 3202 0800      
 8e0  e100      
 8f0        
 *
 c80 bada bada      
 *
 cc0        
 *
 cf0
 
 The driver has changed quite a bit from the first version
 relying on of_platform_populate in mach file, to using
 SoC driver under drivers/soc and finally to NVMEM.
 
 Feedback and comments most welcome.
 
 Version 8 patches can be found here
 https://lkml.org/lkml/2015/8/10/566
 
 Version 7 patches can be found here
 https://lkml.org/lkml/2015/8/6/440
 
 Version 6 RFC patches can be found here
 http://lkml.iu.edu/hypermail/linux/kernel/1506.2/05123.html
 
 Version 5 of the patchset can be found here
 http://lkml.iu.edu/hypermail/linux/kernel/1506.0/03787.html
 
 Version 4 of the patchset can be found here
 https://lkml.org/lkml/2015/5/26/199
 
 Version 3 of the patchset can be found here
 http://www.spinics.net/lists/arm-kernel/msg420847.html
 
 Version 2 of the patchset can be found here
 http://www.spinics.net/lists/devicetree/msg80654.html
 
 Version 1 of the patchset can be found here
 http://www.spinics.net/lists/devicetree/msg80257.html
 
 The RFC version can be found here
 https://lkml.org/lkml/2015/5/11/13
 
 Changes since v8:
 1. Fix three lines over 80 characters
 2. Rebase on top of Greg's char-misc-next branch
 
 Changes since v7:
 1. Add COMPILE_TEST to Kconfig
 2. Use GENMASK and BIT macros where applicable
 3. Fix a code alignment issue
 4. Get the max_register value for regmap config using
 resource_size()
 5. Also add copyright info as the driver logic is based off
 on ocotp code in barebox
 6. Add missing info related to clock in DT binding doc
 
 Changes since v6:
 1. Use the v9 of NVMEM framework patchset
 2. Add a few comments
 3. Initialise buffer address not part of the fuse map to 0
 instead of only handling buffer locations with valid fuse
 addresses.
 
 Changes since v5:
 Use NVMEM framework by Srinivas and Maxime
 
 Changes since v4:
 1. Use devm_* family of functions and use a struct to get rid of
 global variables (suggested by Joachim Eastwood)
 2. Make Kconfig govern the compilation with tristate, instead of
 earlier bool. Paul Bolle raised a valid point that perhaps this
 should have been built in with the bool, however I had not taken
 into consideration generic distro kernels and it makes sense to
 have this tristated. (comments from Paul Bolle and Andreas Farber)
 
 Changes since v3:
 Instead of using the syscon_regmap_lookup_by_compatible function
 use a phandle in the device tree along with offsets specified in
 this phandle node and then read the offset along with the device
 node in the driver for reading from the required region.
 
 Changes since v2:
 Implement the SoC bus code as a driver in drivers/soc
 by registering with fsl,mscm-cpucfg as per Arnd's feedback
 
 Changes since v1:
 Sort the headers in alphabetical order
 
 Changes since RFC:
 Use a DT entry for the ROM area while specifying it as syscon.
 
 Thanks  Regards,
 Sanchayan Maity.
 
 Sanchayan Maity (4):
   clk: clk-vf610: Add clock for Vybrid OCOTP controller
   ARM: dts: vfxxx: Add OCOTP node
   drivers: nvmem: Add Vybrid OCOTP support
   nvmem: Add DT binding documentation for Vybrid OCOTP driver
 
  .../devicetree/bindings/nvmem/vf610-ocotp.txt  |  21 ++
  arch/arm/boot/dts/vfxxx.dtsi   |   9 +
  drivers/clk/imx/clk-vf610.c|   1 +
  drivers/nvmem/Kconfig  |  10 +
  drivers/nvmem/Makefile |   2 +
  drivers/nvmem/vf610-ocotp.c| 302 
 +
  include/dt-bindings/clock/vf610-clock.h|   3 +-
  7 files changed, 347 insertions(+), 1 deletion(-)
  create mode 100644 Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
  create mode 100644 drivers/nvmem/vf610-ocotp.c
 
 -- 
 2.5.0
 
--
To unsubscribe

Re: [PATCH v2 3/4] touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50

Hello Dmitry,

On 15-08-03 14:04:09, Dmitry Torokhov wrote:
 Hi Sanchayan,
 
 On Mon, Aug 03, 2015 at 08:55:44PM +0530, maitysancha...@gmail.com wrote:
  Hello Dmitry,
  
  On 15-07-21 10:20:44, Dmitry Torokhov wrote:
   Hi Stefan,
   
   On Tue, Jul 21, 2015 at 04:43:36PM +0200, Stefan Agner wrote:
Hi Dmitry,

As the original author of the driver I have some remarks to your review

On 2015-07-18 01:42, Dmitry Torokhov wrote:
 +/*
 + * If touch pressure is too low, stop measuring and 
 reenable
 + * touch detection
 + */
 +if (val_p  min_pressure || val_p  2000)
 +break;

This is where the modules touch pressure is used to stop the measurement
process and switch back to interrupt mode. See my remarks at the end.

 +
 +/*
 + * The pressure may not be enough for the first x and 
 the
 + * second y measurement, but, the pressure is ok when 
 the
 + * driver is doing the third and fourth measurement. To
 + * take care of this, we drop the first measurement 
 always.
 + */
 +if (discard_val_on_start) {
 +discard_val_on_start = false;
 +} else {
 +/*
 + * Report touch position and sleep for
 + * next measurement
 + */
 +input_report_abs(vf50_ts-ts_input,
 +ABS_X, VF_ADC_MAX - val_x);
 +input_report_abs(vf50_ts-ts_input,
 +ABS_Y, VF_ADC_MAX - val_y);
 +input_report_abs(vf50_ts-ts_input,
 +ABS_PRESSURE, val_p);
 +input_report_key(vf50_ts-ts_input, BTN_TOUCH, 
 1);
 +input_sync(vf50_ts-ts_input);
 +}
 +
 +msleep(10);
 +}
 +
 +/* Report no more touch, reenable touch detection */
 +input_report_abs(vf50_ts-ts_input, ABS_PRESSURE, 0);
 +input_report_key(vf50_ts-ts_input, BTN_TOUCH, 0);
 +input_sync(vf50_ts-ts_input);
 +
 +vf50_ts_enable_touch_detection(vf50_ts);
 +
 +/* Wait for the pull-up to be stable on high */
 +msleep(10);
 +
 +/* Reenable IRQ to detect touch */
 +enable_irq(vf50_ts-pen_irq);
 +
 +dev_dbg(dev, Reenabled touch detection interrupt\n);
 +}
 +
 +static irqreturn_t vf50_ts_touched(int irq, void *dev_id)
 +{
 +struct vf50_touch_device *vf50_ts = (struct vf50_touch_device 
 *)dev_id;
 +struct device *dev = vf50_ts-pdev-dev;
 +
 +dev_dbg(dev, Touch detected, start worker thread\n);
 +
 +disable_irq_nosync(irq);
 +
 +/* Disable the touch detection plates */
 +gpiod_set_value(vf50_ts-gpio_ym, 0);
 +
 +/* Let the platform mux to default state in order to mux as ADC 
 */
 +pinctrl_pm_select_default_state(dev);
 +
 +queue_work(vf50_ts-ts_workqueue, vf50_ts-ts_work);
 
 If you convert this to a threaded interrupt you won't need to
 disable/reenable interrupt or queue work. You should also be able to 
 use
 gpiod_set_value_cansleep() extending the range of ways the controller
 could be connected to systems.
 

I'm not sure if a threaded interrupt is the right thing here. While the
pen is on the touchscreen (which can be for several seconds)
measurements have to be made in a continuous loop. Is it ok for a
threaded interrupt to run that long?
   
   Yes, why not? Threaded interrupt is simply a kernel thread that is woken
   when hard interrupt handler tells it to wake up. Very similar to
   interrupt + work queue, except that the kernel manages interactions
   properly for you. There are several drivers in kernel that do that, for
   example auo-pixcir-ts.c or tsc2007.c
   

I'm also not sure if it is really safe to _not_ disable the pen down
GPIO interrupt. If we get a interrupt while measuring, we should ignore
that interrupt.
   
   The interrupt management core (you'll have to annotate it as
   IRQF_ONESHOT) will make sure it stays masked properly until the threaded
   handler completes so you do not need to disable it explicitly.
  
  After working some more on threaded irq implementation, if IRQ_ONESHOT
  flag is used while requesting threaded irq, on entering the IRQ handler
  the vf610_gpio_irq_mask is not called and vf610_gpio_irq_unmask is not
  called on exiting the thread function, not something we expected.
  
  In contrast, using explicit disable_irq_nosync and enable_irq in the IRQ
  handler and thread respectively results in the

Re: [PATCH] iio: adc: vf610: Add IIO buffer support for Vybrid ADC

Hello,

On 15-08-04 03:18:46, Duan Andy wrote:
 From: Sanchayan Maity maitysancha...@gmail.com Sent: Monday, August 03, 
 2015 11:10 PM
  To: ji...@kernel.org; linux-...@vger.kernel.org
  Cc: ste...@agner.ch; Duan Fugang-B38611; hof...@osadl.org;
  sanjeev_sha...@mentor.com; Estevam Fabio-R49496; knaac...@gmx.de;
  l...@metafoo.de; pme...@pmeerw.net; antoine.ten...@free-electrons.com;
  linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
  Sanchayan Maity
  Subject: [PATCH] iio: adc: vf610: Add IIO buffer support for Vybrid ADC
  
  This patch adds support for IIO buffer to the Vybrid ADC driver.
  IIO triggered buffer infrastructure along with iio sysfs trigger is used
  to leverage continuous sampling support provided by the ADC block.
  
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
  ---
   drivers/iio/adc/Kconfig |   4 ++
   drivers/iio/adc/vf610_adc.c | 122
  +---
   2 files changed, 120 insertions(+), 6 deletions(-)
  
  diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index
  7c55658..4661241 100644
  --- a/drivers/iio/adc/Kconfig
  +++ b/drivers/iio/adc/Kconfig
  @@ -337,6 +337,10 @@ config TWL6030_GPADC  config VF610_ADC
  tristate Freescale vf610 ADC driver
  depends on OF
  +   select IIO_BUFFER
  +   select IIO_TRIGGER
  +   select IIO_SYSFS_TRIGGER
  +   select IIO_TRIGGERED_BUFFER
  help
Say yes here to support for Vybrid board analog-to-digital
  converter.
Since the IP is used for i.MX6SLX, the driver also support
  i.MX6SLX.
  diff --git a/drivers/iio/adc/vf610_adc.c b/drivers/iio/adc/vf610_adc.c
  index 23b8fb9..af72b9a 100644
  --- a/drivers/iio/adc/vf610_adc.c
  +++ b/drivers/iio/adc/vf610_adc.c
  @@ -34,8 +34,11 @@
   #include linux/err.h
  
   #include linux/iio/iio.h
  +#include linux/iio/buffer.h
   #include linux/iio/sysfs.h
  -#include linux/iio/driver.h
  +#include linux/iio/trigger.h
  +#include linux/iio/trigger_consumer.h #include
  +linux/iio/triggered_buffer.h
  
   /* This will be the driver name the kernel reports */  #define
  DRIVER_NAME vf610-adc
  @@ -170,6 +173,7 @@ struct vf610_adc {
  u32 sample_freq_avail[5];
  
  struct completion completion;
  +   u16 *buffer;
   };
  
   static const u32 vf610_hw_avgs[] = { 1, 4, 8, 16, 32 }; @@ -505,12
  +509,22 @@ static const struct iio_chan_spec_ext_info vf610_ext_info[] =
  {
  .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) |  \
  BIT(IIO_CHAN_INFO_SAMP_FREQ),   \
  .ext_info = vf610_ext_info, \
  +   .address = (_idx),  \
  +   .scan_index = (_idx),   \
  +   .scan_type.sign = 'u',  \
  +   .scan_type.realbits = 12,   \
  +   .scan_type.storagebits = 16,\
   }
  
   #define VF610_ADC_TEMPERATURE_CHAN(_idx, _chan_type) { \
  .type = (_chan_type),   \
  .channel = (_idx),  \
  .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED), \
  +   .address = (_idx),  \
  +   .scan_index = (_idx),   \
  +   .scan_type.sign = 'u',  \
  +   .scan_type.realbits = 12,   \
  +   .scan_type.storagebits = 16,\
   }
  
   static const struct iio_chan_spec vf610_adc_iio_channels[] = { @@ -531,6
  +545,7 @@ static const struct iio_chan_spec vf610_adc_iio_channels[] = {
  VF610_ADC_CHAN(14, IIO_VOLTAGE),
  VF610_ADC_CHAN(15, IIO_VOLTAGE),
  VF610_ADC_TEMPERATURE_CHAN(26, IIO_TEMP),
  +   IIO_CHAN_SOFT_TIMESTAMP(32),
  /* sentinel */
   };
  
  @@ -559,13 +574,21 @@ static int vf610_adc_read_data(struct vf610_adc
  *info)
  
   static irqreturn_t vf610_adc_isr(int irq, void *dev_id)  {
  -   struct vf610_adc *info = (struct vf610_adc *)dev_id;
  +   struct iio_dev *indio_dev = (struct iio_dev *)dev_id;
  +   struct vf610_adc *info = iio_priv(indio_dev);
  int coco;
  
  coco = readl(info-regs + VF610_REG_ADC_HS);
  if (coco  VF610_ADC_HS_COCO0) {
  info-value = vf610_adc_read_data(info);
  -   complete(info-completion);
  +   if (iio_buffer_enabled(indio_dev)) {
  +   info-buffer[0] = info-value;
  +   writel(0, info-regs + VF610_REG_ADC_HS);
 The register is read only. After ADC_Rn is read, the coco bit is cleared.

Right. This crept in from a different implementation which I was trying with
PDB and perhaps a wrong interpretation of the TRM.

Will fix.

Regards,
Sanchayan.

(snip)
--
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 v8 3/4] drivers: nvmem: Add Vybrid OCOTP support

2015-08-12 Thread maitysanchayan

Hello,

On 15-08-12 11:41:55, Srinivas Kandagatla wrote:
 Hi Sanchayan,
 
 Please run checkpatch before you send the patch next time.
 Look at Documentation/SubmittingPatches for more details.
 
 WARNING: line over 80 characters
 #225: FILE: drivers/nvmem/vf610-ocotp.c:174:
 + ret = vf610_ocotp_wait_busy(ocotp-base + 
 OCOTP_CTRL_REG);
 
 WARNING: line over 80 characters
 #237: FILE: drivers/nvmem/vf610-ocotp.c:186:
 + ret = vf610_ocotp_wait_busy(ocotp-base + 
 OCOTP_CTRL_REG);
 
 WARNING: line over 80 characters
 #244: FILE: drivers/nvmem/vf610-ocotp.c:193:
 + writel(OCOTP_CTRL_ERROR, ocotp-base + 
 OCOTP_CTRL_CLR);
 

I had. However splitting these lines seemed odd. Will split and fix.

 
 On 10/08/15 15:11, Sanchayan Maity wrote:
  The patch adds support for the On Chip One Time Programmable Peripheral
  (OCOTP) on the Vybrid platform.
 
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
  ---
drivers/nvmem/Kconfig   |  10 ++
drivers/nvmem/Makefile  |   2 +
drivers/nvmem/vf610-ocotp.c | 301 
  
3 files changed, 313 insertions(+)
create mode 100644 drivers/nvmem/vf610-ocotp.c
 
  diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
  index 0b33014..7af4c1d 100644
  --- a/drivers/nvmem/Kconfig
  +++ b/drivers/nvmem/Kconfig
  @@ -47,4 +47,14 @@ config NVMEM_IMX_OCOTP
This driver can also be built as a module. If so, the module
will be called nvmem-imx-ocotp.
 
 
 Also please can you rebase it on top of char-misc-next?, This patch 
 would not apply as it is because of the above context.

Sure. Will rebase and send.

Thanks.

Regards,
Sanchayan.

 
 
  +config NVMEM_VF610_OCOTP
  +   tristate VF610_SoCs OCOTP support
  +   depends on SOC_VF610 || COMPILE_TEST
  +   help
  + This is a driver for the 'OCOTP' peripheral available on Vybrid
  + devices like VF5xx and VF6xx.
  +
  + This driver can also be built as a module. If so, the module will
  + be called nvmem-vf610-ocotp.
  +
endif
  diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
  index b512d77..8a1eea8 100644
  --- a/drivers/nvmem/Makefile
  +++ b/drivers/nvmem/Makefile
  @@ -12,3 +12,5 @@ obj-$(CONFIG_NVMEM_SUNXI_SID) += nvmem_sunxi_sid.o
nvmem_sunxi_sid-y := sunxi_sid.o
obj-$(CONFIG_NVMEM_IMX_OCOTP) += nvmem-imx-ocotp.o
nvmem-imx-ocotp-y := imx-ocotp.o
  +obj-$(CONFIG_NVMEM_VF610_OCOTP)+= nvmem-vf610-ocotp.o
  +nvmem-vf610-ocotp-y:= vf610-ocotp.o
  diff --git a/drivers/nvmem/vf610-ocotp.c b/drivers/nvmem/vf610-ocotp.c
  new file mode 100644
  index 000..9e18156
  --- /dev/null
  +++ b/drivers/nvmem/vf610-ocotp.c
  @@ -0,0 +1,301 @@
  +/*
  + * Copyright (C) 2015 Toradex AG.
  + *
  + * Author: Sanchayan Maity sanchayan.ma...@toradex.com
  + *
  + * Based on the barebox ocotp driver,
  + * Copyright (c) 2010 Baruch Siach bar...@tkos.co.il
  + * Orex Computed Radiography
  + *
  + * This program is free software; you can redistribute it and/or modify
  + * it under the terms of the GNU General Public License version 2 and
  + * only version 2 as published by the Free Software Foundation.
  + *
  + * This program is distributed in the hope that it will be useful,
  + * but WITHOUT ANY WARRANTY; without even the implied warranty of
  + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  + * GNU General Public License for more details.
  + */
  +
  +#include linux/clk.h
  +#include linux/delay.h
  +#include linux/device.h
  +#include linux/io.h
  +#include linux/module.h
  +#include linux/nvmem-provider.h
  +#include linux/of.h
  +#include linux/platform_device.h
  +#include linux/regmap.h
  +#include linux/slab.h
  +
  +/* OCOTP Register Offsets */
  +#define OCOTP_CTRL_REG 0x00
  +#define OCOTP_CTRL_SET 0x04
  +#define OCOTP_CTRL_CLR 0x08
  +#define OCOTP_TIMING   0x10
  +#define OCOTP_DATA 0x20
  +#define OCOTP_READ_CTRL_REG0x30
  +#define OCOTP_READ_FUSE_DATA   0x40
  +
  +/* OCOTP Register bits and masks */
  +#define OCOTP_CTRL_WR_UNLOCK   16
  +#define OCOTP_CTRL_WR_UNLOCK_KEY   0x3E77
  +#define OCOTP_CTRL_WR_UNLOCK_MASK  GENMASK(31, 16)
  +#define OCOTP_CTRL_ADDR0
  +#define OCOTP_CTRL_ADDR_MASK   GENMASK(6, 0)
  +#define OCOTP_CTRL_RELOAD_SHADOWS  BIT(10)
  +#define OCOTP_CTRL_ERROR   BIT(9)
  +#define OCOTP_CTRL_BUSYBIT(8)
  +
  +#define OCOTP_TIMING_STROBE_READ   16
  +#define OCOTP_TIMING_STROBE_READ_MASK  GENMASK(21, 16)
  +#define OCOTP_TIMING_RELAX 12
  +#define OCOTP_TIMING_RELAX_MASKGENMASK(15, 12)

Re: [PATCH v7 4/4] nvmem: Add DT binding documentation for Vybrid OCOTP driver

Hello,

On 15-08-10 10:18:01, Srinivas Kandagatla wrote:
 
 
 On 06/08/15 16:27, Sanchayan Maity wrote:
  Add the devicetree bindings for the Freescale Vybrid On-Chip
  OTP driver.
 
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
  ---
.../devicetree/bindings/nvmem/vf610-ocotp.txt| 20 
  
1 file changed, 20 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
 
  diff --git a/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt 
  b/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
  new file mode 100644
  index 000..5556810
  --- /dev/null
  +++ b/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
  @@ -0,0 +1,20 @@
  +On-Chip OTP Memory for Freescale Vybrid
  +
  +Required Properties:
  +  compatible:
  +  - fsl,vf610-ocotp for VF5xx/VF6xx
  +  #address-cells : Should be 1
  +  #size-cells : Should be 1
  +  reg : Address and length of OTP controller registers
 
 Is there a reason to not add clocks property in to the bindings?

An error on my part. Will fix with the next revision.

- Sanchayan.

 
  +
  +Example for Vybrid VF5xx/VF6xx:
  +
  +   ocotp: ocotp@400a5000 {
  +   compatible = fsl,vf610-ocotp;
  +   #address-cells = 1;
  +   #size-cells = 1;
  +   reg = 0x400a5000 0xD00;
  +   clocks = clks VF610_CLK_OCOTP;
  +   clock-names = ocotp;
  +   };
  +
 
--
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/4] drivers: nvmem: Add Vybrid OCOTP support

Hello,

On 15-08-10 10:17:53, Srinivas Kandagatla wrote:
 Hi Sanchayan,
 
 
 Could you add Greg to the to list so that we can request him to pick 
 this via his tree.

Will add Greg in cc with the next revision.

 
 
 Few nits, other than that driver looks good.
 
 
 On 06/08/15 16:27, Sanchayan Maity wrote:
  The patch adds support for the On Chip One Time Programmable Peripheral
  (OCOTP) on the Vybrid platform.
 
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
  ---
drivers/nvmem/Kconfig   |  10 ++
drivers/nvmem/Makefile  |   2 +
drivers/nvmem/vf610-ocotp.c | 297 
  
3 files changed, 309 insertions(+)
create mode 100644 drivers/nvmem/vf610-ocotp.c
 
  diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
  index 0b33014..bfd0c02 100644
  --- a/drivers/nvmem/Kconfig
  +++ b/drivers/nvmem/Kconfig
  @@ -47,4 +47,14 @@ config NVMEM_IMX_OCOTP
This driver can also be built as a module. If so, the module
will be called nvmem-imx-ocotp.
 
  +config NVMEM_VF610_OCOTP
  +   tristate VF610_SoCs OCOTP support
  +   depends on SOC_VF610
 You could also add COMPILE_TEST which will ensure that its compile checked.

Ok.

  +   help
  + This is a driver for the 'OCOTP' peripheral available on Vybrid
  + devices like VF5xx and VF6xx.
  +
  + This driver can also be built as a module. If so, the module will
  + be called nvmem-vf610-ocotp.
  +
endif
  diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
  index b512d77..8a1eea8 100644
  --- a/drivers/nvmem/Makefile
  +++ b/drivers/nvmem/Makefile
  @@ -12,3 +12,5 @@ obj-$(CONFIG_NVMEM_SUNXI_SID) += nvmem_sunxi_sid.o
nvmem_sunxi_sid-y := sunxi_sid.o
obj-$(CONFIG_NVMEM_IMX_OCOTP) += nvmem-imx-ocotp.o
nvmem-imx-ocotp-y := imx-ocotp.o
  +obj-$(CONFIG_NVMEM_VF610_OCOTP)+= nvmem-vf610-ocotp.o
  +nvmem-vf610-ocotp-y:= vf610-ocotp.o
  diff --git a/drivers/nvmem/vf610-ocotp.c b/drivers/nvmem/vf610-ocotp.c
  new file mode 100644
  index 000..25ee701
  --- /dev/null
  +++ b/drivers/nvmem/vf610-ocotp.c
  @@ -0,0 +1,297 @@
  +/*
  + * Copyright (C) 2015 Toradex AG.
  + *
  + * Author: Sanchayan Maity sanchayan.ma...@toradex.com
  + *
  + * This program is free software; you can redistribute it and/or modify
  + * it under the terms of the GNU General Public License version 2 and
  + * only version 2 as published by the Free Software Foundation.
  + *
  + * This program is distributed in the hope that it will be useful,
  + * but WITHOUT ANY WARRANTY; without even the implied warranty of
  + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  + * GNU General Public License for more details.
  + */
  +
  +#include linux/clk.h
  +#include linux/delay.h
  +#include linux/device.h
  +#include linux/io.h
  +#include linux/module.h
  +#include linux/nvmem-provider.h
  +#include linux/of.h
  +#include linux/platform_device.h
  +#include linux/regmap.h
  +#include linux/slab.h
  +
  +/* OCOTP Register Offsets */
  +#define OCOTP_CTRL_REG 0x00
  +#define OCOTP_CTRL_SET 0x04
  +#define OCOTP_CTRL_CLR 0x08
  +#define OCOTP_TIMING   0x10
  +#define OCOTP_DATA 0x20
  +#define OCOTP_READ_CTRL_REG0x30
  +#define OCOTP_READ_FUSE_DATA   0x40
  +
  +/* OCOTP Register bits and masks */
  +#define OCOTP_CTRL_WR_UNLOCK   16
  +#define OCOTP_CTRL_WR_UNLOCK_KEY   0x3E77
  +#define OCOTP_CTRL_WR_UNLOCK_MASK  0x
  +#define OCOTP_CTRL_ADDR0
  +#define OCOTP_CTRL_ADDR_MASK   0x7F
  +#define OCOTP_CTRL_RELOAD_SHADOWS  (0x1  10)
  +#define OCOTP_CTRL_ERROR   (0x1  9)
  +#define OCOTP_CTRL_BUSY(0x1  8)
 
 we can use BIT and GENMASK variants here for most of the defines.

Ok.

  +
  +#define OCOTP_TIMING_STROBE_READ   16
  +#define OCOTP_TIMING_STROBE_READ_MASK  0x003F
  +#define OCOTP_TIMING_RELAX 12
  +#define OCOTP_TIMING_RELAX_MASK0xF000
  +#define OCOTP_TIMING_STROBE_PROG   0
  +#define OCOTP_TIMING_STROBE_PROG_MASK  0x0FFF
  +
  +#define OCOTP_READ_CTRL_READ_FUSE  0x1
  +
  +#define VF610_OCOTP_TIMEOUT10
  +
  +#define BF(value, field)   (((value)  field)  field##_MASK)
  +
  +#define DEF_RELAX  20
  +
  +static const int base_to_fuse_addr_mappings[][2] = {
  +   {0x400, 0x00},
  +   {0x410, 0x01},
  +   {0x420, 0x02},
  +   {0x450, 0x05},
  +   {0x4F0, 0x0F},
  +   {0x600, 0x20},
  +   {0x610, 0x21},
  +   {0x620, 0x22},
  +   {0x630, 0x23},
  +   {0x640, 0x24},
  +   {0x650, 0x25},
  +   {0x660, 0x26},
  +   {0x670, 0x27},
  +   {0x6F0,

Re: [PATCH v2] iio: adc: vf610: Add IIO buffer support for Vybrid ADC

Hello,

On 15-08-08 19:46:00, Jonathan Cameron wrote:
 On 08/08/15 18:22, maitysancha...@gmail.com wrote:
  Hello Jonathan,
  
  On 15-08-08 15:29:47, Jonathan Cameron wrote:
  On 05/08/15 13:10, Sanchayan Maity wrote:
  This patch adds support for IIO buffer to the Vybrid ADC driver.
  IIO triggered buffer infrastructure along with iio sysfs trigger
  is used to leverage continuous sampling support provided by the
  ADC block.
  Looking good.  Just a couple more bits and pieces inline from me.
  One or two of which aren't corrected from Peter's review of v1.
 
  I will want Fugang Dong's ack / review tag on the final version
  before applying it however.
  
  Sure.
  
  This driver is some distance form my area of expertise!
  
  I doubt :).
  
 
  Jonathan
 
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
  ---
   drivers/iio/adc/Kconfig |   4 ++
   drivers/iio/adc/vf610_adc.c | 107 
  +---
   2 files changed, 105 insertions(+), 6 deletions(-)
 
  diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
  index 7c55658..4661241 100644
  --- a/drivers/iio/adc/Kconfig
  +++ b/drivers/iio/adc/Kconfig
  @@ -337,6 +337,10 @@ config TWL6030_GPADC
   config VF610_ADC
tristate Freescale vf610 ADC driver
depends on OF
  + select IIO_BUFFER
  + select IIO_TRIGGER
  + select IIO_SYSFS_TRIGGER
  Unless I missed something there is no dependency on this particular
  trigger (it just happens to be the one you've been testing with I guess).
  Could be driven from a hardware trigger belonging to another device for
  example.
  
  Yes right in a way. Right now we do not provide or there is no provision
  for hardware triggers. On the Vybrid, the Peripheral Delay Block (PDB)
  does the job of providing support for software and hardware triggers. PDB
  support is not yet there in Linux however. 
 Not supplying a trigger is fine, but any trigger (that allows other devices
 to bind to it) will be fine.

Ok.

  
  There is also the question of where the Vybrid PDB driver would belong
  to? In the TRM it is put in the timers but the kernel has no generic timer
  framework that I am aware of.
 It's been debated a number of times, but no one has ever written one.
 Not seen anything recently on this topic..  Lars, you seen anything?
 (the blackfin-timer trigger is similar to what you are describing I think).
 
  After some internal reviews we decided to
  do a platform driver which provided functions ADC driver could called into.
 Does rather feel like there ought to be at least a standard home for these.
 Might be worth asking the arm-soc guys...
  
  I have a patchset ready which provides trigger support using PDB however
  configuring the PDB properly has proven to be tricky. While it works but
  not reliably with multiple channels and it would be a while before I get
  that working and post that patchset. So kind of stalled there and just
  because of two registers which need to be written with the correct value
  :). For what it's worth if someone comes across this, some discussion
  here [1] along with patches. (Note however those are a bit old patches
  not exactly my new work).
  
  Sorry for digressing from the topic. Anyways so the idea was to provide
  sysfs triggers as default for using this continuous sampling. Later the
  driver may provide additional triggers. So for now I added the sysfs
  trigger as a select option so that a user won't have to recompile the
  kernel for using the buffers with continuous sampling.
 It's a policy decision so should really be left to the distro builders.
 There are lots of possible triggers out there (though sysfs might be
 the most likely one!)
 
 Hence don't put the select there in Kconfig.  We should shortly have
 Daniel's update to the patches for the high resolution timer
 which would give another obvious choice for starters.

Alright. Will drop that iio sysfs tigger select from the Kconfig.

 
 I doubt many distros build without the sysfs triggers but with other IIO
 stuff.
 
  
 
  + select IIO_TRIGGERED_BUFFER
help
  Say yes here to support for Vybrid board analog-to-digital converter.
  Since the IP is used for i.MX6SLX, the driver also support i.MX6SLX.
  diff --git a/drivers/iio/adc/vf610_adc.c b/drivers/iio/adc/vf610_adc.c
  index 23b8fb9..97cb2ed 100644
  --- a/drivers/iio/adc/vf610_adc.c
  +++ b/drivers/iio/adc/vf610_adc.c
  @@ -34,8 +34,11 @@
   #include linux/err.h
   
   #include linux/iio/iio.h
  +#include linux/iio/buffer.h
   #include linux/iio/sysfs.h
  -#include linux/iio/driver.h
  +#include linux/iio/trigger.h
  +#include linux/iio/trigger_consumer.h
  +#include linux/iio/triggered_buffer.h
   
   /* This will be the driver name the kernel reports */
   #define DRIVER_NAME vf610-adc
  @@ -170,6 +173,7 @@ struct vf610_adc {
u32 sample_freq_avail[5];
   
struct completion completion;
  + u16 buffer[2];
  Note the requirements on the buffer provided to

Re: [PATCH v2 3/4] touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50

2015-07-21 Thread maitysanchayan

On 15-07-21 10:20:44, Dmitry Torokhov wrote:
 Hi Stefan,
 
 On Tue, Jul 21, 2015 at 04:43:36PM +0200, Stefan Agner wrote:
  Hi Dmitry,
  
  As the original author of the driver I have some remarks to your review
  
  On 2015-07-18 01:42, Dmitry Torokhov wrote:
   +/*
   + * If touch pressure is too low, stop measuring and 
   reenable
   + * touch detection
   + */
   +if (val_p  min_pressure || val_p  2000)
   +break;
  
  This is where the modules touch pressure is used to stop the measurement
  process and switch back to interrupt mode. See my remarks at the end.
  
   +
   +/*
   + * The pressure may not be enough for the first x and 
   the
   + * second y measurement, but, the pressure is ok when 
   the
   + * driver is doing the third and fourth measurement. To
   + * take care of this, we drop the first measurement 
   always.
   + */
   +if (discard_val_on_start) {
   +discard_val_on_start = false;
   +} else {
   +/*
   + * Report touch position and sleep for
   + * next measurement
   + */
   +input_report_abs(vf50_ts-ts_input,
   +ABS_X, VF_ADC_MAX - val_x);
   +input_report_abs(vf50_ts-ts_input,
   +ABS_Y, VF_ADC_MAX - val_y);
   +input_report_abs(vf50_ts-ts_input,
   +ABS_PRESSURE, val_p);
   +input_report_key(vf50_ts-ts_input, BTN_TOUCH, 
   1);
   +input_sync(vf50_ts-ts_input);
   +}
   +
   +msleep(10);
   +}
   +
   +/* Report no more touch, reenable touch detection */
   +input_report_abs(vf50_ts-ts_input, ABS_PRESSURE, 0);
   +input_report_key(vf50_ts-ts_input, BTN_TOUCH, 0);
   +input_sync(vf50_ts-ts_input);
   +
   +vf50_ts_enable_touch_detection(vf50_ts);
   +
   +/* Wait for the pull-up to be stable on high */
   +msleep(10);
   +
   +/* Reenable IRQ to detect touch */
   +enable_irq(vf50_ts-pen_irq);
   +
   +dev_dbg(dev, Reenabled touch detection interrupt\n);
   +}
   +
   +static irqreturn_t vf50_ts_touched(int irq, void *dev_id)
   +{
   +struct vf50_touch_device *vf50_ts = (struct vf50_touch_device 
   *)dev_id;
   +struct device *dev = vf50_ts-pdev-dev;
   +
   +dev_dbg(dev, Touch detected, start worker thread\n);
   +
   +disable_irq_nosync(irq);
   +
   +/* Disable the touch detection plates */
   +gpiod_set_value(vf50_ts-gpio_ym, 0);
   +
   +/* Let the platform mux to default state in order to mux as ADC 
   */
   +pinctrl_pm_select_default_state(dev);
   +
   +queue_work(vf50_ts-ts_workqueue, vf50_ts-ts_work);
   
   If you convert this to a threaded interrupt you won't need to
   disable/reenable interrupt or queue work. You should also be able to use
   gpiod_set_value_cansleep() extending the range of ways the controller
   could be connected to systems.
   
  
  I'm not sure if a threaded interrupt is the right thing here. While the
  pen is on the touchscreen (which can be for several seconds)
  measurements have to be made in a continuous loop. Is it ok for a
  threaded interrupt to run that long?
 
 Yes, why not? Threaded interrupt is simply a kernel thread that is woken
 when hard interrupt handler tells it to wake up. Very similar to
 interrupt + work queue, except that the kernel manages interactions
 properly for you. There are several drivers in kernel that do that, for
 example auo-pixcir-ts.c or tsc2007.c
 
  
  I'm also not sure if it is really safe to _not_ disable the pen down
  GPIO interrupt. If we get a interrupt while measuring, we should ignore
  that interrupt.
 
 The interrupt management core (you'll have to annotate it as
 IRQF_ONESHOT) will make sure it stays masked properly until the threaded
 handler completes so you do not need to disable it explicitly.

(snip)

I tried the IRQ threaded implementation. From your reply, I can see my first
implementation was wrong in the sense that I did not use the IRQF_ONESHOT flag.
The touch response time was not good in this case, however thats to be expected
in this case from what I understand now.

With the IRQF_ONESHOT specified the response time is much better compared to
what I was seeing above, but, I still feel it is not the same as with IRQ 
handler
plus workqueue approach. However I have no idea how to quantify this.

So I tried explicit enabling/disabling of IRQ and to me it seems the response
slightly improves compared to

Re: [PATCH v2 3/4] touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50

On 15-07-18 14:03:25, Nicolae Rosia wrote:
 Hi,
 
 On Thu, Jul 16, 2015 at 6:13 PM, Sanchayan Maity
 maitysancha...@gmail.com wrote:
  The Colibri Vybrid VF50 module supports 4-wire touchscreens using
  FETs and ADC inputs. This driver uses the IIO consumer interface
  and relies on the vf610_adc driver based on the IIO framework.
 
  Signed-off-by: Sanch
  +static const struct of_device_id vf50_touch_of_match[] = {
  +   { .compatible = toradex,vf50-touchctrl, },
  +   { }
  +};
  +MODULE_DEVICE_TABLE(of, vf50_touch_of_match);
  +
  +static struct platform_driver __refdata vf50_touch_driver = {
  +   .driver = {
  +   .name = toradex,vf50_touchctrl,
  +   .of_match_table = vf50_touch_of_match,
  +   },
  +   .probe = vf50_ts_probe,
  +   .remove = vf50_ts_remove,
  +   .prevent_deferred_probe = false,
  +};
 Why Toradex ? Isn't this a Freescale IP ?

The 4 wire touchscreen support is provided by using on module circuitry
mainly comprising of FET's and leveraging the GPIOs and on chip ADC of
the Vybrid SoC.

This is specific to our Colibri Vybrid VF50 module and not the Freescale
IP. While I guess one could certainly use the driver for their own needs
if one were to replicate a similar circuitry and change the DT properties
concerning GPIO and ADC's as per their own board, as of now this is only
use on our Toradex VF50 modules and was done by us specifically to provide
touchscreen support for VF50.

Regards,
Sanchayan.
--
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 3/4] touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50

Hello Dmitry,

On 15-07-17 16:42:42, Dmitry Torokhov wrote:
 Hi Sanchayan,
 
 
 On Thu, Jul 16, 2015 at 08:43:21PM +0530, Sanchayan Maity wrote:
  The Colibri Vybrid VF50 module supports 4-wire touchscreens using
  FETs and ADC inputs. This driver uses the IIO consumer interface
  and relies on the vf610_adc driver based on the IIO framework.
 
 This looks pretty good, thank you. Just a few comments below.
 
  
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
  ---
   drivers/input/touchscreen/Kconfig   |  12 +
   drivers/input/touchscreen/Makefile  |   1 +
   drivers/input/touchscreen/colibri-vf50-ts.c | 451 
  
   3 files changed, 464 insertions(+)
   create mode 100644 drivers/input/touchscreen/colibri-vf50-ts.c
  
  diff --git a/drivers/input/touchscreen/Kconfig 
  b/drivers/input/touchscreen/Kconfig
  index 80f6386..28948ca 100644
  --- a/drivers/input/touchscreen/Kconfig
  +++ b/drivers/input/touchscreen/Kconfig
  @@ -1027,4 +1027,16 @@ config TOUCHSCREEN_ZFORCE
To compile this driver as a module, choose M here: the
module will be called zforce_ts.
   
  +config TOUCHSCREEN_COLIBRI_VF50
  +   tristate Toradex Colibri on board touchscreen driver
  +   depends on GPIOLIB  IIO  VF610_ADC
  +   help
  + Say Y here if you have a Colibri VF50 and plan to use
  + the on-board provided 4-wire touchscreen driver.
  +
  + If unsure, say N.
  +
  + To compile this driver as a module, choose M here: the
  + module will be called colibri_vf50_ts.
  +
   endif
  diff --git a/drivers/input/touchscreen/Makefile 
  b/drivers/input/touchscreen/Makefile
  index 44deea7..93746a0 100644
  --- a/drivers/input/touchscreen/Makefile
  +++ b/drivers/input/touchscreen/Makefile
  @@ -84,3 +84,4 @@ obj-$(CONFIG_TOUCHSCREEN_W90X900) += w90p910_ts.o
   obj-$(CONFIG_TOUCHSCREEN_SX8654)   += sx8654.o
   obj-$(CONFIG_TOUCHSCREEN_TPS6507X) += tps6507x-ts.o
   obj-$(CONFIG_TOUCHSCREEN_ZFORCE)   += zforce_ts.o
  +obj-$(CONFIG_TOUCHSCREEN_COLIBRI_VF50) += colibri-vf50-ts.o
  diff --git a/drivers/input/touchscreen/colibri-vf50-ts.c 
  b/drivers/input/touchscreen/colibri-vf50-ts.c
  new file mode 100644
  index 000..eb16bdc
  --- /dev/null
  +++ b/drivers/input/touchscreen/colibri-vf50-ts.c
  @@ -0,0 +1,451 @@
  +/* Copyright 2015 Toradex AG
  + *
  + * Toradex Colibri VF50 Touchscreen driver
  + *
  + * Originally authored by Stefan Agner for 3.0 kernel
  + *
  + * 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 dt-bindings/gpio/gpio.h
 
 Why?

Remnant of old usage. Will fix.

 
  +#include linux/delay.h
  +#include linux/err.h
  +#include linux/gpio.h
  +#include linux/iio/consumer.h
  +#include linux/iio/types.h
  +#include linux/input.h
  +#include linux/interrupt.h
  +#include linux/kernel.h
  +#include linux/module.h
  +#include linux/of_gpio.h
 
 Is not used as far as I can see.

Right. Crept in from old usage of extracting gpio information from DT. Should
have removed when I switched to using gpiod_* and removal of legacy gpio API.
Will fix.

 
  +#include linux/pinctrl/consumer.h
  +#include linux/platform_device.h
  +#include linux/slab.h
  +#include linux/types.h
  +
  +#define DRIVER_NAME colibri-vf50-ts
  +#define DRV_VERSION 1.0
  +
  +#define VF_ADC_MAX ((1  12) - 1)
  +
  +#define COLI_TOUCH_MIN_DELAY_US 1000
  +#define COLI_TOUCH_MAX_DELAY_US 2000
  +
  +static int min_pressure = 200;
  +
  +struct vf50_touch_device {
  +   struct platform_device  *pdev;
  +   struct input_dev*ts_input;
  +   struct workqueue_struct *ts_workqueue;
  +   struct work_struct  ts_work;
  +   struct iio_channel  *channels;
  +   struct gpio_desc *gpio_xp;
  +   struct gpio_desc *gpio_xm;
  +   struct gpio_desc *gpio_yp;
  +   struct gpio_desc *gpio_ym;
  +   struct gpio_desc *gpio_pen_detect;
  +   struct gpio_desc *gpio_pen_detect_pullup;
  +   int pen_irq;
  +   bool stop_touchscreen;
  +};
  +
  +/*
  + * Enables given plates and measures touch parameters using ADC
  + */
  +static int adc_ts_measure(struct iio_channel *channel,
  + struct gpio_desc *plate_p, struct gpio_desc *plate_m)
  +{
  +   int i, value = 0, val = 0;
  +   int ret;
  +
  +   gpiod_set_value(plate_p, 1);
  +   gpiod_set_value(plate_m, 1);
  +
  +   usleep_range(COLI_TOUCH_MIN_DELAY_US, COLI_TOUCH_MAX_DELAY_US);
  +
  +   for (i = 0; i  5; i++) {
  +   ret = iio_read_channel_raw(channel, val);
  +   if (ret  0)
  +   return -EINVAL;
  +
  +   value += val;
  +   }
  +
  +   value /= 5;
  +
  +   gpiod_set_value(plate_p, 0);
  +   gpiod_set_value(plate_m, 0);
  +
  +   return value;
  +}
  +
  +/*
  + * Enable touch detection using falling edge detection on XM
  + */
  +static

Re: [PATCH v2 2/2] ARM: dts: vfxxx: Add property for minimum sample time

2015-07-12 Thread maitysanchayan

Hello Jonathan,

On 15-07-11 18:39:10, Jonathan Cameron wrote:
 On 10/07/15 19:06, maitysancha...@gmail.com wrote:
  Hello Shawn,
  
  On 15-07-10 16:53:24, Shawn Guo wrote:
  On Wed, Jun 24, 2015 at 02:03:41PM +0530, Sanchayan Maity wrote:
  Add a device tree property which allows to specify the minimum sample
  time which can be used to calculate the actual ADC cycles required
  depending on the hardware.
 
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
  ---
   arch/arm/boot/dts/vfxxx.dtsi | 2 ++
   1 file changed, 2 insertions(+)
 
  diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
  index 90a03d5..71d9c08 100644
  --- a/arch/arm/boot/dts/vfxxx.dtsi
  +++ b/arch/arm/boot/dts/vfxxx.dtsi
  @@ -229,6 +229,7 @@
status = disabled;
fsl,adck-max-frequency = 3000, 4000,
2000;
  + min-sample-time = 1000;
};
   
wdoga5: wdog@4003e000 {
  @@ -447,6 +448,7 @@
status = disabled;
fsl,adck-max-frequency = 3000, 4000,
2000;
  + min-sample-time = 1000;
 
  Can we code 1000 as the default in kernel driver, so that only boards
  requiring different value need to have this property?  Doing so makes
  the property optional rather than required.
 
  
  Not sure if hardcoding it in the driver is the right approach.
 If it is a true feature of the device (i.e. if in the case of perfect
 front end electronics) this is the right option, then a default makes
 a lot of sense.  If that isn't the case (I suspect not) then if we
 drop it be optional chances are no one will bother thinking about it
 or trying to tune this at all.
 
 Hence seems wrong to put a fairly arbitrary default value on it.
 However, we do need to still work with old device trees and new kernels
 so need to cope without it.
 
 Hence to my mind, if we had started out with this in the first driver
 version, then the default would be a bad idea.  As we didn't then we
 really need to cope with nothing specified (as best we can) and so
 we do need a sensible default (or perhaps even sensible worst
 case default) in there.

Just to be sure, do I understand you correctly that you agree with the
property being in device tree?

If the device tree property is not specified the driver will just go on
to use the value 3 which was hardcoded earlier. In my opinion it is
better to allow users to change the sampling cycles by specifying or not
specifying this in the device tree rather than have a default value coded
in the driver. However this is just my opinion.

Also, some users might not need the somewhat worst case value of 1000. I
guess we could keep the driver patch the way it is right now and migrate
the property to be specified in our board dts file? So the property can
be picked up from the vf-colibri.dtsi or vf500-colibri.dtsi in the adc
node? Other boards can do the same?

We came up with the change after noticing huge reading discrepancies where
we had a 4 wire resistive touch screen connected to the ADC channels and
the driver sampled these channels at an interval of 10-20ms[1]. Once the
touchscreen came into picture, readings from temperature channel or others
showed deviations between 4-6. Somehow the temperature channel
seemed to be the most affected.

For a while, I thought the ts driver logic was at a fault, but Stefan pointed
out the discrepancies in the driver using a fixed clock cycle which was not
correct along the sampling time also being hardcoded. Stefan's respect ADC
clocking limitations and this patch are based on our above observations.

[1] https://lkml.org/lkml/2015/6/30/103

- Sanchayan.
--
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: [RFC PATCH v6 3/3] drivers: nvmem: Add Vybrid OCOTP support

2015-07-07 Thread maitysanchayan

Hi Stefan,

On 15-07-07 14:49:06, Stefan Wahren wrote:
 Hi Sanchayan,
 
  maitysancha...@gmail.com hat am 7. Juli 2015 um 07:19 geschrieben:
 
 
  [...]
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 17f1a57..84c830d 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -33,4 +33,14 @@ config NVMEM_SUNXI_SID
This driver can also be built as a module. If so, the module
will be called eeprom-sunxi-sid.
   
+config NVMEM_VF610_OCOTP
+ tristate VF610 SoCs OCOTP support
+ depends on SOC_VF610
+ help
+ This is a driver for the 'OCOTP' available on various Vybrid
+ devices.
  
   I don't know much about Vybrid. But this driver is specific for VF610, 
   isn't
   it?
 
  Sorry. I only checked on VF50 and VF61. Will check if is it available with 
  the
  other Vybrid devices and change if it is not so.
 
 no problem. If you spend time in testing your driver with different devices, 
 you
 could mention
 this in your patch description. The naming VF610 suggests that the driver is
 very specific.
 That confuses me a little bit.

Sorry about that. Will add the necessary information in the next respin for 
sure.

 
 
  
+
+
+static int vf610_ocotp_write(void *context, const void *data, size_t
count)
+{
+ return 0;
+}
+
+static int vf610_ocotp_read(void *context,
+ const void *offset, size_t reg_size,
+ void *val, size_t val_size)
+{
+ void __iomem *ocotp_base = context;
+ u32 *buf = val;
+ u32 reg;
+ int ret;
+ int i;
+
+ for (i = 0; i  ARRAY_SIZE(valid_fuse_addr); i++) {
+ vf610_ocotp_set_timing(ocotp_base, ocotp_timing);
+ ret = vf610_ocotp_wait_busy(ocotp_base + OCOTP_CTRL_REG);
+ if (ret)
+ return ret;
  
   Is it really necessary to set the timing in the loop, instead before?
 
  I will test it once. From my understanding of 35.3.1.5 I thought the timing
  needs to explicitly programmed on every read. Perhaps I took it too 
  literally.
 
 It was only a question. If barebox does the same, it should be okay.


Yes, the code logic is completely similar to barebox except for changes like
how timeout is handled here in the wait busy function.

 
  
+
+ reg = readl(ocotp_base + OCOTP_CTRL_REG);
+ reg = ~OCOTP_CTRL_ADDR_MASK;
+ reg = ~OCOTP_CTRL_WR_UNLOCK_MASK;
+ reg |= BF(valid_fuse_addr[i], OCOTP_CTRL_ADDR);
+ writel(reg, ocotp_base + OCOTP_CTRL_REG);
+
+ writel(OCOTP_READ_CTRL_READ_FUSE,
+ ocotp_base + OCOTP_READ_CTRL_REG);
+ ret = vf610_ocotp_wait_busy(ocotp_base + OCOTP_CTRL_REG);
+ if (ret)
+ return ret;
+
+ if (readl(ocotp_base)  OCOTP_CTRL_ERROR) {
+ pr_err(Error reading from fuse address %d\n,
+ valid_fuse_addr[i]);
  
   You could use dev_err() when storing vf610_ocotp_dev in the context.
 
  Ok.
 
  
+ writel(OCOTP_CTRL_ERROR, ocotp_base + OCOTP_CTRL_CLR);
  
   Shouldn't the function abort here?
 
  I am not sure about what usage I should follow here. I went for an
  explicit error message and since 0xBADABADA is expected to be returned
  on a read locked shadow register, the user would get the above for this
  particular fuse address and the rest can still be valid since the TRM
  mentions subsequent reads to unlocked shadow locations will still work
  successfully. So I did not abort on the error. Should I?
 
 In case you don't want to abort, a comment about the 0xBADABADA behavior would
 be helpful.

Ok. Will add the same.

 
 
  
+
+
+static int vf610_ocotp_probe(struct platform_device *pdev)
+{
+ struct vf610_ocotp_dev *ocotp_dev;
+
+ ocotp_dev = devm_kzalloc(pdev-dev,
+ sizeof(struct vf610_ocotp_dev), GFP_KERNEL);
+ if (!ocotp_dev)
+ return -ENOMEM;
+
+ ocotp_dev-dev = pdev-dev;
+
+ ocotp_dev-res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ ocotp_dev-base = devm_ioremap_resource(ocotp_dev-dev, 
ocotp_dev-res);
+ if (IS_ERR(ocotp_dev-base))
+ return PTR_ERR(ocotp_dev-base);
+
+ ocotp_dev-clk = devm_clk_get(ocotp_dev-dev, ocotp);
+ if (IS_ERR(ocotp_dev-clk)) {
+ dev_err(ocotp_dev-dev, failed getting clock, err = %ld\n,
+ PTR_ERR(ocotp_dev-clk));
+ return PTR_ERR(ocotp_dev-clk);
+ }
+
+ ocotp_regmap_config.max_register = resource_size(ocotp_dev-res) - 1;
  
   Looking at valid_fuse_addr shows me 0x3F as last valid register. So the 
   rest
   of the buffer ( 0xD00 - sizeof(valid_fuse_addr) ) in case of raw access
   could be
   uninitializied.
 
  Sorry I did not exactly get you here. The intention behind using the
  valid_fuse_addr
  is to allow reading only from valid fuse addresses and avoid reading from 
  all
  other
  locations as per the Fuse map address table 35-1.
 
 Yes, i got your intention. But from my unterstand the read function should 
 fill
 up
 the complete buffer with defined values. My MXS OCOTP driver have the same
 problem
 and fill

Re: [PATCH v2 0/2] Implement sample time consideration for Vybrid's ADC

2015-07-10 Thread maitysanchayan

Hello Shawn,

On 15-07-10 16:47:04, Shawn Guo wrote:
 On Wed, Jun 24, 2015 at 02:03:39PM +0530, Sanchayan Maity wrote:
  Hello,
  
  This patchset adds a dt binding for specifying sample time
  for the vybrid adc driver and takes this into account for
  sampling frequency calculation and related configuration in
  the driver.
  
  The patchset is based on top of Stefan's patches here
  http://lkml.iu.edu/hypermail/linux/kernel/1505.3/02043.html
  
  which got recently applied. Tested with shawn's for-next
  branch.
  
  Changes since v1:
  
  Change from a vendor specific fsl,min-sample-time to non vendor
  specific min-sample-time.
 
 What's the reason for that?  Property without vendor prefix would be
 the generic one, which should be defined by generic ADC bindings, not
 vf610-adc.txt.

The reason for going with a generic one was discussed in the first series,
as though there might not be any devices at the moment using this property,
some might appear or use it in the future.

I did consider putting this in the generic ADC bindings, however for lack
of one like one present for touchscreen, I kept it in the vf610 specific
driver binding. Thought there should not be any harm with this.

- Sanchayan.

 
 Shawn
 
  
  Version 1 of the patchset can be found here
  http://lkml.iu.edu/hypermail/linux/kernel/1506.1/00026.html
  
  - Sanchayan.
  
  Sanchayan Maity (2):
iio: adc: Determine sampling frequencies by using minimum sample time
ARM: dts: vfxxx: Add property for minimum sample time
  
   .../devicetree/bindings/iio/adc/vf610-adc.txt  |  6 ++
   arch/arm/boot/dts/vfxxx.dtsi   |  2 +
   drivers/iio/adc/vf610_adc.c| 74 
  --
   3 files changed, 78 insertions(+), 4 deletions(-)
  
  -- 
  2.4.4
  
  --
  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/
  
--
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 2/2] ARM: dts: vfxxx: Add property for minimum sample time

2015-07-10 Thread maitysanchayan

Hello Shawn,

On 15-07-10 16:53:24, Shawn Guo wrote:
 On Wed, Jun 24, 2015 at 02:03:41PM +0530, Sanchayan Maity wrote:
  Add a device tree property which allows to specify the minimum sample
  time which can be used to calculate the actual ADC cycles required
  depending on the hardware.
  
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
  ---
   arch/arm/boot/dts/vfxxx.dtsi | 2 ++
   1 file changed, 2 insertions(+)
  
  diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
  index 90a03d5..71d9c08 100644
  --- a/arch/arm/boot/dts/vfxxx.dtsi
  +++ b/arch/arm/boot/dts/vfxxx.dtsi
  @@ -229,6 +229,7 @@
  status = disabled;
  fsl,adck-max-frequency = 3000, 4000,
  2000;
  +   min-sample-time = 1000;
  };
   
  wdoga5: wdog@4003e000 {
  @@ -447,6 +448,7 @@
  status = disabled;
  fsl,adck-max-frequency = 3000, 4000,
  2000;
  +   min-sample-time = 1000;
 
 Can we code 1000 as the default in kernel driver, so that only boards
 requiring different value need to have this property?  Doing so makes
 the property optional rather than required.
 

Not sure if hardcoding it in the driver is the right approach.

However if the maintainers and others agree on doing this, I will do
the necessary change.

Thanks.

Regards,
Sanchayan.
--
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: [RFC PATCH v6 3/3] drivers: nvmem: Add Vybrid OCOTP support

2015-07-10 Thread maitysanchayan

Hello Stefan,

On 15-07-08 22:55:23, Stefan Wahren wrote:
 Hi Sanchayan,
 
  maitysancha...@gmail.com hat am 8. Juli 2015 um 07:39 geschrieben:
 
 
  [...]

 Looking at valid_fuse_addr shows me 0x3F as last valid register. So 
 the
 rest
 of the buffer ( 0xD00 - sizeof(valid_fuse_addr) ) in case of raw 
 access
 could be
 uninitializied.
   
Sorry I did not exactly get you here. The intention behind using the
valid_fuse_addr
is to allow reading only from valid fuse addresses and avoid reading 
from
all
other
locations as per the Fuse map address table 35-1.
  
   Yes, i got your intention. But from my unterstand the read function should
   fill
   up
   the complete buffer with defined values. My MXS OCOTP driver have the same
   problem
   and fill up the invalid registers with zero.
 
  I must admit I had not thought of that. Thats a valid point. I dont know at
  the
  moment however what would be the correct approach here. Perhaps filling
  locations
  other than the valid fuse addresses as per the fuse map table with 
  0xBADABADA
  is
  the right thing? Anyways that's what is going to be returned if we were to
  read
  a location which is read locked or reserved.
 
 since we are operating in userspace the behavior shouldn't be specific to the
 device.
 It would be good when all drivers behave the same. But i think it would be 
 much
 better
 as the nvmem framework take care of it and preinit the buffer with a defined
 value.

There is a v7 now. Yet to give that a try or look at it.

 
 
  However since the fuse address and base address mapping is not exactly 
  linear,
  this would require some additional logic than the simple thing I did. 
 
 I defined a regmap_access_table for valid read registers in my case. But i 
 think
 in your case
 an implementation of the readable_reg callback in the regmap_config would be
 more elegant.
 
 You can validate your implementation under /sys/kernel/debug/regmap/

Thank you for the input. I will have a look at it and give it a try.

 
 Sorry, i'm a newbie to regmap.

Same here as well :)

Regards,
Sanchayan.
--
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] ARM: dts: vfxxx: Add iio_hwmon node for ADC temperature channel

2015-09-07 Thread maitysanchayan

Hi Shawn,

On 15-09-06 12:32:32, Shawn Guo wrote:
> On Thu, Aug 06, 2015 at 09:28:22PM +0530, Sanchayan Maity wrote:
> > Add iio_hwmon node to expose the temperature channel on Vybrid
> > as hardware monitor device using the iio_hwmon driver.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  arch/arm/boot/dts/vfxxx.dtsi | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> > index 39173bb..0993d66 100644
> > --- a/arch/arm/boot/dts/vfxxx.dtsi
> > +++ b/arch/arm/boot/dts/vfxxx.dtsi
> > @@ -597,5 +597,10 @@
> > status = "disabled";
> > };
> > };
> > +
> > +   iio_hwmon {
> 
> Hyphen rather than underscore should be used in node name.

As per iio-bindings.txt I did this. It is the same in imx23.dtsi and imx28.dtsi.

http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/iio/iio-bindings.txt#L85
http://lxr.free-electrons.com/source/arch/arm/boot/dts/imx23.dtsi#L570
http://lxr.free-electrons.com/source/arch/arm/boot/dts/imx28.dtsi#L1246

So should this be changed?

Thanks.

- Sanchayan.

> 
> Shawn
> 
> > +   compatible = "iio-hwmon";
> > +   io-channels = < 16>;
> > +   };
> > };
> >  };
> > -- 
> > 2.5.0
> > 
--
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 v9 1/4] clk: clk-vf610: Add clock for Vybrid OCOTP controller

On 15-09-06 16:15:26, Shawn Guo wrote:
> On Wed, Aug 12, 2015 at 06:49:18PM +0530, Sanchayan Maity wrote:
> > Add clock support for Vybrid On-Chip One Time Programmable
> > (OCOTP) controller.
> > 
> > While the OCOTP block does not require explicit clock gating,
> > for programming the OCOTP timing register the clock rate of
> > ipg clock is required for timing calculations related to fuse
> > and shadow register read sequence. We explicitly specify the
> > ipg clock for OCOTP as a result.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  drivers/clk/imx/clk-vf610.c | 1 +
> >  include/dt-bindings/clock/vf610-clock.h | 3 ++-
> >  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> Please copy linux-clk list and clock maintainers on i.MX clock patches
> as well.  If you run ./scripts/get_maintainer.pl on the patch, you will
> get them.

Ok. Will take care of this with the next version. Thanks.

- Sanchayan.

> 
> Shawn
> 
> > 
> > diff --git a/drivers/clk/imx/clk-vf610.c b/drivers/clk/imx/clk-vf610.c
> > index bff45ea..d1b1c95 100644
> > --- a/drivers/clk/imx/clk-vf610.c
> > +++ b/drivers/clk/imx/clk-vf610.c
> > @@ -387,6 +387,7 @@ static void __init vf610_clocks_init(struct device_node 
> > *ccm_node)
> >  
> > clk[VF610_CLK_SNVS] = imx_clk_gate2("snvs-rtc", "ipg_bus", CCM_CCGR6, 
> > CCM_CCGRx_CGn(7));
> > clk[VF610_CLK_DAP] = imx_clk_gate("dap", "platform_bus", CCM_CCSR, 24);
> > +   clk[VF610_CLK_OCOTP] = imx_clk_gate("ocotp", "ipg_bus", CCM_CCGR6, 
> > CCM_CCGRx_CGn(5));
> >  
> > imx_check_clocks(clk, ARRAY_SIZE(clk));
> >  
> > diff --git a/include/dt-bindings/clock/vf610-clock.h 
> > b/include/dt-bindings/clock/vf610-clock.h
> > index d197634..56c16aa 100644
> > --- a/include/dt-bindings/clock/vf610-clock.h
> > +++ b/include/dt-bindings/clock/vf610-clock.h
> > @@ -194,6 +194,7 @@
> >  #define VF610_PLL7_BYPASS  181
> >  #define VF610_CLK_SNVS 182
> >  #define VF610_CLK_DAP  183
> > -#define VF610_CLK_END  184
> > +#define VF610_CLK_OCOTP 184
> > +#define VF610_CLK_END  185
> >  
> >  #endif /* __DT_BINDINGS_CLOCK_VF610_H */
> > -- 
> > 2.5.0
> > 
--
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 v9 4/4] nvmem: Add DT binding documentation for Vybrid OCOTP driver

On 15-09-06 16:13:35, Shawn Guo wrote:
> On Wed, Aug 12, 2015 at 06:49:21PM +0530, Sanchayan Maity wrote:
> > Add the devicetree bindings for the Freescale Vybrid On-Chip
> > OTP driver.
> > 
> > Signed-off-by: Sanchayan Maity 
> > Acked-by: Srinivas Kandagatla 
> > ---
> >  .../devicetree/bindings/nvmem/vf610-ocotp.txt   | 21 
> > +
> >  1 file changed, 21 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt 
> > b/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
> > new file mode 100644
> > index 000..b29f65f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
> > @@ -0,0 +1,21 @@
> > +On-Chip OTP Memory for Freescale Vybrid
> > +
> > +Required Properties:
> > +  compatible:
> > +  - "fsl,vf610-ocotp" for VF5xx/VF6xx
> > +  #address-cells : Should be 1
> > +  #size-cells : Should be 1
> > +  reg : Address and length of OTP controller and fuse map registers
> > +  clocks : ipg clock we associate with the OCOTP peripheral
> > +  clock-names : Must contain "ocotp" as matching entry
> 
> I'm not sure "ocotp" is a good name for describing a clock from OCOTP
> internal point of view.  "ipg" might be better.  But I would suggest you
> drop clock-names property completely, if "ipg" is the only clock you
> need to describe here.  The clock-names is necessary only when there are
> multiple clocks to distinguish.
> 
> With clock-names dropped, the driver works by passing NULL as the second
> parameter to devm_clk_get() call.

Ok. Will drop the clock-names property retest and try sending it by tomorrow.

- Sanchayan.

> 
> Shawn
> 
> > +
> > +Example for Vybrid VF5xx/VF6xx:
> > +
> > +   ocotp: ocotp@400a5000 {
> > +   compatible = "fsl,vf610-ocotp";
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   reg = <0x400a5000 0xCF0>;
> > +   clocks = < VF610_CLK_OCOTP>;
> > +   clock-names = "ocotp";
> > +   };
> > -- 
> > 2.5.0
> > 
--
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 v9 0/4] Implement OCOTP driver for Vybrid using NVMEM

2015-09-03 Thread maitysanchayan

Hello,

Ping? Anything preventing this from being accepted? I can rework it then if
so.

Thanks.

- Sanchayan.

On 15-08-12 18:49:17, Sanchayan Maity wrote:
> Hello,
> 
> This patchset is based on top of v9 of Srinivas's NVMEM framework patches.
> Tested on Greg's tree char-misc-next branch along with Stefan's NAND driver
> patchset.
> 
> Sample output on Colibri VF50
> 
> root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# uname -a
> Linux colibri-vf 4.2.0-rc6-00130-g24fcfdc #3 SMP Wed Aug 12 18:31:24 IST 2015 
> armv7l GNU/Linux
> 
> root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# hexdump nvmem
> 000        
> *
> 410 72a6 df64      
> 420 11d4 2c14      
> 430        
> *
> 450 0280       
> 460        
> *
> 880 8f01       
> 890        
> *
> 8c0  1000      
> 8d0 3202 0800      
> 8e0  e100      
> 8f0        
> *
> c80 bada bada      
> *
> cc0        
> *
> cf0
> 
> The driver has changed quite a bit from the first version
> relying on of_platform_populate in mach file, to using
> SoC driver under drivers/soc and finally to NVMEM.
> 
> Feedback and comments most welcome.
> 
> Version 8 patches can be found here
> https://lkml.org/lkml/2015/8/10/566
> 
> Version 7 patches can be found here
> https://lkml.org/lkml/2015/8/6/440
> 
> Version 6 RFC patches can be found here
> http://lkml.iu.edu/hypermail/linux/kernel/1506.2/05123.html
> 
> Version 5 of the patchset can be found here
> http://lkml.iu.edu/hypermail/linux/kernel/1506.0/03787.html
> 
> Version 4 of the patchset can be found here
> https://lkml.org/lkml/2015/5/26/199
> 
> Version 3 of the patchset can be found here
> http://www.spinics.net/lists/arm-kernel/msg420847.html
> 
> Version 2 of the patchset can be found here
> http://www.spinics.net/lists/devicetree/msg80654.html
> 
> Version 1 of the patchset can be found here
> http://www.spinics.net/lists/devicetree/msg80257.html
> 
> The RFC version can be found here
> https://lkml.org/lkml/2015/5/11/13
> 
> Changes since v8:
> 1. Fix three lines over 80 characters
> 2. Rebase on top of Greg's char-misc-next branch
> 
> Changes since v7:
> 1. Add COMPILE_TEST to Kconfig
> 2. Use GENMASK and BIT macros where applicable
> 3. Fix a code alignment issue
> 4. Get the max_register value for regmap config using
> resource_size()
> 5. Also add copyright info as the driver logic is based off
> on ocotp code in barebox
> 6. Add missing info related to clock in DT binding doc
> 
> Changes since v6:
> 1. Use the v9 of NVMEM framework patchset
> 2. Add a few comments
> 3. Initialise buffer address not part of the fuse map to 0
> instead of only handling buffer locations with valid fuse
> addresses.
> 
> Changes since v5:
> Use NVMEM framework by Srinivas and Maxime
> 
> Changes since v4:
> 1. Use devm_* family of functions and use a struct to get rid of
> global variables (suggested by Joachim Eastwood)
> 2. Make Kconfig govern the compilation with tristate, instead of
> earlier bool. Paul Bolle raised a valid point that perhaps this
> should have been built in with the bool, however I had not taken
> into consideration generic distro kernels and it makes sense to
> have this tristated. (comments from Paul Bolle and Andreas Farber)
> 
> Changes since v3:
> Instead of using the syscon_regmap_lookup_by_compatible function
> use a phandle in the device tree along with offsets specified in
> this phandle node and then read the offset along with the device
> node in the driver for reading from the required region.
> 
> Changes since v2:
> Implement the SoC bus code as a driver in drivers/soc
> by registering with fsl,mscm-cpucfg as per Arnd's feedback
> 
> Changes since v1:
> Sort the headers in alphabetical order
> 
> Changes since RFC:
> Use a DT entry for the ROM area while specifying it as syscon.
> 
> Thanks & Regards,
> Sanchayan Maity.
> 
> Sanchayan Maity (4):
>   clk: clk-vf610: Add clock for Vybrid OCOTP controller
>   ARM: dts: vfxxx: Add OCOTP node
>   drivers: nvmem: Add Vybrid OCOTP support
>   nvmem: Add DT binding documentation for Vybrid OCOTP driver
> 
>  .../devicetree/bindings/nvmem/vf610-ocotp.txt  |  21 ++
>  arch/arm/boot/dts/vfxxx.dtsi   |   9 +
>  drivers/clk/imx/clk-vf610.c|   1 +
>  drivers/nvmem/Kconfig  |  10 +
>  drivers/nvmem/Makefile |   2 +
>  drivers/nvmem/vf610-ocotp.c| 302 
> +
>  include/dt-bindings/clock/vf610-clock.h|   3 +-
>  7 files changed, 347 insertions(+), 1

Re: [PATCH v9 0/4] Implement OCOTP driver for Vybrid using NVMEM

2015-09-04 Thread maitysanchayan

Hi,

On 15-09-04 09:21:04, Srinivas Kandagatla wrote:
> Hi Sanchayan,
> 
> On 04/09/15 06:50, maitysancha...@gmail.com wrote:
> > Hello,
> >
> > Ping? Anything preventing this from being accepted? I can rework it then if
> > so.
> Thanks for your patience,
> 
> We are in the middle of merge window, I will pick the driver for 4.4 
> after 4.3-rc1 is released for linux-next testing.

Thank you very much for the update Srinivas.

- Sanchayan.

> 
> --srini
> 
> >
> > Thanks.
> >
> > - Sanchayan.
> >
> > On 15-08-12 18:49:17, Sanchayan Maity wrote:
> >> Hello,
> >>
> >> This patchset is based on top of v9 of Srinivas's NVMEM framework patches.
> >> Tested on Greg's tree char-misc-next branch along with Stefan's NAND driver
> >> patchset.
> >>
> >> Sample output on Colibri VF50
> >>
> >> root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# uname -a
> >> Linux colibri-vf 4.2.0-rc6-00130-g24fcfdc #3 SMP Wed Aug 12 18:31:24 IST 
> >> 2015 armv7l GNU/Linux
> >>
> >> root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# hexdump nvmem
> >> 000        
> >> *
> >> 410 72a6 df64      
> >> 420 11d4 2c14      
> >> 430        
> >> *
> >> 450 0280       
> >> 460        
> >> *
> >> 880 8f01       
> >> 890        
> >> *
> >> 8c0  1000      
> >> 8d0 3202 0800      
> >> 8e0  e100      
> >> 8f0        
> >> *
> >> c80 bada bada      
> >> *
> >> cc0        
> >> *
> >> cf0
> >>
> >> The driver has changed quite a bit from the first version
> >> relying on of_platform_populate in mach file, to using
> >> SoC driver under drivers/soc and finally to NVMEM.
> >>
> >> Feedback and comments most welcome.
> >>
> >> Version 8 patches can be found here
> >> https://lkml.org/lkml/2015/8/10/566
> >>
> >> Version 7 patches can be found here
> >> https://lkml.org/lkml/2015/8/6/440
> >>
> >> Version 6 RFC patches can be found here
> >> http://lkml.iu.edu/hypermail/linux/kernel/1506.2/05123.html
> >>
> >> Version 5 of the patchset can be found here
> >> http://lkml.iu.edu/hypermail/linux/kernel/1506.0/03787.html
> >>
> >> Version 4 of the patchset can be found here
> >> https://lkml.org/lkml/2015/5/26/199
> >>
> >> Version 3 of the patchset can be found here
> >> http://www.spinics.net/lists/arm-kernel/msg420847.html
> >>
> >> Version 2 of the patchset can be found here
> >> http://www.spinics.net/lists/devicetree/msg80654.html
> >>
> >> Version 1 of the patchset can be found here
> >> http://www.spinics.net/lists/devicetree/msg80257.html
> >>
> >> The RFC version can be found here
> >> https://lkml.org/lkml/2015/5/11/13
> >>
> >> Changes since v8:
> >> 1. Fix three lines over 80 characters
> >> 2. Rebase on top of Greg's char-misc-next branch
> >>
> >> Changes since v7:
> >> 1. Add COMPILE_TEST to Kconfig
> >> 2. Use GENMASK and BIT macros where applicable
> >> 3. Fix a code alignment issue
> >> 4. Get the max_register value for regmap config using
> >> resource_size()
> >> 5. Also add copyright info as the driver logic is based off
> >> on ocotp code in barebox
> >> 6. Add missing info related to clock in DT binding doc
> >>
> >> Changes since v6:
> >> 1. Use the v9 of NVMEM framework patchset
> >> 2. Add a few comments
> >> 3. Initialise buffer address not part of the fuse map to 0
> >> instead of only handling buffer locations with valid fuse
> >> addresses.
> >>
> >> Changes since v5:
> >> Use NVMEM framework by Srinivas and Maxime
> >>
> >> Changes since v4:
> >> 1. Use devm_* family of functions and use a struct to get rid of
> >> global variables (suggested by Joachim Eastwood)
> >> 2. Make Kconfig govern the compilation with tristate, instead of
> >> earlier bool. Paul Bolle raised a valid point that perhaps this
> >> should have been built in with the bool, however I had not taken
> >> into consideration generic distro kernels and it makes sense to
> >> have this tristated. (comments from Paul Bolle and Andreas Farber)
> >>
> >> Changes since v3:
> >> Instead of using the syscon_regmap_lookup_by_compatible function
> >> use a phandle in the device tree along with offsets specified in
> >> this phandle node and then read the offset along with the device
> >> node in the driver for reading from the required region.
> >>
> >> Changes since v2:
> >> Implement the SoC bus code as a driver in drivers/soc
> >> by registering with fsl,mscm-cpucfg as per Arnd's feedback
> >>
> >> Changes since v1:
> >> Sort the headers in alphabetical order
> >>
> >> Changes since RFC:
> >> Use a DT entry for the ROM area while specifying it as syscon.
> >>
> >> Thanks & Regards,
> >> Sanchayan Maity.
> >>
>

Re: [PATCH v5 1/3] ARM: dts: vf500-colibri: Add device tree node for touchscreen support

2015-09-29 Thread maitysanchayan

Hello Shawn,

The driver has landed in your tree. Can you queue this DT change for the same?

Thanks.

- Sanchayan.

On 15-09-01 18:06:53, Sanchayan Maity wrote:
> Add device tree node for touchscreen support on Colibri VF50. The
> touchscreen functionality on VF50 uses the ADC channels of Vybrid
> and some GPIOs. Also add pinctrl nodes for proper pinmux.
> 
> Signed-off-by: Sanchayan Maity 
> ---
>  arch/arm/boot/dts/vf500-colibri-eval-v3.dts |  5 +++
>  arch/arm/boot/dts/vf500-colibri.dtsi| 47 
> +
>  2 files changed, 52 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/vf500-colibri-eval-v3.dts 
> b/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> index 7fc782c..c3173fc 100644
> --- a/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> +++ b/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> @@ -15,3 +15,8 @@
>   model = "Toradex Colibri VF50 on Colibri Evaluation Board";
>   compatible = "toradex,vf500-colibri_vf50-on-eval", 
> "toradex,vf500-colibri_vf50", "fsl,vf500";
>  };
> +
> + {
> + vf50-ts-min-pressure = <200>;
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/vf500-colibri.dtsi 
> b/arch/arm/boot/dts/vf500-colibri.dtsi
> index cee34a3..84f091d 100644
> --- a/arch/arm/boot/dts/vf500-colibri.dtsi
> +++ b/arch/arm/boot/dts/vf500-colibri.dtsi
> @@ -17,4 +17,51 @@
>   memory {
>   reg = <0x8000 0x800>;
>   };
> +
> + touchscreen: vf50-touchscreen {
> + compatible = "toradex,vf50-touchscreen";
> + io-channels = < 0>,< 0>,
> + < 1>,< 2>;
> + xp-gpios = < 13 GPIO_ACTIVE_LOW>;
> + xm-gpios = < 29 GPIO_ACTIVE_HIGH>;
> + yp-gpios = < 12 GPIO_ACTIVE_LOW>;
> + ym-gpios = < 4 GPIO_ACTIVE_HIGH>;
> + interrupt-parent = <>;
> + interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
> + pinctrl-names = "idle","default","gpios";
> + pinctrl-0 = <_touchctrl_idle>;
> + pinctrl-1 = <_touchctrl_default>;
> + pinctrl-2 = <_touchctrl_gpios>;
> + vf50-ts-min-pressure = <200>;
> + status = "disabled";
> + };
> +};
> +
> + {
> + vf610-colibri {
> + pinctrl_touchctrl_idle: touchctrl_idle {
> + fsl,pins = <
> + VF610_PAD_PTA18__GPIO_8 0x006d
> + VF610_PAD_PTA19__GPIO_9 0x006c
> + >;
> + };
> +
> + pinctrl_touchctrl_default: touchctrl_default {
> + fsl,pins = <
> + VF610_PAD_PTA18__ADC0_SE0   0x0040
> + VF610_PAD_PTA19__ADC0_SE1   0x0040
> + VF610_PAD_PTA16__ADC1_SE0   0x0040
> + VF610_PAD_PTB2__ADC1_SE20x0040
> + >;
> + };
> +
> + pinctrl_touchctrl_gpios: touchctrl_gpios {
> + fsl,pins = <
> + VF610_PAD_PTA23__GPIO_130x22e9
> + VF610_PAD_PTB23__GPIO_930x22e9
> + VF610_PAD_PTA22__GPIO_120x22e9
> + VF610_PAD_PTA11__GPIO_4 0x22e9
> + >;
> + };
> + };
>  };
> -- 
> 2.5.0
> 
--
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 v10 0/4] Implement OCOTP driver for Vybrid using NVMEM

2015-09-21 Thread maitysanchayan

Hello,

Ping?

- Sanchayan.

On 15-09-07 13:51:34, Sanchayan Maity wrote:
> Hello,
> 
> Tested on Greg's tree char-misc-next branch along with Stefan's NAND driver
> patchset.
> 
> Sample output on Colibri VF50
> 
> root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# uname -a
> Linux colibri-vf 4.2.0-rc6-9-g1cec223 #5 SMP Mon Sep 7 12:34:37 IST 2015 
> armv7l GNU/Linux
> 
> root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# hexdump nvmem
> 000        
> *
> 410 72a6 df64      
> 420 11d4 2006      
> 430        
> *
> 450 0280       
> 460        
> *
> 880 8f01       
> 890        
> *
> 8c0  1300      
> 8d0 320a 0800      
> 8e0  e200      
> 8f0        
> *
> c80 bada bada      
> *
> cc0        
> *
> cf0
> 
> Changes since v9:
> 1. Drop clock-names property from DT
> 2. Rebase on top of latest char-misc-next
> 
> Changes since v8:
> 1. Fix three lines over 80 characters
> 2. Rebase on top of Greg's char-misc-next branch
> 
> Changes since v7:
> 1. Add COMPILE_TEST to Kconfig
> 2. Use GENMASK and BIT macros where applicable
> 3. Fix a code alignment issue
> 4. Get the max_register value for regmap config using
> resource_size()
> 5. Also add copyright info as the driver logic is based off
> on ocotp code in barebox
> 6. Add missing info related to clock in DT binding doc
> 
> Changes since v6:
> 1. Use the v9 of NVMEM framework patchset
> 2. Add a few comments
> 3. Initialise buffer address not part of the fuse map to 0
> instead of only handling buffer locations with valid fuse
> addresses.
> 
> Changes since v5:
> Use NVMEM framework by Srinivas and Maxime
> 
> Changes since v4:
> 1. Use devm_* family of functions and use a struct to get rid of
> global variables (suggested by Joachim Eastwood)
> 2. Make Kconfig govern the compilation with tristate, instead of
> earlier bool. Paul Bolle raised a valid point that perhaps this
> should have been built in with the bool, however I had not taken
> into consideration generic distro kernels and it makes sense to
> have this tristated. (comments from Paul Bolle and Andreas Farber)
> 
> Changes since v3:
> Instead of using the syscon_regmap_lookup_by_compatible function
> use a phandle in the device tree along with offsets specified in
> this phandle node and then read the offset along with the device
> node in the driver for reading from the required region.
> 
> Changes since v2:
> Implement the SoC bus code as a driver in drivers/soc
> by registering with fsl,mscm-cpucfg as per Arnd's feedback
> 
> Changes since v1:
> Sort the headers in alphabetical order
> 
> Changes since RFC:
> Use a DT entry for the ROM area while specifying it as syscon.
> 
> Version 9 patches can be found here
> https://lkml.org/lkml/2015/8/12/530
> 
> Version 8 patches can be found here
> https://lkml.org/lkml/2015/8/10/566
> 
> Version 7 patches can be found here
> https://lkml.org/lkml/2015/8/6/440
> 
> Version 6 RFC patches can be found here
> http://lkml.iu.edu/hypermail/linux/kernel/1506.2/05123.html
> 
> Version 5 of the patchset can be found here
> http://lkml.iu.edu/hypermail/linux/kernel/1506.0/03787.html
> 
> Version 4 of the patchset can be found here
> https://lkml.org/lkml/2015/5/26/199
> 
> Version 3 of the patchset can be found here
> http://www.spinics.net/lists/arm-kernel/msg420847.html
> 
> Version 2 of the patchset can be found here
> http://www.spinics.net/lists/devicetree/msg80654.html
> 
> Version 1 of the patchset can be found here
> http://www.spinics.net/lists/devicetree/msg80257.html
> 
> The RFC version can be found here
> https://lkml.org/lkml/2015/5/11/13
> 
> Thanks & Regards,
> Sanchayan Maity.
> 
> Sanchayan Maity (4):
>   clk: clk-vf610: Add clock for Vybrid OCOTP controller
>   ARM: dts: vfxxx: Add OCOTP node
>   drivers: nvmem: Add Vybrid OCOTP support
>   nvmem: Add DT binding documentation for Vybrid OCOTP driver
> 
>  .../devicetree/bindings/nvmem/vf610-ocotp.txt  |  19 ++
>  arch/arm/boot/dts/vfxxx.dtsi   |   8 +
>  drivers/clk/imx/clk-vf610.c|   1 +
>  drivers/nvmem/Kconfig  |  10 +
>  drivers/nvmem/Makefile |   2 +
>  drivers/nvmem/vf610-ocotp.c| 302 
> +
>  include/dt-bindings/clock/vf610-clock.h|   3 +-
>  7 files changed, 344 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
>  create mode 100644 drivers/nvmem/vf610-ocotp.c
> 
> -- 
> 2.5.1
> 
--
To unsubscribe from this list:

Re: touchscreen: edt-ft5x06: Prevent DMA driver from mapping an area on stack

2015-12-13 Thread maitysanchayan

Hello,

On 15-12-12 20:42:37, Dmitry Torokhov wrote:
> On Sat, Dec 12, 2015 at 06:13:55PM +0100, Wolfram Sang wrote:
> > 
> > > Frankly speaking I do not know where the fix should actually be. I2C IMX
> > > driver somehow taking care of this or the users of I2C, touchscreen 
> > > drivers
> > > in this case. In my opinion, the fix should be with the touchscreen driver
> > > however I did like to have feedback or hear opinions on what is the 
> > > accepted
> > > solution to this.
> > 
> > There is no accepted solution to this yet :( DMA is/was still too rare for
> > a serious discussion about this. There is also [1] and probably more...
> > 
> > [1]  http://patchwork.ozlabs.org/patch/220137/
> 
> I believe vast majority of i2c client drivers do not expect that the
> transfer buffer they supply in i2c messages are supposed to be DMAable
> (unlike USB and SPI buses that had that requirement from the beginning).
> 
> I won't be applying this patch unless we decide that I2C changes the
> rules.

Understood. Thanks for the clarifications Dmitry and Wolfram.

- Sanchayan.
--
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] ARM: dts: vfxxx: Fix erroneous property in esdhc0 node

2015-11-20 Thread maitysanchayan

Ping?

On 15-10-18 11:18:48, Sanchayan Maity wrote:
> Something seems to have gone wrong during the merging of the device
> tree changes with the following patch
> 
> "ARM: dts: add property for maximum ADC clock frequencies"
> 
> The property "fsl,adck-max-frequency" instead of being applied for
> the ADC1 node got applied to the esdhc0 node. This patch fixes it.
> 
> Signed-off-by: Sanchayan Maity 
> ---
>  arch/arm/boot/dts/vfxxx.dtsi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> index 6736bae..a64bfe1 100644
> --- a/arch/arm/boot/dts/vfxxx.dtsi
> +++ b/arch/arm/boot/dts/vfxxx.dtsi
> @@ -461,6 +461,8 @@
>   clock-names = "adc";
>   #io-channel-cells = <1>;
>   status = "disabled";
> + fsl,adck-max-frequency = <3000>, <4000>,
> + <2000>;
>   };
>  
>   esdhc0: esdhc@400b1000 {
> @@ -472,8 +474,6 @@
>   < VF610_CLK_ESDHC0>;
>   clock-names = "ipg", "ahb", "per";
>   status = "disabled";
> - fsl,adck-max-frequency = <3000>, <4000>,
> - <2000>;
>   };
>  
>   esdhc1: esdhc@400b2000 {
> -- 
> 2.6.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 v3 4/4] soc: Add SoC driver for Freescale Vybrid platform

2016-06-09 Thread maitysanchayan

Hello Rob,

On 16-05-27 15:38:17, maitysancha...@gmail.com wrote:
> On 16-05-27 10:31:55, Arnd Bergmann wrote:
> > On Friday, May 27, 2016 12:03:01 PM CEST maitysancha...@gmail.com wrote:
> > > 
> > > So if I understand correctly, the binding at the SoC level is fine.
> > > Keeping that but removing the additional made-up properties, viz. below
> > > 
> > > rom-revision: phandle to the on-chip ROM node
> > > mscm: phandle to the MSCM CPU configuration node
> > > nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> > > nvmem-cell-names: should contain string names "cfg0" and "cfg1"
> > > 
> > > would be fine?
> > > 
> > > We would have something similar to here
> > > http://www.spinics.net/lists/devicetree/msg80655.html
> > > 
> > > but now with the DT binding under SoC bus.
> > > 
> > 
> > 
> > You look up the OTP device as a syscon here, which seems odd since there
> > is already an nvmem driver for it. Shouldn't you use the nvmem API for
> > that?
> > 
> > Arnd
> 
> I need the following 
> 
> nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> nvmem-cell-names: should contain string names "cfg0" and "cfg1"
> 
> to be able to use the NVMEM consumer API.
> 
> If I can put them at SoC node level then I certainly can use the NVMEM API.
> 

Would the following be acceptable at the SoC node level

> nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> nvmem-cell-names: should contain string names "cfg0" and "cfg1"

Regards,
Sanchayan.

Re: [PATCH v3 4/4] soc: Add SoC driver for Freescale Vybrid platform

2016-05-27 Thread maitysanchayan

On 16-05-27 10:31:55, Arnd Bergmann wrote:
> On Friday, May 27, 2016 12:03:01 PM CEST maitysancha...@gmail.com wrote:
> > 
> > So if I understand correctly, the binding at the SoC level is fine.
> > Keeping that but removing the additional made-up properties, viz. below
> > 
> > rom-revision: phandle to the on-chip ROM node
> > mscm: phandle to the MSCM CPU configuration node
> > nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> > nvmem-cell-names: should contain string names "cfg0" and "cfg1"
> > 
> > would be fine?
> > 
> > We would have something similar to here
> > http://www.spinics.net/lists/devicetree/msg80655.html
> > 
> > but now with the DT binding under SoC bus.
> > 
> 
> 
> You look up the OTP device as a syscon here, which seems odd since there
> is already an nvmem driver for it. Shouldn't you use the nvmem API for
> that?
> 
>   Arnd

I need the following 

nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
nvmem-cell-names: should contain string names "cfg0" and "cfg1"

to be able to use the NVMEM consumer API.

If I can put them at SoC node level then I certainly can use the NVMEM API.

Regards,
Sanchayan.

Re: [PATCH v3 4/4] soc: Add SoC driver for Freescale Vybrid platform

2016-05-27 Thread maitysanchayan

Hello Stefan,

On 16-05-27 10:28:45, Stefan Agner wrote:
> On 2016-05-27 03:08, maitysancha...@gmail.com wrote:
> > On 16-05-27 10:31:55, Arnd Bergmann wrote:
> >> On Friday, May 27, 2016 12:03:01 PM CEST maitysancha...@gmail.com wrote:
> >> >
> >> > So if I understand correctly, the binding at the SoC level is fine.
> >> > Keeping that but removing the additional made-up properties, viz. below
> >> >
> >> > rom-revision: phandle to the on-chip ROM node
> >> > mscm: phandle to the MSCM CPU configuration node
> >> > nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> >> > nvmem-cell-names: should contain string names "cfg0" and "cfg1"
> >> >
> >> > would be fine?
> >> >
> >> > We would have something similar to here
> >> > http://www.spinics.net/lists/devicetree/msg80655.html
> >> >
> >> > but now with the DT binding under SoC bus.
> >> >
> >>
> >>
> >> You look up the OTP device as a syscon here, which seems odd since there
> >> is already an nvmem driver for it. Shouldn't you use the nvmem API for
> >> that?
> >>
> >>Arnd
> > 
> > I need the following 
> > 
> > nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> > nvmem-cell-names: should contain string names "cfg0" and "cfg1"
> > 
> > to be able to use the NVMEM consumer API.
> 
> I did not tested it, but it seems the NVMEM consumer API has some kind
> of non-DT fallback:
> http://lxr.free-electrons.com/source/drivers/nvmem/core.c#L827
> 
> Right now, it seems to me that it does not handle the case where we have
> a of_node but don't want to use it... You might need to add some extra
> handling if there is a of_node without nvmem-cell-names/nvmem-cells, and
> fall back to nvmem_cell_get_from_list.
> 

I have already looked at the core nvmem code for options but wanted to avoid
any additons if possible.

However if adding the nvmem properties at the SoC node level is frowned upon
I will make the necessary changes required.

Regards,
Sanchayan.

Re: [PATCH v3 4/4] soc: Add SoC driver for Freescale Vybrid platform

2016-05-27 Thread maitysanchayan

Hello Rob,

On 16-05-24 12:09:41, Rob Herring wrote:
> On Mon, May 23, 2016 at 11:14 PM,   wrote:
> > Hello Rob,
> >
> > On 16-05-23 16:18:13, Rob Herring wrote:
> >> On Fri, May 20, 2016 at 03:32:05PM +0530, Sanchayan Maity wrote:
> >> > This adds a SoC driver to be used by Freescale Vybrid SoC's.
> >> > Driver utilises syscon and nvmem consumer API's to get the
> >> > various register values needed and expose the SoC specific
> >> > properties via sysfs.
> >> >
> >> > A sample output from Colibri Vybrid VF61 is below:
> >> >
> >> > root@colibri-vf:~# cd /sys/bus/soc/devices/soc0
> >> > root@colibri-vf:/sys/bus/soc/devices/soc0# ls
> >> > family machinepower  revision   soc_id subsystem  uevent
> >> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat family
> >> > Freescale Vybrid VF610
> >> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat machine
> >> > Freescale Vybrid
> >> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat revision
> >> > 0013
> >> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat soc_id
> >> > df6472a6130f29d4
> >> >
> >> > Signed-off-by: Sanchayan Maity 
> >> > ---
> >> >  .../bindings/arm/freescale/fsl,vf610-soc.txt   |  20 +++
> >> >  drivers/soc/Kconfig|   1 +
> >> >  drivers/soc/fsl/Kconfig|  10 ++
> >> >  drivers/soc/fsl/Makefile   |   1 +
> >> >  drivers/soc/fsl/soc-vf610.c| 198 
> >> > +
> >> >  5 files changed, 230 insertions(+)
> >> >  create mode 100644 
> >> > Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> >> >  create mode 100644 drivers/soc/fsl/Kconfig
> >> >  create mode 100644 drivers/soc/fsl/soc-vf610.c
> >> >
> >> > diff --git 
> >> > a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt 
> >> > b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> >> > new file mode 100644
> >> > index 000..338905d
> >> > --- /dev/null
> >> > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> >> > @@ -0,0 +1,20 @@
> >> > +Vybrid System-on-Chip
> >> > +-
> >> > +
> >> > +Required properties:
> >> > +
> >> > +- compatible: "fsl,vf610-soc"
> >> > +- rom-revision: phandle to the on-chip ROM node
> >> > +- mscm: phandle to the MSCM CPU configuration node
> >> > +- nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and 
> >> > ocotp_cfg1
> >> > +- nvmem-cell-names: should contain string names "cfg0" and "cfg1"
> >>
> >> I still have similar concerns as the discussion on the last version.
> >> This version only proves that you aren't describing h/w, but rather just
> >> a collection of data that some driver wants.
> >>
> >> A driver can just as easily look-up all the nodes directly that these
> >> phandles point to.
> >
> > Agreed, that we can look up all the nodes directly that these phandles
> > refer to but I would still need a DT entry to bind to. While I could
> > bind to existing nodes like mscm cpucfg but that doesn't seem right.
> >
> > The very first approach that we had taken was to integrate this 
> > functionality
> > in mach-vf610.c code under mach-imx
> > http://www.spinics.net/lists/devicetree/msg80654.html
> 
> Yes, everyone wants to move all platform devices in the kernel to a
> corresponding DT node. The result is often making up nodes to do this.
> It's the same thing with cpufreq.
> 
> > and then it was recommended to migrate this to drivers/soc where we did use
> > phandles or direct look up via compatible strings
> 
> The location in the tree is an orthogonal issue. You could move it and
> use of_machine_is_compatible without any DT change.
> 
> The primary issue I have here is how do we bind soc_bus to DT in a
> consistent way. Sorry, but vybrid specific patches alone are never
> going to solve that issue.
> 
> > http://www.spinics.net/lists/arm-kernel/msg420847.html
> >
> > and
> >
> > http://lkml.iu.edu/hypermail/linux/kernel/1506.0/03787.html
> >
> > There hasn't been a consensus since v1.
> 
> I actually prefer your previous version binding soc_bus to the root
> bus node to this version. I think that is closer to the right
> direction. 

So if I understand correctly, the binding at the SoC level is fine.
Keeping that but removing the additional made-up properties, viz. below

rom-revision: phandle to the on-chip ROM node
mscm: phandle to the MSCM CPU configuration node
nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
nvmem-cell-names: should contain string names "cfg0" and "cfg1"

would be fine?

We would have something similar to here
http://www.spinics.net/lists/devicetree/msg80655.html

but now with the DT binding under SoC bus.

Regards,
Sanchayan.

> After all, pretty much everything is an SOC and every SOC
> has an SOC bus. Pretty much every SOC and board have revisions and may
> need to expose that revision info as well. We have to do

Re: [PATCH v2] ARM: dts: vfxxx: Add iio_hwmon node for ADC temperature channel

2016-02-14 Thread maitysanchayan

Hello Shawn,

On 16-02-14 16:33:49, Shawn Guo wrote:
> On Fri, Feb 12, 2016 at 05:53:00PM +0530, Sanchayan Maity wrote:
> > Add iio_hwmon node to expose the temperature channel on Vybrid as
> > hardware monitor device using the iio_hwmon driver.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> > 
> > Hello,
> > 
> > The first version of the patch was send quite a while ago.
> > https://lkml.org/lkml/2015/9/16/932
> > 
> > Shawn you had requested that hyphen rather than underscore should
> > be used in node name. I looked into that.
> > 
> > The iio_hwmon driver calls hwmon_device register_with_groups inside
> > hwmon.c and this
> > http://lxr.free-electrons.com/source/drivers/hwmon/hwmon.c#L103
> > 
> > does not allow hyphen in hwmon name attribute. I was not aware of
> > this but while trying to test the change, the device probe failed
> > with EINVAL. I think we should stick to the existing use of the
> > bindings or we need to change the hwmon code as well along with the
> > existing device tree files and binding documentation.
> 
> I disagree.
> 
> If hyphen is invalid to be part of hwmon name attribute, the following
> code in iio_hwmon_probe() is plain wrong, because hyphen is very valid
> to be part of node names in device tree.
> 
> if (dev->of_node && dev->of_node->name)
> name = dev->of_node->name;

@Shawn
I agree with what you state here, however as you can see the hwmon_device_
register_with_groups does check for hypen with strpbrk and returns EINVAL.
Changing to hyphen instead of currently present underscore in iio_hwmon
node name causes probe failure.

If the node name needs to have hyphen, then the check for hyphen as an invalid
character in hwmon name attribute needs to be changed. I am CC'ing the hwmon
subsystem maintainers Jean Delvare ands Guenter Roeck as well as hwmon list to
check.

@Jean & Guenter
Can you please comment if the change to hwmon_device_register_with_groups
to accept hyphen as a valid character in hwmon name attribute will be 
acceptable?
Sorry if this is sudden andfor bringing you late into the discussion Jean and
Guenter.

Thanks & Regards,
Sanchayan.

> 
> Shawn
> 
> > 
> > Changes since v1:
> > 1. Expose ADC1 temperature channel as well
> > 2. Move the entry outside of the aips1 bus node
> > 
> > Best Regards,
> > Sanchayan Maity.
> > ---
> >  arch/arm/boot/dts/vfxxx.dtsi | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> > index a5f07e3..8ed8e47 100644
> > --- a/arch/arm/boot/dts/vfxxx.dtsi
> > +++ b/arch/arm/boot/dts/vfxxx.dtsi
> > @@ -673,5 +673,10 @@
> > status = "disabled";
> > };
> > };
> > +
> > +   iio_hwmon {
> > +   compatible = "iio-hwmon";
> > +   io-channels = < 16>, < 16>;
> > +   };
> > };
> >  };
> > -- 
> > 2.7.1
> > 
> >

Re: [PATCH v1 0/4] Implement SoC bus driver for Vybrid

2016-03-27 Thread maitysanchayan

Hello,

Ping.

- Sanchayan.

On 16-03-11 14:29:27, Sanchayan Maity wrote:
> Hello,
> 
> This patchset implements SoC bus support for Freescale Vybrid platform,
> implementing the following
> https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-devices-soc
> 
> This a reworked version of an older patchset series posted in June 2015
> which was at v5 then [1]. Since the NVMEM framework was then getting
> introduced, we decided that first a NVMEM driver for OCOTP peripheral
> being in place would be better.
> 
> Compared to the older revisions, this driver now relies on NVMEM
> consumer API using the NVMEM based vf610_ocotp driver which has
> already been in mainline for a while now. Also now a new syscon
> abstraction "syscon_regmap_read_from_offset" is implemented and
> exported from syscon allowing accessing a register from a syscon
> reference like this
> 
> ocotp-cfg1 = < 0x20>;
> 
> avoiding code repetition in the driver.
> 
> One point on which we were not sure here is whether we really should
> introduce a new Kconfig symbol as being introduced here. While we
> could just enable it when SOC_VF610 is selected, this however would
> introduce circular dependencies.
> 
> This patch series is based on top of shawn's for-next branch and
> tested on Colibri Vybrid VF50 and VF61 modules.
> 
> Feedback is most welcome.
> 
> [1] Older v5:
> http://lkml.iu.edu/hypermail/linux/kernel/1506.0/03787.html
> Even earlier versions:
> Version 4 of the patchset can be found here
> https://lkml.org/lkml/2015/5/26/199
> Version 3 of the patchset can be found here
> http://www.spinics.net/lists/arm-kernel/msg420847.html
> Version 2 of the patchset can be found here
> http://www.spinics.net/lists/devicetree/msg80654.html
> Version 1 of the patchset can be found here
> http://www.spinics.net/lists/devicetree/msg80257.html
> The RFC version can be found here
> https://lkml.org/lkml/2015/5/11/13
> 
> Regards,
> Sanchayan.
> 
> Sanchayan Maity (4):
>   mfd: syscon: Introduce syscon_regmap_read_from_offset
>   ARM: dts: vfxxx: Add device tree node for OCOTP
>   ARM: dts: vfxxx: Add OCROM and phandle entries for Vybrid SoC bus driver
>   soc: Add SoC bus driver for Freescale Vybrid Platform
> 
>  arch/arm/boot/dts/vfxxx.dtsi |  28 +++-
>  drivers/mfd/syscon.c |  30 
>  drivers/soc/Kconfig  |   1 +
>  drivers/soc/fsl/Kconfig  |  10 +++
>  drivers/soc/fsl/Makefile |   1 +
>  drivers/soc/fsl/soc-vf610.c  | 160 
> +++
>  include/linux/mfd/syscon.h   |  10 +++
>  7 files changed, 239 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/soc/fsl/Kconfig
>  create mode 100644 drivers/soc/fsl/soc-vf610.c
> 
> -- 
> 2.7.2
>

Re: [PATCH v1 3/4] ARM: dts: vfxxx: Add OCROM and phandle entries for Vybrid SoC bus driver

2016-04-04 Thread maitysanchayan

Hello,

On 16-04-01 14:00:46, Shawn Guo wrote:
> On Fri, Mar 11, 2016 at 02:29:30PM +0530, Sanchayan Maity wrote:
> > Add OCROM node and introduce phandles to OCROM, MSCM and NVMEM
> > OCOTP for use by the Vybrid SoC bus driver.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  arch/arm/boot/dts/vfxxx.dtsi | 12 +++-
> >  1 file changed, 11 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> > index db9157e..0dd7ad5 100644
> > --- a/arch/arm/boot/dts/vfxxx.dtsi
> > +++ b/arch/arm/boot/dts/vfxxx.dtsi
> > @@ -87,9 +87,19 @@
> > soc {
> > #address-cells = <1>;
> > #size-cells = <1>;
> > -   compatible = "simple-bus";
> > +   compatible = "fsl,vf610-soc-bus", "simple-bus";
> > interrupt-parent = <_ir>;
> > ranges;
> > +   fsl,rom-revision = < 0x80>;
> > +   fsl,cpu-count = <_cpucfg 0x2C>;
> > +   fsl,l2-size = <_cpucfg 0x14>;
> 
> We need a bindings doc for these new properties and compatible.

Ok. Will add the documentation part in v2.

- Sanchayan.

> 
> Shawn
> 
> > +   nvmem-cells = <_cfg0>, <_cfg1>;
> > +   nvmem-cell-names = "cfg0", "cfg1";
> > +
> > +   ocrom: ocrom@ {
> > +   compatible = "fsl,vf610-ocrom", "syscon";
> > +   reg = <0x 0x18000>;
> > +   };
> >  
> > aips0: aips-bus@4000 {
> > compatible = "fsl,aips-bus", "simple-bus";
> > -- 
> > 2.7.2
> > 
> >

Re: [RFC PATCH 0/4] Implement USB device/host switch for Vybrid

2016-03-30 Thread maitysanchayan

Hello Peter,

On 16-03-29 00:24:46, Peter Chen wrote:
>  
> > 
> > On 2016-03-25 00:40, Peter Chen wrote:
> > > On Tue, Mar 15, 2016 at 02:08:26PM +0530, Sanchayan Maity wrote:
> > >> Hello Peter,
> > >>
> > >> The existing usage of extcon in Chipidea driver relies on OTG
> > >> registers. In case of SoC with dual role device but not a true OTG
> > >> controller, this does not work. Such SoC's should specify the
> > >> existing CI_HDRC_DUAL_ROLE_NOT_OTG flag and do the role switch
> > >> without checking any of the OTG registers in my opinion.
> > >> This is the case for Vybrid which uses a Chipidea IP but does not
> > >> have a true 5 pin OTG implemented.
> > >
> > > Sorry to reply you late due to my new born baby.
> > >
> > > Are you sure Vybrid is NOT OTG core? Afaik, it is uses the same IP
> > > base with other Freescale SoCs, just the IP core is 2.40a.
> > > When working at device mode, can you read vbus status through OTGSC?
> > > And if there is an ID pin (input pin) for Vybrid? I mean SoC, not the
> > > board.
> > 
> > I think the IP is actually OTG capable, the registers are there, but the 
> > signals
> > seem not to be available on the SoC package. That is also what the RM 
> > says...
> > 
> > Quotes from the RM:
> > 
> > "OTG controller should be treated as
> > Dual role controller that allows the
> > controller to act as either a Host or a
> > device with no support for HNP/SRP."
> > 
> > And later, in Chapter 11.1:
> > 
> > "The USB is not a true OTG. It can be configured by software to function 
> > either
> > as peripheral or as host. The ID pin, which is unique for OTG operation, is 
> > not
> > present in this implementation. There are no five pin interface. The user 
> > will
> > get four pin host/ device interface."
> > 
> 
> Get it, thanks. I am doing a patch for covering this case and vbus always-on 
> case.

If I may ask at this point, how would your implementation be covering this case
for Vybrid?

- Sanchayan.

Re: [PATCH 05/12] nvmem: vif610-ocotp: remove nvmem regmap dependency

2016-04-26 Thread maitysanchayan

Hello Srinivas,

On 16-04-24 20:28:09, Srinivas Kandagatla wrote:
> This patch moves to nvmem support in the driver to use callback
> instead of regmap.

Minor nit, it says "vif610-octop" it should have been vf610-ocotp.

For what it's worth, I tested this on Colibri Vybrid VF61 for a while and
all seems to work fine.

So with the testing for vf610-ocotp driver other than the minor nit

Acked-by: Sanchayan Maity 

Regards,
Sanchayan.

> 
> Signed-off-by: Srinivas Kandagatla 
> ---
>  drivers/nvmem/vf610-ocotp.c | 44 ++--
>  1 file changed, 10 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/nvmem/vf610-ocotp.c b/drivers/nvmem/vf610-ocotp.c
> index 8641319..72e4faa 100644
> --- a/drivers/nvmem/vf610-ocotp.c
> +++ b/drivers/nvmem/vf610-ocotp.c
> @@ -25,7 +25,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  
>  /* OCOTP Register Offsets */
> @@ -152,23 +151,16 @@ static int vf610_get_fuse_address(int base_addr_offset)
>   return -EINVAL;
>  }
>  
> -static int vf610_ocotp_write(void *context, const void *data, size_t count)
> -{
> - return 0;
> -}
> -
> -static int vf610_ocotp_read(void *context,
> - const void *off, size_t reg_size,
> - void *val, size_t val_size)
> +static int vf610_ocotp_read(void *context, unsigned int offset,
> + void *val, size_t bytes)
>  {
>   struct vf610_ocotp *ocotp = context;
>   void __iomem *base = ocotp->base;
> - unsigned int offset = *(u32 *)off;
>   u32 reg, *buf = val;
>   int fuse_addr;
>   int ret;
>  
> - while (val_size > 0) {
> + while (bytes > 0) {
>   fuse_addr = vf610_get_fuse_address(offset);
>   if (fuse_addr > 0) {
>   writel(ocotp->timing, base + OCOTP_TIMING);
> @@ -205,29 +197,19 @@ static int vf610_ocotp_read(void *context,
>   }
>  
>   buf++;
> - val_size--;
> - offset += reg_size;
> + bytes -= 4;
> + offset += 4;
>   }
>  
>   return 0;
>  }
>  
> -static struct regmap_bus vf610_ocotp_bus = {
> - .read = vf610_ocotp_read,
> - .write = vf610_ocotp_write,
> - .reg_format_endian_default = REGMAP_ENDIAN_NATIVE,
> - .val_format_endian_default = REGMAP_ENDIAN_NATIVE,
> -};
> -
> -static struct regmap_config ocotp_regmap_config = {
> - .reg_bits = 32,
> - .val_bits = 32,
> - .reg_stride = 4,
> -};
> -
>  static struct nvmem_config ocotp_config = {
>   .name = "ocotp",
>   .owner = THIS_MODULE,
> + .stride = 4,
> + .word_size = 4,
> + .reg_read = vf610_ocotp_read,
>  };
>  
>  static const struct of_device_id ocotp_of_match[] = {
> @@ -247,7 +229,6 @@ static int vf610_ocotp_probe(struct platform_device *pdev)
>  {
>   struct device *dev = >dev;
>   struct resource *res;
> - struct regmap *regmap;
>   struct vf610_ocotp *ocotp_dev;
>  
>   ocotp_dev = devm_kzalloc(>dev,
> @@ -267,13 +248,8 @@ static int vf610_ocotp_probe(struct platform_device 
> *pdev)
>   return PTR_ERR(ocotp_dev->clk);
>   }
>  
> - ocotp_regmap_config.max_register = resource_size(res);
> - regmap = devm_regmap_init(dev,
> - _ocotp_bus, ocotp_dev, _regmap_config);
> - if (IS_ERR(regmap)) {
> - dev_err(dev, "regmap init failed\n");
> - return PTR_ERR(regmap);
> - }
> + ocotp_config.size = resource_size(res);
> + ocotp_config.priv = ocotp_dev;
>   ocotp_config.dev = dev;
>  
>   ocotp_dev->nvmem = nvmem_register(_config);
> -- 
> 2.5.0
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 4/4] soc: Add SoC driver for Freescale Vybrid platform

2016-05-23 Thread maitysanchayan

Hello Rob,

On 16-05-23 16:18:13, Rob Herring wrote:
> On Fri, May 20, 2016 at 03:32:05PM +0530, Sanchayan Maity wrote:
> > This adds a SoC driver to be used by Freescale Vybrid SoC's.
> > Driver utilises syscon and nvmem consumer API's to get the
> > various register values needed and expose the SoC specific
> > properties via sysfs.
> > 
> > A sample output from Colibri Vybrid VF61 is below:
> > 
> > root@colibri-vf:~# cd /sys/bus/soc/devices/soc0
> > root@colibri-vf:/sys/bus/soc/devices/soc0# ls
> > family machinepower  revision   soc_id subsystem  uevent
> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat family
> > Freescale Vybrid VF610
> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat machine
> > Freescale Vybrid
> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat revision
> > 0013
> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat soc_id
> > df6472a6130f29d4
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  .../bindings/arm/freescale/fsl,vf610-soc.txt   |  20 +++
> >  drivers/soc/Kconfig|   1 +
> >  drivers/soc/fsl/Kconfig|  10 ++
> >  drivers/soc/fsl/Makefile   |   1 +
> >  drivers/soc/fsl/soc-vf610.c| 198 
> > +
> >  5 files changed, 230 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> >  create mode 100644 drivers/soc/fsl/Kconfig
> >  create mode 100644 drivers/soc/fsl/soc-vf610.c
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt 
> > b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> > new file mode 100644
> > index 000..338905d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> > @@ -0,0 +1,20 @@
> > +Vybrid System-on-Chip
> > +-
> > +
> > +Required properties:
> > +
> > +- compatible: "fsl,vf610-soc"
> > +- rom-revision: phandle to the on-chip ROM node
> > +- mscm: phandle to the MSCM CPU configuration node
> > +- nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> > +- nvmem-cell-names: should contain string names "cfg0" and "cfg1"
> 
> I still have similar concerns as the discussion on the last version. 
> This version only proves that you aren't describing h/w, but rather just 
> a collection of data that some driver wants.
> 
> A driver can just as easily look-up all the nodes directly that these 
> phandles point to.

Agreed, that we can look up all the nodes directly that these phandles
refer to but I would still need a DT entry to bind to. While I could
bind to existing nodes like mscm cpucfg but that doesn't seem right.

The very first approach that we had taken was to integrate this functionality
in mach-vf610.c code under mach-imx
http://www.spinics.net/lists/devicetree/msg80654.html

and then it was recommended to migrate this to drivers/soc where we did use
phandles or direct look up via compatible strings

http://www.spinics.net/lists/arm-kernel/msg420847.html

and

http://lkml.iu.edu/hypermail/linux/kernel/1506.0/03787.html

There hasn't been a consensus since v1.

> 
> And as long as we have inconsistent use of soc_device, I don't want to 
> see any compatible strings related to it.
> 

Regards,
Sanchayan.

Re: [PATCH v2 2/5] ARM: dts: vfxxx: Add device tree node for OCOTP

2016-05-02 Thread maitysanchayan

Hello Arnd,

On 16-05-02 09:31:12, Arnd Bergmann wrote:
> On Monday 02 May 2016 12:35:01 Sanchayan Maity wrote:
> > +   ocotp@400a5000 {
> > +   compatible = "fsl,vf610-ocotp";
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   reg = <0x400a5000 0xCF0>;
> > +   clocks = < VF610_CLK_OCOTP>;
> > +
> > +   ocotp_cfg0: cfg0@410 {
> > +   reg = <0x410 0x4>;
> > +   };
> > +
> > +   ocotp_cfg1: cfg1@420 {
> > +   reg = <0x420 0x4>;
> > +   };
> > +   };
> 
> How do the registers of the child nodes relate to the registers of the
> parent? If there are in the same address space, it might be good to
> add a "ranges" property to describe it.

cfg0 and cfg1 are in the same address space viz. 0x400a5410 and 0x400a5420
respectively. These nodes are primarily for use by the NVMEM consumer API in
the SoC bus driver to retrieve the values from these registers leveraging
the NVMEM vf610 ocotp driver.

Based on the NVMEM bindings here
http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/nvmem/nvmem.txt#L33

Thanks.

Regards,
Sanchayan.

> 
>   Arnd

> Date: Mon, 02 May 2016 12:02:21 +1000
> From: Gavin Shan 
> To: Rob Herring 
> Cc: "devicet...@vger.kernel.org" ,
>  a...@ozlabs.ru, Gavin Shan , Grant Likely
>  , "linux-...@vger.kernel.org"
>  , Bjorn Helgaas ,
>  linuxppc-dev , d...@axtens.net
> Subject: Re: [PATCH v8 40/45] drivers/of: Split unflatten_dt_node()
> 
> On Wed, Feb 17, 2016 at 08:30:42AM -0600, Rob Herring wrote:
> >On Tue, Feb 16, 2016 at 9:44 PM, Gavin Shan  
> >wrote:
> >> The function unflatten_dt_node() is called recursively to unflatten
> >> device nodes and properties in the FDT blob. It looks complicated
> >> and hard to be understood.
> >>
> >> This splits the function into 3 functions: populate_properties(),
> >> populate_node() and unflatten_dt_node(). populate_properties(),
> >> which is called by populate_node(), creates properties for the
> >> indicated device node. The later one creates the device nodes
> >> from FDT blob. populate_node() gets the offset in FDT blob for
> >> next device nodes and then calls populate_node(). No logical
> >> changes introduced.
> >>
> >> Signed-off-by: Gavin Shan 
> >> ---
> >>  drivers/of/fdt.c | 249 
> >> ---
> >>  1 file changed, 147 insertions(+), 102 deletions(-)
> >
> >One nit, otherwise:
> >
> >Acked-by: Rob Herring 
> >
> >[...]
> >
> >> +   /* And we process the "ibm,phandle" property
> >> +* used in pSeries dynamic device tree
> >> +* stuff
> >> +*/
> >> +   if (!strcmp(pname, "ibm,phandle"))
> >> +   np->phandle = be32_to_cpup(val);
> >> +
> >> +   pp->name   = (char *)pname;
> >> +   pp->length = sz;
> >> +   pp->value  = (__be32 *)val;
> >
> >This cast should not be needed.
> >
> 
> It's needed. Otherwise, we will have warning. So I will keep it. I just
> went through this one for next revision and sorry for late response.
> 
> drivers/of/fdt.c:225:14: warning: assignment discards ‘const’ qualifier from 
> pointer target type
>pp->value  = val;
>   ^
> 
> Thanks,
> Gavin
> 
> >> +   *pprev = pp;
> >> +   pprev  = >next;
> >> +   }
> >
> 
> ___
> Linuxppc-dev mailing list
> linuxppc-...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 5/5] vf610-soc: Add Vybrid SoC device tree binding documentation

2016-05-05 Thread maitysanchayan

Hello Rob,

On 16-05-03 21:30:26, Rob Herring wrote:
> On Mon, May 02, 2016 at 12:35:04PM +0530, Sanchayan Maity wrote:
> > Add device tree binding documentation for Vybrid SoC.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  .../bindings/arm/freescale/fsl,vf610-soc.txt   | 35 
> > ++
> >  1 file changed, 35 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt 
> > b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> > new file mode 100644
> > index 000..bdd95e8
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> > @@ -0,0 +1,35 @@
> > +Vybrid System-on-Chip
> > +-
> > +
> > +Required properties:
> > +
> > +- #address-cells: must be 1
> > +- #size-cells: must be 1
> > +- compatible: "fsl,vf610-soc-bus", "simple-bus"
> 
> If this is a bus, put the file in bindings/bus/...

The fsl,vf610-soc-bus binding is used to bind the driver in question with
an appropriate compatible node.

Basically being a standalone platform driver, there was need of a compatible
property to bind on. Introducing a separate device tree node for it's sake
didn't seem appropriate so the alteration to SoC node's compatible.

> 
> > +- interrupt-parent: phandle to the MSCM interrupt router node
> > +- ranges
> > +- fsl,rom-revision: phandle to the on-chip ROM node and address of rom
> > +  revision register
> 
> Why is this needed here? Can't you search the tree for the ROM node and 
> get this info.

Strictly per say this and next two can be specified in their respective nodes
of ocrom and mscm cpucfg, however they would then require the use of syscon_
regmap_lookup_by_compatible and this seems clean along with the introduction
of new syscon_regmap_read_from_offset function used with SoC node.

> 
> > +- fsl,cpu-count: phandle to the MSCM CPU configuration node and address of
> > +  CPU count register
> > +- fsl,l2-size: phandle to the MSCM CPU configuration node and address of
> > +  L2 cache size register
> > +- nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> > +- nvmem-cell-names: should contain string names "cfg0" and "cfg1"
> 
> How are all these properties used?

All the above five are used to get the relevant values from the registers and
expose the information for SoC sysfs device.
https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-devices-soc

nvmem are consumer nodes which are accessed using the NVMEM consumer API's
leveraging the NVMEM framework and NVMEM vf610 ocotp driver.

Regards,
Sanchayan.

> 
> > +
> > +Example:
> > +
> > +   soc {
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   compatible = "fsl,vf610-soc-bus", "simple-bus";
> > +   interrupt-parent = <_ir>;
> > +   ranges;
> > +   fsl,rom-revision = < 0x80>;
> > +   fsl,cpu-count = <_cpucfg 0x2C>;
> > +   fsl,l2-size = <_cpucfg 0x14>;
> > +   nvmem-cells = <_cfg0>, <_cfg1>;
> > +   nvmem-cell-names = "cfg0", "cfg1";
> > +
> > +   ...
> > +   };
> > -- 
> > 2.8.2
> >

Re: [PATCH v4 3/5] nvmem: core: Add consumer API to get nvmem cell from node

2016-07-07 Thread maitysanchayan

Hello Srinivas,

On 16-07-07 14:16:36, Srinivas Kandagatla wrote:
> 
> 
> On 07/07/16 13:33, maitysancha...@gmail.com wrote:
> > Hello Srinivas,
> > 
> > On 16-07-07 10:18:49, Srinivas Kandagatla wrote:
> > > 
> > > 
> > > On 07/07/16 07:39, Sanchayan Maity wrote:
> > > > From: Stefan Agner 
> > > > 
> > > > The existing NVMEM consumer API's do not allow to get a
> > > > NVMEM cell directly given a device tree node. This patch
> > > > adds a function to provide this functionality.
> > > > 
> > > > Assuming the nvmem cell id name is known, this can be used
> > > > as follows
> > > > 
> > > > struct device_node *cell_np;
> > > > struct nvmem_cell *foo_cell;
> > > > 
> > > > cell_np = of_find_node_by_name(parent, "foo");
> > > > foo_cell = of_nvmem_cell_get_direct(cell_np);
> > > 
> > > I don't see a real gain in adding this new api,
> > > This will encourage people to use non-standard nvmem bindings.
> > > 
> > > why not just use standard nvmem bindings.. and use
> > > 
> > > of_nvmem_cell_get(np, "foo");
> > > 
> > > which should work in your case.
> > 
> > It will not work in our case. I believe what you are referring to will
> > work if I were to pass the device node pointer which was a NVMEM consumer
> > containing the nvmem-cells property. In our case, we pass the device node
> > pointer pointing to /soc which is not a nvmem consumer. In this case it
> > will not have nvmem-cells property causing of_nvmem_cell_get to return
> > EINVAL when it calls of_parse_phandle with "nvmem-cells".
> 
> I could not see any bindings/ dt patches or dt examples for this this
> series.. so Am guessing your node would look like:
> 
> soc {
>   cfg0: cfg0 {
>   ...
>   };
>   cfg1: cfg1 {
>   ...
>   };
> };
> 
> If this is not how it looks, can you share the details.
> 
> What Am saying is that why not have:
> 
> soc {
>   nvmem-cells = <>, <>;
>   nvmem-cell-names = "cfg0", "cfg1";
> 
>   cfg0: cfg0 {
>   ...
>   };
> 
>   cfg1: cfg1 {
>   ...
>   };
> };
> 
> > 
> > Our requirement is to be able to pass the soc node pointer and then
> > be able to get a nvmem cell by specifying it's name. So for our case
> 
> Why?

Sorry for not providing the background directly. The patches before this
series used that approach. In the previous discussions it has been pointed
out that it is not acceptable to have additional device tree bindings for
providing data that the driver wants at the SoC node level or to have bindings
just for the SoC bus driver alone since we aren't really describing the
hardware.

For the discussion,
https://lkml.org/lkml/2016/5/23/573
https://lkml.org/lkml/2016/5/2/71

Regards,
Sanchayan.


> 
> > ocotp node has cfg0 and cfg1 which we want but we cannot use existing
> > nvmem consumer API since that requires having the nvmem consumer properties
> > in the node we are binding to viz. is a direct nvmem consumer.
> > 
> > Regards,
> > Sanchayan.
> > 
> > > 
> > > thanks,
> > > srini
> > > > 
> > > > Parent node can also be the of_node of the main SoC device
> > > > node.
> > > > 
> > > > Signed-off-by: Sanchayan Maity 
> > > > ---
> > > >drivers/nvmem/core.c   | 44 
> > > > +-
> > > >include/linux/nvmem-consumer.h |  1 +
> > > >2 files changed, 32 insertions(+), 13 deletions(-)
> > > > 
> > > > diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> > > > index 965911d..470abee 100644
> > > > --- a/drivers/nvmem/core.c
> > > > +++ b/drivers/nvmem/core.c
> > > > @@ -743,29 +743,21 @@ static struct nvmem_cell 
> > > > *nvmem_cell_get_from_list(const char *cell_id)
> > > > 
> > > >#if IS_ENABLED(CONFIG_NVMEM) && IS_ENABLED(CONFIG_OF)
> > > >/**
> > > > - * of_nvmem_cell_get() - Get a nvmem cell from given device node and 
> > > > cell id
> > > > + * of_nvmem_cell_get_direct() - Get a nvmem cell from given device node
> > > > *
> > > > - * @dev node: Device tree node that uses the nvmem cell
> > > > - * @id: nvmem cell name from nvmem-cell-names property.
> > > > + * @dev node: Device tree node that uses nvmem cell
> > > > *
> > > > * Return: Will be an ERR_PTR() on error or a valid pointer
> > > > * to a struct nvmem_cell.  The nvmem_cell will be freed by the
> > > > * nvmem_cell_put().
> > > > */
> > > > -struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
> > > > -   const char *name)
> > > > +struct nvmem_cell *of_nvmem_cell_get_direct(struct device_node 
> > > > *cell_np)
> > > >{
> > > > -   struct device_node *cell_np, *nvmem_np;
> > > > +   struct device_node *nvmem_np;
> > > > struct nvmem_cell *cell;
> > > > struct nvmem_device *nvmem;
> > > > const __be32 *addr;
> > > > -   int rval, len, index;
> > > > -
> > > > -   index = of_property_match_string(np, "nvmem-cell-names", name);
> > > > -

Re: [PATCH v4 3/5] nvmem: core: Add consumer API to get nvmem cell from node

2016-07-07 Thread maitysanchayan

Hello Srinivas,

On 16-07-07 10:18:49, Srinivas Kandagatla wrote:
> 
> 
> On 07/07/16 07:39, Sanchayan Maity wrote:
> > From: Stefan Agner 
> > 
> > The existing NVMEM consumer API's do not allow to get a
> > NVMEM cell directly given a device tree node. This patch
> > adds a function to provide this functionality.
> > 
> > Assuming the nvmem cell id name is known, this can be used
> > as follows
> > 
> > struct device_node *cell_np;
> > struct nvmem_cell *foo_cell;
> > 
> > cell_np = of_find_node_by_name(parent, "foo");
> > foo_cell = of_nvmem_cell_get_direct(cell_np);
> 
> I don't see a real gain in adding this new api,
> This will encourage people to use non-standard nvmem bindings.
> 
> why not just use standard nvmem bindings.. and use
> 
> of_nvmem_cell_get(np, "foo");
> 
> which should work in your case.

It will not work in our case. I believe what you are referring to will
work if I were to pass the device node pointer which was a NVMEM consumer
containing the nvmem-cells property. In our case, we pass the device node
pointer pointing to /soc which is not a nvmem consumer. In this case it
will not have nvmem-cells property causing of_nvmem_cell_get to return
EINVAL when it calls of_parse_phandle with "nvmem-cells".

Our requirement is to be able to pass the soc node pointer and then
be able to get a nvmem cell by specifying it's name. So for our case
ocotp node has cfg0 and cfg1 which we want but we cannot use existing
nvmem consumer API since that requires having the nvmem consumer properties
in the node we are binding to viz. is a direct nvmem consumer.

Regards,
Sanchayan.

> 
> thanks,
> srini
> > 
> > Parent node can also be the of_node of the main SoC device
> > node.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >   drivers/nvmem/core.c   | 44 
> > +-
> >   include/linux/nvmem-consumer.h |  1 +
> >   2 files changed, 32 insertions(+), 13 deletions(-)
> > 
> > diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> > index 965911d..470abee 100644
> > --- a/drivers/nvmem/core.c
> > +++ b/drivers/nvmem/core.c
> > @@ -743,29 +743,21 @@ static struct nvmem_cell 
> > *nvmem_cell_get_from_list(const char *cell_id)
> > 
> >   #if IS_ENABLED(CONFIG_NVMEM) && IS_ENABLED(CONFIG_OF)
> >   /**
> > - * of_nvmem_cell_get() - Get a nvmem cell from given device node and cell 
> > id
> > + * of_nvmem_cell_get_direct() - Get a nvmem cell from given device node
> >*
> > - * @dev node: Device tree node that uses the nvmem cell
> > - * @id: nvmem cell name from nvmem-cell-names property.
> > + * @dev node: Device tree node that uses nvmem cell
> >*
> >* Return: Will be an ERR_PTR() on error or a valid pointer
> >* to a struct nvmem_cell.  The nvmem_cell will be freed by the
> >* nvmem_cell_put().
> >*/
> > -struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
> > -   const char *name)
> > +struct nvmem_cell *of_nvmem_cell_get_direct(struct device_node *cell_np)
> >   {
> > -   struct device_node *cell_np, *nvmem_np;
> > +   struct device_node *nvmem_np;
> > struct nvmem_cell *cell;
> > struct nvmem_device *nvmem;
> > const __be32 *addr;
> > -   int rval, len, index;
> > -
> > -   index = of_property_match_string(np, "nvmem-cell-names", name);
> > -
> > -   cell_np = of_parse_phandle(np, "nvmem-cells", index);
> > -   if (!cell_np)
> > -   return ERR_PTR(-EINVAL);
> > +   int rval, len;
> > 
> > nvmem_np = of_get_next_parent(cell_np);
> > if (!nvmem_np)
> > @@ -824,6 +816,32 @@ err_mem:
> > 
> > return ERR_PTR(rval);
> >   }
> > +EXPORT_SYMBOL_GPL(of_nvmem_cell_get_direct);
> > +
> > +/**
> > + * of_nvmem_cell_get() - Get a nvmem cell from given device node and cell 
> > id
> > + *
> > + * @dev node: Device tree node that uses the nvmem cell
> > + * @id: nvmem cell name from nvmem-cell-names property.
> > + *
> > + * Return: Will be an ERR_PTR() on error or a valid pointer
> > + * to a struct nvmem_cell.  The nvmem_cell will be freed by the
> > + * nvmem_cell_put().
> > + */
> > +struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
> > +   const char *name)
> > +{
> > +   struct device_node *cell_np;
> > +   int index;
> > +
> > +   index = of_property_match_string(np, "nvmem-cell-names", name);
> > +
> > +   cell_np = of_parse_phandle(np, "nvmem-cells", index);
> > +   if (!cell_np)
> > +   return ERR_PTR(-EINVAL);
> > +
> > +   return of_nvmem_cell_get_direct(cell_np);
> > +}
> >   EXPORT_SYMBOL_GPL(of_nvmem_cell_get);
> >   #endif
> > 
> > diff --git a/include/linux/nvmem-consumer.h b/include/linux/nvmem-consumer.h
> > index 9bb77d3..bf879fc 100644
> > --- a/include/linux/nvmem-consumer.h
> > +++ b/include/linux/nvmem-consumer.h
> > @@ -136,6 +136,7 @@ static inline int nvmem_device_write(struct 
> > nvmem_device *nvmem,
> >   #endif /* CONFIG_NVMEM */
> > 
> >

Re: [PATCH v4 3/5] nvmem: core: Add consumer API to get nvmem cell from node

2016-08-01 Thread maitysanchayan

On 16-07-08 18:23:42, Srinivas Kandagatla wrote:
> 
> 
> On 08/07/16 17:42, Stefan Agner wrote:
> > On 2016-07-08 08:41, Srinivas Kandagatla wrote:
> > > On 07/07/16 14:48, maitysancha...@gmail.com wrote:
> > > > Hello Srinivas,
> > > > 
> > > > On 16-07-07 1
> 
> ...
> 
> > > > > > 
> > > > > > Our requirement is to be able to pass the soc node pointer and then
> > > > > > be able to get a nvmem cell by specifying it's name. So for our case
> > > > > 
> > > > > Why?
> > > > 
> > > > Sorry for not providing the background directly. The patches before this
> > > > series used that approach. In the previous discussions it has been 
> > > > pointed
> > > > out that it is not acceptable to have additional device tree bindings 
> > > > for
> > > > providing data that the driver wants at the SoC node level or to have 
> > > > bindings
> > > > just for the SoC bus driver alone since we aren't really describing the
> > > > hardware.
> > > > 
> > > SOC driver seems to search for an arbitrary node by its name, which is
> > > not a binding and can break anytime in cases If the scope of nvmem
> > > provider is out of soc node or if the nvmem cells are not named as
> > > expected. That looks very fragile.
> > 
> > In that case, that just "won't happen" because the soc driver is a very
> > soc specific driver only used for this device tree. We it will always
> > bind to that high level soc node.
> > 
> > > 
> > > If the soc node is actual consumer of nvmem cells, I see no reason why
> > > we should not use proper nvmem bindings?
> > 
> > There is a reason: We don't describe the hardware with it...
> > 
> > The cfg0/cfg1 register which Sanchayan needs to read in the soc bus
> > driver are just two register with a unique ID of the SoC. In whatever
> 
> "Unique ID of the SOC" doesn't this mean that its a part of soc hw
> description/configuration/setup?
> 
> Am still not clear why this setup any different to other use cases like mac
> address/calibration data?
> 
> I still feel that this should be described in the DT.
> 
> Rob,
>  What do you think?

Hello Rob,

Can you please comment?

Regards,
Sanchayan.

> 
> 
> > driver throughout the system we use that ID (e.g. in a random generator
> > for initialization) we never describe an actual hardware relation... Its
> > just software and how we use that unique ID. The device tree is ment to
> > describe hardware. Hence the NVMEM consumer binding is not suited for
> > such NVMEM cells...
> > 
> > By describing the NVMEM cells location in device tree (producer API, the
> > NVMEM cells are in hardware at that location, so using the device tree
> > for that part is fine) and hard coding the NVMEM cell we need in the
> > driver code we don't violate the device tree matra "describe the
> > hardware"...
> 
> IMHO, We should indeed describe the SOC hardware and its relationship w.r.t
> to nvmem provider in device tree. Reasoning being these both are some form
> of IP blocks/hw which depend on each other.
> 
> > 
> > Looking-up the nodes direcly is what Rob suggested here:
> > https://lkml.org/lkml/2016/5/23/573
> 
> I did read this, I was not convinced that we should do a direct lookup for
> nvmem cells.
> 
> thanks,
> srini
> > 
> > > 
> > > Given the fact that the patch is potentially bypassing the nvmem
> > > bindings, am not happy to take it!
> > 
> > If you can provide a solution acceptable by the device tree folks and
> > works without this patch, I am happy to do it...
> 
> 
> > 
> > Btw, I am not entirely happy with the API name, but did not had a better
> > idea... And we we should probably add a note that the device tree
> > consumer binding is the preferred way to do it.
> > 
> > --
> > Stefan
> > 
> > 
> > > 
> > > thanks,
> > > srini
> > > 
> > > > For the discussion,
> > > > https://lkml.org/lkml/2016/5/23/573
> > > > https://lkml.org/lkml/2016/5/2/71
> > > > 
> > > > Regards,
> > > > Sanchayan.
> > > > 
> > > > 
> > > > > 
> > > > > > ocotp node has cfg0 and cfg1 which we want but we cannot use 
> > > > > > existing
> > > > > > nvmem consumer API since that requires having the nvmem consumer 
> > > > > > properties
> > > > > > in the node we are binding to viz. is a direct nvmem consumer.
> > > > > > 
> > > > > > Regards,
> > > > > > Sanchayan.
> > > > > > 
> > > > > > > 
> > > > > > > thanks,
> > > > > > > srini
> > > > > > > > 
> > > > > > > > Parent node can also be the of_node of the main SoC device
> > > > > > > > node.
> > > > > > > > 
> > > > > > > > Signed-off-by: Sanchayan Maity 
> > > > > > > > ---
> > > > > > > >  drivers/nvmem/core.c   | 44 
> > > > > > > > +-
> > > > > > > >  include/linux/nvmem-consumer.h |  1 +
> > > > > > > >  2 files changed, 32 insertions(+), 13 deletions(-)
> > > > > > > > 
> > > > > > > > diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> > > > > > > > index 965911d..470abee 100644
> > > > > > > > --- a/drivers/nvmem/core.c
> > > > > > > >

Re: [PATCH v1 3/3] ARM: dts: imx6qdl-apalis: Use enable-gpios property for backlight

2016-09-16 Thread maitysanchayan

Hello Marcel,

On 16-09-16 13:38:54, Marcel Ziswiler wrote:
> On Wed, 2016-09-14 at 12:05 +0530, Sanchayan Maity wrote:
> > Use enable-gpios property of PWM backlight driver for backlight
> > control. While at it also fix the use of brightness levels required
> > by EDT displays which require inverted PWM's.
> 
> That part I am missing below. Did you forget to include it?

No, actually I missed fixing the commit message. Currently PWM polarity
inversion is not supported and while checking, I kept the brightness
levels as is currently but did not change the commit message.

Will send a v2 and fix this.

Regards,
Sanchayan.

> 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  arch/arm/boot/dts/imx6qdl-apalis.dtsi | 9 +
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > index 8c67dd8..9100bde 100644
> > --- a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > +++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > @@ -49,7 +49,10 @@
> >  
> >     backlight: backlight {
> >     compatible = "pwm-backlight";
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_gpio_bl_on>;
> >     pwms = < 0 500>;
> > +   enable-gpios = < 13 GPIO_ACTIVE_HIGH>;
> >     status = "disabled";
> >     };
> >  
> > @@ -614,6 +617,12 @@
> >     >;
> >     };
> >  
> > +   pinctrl_gpio_bl_on: gpioblon {
> > +   fsl,pins = <
> > +   MX6QDL_PAD_EIM_DA13__GPIO3_IO13 0x1b0b0
> > +   >;
> > +   };
> > +
> >     pinctrl_gpio_keys: gpio1io04grp {
> >     fsl,pins = <
> >     /* Power button */

Re: [PATCH] ARM: dts: imx6: Add support for Toradex Colibri iMX6 module

2016-09-26 Thread maitysanchayan

Hello,

Ping?

- Sanchayan.

On 16-09-21 16:54:38, Sanchayan Maity wrote:
> Add support for Toradex Colibri iMX6 module.
> 
> Signed-off-by: Sanchayan Maity 
> ---
>  arch/arm/boot/dts/Makefile   |   1 +
>  arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts | 253 
>  arch/arm/boot/dts/imx6qdl-colibri.dtsi   | 890 
> +++
>  3 files changed, 1144 insertions(+)
>  create mode 100644 arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
>  create mode 100644 arch/arm/boot/dts/imx6qdl-colibri.dtsi
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index f79cac2..44ff380 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -323,6 +323,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
>   imx6dl-aristainetos_7.dtb \
>   imx6dl-aristainetos2_4.dtb \
>   imx6dl-aristainetos2_7.dtb \
> + imx6dl-colibri-eval-v3.dtb \
>   imx6dl-cubox-i.dtb \
>   imx6dl-dfi-fs700-m60.dtb \
>   imx6dl-gw51xx.dtb \
> diff --git a/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts 
> b/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
> new file mode 100644
> index 000..e0c2172
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
> @@ -0,0 +1,253 @@
> +/*
> + * Copyright 2014-2016 Toradex AG
> + * Copyright 2012 Freescale Semiconductor, Inc.
> + * Copyright 2011 Linaro Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file 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.
> + *
> + * This file is distributed in the hope that it will be useful
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include 
> +#include 
> +#include "imx6dl.dtsi"
> +#include "imx6qdl-colibri.dtsi"
> +
> +/ {
> + model = "Toradex Colibri iMX6DL/S on Colibri Evaluation Board V3";
> + compatible = "toradex,colibri_imx6dl-eval-v3", "toradex,colibri_imx6dl",
> +  "fsl,imx6dl";
> +
> + aliases {
> + i2c0 = 
> + i2c1 = 
> + };
> +
> + aliases {
> + rtc0 = _i2c;
> + rtc1 = _rtc;
> + };
> +
> + clocks {
> + /* Fixed crystal dedicated to mcp251x */
> + clk16m: clk@1 {
> + compatible = "fixed-clock";
> + reg = <1>;
> + #clock-cells = <0>;
> + clock-frequency = <1600>;
> + clock-output-names = "clk16m";
> + };
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + pinctrl-names = "default";
> + pinctrl-0 = <_gpio_keys>;
> +
> + wakeup {
> + label = "Wake-Up";
> + gpios = < 22 GPIO_ACTIVE_HIGH>; /* SODIMM 45 */
> + linux,code = ;
> + debounce-interval = <10>;
> + wakeup-source;
> + };
> + };
> +
> + lcd_display: display@di0 {
> + compatible = "fsl,imx-parallel-display";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interface-pix-fmt = "bgr666";
> + pinctrl-names = "default";
> + pinctrl-0 = <_ipu1_lcdif>;
> +

Re: [PATCH v2 1/3] ARM: dts: imx6qdl-apalis: Do not rely on DDC I2C bus bitbang for HDMI

2016-09-26 Thread maitysanchayan

Hello,

Ping?

- Sanchayan.

On 16-09-19 10:41:51, Sanchayan Maity wrote:
> Remove the use of DDC I2C bus bitbang to support reading of EDID
> and rely on support from internal HDMI I2C master controller instead.
> As a result remove the device tree property ddc-i2c-bus.
> 
> Signed-off-by: Sanchayan Maity 
> ---
> Changes since v1:
> 
> Change the ranking in i2c aliases
> 
> v1: https://lkml.org/lkml/2016/9/14/55
> ---
>  arch/arm/boot/dts/imx6q-apalis-ixora.dts | 12 +++-
>  arch/arm/boot/dts/imx6qdl-apalis.dtsi| 25 +
>  2 files changed, 12 insertions(+), 25 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx6q-apalis-ixora.dts 
> b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> index 207b85b..82b81e0 100644
> --- a/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> +++ b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> @@ -55,10 +55,9 @@
>"fsl,imx6q";
>  
>   aliases {
> - i2c0 = 
> - i2c1 = 
> - i2c2 = 
> - i2c3 = 
> + i2c0 = 
> + i2c1 = 
> + i2c2 = 
>   };
>  
>   aliases {
> @@ -186,11 +185,6 @@
>  };
>  
>   {
> - ddc-i2c-bus = <>;
> - status = "okay";
> -};
> -
> - {
>   status = "okay";
>  };
>  
> diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi 
> b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> index 99e323b..8c67dd8 100644
> --- a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> @@ -53,18 +53,6 @@
>   status = "disabled";
>   };
>  
> - /* DDC_I2C: I2C2_SDA/SCL on MXM3 205/207 */
> - i2cddc: i2c@0 {
> - compatible = "i2c-gpio";
> - pinctrl-names = "default";
> - pinctrl-0 = <_i2c_ddc>;
> - gpios = < 16 GPIO_ACTIVE_HIGH /* sda */
> -   30 GPIO_ACTIVE_HIGH /* scl */
> - >;
> - i2c-gpio,delay-us = <2>;/* ~100 kHz */
> - status = "disabled";
> - };
> -
>   reg_1p8v: regulator-1p8v {
>   compatible = "regulator-fixed";
>   regulator-name = "1P8V";
> @@ -209,6 +197,12 @@
>   };
>  };
>  
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_hdmi_ddc>;
> + status = "disabled";
> +};
> +
>  /*
>   * GEN1_I2C: I2C1_SDA/SCL on MXM3 209/211 (e.g. RTC on carrier
>   * board)
> @@ -633,11 +627,10 @@
>   >;
>   };
>  
> - pinctrl_i2c_ddc: gpioi2cddcgrp {
> + pinctrl_hdmi_ddc: hdmiddcgrp {
>   fsl,pins = <
> - /* DDC bitbang */
> - MX6QDL_PAD_EIM_EB2__GPIO2_IO30 0x1b0b0
> - MX6QDL_PAD_EIM_D16__GPIO3_IO16 0x1b0b0
> + MX6QDL_PAD_EIM_EB2__HDMI_TX_DDC_SCL 0x4001b8b1
> + MX6QDL_PAD_EIM_D16__HDMI_TX_DDC_SDA 0x4001b8b1
>   >;
>   };
>  
> -- 
> 2.9.3
>

Re: [PATCH v1 1/2] ARM: dts: vfxxx: Enable DMA for DSPI on Vybrid

2016-10-03 Thread maitysanchayan

Hello Stefan,

On 16-10-03 11:05:59, Stefan Agner wrote:
> On 2016-10-03 05:50, Sanchayan Maity wrote:
> > Enable DMA for DSPI on Vybrid.
> 
> Hm, we have that in 4.4 already, is that meant for 4.1?

Sorry?! I send this out for mainline and the patch series is based
on top of shawn's for-next branch. Did not intend it for our downstream
4.1.

Thanks.

Regards,
Stefan.

> 
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  arch/arm/boot/dts/vf-colibri.dtsi | 4 
> >  arch/arm/boot/dts/vfxxx.dtsi  | 6 ++
> >  2 files changed, 10 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/vf-colibri.dtsi
> > b/arch/arm/boot/dts/vf-colibri.dtsi
> > index b741709..21bfef9 100644
> > --- a/arch/arm/boot/dts/vf-colibri.dtsi
> > +++ b/arch/arm/boot/dts/vf-colibri.dtsi
> > @@ -108,6 +108,10 @@
> > status = "okay";
> >  };
> >  
> > + {
> > +   status = "okay";
> > +};
> > +
> >   {
> > pinctrl-names = "default";
> > pinctrl-0 = <_esdhc1>;
> > diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> > index 2c13ec6..eac4213 100644
> > --- a/arch/arm/boot/dts/vfxxx.dtsi
> > +++ b/arch/arm/boot/dts/vfxxx.dtsi
> > @@ -194,6 +194,9 @@
> > clocks = < VF610_CLK_DSPI0>;
> > clock-names = "dspi";
> > spi-num-chipselects = <6>;
> > +   dmas = < 1 12>,
> > +   < 1 13>;
> > +   dma-names = "rx", "tx";
> > status = "disabled";
> > };
> >  
> > @@ -206,6 +209,9 @@
> > clocks = < VF610_CLK_DSPI1>;
> > clock-names = "dspi";
> > spi-num-chipselects = <4>;
> > +   dmas = < 1 14>,
> > +   < 1 15>;
> > +   dma-names = "rx", "tx";
> > status = "disabled";
> > };

Re: [PATCH v2 1/3] ARM: dts: imx6qdl-apalis: Do not rely on DDC I2C bus bitbang for HDMI

2016-11-08 Thread maitysanchayan

Hello Shawn,

On 16-10-22 15:43:04, Vladimir Zapolskiy wrote:
> Hi Shawn,
> 
> On 10/22/2016 06:25 AM, Shawn Guo wrote:
> > On Mon, Sep 19, 2016 at 10:41:51AM +0530, Sanchayan Maity wrote:
> > > Remove the use of DDC I2C bus bitbang to support reading of EDID
> > > and rely on support from internal HDMI I2C master controller instead.
> > > As a result remove the device tree property ddc-i2c-bus.
> > > 
> > > Signed-off-by: Sanchayan Maity 
> > 
> > I think that the dw-hdmi i2c support [1] is a prerequisite of this
> > patch.  I do not see it lands on v4.9-rc1.  Or am I missing something?
> > 
> > Shawn
> > 
> > [1] https://patchwork.kernel.org/patch/9296883/
> > 
> 
> I'm adding Philipp to Cc, since he is the last one who tested the change
> and helped me to push the change to the mainline:
> 
>   https://lists.freedesktop.org/archives/dri-devel/2016-September/118569.html
> 
> The problem is that there is no official DW HDMI bridge maintainer, may be
> you can review the change, and if you find it satisfactory push it through
> ARM/iMX tree.

Shawn, is it okay if that patch goes through your ARM/iMX tree?

- Sanchayan.

Re: [PATCH v2 1/4] spi: spi-fsl-dspi: Fix SPI transfer issue when using multiple SPI_IOC_MESSAGE

Hello Mark,

On 16-11-21 19:18:47, Mark Brown wrote:
> On Mon, Nov 21, 2016 at 11:24:01AM +0530, Sanchayan Maity wrote:
> > Current DMA implementation had a bug where the DMA transfer would
> > exit the loop in dspi_transfer_one_message after the completion of
> > a single transfer. This results in a multi message transfer submitted
> > with SPI_IOC_MESSAGE to terminate incorrectly without an error.
> 
> Please don't resend already applied patches.  If there are any changes
> needed please send incremental changes on top of what's already applied.

This is not a resend of an applied patch. The whole series applies on
top of your topic/fsl-dspi branch and has fixes for the SPI DMA as
incremental changes

- Sanchaya.

Re: [PATCH v2 1/4] spi: spi-fsl-dspi: Fix SPI transfer issue when using multiple SPI_IOC_MESSAGE

Hello Mark,

On 16-11-22 00:44:30, maitysancha...@gmail.com wrote:
> Hello Mark,
> 
> On 16-11-21 19:18:47, Mark Brown wrote:
> > On Mon, Nov 21, 2016 at 11:24:01AM +0530, Sanchayan Maity wrote:
> > > Current DMA implementation had a bug where the DMA transfer would
> > > exit the loop in dspi_transfer_one_message after the completion of
> > > a single transfer. This results in a multi message transfer submitted
> > > with SPI_IOC_MESSAGE to terminate incorrectly without an error.
> > 
> > Please don't resend already applied patches.  If there are any changes
> > needed please send incremental changes on top of what's already applied.
> 
> This is not a resend of an applied patch. The whole series applies on
> top of your topic/fsl-dspi branch and has fixes for the SPI DMA as
> incremental changes
> 
Sorry. I take that back. I now see you applied the patch and I got the applied
mail after I replied.

- Sanchayan.

Re: [PATCH v2 2/4] spi: spi-fsl-dspi: Fix continuous selection format

On 16-11-21 15:15:41, Stefan Agner wrote:
> On 2016-11-20 21:54, Sanchayan Maity wrote:
> > Current DMA implementation was not handling the continuous selection
> > format viz. SPI chip select would be deasserted even between sequential
> > serial transfers. Use the cs_change variable and correctly set or
> > reset the CONT bit accordingly for case where peripherals require
> > the chip select to be asserted between sequential transfers.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  drivers/spi/spi-fsl-dspi.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> > index b1ee1f5..41422cd 100644
> > --- a/drivers/spi/spi-fsl-dspi.c
> > +++ b/drivers/spi/spi-fsl-dspi.c
> > @@ -261,6 +261,8 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi 
> > *dspi)
> > dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
> > SPI_PUSHR_PCS(dspi->cs) |
> > SPI_PUSHR_CTAS(0);
> > +   if (!dspi->cs_change)
> > +   dspi->dma->tx_dma_buf[i] |= SPI_PUSHR_CONT;
> > dspi->tx += tx_word + 1;
> >  
> > dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,
> 
> Other transfer mode use:
> 
> if ((dspi->cs_change) && (!dspi->len))  
>
> dspi_pushr &= ~SPI_PUSHR_CONT;
> 
> which indicates that they only clear SPI_PUSHR_CONT at the very end of a
> transfer... The DMA code currently deselects after every DMA transfer if
> dspi->cs_change is set.
> 
> Maybe we should use the helper dspi_data_to_pushr to fill the DMA buffer
> and _clear_ SPI_PUSHR_CONT if necessary like the other transfer modes
> do... Then we can use the for loop to fill the complete buffer and get
> rid of some code dupplication.
> 
> I see that dspi_data_to_pushr does move len too, which we did not in the
> DMA case. dspi->len gets incremented only on successful DMA transfer in
> dspi_dma_xfer. However, I wonder if that is not even a bug: We increment
> dspi->tx always, but len only on success. This makes len go off sync
> with regards to the tx pointer which does not help anybody. So lets get
> rid of the update code in dspi_dma_xfer
> 

Thanks for the feedback. Using dspi_data_to_pushr really cleans up that
tx path very nicely. Why didn't I see it. Will send a follow up patch
soon after testing again.

- Sanchayan.

Re: [PATCH v2 4/4] spi: spi-fsl-dspi: Minor code cleanup and error path fixes

On 16-11-21 15:22:09, Stefan Agner wrote:
> On 2016-11-20 21:54, Sanchayan Maity wrote:
> > Code cleanup for improving code readability and error path fixes
> > and cleanup removing use of devm_kfree.
> 
> Two things in one, not very nice. Especially the dma_free_coherent is
> really a bug and the other is a cleanup. Can you make a separate patch
> for the bug?
> 
> As for the cleanup, I don't like the one line conditions too, but I
> don't think it is worth a patch. At least the TX path should be solved
> with my suggestion in patch 2.

Agreed.

- Sanchayan.

> 
> --
> Stefan
> 
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  drivers/spi/spi-fsl-dspi.c | 22 --
> >  1 file changed, 16 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> > index 08882f7..2987a16 100644
> > --- a/drivers/spi/spi-fsl-dspi.c
> > +++ b/drivers/spi/spi-fsl-dspi.c
> > @@ -226,8 +226,10 @@ static void dspi_rx_dma_callback(void *arg)
> > if (!(dspi->dataflags & TRAN_STATE_RX_VOID)) {
> > for (i = 0; i < dma->curr_xfer_len; i++) {
> > d = dspi->dma->rx_dma_buf[i];
> > -   rx_word ? (*(u16 *)dspi->rx = d) :
> > -   (*(u8 *)dspi->rx = d);
> > +   if (rx_word)
> > +   *(u16 *)dspi->rx = d;
> > +   else
> > +   *(u8 *)dspi->rx = d;
> > dspi->rx += rx_word + 1;
> > }
> > }
> > @@ -247,14 +249,20 @@ static int dspi_next_xfer_dma_submit(struct
> > fsl_dspi *dspi)
> > tx_word = is_double_byte_mode(dspi);
> >  
> > for (i = 0; i < dma->curr_xfer_len - 1; i++) {
> > -   val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
> > +   if (tx_word)
> > +   val = *(u16 *) dspi->tx;
> > +   else
> > +   val = *(u8 *) dspi->tx;
> > dspi->dma->tx_dma_buf[i] =
> > SPI_PUSHR_TXDATA(val) | SPI_PUSHR_PCS(dspi->cs) |
> > SPI_PUSHR_CTAS(0) | SPI_PUSHR_CONT;
> > dspi->tx += tx_word + 1;
> > }
> >  
> > -   val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
> > +   if (tx_word)
> > +   val = *(u16 *) dspi->tx;
> > +   else
> > +   val = *(u8 *) dspi->tx;
> > dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
> > SPI_PUSHR_PCS(dspi->cs) |
> > SPI_PUSHR_CTAS(0);
> > @@ -430,9 +438,11 @@ static int dspi_request_dma(struct fsl_dspi
> > *dspi, phys_addr_t phy_addr)
> > return 0;
> >  
> >  err_slave_config:
> > -   devm_kfree(dev, dma->rx_dma_buf);
> > +   dma_free_coherent(dev, DSPI_DMA_BUFSIZE,
> > +   dma->rx_dma_buf, dma->rx_dma_phys);
> >  err_rx_dma_buf:
> > -   devm_kfree(dev, dma->tx_dma_buf);
> > +   dma_free_coherent(dev, DSPI_DMA_BUFSIZE,
> > +   dma->tx_dma_buf, dma->tx_dma_phys);
> >  err_tx_dma_buf:
> > dma_release_channel(dma->chan_tx);
> >  err_tx_channel:

Re: [PATCH 3/4] spi: spi-fsl-dspi: Fix continuous selection format

2016-11-18 Thread maitysanchayan

Hello Stefan,

On 16-11-17 17:07:24, Stefan Agner wrote:
> On 2016-11-17 04:16, Sanchayan Maity wrote:
> > Current DMA implementation was not handling the continuous selection
> > format viz. SPI chip select would be deasserted even between sequential
> > serial transfers. Use the cs_change variable and correctly set or
> > reset the CONT bit accordingly for case where peripherals require
> > the chip select to be asserted between sequential transfers.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  drivers/spi/spi-fsl-dspi.c | 13 ++---
> >  1 file changed, 10 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> > index aee8c88..164e2e1 100644
> > --- a/drivers/spi/spi-fsl-dspi.c
> > +++ b/drivers/spi/spi-fsl-dspi.c
> > @@ -258,9 +258,16 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi 
> > *dspi)
> > }
> >  
> > val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
> > -   dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
> > -   SPI_PUSHR_PCS(dspi->cs) |
> > -   SPI_PUSHR_CTAS(0);
> > +   if (dspi->cs_change) {
> > +   dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
> > +   SPI_PUSHR_PCS(dspi->cs) |
> > +   SPI_PUSHR_CTAS(0);
> > +   } else {
> > +   dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
> > +   SPI_PUSHR_PCS(dspi->cs) |
> > +   SPI_PUSHR_CTAS(0) |
> > +   SPI_PUSHR_CONT;
> > +   }
> 
> How about:
> 
> 
>   dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
>   SPI_PUSHR_PCS(dspi->cs) |
>   SPI_PUSHR_CTAS(0);
> 
> + if (dspi->cs_change)
> + dspi->dma->tx_dma_buf[i] |= SPI_PUSHR_CONT;
> 
> 
> Avoids code duplication...

Agreed. It's much better. Should be !dspi->cs_change though.

Will include it in next iteration.

Thanks & Regards,
Sanchayan.

> 
> --
> Stefan
> 
> 
> 
> > dspi->tx += tx_word + 1;
> >  
> > dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,

Re: [PATCH 2/4] spi: spi-fsl-dspi: Fix incorrect DMA setup

2016-11-18 Thread maitysanchayan

On 16-11-17 17:03:19, Stefan Agner wrote:
> On 2016-11-17 04:16, Sanchayan Maity wrote:
> > Currently dmaengine_prep_slave_single was being called with length
> > set to the complete DMA buffer size. This resulted in unwanted bytes
> > being transferred to the SPI register leading to clock and MOSI lines
> > having unwanted data even after chip select got deasserted and the
> > required bytes having been transferred.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  drivers/spi/spi-fsl-dspi.c | 10 --
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> > index b1ee1f5..aee8c88 100644
> > --- a/drivers/spi/spi-fsl-dspi.c
> > +++ b/drivers/spi/spi-fsl-dspi.c
> > @@ -265,7 +265,10 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi 
> > *dspi)
> >  
> > dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,
> > dma->tx_dma_phys,
> > -   DSPI_DMA_BUFSIZE, DMA_MEM_TO_DEV,
> > +   dma->curr_xfer_len *
> > +   DMA_SLAVE_BUSWIDTH_4_BYTES /
> > +   (tx_word ? 2 : 1),
> > +   DMA_MEM_TO_DEV,
> 
> Hm, this is getting ridiculous, I think we convert curr_xfer_len from
> bytes to DMA transfers in almost every use.
> 
> Can we make it be transfer length in actual 4 byte transfers? We then
> probably have to convert it to bytes once to subtract from
> curr_remaining_bytes, but I think it would simplify code overall...

Will the below be acceptable fix?

diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 41422cd..db7f091 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -217,15 +217,13 @@ static void dspi_rx_dma_callback(void *arg)
struct fsl_dspi *dspi = arg;
struct fsl_dspi_dma *dma = dspi->dma;
int rx_word;
-   int i, len;
+   int i;
u16 d;
 
rx_word = is_double_byte_mode(dspi);
 
-   len = rx_word ? (dma->curr_xfer_len / 2) : dma->curr_xfer_len;
-
if (!(dspi->dataflags & TRAN_STATE_RX_VOID)) {
-   for (i = 0; i < len; i++) {
+   for (i = 0; i < dma->curr_xfer_len; i++) {
d = dspi->dma->rx_dma_buf[i];
rx_word ? (*(u16 *)dspi->rx = d) :
(*(u8 *)dspi->rx = d);
@@ -242,14 +240,12 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi 
*dspi)
struct device *dev = >pdev->dev;
int time_left;
int tx_word;
-   int i, len;
+   int i;
u16 val;
 
tx_word = is_double_byte_mode(dspi);
 
-   len = tx_word ? (dma->curr_xfer_len / 2) : dma->curr_xfer_len;
-
-   for (i = 0; i < len - 1; i++) {
+   for (i = 0; i < dma->curr_xfer_len - 1; i++) {
val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
dspi->dma->tx_dma_buf[i] =
SPI_PUSHR_TXDATA(val) | SPI_PUSHR_PCS(dspi->cs) |
@@ -267,7 +263,9 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
 
dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,
dma->tx_dma_phys,
-   DSPI_DMA_BUFSIZE, DMA_MEM_TO_DEV,
+   dma->curr_xfer_len *
+   DMA_SLAVE_BUSWIDTH_4_BYTES,
+   DMA_MEM_TO_DEV,
DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!dma->tx_desc) {
dev_err(dev, "Not able to get desc for DMA xfer\n");
@@ -283,7 +281,9 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
 
dma->rx_desc = dmaengine_prep_slave_single(dma->chan_rx,
dma->rx_dma_phys,
-   DSPI_DMA_BUFSIZE, DMA_DEV_TO_MEM,
+   dma->curr_xfer_len *
+   DMA_SLAVE_BUSWIDTH_4_BYTES,
+   DMA_DEV_TO_MEM,
DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!dma->rx_desc) {
dev_err(dev, "Not able to get desc for DMA xfer\n");
@@ -330,17 +330,17 @@ static int dspi_dma_xfer(struct fsl_dspi *dspi)
struct device *dev = >pdev->dev;
int curr_remaining_bytes;
int bytes_per_buffer;
-   int tx_word;
+   int tx_word = 1;
int ret = 0;
 
-   tx_word = is_double_byte_mode(dspi);
+   if (is_double_byte_mode(dspi))
+   tx_word = 2;
curr_remaining_bytes = dspi->len;
+   bytes_per_buffer = DSPI_DMA_BUFSIZE / DSPI_FIFO_SIZE;
while (curr_remaining_bytes) {
/* Check if current transfer fits the DMA buffer

Re: [PATCH] ARM: dts: vfxxx: Enable DMA for DSPI2 and DSPI3

2016-11-11 Thread maitysanchayan

On 16-11-11 20:46:12, Fabio Estevam wrote:
> On Thu, Nov 10, 2016 at 9:45 AM, Sanchayan Maity
>  wrote:
> > Enable DMA for DSPI2 and DSPI3 on Vybrid.
> 
> You missed your Signed-off-by line.

Argh...Sorry about that...Will send a follow patch with this fixed.

- Sanchayan.

Re: [PATCH v2] spi: spi-fsl-dspi: Add DMA support for Vybrid

2016-10-17 Thread maitysanchayan

Hello,

Ping?

Regards,
Sanchayan.

On 16-10-04 16:28:33, Sanchayan Maity wrote:
> Add DMA support for Vybrid.
> 
> Signed-off-by: Sanchayan Maity 
> ---
> Changes since v1:
> - Change in the dspi_dma_xfer function. Use more apt DSPI_FIFO_SIZE
> instead of sizeof(u32)
> - Do not set RSER on every iteration of loop
> 
> Tested on Toradex Colibri Vybrid VF61 module with spi based MCP CAN 251x
> and spidev using RX/TX loopback and based on shawn's for-next branch
> currently at 4.8-rc1.
> 
> Regards,
> Sanchayan.
> ---
>  drivers/spi/spi-fsl-dspi.c | 291 
> +
>  1 file changed, 291 insertions(+)
> 
> diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> index 9e9dadb..0f81075 100644
> --- a/drivers/spi/spi-fsl-dspi.c
> +++ b/drivers/spi/spi-fsl-dspi.c
> @@ -15,6 +15,8 @@
>  
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -40,6 +42,7 @@
>  #define TRAN_STATE_WORD_ODD_NUM  0x04
>  
>  #define DSPI_FIFO_SIZE   4
> +#define DSPI_DMA_BUFSIZE (DSPI_FIFO_SIZE * 1024)
>  
>  #define SPI_MCR  0x00
>  #define SPI_MCR_MASTER   (1 << 31)
> @@ -71,6 +74,11 @@
>  #define SPI_SR_EOQF  0x1000
>  #define SPI_SR_TCFQF 0x8000
>  
> +#define SPI_RSER_TFFFE   BIT(25)
> +#define SPI_RSER_TFFFD   BIT(24)
> +#define SPI_RSER_RFDFE   BIT(17)
> +#define SPI_RSER_RFDFD   BIT(16)
> +
>  #define SPI_RSER 0x30
>  #define SPI_RSER_EOQFE   0x1000
>  #define SPI_RSER_TCFQE   0x8000
> @@ -108,6 +116,8 @@
>  
>  #define SPI_TCR_TCNT_MAX 0x1
>  
> +#define DMA_COMPLETION_TIMEOUT   msecs_to_jiffies(3000)
> +
>  struct chip_data {
>   u32 mcr_val;
>   u32 ctar_val;
> @@ -117,6 +127,7 @@ struct chip_data {
>  enum dspi_trans_mode {
>   DSPI_EOQ_MODE = 0,
>   DSPI_TCFQ_MODE,
> + DSPI_DMA_MODE,
>  };
>  
>  struct fsl_dspi_devtype_data {
> @@ -139,6 +150,22 @@ static const struct fsl_dspi_devtype_data ls2085a_data = 
> {
>   .max_clock_factor = 8,
>  };
>  
> +struct fsl_dspi_dma {
> + u32 curr_xfer_len;
> +
> + u32 *tx_dma_buf;
> + struct dma_chan *chan_tx;
> + dma_addr_t tx_dma_phys;
> + struct completion cmd_tx_complete;
> + struct dma_async_tx_descriptor *tx_desc;
> +
> + u32 *rx_dma_buf;
> + struct dma_chan *chan_rx;
> + dma_addr_t rx_dma_phys;
> + struct completion cmd_rx_complete;
> + struct dma_async_tx_descriptor *rx_desc;
> +};
> +
>  struct fsl_dspi {
>   struct spi_master   *master;
>   struct platform_device  *pdev;
> @@ -165,6 +192,7 @@ struct fsl_dspi {
>   u32 waitflags;
>  
>   u32 spi_tcnt;
> + struct fsl_dspi_dma *dma;
>  };
>  
>  static inline int is_double_byte_mode(struct fsl_dspi *dspi)
> @@ -368,6 +396,259 @@ static void dspi_tcfq_read(struct fsl_dspi *dspi)
>   dspi_data_from_popr(dspi, rx_word);
>  }
>  
> +static void dspi_tx_dma_callback(void *arg)
> +{
> + struct fsl_dspi *dspi = arg;
> + struct fsl_dspi_dma *dma = dspi->dma;
> +
> + complete(>cmd_tx_complete);
> +}
> +
> +static void dspi_rx_dma_callback(void *arg)
> +{
> + struct fsl_dspi *dspi = arg;
> + struct fsl_dspi_dma *dma = dspi->dma;
> + int rx_word;
> + int i, len;
> + u16 d;
> +
> + rx_word = is_double_byte_mode(dspi);
> +
> + len = rx_word ? (dma->curr_xfer_len / 2) : dma->curr_xfer_len;
> +
> + if (!(dspi->dataflags & TRAN_STATE_RX_VOID)) {
> + for (i = 0; i < len; i++) {
> + d = dspi->dma->rx_dma_buf[i];
> + rx_word ? (*(u16 *)dspi->rx = d) :
> + (*(u8 *)dspi->rx = d);
> + dspi->rx += rx_word + 1;
> + }
> + }
> +
> + complete(>cmd_rx_complete);
> +}
> +
> +static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
> +{
> + struct fsl_dspi_dma *dma = dspi->dma;
> + struct device *dev = >pdev->dev;
> + int time_left;
> + int tx_word;
> + int i, len;
> + u16 val;
> +
> + tx_word = is_double_byte_mode(dspi);
> +
> + len = tx_word ? (dma->curr_xfer_len / 2) : dma->curr_xfer_len;
> +
> + for (i = 0; i < len - 1; i++) {
> + val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
> + dspi->dma->tx_dma_buf[i] =
> + SPI_PUSHR_TXDATA(val) | SPI_PUSHR_PCS(dspi->cs) |
> + SPI_PUSHR_CTAS(0) | SPI_PUSHR_CONT;
> + dspi->tx += tx_word + 1;
> + }
> +
> + val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
> + dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
> + SPI_PUSHR_PCS(dspi->cs) |
> + SPI_PUSHR_CTAS(0);
> + dspi->tx += tx_word + 1;
>

Re: [PATCH] ARM: dts: imx6: Add support for Toradex Colibri iMX6 module

2016-10-17 Thread maitysanchayan

Hello,

Ping?

- Sanchayan.

On 16-09-21 16:54:38, Sanchayan Maity wrote:
> Add support for Toradex Colibri iMX6 module.
> 
> Signed-off-by: Sanchayan Maity 
> ---
>  arch/arm/boot/dts/Makefile   |   1 +
>  arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts | 253 
>  arch/arm/boot/dts/imx6qdl-colibri.dtsi   | 890 
> +++
>  3 files changed, 1144 insertions(+)
>  create mode 100644 arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
>  create mode 100644 arch/arm/boot/dts/imx6qdl-colibri.dtsi
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index f79cac2..44ff380 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -323,6 +323,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
>   imx6dl-aristainetos_7.dtb \
>   imx6dl-aristainetos2_4.dtb \
>   imx6dl-aristainetos2_7.dtb \
> + imx6dl-colibri-eval-v3.dtb \
>   imx6dl-cubox-i.dtb \
>   imx6dl-dfi-fs700-m60.dtb \
>   imx6dl-gw51xx.dtb \
> diff --git a/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts 
> b/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
> new file mode 100644
> index 000..e0c2172
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
> @@ -0,0 +1,253 @@
> +/*
> + * Copyright 2014-2016 Toradex AG
> + * Copyright 2012 Freescale Semiconductor, Inc.
> + * Copyright 2011 Linaro Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file 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.
> + *
> + * This file is distributed in the hope that it will be useful
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include 
> +#include 
> +#include "imx6dl.dtsi"
> +#include "imx6qdl-colibri.dtsi"
> +
> +/ {
> + model = "Toradex Colibri iMX6DL/S on Colibri Evaluation Board V3";
> + compatible = "toradex,colibri_imx6dl-eval-v3", "toradex,colibri_imx6dl",
> +  "fsl,imx6dl";
> +
> + aliases {
> + i2c0 = 
> + i2c1 = 
> + };
> +
> + aliases {
> + rtc0 = _i2c;
> + rtc1 = _rtc;
> + };
> +
> + clocks {
> + /* Fixed crystal dedicated to mcp251x */
> + clk16m: clk@1 {
> + compatible = "fixed-clock";
> + reg = <1>;
> + #clock-cells = <0>;
> + clock-frequency = <1600>;
> + clock-output-names = "clk16m";
> + };
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + pinctrl-names = "default";
> + pinctrl-0 = <_gpio_keys>;
> +
> + wakeup {
> + label = "Wake-Up";
> + gpios = < 22 GPIO_ACTIVE_HIGH>; /* SODIMM 45 */
> + linux,code = ;
> + debounce-interval = <10>;
> + wakeup-source;
> + };
> + };
> +
> + lcd_display: display@di0 {
> + compatible = "fsl,imx-parallel-display";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interface-pix-fmt = "bgr666";
> + pinctrl-names = "default";
> + pinctrl-0 = <_ipu1_lcdif>;
> +

Re: [PATCH v3 2/2] soc: Add driver for Freescale Vybrid Platform

2015-05-22 Thread maitysanchayan

Hello Arnd,

On 15-05-22 13:11:46, Arnd Bergmann wrote:
> On Friday 22 May 2015 16:21:54 Sanchayan Maity wrote:
> > +#define OCOTP_CFG0_OFFSET  0x0410
> > +#define OCOTP_CFG1_OFFSET  0x0420
> > +#define MSCM_CPxCOUNT_OFFSET   0x002C
> > +#define MSCM_CPxCFG1_OFFSET0x0014
> > +#define ROM_REVISION_OFFSET0x0080
> > +
> > +static const struct of_device_id vf610_soc_bus_match[] = {
> > +   { .compatible = "fsl,vf610-mscm-cpucfg", },
> > +   { /* sentinel */ }
> > +};
> > +
> > +static int __init vf610_soc_init(void)
> > +{
> > +   struct regmap *ocotp_regmap, *mscm_regmap, *rom_regmap;
> > +   struct soc_device_attribute *soc_dev_attr;
> > +   struct soc_device *soc_dev;
> > +   struct device_node *np;
> > +   char soc_type[] = "xx0";
> > +   u32 cpxcount, cpxcfg1;
> > +   u32 soc_id1, soc_id2, rom_rev;
> > +   u64 soc_id;
> > +   int ret;
> > +
> > +   np = of_find_matching_node(NULL, vf610_soc_bus_match);
> > +   if (!np)
> > +   return -ENODEV;
> > +
> 
> Why not use module_platform_driver() and make this a probe function instead?

Had done that but after having a look at the existing integrator and versatile
platform implementation, I changed it. Will switch to using that.

> 
> > +   ocotp_regmap = syscon_regmap_lookup_by_compatible("fsl,vf610-ocotp");
> > +   if (IS_ERR(ocotp_regmap)) {
> > +   pr_err("regmap lookup for octop failed\n");
> > +   return PTR_ERR(ocotp_regmap);
> > +   }
> > +
> > +   mscm_regmap = 
> > syscon_regmap_lookup_by_compatible("fsl,vf610-mscm-cpucfg");
> > +   if (IS_ERR(mscm_regmap)) {
> > +   pr_err("regmap lookup for mscm failed");
> > +   return PTR_ERR(mscm_regmap);
> > +   }
> > +
> > +   rom_regmap = syscon_regmap_lookup_by_compatible("fsl,vf610-ocrom");
> > +   if (IS_ERR(rom_regmap)) {
> > +   pr_err("regmap lookup for ocrom failed");
> > +   return PTR_ERR(rom_regmap);
> > +   }
> 
> Can you use syscon_regmap_lookup_by_phandle instead, and put the
> phandles in the fsl,vf610-mscm-cpucfg node?

Ok. Will do so.

- Sanchayan.

> 
> Also, I'd argue that the mscm should not be a syscon device at all,
> but instead I'd use platform_get_resource()/devm_ioremap_resource()
> to get an __iomem pointer.
> 
>   Arnd
--
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 2/2] soc: Add driver for Freescale Vybrid Platform

2015-05-25 Thread maitysanchayan

Hello Arnd,

On 15-05-22 15:20:00, Arnd Bergmann wrote:
> On Friday 22 May 2015 14:02:52 Stefan Agner wrote:
> > > Can you use syscon_regmap_lookup_by_phandle instead, and put the
> > > phandles in the fsl,vf610-mscm-cpucfg node?
> > 
> > Hm, with that we would wire up hardware modules which does nothing has
> > to do with each other. We just happen to need a driver which collects
> > information accross the SoC. I'm not sure we should put the modules
> > required into the device tree.
> > 
> > I don't think its nice to have the compatible strings in the source
> > code, however it feels more appropriate than in the device tree, IMHO...
> 
> I see. Another option would be to point directly to the registers
> you need:
> 
>   ocotp-cfg0 = < 0x10>;
>   ocotp-cfg1 = < 0x20>;
>   rom-revision = < 0x80>;
> 
> We don't yet have an abstraction to access a register from a syscon
> reference like this, but you could either roll your own here, or 
> add a generic abstraction.

Can you tell me a little about how can I start implementing it? I am not
clear on how to approach this.

> 
> > > Also, I'd argue that the mscm should not be a syscon device at all,
> > > but instead I'd use platform_get_resource()/devm_ioremap_resource()
> > > to get an __iomem pointer.
> > 
> > We need to have mscm-cpucfg to be syscon because we need to get the CPU
> > personality in the MSCM interrupt router driver (irq-vf610-mscm-ir.c). 
> 
> It can be both at the same time now.
> 
>   Arnd

Regards,
Sanchayan.
--
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 3/4] touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50

Hello Dmitry,

On 15-08-03 14:04:09, Dmitry Torokhov wrote:
> Hi Sanchayan,
> 
> On Mon, Aug 03, 2015 at 08:55:44PM +0530, maitysancha...@gmail.com wrote:
> > Hello Dmitry,
> > 
> > On 15-07-21 10:20:44, Dmitry Torokhov wrote:
> > > Hi Stefan,
> > > 
> > > On Tue, Jul 21, 2015 at 04:43:36PM +0200, Stefan Agner wrote:
> > > > Hi Dmitry,
> > > > 
> > > > As the original author of the driver I have some remarks to your review
> > > > 
> > > > On 2015-07-18 01:42, Dmitry Torokhov wrote:
> > > > >> +/*
> > > > >> + * If touch pressure is too low, stop measuring and 
> > > > >> reenable
> > > > >> + * touch detection
> > > > >> + */
> > > > >> +if (val_p < min_pressure || val_p > 2000)
> > > > >> +break;
> > > > 
> > > > This is where the modules touch pressure is used to stop the measurement
> > > > process and switch back to interrupt mode. See my remarks at the end.
> > > > 
> > > > >> +
> > > > >> +/*
> > > > >> + * The pressure may not be enough for the first x and 
> > > > >> the
> > > > >> + * second y measurement, but, the pressure is ok when 
> > > > >> the
> > > > >> + * driver is doing the third and fourth measurement. To
> > > > >> + * take care of this, we drop the first measurement 
> > > > >> always.
> > > > >> + */
> > > > >> +if (discard_val_on_start) {
> > > > >> +discard_val_on_start = false;
> > > > >> +} else {
> > > > >> +/*
> > > > >> + * Report touch position and sleep for
> > > > >> + * next measurement
> > > > >> + */
> > > > >> +input_report_abs(vf50_ts->ts_input,
> > > > >> +ABS_X, VF_ADC_MAX - val_x);
> > > > >> +input_report_abs(vf50_ts->ts_input,
> > > > >> +ABS_Y, VF_ADC_MAX - val_y);
> > > > >> +input_report_abs(vf50_ts->ts_input,
> > > > >> +ABS_PRESSURE, val_p);
> > > > >> +input_report_key(vf50_ts->ts_input, BTN_TOUCH, 
> > > > >> 1);
> > > > >> +input_sync(vf50_ts->ts_input);
> > > > >> +}
> > > > >> +
> > > > >> +msleep(10);
> > > > >> +}
> > > > >> +
> > > > >> +/* Report no more touch, reenable touch detection */
> > > > >> +input_report_abs(vf50_ts->ts_input, ABS_PRESSURE, 0);
> > > > >> +input_report_key(vf50_ts->ts_input, BTN_TOUCH, 0);
> > > > >> +input_sync(vf50_ts->ts_input);
> > > > >> +
> > > > >> +vf50_ts_enable_touch_detection(vf50_ts);
> > > > >> +
> > > > >> +/* Wait for the pull-up to be stable on high */
> > > > >> +msleep(10);
> > > > >> +
> > > > >> +/* Reenable IRQ to detect touch */
> > > > >> +enable_irq(vf50_ts->pen_irq);
> > > > >> +
> > > > >> +dev_dbg(dev, "Reenabled touch detection interrupt\n");
> > > > >> +}
> > > > >> +
> > > > >> +static irqreturn_t vf50_ts_touched(int irq, void *dev_id)
> > > > >> +{
> > > > >> +struct vf50_touch_device *vf50_ts = (struct vf50_touch_device 
> > > > >> *)dev_id;
> > > > >> +struct device *dev = _ts->pdev->dev;
> > > > >> +
> > > > >> +dev_dbg(dev, "Touch detected, start worker thread\n");
> > > > >> +
> > > > >> +disable_irq_nosync(irq);
> > > > >> +
> > > > >> +/* Disable the touch detection plates */
> > > > >> +gpiod_set_value(vf50_ts->gpio_ym, 0);
> > > > >> +
> > > > >> +/* Let the platform mux to default state in order to mux as ADC 
> > > > >> */
> > > > >> +pinctrl_pm_select_default_state(dev);
> > > > >> +
> > > > >> +queue_work(vf50_ts->ts_workqueue, _ts->ts_work);
> > > > > 
> > > > > If you convert this to a threaded interrupt you won't need to
> > > > > disable/reenable interrupt or queue work. You should also be able to 
> > > > > use
> > > > > gpiod_set_value_cansleep() extending the range of ways the controller
> > > > > could be connected to systems.
> > > > > 
> > > > 
> > > > I'm not sure if a threaded interrupt is the right thing here. While the
> > > > pen is on the touchscreen (which can be for several seconds)
> > > > measurements have to be made in a continuous loop. Is it ok for a
> > > > threaded interrupt to run that long?
> > > 
> > > Yes, why not? Threaded interrupt is simply a kernel thread that is woken
> > > when hard interrupt handler tells it to wake up. Very similar to
> > > interrupt + work queue, except that the kernel manages interactions
> > > properly for you. There are several drivers in kernel that do that, for
> > > example auo-pixcir-ts.c or tsc2007.c
> > > 
> > > > 
> > > > I'm also not sure if it is really safe to _not_ disable the pen down
> > > > GPIO interrupt. If we get a interrupt while measuring, we should ignore
> > > > that interrupt.
> > > 
> > > The interrupt management core

Re: [PATCH] iio: adc: vf610: Add IIO buffer support for Vybrid ADC

Hello,

On 15-08-04 03:18:46, Duan Andy wrote:
> From: Sanchayan Maity  Sent: Monday, August 03, 
> 2015 11:10 PM
> > To: ji...@kernel.org; linux-...@vger.kernel.org
> > Cc: ste...@agner.ch; Duan Fugang-B38611; hof...@osadl.org;
> > sanjeev_sha...@mentor.com; Estevam Fabio-R49496; knaac...@gmx.de;
> > l...@metafoo.de; pme...@pmeerw.net; antoine.ten...@free-electrons.com;
> > linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > Sanchayan Maity
> > Subject: [PATCH] iio: adc: vf610: Add IIO buffer support for Vybrid ADC
> > 
> > This patch adds support for IIO buffer to the Vybrid ADC driver.
> > IIO triggered buffer infrastructure along with iio sysfs trigger is used
> > to leverage continuous sampling support provided by the ADC block.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  drivers/iio/adc/Kconfig |   4 ++
> >  drivers/iio/adc/vf610_adc.c | 122
> > +---
> >  2 files changed, 120 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index
> > 7c55658..4661241 100644
> > --- a/drivers/iio/adc/Kconfig
> > +++ b/drivers/iio/adc/Kconfig
> > @@ -337,6 +337,10 @@ config TWL6030_GPADC  config VF610_ADC
> > tristate "Freescale vf610 ADC driver"
> > depends on OF
> > +   select IIO_BUFFER
> > +   select IIO_TRIGGER
> > +   select IIO_SYSFS_TRIGGER
> > +   select IIO_TRIGGERED_BUFFER
> > help
> >   Say yes here to support for Vybrid board analog-to-digital
> > converter.
> >   Since the IP is used for i.MX6SLX, the driver also support
> > i.MX6SLX.
> > diff --git a/drivers/iio/adc/vf610_adc.c b/drivers/iio/adc/vf610_adc.c
> > index 23b8fb9..af72b9a 100644
> > --- a/drivers/iio/adc/vf610_adc.c
> > +++ b/drivers/iio/adc/vf610_adc.c
> > @@ -34,8 +34,11 @@
> >  #include 
> > 
> >  #include 
> > +#include 
> >  #include 
> > -#include 
> > +#include 
> > +#include  #include
> > +
> > 
> >  /* This will be the driver name the kernel reports */  #define
> > DRIVER_NAME "vf610-adc"
> > @@ -170,6 +173,7 @@ struct vf610_adc {
> > u32 sample_freq_avail[5];
> > 
> > struct completion completion;
> > +   u16 *buffer;
> >  };
> > 
> >  static const u32 vf610_hw_avgs[] = { 1, 4, 8, 16, 32 }; @@ -505,12
> > +509,22 @@ static const struct iio_chan_spec_ext_info vf610_ext_info[] =
> > {
> > .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) |  \
> > BIT(IIO_CHAN_INFO_SAMP_FREQ),   \
> > .ext_info = vf610_ext_info, \
> > +   .address = (_idx),  \
> > +   .scan_index = (_idx),   \
> > +   .scan_type.sign = 'u',  \
> > +   .scan_type.realbits = 12,   \
> > +   .scan_type.storagebits = 16,\
> >  }
> > 
> >  #define VF610_ADC_TEMPERATURE_CHAN(_idx, _chan_type) { \
> > .type = (_chan_type),   \
> > .channel = (_idx),  \
> > .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED), \
> > +   .address = (_idx),  \
> > +   .scan_index = (_idx),   \
> > +   .scan_type.sign = 'u',  \
> > +   .scan_type.realbits = 12,   \
> > +   .scan_type.storagebits = 16,\
> >  }
> > 
> >  static const struct iio_chan_spec vf610_adc_iio_channels[] = { @@ -531,6
> > +545,7 @@ static const struct iio_chan_spec vf610_adc_iio_channels[] = {
> > VF610_ADC_CHAN(14, IIO_VOLTAGE),
> > VF610_ADC_CHAN(15, IIO_VOLTAGE),
> > VF610_ADC_TEMPERATURE_CHAN(26, IIO_TEMP),
> > +   IIO_CHAN_SOFT_TIMESTAMP(32),
> > /* sentinel */
> >  };
> > 
> > @@ -559,13 +574,21 @@ static int vf610_adc_read_data(struct vf610_adc
> > *info)
> > 
> >  static irqreturn_t vf610_adc_isr(int irq, void *dev_id)  {
> > -   struct vf610_adc *info = (struct vf610_adc *)dev_id;
> > +   struct iio_dev *indio_dev = (struct iio_dev *)dev_id;
> > +   struct vf610_adc *info = iio_priv(indio_dev);
> > int coco;
> > 
> > coco = readl(info->regs + VF610_REG_ADC_HS);
> > if (coco & VF610_ADC_HS_COCO0) {
> > info->value = vf610_adc_read_data(info);
> > -   complete(>completion);
> > +   if (iio_buffer_enabled(indio_dev)) {
> > +   info->buffer[0] = info->value;
> > +   writel(0, info->regs + VF610_REG_ADC_HS);
> The register is read only. After ADC_Rn is read, the coco bit is cleared.

Right. This crept in from a different implementation which I was trying with
PDB and perhaps a wrong interpretation of the TRM.

Will fix.

Regards,
Sanchayan.

(snip)
--
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 3/4] touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50

2015-07-21 Thread maitysanchayan

On 15-07-21 10:20:44, Dmitry Torokhov wrote:
> Hi Stefan,
> 
> On Tue, Jul 21, 2015 at 04:43:36PM +0200, Stefan Agner wrote:
> > Hi Dmitry,
> > 
> > As the original author of the driver I have some remarks to your review
> > 
> > On 2015-07-18 01:42, Dmitry Torokhov wrote:
> > >> +/*
> > >> + * If touch pressure is too low, stop measuring and 
> > >> reenable
> > >> + * touch detection
> > >> + */
> > >> +if (val_p < min_pressure || val_p > 2000)
> > >> +break;
> > 
> > This is where the modules touch pressure is used to stop the measurement
> > process and switch back to interrupt mode. See my remarks at the end.
> > 
> > >> +
> > >> +/*
> > >> + * The pressure may not be enough for the first x and 
> > >> the
> > >> + * second y measurement, but, the pressure is ok when 
> > >> the
> > >> + * driver is doing the third and fourth measurement. To
> > >> + * take care of this, we drop the first measurement 
> > >> always.
> > >> + */
> > >> +if (discard_val_on_start) {
> > >> +discard_val_on_start = false;
> > >> +} else {
> > >> +/*
> > >> + * Report touch position and sleep for
> > >> + * next measurement
> > >> + */
> > >> +input_report_abs(vf50_ts->ts_input,
> > >> +ABS_X, VF_ADC_MAX - val_x);
> > >> +input_report_abs(vf50_ts->ts_input,
> > >> +ABS_Y, VF_ADC_MAX - val_y);
> > >> +input_report_abs(vf50_ts->ts_input,
> > >> +ABS_PRESSURE, val_p);
> > >> +input_report_key(vf50_ts->ts_input, BTN_TOUCH, 
> > >> 1);
> > >> +input_sync(vf50_ts->ts_input);
> > >> +}
> > >> +
> > >> +msleep(10);
> > >> +}
> > >> +
> > >> +/* Report no more touch, reenable touch detection */
> > >> +input_report_abs(vf50_ts->ts_input, ABS_PRESSURE, 0);
> > >> +input_report_key(vf50_ts->ts_input, BTN_TOUCH, 0);
> > >> +input_sync(vf50_ts->ts_input);
> > >> +
> > >> +vf50_ts_enable_touch_detection(vf50_ts);
> > >> +
> > >> +/* Wait for the pull-up to be stable on high */
> > >> +msleep(10);
> > >> +
> > >> +/* Reenable IRQ to detect touch */
> > >> +enable_irq(vf50_ts->pen_irq);
> > >> +
> > >> +dev_dbg(dev, "Reenabled touch detection interrupt\n");
> > >> +}
> > >> +
> > >> +static irqreturn_t vf50_ts_touched(int irq, void *dev_id)
> > >> +{
> > >> +struct vf50_touch_device *vf50_ts = (struct vf50_touch_device 
> > >> *)dev_id;
> > >> +struct device *dev = _ts->pdev->dev;
> > >> +
> > >> +dev_dbg(dev, "Touch detected, start worker thread\n");
> > >> +
> > >> +disable_irq_nosync(irq);
> > >> +
> > >> +/* Disable the touch detection plates */
> > >> +gpiod_set_value(vf50_ts->gpio_ym, 0);
> > >> +
> > >> +/* Let the platform mux to default state in order to mux as ADC 
> > >> */
> > >> +pinctrl_pm_select_default_state(dev);
> > >> +
> > >> +queue_work(vf50_ts->ts_workqueue, _ts->ts_work);
> > > 
> > > If you convert this to a threaded interrupt you won't need to
> > > disable/reenable interrupt or queue work. You should also be able to use
> > > gpiod_set_value_cansleep() extending the range of ways the controller
> > > could be connected to systems.
> > > 
> > 
> > I'm not sure if a threaded interrupt is the right thing here. While the
> > pen is on the touchscreen (which can be for several seconds)
> > measurements have to be made in a continuous loop. Is it ok for a
> > threaded interrupt to run that long?
> 
> Yes, why not? Threaded interrupt is simply a kernel thread that is woken
> when hard interrupt handler tells it to wake up. Very similar to
> interrupt + work queue, except that the kernel manages interactions
> properly for you. There are several drivers in kernel that do that, for
> example auo-pixcir-ts.c or tsc2007.c
> 
> > 
> > I'm also not sure if it is really safe to _not_ disable the pen down
> > GPIO interrupt. If we get a interrupt while measuring, we should ignore
> > that interrupt.
> 
> The interrupt management core (you'll have to annotate it as
> IRQF_ONESHOT) will make sure it stays masked properly until the threaded
> handler completes so you do not need to disable it explicitly.

(snip)

I tried the IRQ threaded implementation. From your reply, I can see my first
implementation was wrong in the sense that I did not use the IRQF_ONESHOT flag.
The touch response time was not good in this case, however thats to be expected
in this case

Re: [RFC PATCH v6 3/3] drivers: nvmem: Add Vybrid OCOTP support

2015-07-07 Thread maitysanchayan

Hi Stefan,

On 15-07-07 14:49:06, Stefan Wahren wrote:
> Hi Sanchayan,
> 
> > maitysancha...@gmail.com hat am 7. Juli 2015 um 07:19 geschrieben:
> >
> >
> > [...]
> > > > diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
> > > > index 17f1a57..84c830d 100644
> > > > --- a/drivers/nvmem/Kconfig
> > > > +++ b/drivers/nvmem/Kconfig
> > > > @@ -33,4 +33,14 @@ config NVMEM_SUNXI_SID
> > > > This driver can also be built as a module. If so, the module
> > > > will be called eeprom-sunxi-sid.
> > > >
> > > > +config NVMEM_VF610_OCOTP
> > > > + tristate "VF610 SoCs OCOTP support"
> > > > + depends on SOC_VF610
> > > > + help
> > > > + This is a driver for the 'OCOTP' available on various Vybrid
> > > > + devices.
> > >
> > > I don't know much about Vybrid. But this driver is specific for VF610, 
> > > isn't
> > > it?
> >
> > Sorry. I only checked on VF50 and VF61. Will check if is it available with 
> > the
> > other Vybrid devices and change if it is not so.
> 
> no problem. If you spend time in testing your driver with different devices, 
> you
> could mention
> this in your patch description. The naming VF610 suggests that the driver is
> very specific.
> That confuses me a little bit.

Sorry about that. Will add the necessary information in the next respin for 
sure.

> 
> >
> > >
> > > > +
> > > > +
> > > > +static int vf610_ocotp_write(void *context, const void *data, size_t
> > > > count)
> > > > +{
> > > > + return 0;
> > > > +}
> > > > +
> > > > +static int vf610_ocotp_read(void *context,
> > > > + const void *offset, size_t reg_size,
> > > > + void *val, size_t val_size)
> > > > +{
> > > > + void __iomem *ocotp_base = context;
> > > > + u32 *buf = val;
> > > > + u32 reg;
> > > > + int ret;
> > > > + int i;
> > > > +
> > > > + for (i = 0; i < ARRAY_SIZE(valid_fuse_addr); i++) {
> > > > + vf610_ocotp_set_timing(ocotp_base, ocotp_timing);
> > > > + ret = vf610_ocotp_wait_busy(ocotp_base + OCOTP_CTRL_REG);
> > > > + if (ret)
> > > > + return ret;
> > >
> > > Is it really necessary to set the timing in the loop, instead before?
> >
> > I will test it once. From my understanding of 35.3.1.5 I thought the timing
> > needs to explicitly programmed on every read. Perhaps I took it too 
> > literally.
> 
> It was only a question. If barebox does the same, it should be okay.
>

Yes, the code logic is completely similar to barebox except for changes like
how timeout is handled here in the wait busy function.

> >
> > >
> > > > +
> > > > + reg = readl(ocotp_base + OCOTP_CTRL_REG);
> > > > + reg &= ~OCOTP_CTRL_ADDR_MASK;
> > > > + reg &= ~OCOTP_CTRL_WR_UNLOCK_MASK;
> > > > + reg |= BF(valid_fuse_addr[i], OCOTP_CTRL_ADDR);
> > > > + writel(reg, ocotp_base + OCOTP_CTRL_REG);
> > > > +
> > > > + writel(OCOTP_READ_CTRL_READ_FUSE,
> > > > + ocotp_base + OCOTP_READ_CTRL_REG);
> > > > + ret = vf610_ocotp_wait_busy(ocotp_base + OCOTP_CTRL_REG);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + if (readl(ocotp_base) & OCOTP_CTRL_ERROR) {
> > > > + pr_err("Error reading from fuse address %d\n",
> > > > + valid_fuse_addr[i]);
> > >
> > > You could use dev_err() when storing vf610_ocotp_dev in the context.
> >
> > Ok.
> >
> > >
> > > > + writel(OCOTP_CTRL_ERROR, ocotp_base + OCOTP_CTRL_CLR);
> > >
> > > Shouldn't the function abort here?
> >
> > I am not sure about what usage I should follow here. I went for an
> > explicit error message and since 0xBADABADA is expected to be returned
> > on a read locked shadow register, the user would get the above for this
> > particular fuse address and the rest can still be valid since the TRM
> > mentions "subsequent reads to unlocked shadow locations will still work
> > successfully." So I did not abort on the error. Should I?
> 
> In case you don't want to abort, a comment about the 0xBADABADA behavior would
> be helpful.

Ok. Will add the same.

> 
> >
> > >
> > > > +
> > > > +
> > > > +static int vf610_ocotp_probe(struct platform_device *pdev)
> > > > +{
> > > > + struct vf610_ocotp_dev *ocotp_dev;
> > > > +
> > > > + ocotp_dev = devm_kzalloc(>dev,
> > > > + sizeof(struct vf610_ocotp_dev), GFP_KERNEL);
> > > > + if (!ocotp_dev)
> > > > + return -ENOMEM;
> > > > +
> > > > + ocotp_dev->dev = >dev;
> > > > +
> > > > + ocotp_dev->res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > > > + ocotp_dev->base = devm_ioremap_resource(ocotp_dev->dev, 
> > > > ocotp_dev->res);
> > > > + if (IS_ERR(ocotp_dev->base))
> > > > + return PTR_ERR(ocotp_dev->base);
> > > > +
> > > > + ocotp_dev->clk = devm_clk_get(ocotp_dev->dev, "ocotp");
> > > > + if (IS_ERR(ocotp_dev->clk)) {
> > > > + dev_err(ocotp_dev->dev, "failed getting clock, err = %ld\n",
> > > > + PTR_ERR(ocotp_dev->clk));
> > > > + return PTR_ERR(ocotp_dev->clk);
> > > > + }
> > > > +
> > > > + ocotp_regmap_config.max_register = resource_size(ocotp_dev->res) - 1;
> > >
> > > Looking at valid_fuse_addr shows me 0x3F as last valid register. So the 
> > > rest
> > > of the buffer ( 0xD00 - sizeof(valid_fuse_addr) ) in case

Re: [PATCH v2 3/4] touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50

On 15-07-18 14:03:25, Nicolae Rosia wrote:
> Hi,
> 
> On Thu, Jul 16, 2015 at 6:13 PM, Sanchayan Maity
>  wrote:
> > The Colibri Vybrid VF50 module supports 4-wire touchscreens using
> > FETs and ADC inputs. This driver uses the IIO consumer interface
> > and relies on the vf610_adc driver based on the IIO framework.
> >
> > Signed-off-by: Sanch
> > +static const struct of_device_id vf50_touch_of_match[] = {
> > +   { .compatible = "toradex,vf50-touchctrl", },
> > +   { }
> > +};
> > +MODULE_DEVICE_TABLE(of, vf50_touch_of_match);
> > +
> > +static struct platform_driver __refdata vf50_touch_driver = {
> > +   .driver = {
> > +   .name = "toradex,vf50_touchctrl",
> > +   .of_match_table = vf50_touch_of_match,
> > +   },
> > +   .probe = vf50_ts_probe,
> > +   .remove = vf50_ts_remove,
> > +   .prevent_deferred_probe = false,
> > +};
> Why Toradex ? Isn't this a Freescale IP ?

The 4 wire touchscreen support is provided by using on module circuitry
mainly comprising of FET's and leveraging the GPIOs and on chip ADC of
the Vybrid SoC.

This is specific to our Colibri Vybrid VF50 module and not the Freescale
IP. While I guess one could certainly use the driver for their own needs
if one were to replicate a similar circuitry and change the DT properties
concerning GPIO and ADC's as per their own board, as of now this is only
use on our Toradex VF50 modules and was done by us specifically to provide
touchscreen support for VF50.

Regards,
Sanchayan.
--
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 3/4] touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50

Hello Dmitry,

On 15-07-17 16:42:42, Dmitry Torokhov wrote:
> Hi Sanchayan,
> 
> 
> On Thu, Jul 16, 2015 at 08:43:21PM +0530, Sanchayan Maity wrote:
> > The Colibri Vybrid VF50 module supports 4-wire touchscreens using
> > FETs and ADC inputs. This driver uses the IIO consumer interface
> > and relies on the vf610_adc driver based on the IIO framework.
> 
> This looks pretty good, thank you. Just a few comments below.
> 
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  drivers/input/touchscreen/Kconfig   |  12 +
> >  drivers/input/touchscreen/Makefile  |   1 +
> >  drivers/input/touchscreen/colibri-vf50-ts.c | 451 
> > 
> >  3 files changed, 464 insertions(+)
> >  create mode 100644 drivers/input/touchscreen/colibri-vf50-ts.c
> > 
> > diff --git a/drivers/input/touchscreen/Kconfig 
> > b/drivers/input/touchscreen/Kconfig
> > index 80f6386..28948ca 100644
> > --- a/drivers/input/touchscreen/Kconfig
> > +++ b/drivers/input/touchscreen/Kconfig
> > @@ -1027,4 +1027,16 @@ config TOUCHSCREEN_ZFORCE
> >   To compile this driver as a module, choose M here: the
> >   module will be called zforce_ts.
> >  
> > +config TOUCHSCREEN_COLIBRI_VF50
> > +   tristate "Toradex Colibri on board touchscreen driver"
> > +   depends on GPIOLIB && IIO && VF610_ADC
> > +   help
> > + Say Y here if you have a Colibri VF50 and plan to use
> > + the on-board provided 4-wire touchscreen driver.
> > +
> > + If unsure, say N.
> > +
> > + To compile this driver as a module, choose M here: the
> > + module will be called colibri_vf50_ts.
> > +
> >  endif
> > diff --git a/drivers/input/touchscreen/Makefile 
> > b/drivers/input/touchscreen/Makefile
> > index 44deea7..93746a0 100644
> > --- a/drivers/input/touchscreen/Makefile
> > +++ b/drivers/input/touchscreen/Makefile
> > @@ -84,3 +84,4 @@ obj-$(CONFIG_TOUCHSCREEN_W90X900) += w90p910_ts.o
> >  obj-$(CONFIG_TOUCHSCREEN_SX8654)   += sx8654.o
> >  obj-$(CONFIG_TOUCHSCREEN_TPS6507X) += tps6507x-ts.o
> >  obj-$(CONFIG_TOUCHSCREEN_ZFORCE)   += zforce_ts.o
> > +obj-$(CONFIG_TOUCHSCREEN_COLIBRI_VF50) += colibri-vf50-ts.o
> > diff --git a/drivers/input/touchscreen/colibri-vf50-ts.c 
> > b/drivers/input/touchscreen/colibri-vf50-ts.c
> > new file mode 100644
> > index 000..eb16bdc
> > --- /dev/null
> > +++ b/drivers/input/touchscreen/colibri-vf50-ts.c
> > @@ -0,0 +1,451 @@
> > +/* Copyright 2015 Toradex AG
> > + *
> > + * Toradex Colibri VF50 Touchscreen driver
> > + *
> > + * Originally authored by Stefan Agner for 3.0 kernel
> > + *
> > + * 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 
> 
> Why?

Remnant of old usage. Will fix.

> 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> 
> Is not used as far as I can see.

Right. Crept in from old usage of extracting gpio information from DT. Should
have removed when I switched to using gpiod_* and removal of legacy gpio API.
Will fix.

> 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define DRIVER_NAME "colibri-vf50-ts"
> > +#define DRV_VERSION "1.0"
> > +
> > +#define VF_ADC_MAX ((1 << 12) - 1)
> > +
> > +#define COLI_TOUCH_MIN_DELAY_US 1000
> > +#define COLI_TOUCH_MAX_DELAY_US 2000
> > +
> > +static int min_pressure = 200;
> > +
> > +struct vf50_touch_device {
> > +   struct platform_device  *pdev;
> > +   struct input_dev*ts_input;
> > +   struct workqueue_struct *ts_workqueue;
> > +   struct work_struct  ts_work;
> > +   struct iio_channel  *channels;
> > +   struct gpio_desc *gpio_xp;
> > +   struct gpio_desc *gpio_xm;
> > +   struct gpio_desc *gpio_yp;
> > +   struct gpio_desc *gpio_ym;
> > +   struct gpio_desc *gpio_pen_detect;
> > +   struct gpio_desc *gpio_pen_detect_pullup;
> > +   int pen_irq;
> > +   bool stop_touchscreen;
> > +};
> > +
> > +/*
> > + * Enables given plates and measures touch parameters using ADC
> > + */
> > +static int adc_ts_measure(struct iio_channel *channel,
> > + struct gpio_desc *plate_p, struct gpio_desc *plate_m)
> > +{
> > +   int i, value = 0, val = 0;
> > +   int ret;
> > +
> > +   gpiod_set_value(plate_p, 1);
> > +   gpiod_set_value(plate_m, 1);
> > +
> > +   usleep_range(COLI_TOUCH_MIN_DELAY_US, COLI_TOUCH_MAX_DELAY_US);
> > +
> > +   for (i = 0; i < 5; i++) {
> > +   ret = iio_read_channel_raw(channel, );
> > +   if (ret < 0)
> > +   return -EINVAL;
> > +
> > +   value += val;
> > +   }
> > +
> > +   value /= 5;
> > +
> > +   gpiod_set_value(plate_p, 0);
> > +   gpiod_set_value(plate_m, 0);
> > +
> > +   return value;
> > +}
> > +
> > +/*
> > + * Enable touch detection using falling edge

Re: [PATCH v2 3/4] touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50

2015-08-03 Thread maitysanchayan

Hello Dmitry,

On 15-07-21 10:20:44, Dmitry Torokhov wrote:
> Hi Stefan,
> 
> On Tue, Jul 21, 2015 at 04:43:36PM +0200, Stefan Agner wrote:
> > Hi Dmitry,
> > 
> > As the original author of the driver I have some remarks to your review
> > 
> > On 2015-07-18 01:42, Dmitry Torokhov wrote:
> > >> +/*
> > >> + * If touch pressure is too low, stop measuring and 
> > >> reenable
> > >> + * touch detection
> > >> + */
> > >> +if (val_p < min_pressure || val_p > 2000)
> > >> +break;
> > 
> > This is where the modules touch pressure is used to stop the measurement
> > process and switch back to interrupt mode. See my remarks at the end.
> > 
> > >> +
> > >> +/*
> > >> + * The pressure may not be enough for the first x and 
> > >> the
> > >> + * second y measurement, but, the pressure is ok when 
> > >> the
> > >> + * driver is doing the third and fourth measurement. To
> > >> + * take care of this, we drop the first measurement 
> > >> always.
> > >> + */
> > >> +if (discard_val_on_start) {
> > >> +discard_val_on_start = false;
> > >> +} else {
> > >> +/*
> > >> + * Report touch position and sleep for
> > >> + * next measurement
> > >> + */
> > >> +input_report_abs(vf50_ts->ts_input,
> > >> +ABS_X, VF_ADC_MAX - val_x);
> > >> +input_report_abs(vf50_ts->ts_input,
> > >> +ABS_Y, VF_ADC_MAX - val_y);
> > >> +input_report_abs(vf50_ts->ts_input,
> > >> +ABS_PRESSURE, val_p);
> > >> +input_report_key(vf50_ts->ts_input, BTN_TOUCH, 
> > >> 1);
> > >> +input_sync(vf50_ts->ts_input);
> > >> +}
> > >> +
> > >> +msleep(10);
> > >> +}
> > >> +
> > >> +/* Report no more touch, reenable touch detection */
> > >> +input_report_abs(vf50_ts->ts_input, ABS_PRESSURE, 0);
> > >> +input_report_key(vf50_ts->ts_input, BTN_TOUCH, 0);
> > >> +input_sync(vf50_ts->ts_input);
> > >> +
> > >> +vf50_ts_enable_touch_detection(vf50_ts);
> > >> +
> > >> +/* Wait for the pull-up to be stable on high */
> > >> +msleep(10);
> > >> +
> > >> +/* Reenable IRQ to detect touch */
> > >> +enable_irq(vf50_ts->pen_irq);
> > >> +
> > >> +dev_dbg(dev, "Reenabled touch detection interrupt\n");
> > >> +}
> > >> +
> > >> +static irqreturn_t vf50_ts_touched(int irq, void *dev_id)
> > >> +{
> > >> +struct vf50_touch_device *vf50_ts = (struct vf50_touch_device 
> > >> *)dev_id;
> > >> +struct device *dev = _ts->pdev->dev;
> > >> +
> > >> +dev_dbg(dev, "Touch detected, start worker thread\n");
> > >> +
> > >> +disable_irq_nosync(irq);
> > >> +
> > >> +/* Disable the touch detection plates */
> > >> +gpiod_set_value(vf50_ts->gpio_ym, 0);
> > >> +
> > >> +/* Let the platform mux to default state in order to mux as ADC 
> > >> */
> > >> +pinctrl_pm_select_default_state(dev);
> > >> +
> > >> +queue_work(vf50_ts->ts_workqueue, _ts->ts_work);
> > > 
> > > If you convert this to a threaded interrupt you won't need to
> > > disable/reenable interrupt or queue work. You should also be able to use
> > > gpiod_set_value_cansleep() extending the range of ways the controller
> > > could be connected to systems.
> > > 
> > 
> > I'm not sure if a threaded interrupt is the right thing here. While the
> > pen is on the touchscreen (which can be for several seconds)
> > measurements have to be made in a continuous loop. Is it ok for a
> > threaded interrupt to run that long?
> 
> Yes, why not? Threaded interrupt is simply a kernel thread that is woken
> when hard interrupt handler tells it to wake up. Very similar to
> interrupt + work queue, except that the kernel manages interactions
> properly for you. There are several drivers in kernel that do that, for
> example auo-pixcir-ts.c or tsc2007.c
> 
> > 
> > I'm also not sure if it is really safe to _not_ disable the pen down
> > GPIO interrupt. If we get a interrupt while measuring, we should ignore
> > that interrupt.
> 
> The interrupt management core (you'll have to annotate it as
> IRQF_ONESHOT) will make sure it stays masked properly until the threaded
> handler completes so you do not need to disable it explicitly.

After working some more on threaded irq implementation, if IRQ_ONESHOT
flag is used while requesting threaded irq, on entering the IRQ handler
the vf610_gpio_irq_mask is not called and vf610_gpio_irq_unmask is not
called on exiting the thread

Re: [PATCH v4 2/2] soc: Add driver for Freescale Vybrid Platform

2015-05-27 Thread maitysanchayan

Hello,

On 15-05-27 09:31:50, Paul Bolle wrote:
> On Tue, 2015-05-26 at 17:06 +0530, Sanchayan Maity wrote:
> > --- /dev/null
> > +++ b/drivers/soc/fsl/Kconfig
> 
> > +config SOC_VF610
> > +  bool "SoC bus device for the Freescale Vybrid platform"
> > +  select SOC_BUS
> > +  help
> > +Include support for the SoC bus on the Freescale Vybrid platform
> > +providing some sysfs information about the module variant.
> > \ No newline at end of file
> 
> (That review comment is courtesy of git.)

Will fix it.

> 
> > --- /dev/null
> > +++ b/drivers/soc/fsl/Makefile
> 
> > +obj-$(CONFIG_SOC_VF610)+= soc-vf610.o
> 
> > --- /dev/null
> > +++ b/drivers/soc/fsl/soc-vf610.c
> 
> > +MODULE_DEVICE_TABLE(of, vf610_soc_bus_match);
> 
> > +module_platform_driver(vf610_soc_driver);
> 
> (The series starting at https://lkml.org/lkml/2015/5/10/131 would allow
> to use builtin_platform_driver() for built-in only code.)

Thanks for bringing this to my attention. I am subscribed to the mailing
list however this skipped me.

> 
> > +MODULE_DESCRIPTION("Freescale VF610 SoC bus driver");
> > +MODULE_LICENSE("GPL v2");
> 
> I think soc-vf610.o can only be built-in. But its code contains a few
> module specific macros. Was it perhaps intended for SOC_VF610 to be
> tristate?

I too think that should be built-in. Did not have an intention of making
it tristate, however while using other drivers as references, the perhaps
unneccessary stuff crept in.

The MODULE_* references can be removed along with the corresponding header
file. However that series has not been merged yet, so I can't use builtin_*
yet?

@Arnd

Are you ok with the patch in general? I can take care of the above changes
and send a new version. And once the builtin_driver stuff gets merged, I
can send a minor patch to change this module one to builtin?

Regards,
Sanchayan.
--
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: [RFC 0/2] Implement SoC bus support for Vybrid

2015-05-13 Thread maitysanchayan

Hello,

Ping? Any inputs?
 
On 15-05-11 10:41:37, Sanchayan Maity wrote:
> Hello,
> 
> Currently this patchset is based of on our local branch but would like 
> some comments before I push this to mainline through Shawn's tree.
> 
> This patchset implements the following
> https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-devices-soc
> 
> Currently the required information is more or less read across the whole 
> SoC, but I guess we cannot change that since these are the locations 
> with the required information.
> 
> There seem to be three options for the revision field:
> - ROM revision (see https://community.freescale.com/docs/DOC-94802)
> - ANADIG revision (ANADIG_DIGIPROC, as used for the i.MX SoC's)
> - OCOTP revision
> 
> Some numbers:
> 
> Colibri VF61 1.1A (2N02G)
> - 0x0013
> - 0x0061
> - 0x0100
> - 0x41c8
> 
> Colibri VF61 V1.0B (1N02G)
> - 0x0011
> - 0x0061
> - 0x0100
> - 0x41c8
> 
> Colibri VF61 V1.0A (which is actually a VF600 SoC, no L2 cache, since
> that was the only one we could buy back then, 1N02G printed on it)
> - 0x0011
> - 0x0061
> - 0x0100
> - none...
> 
> Colibri VF50 V1.0A (1N02G)
> - 0x0011
> - 0x0061
> - 0x0100
> - none...
> 
> Vybrid Tower Rev J (1N02G)
> - 0x0011
> - 0x0061
> - 0x0100
> - 0x41c8
> 
> Read from u-boot
> md.l 0x80 1
> md.l 0x40050260 1
> md.l 0x400A5090 1
> 
> 
> The ROM revision seems to differ most. So we would like to go with the 
> revision from the ROM register 0x80.
> 
> Now coming to the primary question. This ROM revision register is not 
> really within any of the peripheral maps and I would like to access it 
> for the versioning information. Currently, I used ioremap like below
> 
> ioremap(ROM_REVISION_REGISTER, SZ_1);
> 
> which I guess probably is not the right way to do it. What would be the 
> correct or better way to do this? 
> 
> Also comments or feedback or any of the other parts of the patch are 
> also welcome.
> 
> Some Sample outputs are below:
> On Colibri VF61 V1.1A:
> root@colibri-vf:/sys/devices/soc0# ls
> backlight  fxosc  regulators sound  uevent
> bl_on  gpio-keys  revision   subsystem
> clk16m machinesocsxosc
> family power  soc_id syscon-reboot
> root@colibri-vf:/sys/devices/soc0# cat revision
> 0013
> root@colibri-vf:/sys/devices/soc0# cat soc_id
> dbc8435c211629d4
> root@colibri-vf:/sys/devices/soc0# cat family
> Freescale Vybrid VF610
> 
> On Colibri VF50 V1.1A:
> root@colibri-vf:/sys/devices/soc0# ls
> backlight   machine subsystem
> bl_on   power   sxosc
> clk16m  regulators  syscon-reboot
> family  revisiontoradex,vf50_touchctrl
> fxosc   soc uevent
> gpio-keys   soc_id
> root@colibri-vf:/sys/devices/soc0# cat revision
> 0013
> root@colibri-vf:/sys/devices/soc0# cat soc_id
> df63c12a2e2161d4
> root@colibri-vf:/sys/devices/soc0# cat family
> Freescale Vybrid VF500
> root@colibri-vf:/sys/devices/soc0# cat machine
> Freescale Vybrid
> 
> Thanks & Regards,
> Sanchayan Maity.
> 
> Sanchayan Maity (2):
>   ARM: dts: vfxxx: Add OCOTP node
>   ARM: vf610: Add SoC bus support for Vybrid
> 
>  arch/arm/boot/dts/vfxxx.dtsi   |  5 +++
>  arch/arm/mach-imx/mach-vf610.c | 76 
> +-
>  2 files changed, 80 insertions(+), 1 deletion(-)
> 
> -- 
> 2.4.0
> 
--
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 v5 1/2] ARM: dts: vfxxx: Add OCOTP and OCROM nodes

Hello Maxime,

On 15-06-06 13:58:33, Maxime Ripard wrote:
> Hi,
> 
> On Fri, Jun 05, 2015 at 02:52:37PM +0530, Sanchayan Maity wrote:
> > Add a device tree node for the On-Chip One Time Programmable
> > Controller (OCOTP) and the On-Chip ROM.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  arch/arm/boot/dts/vfxxx.dtsi | 12 
> >  1 file changed, 12 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> > index 2f4b04d..ed9b6b8 100644
> > --- a/arch/arm/boot/dts/vfxxx.dtsi
> > +++ b/arch/arm/boot/dts/vfxxx.dtsi
> > @@ -56,6 +56,13 @@
> > compatible = "simple-bus";
> > interrupt-parent = <_ir>;
> > ranges;
> > +   ocotp-cfg = < 0x410 0x420>;
> > +   rom-revision = < 0x80>;
> > +
> > +   ocrom: ocrom {
> > +   compatible = "fsl,vf610-ocrom", "syscon";
> > +   reg = <0x 0x18000>;
> > +   };
> 
> Shouldn't that use the new nvmem framework currently being discussed,
> instead of defining custom bindings?

I am aware of those nvmem framework patches by Srinivas, however from what
I can see that framework has not been merged yet atleast from the mail
chain that I see for v5 of the patchset so I have not properly looked into
that. Mark Brown did apply the regmap patches to his tree, but has the rest
of the framework been merged or is it expected to be merged?

If it is expected to be merged and if that framework is a fit for what we
are trying to do here and it seems so on a quick glance, then I can go with
that. However I still did like to hear from Arnd or have some more comments
before I go for that approach with the next respin.

- Sanchayan
--
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 v5 2/2] soc: Add driver for Freescale Vybrid Platform

Hello Paul,

On 15-06-06 12:26:07, Paul Bolle wrote:
> On Fri, 2015-06-05 at 14:52 +0530, Sanchayan Maity wrote:
> > --- /dev/null
> > +++ b/drivers/soc/fsl/Kconfig
> 
> > +config SOC_BUS_VF610
> > +  tristate "SoC bus device for the Freescale Vybrid platform"
> > +  depends on SOC_VF610
> > +  select SOC_BUS
> > +  help
> > +Include support for the SoC bus on the Freescale Vybrid platform
> > +providing some sysfs information about the module variant.
> 
> > --- /dev/null
> > +++ b/drivers/soc/fsl/Makefile
> 
> > +obj-$(CONFIG_SOC_BUS_VF610)+= soc-vf610.o
> 
> > --- /dev/null
> > +++ b/drivers/soc/fsl/soc-vf610.c
> > @@ -0,0 +1,166 @@
> > +/*
> > + * Copyright 2015 Toradex AG
> > + *
> > + * Author: Sanchayan Maity 
> > + *
> > + * 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 
> > +
> > +#define DRIVER_NAME "vf610-soc-bus"
> > +
> > +#define MSCM_CPxCOUNT_OFFSET   0x002C
> > +#define MSCM_CPxCFG1_OFFSET0x0014
> > +
> > +struct vf610_soc {
> > +   struct device *dev;
> > +   struct soc_device_attribute *soc_dev_attr;
> > +   struct soc_device *soc_dev;
> > +};
> > +
> > +static int vf610_soc_probe(struct platform_device *pdev)
> > +{
> > +   struct vf610_soc *info;
> > +   struct regmap *ocotp_regmap, *mscm_regmap, *rom_regmap;
> > +   struct device *dev = >dev;
> > +   struct device_node *node = pdev->dev.of_node;
> > +   struct device_node *soc_node;
> > +   struct of_phandle_args pargs;
> > +   char soc_type[] = "xx0";
> > +   u32 cfg0_offset, cfg1_offset, rom_rev_offset;
> > +   u32 soc_id1, soc_id2, rom_rev;
> > +   u32 cpxcount, cpxcfg1;
> > +   u64 soc_id;
> > +   int ret;
> > +
> > +   info = devm_kzalloc(>dev, sizeof(struct vf610_soc), GFP_KERNEL);
> > +   if (!info)
> > +   return -ENOMEM;
> > +
> > +   info->dev = >dev;
> > +   platform_set_drvdata(pdev, info);
> > +
> > +   mscm_regmap = syscon_node_to_regmap(node);
> > +   if (IS_ERR(mscm_regmap)) {
> > +   dev_err(dev, "regmap lookup for mscm failed\n");
> > +   return PTR_ERR(mscm_regmap);
> > +   }
> > +
> > +   soc_node = of_find_node_by_path("/soc");
> > +
> > +   ret = of_parse_phandle_with_fixed_args(soc_node,
> > +   "ocotp-cfg", 2, 0, );
> > +   if (ret) {
> > +   dev_err(dev, "lookup failed for ocotp-cfg node %d\n", ret);
> > +   return ret;
> > +   }
> > +
> > +   ocotp_regmap = syscon_node_to_regmap(pargs.np);
> > +   if (IS_ERR(ocotp_regmap)) {
> > +   of_node_put(pargs.np);
> > +   dev_err(dev, "regmap lookup for ocotp failed\n");
> > +   return PTR_ERR(ocotp_regmap);
> > +   }
> > +
> > +   cfg0_offset = pargs.args[0];
> > +   cfg1_offset = pargs.args[1];
> > +   of_node_put(pargs.np);
> > +
> > +   ret = of_parse_phandle_with_fixed_args(soc_node,
> > +   "rom-revision", 1, 0, );
> > +   if (ret) {
> > +   dev_err(dev, "lookup failed for rom-revision node %d\n", ret);
> > +   return ret;
> > +   }
> > +
> > +   rom_regmap = syscon_node_to_regmap(pargs.np);
> > +   if (IS_ERR(rom_regmap)) {
> > +   of_node_put(pargs.np);
> > +   dev_err(dev, "regmap lookup for ocrom failed\n");
> > +   return PTR_ERR(rom_regmap);
> > +   }
> > +
> > +   rom_rev_offset = pargs.args[0];
> > +   of_node_put(pargs.np);
> > +
> > +   ret = regmap_read(ocotp_regmap, cfg0_offset, _id1);
> > +   if (ret)
> > +   return -ENODEV;
> > +
> > +   ret = regmap_read(ocotp_regmap, cfg1_offset, _id2);
> > +   if (ret)
> > +   return -ENODEV;
> > +
> > +   soc_id = (u64) soc_id1 << 32 | soc_id2;
> > +   add_device_randomness(_id, sizeof(soc_id));
> > +
> > +   ret = regmap_read(mscm_regmap, MSCM_CPxCOUNT_OFFSET, );
> > +   if (ret)
> > +   return -ENODEV;
> > +
> > +   ret = regmap_read(mscm_regmap, MSCM_CPxCFG1_OFFSET, );
> > +   if (ret)
> > +   return -ENODEV;
> > +
> > +   soc_type[0] = cpxcount ? '6' : '5'; /* Dual Core => VF6x0 */
> > +   soc_type[1] = cpxcfg1 ? '1' : '0'; /* L2 Cache => VFx10 */
> > +
> > +   ret = regmap_read(rom_regmap, rom_rev_offset, _rev);
> > +   if (ret)
> > +   return -ENODEV;
> > +
> > +   info->soc_dev_attr = devm_kzalloc(>dev,
> > +   sizeof(info->soc_dev_attr), GFP_KERNEL);
> > +   if (!info->soc_dev_attr)
> > +   return -ENOMEM;
> > +
> > +   info->soc_dev_attr->machine = devm_kasprintf(>dev,
> > +   GFP_KERNEL, "Freescale Vybrid");
> > +   info->soc_dev_attr->soc_id = devm_kasprintf(>dev,
> > +   GFP_KERNEL, "%016llx", soc_id);
> > +   info->soc_dev_attr->family = devm_kasprintf(>dev,
> > +

Re: [PATCH v1 2/2] ARM: vf610: Add SoC bus support for Vybrid

2015-05-19 Thread maitysanchayan

Hello Shawn,

On 15-05-19 14:24:13, Shawn Guo wrote:
> On Mon, May 18, 2015 at 11:50:07AM +0530, Sanchayan Maity wrote:
> > Implements SoC bus support to export SoC specific information. Read
> > the unique SoC ID from the Vybrid On Chip One Time Programmable
> > (OCOTP) controller, SoC specific information from the Miscellaneous
> > System Control Module (MSCM), revision from the ROM revision register
> > and expose it via the SoC bus infrastructure.
> > 
> > Sample Output:
> > 
> > root@vf:/sys/devices/soc0# cat soc_id
> > df63c12a2e2161d4
> > root@vf:/sys/devices/soc0# cat family
> > Freescale Vybrid VF500
> > root@vf:/sys/devices/soc0# cat revision
> > 0013
> > root@vf:/sys/devices/soc0# cat machine
> > Freescale Vybrid
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  arch/arm/mach-imx/mach-vf610.c | 81 
> > ++
> >  1 file changed, 81 insertions(+)
> > 
> > diff --git a/arch/arm/mach-imx/mach-vf610.c b/arch/arm/mach-imx/mach-vf610.c
> > index 2e7c75b..64c78e4 100644
> > --- a/arch/arm/mach-imx/mach-vf610.c
> > +++ b/arch/arm/mach-imx/mach-vf610.c
> > @@ -11,6 +11,86 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> 
> Please group  headers together and sort alphabetically.

Ok. Will fix this and send out a v2. The rest is acceptable?

> 
> Shawn

Thanks & Regards,
Sanchayan Maity.
--
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 v9 0/4] Implement OCOTP driver for Vybrid using NVMEM

2015-09-03 Thread maitysanchayan

Hello,

Ping? Anything preventing this from being accepted? I can rework it then if
so.

Thanks.

- Sanchayan.

On 15-08-12 18:49:17, Sanchayan Maity wrote:
> Hello,
> 
> This patchset is based on top of v9 of Srinivas's NVMEM framework patches.
> Tested on Greg's tree char-misc-next branch along with Stefan's NAND driver
> patchset.
> 
> Sample output on Colibri VF50
> 
> root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# uname -a
> Linux colibri-vf 4.2.0-rc6-00130-g24fcfdc #3 SMP Wed Aug 12 18:31:24 IST 2015 
> armv7l GNU/Linux
> 
> root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# hexdump nvmem
> 000        
> *
> 410 72a6 df64      
> 420 11d4 2c14      
> 430        
> *
> 450 0280       
> 460        
> *
> 880 8f01       
> 890        
> *
> 8c0  1000      
> 8d0 3202 0800      
> 8e0  e100      
> 8f0        
> *
> c80 bada bada      
> *
> cc0        
> *
> cf0
> 
> The driver has changed quite a bit from the first version
> relying on of_platform_populate in mach file, to using
> SoC driver under drivers/soc and finally to NVMEM.
> 
> Feedback and comments most welcome.
> 
> Version 8 patches can be found here
> https://lkml.org/lkml/2015/8/10/566
> 
> Version 7 patches can be found here
> https://lkml.org/lkml/2015/8/6/440
> 
> Version 6 RFC patches can be found here
> http://lkml.iu.edu/hypermail/linux/kernel/1506.2/05123.html
> 
> Version 5 of the patchset can be found here
> http://lkml.iu.edu/hypermail/linux/kernel/1506.0/03787.html
> 
> Version 4 of the patchset can be found here
> https://lkml.org/lkml/2015/5/26/199
> 
> Version 3 of the patchset can be found here
> http://www.spinics.net/lists/arm-kernel/msg420847.html
> 
> Version 2 of the patchset can be found here
> http://www.spinics.net/lists/devicetree/msg80654.html
> 
> Version 1 of the patchset can be found here
> http://www.spinics.net/lists/devicetree/msg80257.html
> 
> The RFC version can be found here
> https://lkml.org/lkml/2015/5/11/13
> 
> Changes since v8:
> 1. Fix three lines over 80 characters
> 2. Rebase on top of Greg's char-misc-next branch
> 
> Changes since v7:
> 1. Add COMPILE_TEST to Kconfig
> 2. Use GENMASK and BIT macros where applicable
> 3. Fix a code alignment issue
> 4. Get the max_register value for regmap config using
> resource_size()
> 5. Also add copyright info as the driver logic is based off
> on ocotp code in barebox
> 6. Add missing info related to clock in DT binding doc
> 
> Changes since v6:
> 1. Use the v9 of NVMEM framework patchset
> 2. Add a few comments
> 3. Initialise buffer address not part of the fuse map to 0
> instead of only handling buffer locations with valid fuse
> addresses.
> 
> Changes since v5:
> Use NVMEM framework by Srinivas and Maxime
> 
> Changes since v4:
> 1. Use devm_* family of functions and use a struct to get rid of
> global variables (suggested by Joachim Eastwood)
> 2. Make Kconfig govern the compilation with tristate, instead of
> earlier bool. Paul Bolle raised a valid point that perhaps this
> should have been built in with the bool, however I had not taken
> into consideration generic distro kernels and it makes sense to
> have this tristated. (comments from Paul Bolle and Andreas Farber)
> 
> Changes since v3:
> Instead of using the syscon_regmap_lookup_by_compatible function
> use a phandle in the device tree along with offsets specified in
> this phandle node and then read the offset along with the device
> node in the driver for reading from the required region.
> 
> Changes since v2:
> Implement the SoC bus code as a driver in drivers/soc
> by registering with fsl,mscm-cpucfg as per Arnd's feedback
> 
> Changes since v1:
> Sort the headers in alphabetical order
> 
> Changes since RFC:
> Use a DT entry for the ROM area while specifying it as syscon.
> 
> Thanks & Regards,
> Sanchayan Maity.
> 
> Sanchayan Maity (4):
>   clk: clk-vf610: Add clock for Vybrid OCOTP controller
>   ARM: dts: vfxxx: Add OCOTP node
>   drivers: nvmem: Add Vybrid OCOTP support
>   nvmem: Add DT binding documentation for Vybrid OCOTP driver
> 
>  .../devicetree/bindings/nvmem/vf610-ocotp.txt  |  21 ++
>  arch/arm/boot/dts/vfxxx.dtsi   |   9 +
>  drivers/clk/imx/clk-vf610.c|   1 +
>  drivers/nvmem/Kconfig  |  10 +
>  drivers/nvmem/Makefile |   2 +
>  drivers/nvmem/vf610-ocotp.c| 302 
> +
>  include/dt-bindings/clock/vf610-clock.h|   3 +-
>  7 files changed, 347 insertions(+), 1

Re: [PATCH v9 0/4] Implement OCOTP driver for Vybrid using NVMEM

2015-09-04 Thread maitysanchayan

Hi,

On 15-09-04 09:21:04, Srinivas Kandagatla wrote:
> Hi Sanchayan,
> 
> On 04/09/15 06:50, maitysancha...@gmail.com wrote:
> > Hello,
> >
> > Ping? Anything preventing this from being accepted? I can rework it then if
> > so.
> Thanks for your patience,
> 
> We are in the middle of merge window, I will pick the driver for 4.4 
> after 4.3-rc1 is released for linux-next testing.

Thank you very much for the update Srinivas.

- Sanchayan.

> 
> --srini
> 
> >
> > Thanks.
> >
> > - Sanchayan.
> >
> > On 15-08-12 18:49:17, Sanchayan Maity wrote:
> >> Hello,
> >>
> >> This patchset is based on top of v9 of Srinivas's NVMEM framework patches.
> >> Tested on Greg's tree char-misc-next branch along with Stefan's NAND driver
> >> patchset.
> >>
> >> Sample output on Colibri VF50
> >>
> >> root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# uname -a
> >> Linux colibri-vf 4.2.0-rc6-00130-g24fcfdc #3 SMP Wed Aug 12 18:31:24 IST 
> >> 2015 armv7l GNU/Linux
> >>
> >> root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# hexdump nvmem
> >> 000        
> >> *
> >> 410 72a6 df64      
> >> 420 11d4 2c14      
> >> 430        
> >> *
> >> 450 0280       
> >> 460        
> >> *
> >> 880 8f01       
> >> 890        
> >> *
> >> 8c0  1000      
> >> 8d0 3202 0800      
> >> 8e0  e100      
> >> 8f0        
> >> *
> >> c80 bada bada      
> >> *
> >> cc0        
> >> *
> >> cf0
> >>
> >> The driver has changed quite a bit from the first version
> >> relying on of_platform_populate in mach file, to using
> >> SoC driver under drivers/soc and finally to NVMEM.
> >>
> >> Feedback and comments most welcome.
> >>
> >> Version 8 patches can be found here
> >> https://lkml.org/lkml/2015/8/10/566
> >>
> >> Version 7 patches can be found here
> >> https://lkml.org/lkml/2015/8/6/440
> >>
> >> Version 6 RFC patches can be found here
> >> http://lkml.iu.edu/hypermail/linux/kernel/1506.2/05123.html
> >>
> >> Version 5 of the patchset can be found here
> >> http://lkml.iu.edu/hypermail/linux/kernel/1506.0/03787.html
> >>
> >> Version 4 of the patchset can be found here
> >> https://lkml.org/lkml/2015/5/26/199
> >>
> >> Version 3 of the patchset can be found here
> >> http://www.spinics.net/lists/arm-kernel/msg420847.html
> >>
> >> Version 2 of the patchset can be found here
> >> http://www.spinics.net/lists/devicetree/msg80654.html
> >>
> >> Version 1 of the patchset can be found here
> >> http://www.spinics.net/lists/devicetree/msg80257.html
> >>
> >> The RFC version can be found here
> >> https://lkml.org/lkml/2015/5/11/13
> >>
> >> Changes since v8:
> >> 1. Fix three lines over 80 characters
> >> 2. Rebase on top of Greg's char-misc-next branch
> >>
> >> Changes since v7:
> >> 1. Add COMPILE_TEST to Kconfig
> >> 2. Use GENMASK and BIT macros where applicable
> >> 3. Fix a code alignment issue
> >> 4. Get the max_register value for regmap config using
> >> resource_size()
> >> 5. Also add copyright info as the driver logic is based off
> >> on ocotp code in barebox
> >> 6. Add missing info related to clock in DT binding doc
> >>
> >> Changes since v6:
> >> 1. Use the v9 of NVMEM framework patchset
> >> 2. Add a few comments
> >> 3. Initialise buffer address not part of the fuse map to 0
> >> instead of only handling buffer locations with valid fuse
> >> addresses.
> >>
> >> Changes since v5:
> >> Use NVMEM framework by Srinivas and Maxime
> >>
> >> Changes since v4:
> >> 1. Use devm_* family of functions and use a struct to get rid of
> >> global variables (suggested by Joachim Eastwood)
> >> 2. Make Kconfig govern the compilation with tristate, instead of
> >> earlier bool. Paul Bolle raised a valid point that perhaps this
> >> should have been built in with the bool, however I had not taken
> >> into consideration generic distro kernels and it makes sense to
> >> have this tristated. (comments from Paul Bolle and Andreas Farber)
> >>
> >> Changes since v3:
> >> Instead of using the syscon_regmap_lookup_by_compatible function
> >> use a phandle in the device tree along with offsets specified in
> >> this phandle node and then read the offset along with the device
> >> node in the driver for reading from the required region.
> >>
> >> Changes since v2:
> >> Implement the SoC bus code as a driver in drivers/soc
> >> by registering with fsl,mscm-cpucfg as per Arnd's feedback
> >>
> >> Changes since v1:
> >> Sort the headers in alphabetical order
> >>
> >> Changes since RFC:
> >> Use a DT entry for the ROM area while specifying it as syscon.
> >>
> >> Thanks & Regards,
> >> Sanchayan Maity.
> >>
>

Re: [PATCH v9 1/4] clk: clk-vf610: Add clock for Vybrid OCOTP controller

On 15-09-06 16:15:26, Shawn Guo wrote:
> On Wed, Aug 12, 2015 at 06:49:18PM +0530, Sanchayan Maity wrote:
> > Add clock support for Vybrid On-Chip One Time Programmable
> > (OCOTP) controller.
> > 
> > While the OCOTP block does not require explicit clock gating,
> > for programming the OCOTP timing register the clock rate of
> > ipg clock is required for timing calculations related to fuse
> > and shadow register read sequence. We explicitly specify the
> > ipg clock for OCOTP as a result.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  drivers/clk/imx/clk-vf610.c | 1 +
> >  include/dt-bindings/clock/vf610-clock.h | 3 ++-
> >  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> Please copy linux-clk list and clock maintainers on i.MX clock patches
> as well.  If you run ./scripts/get_maintainer.pl on the patch, you will
> get them.

Ok. Will take care of this with the next version. Thanks.

- Sanchayan.

> 
> Shawn
> 
> > 
> > diff --git a/drivers/clk/imx/clk-vf610.c b/drivers/clk/imx/clk-vf610.c
> > index bff45ea..d1b1c95 100644
> > --- a/drivers/clk/imx/clk-vf610.c
> > +++ b/drivers/clk/imx/clk-vf610.c
> > @@ -387,6 +387,7 @@ static void __init vf610_clocks_init(struct device_node 
> > *ccm_node)
> >  
> > clk[VF610_CLK_SNVS] = imx_clk_gate2("snvs-rtc", "ipg_bus", CCM_CCGR6, 
> > CCM_CCGRx_CGn(7));
> > clk[VF610_CLK_DAP] = imx_clk_gate("dap", "platform_bus", CCM_CCSR, 24);
> > +   clk[VF610_CLK_OCOTP] = imx_clk_gate("ocotp", "ipg_bus", CCM_CCGR6, 
> > CCM_CCGRx_CGn(5));
> >  
> > imx_check_clocks(clk, ARRAY_SIZE(clk));
> >  
> > diff --git a/include/dt-bindings/clock/vf610-clock.h 
> > b/include/dt-bindings/clock/vf610-clock.h
> > index d197634..56c16aa 100644
> > --- a/include/dt-bindings/clock/vf610-clock.h
> > +++ b/include/dt-bindings/clock/vf610-clock.h
> > @@ -194,6 +194,7 @@
> >  #define VF610_PLL7_BYPASS  181
> >  #define VF610_CLK_SNVS 182
> >  #define VF610_CLK_DAP  183
> > -#define VF610_CLK_END  184
> > +#define VF610_CLK_OCOTP 184
> > +#define VF610_CLK_END  185
> >  
> >  #endif /* __DT_BINDINGS_CLOCK_VF610_H */
> > -- 
> > 2.5.0
> > 
--
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 v9 4/4] nvmem: Add DT binding documentation for Vybrid OCOTP driver

On 15-09-06 16:13:35, Shawn Guo wrote:
> On Wed, Aug 12, 2015 at 06:49:21PM +0530, Sanchayan Maity wrote:
> > Add the devicetree bindings for the Freescale Vybrid On-Chip
> > OTP driver.
> > 
> > Signed-off-by: Sanchayan Maity 
> > Acked-by: Srinivas Kandagatla 
> > ---
> >  .../devicetree/bindings/nvmem/vf610-ocotp.txt   | 21 
> > +
> >  1 file changed, 21 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt 
> > b/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
> > new file mode 100644
> > index 000..b29f65f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
> > @@ -0,0 +1,21 @@
> > +On-Chip OTP Memory for Freescale Vybrid
> > +
> > +Required Properties:
> > +  compatible:
> > +  - "fsl,vf610-ocotp" for VF5xx/VF6xx
> > +  #address-cells : Should be 1
> > +  #size-cells : Should be 1
> > +  reg : Address and length of OTP controller and fuse map registers
> > +  clocks : ipg clock we associate with the OCOTP peripheral
> > +  clock-names : Must contain "ocotp" as matching entry
> 
> I'm not sure "ocotp" is a good name for describing a clock from OCOTP
> internal point of view.  "ipg" might be better.  But I would suggest you
> drop clock-names property completely, if "ipg" is the only clock you
> need to describe here.  The clock-names is necessary only when there are
> multiple clocks to distinguish.
> 
> With clock-names dropped, the driver works by passing NULL as the second
> parameter to devm_clk_get() call.

Ok. Will drop the clock-names property retest and try sending it by tomorrow.

- Sanchayan.

> 
> Shawn
> 
> > +
> > +Example for Vybrid VF5xx/VF6xx:
> > +
> > +   ocotp: ocotp@400a5000 {
> > +   compatible = "fsl,vf610-ocotp";
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   reg = <0x400a5000 0xCF0>;
> > +   clocks = < VF610_CLK_OCOTP>;
> > +   clock-names = "ocotp";
> > +   };
> > -- 
> > 2.5.0
> > 
--
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] ARM: dts: vfxxx: Add iio_hwmon node for ADC temperature channel

2015-09-07 Thread maitysanchayan

Hi Shawn,

On 15-09-06 12:32:32, Shawn Guo wrote:
> On Thu, Aug 06, 2015 at 09:28:22PM +0530, Sanchayan Maity wrote:
> > Add iio_hwmon node to expose the temperature channel on Vybrid
> > as hardware monitor device using the iio_hwmon driver.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  arch/arm/boot/dts/vfxxx.dtsi | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> > index 39173bb..0993d66 100644
> > --- a/arch/arm/boot/dts/vfxxx.dtsi
> > +++ b/arch/arm/boot/dts/vfxxx.dtsi
> > @@ -597,5 +597,10 @@
> > status = "disabled";
> > };
> > };
> > +
> > +   iio_hwmon {
> 
> Hyphen rather than underscore should be used in node name.

As per iio-bindings.txt I did this. It is the same in imx23.dtsi and imx28.dtsi.

http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/iio/iio-bindings.txt#L85
http://lxr.free-electrons.com/source/arch/arm/boot/dts/imx23.dtsi#L570
http://lxr.free-electrons.com/source/arch/arm/boot/dts/imx28.dtsi#L1246

So should this be changed?

Thanks.

- Sanchayan.

> 
> Shawn
> 
> > +   compatible = "iio-hwmon";
> > +   io-channels = < 16>;
> > +   };
> > };
> >  };
> > -- 
> > 2.5.0
> > 
--
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] iio: adc: vf610: Add IIO buffer support for Vybrid ADC

2015-08-17 Thread maitysanchayan

Hello Jonathan,

On 15-08-15 21:24:01, Jonathan Cameron wrote:
> On 11/08/15 10:05, Sanchayan Maity wrote:
> > This patch adds support for IIO buffer to the Vybrid ADC driver.
> > IIO triggered buffer infrastructure along with iio sysfs trigger
> > is used to leverage continuous sampling support provided by the
> > ADC block.
> > 
> > Signed-off-by: Sanchayan Maity 
> Hi Sanchayan,
> 
> Very nearly there. One little point to do with the buffer handling.
> Basically I don't think you want anything in the preenable or
> postdisable hooks, just in the 'internal' ones.
> 
> Jonathan
> > ---
> >  drivers/iio/adc/Kconfig |   2 +
> >  drivers/iio/adc/vf610_adc.c | 102 
> > +---
> >  2 files changed, 97 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> > index 7c55658..660f790 100644
> > --- a/drivers/iio/adc/Kconfig
> > +++ b/drivers/iio/adc/Kconfig
> > @@ -337,6 +337,8 @@ config TWL6030_GPADC
> >  config VF610_ADC
> > tristate "Freescale vf610 ADC driver"
> > depends on OF
> > +   select IIO_BUFFER
> > +   select IIO_TRIGGERED_BUFFER
> > help
> >   Say yes here to support for Vybrid board analog-to-digital converter.
> >   Since the IP is used for i.MX6SLX, the driver also support i.MX6SLX.
> > diff --git a/drivers/iio/adc/vf610_adc.c b/drivers/iio/adc/vf610_adc.c
> > index 23b8fb9..de62c48 100644
> > --- a/drivers/iio/adc/vf610_adc.c
> > +++ b/drivers/iio/adc/vf610_adc.c
> > @@ -34,8 +34,11 @@
> >  #include 
> >  
> >  #include 
> > +#include 
> >  #include 
> > -#include 
> > +#include 
> > +#include 
> > +#include 
> >  
> >  /* This will be the driver name the kernel reports */
> >  #define DRIVER_NAME "vf610-adc"
> > @@ -170,6 +173,7 @@ struct vf610_adc {
> > u32 sample_freq_avail[5];
> >  
> > struct completion completion;
> > +   u16 buffer[8];
> >  };
> >  
> >  static const u32 vf610_hw_avgs[] = { 1, 4, 8, 16, 32 };
> > @@ -505,12 +509,24 @@ static const struct iio_chan_spec_ext_info 
> > vf610_ext_info[] = {
> > .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) |  \
> > BIT(IIO_CHAN_INFO_SAMP_FREQ),   \
> > .ext_info = vf610_ext_info, \
> > +   .scan_index = (_idx),   \
> > +   .scan_type = {  \
> > +   .sign = 'u',\
> > +   .realbits = 12, \
> > +   .storagebits = 16,  \
> > +   },  \
> >  }
> >  
> >  #define VF610_ADC_TEMPERATURE_CHAN(_idx, _chan_type) { \
> > .type = (_chan_type),   \
> > .channel = (_idx),  \
> > .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED), \
> > +   .scan_index = (_idx),   \
> > +   .scan_type = {  \
> > +   .sign = 'u',\
> > +   .realbits = 12, \
> > +   .storagebits = 16,  \
> > +   },  \
> >  }
> >  
> >  static const struct iio_chan_spec vf610_adc_iio_channels[] = {
> > @@ -531,6 +547,7 @@ static const struct iio_chan_spec 
> > vf610_adc_iio_channels[] = {
> > VF610_ADC_CHAN(14, IIO_VOLTAGE),
> > VF610_ADC_CHAN(15, IIO_VOLTAGE),
> > VF610_ADC_TEMPERATURE_CHAN(26, IIO_TEMP),
> > +   IIO_CHAN_SOFT_TIMESTAMP(32),
> > /* sentinel */
> >  };
> >  
> > @@ -559,13 +576,20 @@ static int vf610_adc_read_data(struct vf610_adc *info)
> >  
> >  static irqreturn_t vf610_adc_isr(int irq, void *dev_id)
> >  {
> > -   struct vf610_adc *info = (struct vf610_adc *)dev_id;
> > +   struct iio_dev *indio_dev = (struct iio_dev *)dev_id;
> > +   struct vf610_adc *info = iio_priv(indio_dev);
> > int coco;
> >  
> > coco = readl(info->regs + VF610_REG_ADC_HS);
> > if (coco & VF610_ADC_HS_COCO0) {
> > info->value = vf610_adc_read_data(info);
> > -   complete(>completion);
> > +   if (iio_buffer_enabled(indio_dev)) {
> > +   info->buffer[0] = info->value;
> > +   iio_push_to_buffers_with_timestamp(indio_dev,
> > +   info->buffer, iio_get_time_ns());
> > +   iio_trigger_notify_done(indio_dev->trig);
> > +   } else
> > +   complete(>completion);
> > }
> >  
> > return IRQ_HANDLED;
> > @@ -613,8 +637,12 @@ static int vf610_read_raw(struct iio_dev *indio_dev,
> > case IIO_CHAN_INFO_RAW:
> > case IIO_CHAN_INFO_PROCESSED:
> > mutex_lock(_dev->mlock);
> > -   reinit_completion(>completion);
> > +   if (iio_buffer_enabled(indio_dev)) {
> > +   mutex_unlock(_dev->mlock);
> > +   return -EBUSY;
> > +   }
> >  
> > +

Re: [PATCH v2] iio: adc: vf610: Add IIO buffer support for Vybrid ADC

2015-08-08 Thread maitysanchayan

Hello Jonathan,

On 15-08-08 15:29:47, Jonathan Cameron wrote:
> On 05/08/15 13:10, Sanchayan Maity wrote:
> > This patch adds support for IIO buffer to the Vybrid ADC driver.
> > IIO triggered buffer infrastructure along with iio sysfs trigger
> > is used to leverage continuous sampling support provided by the
> > ADC block.
> Looking good.  Just a couple more bits and pieces inline from me.
> One or two of which aren't corrected from Peter's review of v1.
> 
> I will want Fugang Dong's ack / review tag on the final version
> before applying it however.

Sure.

> This driver is some distance form my area of expertise!

I doubt :).

> 
> Jonathan
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  drivers/iio/adc/Kconfig |   4 ++
> >  drivers/iio/adc/vf610_adc.c | 107 
> > +---
> >  2 files changed, 105 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> > index 7c55658..4661241 100644
> > --- a/drivers/iio/adc/Kconfig
> > +++ b/drivers/iio/adc/Kconfig
> > @@ -337,6 +337,10 @@ config TWL6030_GPADC
> >  config VF610_ADC
> > tristate "Freescale vf610 ADC driver"
> > depends on OF
> > +   select IIO_BUFFER
> > +   select IIO_TRIGGER
> > +   select IIO_SYSFS_TRIGGER
> Unless I missed something there is no dependency on this particular
> trigger (it just happens to be the one you've been testing with I guess).
> Could be driven from a hardware trigger belonging to another device for
> example.

Yes right in a way. Right now we do not provide or there is no provision
for hardware triggers. On the Vybrid, the Peripheral Delay Block (PDB)
does the job of providing support for software and hardware triggers. PDB
support is not yet there in Linux however. 

There is also the question of where the Vybrid PDB driver would belong
to? In the TRM it is put in the timers but the kernel has no generic timer
framework that I am aware of. After some internal reviews we decided to
do a platform driver which provided functions ADC driver could called into.

I have a patchset ready which provides trigger support using PDB however
configuring the PDB properly has proven to be tricky. While it works but
not reliably with multiple channels and it would be a while before I get
that working and post that patchset. So kind of stalled there and just
because of two registers which need to be written with the correct value
:). For what it's worth if someone comes across this, some discussion
here [1] along with patches. (Note however those are a bit old patches
not exactly my new work).

Sorry for digressing from the topic. Anyways so the idea was to provide
sysfs triggers as default for using this continuous sampling. Later the
driver may provide additional triggers. So for now I added the sysfs
trigger as a select option so that a user won't have to recompile the
kernel for using the buffers with continuous sampling.

> 
> > +   select IIO_TRIGGERED_BUFFER
> > help
> >   Say yes here to support for Vybrid board analog-to-digital converter.
> >   Since the IP is used for i.MX6SLX, the driver also support i.MX6SLX.
> > diff --git a/drivers/iio/adc/vf610_adc.c b/drivers/iio/adc/vf610_adc.c
> > index 23b8fb9..97cb2ed 100644
> > --- a/drivers/iio/adc/vf610_adc.c
> > +++ b/drivers/iio/adc/vf610_adc.c
> > @@ -34,8 +34,11 @@
> >  #include 
> >  
> >  #include 
> > +#include 
> >  #include 
> > -#include 
> > +#include 
> > +#include 
> > +#include 
> >  
> >  /* This will be the driver name the kernel reports */
> >  #define DRIVER_NAME "vf610-adc"
> > @@ -170,6 +173,7 @@ struct vf610_adc {
> > u32 sample_freq_avail[5];
> >  
> > struct completion completion;
> > +   u16 buffer[2];
> Note the requirements on the buffer provided to
> iio_push_to_buffers_with_timestamp
> Needs to be u16 buffer[8] to allow for the aligned 64bit (4 word) timestamp.
> 
> Peter pointed this out in his follow up email and you said you'd implement
> it.. Guessing this got lost somewhere.

No, I meant to implement what Peter recommended but I guess I did not completely
grasp what he intended. Sorry about that. Will fix this and ask further if in
more doubts.

> 
> 
> >  };
> >  
> >  static const u32 vf610_hw_avgs[] = { 1, 4, 8, 16, 32 };
> > @@ -505,12 +509,22 @@ static const struct iio_chan_spec_ext_info 
> > vf610_ext_info[] = {
> > .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) |  \
> > BIT(IIO_CHAN_INFO_SAMP_FREQ),   \
> > .ext_info = vf610_ext_info, \
> > +   .address = (_idx),  \
> > +   .scan_index = (_idx),   \
> > +   .scan_type.sign = 'u',  \
> > +   .scan_type.realbits = 12,   \
> > +   .scan_type.storagebits = 16,\
> >  }
> >  
> >  #define VF610_ADC_TEMPERATURE_CHAN(_idx, _chan_type) { \
> > .type = (_chan_type),   \
> > .channel = (_idx),  \
> >

Re: [PATCH v2] iio: adc: vf610: Add IIO buffer support for Vybrid ADC