Re: [PATCH V5] ARM: mach-shmobile: Don't init CNTVOFF/counter if PSCI is available
Hello, all Gentle reminder... -- Regards, Oleksandr Tyshchenko
Re: [RFC PATCH] ARM: mach-shmobile: Parse DT to get ARCH timer memory region
On 13.05.19 12:19, Julien Grall wrote:
Hi,
Hi, Julien, Geert
On 5/10/19 5:22 PM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Don't use hardcoded address, retrieve it from device-tree instead.
And besides, this patch fixes the memory error when running
on top of Xen hypervisor:
(XEN) traps.c:1999:d0v0 HSR=0x93830007 pc=0xc0b097f8 gva=0xf0805000
gpa=0x00e608
Which shows that VCPU0 in Dom0 is trying to access an address in memory
it is not allowed to access (0x00e608).
Put simply, Xen doesn't know that it is a device's register memory
since it wasn't described in a host device tree (which Xen parses)
and as the result this memory region wasn't assigned to Dom0 at
domain creation time.
Signed-off-by: Oleksandr Tyshchenko
---
This patch is meant to get feedback from the community before
proceeding further. If we decide to go this direction, all Gen2
device-trees should be updated (add memory region) before
this patch going in.
e.g. r8a7790.dtsi:
...
timer {
compatible = "arm,armv7-timer";
interrupts-extended = <&gic GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) |
IRQ_TYPE_LEVEL_LOW)>,
<&gic GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) |
IRQ_TYPE_LEVEL_LOW)>,
<&gic GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8) |
IRQ_TYPE_LEVEL_LOW)>,
<&gic GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8) |
IRQ_TYPE_LEVEL_LOW)>;
+ reg = <0 0xe608 0 0x1000>;
This looks incorrect, the "arm,armv7-timer" bindings doesn't offer you
the possibility to specify an MMIO region. This makes sense because it
is meant to describe the Arch timer that is only access via
co-processor registers.
Looking at the code, I think the MMIO region corresponds to the
coresight (based on the register name). So you may want to describe
the coresight in the Device-Tree.
Also, AFAICT, the code is configuring and turning on the timer if it
has not been done yet. If you are here running on Xen, then you have
probably done something wrong. Indeed, it means Xen would not be able
to use the timer until Dom0 has booted. But, shouldn't newer U-boot do
it for you?
Let me elaborate a bit more on this...
Indeed, my PSCI patch series for U-Boot includes a patch [1] for
configuring that "counter module". So, if PSCI is available
(psci_smp_available() == true), then most likely we are running on
PSCI-enabled
U-Boot which, we assume, has already taken care of configuring timer (as
well as resetting CNTVOFF). So, when running on Xen, the timer was
configured beforehand in U-Boot, and Xen is able to use it from the very
beginning, these is no need to wait for Dom0 to configure it.
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 1 KHz
So, the code in brackets won't be called when using PSCI/running Xen,
since the timer is already both enabled and configured:
if ((ioread32(base + CNTCR) & 1) == 0 ||
ioread32(base + CNTFID0) != freq) {
/* Update registers with correct frequency */
iowrite32(freq, base + CNTFID0);
asm volatile("mcr p15, 0, %0, c14, c0, 0" : : "r" (freq));
/* make sure arch timer is started by setting bit 0 of CNTCR */
iowrite32(1, base + CNTCR);
}
But, the problem here is the first read access from timer register (when
we check whether the timer requires enabling) results in hypervisor trap:
(XEN) traps.c:1999:d0v0 HSR=0x93830007 pc=0xc0b097f8 gva=0xf0805000
gpa=0x00e608
So, if the DT bindings for the counter module is not an option (if I
correctly understood a discussion pointed by Geert in another letter),
we should probably prevent all timer code here from being executed if
PSCI is in use.
What I mean is to return to [2], but with the modification to use
psci_smp_available() helper as an indicator of PSCI usage.
Julien, Geert, what do you think?
[1] https://marc.info/?l=u-boot&m=154895714510154&w=2
[2] https://lkml.org/lkml/2019/4/17/810
Cheers,
--
Regards,
Oleksandr Tyshchenko
Re: [RFC PATCH] ARM: mach-shmobile: Parse DT to get ARCH timer memory region
On 13.05.19 18:13, Geert Uytterhoeven wrote: Hi Oleksandr, Hi Geert So, if the DT bindings for the counter module is not an option (if I correctly understood a discussion pointed by Geert in another letter), we should probably prevent all timer code here from being executed if PSCI is in use. What I mean is to return to [2], but with the modification to use psci_smp_available() helper as an indicator of PSCI usage. Julien, Geert, what do you think? Yes, that sounds good to me. Note that psci_smp_available() seems to return false if CONFIG_SMP=n, so checking for that is not sufficient to avoid crashes when running a uniprocessor kernel on a PSCI-enabled system. Indeed, you are right. Nothing than just check for psci_ops.cpu_on == NULL directly comes to mind... Have already checked with CONFIG_SMP=n, it works. Sounds ok? -- Regards, Oleksandr Tyshchenko
Re: [RFC PATCH] ARM: mach-shmobile: Parse DT to get ARCH timer memory region
On 14.05.19 10:16, Geert Uytterhoeven wrote:
Hi Oleksandr,
Hi Geert
On Mon, May 13, 2019 at 6:00 PM Oleksandr wrote:
On 13.05.19 18:13, Geert Uytterhoeven wrote:
So, if the DT bindings for the counter module is not an option (if I
correctly understood a discussion pointed by Geert in another letter),
we should probably prevent all timer code here from being executed if
PSCI is in use.
What I mean is to return to [2], but with the modification to use
psci_smp_available() helper as an indicator of PSCI usage.
Julien, Geert, what do you think?
Yes, that sounds good to me.
Note that psci_smp_available() seems to return false if CONFIG_SMP=n,
so checking for that is not sufficient to avoid crashes when running a
uniprocessor kernel on a PSCI-enabled system.
Indeed, you are right.
Nothing than just check for psci_ops.cpu_on == NULL directly comes to
mind...
Have already checked with CONFIG_SMP=n, it works.
Sounds ok?
Fine for me, thanks!
Great, I will send new version.
Gr{oetje,eeting}s,
Geert
--
Regards,
Oleksandr Tyshchenko
Re: [PATCH V4] ARM: mach-shmobile: Don't init CNTVOFF/counter if PSCI is available
On 14.05.19 19:13, Julien Grall wrote: Hi, Hi Julien On 14/05/2019 17:06, Oleksandr Tyshchenko wrote: diff --git a/arch/arm/mach-shmobile/setup-rcar-gen2.c b/arch/arm/mach-shmobile/setup-rcar-gen2.c index eea60b2..64e3abd 100644 --- a/arch/arm/mach-shmobile/setup-rcar-gen2.c +++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c @@ -17,6 +17,7 @@ #include #include #include +#include #include #include #include "common.h" @@ -63,6 +64,15 @@ void __init rcar_gen2_timer_init(void) void __iomem *base; u32 freq; + /* + * If PSCI is available then most likely we are running on PSCI-enabled + * U-Boot which, we assume, has already taken care of resetting CNTVOFF + * and updating counter module before switching to non-secure mode + * and we don't need to. + */ + if (psci_ops.cpu_on) > + goto skip_update; Are you sure this is working when ARM_PSCI_FW is not selected? Is it possible to have a .config for RCAR without ARM_PSCI_FW? Oh, my fault. Mainline shmobile_defconfig has PSCI stuff disabled. I should have checked for the PSCI operation to be available only if CONFIG_ARM_PSCI_FW is defined. Thank you for pointing this out. Cheers, -- Regards, Oleksandr Tyshchenko
Re: [PATCH V5] ARM: mach-shmobile: Don't init CNTVOFF/counter if PSCI is available
On 28.05.19 11:27, Geert Uytterhoeven wrote:
Hi Oleksandr,
Hi Geert, all
Thanks for the update!
Reviewed-by: Geert Uytterhoeven
Thank you for review!
Just FYI:
Required support for Gen2 Stout board has been already added to Xen [1].
What needs to be done next is to add support for handling device-tree
nodes with "interrupts-extended" property in Xen [2].
This is related to Gen3 as well.
[1]
https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg44386.html
[2]
https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg45951.html
Two cosmetic comments below. I'll leave it to Simon to ignore them for
applying ;-)
@@ -62,6 +63,21 @@ void __init rcar_gen2_timer_init(void)
{
void __iomem *base;
u32 freq;
+ bool need_update = true;
Some people like reverse Xmas tree declaration order...
+
+ /*
+* If PSCI is available then most likely we are running on PSCI-enabled
+* U-Boot which, we assume, has already taken care of resetting CNTVOFF
+* and updating counter module before switching to non-secure mode
+* and we don't need to.
+*/
+#if defined(CONFIG_ARM_PSCI_FW)
#ifdef CONFIG_ARM_PSCI_FW ?
Gr{oetje,eeting}s,
Geert
--
Regards,
Oleksandr Tyshchenko
Re: [PATCH V5] ARM: mach-shmobile: Don't init CNTVOFF/counter if PSCI is available
Oleksandr, could I trouble you to respin with the changes suggested by Geert? Hi, Simon. Sure, will send an updated patch tomorrow. -- Regards, Oleksandr Tyshchenko
Re: [v4,0/3] iommu/ipmmu-vmsa: r8a7796 support V4
Hi, all. Gentle reminder. On 05.09.17 19:52, Oleksandr wrote: Hi, Magnus, maintainers, all. On 19.06.17 14:04, Magnus Damm wrote: iommu/ipmmu-vmsa: r8a7796 support V4 [PATCH v4 1/3] iommu/ipmmu-vmsa: Add r8a7796 DT binding [PATCH v4 2/3] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48 [PATCH v4 3/3] iommu/ipmmu-vmsa: Hook up r8a7796 DT matching code This series adds r8a7796 support to the IPMMU driver. The DT binding gets updated, maximum number of micro-TLBs are increased and the driver is adjusted to match on the new DT binding. I am interested in adding IPMMU-VMSA support to Xen hypervisor. I did some preparations for making IPMMU-VMSA to feel comfortable [1] inside Xen followed by direct porting Linux IPMMU-VMSA driver and ARM LPAE page-table allocator [2] to it. I decided to base on the "BSP" driver [3] because it had more complete support than the "mainline" one [4]. During review I got a feedback that "BSP" driver wasn't the best choice to be ported. Xen ARM maintainers worry about "BSP" driver which haven't had a thorough review by the Linux community and as the result might have bugs which will never be fixed, etc. So, for the IPMMU-VMSA support to be accepted by Xen community I should either write our own driver based on BSP/mainline/whatever which contains only relevant to Xen things or direct port from "mainline" driver. As the second option relies on the required support [5] which isn't in mainline yet, it is not clear when this support gets merged and how it will be modified/reworked before, we preliminarily decided to follow the first option. But, I would like to consider second option again. Despite the complexity of second option, it has one significant benefit. I see that Linux driver is being developed quite actively and looking over all related patch series I got a feeling that required support was about to reach upstream. Could you, please, clarify some questions which, I hope, help us to make a decision: 1. Do you have approximate time-frame for getting this support in? 2. Are fundamental/significant changes planned for this support? Also, may I ask for a link to github branch which contains current (and likely r8a7795 and 32-bit ARM update) patch series? Thank you in advance! And sorry for the most likely incorrect format of this email. [1] https://www.mail-archive.com/xen-devel@lists.xen.org/msg115901.html [2] https://lists.xen.org/archives/html/xen-devel/2017-07/msg02679.html [3] https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/tree/drivers/iommu/ipmmu-vmsa.c?h=v4.9/rcar-3.5.3 [4] http://elixir.free-electrons.com/linux/latest/source/drivers/iommu/ipmmu-vmsa.c [5] https://lists.linuxfoundation.org/pipermail/iommu/2017-June/022567.html https://lists.linuxfoundation.org/pipermail/iommu/2017-June/022577.html https://lkml.org/lkml/2017/7/17/393 Changes since V3: - Rebased on top of [PATCH v4 00/09] iommu/ipmmu-vmsa: r8a7795 support V4 - Patch 3/3 updated with Reviewed-by - thanks Geert! Changes since V2: - Patch 2/3 updated with an outer set of () - thanks Ramesh! - Patch 2/3 updated with Reviewed-by - thanks Geert! - Patch 3/3 updated to include white list support Changes since V1: - Patch 1/3 updated with more Acked-by tags - Patch 2/3 updated with high I/O register range support Patch 1/3 is ready for upstream merge and includes the following tags: Signed-off-by: Magnus Damm Acked-by: Laurent Pinchart Acked-by: Rob Herring Acked-by: Simon Horman Acked-by: Geert Uytterhoeven Patch 2/3 and 3/3 are quite trivial but have no acked-by so far. Signed-off-by: Magnus Damm --- Developed on top of next-20170614 with the following series applied [PATCH 00/04] iommu/ipmmu-vmsa: 32-bit ARM update [PATCH v4 00/09] iommu/ipmmu-vmsa: r8a7795 support V4 Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt |1 drivers/iommu/ipmmu-vmsa.c | 24 +++--- 2 files changed, 18 insertions(+), 7 deletions(-)
Re: [PATCH] block,bfq: Disable writeback throttling
Tested-by: Oleksandr Natalenko Similarly to CFQ, BFQ has its write-throttling heuristics, and it is better not to combine them with further write-throttling heuristics of a different nature. So this commit disables write-back throttling for a device if BFQ is used as I/O scheduler for that device. Signed-off-by: Luca Miccio Signed-off-by: Paolo Valente --- block/bfq-iosched.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Re: I/O hangs after resuming from suspend-to-ram
Hello. Addressing your questions below. Can't reproduce even with putting dmcypt on raid10 after applying my patch. Just a side note, that dm-crypt is not necessary here — I am able to trigger hang with RAID10 and LVM only. BTW, could you share us which blk-mq scheduler you are using on sata? Okay, now it makes sense. Previously, without your patch I was able to reproduce the issue with "mq-deadline", "bfq" and "none". Now, I cannot trigger it with "none" set, but "mq-deadline" still hangs for me. Does this mean each scheduler should be modified separately? Could you apply the following debug patch and provide the dmesg log after running the commands below? Is it still relevant since I confirm issue to be fixed with "none"? Thanks. 30.08.2017 07:17, Ming Lei написав: …SNIP… Can't reproduce even with putting dmcypt on raid10 after applying my patch. …SNIP…
Re: I/O hangs after resuming from suspend-to-ram
Hi. So, current summary: 1) first patch + debug patch: I can reproduce the issue in wild, but not with pm_test set; 2) first patch + debug patch + second patch: I cannot reproduce issue at all, neither with "none", nor with "mq-deadline". Thus, "blk-mq: align to legacy path for implementing blk_execute_rq" + "blk-mq: add requests in the tail of hctx->dispatch" look like a proper fix. Thanks for that! I setup dm-crypt on /dev/md0 directly, could you show me how to setup lvm on raid10? If still relevant, here is a layout: === sda 8:008G 0 disk |-sda1 8:10 128M 0 part /boot/EFI `-sda2 8:20 7.9G 0 part `-md0 9:00 7.9G 0 raid10 `-system-root 253:00 7.9G 0 lvm/ sdb 8:16 08G 0 disk |-sdb1 8:17 0 128M 0 part `-sdb2 8:18 0 7.9G 0 part `-md0 9:00 7.9G 0 raid10 `-system-root 253:00 7.9G 0 lvm/ === Anything else you'd like /me to test? 30.08.2017 10:06, Ming Lei написав: …SNIP… Please try the following patch and previous patch together and see if they make a difference: …SNIP…
Re: [PATCH BUGFIX/IMPROVEMENT 0/3] three bfq fixes restoring service guarantees with random sync writes in bg
Tested-by: Oleksander Natalenko I'm "Oleksandr" :). 31.08.2017 08:10, Paolo Valente wrote: Hi, while testing the read-write unfairness issues reported by Mel, I found BFQ failing to guarantee good responsiveness against heavy random sync writes in the background, i.e., multiple writers doing random writes and systematic fdatasync [1]. The failure was caused by three related bugs, because of which BFQ failed to guarantee to high-weight processes the expected fraction of the throughput. The three patches in this series fix these bugs. These fixes restore the usual BFQ service guarantees (and thus optimal responsiveness too), against the above background workload and, probably, against other similar workloads. Thanks, Paolo [1] https://lkml.org/lkml/2017/8/9/957 Paolo Valente (3): block, bfq: make lookup_next_entity push up vtime on expirations block, bfq: remove direct switch to an entity in higher class block, bfq: guarantee update_next_in_service always returns an eligible entity block/bfq-iosched.c | 4 +-- block/bfq-iosched.h | 4 +-- block/bfq-wf2q.c| 91 - 3 files changed, 60 insertions(+), 39 deletions(-) -- 2.10.0
Re: [v4,0/3] iommu/ipmmu-vmsa: r8a7796 support V4
Hi, Magnus, maintainers, all. On 19.06.17 14:04, Magnus Damm wrote: iommu/ipmmu-vmsa: r8a7796 support V4 [PATCH v4 1/3] iommu/ipmmu-vmsa: Add r8a7796 DT binding [PATCH v4 2/3] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48 [PATCH v4 3/3] iommu/ipmmu-vmsa: Hook up r8a7796 DT matching code This series adds r8a7796 support to the IPMMU driver. The DT binding gets updated, maximum number of micro-TLBs are increased and the driver is adjusted to match on the new DT binding. I am interested in adding IPMMU-VMSA support to Xen hypervisor. I did some preparations for making IPMMU-VMSA to feel comfortable [1] inside Xen followed by direct porting Linux IPMMU-VMSA driver and ARM LPAE page-table allocator [2] to it. I decided to base on the "BSP" driver [3] because it had more complete support than the "mainline" one [4]. During review I got a feedback that "BSP" driver wasn't the best choice to be ported. Xen ARM maintainers worry about "BSP" driver which haven't had a thorough review by the Linux community and as the result might have bugs which will never be fixed, etc. So, for the IPMMU-VMSA support to be accepted by Xen community I should either write our own driver based on BSP/mainline/whatever which contains only relevant to Xen things or direct port from "mainline" driver. As the second option relies on the required support [5] which isn't in mainline yet, it is not clear when this support gets merged and how it will be modified/reworked before, we preliminarily decided to follow the first option. But, I would like to consider second option again. Despite the complexity of second option, it has one significant benefit. I see that Linux driver is being developed quite actively and looking over all related patch series I got a feeling that required support was about to reach upstream. Could you, please, clarify some questions which, I hope, help us to make a decision: 1. Do you have approximate time-frame for getting this support in? 2. Are fundamental/significant changes planned for this support? Also, may I ask for a link to github branch which contains current (and likely r8a7795 and 32-bit ARM update) patch series? Thank you in advance! And sorry for the most likely incorrect format of this email. [1] https://www.mail-archive.com/xen-devel@lists.xen.org/msg115901.html [2] https://lists.xen.org/archives/html/xen-devel/2017-07/msg02679.html [3] https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/tree/drivers/iommu/ipmmu-vmsa.c?h=v4.9/rcar-3.5.3 [4] http://elixir.free-electrons.com/linux/latest/source/drivers/iommu/ipmmu-vmsa.c [5] https://lists.linuxfoundation.org/pipermail/iommu/2017-June/022567.html https://lists.linuxfoundation.org/pipermail/iommu/2017-June/022577.html https://lkml.org/lkml/2017/7/17/393 Changes since V3: - Rebased on top of [PATCH v4 00/09] iommu/ipmmu-vmsa: r8a7795 support V4 - Patch 3/3 updated with Reviewed-by - thanks Geert! Changes since V2: - Patch 2/3 updated with an outer set of () - thanks Ramesh! - Patch 2/3 updated with Reviewed-by - thanks Geert! - Patch 3/3 updated to include white list support Changes since V1: - Patch 1/3 updated with more Acked-by tags - Patch 2/3 updated with high I/O register range support Patch 1/3 is ready for upstream merge and includes the following tags: Signed-off-by: Magnus Damm Acked-by: Laurent Pinchart Acked-by: Rob Herring Acked-by: Simon Horman Acked-by: Geert Uytterhoeven Patch 2/3 and 3/3 are quite trivial but have no acked-by so far. Signed-off-by: Magnus Damm --- Developed on top of next-20170614 with the following series applied [PATCH 00/04] iommu/ipmmu-vmsa: 32-bit ARM update [PATCH v4 00/09] iommu/ipmmu-vmsa: r8a7795 support V4 Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt |1 drivers/iommu/ipmmu-vmsa.c | 24 +++--- 2 files changed, 18 insertions(+), 7 deletions(-)
[PATCH v5 1/2] staging: iio: Documentation sysfs-bus-iio add power_mode
Add description about in_accelX_power_mode and in_accel_power_mode_available. Signed-off-by: Oleksandr Kravchenko --- Documentation/ABI/testing/sysfs-bus-iio | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index dda81ff..1a333f3 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -792,3 +792,13 @@ Contact: linux-...@vger.kernel.org Description: This attribute is used to read the amount of quadrature error present in the device at a given time. + +What: /sys/.../iio:deviceX/in_accelX_power_mode +KernelVersion: 3.11 +Contact: linux-...@vger.kernel.org +Description: + Specifies the chip power mode. + low_noise: reduce noise level from ADC, + low_power: enable low current consumption. + For a list of available output power modes read + in_accel_power_mode_available. -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 2/2] iio: add Bosch BMA180 acceleration sensor driver
This patch adds IIO driver for Bosch BMA180 triaxial
acceleration sensor.
http://dlnmh9ip6v2uc.cloudfront.net/datasheets/
Sensors/Accelerometers/BST-BMA180-DS000-07_2.pdf
Stephen Warren:
The binding looks simple enough to me, so the binding
Acked-by: Stephen Warren
Signed-off-by: Oleksandr Kravchenko
---
.../devicetree/bindings/iio/accel/bma180.txt | 24 +
drivers/iio/accel/Kconfig | 12 +
drivers/iio/accel/Makefile |2 +
drivers/iio/accel/bma180.c | 676
4 files changed, 714 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/accel/bma180.txt
create mode 100644 drivers/iio/accel/bma180.c
diff --git a/Documentation/devicetree/bindings/iio/accel/bma180.txt
b/Documentation/devicetree/bindings/iio/accel/bma180.txt
new file mode 100644
index 000..c593357
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/accel/bma180.txt
@@ -0,0 +1,24 @@
+* Bosch BMA180 triaxial acceleration sensor
+
+http://omapworld.com/BMA180_111_1002839.pdf
+
+Required properties:
+
+ - compatible : should be "bosch,bma180"
+ - reg : the I2C address of the sensor
+
+Optional properties:
+
+ - interrupt-parent : should be the phandle for the interrupt controller
+
+ - interrupts : interrupt mapping for GPIO IRQ, it should by configured with
+ flags IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING
+
+Example:
+
+bma180@40 {
+ compatible = "bosch,bma180";
+ reg = <0x40>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <18 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING)>;
+};
diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
index 719d83f..bd9d581 100644
--- a/drivers/iio/accel/Kconfig
+++ b/drivers/iio/accel/Kconfig
@@ -3,6 +3,18 @@
#
menu "Accelerometers"
+config BMA180
+ tristate "Bosch BMA180 3-Axis Accelerometer Driver"
+ depends on I2C
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ help
+ Say Y here if you want to build a driver for the Bosch BMA180
+ triaxial acceleration sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called bma180.
+
config HID_SENSOR_ACCEL_3D
depends on HID_SENSOR_HUB
select IIO_BUFFER
diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
index 87d8fa2..eb09d72 100644
--- a/drivers/iio/accel/Makefile
+++ b/drivers/iio/accel/Makefile
@@ -2,6 +2,8 @@
# Makefile for industrial I/O accelerometer drivers
#
+obj-$(CONFIG_BMA180) += bma180.o
+
obj-$(CONFIG_HID_SENSOR_ACCEL_3D) += hid-sensor-accel-3d.o
obj-$(CONFIG_IIO_ST_ACCEL_3AXIS) += st_accel.o
diff --git a/drivers/iio/accel/bma180.c b/drivers/iio/accel/bma180.c
new file mode 100644
index 000..12e32e6
--- /dev/null
+++ b/drivers/iio/accel/bma180.c
@@ -0,0 +1,676 @@
+/*
+ * bma180.c - IIO driver for Bosch BMA180 triaxial acceleration sensor
+ *
+ * Copyright 2013 Oleksandr Kravchenko
+ *
+ * This file is subject to the terms and conditions of version 2 of
+ * the GNU General Public License. See the file COPYING in the main
+ * directory of this archive for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define BMA180_DRV_NAME "bma180"
+#define BMA180_IRQ_NAME "bma180_event"
+
+/* Register set */
+#define BMA180_CHIP_ID 0x00 /* Need to distinguish BMA180 from other */
+#define BMA180_ACC_X_LSB 0x02 /* First of 6 registers of accel data */
+#define BMA180_CTRL_REG0 0x0d
+#define BMA180_RESET 0x10
+#define BMA180_BW_TCS 0x20
+#define BMA180_CTRL_REG3 0x21
+#define BMA180_TCO_Z 0x30
+#define BMA180_OFFSET_LSB1 0x35
+
+/* BMA180_CTRL_REG0 bits */
+#define BMA180_DIS_WAKE_UP BIT(0) /* Disable wake up mode */
+#define BMA180_SLEEP BIT(1) /* 1 - chip will sleep */
+#define BMA180_EE_WBIT(4) /* Unlock writing to addr from 0x20 */
+#define BMA180_RESET_INT BIT(6) /* Reset pending interrupts */
+
+/* BMA180_CTRL_REG3 bits */
+#define BMA180_NEW_DATA_INTBIT(1) /* Intr every new accel data is ready */
+
+/* BMA180_OFFSET_LSB1 skipping mode bit */
+#define BMA180_SMP_SKIPBIT(0)
+
+/* Bit masks for registers bit fields */
+#define BMA180_RANGE 0x0e /* Range of measured accel values*/
+#define BMA180_BW 0xf0 /* Accel bandwidth */
+#define BMA180_MODE_CONFIG 0x03 /* Config operation modes */
+
+/* We have to write this value in reset register to do soft reset */
+#define BMA180_RESET_VAL 0xb6
+
+#define BMA_180_ID_REG_VAL 0x03
+
+/* Chip power modes */
+#define BMA180_LOW_NOISE 0x00
+#define BMA180_LOW_POWER 0x03
+
+#define BMA180_LOW_NOISE_STR "l
Re: [PATCH v5 1/2] staging: iio: Documentation sysfs-bus-iio add power_mode
Please ignore this patch, it is wrong -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 2/2] iio: add Bosch BMA180 acceleration sensor driver
This patch adds IIO driver for Bosch BMA180 triaxial
acceleration sensor.
http://dlnmh9ip6v2uc.cloudfront.net/datasheets/
Sensors/Accelerometers/BST-BMA180-DS000-07_2.pdf
Stephen Warren:
The binding looks simple enough to me, so the binding
Acked-by: Stephen Warren
Signed-off-by: Oleksandr Kravchenko
---
.../devicetree/bindings/iio/accel/bma180.txt | 24 +
drivers/iio/accel/Kconfig | 12 +
drivers/iio/accel/Makefile |2 +
drivers/iio/accel/bma180.c | 676
4 files changed, 714 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/accel/bma180.txt
create mode 100644 drivers/iio/accel/bma180.c
diff --git a/Documentation/devicetree/bindings/iio/accel/bma180.txt
b/Documentation/devicetree/bindings/iio/accel/bma180.txt
new file mode 100644
index 000..c593357
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/accel/bma180.txt
@@ -0,0 +1,24 @@
+* Bosch BMA180 triaxial acceleration sensor
+
+http://omapworld.com/BMA180_111_1002839.pdf
+
+Required properties:
+
+ - compatible : should be "bosch,bma180"
+ - reg : the I2C address of the sensor
+
+Optional properties:
+
+ - interrupt-parent : should be the phandle for the interrupt controller
+
+ - interrupts : interrupt mapping for GPIO IRQ, it should by configured with
+ flags IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING
+
+Example:
+
+bma180@40 {
+ compatible = "bosch,bma180";
+ reg = <0x40>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <18 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING)>;
+};
diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
index 719d83f..bd9d581 100644
--- a/drivers/iio/accel/Kconfig
+++ b/drivers/iio/accel/Kconfig
@@ -3,6 +3,18 @@
#
menu "Accelerometers"
+config BMA180
+ tristate "Bosch BMA180 3-Axis Accelerometer Driver"
+ depends on I2C
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ help
+ Say Y here if you want to build a driver for the Bosch BMA180
+ triaxial acceleration sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called bma180.
+
config HID_SENSOR_ACCEL_3D
depends on HID_SENSOR_HUB
select IIO_BUFFER
diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
index 87d8fa2..eb09d72 100644
--- a/drivers/iio/accel/Makefile
+++ b/drivers/iio/accel/Makefile
@@ -2,6 +2,8 @@
# Makefile for industrial I/O accelerometer drivers
#
+obj-$(CONFIG_BMA180) += bma180.o
+
obj-$(CONFIG_HID_SENSOR_ACCEL_3D) += hid-sensor-accel-3d.o
obj-$(CONFIG_IIO_ST_ACCEL_3AXIS) += st_accel.o
diff --git a/drivers/iio/accel/bma180.c b/drivers/iio/accel/bma180.c
new file mode 100644
index 000..12e32e6
--- /dev/null
+++ b/drivers/iio/accel/bma180.c
@@ -0,0 +1,676 @@
+/*
+ * bma180.c - IIO driver for Bosch BMA180 triaxial acceleration sensor
+ *
+ * Copyright 2013 Oleksandr Kravchenko
+ *
+ * This file is subject to the terms and conditions of version 2 of
+ * the GNU General Public License. See the file COPYING in the main
+ * directory of this archive for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define BMA180_DRV_NAME "bma180"
+#define BMA180_IRQ_NAME "bma180_event"
+
+/* Register set */
+#define BMA180_CHIP_ID 0x00 /* Need to distinguish BMA180 from other */
+#define BMA180_ACC_X_LSB 0x02 /* First of 6 registers of accel data */
+#define BMA180_CTRL_REG0 0x0d
+#define BMA180_RESET 0x10
+#define BMA180_BW_TCS 0x20
+#define BMA180_CTRL_REG3 0x21
+#define BMA180_TCO_Z 0x30
+#define BMA180_OFFSET_LSB1 0x35
+
+/* BMA180_CTRL_REG0 bits */
+#define BMA180_DIS_WAKE_UP BIT(0) /* Disable wake up mode */
+#define BMA180_SLEEP BIT(1) /* 1 - chip will sleep */
+#define BMA180_EE_WBIT(4) /* Unlock writing to addr from 0x20 */
+#define BMA180_RESET_INT BIT(6) /* Reset pending interrupts */
+
+/* BMA180_CTRL_REG3 bits */
+#define BMA180_NEW_DATA_INTBIT(1) /* Intr every new accel data is ready */
+
+/* BMA180_OFFSET_LSB1 skipping mode bit */
+#define BMA180_SMP_SKIPBIT(0)
+
+/* Bit masks for registers bit fields */
+#define BMA180_RANGE 0x0e /* Range of measured accel values*/
+#define BMA180_BW 0xf0 /* Accel bandwidth */
+#define BMA180_MODE_CONFIG 0x03 /* Config operation modes */
+
+/* We have to write this value in reset register to do soft reset */
+#define BMA180_RESET_VAL 0xb6
+
+#define BMA_180_ID_REG_VAL 0x03
+
+/* Chip power modes */
+#define BMA180_LOW_NOISE 0x00
+#define BMA180_LOW_POWER 0x03
+
+#define BMA180_LOW_NOISE_STR "l
[PATCH v5 1/2] staging: iio: Documentation sysfs-bus-iio add power_mode
Add description about in_accelX_power_mode and in_accel_power_mode_available. Signed-off-by: Oleksandr Kravchenko --- Documentation/ABI/testing/sysfs-bus-iio | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index dda81ff..1a333f3 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -792,3 +792,13 @@ Contact: linux-...@vger.kernel.org Description: This attribute is used to read the amount of quadrature error present in the device at a given time. + +What: /sys/.../iio:deviceX/in_accelX_power_mode +KernelVersion: 3.11 +Contact: linux-...@vger.kernel.org +Description: + Specifies the chip power mode. + low_noise: reduce noise level from ADC, + low_power: enable low current consumption. + For a list of available output power modes read + in_accel_power_mode_available. -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers: misc: ti-st: fix potential race if st_kim_start fails
If st_kim_start() fails registered protocols should be removed. This is
done by calling st_reg_complete(), which as comment states is called
with spin lock held. But in st_register() when st_kim_start fails it
is called without holding spin lock, creating possibility of concurrent
access to st_gdata data members.
Hold spin lock while calling st_reg_complete if st_kim_start() fails.
Signed-off-by: Oleksandr Kozaruk
---
drivers/misc/ti-st/st_core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/misc/ti-st/st_core.c b/drivers/misc/ti-st/st_core.c
index 0a14280..8d64b68 100644
--- a/drivers/misc/ti-st/st_core.c
+++ b/drivers/misc/ti-st/st_core.c
@@ -562,7 +562,9 @@ long st_register(struct st_proto_s *new_proto)
if ((st_gdata->protos_registered != ST_EMPTY) &&
(test_bit(ST_REG_PENDING, &st_gdata->st_state))) {
pr_err(" KIM failure complete callback ");
+ spin_lock_irqsave(&st_gdata->lock, flags);
st_reg_complete(st_gdata, err);
+ spin_unlock_irqrestore(&st_gdata->lock, flags);
clear_bit(ST_REG_PENDING, &st_gdata->st_state);
}
return -EINVAL;
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] ARM: dts: twl: Add GPADC data to device tree
GPADC is the general purpose ADC present on twl6030.
The dt data is interrupt used to trigger end of ADC
conversion.
Signed-off-by: Oleksandr Kozaruk
---
arch/arm/boot/dts/twl6030.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 2e3bd31..434842c 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -103,4 +103,10 @@
compatible = "ti,twl6030-pwmled";
#pwm-cells = <2>;
};
+
+ gpadc: twl6030_gpadc {
+ compatible = "ti,twl6030_gpadc";
+ interrupts = <3>;
+ #io-channel-cells = <1>;
+ };
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/2] TWL6030, TWL6032 GPADC driver
Hello, This is version 2 - the driver put in drivers/iio, and converted using iio facilities as suggested by Graeme. TWL603[02] GPADC is used to measure battery voltage, battery temperature, battery presence ID, and could be used to measure twl603[02] die temperature. This is used on TI blaze, blaze tablet platforms. The TWL6030/TWL6032 is a PMIC that has a GPADC with 17/19 channels respectively. Some channels have current source and are used for measuring voltage drop on resistive load for detecting battery ID resistance, or measuring voltage drop on NTC resistors for external temperature measurements, other channels measure voltage, (i.e. battery voltage), and have inbuilt voltage dividers, thus, capable to scale voltage. Some channels are dedicated for measuring die temperature. Some channels could be calibrated in 2 points, having offsets from ideal values in trim registers. The difference between GPADC in TWL6030 and TWL6032: - 10 bit vs 12 bit ADC; - 17 vs 19 channels; - channels have different purpose(i. e. battery voltage channel 8 vs channel 18); - trim values are interpreted differently. The driver exports function returning converted value for requested channels. Sysfs entries are added to start and read conversion result in millivolts for chosen channel. The driver is derived from git://git.omapzoom.org/kernel/omap.git The original driver's authors and contributors are Balaji T K, Graeme Gregory, Ambresh K, Girish S Ghongdemath. The changes to the original driver: - device tree adaptation; - drop ioctl support - never been used; - unified measurement method for both devices; - get rid of "if (device == X)" code style to data driven; - drop polling end of conversion and use interrupt instead; - iio framework is used Tested with on blaze tablet 2 with OMAP4430(twl6030), and OMAP4470(twl6032) SOMs. The patches were tested against 3.10-rc7 Oleksandr Kozaruk (2): ARM: dts: twl: Add GPADC data to device tree iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver arch/arm/boot/dts/twl6030.dtsi |6 + drivers/iio/adc/Kconfig |8 + drivers/iio/adc/Makefile|1 + drivers/iio/adc/twl6030-gpadc.c | 1019 +++ 4 files changed, 1034 insertions(+) create mode 100644 drivers/iio/adc/twl6030-gpadc.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC, known also as Phoenix and PhoenixLite. The TWL6030 and TWL6032 have GPADC with 17 and 19 channels respectively. Some channels have current source and are used for measuring voltage drop on resistive load for detecting battery ID resistance, or measuring voltage drop on NTC resistors for external temperature measurements. Some channels measure voltage, (i.e. battery voltage), and have voltage dividers, thus, capable to scale voltage. Some channels are dedicated for measuring die temperature. Some channels are calibrated in 2 points, having offsets from ideal values kept in trim registers. This is used to correct measurements. The differences between GPADC in TWL6030 and TWL6032: - 10 bit vs 12 bit ADC; - 17 vs 19 channels; - channels have different purpose(i. e. battery voltage channel 8 vs channel 18); - trim values are interpreted differently. The driver exports function returning converted value for requested channels. Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K, Girish S Ghongdemath. Signed-off-by: Balaji T K Graeme Gregory Signed-off-by: Oleksandr Kozaruk --- drivers/iio/adc/Kconfig |8 + drivers/iio/adc/Makefile|1 + drivers/iio/adc/twl6030-gpadc.c | 1019 +++ 3 files changed, 1028 insertions(+) create mode 100644 drivers/iio/adc/twl6030-gpadc.c diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index ab0767e6..87d699e 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -157,4 +157,12 @@ config VIPERBOARD_ADC Say yes here to access the ADC part of the Nano River Technologies Viperboard. +config TWL6030_GPADC + tristate "TWL6030 GPADC (General Purpose A/D Convertor) Support" + depends on TWL4030_CORE + default n + help + Say yes here if you want support for the TWL6030 General Purpose + A/D Convertor. + endmenu diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile index 0a825be..8b05633 100644 --- a/drivers/iio/adc/Makefile +++ b/drivers/iio/adc/Makefile @@ -17,3 +17,4 @@ obj-$(CONFIG_MAX1363) += max1363.o obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o +obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c new file mode 100644 index 000..d9529a9 --- /dev/null +++ b/drivers/iio/adc/twl6030-gpadc.c @@ -0,0 +1,1019 @@ +/* + * TWL6030 GPADC module driver + * + * Copyright (C) 2009-2013 Texas Instruments Inc. + * Nishant Kamat + * Balaji T K + * Graeme Gregory + * Girish S Ghongdemath + * Ambresh K + * Oleksandr Kozaruk + * + * 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. + * + * 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. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DRIVER_NAME"twl6030_gpadc" + +#define TWL6030_GPADC_MAX_CHANNELS 17 +#define TWL6032_GPADC_MAX_CHANNELS 19 +/* Define this as the biggest of all chips using this driver */ +#define GPADC_MAX_CHANNELS TWL6032_GPADC_MAX_CHANNELS + +#define TWL6030_GPADC_CTRL 0x00/* 0x2e */ +#define TWL6030_GPADC_CTRL20x01/* 0x2f */ + +#define TWL6030_GPADC_CTRL_P1 0x05 +#define TWL6030_GPADC_CTRL_P2 0x06 + +#define TWL6032_GPADC_GPSELECT_ISB 0x07 +#define TWL6032_GPADC_CTRL_P1 0x08 + +#define TWL6032_GPADC_RTCH0_LSB0x09 +#define TWL6032_GPADC_RTCH0_MSB0x0a +#define TWL6032_GPADC_RTCH1_LSB0x0b +#define TWL6032_GPADC_RTCH1_MSB0x0c +#define TWL6032_GPADC_GPCH0_LSB0x0d +#define TWL6032_GPADC_GPCH0_MSB0x0e + +#define TWL6030_GPADC_CTRL_P1_SP1 BIT(3) +#define TWL6030_GPADC_CTRL_P1_EOCRTBIT(2) +#define TWL6030_GPADC_CTRL_P1_EOCP1BIT(1) +#define TWL6030_GPADC_CTRL_P1_BUSY BIT(0) + +#define TWL6030_GPADC_CTRL_P2_SP2 BIT(2) +#define TWL6030_GPADC_CTRL_P2_EOCP2BIT(1) +#define TWL6030_GPADC_CTRL_P1_BUSY BIT(0) + +#define TWL6030_GPADC_EOC_SW
[PATCH] iio: add APDS9300 ambilent light sensor driver
From: Oleksandr Kravchenko
This patch adds IIO driver for APDS9300 ambilent light sensor (ALS).
http://www.avagotech.com/docs/AV02-1077EN
The driver allows to read raw data from ADC registers or calculate
lux value. It also can handle threshold inrerrupt.
Signed-off-by: Oleksandr Kravchenko
---
.../devicetree/bindings/iio/light/apds9300.txt | 22 +
drivers/iio/light/Kconfig | 10 +
drivers/iio/light/Makefile |1 +
drivers/iio/light/apds9300.c | 528
4 files changed, 561 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/light/apds9300.txt
create mode 100644 drivers/iio/light/apds9300.c
diff --git a/Documentation/devicetree/bindings/iio/light/apds9300.txt
b/Documentation/devicetree/bindings/iio/light/apds9300.txt
new file mode 100644
index 000..d6f66c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/apds9300.txt
@@ -0,0 +1,22 @@
+* Avago APDS9300 ambient light sensor
+
+http://www.avagotech.com/docs/AV02-1077EN
+
+Required properties:
+
+ - compatible : should be "avago,apds9300"
+ - reg : the I2C address of the sensor
+
+Optional properties:
+
+ - interrupt-parent : should be the phandle for the interrupt controller
+ - interrupts : interrupt mapping for GPIO IRQ
+
+Example:
+
+apds9300@39 {
+ compatible = "avago,apds9300";
+ reg = <0x39>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <29 8>;
+};
diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
index 5ef1a39..08a6742 100644
--- a/drivers/iio/light/Kconfig
+++ b/drivers/iio/light/Kconfig
@@ -52,6 +52,16 @@ config VCNL4000
To compile this driver as a module, choose M here: the
module will be called vcnl4000.
+config APDS9300
+ tristate "APDS9300 ambient light sensor"
+ depends on I2C
+ help
+Say Y here if you want to build a driver for the Avago APDS9300
+ambient light sensor.
+
+To compile this driver as a module, choose M here: the
+module will be called apds9300.
+
config HID_SENSOR_ALS
depends on HID_SENSOR_HUB
select IIO_BUFFER
diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
index 040d9c7..da58e12 100644
--- a/drivers/iio/light/Makefile
+++ b/drivers/iio/light/Makefile
@@ -6,4 +6,5 @@ obj-$(CONFIG_ADJD_S311) += adjd_s311.o
obj-$(CONFIG_SENSORS_LM3533) += lm3533-als.o
obj-$(CONFIG_SENSORS_TSL2563) += tsl2563.o
obj-$(CONFIG_VCNL4000) += vcnl4000.o
+obj-$(CONFIG_APDS9300) += apds9300.o
obj-$(CONFIG_HID_SENSOR_ALS) += hid-sensor-als.o
diff --git a/drivers/iio/light/apds9300.c b/drivers/iio/light/apds9300.c
new file mode 100644
index 000..2275ecc
--- /dev/null
+++ b/drivers/iio/light/apds9300.c
@@ -0,0 +1,528 @@
+/*
+ * apds9300.c - IIO driver for Avago APDS9300 ambient light sensor
+ *
+ * Copyright 2013 Oleksandr Kravchenko
+ *
+ * This file is subject to the terms and conditions of version 2 of
+ * the GNU General Public License. See the file COPYING in the main
+ * directory of this archive for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ALS_DRV_NAME "apds9300"
+#define ALS_IRQ_NAME "apds9300_event"
+
+/* Command register bits */
+#define ALS_CMDBIT(7) /* Select command register. Must write
as 1 */
+#define ALS_WORD BIT(5) /* I2C write/read: if 1 word, if 0 byte */
+#define ALS_CLEAR BIT(6) /* Interrupt clear. Clears pending interrupt */
+
+/* Register set */
+#define ALS_CONTROL0x00 /* Control of basic functions */
+#define ALS_THRESHLOWLOW 0x02 /* Low byte of low interrupt threshold */
+#define ALS_THRESHHIGHLOW 0x04 /* Low byte of high interrupt threshold */
+#define ALS_INTERRUPT 0x06 /* Interrupt control */
+#define ALS_DATA0LOW 0x0c /* Low byte of ADC channel 0 */
+#define ALS_DATA1LOW 0x0e /* Low byte of ADC channel 1 */
+
+/* Power on/off value for ALS_CONTROL register */
+#define ALS_POWER_ON 0x03
+#define ALS_POWER_OFF 0x00
+
+/* Interrupts */
+#define ALS_INTR_ENABLE0x10
+/* Interrupt Persist Function: Any value outside of threshold range */
+#define ALS_THRESH_INTR0x01
+
+#define ALS_THRESH_MAX 0x /* Max threshold value */
+
+struct als_data {
+ struct i2c_client *client;
+ struct mutex mutex;
+ int power_state;
+ int thresh_low;
+ int thresh_hi;
+ int intr_en;
+};
+
+/* Lux calculation */
+
+/* Calculated values 1000 * (CH1/CH0)^1.4 for CH1/CH0 from 0 to 0.52 */
+static const u16 lux_ratio[] = {
+ 0, 2, 4, 7, 11, 15, 19, 24, 29, 34, 40, 45, 51, 57, 64, 70, 77, 84, 91,
+ 98, 105, 112, 120, 128, 136, 144, 152, 160, 168, 177, 185, 194,
[PATCH v3 0/2] TWL6030, TWL6032 GPADC driver
Hello, v3 - fixed compiler warning v2 - the driver put in drivers/iio, and converted using iio facilities as suggested by Graeme. TWL603[02] GPADC is used to measure battery voltage, battery temperature, battery presence ID, and could be used to measure twl603[02] die temperature. This is used on TI blaze, blaze tablet platforms. The TWL6030/TWL6032 is a PMIC that has a GPADC with 17/19 channels respectively. Some channels have current source and are used for measuring voltage drop on resistive load for detecting battery ID resistance, or measuring voltage drop on NTC resistors for external temperature measurements, other channels measure voltage, (i.e. battery voltage), and have inbuilt voltage dividers, thus, capable to scale voltage. Some channels are dedicated for measuring die temperature. Some channels could be calibrated in 2 points, having offsets from ideal values in trim registers. The difference between GPADC in TWL6030 and TWL6032: - 10 bit vs 12 bit ADC; - 17 vs 19 channels; - channels have different purpose(i. e. battery voltage channel 8 vs channel 18); - trim values are interpreted differently. The driver exports function returning converted value for requested channels. Sysfs entries are added to start and read conversion result in millivolts for chosen channel. The driver is derived from git://git.omapzoom.org/kernel/omap.git The original driver's authors and contributors are Balaji T K, Graeme Gregory, Ambresh K, Girish S Ghongdemath. The changes to the original driver: - device tree adaptation; - drop ioctl support - never been used; - unified measurement method for both devices; - get rid of "if (device == X)" code style to data driven; - drop polling end of conversion and use interrupt instead; - iio framework is used Tested with on blaze tablet 2 with OMAP4430(twl6030), and OMAP4470(twl6032) SOMs. The patches were tested against 3.10-rc7 Oleksandr Kozaruk (2): ARM: dts: twl: Add GPADC data to device tree iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver arch/arm/boot/dts/twl6030.dtsi |6 + drivers/iio/adc/Kconfig |8 + drivers/iio/adc/Makefile|1 + drivers/iio/adc/twl6030-gpadc.c | 1019 +++ 4 files changed, 1034 insertions(+) create mode 100644 drivers/iio/adc/twl6030-gpadc.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/2] ARM: dts: twl: Add GPADC data to device tree
GPADC is the general purpose ADC present on twl6030.
The dt data is interrupt used to trigger end of ADC
conversion.
Signed-off-by: Oleksandr Kozaruk
---
arch/arm/boot/dts/twl6030.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 2e3bd31..434842c 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -103,4 +103,10 @@
compatible = "ti,twl6030-pwmled";
#pwm-cells = <2>;
};
+
+ gpadc: twl6030_gpadc {
+ compatible = "ti,twl6030_gpadc";
+ interrupts = <3>;
+ #io-channel-cells = <1>;
+ };
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC, known also as Phoenix and PhoenixLite. The TWL6030 and TWL6032 have GPADC with 17 and 19 channels respectively. Some channels have current source and are used for measuring voltage drop on resistive load for detecting battery ID resistance, or measuring voltage drop on NTC resistors for external temperature measurements. Some channels measure voltage, (i.e. battery voltage), and have voltage dividers, thus, capable to scale voltage. Some channels are dedicated for measuring die temperature. Some channels are calibrated in 2 points, having offsets from ideal values kept in trim registers. This is used to correct measurements. The differences between GPADC in TWL6030 and TWL6032: - 10 bit vs 12 bit ADC; - 17 vs 19 channels; - channels have different purpose(i. e. battery voltage channel 8 vs channel 18); - trim values are interpreted differently. The driver exports function returning converted value for requested channels. Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K, Girish S Ghongdemath. Signed-off-by: Balaji T K Graeme Gregory Signed-off-by: Oleksandr Kozaruk --- drivers/iio/adc/Kconfig |8 + drivers/iio/adc/Makefile|1 + drivers/iio/adc/twl6030-gpadc.c | 1019 +++ 3 files changed, 1028 insertions(+) create mode 100644 drivers/iio/adc/twl6030-gpadc.c diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index ab0767e6..87d699e 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -157,4 +157,12 @@ config VIPERBOARD_ADC Say yes here to access the ADC part of the Nano River Technologies Viperboard. +config TWL6030_GPADC + tristate "TWL6030 GPADC (General Purpose A/D Convertor) Support" + depends on TWL4030_CORE + default n + help + Say yes here if you want support for the TWL6030 General Purpose + A/D Convertor. + endmenu diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile index 0a825be..8b05633 100644 --- a/drivers/iio/adc/Makefile +++ b/drivers/iio/adc/Makefile @@ -17,3 +17,4 @@ obj-$(CONFIG_MAX1363) += max1363.o obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o +obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c new file mode 100644 index 000..6ceb789 --- /dev/null +++ b/drivers/iio/adc/twl6030-gpadc.c @@ -0,0 +1,1019 @@ +/* + * TWL6030 GPADC module driver + * + * Copyright (C) 2009-2013 Texas Instruments Inc. + * Nishant Kamat + * Balaji T K + * Graeme Gregory + * Girish S Ghongdemath + * Ambresh K + * Oleksandr Kozaruk + * + * 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. + * + * 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. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DRIVER_NAME"twl6030_gpadc" + +#define TWL6030_GPADC_MAX_CHANNELS 17 +#define TWL6032_GPADC_MAX_CHANNELS 19 +/* Define this as the biggest of all chips using this driver */ +#define GPADC_MAX_CHANNELS TWL6032_GPADC_MAX_CHANNELS + +#define TWL6030_GPADC_CTRL 0x00/* 0x2e */ +#define TWL6030_GPADC_CTRL20x01/* 0x2f */ + +#define TWL6030_GPADC_CTRL_P1 0x05 +#define TWL6030_GPADC_CTRL_P2 0x06 + +#define TWL6032_GPADC_GPSELECT_ISB 0x07 +#define TWL6032_GPADC_CTRL_P1 0x08 + +#define TWL6032_GPADC_RTCH0_LSB0x09 +#define TWL6032_GPADC_RTCH0_MSB0x0a +#define TWL6032_GPADC_RTCH1_LSB0x0b +#define TWL6032_GPADC_RTCH1_MSB0x0c +#define TWL6032_GPADC_GPCH0_LSB0x0d +#define TWL6032_GPADC_GPCH0_MSB0x0e + +#define TWL6030_GPADC_CTRL_P1_SP1 BIT(3) +#define TWL6030_GPADC_CTRL_P1_EOCRTBIT(2) +#define TWL6030_GPADC_CTRL_P1_EOCP1BIT(1) +#define TWL6030_GPADC_CTRL_P1_BUSY BIT(0) + +#define TWL6030_GPADC_CTRL_P2_SP2 BIT(2) +#define TWL6030_GPADC_CTRL_P2_EOCP2BIT(1) +#define TWL6030_GPADC_CTRL_P1_BUSY BIT(0) + +#define TWL6030_GPADC_EOC_SW
RE: [PATCH v1 2/2] mfd: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
Hi Lee, Thank you for the review. There is v3 of this patch. My bad I didn't put it in reply to v1. I'll address you comments in v4. Would you care to review v3, please. Regards, OK. >> The GPADC is general purpose ADC found on TWL6030, >> and TWL6032 PMIC, known also as Phoenix and PhoenixLite. >> >> The TWL6030 and TWL6032 have GPADC with 17 and 19 >> channels respectively. Some channels have current >> source and are used for measuring voltage drop >> on resistive load for detecting battery ID resistance, >> or measuring voltage drop on NTC resistors for external >> temperature measurements. Some channels measure voltage, >> (i.e. battery voltage), and have voltage dividers, >> thus, capable to scale voltage. Some channels are dedicated >> for measuring die temperature. > >Can you use the full available width of the buffer please, either 72 >or 80 chars is normally fine. > >> Some channels are calibrated in 2 points, having >> offsets from ideal values kept in trim registers. This >> is used to correct measurements. >> >> The differences between GPADC in TWL6030 and TWL6032: >> - 10 bit vs 12 bit ADC; >> - 17 vs 19 channels; >> - channels have different purpose(i. e. battery voltage > >Nit: No space here -^ > >> channel 8 vs channel 18); >> - trim values are interpreted differently. >> >> The driver exports function returning converted value for >> requested channels. >> >> Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K, >> Girish S Ghongdemath. >> >> Signed-off-by: Balaji T K >> Graeme Gregory > >SOB? RB? AB? > >> Signed-off-by: Oleksandr Kozaruk >> --- >> .../testing/sysfs-devices-platform-twl6030_gpadc |5 + >> drivers/mfd/Kconfig|8 + >> drivers/mfd/Makefile |1 + >> drivers/mfd/twl6030-gpadc.c| 1053 >> >> include/linux/i2c/twl6030-gpadc.h | 51 + > >Why here instead of include/linux/mfd? > >> 5 files changed, 1118 insertions(+) >> create mode 100644 >> Documentation/ABI/testing/sysfs-devices-platform-twl6030_gpadc >> create mode 100644 drivers/mfd/twl6030-gpadc.c >> create mode 100644 include/linux/i2c/twl6030-gpadc.h >> >> diff --git a/Documentation/ABI/testing/sysfs-devices-platform-twl6030_gpadc >> b/Documentation/ABI/testing/sysfs-devices-platform-twl6030_gpadc >> new file mode 100644 >> index 000..e9c5812 >> --- /dev/null >> +++ b/Documentation/ABI/testing/sysfs-devices-platform-twl6030_gpadc >> @@ -0,0 +1,5 @@ >> +What:/sys/bus/platform/devices/twl603X_gpadc.26/inX_channel > >Are you sure this is where they will be created? > >What's with the .26? > >> +Date:June 2013 >> +Contact: Oleksandr Kozaruk >> +Description: Start GPADC conversion for chosen channel X and report the >> result. >> + The result is returned in millivolts. > >Does this require Greg's Ack? > >> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig >> index d54e985..8eb7494 100644 >> --- a/drivers/mfd/Kconfig >> +++ b/drivers/mfd/Kconfig >> @@ -970,6 +970,14 @@ config MFD_TC3589X >> additional drivers must be enabled in order to use the >> functionality of the device. >> >> +config TWL6030_GPADC > >As this supports the TWL6030 and TWL6032, wouldn't it be better to use >TWL603X. Same goes for the driver/header filenames. > >> + tristate "TWL6030 GPADC (General Purpose A/D Convertor) Support" >> + depends on TWL4030_CORE >> + default n >> + help >> + Say yes here if you want support for the TWL6030 General Purpose >> + A/D Convertor. >> + > >Any chance you can bundle this with the other TWL* variants instead of >dumping it in an arbitrary location within the Kconfig file? > >> config MFD_TMIO >> bool >> default n >> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile >> index 718e94a..59f504f 100644 >> --- a/drivers/mfd/Makefile >> +++ b/drivers/mfd/Makefile >> @@ -70,6 +70,7 @@ obj-$(CONFIG_MENELAUS) += menelaus.o >> obj-$(CONFIG_TWL4030_CORE) += twl-core.o twl4030-irq.o twl6030-irq.o >> obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o >> obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o >> +obj-$(CONFIG_TWL6030_GPADC)+= twl6030-gpadc.o >> obj-$(CONFIG_MFD_TWL
RE: [PATCH v1 2/2] mfd: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
>I'd rather go straight on to review v4 with my comments addressed, if >it's all the same to you? Sure. Thank you. Best regards, OK.-- 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 v1] MFD: Change TWL6025 references to TWL6032
On 06/07/2013 05:44 PM, g...@slimlogic.co.uk wrote: On 2013-06-07 15:36, Mark Brown wrote: On Fri, Jun 07, 2013 at 01:53:10PM +0300, Oleksandr Kozaruk wrote: From: Graeme Gregory The TWL6025 was never released beyond sample form and was replaced by the PhoenixLite range of chips - TWL6032. Change the references to reference the TWL6032 class and name the registers to twl6032 in line with an actual released chip name to avoid confusion. Currently there is no users of TWL6025 in the code. Given that the chip exists even if not widely distributed it seems as well to keep the twl6025 references in there at least in the device ID table - it won't do any harm to people using the twl6032 name and might help someone who happens to pick up an old board for whatever reason. I do not think any "old boards" exist, it really was a limited run! Graeme Hello Mark, Graeme So, what is your opinion? Could we move forward with this? In addition, If twl6032 will be added on top of twl6025 there will be no guarantee that twl6025 will work because: - there is no HW to verify - there is no documentation on twl6025 available, so, in case if current implementation is different from what is needed for twl6032 - it can't be handled properly -- 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 v1] MFD: Change TWL6025 references to TWL6032
On 06/07/2013 05:44 PM, g...@slimlogic.co.uk wrote: On 2013-06-07 15:36, Mark Brown wrote: On Fri, Jun 07, 2013 at 01:53:10PM +0300, Oleksandr Kozaruk wrote: From: Graeme Gregory The TWL6025 was never released beyond sample form and was replaced by the PhoenixLite range of chips - TWL6032. Change the references to reference the TWL6032 class and name the registers to twl6032 in line with an actual released chip name to avoid confusion. Currently there is no users of TWL6025 in the code. Given that the chip exists even if not widely distributed it seems as well to keep the twl6025 references in there at least in the device ID table - it won't do any harm to people using the twl6032 name and might help someone who happens to pick up an old board for whatever reason. I do not think any "old boards" exist, it really was a limited run! Graeme Hello Mark, Graeme, Taking in account that: - there is no hardware to test twl6025, testing is not possible; - there is no documentation for twl6025, and if there are any changes to twl6032 is not known; - twl6032 is available, and in production, twl6025 is not even found on ti.com <http://ti.com> So, what do you think, can this change be accepted? // I apologize for sending personal e-mails, not to the mail list -- 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 v1] MFD: Change TWL6025 references to TWL6032
On 06/07/2013 05:44 PM, g...@slimlogic.co.uk wrote: On 2013-06-07 15:36, Mark Brown wrote: On Fri, Jun 07, 2013 at 01:53:10PM +0300, Oleksandr Kozaruk wrote: From: Graeme Gregory The TWL6025 was never released beyond sample form and was replaced by the PhoenixLite range of chips - TWL6032. Change the references to reference the TWL6032 class and name the registers to twl6032 in line with an actual released chip name to avoid confusion. Currently there is no users of TWL6025 in the code. Given that the chip exists even if not widely distributed it seems as well to keep the twl6025 references in there at least in the device ID table - it won't do any harm to people using the twl6032 name and might help someone who happens to pick up an old board for whatever reason. I do not think any "old boards" exist, it really was a limited run! Graeme Hello Mark, Graeme, Taking in account that: - there is no hardware to test twl6025, testing is not possible; - there is no documentation for twl6025, and if there are any changes to twl6032 is not known; - twl6032 is available, and in production, twl6025 is not even found on ti.com <https://emea.mail.ti.com/owa/redir.aspx?C=Lmz99OgekUScv9U89hUFHXTz_mebO9AIdxDOPBzqDKKuqB_Dr5dpU_Sl2criZoxOeMxW4IqmDOA.&URL=http%3a%2f%2fti.com> So, what do you think, can this change be accepted? // I apologize for sending previous email as personal, not to mail list. -- 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 v1] MFD: Change TWL6025 references to TWL6032
On 06/13/2013 11:17 AM, Oleksandr Kozaruk wrote: On Fri, Jun 7, 2013 at 5:44 PM, <mailto:g...@slimlogic.co.uk>> wrote: > > On 2013-06-07 15:36, Mark Brown wrote: >> >> On Fri, Jun 07, 2013 at 01:53:10PM +0300, Oleksandr Kozaruk wrote: >>> >>> From: Graeme Gregory mailto:g...@slimlogic.co.uk>> >>> >>> The TWL6025 was never released beyond sample form and was replaced by >>> the PhoenixLite range of chips - TWL6032. Change the references to >>> reference the TWL6032 class and name the registers to twl6032 in line with >>> an actual released chip name to avoid confusion. >>> >>> Currently there is no users of TWL6025 in the code. >> >> >> Given that the chip exists even if not widely distributed it seems as >> well to keep the twl6025 references in there at least in the device ID >> table - it won't do any harm to people using the twl6032 name and might >> help someone who happens to pick up an old board for whatever reason. > > > I do not think any "old boards" exist, it really was a limited run! > > Graeme Hello Mark, Graeme, Taking in account that: - there is no hardware to test twl6025, testing is not possible; - there is no documentation for twl6025, and if there are any changes to twl6032 is not known; - twl6032 is available, and in production, twl6025 is not even found on ti.com <http://ti.com> So, what do you think, can this change be accepted? <http://www.globallogic.com/email_disclaimer.txt> Sorry for spamming - had problems with mail server. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] MFD: Change TWL6025 references to TWL6032
From: Graeme Gregory
The TWL6025 was never released beyond sample form and was replaced by
the PhoenixLite range of chips - TWL6032. Change the references to
reference the TWL6032 class and name the registers to twl6032 in line with
an actual released chip name to avoid confusion.
Currently there are no users of TWL6025 in the code.
Signed-off-by: Graeme Gregory
Signed-off-by: Oleksandr Kozaruk
Acked-by: Lee Jones
---
There are non-mainline branches that use twl6032 by its name (for example
git://git.omapzoom.org/kernel/omap.git). There is intention to add support
of twl6032 device in mainline, but we'd like to know if we can use twl6032
instead of twl6025 in our new patches, that we are going to provide.
Related discussion: https://patchwork.kernel.org/patch/2686331/
.../bindings/regulator/twl-regulator.txt | 26 +++
.../devicetree/bindings/usb/twl-usb.txt|2 +-
drivers/mfd/twl-core.c | 46 ++--
drivers/regulator/twl-regulator.c | 76 ++--
drivers/usb/phy/phy-twl6030-usb.c |2 +-
include/linux/i2c/twl.h| 30
6 files changed, 91 insertions(+), 91 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/twl-regulator.txt
b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
index 658749b..75b0c16 100644
--- a/Documentation/devicetree/bindings/regulator/twl-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
@@ -18,20 +18,20 @@ For twl6030 regulators/LDOs
- "ti,twl6030-vdd1" for VDD1 SMPS
- "ti,twl6030-vdd2" for VDD2 SMPS
- "ti,twl6030-vdd3" for VDD3 SMPS
-For twl6025 regulators/LDOs
+For twl6032 regulators/LDOs
- compatible:
- - "ti,twl6025-ldo1" for LDO1 LDO
- - "ti,twl6025-ldo2" for LDO2 LDO
- - "ti,twl6025-ldo3" for LDO3 LDO
- - "ti,twl6025-ldo4" for LDO4 LDO
- - "ti,twl6025-ldo5" for LDO5 LDO
- - "ti,twl6025-ldo6" for LDO6 LDO
- - "ti,twl6025-ldo7" for LDO7 LDO
- - "ti,twl6025-ldoln" for LDOLN LDO
- - "ti,twl6025-ldousb" for LDOUSB LDO
- - "ti,twl6025-smps3" for SMPS3 SMPS
- - "ti,twl6025-smps4" for SMPS4 SMPS
- - "ti,twl6025-vio" for VIO SMPS
+ - "ti,twl6032-ldo1" for LDO1 LDO
+ - "ti,twl6032-ldo2" for LDO2 LDO
+ - "ti,twl6032-ldo3" for LDO3 LDO
+ - "ti,twl6032-ldo4" for LDO4 LDO
+ - "ti,twl6032-ldo5" for LDO5 LDO
+ - "ti,twl6032-ldo6" for LDO6 LDO
+ - "ti,twl6032-ldo7" for LDO7 LDO
+ - "ti,twl6032-ldoln" for LDOLN LDO
+ - "ti,twl6032-ldousb" for LDOUSB LDO
+ - "ti,twl6032-smps3" for SMPS3 SMPS
+ - "ti,twl6032-smps4" for SMPS4 SMPS
+ - "ti,twl6032-vio" for VIO SMPS
For twl4030 regulators/LDOs
- compatible:
- "ti,twl4030-vaux1" for VAUX1 LDO
diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt
b/Documentation/devicetree/bindings/usb/twl-usb.txt
index 36b9aed..0aee0ad 100644
--- a/Documentation/devicetree/bindings/usb/twl-usb.txt
+++ b/Documentation/devicetree/bindings/usb/twl-usb.txt
@@ -8,7 +8,7 @@ TWL6030 USB COMPARATOR
usb interrupt number that raises VBUS interrupts when the controller has to
act as device
- usb-supply : phandle to the regulator device tree node. It should be vusb
- if it is twl6030 or ldousb if it is twl6025 subclass.
+ if it is twl6030 or ldousb if it is twl6032 subclass.
twl6030-usb {
compatible = "ti,twl6030-usb";
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 89ab4d9..f39bceb 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -118,7 +118,7 @@
#define TWL6030_BASEADD_GASGAUGE 0x00C0
#define TWL6030_BASEADD_PIH0x00D0
#define TWL6030_BASEADD_CHARGER0x00E0
-#define TWL6025_BASEADD_CHARGER0x00DA
+#define TWL6032_BASEADD_CHARGER0x00DA
#define TWL6030_BASEADD_LED0x00F4
/* subchip/slave 2 0x4A - DFT */
@@ -718,9 +718,9 @@ add_children(struct twl4030_platform_data *pdata, unsigned
irq_base,
| REGULATOR_CHANGE_STATUS,
};
- if (features & TWL6025_SUBCLASS) {
+ if (features & TWL6032_SUBCLASS) {
usb3v3.supply = "ldousb";
- regulator = TWL6025_REG_LDOUSB;
+ regulator = TWL6032_REG_LDOUSB;
} else {
usb3v3.supply = "vusb";
regulator = TWL6030_REG_VUSB;
@@ -747,8 +747,8 @@ add_children(struct twl4030_platform_data *pdata, unsigned
irq_base,
Re: [PATCH 1/1] i2c: omap: correct usage of the interrupt enable register
On 05/29/2013 08:22 PM, Kevin Hilman wrote: Oleksandr Dmytryshyn writes: Starting from the OMAP chips with version2 registers scheme there are 2 registers (I2C_IRQENABLE_SET and I2C_IRQENABLE_CLR) to manage interrupts instead of the older OMAP chips with old scheme which have only one register (I2C_IE). Now we should use I2C_IRQENABLE_SET register for enabling interrupts and I2C_IRQENABLE_CLR register for disabling interrupts. Why? (changelogs should always answer the "why" question) IOW, what is broken without this change, how does it fail? And equally important, how is it currently working? Kevin Hi, Kevin. If the i2c controller during suspend will generate an interrupt, it can lead to unpredictable behaviour in the kernel. Based on the logic of the kernel code interrupts from i2c should be prohibited during suspend. Kernel writes 0 to the I2C_IE register in the omap_i2c_runtime_suspend() function. In the other side kernel writes saved interrupt flags to the I2C_IE register in omap_i2c_runtime_resume() function. I.e. interrupts should be disabled during suspend. This works for chips with version1 registers scheme. Interrupts are disabled during suspend. For chips with version2 scheme registers writting 0 to the I2C_IE register does nothing (because now the I2C_IRQENABLE_SET register is located at this address ). This register is used to enable interrupts. For disabling interrupts I2C_IRQENABLE_CLR register should be used. I've checked that interrupts in the i2c controller are still enabled after writting 0 to the I2C_IE register. But with my patch interrupts are disabled in the omap_i2c_runtime_suspend() function. -- Best regards, Oleksandr Dmytryshyn | OMAP4 Platform GlobalLogic Inc. | Innovation by Design -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] i2c: omap: correct usage of the interrupt enable register
On 05/30/2013 05:18 PM, Kevin Hilman wrote: Oleksandr Dmytryshyn writes: On 05/29/2013 08:22 PM, Kevin Hilman wrote: Oleksandr Dmytryshyn writes: Starting from the OMAP chips with version2 registers scheme there are 2 registers (I2C_IRQENABLE_SET and I2C_IRQENABLE_CLR) to manage interrupts instead of the older OMAP chips with old scheme which have only one register (I2C_IE). Now we should use I2C_IRQENABLE_SET register for enabling interrupts and I2C_IRQENABLE_CLR register for disabling interrupts. Why? (changelogs should always answer the "why" question) IOW, what is broken without this change, how does it fail? And equally important, how is it currently working? Kevin Hi, Kevin. If the i2c controller during suspend will generate an interrupt, it can lead to unpredictable behaviour in the kernel. Based on the logic of the kernel code interrupts from i2c should be prohibited during suspend. Kernel writes 0 to the I2C_IE register in the omap_i2c_runtime_suspend() function. In the other side kernel writes saved interrupt flags to the I2C_IE register in omap_i2c_runtime_resume() function. I.e. interrupts should be disabled during suspend. This works for chips with version1 registers scheme. Interrupts are disabled during suspend. For chips with version2 scheme registers writting 0 to the I2C_IE register does nothing (because now the I2C_IRQENABLE_SET register is located at this address ). This register is used to enable interrupts. For disabling interrupts I2C_IRQENABLE_CLR register should be used. I've checked that interrupts in the i2c controller are still enabled after writting 0 to the I2C_IE register. But with my patch interrupts are disabled in the omap_i2c_runtime_suspend() function. Yes, I understand why your patch works, and it looks correct to me. My main concern is that the changelog is missing a detailed description of the problem that is being solved, as well as a summary of why this has ever worked. I guess we've just been lucky and not seen interrupts during suspend? Kevin Hi, Kevin. Yes. You are right about the interrupts. -- Best regards, Oleksandr Dmytryshyn | OMAP4 Platform GlobalLogic Inc. | Innovation by Design -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/1] i2c: omap: correct usage of the interrupt enable register
I've just added a detailed description of the problem that is being solved to the cover letter and commit message in the patch. If the i2c controller during suspend will generate an interrupt, it can lead to unpredictable behaviour in the kernel. Based on the logic of the kernel code interrupts from i2c should be prohibited during suspend. Kernel writes 0 to the I2C_IE register in the omap_i2c_runtime_suspend() function. In the other side kernel writes saved interrupt flags to the I2C_IE register in omap_i2c_runtime_resume() function. I.e. interrupts should be disabled during suspend. This works for chips with version1 registers scheme. Interrupts are disabled during suspend. For chips with version2 scheme registers writting 0 to the I2C_IE register does nothing (because now the I2C_IRQENABLE_SET register is located at this address). This register is used to enable interrupts. For disabling interrupts I2C_IRQENABLE_CLR register should be used. Because the registers I2C_IRQENABLE_SET and I2C_IE have the same addresses, the interrupt enabling procedure is unchanged. I've checked that interrupts in the i2c controller are still enabled after writting 0 to the I2C_IE register. But with my patch interrupts are disabled in the omap_i2c_runtime_suspend() function. Next patch fixes it. Patch is based on: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git tag: v3.10-rc2 Verified on OMAP4430. Oleksandr Dmytryshyn (1): i2c: omap: correct usage of the interrupt enable register drivers/i2c/busses/i2c-omap.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) -- 1.8.2.rc2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/1] i2c: omap: correct usage of the interrupt enable register
If the i2c controller during suspend will generate an interrupt, it
can lead to unpredictable behaviour in the kernel.
Based on the logic of the kernel code interrupts from i2c should be
prohibited during suspend. Kernel writes 0 to the I2C_IE register in
the omap_i2c_runtime_suspend() function. In the other side kernel
writes saved interrupt flags to the I2C_IE register in
omap_i2c_runtime_resume() function. I.e. interrupts should be disabled
during suspend.
This works for chips with version1 registers scheme. Interrupts are
disabled during suspend. For chips with version2 scheme registers
writting 0 to the I2C_IE register does nothing (because now the
I2C_IRQENABLE_SET register is located at this address). This register
is used to enable interrupts. For disabling interrupts
I2C_IRQENABLE_CLR register should be used.
Because the registers I2C_IRQENABLE_SET and I2C_IE have the same
addresses, the interrupt enabling procedure is unchanged.
Signed-off-by: Oleksandr Dmytryshyn
---
drivers/i2c/busses/i2c-omap.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index e02f9e3..2419899 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -180,6 +180,8 @@ enum {
#define I2C_OMAP_ERRATA_I207 (1 << 0)
#define I2C_OMAP_ERRATA_I462 (1 << 1)
+#define OMAP_I2C_INTERRUPTS_MASK 0x6FFF
+
struct omap_i2c_dev {
spinlock_t lock; /* IRQ synchronization */
struct device *dev;
@@ -193,6 +195,7 @@ struct omap_i2c_dev {
long latency);
u32 speed; /* Speed of bus in kHz */
u32 flags;
+ u16 scheme;
u16 cmd_err;
u8 *buf;
u8 *regs;
@@ -1082,7 +1085,7 @@ omap_i2c_probe(struct platform_device *pdev)
int irq;
int r;
u32 rev;
- u16 minor, major, scheme;
+ u16 minor, major;
/* NOTE: driver uses the static register mapping */
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -1159,8 +1162,8 @@ omap_i2c_probe(struct platform_device *pdev)
*/
rev = __raw_readw(dev->base + 0x04);
- scheme = OMAP_I2C_SCHEME(rev);
- switch (scheme) {
+ dev->scheme = OMAP_I2C_SCHEME(rev);
+ switch (dev->scheme) {
case OMAP_I2C_SCHEME_0:
dev->regs = (u8 *)reg_map_ip_v1;
dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG);
@@ -1289,7 +1292,11 @@ static int omap_i2c_runtime_suspend(struct device *dev)
_dev->iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
- omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
+ if (_dev->scheme == OMAP_I2C_SCHEME_0)
+ omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
+ else
+ omap_i2c_write_reg(_dev, OMAP_I2C_IP_V2_IRQENABLE_CLR,
+ OMAP_I2C_INTERRUPTS_MASK);
if (_dev->rev < OMAP_I2C_OMAP1_REV_2) {
omap_i2c_read_reg(_dev, OMAP_I2C_IV_REG); /* Read clears */
--
1.8.2.rc2
--
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 1/1] i2c: omap: correct usage of the interrupt enable register
On 05/30/2013 07:46 PM, Kevin Hilman wrote:
Oleksandr Dmytryshyn writes:
If the i2c controller during suspend will generate an interrupt, it
can lead to unpredictable behaviour in the kernel.
Based on the logic of the kernel code interrupts from i2c should be
prohibited during suspend. Kernel writes 0 to the I2C_IE register in
the omap_i2c_runtime_suspend() function. In the other side kernel
writes saved interrupt flags to the I2C_IE register in
omap_i2c_runtime_resume() function. I.e. interrupts should be disabled
during suspend.
This works for chips with version1 registers scheme. Interrupts are
disabled during suspend. For chips with version2 scheme registers
writting 0 to the I2C_IE register does nothing (because now the
I2C_IRQENABLE_SET register is located at this address). This register
is used to enable interrupts. For disabling interrupts
I2C_IRQENABLE_CLR register should be used.
Because the registers I2C_IRQENABLE_SET and I2C_IE have the same
addresses, the interrupt enabling procedure is unchanged.
Signed-off-by: Oleksandr Dmytryshyn
Much better, but still doesn't explain how/why this has been working up
until now. Have we just been lucky?
Yes, this has been working up until now because we've just been lucky.
---
drivers/i2c/busses/i2c-omap.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index e02f9e3..2419899 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -180,6 +180,8 @@ enum {
#define I2C_OMAP_ERRATA_I207 (1 << 0)
#define I2C_OMAP_ERRATA_I462 (1 << 1)
+#define OMAP_I2C_INTERRUPTS_MASK 0x6FFF
To be more clear, this should probably have v2 in the name.
I'll rename this mask in the patch-set v3
Kevin
--
Best regards,
Oleksandr Dmytryshyn | OMAP4 Platform
GlobalLogic Inc. | Innovation by Design
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/1] i2c: omap: correct usage of the interrupt enable register
If the i2c controller during suspend will generate an interrupt, it
can lead to unpredictable behaviour in the kernel.
Based on the logic of the kernel code interrupts from i2c should be
prohibited during suspend. Kernel writes 0 to the I2C_IE register in
the omap_i2c_runtime_suspend() function. In the other side kernel
writes saved interrupt flags to the I2C_IE register in
omap_i2c_runtime_resume() function. I.e. interrupts should be disabled
during suspend.
This works for chips with version1 registers scheme. Interrupts are
disabled during suspend. For chips with version2 scheme registers
writting 0 to the I2C_IE register does nothing (because now the
I2C_IRQENABLE_SET register is located at this address). This register
is used to enable interrupts. For disabling interrupts
I2C_IRQENABLE_CLR register should be used.
Because the registers I2C_IRQENABLE_SET and I2C_IE have the same
addresses, the interrupt enabling procedure is unchanged.
Change-Id: Ie49165990a4e7c67a4ccf2e4a66cd3b78f2e2b70
Signed-off-by: Oleksandr Dmytryshyn
---
drivers/i2c/busses/i2c-omap.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index e02f9e3..64c26f9 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -180,6 +180,8 @@ enum {
#define I2C_OMAP_ERRATA_I207 (1 << 0)
#define I2C_OMAP_ERRATA_I462 (1 << 1)
+#define OMAP_I2C_IP_V2_INTERRUPTS_MASK 0x6FFF
+
struct omap_i2c_dev {
spinlock_t lock; /* IRQ synchronization */
struct device *dev;
@@ -193,6 +195,7 @@ struct omap_i2c_dev {
long latency);
u32 speed; /* Speed of bus in kHz */
u32 flags;
+ u16 scheme;
u16 cmd_err;
u8 *buf;
u8 *regs;
@@ -1082,7 +1085,7 @@ omap_i2c_probe(struct platform_device *pdev)
int irq;
int r;
u32 rev;
- u16 minor, major, scheme;
+ u16 minor, major;
/* NOTE: driver uses the static register mapping */
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -1159,8 +1162,8 @@ omap_i2c_probe(struct platform_device *pdev)
*/
rev = __raw_readw(dev->base + 0x04);
- scheme = OMAP_I2C_SCHEME(rev);
- switch (scheme) {
+ dev->scheme = OMAP_I2C_SCHEME(rev);
+ switch (dev->scheme) {
case OMAP_I2C_SCHEME_0:
dev->regs = (u8 *)reg_map_ip_v1;
dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG);
@@ -1289,7 +1292,11 @@ static int omap_i2c_runtime_suspend(struct device *dev)
_dev->iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
- omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
+ if (_dev->scheme == OMAP_I2C_SCHEME_0)
+ omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
+ else
+ omap_i2c_write_reg(_dev, OMAP_I2C_IP_V2_IRQENABLE_CLR,
+ OMAP_I2C_IP_V2_INTERRUPTS_MASK);
if (_dev->rev < OMAP_I2C_OMAP1_REV_2) {
omap_i2c_read_reg(_dev, OMAP_I2C_IV_REG); /* Read clears */
--
1.8.2.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/1] i2c: omap: correct usage of the interrupt enable register
I've just renamed OMAP_I2C_INTERRUPTS_MASK to the OMAP_I2C_IP_V2_INTERRUPTS_MASK. If the i2c controller during suspend will generate an interrupt, it can lead to unpredictable behaviour in the kernel. Based on the logic of the kernel code interrupts from i2c should be prohibited during suspend. Kernel writes 0 to the I2C_IE register in the omap_i2c_runtime_suspend() function. In the other side kernel writes saved interrupt flags to the I2C_IE register in omap_i2c_runtime_resume() function. I.e. interrupts should be disabled during suspend. This works for chips with version1 registers scheme. Interrupts are disabled during suspend. For chips with version2 scheme registers writting 0 to the I2C_IE register does nothing (because now the I2C_IRQENABLE_SET register is located at this address). This register is used to enable interrupts. For disabling interrupts I2C_IRQENABLE_CLR register should be used. Because the registers I2C_IRQENABLE_SET and I2C_IE have the same addresses, the interrupt enabling procedure is unchanged. I've checked that interrupts in the i2c controller are still enabled after writting 0 to the I2C_IE register. But with my patch interrupts are disabled in the omap_i2c_runtime_suspend() function. This has been working up until now because we've just been lucky. Next patch fixes it. Patch is based on: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git tag: v3.10-rc2 Verified on OMAP4430. Oleksandr Dmytryshyn (1): i2c: omap: correct usage of the interrupt enable register drivers/i2c/busses/i2c-omap.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) -- 1.8.2.rc2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 0/1] i2c: omap: correct usage of the interrupt enable register
I've just removed unnecessary Change-Id line. If the i2c controller during suspend will generate an interrupt, it can lead to unpredictable behaviour in the kernel. Based on the logic of the kernel code interrupts from i2c should be prohibited during suspend. Kernel writes 0 to the I2C_IE register in the omap_i2c_runtime_suspend() function. In the other side kernel writes saved interrupt flags to the I2C_IE register in omap_i2c_runtime_resume() function. I.e. interrupts should be disabled during suspend. This works for chips with version1 registers scheme. Interrupts are disabled during suspend. For chips with version2 scheme registers writting 0 to the I2C_IE register does nothing (because now the I2C_IRQENABLE_SET register is located at this address). This register is used to enable interrupts. For disabling interrupts I2C_IRQENABLE_CLR register should be used. Because the registers I2C_IRQENABLE_SET and I2C_IE have the same addresses, the interrupt enabling procedure is unchanged. I've checked that interrupts in the i2c controller are still enabled after writting 0 to the I2C_IE register. But with my patch interrupts are disabled in the omap_i2c_runtime_suspend() function. This has been working up until now because we've just been lucky. Next patch fixes it. Patch is based on: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git tag: v3.10-rc2 Verified on OMAP4430. Oleksandr Dmytryshyn (1): i2c: omap: correct usage of the interrupt enable register drivers/i2c/busses/i2c-omap.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) -- 1.8.2.rc2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/1] i2c: omap: correct usage of the interrupt enable register
If the i2c controller during suspend will generate an interrupt, it
can lead to unpredictable behaviour in the kernel.
Based on the logic of the kernel code interrupts from i2c should be
prohibited during suspend. Kernel writes 0 to the I2C_IE register in
the omap_i2c_runtime_suspend() function. In the other side kernel
writes saved interrupt flags to the I2C_IE register in
omap_i2c_runtime_resume() function. I.e. interrupts should be disabled
during suspend.
This works for chips with version1 registers scheme. Interrupts are
disabled during suspend. For chips with version2 scheme registers
writting 0 to the I2C_IE register does nothing (because now the
I2C_IRQENABLE_SET register is located at this address). This register
is used to enable interrupts. For disabling interrupts
I2C_IRQENABLE_CLR register should be used.
Because the registers I2C_IRQENABLE_SET and I2C_IE have the same
addresses, the interrupt enabling procedure is unchanged.
Signed-off-by: Oleksandr Dmytryshyn
---
drivers/i2c/busses/i2c-omap.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index e02f9e3..64c26f9 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -180,6 +180,8 @@ enum {
#define I2C_OMAP_ERRATA_I207 (1 << 0)
#define I2C_OMAP_ERRATA_I462 (1 << 1)
+#define OMAP_I2C_IP_V2_INTERRUPTS_MASK 0x6FFF
+
struct omap_i2c_dev {
spinlock_t lock; /* IRQ synchronization */
struct device *dev;
@@ -193,6 +195,7 @@ struct omap_i2c_dev {
long latency);
u32 speed; /* Speed of bus in kHz */
u32 flags;
+ u16 scheme;
u16 cmd_err;
u8 *buf;
u8 *regs;
@@ -1082,7 +1085,7 @@ omap_i2c_probe(struct platform_device *pdev)
int irq;
int r;
u32 rev;
- u16 minor, major, scheme;
+ u16 minor, major;
/* NOTE: driver uses the static register mapping */
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -1159,8 +1162,8 @@ omap_i2c_probe(struct platform_device *pdev)
*/
rev = __raw_readw(dev->base + 0x04);
- scheme = OMAP_I2C_SCHEME(rev);
- switch (scheme) {
+ dev->scheme = OMAP_I2C_SCHEME(rev);
+ switch (dev->scheme) {
case OMAP_I2C_SCHEME_0:
dev->regs = (u8 *)reg_map_ip_v1;
dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG);
@@ -1289,7 +1292,11 @@ static int omap_i2c_runtime_suspend(struct device *dev)
_dev->iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
- omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
+ if (_dev->scheme == OMAP_I2C_SCHEME_0)
+ omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
+ else
+ omap_i2c_write_reg(_dev, OMAP_I2C_IP_V2_IRQENABLE_CLR,
+ OMAP_I2C_IP_V2_INTERRUPTS_MASK);
if (_dev->rev < OMAP_I2C_OMAP1_REV_2) {
omap_i2c_read_reg(_dev, OMAP_I2C_IV_REG); /* Read clears */
--
1.8.2.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5] i2c: omap: correct usage of the interrupt enable register
We've been lucky not to have any interrupts fire during the suspend
path, otherwise we would have unpredictable behaviour in the kernel.
Based on the logic of the kernel code interrupts from i2c should be
prohibited during suspend. Kernel writes 0 to the I2C_IE register in
the omap_i2c_runtime_suspend() function. In the other side kernel
writes saved interrupt flags to the I2C_IE register in
omap_i2c_runtime_resume() function. I.e. interrupts should be disabled
during suspend.
This works for chips with version1 registers scheme. Interrupts are
disabled during suspend. For chips with version2 scheme registers
writting 0 to the I2C_IE register does nothing (because now the
I2C_IRQENABLE_SET register is located at this address). This register
is used to enable interrupts. For disabling interrupts
I2C_IRQENABLE_CLR register should be used.
Because the registers I2C_IRQENABLE_SET and I2C_IE have the same
addresses, the interrupt enabling procedure is unchanged.
I've checked that interrupts in the i2c controller are still enabled
after writting 0 to the I2C_IRQENABLE_SET register. With this patch
interrupts are disabled in the omap_i2c_runtime_suspend() function.
Patch is based on:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
tag: v3.10-rc2
Verified on OMAP4430.
Signed-off-by: Oleksandr Dmytryshyn
---
drivers/i2c/busses/i2c-omap.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index e02f9e3..64c26f9 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -180,6 +180,8 @@ enum {
#define I2C_OMAP_ERRATA_I207 (1 << 0)
#define I2C_OMAP_ERRATA_I462 (1 << 1)
+#define OMAP_I2C_IP_V2_INTERRUPTS_MASK 0x6FFF
+
struct omap_i2c_dev {
spinlock_t lock; /* IRQ synchronization */
struct device *dev;
@@ -193,6 +195,7 @@ struct omap_i2c_dev {
long latency);
u32 speed; /* Speed of bus in kHz */
u32 flags;
+ u16 scheme;
u16 cmd_err;
u8 *buf;
u8 *regs;
@@ -1082,7 +1085,7 @@ omap_i2c_probe(struct platform_device *pdev)
int irq;
int r;
u32 rev;
- u16 minor, major, scheme;
+ u16 minor, major;
/* NOTE: driver uses the static register mapping */
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -1159,8 +1162,8 @@ omap_i2c_probe(struct platform_device *pdev)
*/
rev = __raw_readw(dev->base + 0x04);
- scheme = OMAP_I2C_SCHEME(rev);
- switch (scheme) {
+ dev->scheme = OMAP_I2C_SCHEME(rev);
+ switch (dev->scheme) {
case OMAP_I2C_SCHEME_0:
dev->regs = (u8 *)reg_map_ip_v1;
dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG);
@@ -1289,7 +1292,11 @@ static int omap_i2c_runtime_suspend(struct device *dev)
_dev->iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
- omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
+ if (_dev->scheme == OMAP_I2C_SCHEME_0)
+ omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
+ else
+ omap_i2c_write_reg(_dev, OMAP_I2C_IP_V2_IRQENABLE_CLR,
+ OMAP_I2C_IP_V2_INTERRUPTS_MASK);
if (_dev->rev < OMAP_I2C_OMAP1_REV_2) {
omap_i2c_read_reg(_dev, OMAP_I2C_IV_REG); /* Read clears */
--
1.8.2.rc2
--
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/
[RFC v1] MFD: Change TWL6025 references to TWL6032
From: Graeme Gregory
The TWL6025 was never released beyond sample form and was replaced by
the PhoenixLite range of chips - TWL6032. Change the references to
reference the TWL6032 class and name the registers to twl6032 in line with
an actual released chip name to avoid confusion.
Currently there is no users of TWL6025 in the code.
Signed-off-by: Graeme Gregory
Signed-off-by: Oleksandr Kozaruk
---
There are non-mainline branches that use twl6032 by its name (for example
git://git.omapzoom.org/kernel/omap.git). There is intention to add support
of twl6032 device in mainline, but we'd like to know if we can use twl6032
instead of twl6025 in our new patches, that we are going to provide.
drivers/mfd/twl-core.c| 46 +++---
drivers/regulator/twl-regulator.c | 76 ++---
drivers/usb/phy/phy-twl6030-usb.c |2 +-
include/linux/i2c/twl.h | 30 +++
4 files changed, 77 insertions(+), 77 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 89ab4d9..f39bceb 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -118,7 +118,7 @@
#define TWL6030_BASEADD_GASGAUGE 0x00C0
#define TWL6030_BASEADD_PIH0x00D0
#define TWL6030_BASEADD_CHARGER0x00E0
-#define TWL6025_BASEADD_CHARGER0x00DA
+#define TWL6032_BASEADD_CHARGER0x00DA
#define TWL6030_BASEADD_LED0x00F4
/* subchip/slave 2 0x4A - DFT */
@@ -718,9 +718,9 @@ add_children(struct twl4030_platform_data *pdata, unsigned
irq_base,
| REGULATOR_CHANGE_STATUS,
};
- if (features & TWL6025_SUBCLASS) {
+ if (features & TWL6032_SUBCLASS) {
usb3v3.supply = "ldousb";
- regulator = TWL6025_REG_LDOUSB;
+ regulator = TWL6032_REG_LDOUSB;
} else {
usb3v3.supply = "vusb";
regulator = TWL6030_REG_VUSB;
@@ -747,8 +747,8 @@ add_children(struct twl4030_platform_data *pdata, unsigned
irq_base,
usb3v3.dev_name = dev_name(child);
} else if (IS_ENABLED(CONFIG_REGULATOR_TWL4030) &&
twl_class_is_6030()) {
- if (features & TWL6025_SUBCLASS)
- child = add_regulator(TWL6025_REG_LDOUSB,
+ if (features & TWL6032_SUBCLASS)
+ child = add_regulator(TWL6032_REG_LDOUSB,
pdata->ldousb, features);
else
child = add_regulator(TWL6030_REG_VUSB,
@@ -872,7 +872,7 @@ add_children(struct twl4030_platform_data *pdata, unsigned
irq_base,
/* twl6030 regulators */
if (IS_ENABLED(CONFIG_REGULATOR_TWL4030) && twl_class_is_6030() &&
- !(features & TWL6025_SUBCLASS)) {
+ !(features & TWL6032_SUBCLASS)) {
child = add_regulator(TWL6030_REG_VDD1, pdata->vdd1,
features);
if (IS_ERR(child))
@@ -952,60 +952,60 @@ add_children(struct twl4030_platform_data *pdata,
unsigned irq_base,
return PTR_ERR(child);
}
- /* twl6025 regulators */
+ /* twl6032 regulators */
if (IS_ENABLED(CONFIG_REGULATOR_TWL4030) && twl_class_is_6030() &&
- (features & TWL6025_SUBCLASS)) {
- child = add_regulator(TWL6025_REG_LDO5, pdata->ldo5,
+ (features & TWL6032_SUBCLASS)) {
+ child = add_regulator(TWL6032_REG_LDO5, pdata->ldo5,
features);
if (IS_ERR(child))
return PTR_ERR(child);
- child = add_regulator(TWL6025_REG_LDO1, pdata->ldo1,
+ child = add_regulator(TWL6032_REG_LDO1, pdata->ldo1,
features);
if (IS_ERR(child))
return PTR_ERR(child);
- child = add_regulator(TWL6025_REG_LDO7, pdata->ldo7,
+ child = add_regulator(TWL6032_REG_LDO7, pdata->ldo7,
features);
if (IS_ERR(child))
return PTR_ERR(child);
- child = add_regulator(TWL6025_REG_LDO6, pdata->ldo6,
+ child = add_regulator(TWL6032_REG_LDO6, pdata->ldo6,
features);
if (IS_ERR(child))
return PTR_ERR(child);
- child = add_regulator(TWL6025_REG_LDOLN, pdata->ldoln,
+ child =
[PATCH v1 0/2] TWL6030, TWL6032 GPADC driver
Hello TWL603[02] GPADC is used to measure battery voltage, battery temperature, battery presence ID, and could be used to measure twl603[02] die temperature. This is used on TI blaze, blaze tablet platforms. The TWL6030 and TWL6032 have GPADC with 17 and 19 channels respectively. Some channels have current source and are used for measuring voltage drop on resistive load for detecting battery ID resistance, or measuring voltage drop on NTC resistors for external temperature measurements. Some channels measure voltage, (i.e. battery voltage), and have inbuilt voltage dividers, thus, capable to scale voltage. Some channels are dedicated for measuring die temperature. Some channels could be calibrated in 2 points, having offsets from ideal values in trim registers. The difference between GPADC in TWL6030 and TWL6032: - 10 bit vs 12 bit ADC; - 17 vs 19 channels; - channels have different purpose(i. e. battery voltage channel 8 vs channel 18); - trim values are interpreted differently. The driver exports function returning converted value for requested channels: raw code, corrected code, and converted to mV result. Sysfs entries are added to start and read conversion result in millivolts for channel if it has calibration data, or ADC code(for temperature and test network channels). The driver is derived from git://git.omapzoom.org/kernel/omap.git The original driver's authors and contributors are Balaji T K, Graeme Gregory, Ambresh K, Girish S Ghongdemath. The changes to the original driver: - device tree adaptation; - drop ioctl support - never been used; - unified measurement method for both devices; - get rid of "if (device == X)" code style to data driven; - drop polling end of conversion and use interrupt instead; - simplified (hopefully) exported external function interface to the driver. Tested with on blaze tablet 2 with OMAP4430(twl6030), and OMAP4470(twl6032) SOMs. The patches were tested against 3.10-rc7 Oleksandr Kozaruk (2): ARM: dts: twl: Add GPADC data to device tree mfd: twl6030-gpadc: TWL6030, TWL6032 GPADC driver .../testing/sysfs-devices-platform-twl6030_gpadc |5 + arch/arm/boot/dts/twl6030.dtsi |5 + drivers/mfd/Kconfig|8 + drivers/mfd/Makefile |1 + drivers/mfd/twl6030-gpadc.c| 1053 include/linux/i2c/twl6030-gpadc.h | 51 + 6 files changed, 1123 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-devices-platform-twl6030_gpadc create mode 100644 drivers/mfd/twl6030-gpadc.c create mode 100644 include/linux/i2c/twl6030-gpadc.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 2/2] mfd: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC, known also as Phoenix and PhoenixLite. The TWL6030 and TWL6032 have GPADC with 17 and 19 channels respectively. Some channels have current source and are used for measuring voltage drop on resistive load for detecting battery ID resistance, or measuring voltage drop on NTC resistors for external temperature measurements. Some channels measure voltage, (i.e. battery voltage), and have voltage dividers, thus, capable to scale voltage. Some channels are dedicated for measuring die temperature. Some channels are calibrated in 2 points, having offsets from ideal values kept in trim registers. This is used to correct measurements. The differences between GPADC in TWL6030 and TWL6032: - 10 bit vs 12 bit ADC; - 17 vs 19 channels; - channels have different purpose(i. e. battery voltage channel 8 vs channel 18); - trim values are interpreted differently. The driver exports function returning converted value for requested channels. Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K, Girish S Ghongdemath. Signed-off-by: Balaji T K Graeme Gregory Signed-off-by: Oleksandr Kozaruk --- .../testing/sysfs-devices-platform-twl6030_gpadc |5 + drivers/mfd/Kconfig|8 + drivers/mfd/Makefile |1 + drivers/mfd/twl6030-gpadc.c| 1053 include/linux/i2c/twl6030-gpadc.h | 51 + 5 files changed, 1118 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-devices-platform-twl6030_gpadc create mode 100644 drivers/mfd/twl6030-gpadc.c create mode 100644 include/linux/i2c/twl6030-gpadc.h diff --git a/Documentation/ABI/testing/sysfs-devices-platform-twl6030_gpadc b/Documentation/ABI/testing/sysfs-devices-platform-twl6030_gpadc new file mode 100644 index 000..e9c5812 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-platform-twl6030_gpadc @@ -0,0 +1,5 @@ +What: /sys/bus/platform/devices/twl603X_gpadc.26/inX_channel +Date: June 2013 +Contact: Oleksandr Kozaruk +Description: Start GPADC conversion for chosen channel X and report the result. + The result is returned in millivolts. diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index d54e985..8eb7494 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -970,6 +970,14 @@ config MFD_TC3589X additional drivers must be enabled in order to use the functionality of the device. +config TWL6030_GPADC + tristate "TWL6030 GPADC (General Purpose A/D Convertor) Support" + depends on TWL4030_CORE + default n + help + Say yes here if you want support for the TWL6030 General Purpose + A/D Convertor. + config MFD_TMIO bool default n diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index 718e94a..59f504f 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -70,6 +70,7 @@ obj-$(CONFIG_MENELAUS)+= menelaus.o obj-$(CONFIG_TWL4030_CORE) += twl-core.o twl4030-irq.o twl6030-irq.o obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o +obj-$(CONFIG_TWL6030_GPADC)+= twl6030-gpadc.o obj-$(CONFIG_MFD_TWL4030_AUDIO)+= twl4030-audio.o obj-$(CONFIG_TWL6040_CORE) += twl6040.o diff --git a/drivers/mfd/twl6030-gpadc.c b/drivers/mfd/twl6030-gpadc.c new file mode 100644 index 000..1868bc0 --- /dev/null +++ b/drivers/mfd/twl6030-gpadc.c @@ -0,0 +1,1053 @@ +/* + * TWL6030 GPADC module driver + * + * Copyright (C) 2009-2013 Texas Instruments Inc. + * Nishant Kamat + * Balaji T K + * Graeme Gregory + * Girish S Ghongdemath + * Ambresh K + * Oleksandr Kozaruk + * + * 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. + * + * 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. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DRIVER_NAME"twl6030_gpadc" + +#define TWL6030_GPADC_MAX_CHANNELS 17 +#define TWL6032_GPADC_MAX_CHANNELS 19 +/* Define this as the biggest of all chips using this driver */ +#define GPADC_MAX_CHANNELS TWL6032_GPADC_MAX_CHANNELS + +#define TWL6030_GPADC_CTRL 0x00/* 0x2e */ +#define TWL6030_GPADC_CTRL2
[PATCH v1 1/2] ARM: dts: twl: Add GPADC data to device tree
GPADC is the general purpose ADC present on twl6030.
The dt data is interrupt used to trigger end of ADC
conversion.
Signed-off-by: Oleksandr Kozaruk
---
arch/arm/boot/dts/twl6030.dtsi |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 2e3bd31..189872c 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -103,4 +103,9 @@
compatible = "ti,twl6030-pwmled";
#pwm-cells = <2>;
};
+
+ twl6030_gpadc {
+ compatible = "ti,twl6030_gpadc";
+ interrupts = <3>;
+ };
};
--
1.7.9.5
--
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: add Bosch BMA180 acceleration sensor driver
On Thu, Aug 15, 2013 at 1:22 PM, Jonathan Cameron wrote:
> On 08/13/13 16:44, Oleksandr Kravchenko wrote:
>> This patch adds IIO driver for Bosch BMA180 triaxial
>> acceleration sensor.
>> http://dlnmh9ip6v2uc.cloudfront.net/datasheets/
>> Sensors/Accelerometers/BST-BMA180-DS000-07_2.pdf
>>
>> Signed-off-by: Oleksandr Kravchenko
> Hi,
>
> Firstly, just a thought (I haven't made up my mind whether it is a good idea
> or
> not!) but you could use devm_kzalloc for data->buff and hence avoid having
> to care about freeing it in the remove function. Update scan mode isn't
> a particularly fast path so I doubt the small overhead will matter.
Thanks, it is a good idea.
>
> Otherwise, the abi additions need documenting iff they don't fit within
> existing ABI. If they do then they need to match existing ABI.
>
> Of those, 'mode' is rather device specific and could probably do with
> a more detailed name. The only 'generic' way to do it would be to make the
> channel type attributes writable and treat it as a resolution control rather
> than a noise/power trade off. Uggly though so perhaps what you have makes
> sense. We can always add a more generic way of controlling this if it
> starts turning up in lots of devices (keeping this method of course to avoid
> breaking ABI).
Ok, I'll change 'mode' to 'power_mode' and document it in ABI.
>
> 'bandwidth' is already (I think) covered by the ABI. For the bandwidth
> optoins you have enabled we are talking low pass
> filters and presumably their 3db point.
> In Documentation/ABI/testing/sysfs-bus-iio you will find
> in_accel_filter_low_pass_3db_frequency. My filter theory is
> rather rusty (not sure it was
> every anything else ;). Hence I'm not entirely sure how to work
> out the 3db frequency from the 'pole frequency' if they are not infact
> the same thing..
You are right. In my case 'bandwidth' is low path filter. I'll change my driver
accordingly. But how can I declare available values?
If I do it in next way:
static IIO_CONST_ATTR(in_accel0_filter_low_pass_3db_frequency_available,
BMA180_BW_AVAILABLE);
it will lock so ugly in the code and sysfs...
>
> Otherwise, the driver looks good to me.
>
> Jonathan
>> ---
>> .../devicetree/bindings/iio/accel/bma180.txt | 24 +
>> drivers/iio/accel/Kconfig | 12 +
>> drivers/iio/accel/Makefile |2 +
>> drivers/iio/accel/bma180.c | 689
>>
>> 4 files changed, 727 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/iio/accel/bma180.txt
>> create mode 100644 drivers/iio/accel/bma180.c
>>
>> diff --git a/Documentation/devicetree/bindings/iio/accel/bma180.txt
>> b/Documentation/devicetree/bindings/iio/accel/bma180.txt
>> new file mode 100644
>> index 000..c593357
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/accel/bma180.txt
>> @@ -0,0 +1,24 @@
>> +* Bosch BMA180 triaxial acceleration sensor
>> +
>> +http://omapworld.com/BMA180_111_1002839.pdf
>> +
>> +Required properties:
>> +
>> + - compatible : should be "bosch,bma180"
>> + - reg : the I2C address of the sensor
>> +
>> +Optional properties:
>> +
>> + - interrupt-parent : should be the phandle for the interrupt controller
>> +
>> + - interrupts : interrupt mapping for GPIO IRQ, it should by configured
>> with
>> + flags IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING
>> +
>> +Example:
>> +
>> +bma180@40 {
>> + compatible = "bosch,bma180";
>> + reg = <0x40>;
>> + interrupt-parent = <&gpio6>;
>> + interrupts = <18 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING)>;
>> +};
>> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
>> index 719d83f..bd9d581 100644
>> --- a/drivers/iio/accel/Kconfig
>> +++ b/drivers/iio/accel/Kconfig
>> @@ -3,6 +3,18 @@
>> #
>> menu "Accelerometers"
>>
>> +config BMA180
>> + tristate "Bosch BMA180 3-Axis Accelerometer Driver"
>> + depends on I2C
>> + select IIO_BUFFER
>> + select IIO_TRIGGERED_BUFFER
>> + help
>> + Say Y here if you want to build a driver for the Bosch BMA180
>> + triaxial acceleration sensor.
>> +
>> + To compile this driver as a module, choose M here: the
>> + module will be called bma180.
>> +
>> confi
RE: [PATCH v8 0/2] TWL6030, TWL6032 GPADC driver
>On 08/15/13 13:59, Mark Rutland wrote:
>> On Thu, Aug 15, 2013 at 12:03:02PM +0100, Jonathan Cameron wrote:
>>>
>>>>> The changes to the original driver:
>>>>> - device tree adaptation;
>>>>
>>>> I couldn't see a binding document in this series or in mainline. Have I
>>>> looked in the wrong places?
>>>
>>> Nothing explicit supplied, but does it need one given it is doing only
>>> iio bindings (bindings/iio/iio-bindings.txt)
>>> plus twl child bindings
>>> (bindings/mfd/twl-family.txt)
>>
>> Every binding needs to be documented.
>>
>>>
>>> If it does, I guess absolutely everything does, then fair enough!
>>> I guess that would make sense as there is no way for someone writing
>>> a device tree to know that there is nothing else to be specified.
>>
>> Yup, that's why. Also, Linux isn't necessarily the only consumer, and
>> other consumers shouldn't need to read Linux code to figure out how a
>> particular binding is supposed to look.
>>
>Fair enough. Thanks for clearing that up.
>
>Oleksandr, could you send a follow up patch adding the required documentation?
>(mostly a cut and paste job from similar elements by the look of it).
>
Hello,
Is this good enough?
>From 211e81ff4a146d9ec27443696a429e795c58dc30 Mon Sep 17 00:00:00 2001
From: Oleksandr Kozaruk
Date: Thu, 15 Aug 2013 16:14:11 +0300
Subject: [PATCH] iio: adc: Add bindigs documentation for twl6030 GPADC
Add required documentation for twl6030 GPADC device tree
bindings.
Signed-off-by: Oleksandr Kozaruk
---
.../devicetree/bindings/iio/adc/twl6030-gpadc.txt | 14 ++
1 file changed, 14 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/twl6030-gpadc.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/twl6030-gpadc.txt
b/Documentation/devicetree/bindings/iio/adc/twl6030-gpadc.txt
new file mode 100644
index 000..6829420
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/twl6030-gpadc.txt
@@ -0,0 +1,14 @@
+Texas Instruments twl6030/twl6032 GPADC device driver
+
+Required properties:
+ - compatible: must be "ti,twl6030-gpadc" for TWL6030 or
+ "ti,twl6032-gpadc" for TWL6032
+ - interrupts: interrupt number associated with it
+ - #io-channel-cells: must be <1> - multiple IIO outputs
+
+Example:
+ adc {
+ compatible = "ti,twl6030-gpadc";
+ interrupts = <3>;
+ #io-channel-cells = <1>;
+ };
--
1.8.1.2
--
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: add Bosch BMA180 acceleration sensor driver
On Thu, Aug 15, 2013 at 8:57 PM, Jonathan Cameron wrote: > On 08/15/13 14:41, Oleksandr Kravchenko wrote: >> On Thu, Aug 15, 2013 at 1:22 PM, Jonathan Cameron wrote: >>> On 08/13/13 16:44, Oleksandr Kravchenko wrote: >>>> This patch adds IIO driver for Bosch BMA180 triaxial >>>> acceleration sensor. >>>> http://dlnmh9ip6v2uc.cloudfront.net/datasheets/ >>>> Sensors/Accelerometers/BST-BMA180-DS000-07_2.pdf >>>> >>>> Signed-off-by: Oleksandr Kravchenko >>> Hi, >>> >>> Firstly, just a thought (I haven't made up my mind whether it is a good >>> idea or >>> not!) but you could use devm_kzalloc for data->buff and hence avoid having >>> to care about freeing it in the remove function. Update scan mode isn't >>> a particularly fast path so I doubt the small overhead will matter. >> Thanks, it is a good idea. >> >>> >>> Otherwise, the abi additions need documenting iff they don't fit within >>> existing ABI. If they do then they need to match existing ABI. >>> >>> Of those, 'mode' is rather device specific and could probably do with >>> a more detailed name. The only 'generic' way to do it would be to make the >>> channel type attributes writable and treat it as a resolution control rather >>> than a noise/power trade off. Uggly though so perhaps what you have makes >>> sense. We can always add a more generic way of controlling this if it >>> starts turning up in lots of devices (keeping this method of course to avoid >>> breaking ABI). >> Ok, I'll change 'mode' to 'power_mode' and document it in ABI. Can I use ext_info and iio_chan_spec_ext_info to provide my "power_mode" in my driver like "powerdown_mode" in some other drivers? >>> >>> 'bandwidth' is already (I think) covered by the ABI. For the bandwidth >>> optoins you have enabled we are talking low pass >>> filters and presumably their 3db point. >>> In Documentation/ABI/testing/sysfs-bus-iio you will find >>> in_accel_filter_low_pass_3db_frequency. My filter theory is >>> rather rusty (not sure it was >>> every anything else ;). Hence I'm not entirely sure how to work >>> out the 3db frequency from the 'pole frequency' if they are not infact >>> the same thing.. >> You are right. In my case 'bandwidth' is low path filter. I'll change my >> driver >> accordingly. But how can I declare available values? >> If I do it in next way: >> static IIO_CONST_ATTR(in_accel0_filter_low_pass_3db_frequency_available, >> BMA180_BW_AVAILABLE); > Not shared across all channels? If it is then > in_accel_filter_low_pass_3db_frequency_available it is... >> it will lock so ugly in the code and sysfs... > > yeah. There are plans to clean that sort of thing up. I keep mentioning > them > and never getting them done though. > > In brief drivers will be able to provide and additional callback > which will then return pointers to arrays containing all the numbers to > specify the 'range' of values any parameter in info_mask can take > (note this includes the raw and processed values as well as the other bits). > > I sketch out how we could do this from time to time and dont' quite get > around to > doing it. >> >>> >>> Otherwise, the driver looks good to me. >>> >>> Jonathan >>>> --- >>>> .../devicetree/bindings/iio/accel/bma180.txt | 24 + >>>> drivers/iio/accel/Kconfig | 12 + >>>> drivers/iio/accel/Makefile |2 + >>>> drivers/iio/accel/bma180.c | 689 >>>> >>>> 4 files changed, 727 insertions(+) >>>> create mode 100644 Documentation/devicetree/bindings/iio/accel/bma180.txt >>>> create mode 100644 drivers/iio/accel/bma180.c >>>> >>>> diff --git a/Documentation/devicetree/bindings/iio/accel/bma180.txt >>>> b/Documentation/devicetree/bindings/iio/accel/bma180.txt >>>> new file mode 100644 >>>> index 000..c593357 >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/iio/accel/bma180.txt >>>> @@ -0,0 +1,24 @@ >>>> +* Bosch BMA180 triaxial acceleration sensor >>>> + >>>> +http://omapworld.com/BMA180_111_1002839.pdf >>>> + >>>> +Required propert
[PATCH v4 1/2] staging: iio: Documentation sysfs-bus-iio add power_mode
Add description about in_accelX_power_mode and in_accel_power_mode_available. Signed-off-by: Oleksandr Kravchenko --- Documentation/ABI/testing/sysfs-bus-iio | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index dda81ff..1a333f3 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -792,3 +792,13 @@ Contact: linux-...@vger.kernel.org Description: This attribute is used to read the amount of quadrature error present in the device at a given time. + +What: /sys/.../iio:deviceX/in_accelX_power_mode +KernelVersion: 3.11 +Contact: linux-...@vger.kernel.org +Description: + Specifies the chip power mode. + low_noise: reduce noise level from ADC, + low_power: enable low current consumption. + For a list of available output power modes read + in_accel_power_mode_available. -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/2] iio: add Bosch BMA180 acceleration sensor driver
This patch adds IIO driver for Bosch BMA180 triaxial
acceleration sensor.
http://dlnmh9ip6v2uc.cloudfront.net/datasheets/
Sensors/Accelerometers/BST-BMA180-DS000-07_2.pdf
Signed-off-by: Oleksandr Kravchenko
---
.../devicetree/bindings/iio/accel/bma180.txt | 24 +
drivers/iio/accel/Kconfig | 12 +
drivers/iio/accel/Makefile |2 +
drivers/iio/accel/bma180.c | 676
4 files changed, 714 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/accel/bma180.txt
create mode 100644 drivers/iio/accel/bma180.c
diff --git a/Documentation/devicetree/bindings/iio/accel/bma180.txt
b/Documentation/devicetree/bindings/iio/accel/bma180.txt
new file mode 100644
index 000..c593357
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/accel/bma180.txt
@@ -0,0 +1,24 @@
+* Bosch BMA180 triaxial acceleration sensor
+
+http://omapworld.com/BMA180_111_1002839.pdf
+
+Required properties:
+
+ - compatible : should be "bosch,bma180"
+ - reg : the I2C address of the sensor
+
+Optional properties:
+
+ - interrupt-parent : should be the phandle for the interrupt controller
+
+ - interrupts : interrupt mapping for GPIO IRQ, it should by configured with
+ flags IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING
+
+Example:
+
+bma180@40 {
+ compatible = "bosch,bma180";
+ reg = <0x40>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <18 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING)>;
+};
diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
index 719d83f..bd9d581 100644
--- a/drivers/iio/accel/Kconfig
+++ b/drivers/iio/accel/Kconfig
@@ -3,6 +3,18 @@
#
menu "Accelerometers"
+config BMA180
+ tristate "Bosch BMA180 3-Axis Accelerometer Driver"
+ depends on I2C
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ help
+ Say Y here if you want to build a driver for the Bosch BMA180
+ triaxial acceleration sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called bma180.
+
config HID_SENSOR_ACCEL_3D
depends on HID_SENSOR_HUB
select IIO_BUFFER
diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
index 87d8fa2..eb09d72 100644
--- a/drivers/iio/accel/Makefile
+++ b/drivers/iio/accel/Makefile
@@ -2,6 +2,8 @@
# Makefile for industrial I/O accelerometer drivers
#
+obj-$(CONFIG_BMA180) += bma180.o
+
obj-$(CONFIG_HID_SENSOR_ACCEL_3D) += hid-sensor-accel-3d.o
obj-$(CONFIG_IIO_ST_ACCEL_3AXIS) += st_accel.o
diff --git a/drivers/iio/accel/bma180.c b/drivers/iio/accel/bma180.c
new file mode 100644
index 000..ae15580
--- /dev/null
+++ b/drivers/iio/accel/bma180.c
@@ -0,0 +1,676 @@
+/*
+ * bma180.c - IIO driver for Bosch BMA180 triaxial acceleration sensor
+ *
+ * Copyright 2013 Oleksandr Kravchenko
+ *
+ * This file is subject to the terms and conditions of version 2 of
+ * the GNU General Public License. See the file COPYING in the main
+ * directory of this archive for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define BMA180_DRV_NAME "bma180"
+#define BMA180_IRQ_NAME "bma180_event"
+
+/* Register set */
+#define BMA180_CHIP_ID 0x00 /* Need to distinguish BMA180 from other */
+#define BMA180_ACC_X_LSB 0x02 /* First of 6 registers of accel data */
+#define BMA180_CTRL_REG0 0x0d
+#define BMA180_RESET 0x10
+#define BMA180_BW_TCS 0x20
+#define BMA180_CTRL_REG3 0x21
+#define BMA180_TCO_Z 0x30
+#define BMA180_OFFSET_LSB1 0x35
+
+/* BMA180_CTRL_REG0 bits */
+#define BMA180_DIS_WAKE_UP BIT(0) /* Disable wake up mode */
+#define BMA180_SLEEP BIT(1) /* 1 - chip will sleep */
+#define BMA180_EE_WBIT(4) /* Unlock writing to addr from 0x20 */
+#define BMA180_RESET_INT BIT(6) /* Reset pending interrupts */
+
+/* BMA180_CTRL_REG3 bits */
+#define BMA180_NEW_DATA_INTBIT(1) /* Intr every new accel data is ready */
+
+/* BMA180_OFFSET_LSB1 skipping mode bit */
+#define BMA180_SMP_SKIPBIT(0)
+
+/* Bit masks for registers bit fields */
+#define BMA180_RANGE 0x0e /* Range of measured accel values*/
+#define BMA180_BW 0xf0 /* Accel bandwidth */
+#define BMA180_MODE_CONFIG 0x03 /* Config operation modes */
+
+/* We have to write this value in reset register to do soft reset */
+#define BMA180_RESET_VAL 0xb6
+
+#define BMA_180_ID_REG_VAL 0x03
+
+/* Chip power modes */
+#define BMA180_LOW_NOISE 0x00
+#define BMA180_LOW_POWER 0x03
+
+#define BMA180_LOW_NOISE_STR "low_noise"
+#define BMA180_LOW_POWER_STR "low_power"
+
+/* Defaults values */
+#
[PATCH] iio: adc: twl6030-gpadc: Use devm_* API family
Using devm_iio_device_alloc and devm_request_threaded_irq makes
code simpler.
Signed-off-by: Oleksandr Kozaruk
---
drivers/iio/adc/twl6030-gpadc.c | 36 ++--
1 file changed, 10 insertions(+), 26 deletions(-)
diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c
index a80a049..a558516 100644
--- a/drivers/iio/adc/twl6030-gpadc.c
+++ b/drivers/iio/adc/twl6030-gpadc.c
@@ -893,11 +893,9 @@ static int twl6030_gpadc_probe(struct platform_device
*pdev)
pdata = match->data;
- indio_dev = iio_device_alloc(sizeof(*gpadc));
- if (!indio_dev) {
- dev_err(dev, "failed allocating iio device\n");
- ret = -ENOMEM;
- }
+ indio_dev = devm_iio_device_alloc(dev, sizeof(*gpadc));
+ if (!indio_dev)
+ return -ENOMEM;
gpadc = iio_priv(indio_dev);
@@ -905,7 +903,7 @@ static int twl6030_gpadc_probe(struct platform_device *pdev)
sizeof(*gpadc->twl6030_cal_tbl) *
pdata->nchannels, GFP_KERNEL);
if (!gpadc->twl6030_cal_tbl)
- goto err_free_device;
+ return -ENOMEM;
gpadc->dev = dev;
gpadc->pdata = pdata;
@@ -917,33 +915,30 @@ static int twl6030_gpadc_probe(struct platform_device
*pdev)
ret = pdata->calibrate(gpadc);
if (ret < 0) {
dev_err(&pdev->dev, "failed to read calibration registers\n");
- goto err_free_device;
+ return ret;
}
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
dev_err(&pdev->dev, "failed to get irq\n");
- goto err_free_device;
+ return irq;
}
- ret = request_threaded_irq(irq, NULL, twl6030_gpadc_irq_handler,
+ ret = devm_request_threaded_irq(dev, irq, NULL,
+ twl6030_gpadc_irq_handler,
IRQF_ONESHOT, "twl6030_gpadc", indio_dev);
- if (ret) {
- dev_dbg(&pdev->dev, "could not request irq\n");
- goto err_free_device;
- }
ret = twl6030_gpadc_enable_irq(TWL6030_GPADC_RT_SW1_EOC_MASK);
if (ret < 0) {
dev_err(&pdev->dev, "failed to enable GPADC interrupt\n");
- goto err_free_irq;
+ return ret;
}
ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCS,
TWL6030_REG_TOGGLE1);
if (ret < 0) {
dev_err(&pdev->dev, "failed to enable GPADC module\n");
- goto err_free_irq;
+ return ret;
}
indio_dev->name = DRIVER_NAME;
@@ -954,15 +949,6 @@ static int twl6030_gpadc_probe(struct platform_device
*pdev)
indio_dev->num_channels = pdata->nchannels;
ret = iio_device_register(indio_dev);
- if (ret)
- goto err_free_irq;
-
- return ret;
-
-err_free_irq:
- free_irq(irq, indio_dev);
-err_free_device:
- iio_device_free(indio_dev);
return ret;
}
@@ -972,9 +958,7 @@ static int twl6030_gpadc_remove(struct platform_device
*pdev)
struct iio_dev *indio_dev = platform_get_drvdata(pdev);
twl6030_gpadc_disable_irq(TWL6030_GPADC_RT_SW1_EOC_MASK);
- free_irq(platform_get_irq(pdev, 0), indio_dev);
iio_device_unregister(indio_dev);
- iio_device_free(indio_dev);
return 0;
}
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] iio: adc: Add bindigs documentation for twl6030 GPADC
Add required documentation for twl6030 GPADC device tree
bindings.
Signed-off-by: Oleksandr Kozaruk
---
.../devicetree/bindings/iio/adc/twl6030-gpadc.txt | 45 ++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/twl6030-gpadc.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/twl6030-gpadc.txt
b/Documentation/devicetree/bindings/iio/adc/twl6030-gpadc.txt
new file mode 100644
index 000..6cd3ef3
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/twl6030-gpadc.txt
@@ -0,0 +1,45 @@
+Texas Instruments twl6030/twl6032 GPADC device driver
+
+Required properties:
+ - compatible: must be "ti,twl6030-gpadc" for TWL6030 or
+ "ti,twl6032-gpadc" for TWL6032
+ - interrupts: interrupt number associated with it
+ - #io-channel-cells: must be <1> - multiple IIO outputs are present
+ iio consumers can use following io-channels:
+ twl6030:
+ 0 - battery type
+ 1 - battery temperature resistor value
+ 2 - audio accessory/general purpose
+ 3 - general purpose
+ 4 - temperature/general purpose
+ 5 - general purpose
+ 6 - general purpose
+ 7 - main battery
+ 8 - backup battery
+ 9 - charger input
+ 10 - VBUS
+ 11 - VBUS charging current
+ 14 - USB ID
+ twl6032:
+ 0 - battery type
+ 1 - battery temperature resistor value
+ 2 - audio accessory/general purpose
+ 3 - temperature with external diode/general purpose
+ 4 - temperature/general purpose
+ 5 - general purpose
+ 6 - general purpose
+ 7 - system supply
+ 8 - backup battery
+ 9 - charger input
+ 10 - VBUS
+ 11 - VBUS charging current
+ 14 - USB ID
+ 17 - battery charging current
+ 18 - battery voltage
+
+Example:
+ adc {
+ compatible = "ti,twl6030-gpadc";
+ interrupts = <3>;
+ #io-channel-cells = <1>;
+ };
--
1.8.1.2
--
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] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
Hello Lars-Peter,
Thank you for the review.
>> diff --git a/drivers/iio/adc/twl6030-gpadc.c
>> b/drivers/iio/adc/twl6030-gpadc.c
>> new file mode 100644
>> index 000..6ceb789
>> --- /dev/null
>> +++ b/drivers/iio/adc/twl6030-gpadc.c
>> @@ -0,0 +1,1019 @@
>[...]
>> +static u8 twl6032_channel_to_reg(int channel)
>> +{
>> + return TWL6032_GPADC_GPCH0_LSB;
>
>There is more than one channel, isn't there?
Yes. But for twl6032 channel of interest is chosen first. When the conversion
is ready tre result is available in GPCH0_LSB/GPCH1_MSB for any cosen
channel. For twl6030 there are as many result register pairs as many of
channels.
>> + ret = devm_request_threaded_irq(dev, irq, NULL,
>> + twl6030_gpadc_irq_handler,
>> + IRQF_ONESHOT, "twl6030_gpadc", gpadc);
>
>You access memory in the interrupt handler which is freed before the interrupt
>handler is freed.
Thanks for pointing this. devm_* will free memory for irq after the driver
is removed and memory for the device is freed. I took me awhile to understand
this. Is there going to be something like devm_iio_device_alloc? whould it be
helpfull?--
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] iio: add APDS9300 ambilent light sensor driver
Thank you for review! But I don't completely understand one of your comment:
>> +static int als_probe(struct i2c_client *client, const struct i2c_device_id
>> *id)
[...]
>> + if (client->irq) {
>> + ret = devm_request_threaded_irq(&client->dev, client->irq,
>> + NULL, als_interrupt_handler,
>> + IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
>> + ALS_IRQ_NAME, indio_dev);
>
> This is a bit racy, you access memory in the irq handler that is freed
> before the irq is freed.
Do you mean than that indio_dev may be used in interrupt handler after
iio_device_free(indio_dev) called in als_remove() function?
If so, can I use disable_irq() in als_remove() before iio_device_free()
to avoid this problem?
On Fri, Jul 12, 2013 at 8:04 PM, Lars-Peter Clausen wrote:
> On 07/10/2013 03:08 PM, Oleksandr Kravchenko wrote:
>> From: Oleksandr Kravchenko
>>
>> This patch adds IIO driver for APDS9300 ambilent light sensor (ALS).
>
> s/ambilent/ambient/
>
>> http://www.avagotech.com/docs/AV02-1077EN
>>
>> The driver allows to read raw data from ADC registers or calculate
>> lux value. It also can handle threshold inrerrupt.
>
> s/inrerrupt/interrupt/
>
> The patch looks very good in general, a couple of comment inline.
>
>>
>> Signed-off-by: Oleksandr Kravchenko
>> ---
>> .../devicetree/bindings/iio/light/apds9300.txt | 22 +
>> drivers/iio/light/Kconfig | 10 +
>> drivers/iio/light/Makefile |1 +
>> drivers/iio/light/apds9300.c | 528
>>
>> 4 files changed, 561 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/iio/light/apds9300.txt
>> create mode 100644 drivers/iio/light/apds9300.c
>>
>> diff --git a/Documentation/devicetree/bindings/iio/light/apds9300.txt
>> b/Documentation/devicetree/bindings/iio/light/apds9300.txt
>> new file mode 100644
>> index 000..d6f66c7
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/light/apds9300.txt
>> @@ -0,0 +1,22 @@
>> +* Avago APDS9300 ambient light sensor
>> +
>> +http://www.avagotech.com/docs/AV02-1077EN
>> +
>> +Required properties:
>> +
>> + - compatible : should be "avago,apds9300"
>
> You should also add the avago vendor prefix to
> Documentation/devicetree/bindings/vendor-prefixes.txt. Preferably in a
> separate patch.
>
>> + - reg : the I2C address of the sensor
>> +
>> +Optional properties:
>> +
>> + - interrupt-parent : should be the phandle for the interrupt controller
>> + - interrupts : interrupt mapping for GPIO IRQ
>> +
>> +Example:
>> +
>> +apds9300@39 {
>> + compatible = "avago,apds9300";
>> + reg = <0x39>;
>> + interrupt-parent = <&gpio2>;
>> + interrupts = <29 8>;
>> +};
>> diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
>> index 5ef1a39..08a6742 100644
>> --- a/drivers/iio/light/Kconfig
>> +++ b/drivers/iio/light/Kconfig
>> @@ -52,6 +52,16 @@ config VCNL4000
>>To compile this driver as a module, choose M here: the
>>module will be called vcnl4000.
>>
>> +config APDS9300
>> + tristate "APDS9300 ambient light sensor"
>> + depends on I2C
>> + help
>> + Say Y here if you want to build a driver for the Avago APDS9300
>> + ambient light sensor.
>> +
>> + To compile this driver as a module, choose M here: the
>> + module will be called apds9300.
>> +
>
> Keeps this in alphabetical order
>
>> config HID_SENSOR_ALS
>> depends on HID_SENSOR_HUB
>> select IIO_BUFFER
>> diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
>> index 040d9c7..da58e12 100644
>> --- a/drivers/iio/light/Makefile
>> +++ b/drivers/iio/light/Makefile
>> @@ -6,4 +6,5 @@ obj-$(CONFIG_ADJD_S311) += adjd_s311.o
>> obj-$(CONFIG_SENSORS_LM3533) += lm3533-als.o
>> obj-$(CONFIG_SENSORS_TSL2563)+= tsl2563.o
>> obj-$(CONFIG_VCNL4000) += vcnl4000.o
>> +obj-$(CONFIG_APDS9300) += apds9300.o
>
> Same here
>
>> obj-$(CONFIG_HID_SENSOR_ALS) += hid-sensor-als.o
>> diff --git a/drivers/iio/light/apds9300.c b/drivers/iio/light/apds9300.c
>> new file mode 100644
>> index 000..2275ecc
>> --- /dev/null
>> +++ b/drivers/iio/light/apds9300.c
>
RE: [PATCH v3 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
Hello Jonathan,
Thanks for the review.
>Couple of things:
>
>1) It looks from the driver that a lot of the channels are not measuring
>voltages but rather temperature or currents etc. If so then their
>types in the channel mask should be appropriately set. Also if some
>of the channels are entirely internal test networks, what is the benefit
>of exposing them to userspace as readable channels?
>If channels are merely 'suggested' as being used for temperatures etc
>then it is fine to keep them as voltages.
There are two kinds of channel for measuring temperature: die temperature
and those that measure temperature indirectly measuring voltage on resistive
load(NTC sensor).
die temperature is calculated by some formulas which convert ADC code to
temperature. This is not implemented in the driver.
Channels intended to measure temperature with NTC sensor have inbuilt current
sources. Voltage measured by this channels and specific NTC could be converted
to temperature.
This is the reason they chosen to be voltage channels.
As for test network I'll remove them from exposing to userspace.
[...]
>> +static int twl6030_gpadc_get_raw(struct twl6030_gpadc_data *gpadc,
>> + int channel, int *res)
>> +{
>> + u8 reg = gpadc->pdata->channel_to_reg(channel);
>> + u8 val[2];
>
>le16 val;
>> + int ret;
>> +
>ret = twl6030_gpadc_read(val, reg);
>(note that (reg, val) ordering of parameters would be a more common choice)
>
>> + ret = twl6030_gpadc_read(val, reg);
>> + if (ret) {
>> + dev_dbg(gpadc->dev, "unable to read register 0x%X\n", reg);
>> + return ret;
>> + }
>> +
>res = le16_to_cpup(val);
>
>> + *res = (val[1] << 8) | val[0];
>> +
>> + return ret;
>> +}
>> +
You mean something like this:
static int twl6030_gpadc_get_raw(struct twl6030_gpadc_data *gpadc,
int channel, int *res)
{
u8 reg = gpadc->pdata->channel_to_reg(channel);
__le16 val;
int ret;
ret = twl6030_gpadc_read(reg, (u8 *)&val);
if (ret) {
dev_dbg(gpadc->dev, "unable to read register 0x%X\n", reg);
return ret;
}
*res = le16_to_cpup(&val);
return ret;
}
Note, that twl6030_gpadc_read() is just wrapper for twl_i2c_read() which takes
"an array of num_bytes containing data to be read"
I like the original implementation better then this(if I did it correctly)
Do you insist on this change?
[...]
>> +static int twl6030_gpadc_get_processed(struct twl6030_gpadc_data *gpadc,
>> + int channel, int *val)
>> +{
>> + int raw_code;
>>
Re: [PATCH] iio: add APDS9300 ambilent light sensor driver
I can't to find devm_iio_device_alloc() in my kernel v3.11-rc1
On Mon, Jul 15, 2013 at 3:35 PM, Lars-Peter Clausen wrote:
> On 07/15/2013 02:27 PM, Oleksandr Kravchenko wrote:
>> Thank you for review! But I don't completely understand one of your comment:
>>
>>>> +static int als_probe(struct i2c_client *client, const struct
>>>> i2c_device_id *id)
>> [...]
>>>> + if (client->irq) {
>>>> + ret = devm_request_threaded_irq(&client->dev, client->irq,
>>>> + NULL, als_interrupt_handler,
>>>> + IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
>>>> + ALS_IRQ_NAME, indio_dev);
>>>
>>> This is a bit racy, you access memory in the irq handler that is freed
>>> before the irq is freed.
>>
>> Do you mean than that indio_dev may be used in interrupt handler after
>> iio_device_free(indio_dev) called in als_remove() function?
>>
>> If so, can I use disable_irq() in als_remove() before iio_device_free()
>> to avoid this problem?
>>
>
> Just add a devm_iio_device_alloc() and use that, instead of trying to bodch
> around the issue.
>
--
Oleksandr Kravchenko
GlobalLogic
P +380633213187
P +380994930248
www.globallogic.com
http://www.globallogic.com/email_disclaimer.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC, known also as Phoenix and PhoenixLite. The TWL6030 and TWL6032 have GPADC with 17 and 19 channels respectively. Some channels have current source and are used for measuring voltage drop on resistive load for detecting battery ID resistance, or measuring voltage drop on NTC resistors for external temperature measurements. Some channels measure voltage, (i.e. battery voltage), and have voltage dividers, thus, capable to scale voltage. Some channels are dedicated for measuring die temperature. Some channels are calibrated in 2 points, having offsets from ideal values kept in trim registers. This is used to correct measurements. The differences between GPADC in TWL6030 and TWL6032: - 10 bit vs 12 bit ADC; - 17 vs 19 channels; - channels have different purpose(i.e. battery voltage channel 8 vs channel 18); - trim values are interpreted differently. Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K, Girish S Ghongdemath. Signed-off-by: Balaji T K Signed-off-by: Graeme Gregory Signed-off-by: Oleksandr Kozaruk --- drivers/iio/adc/Kconfig | 14 + drivers/iio/adc/Makefile|1 + drivers/iio/adc/twl6030-gpadc.c | 1008 +++ 3 files changed, 1023 insertions(+) create mode 100644 drivers/iio/adc/twl6030-gpadc.c diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index ab0767e6..3172461 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -150,6 +150,20 @@ config TI_AM335X_ADC Say yes here to build support for Texas Instruments ADC driver which is also a MFD client. +config TWL6030_GPADC + tristate "TWL6030 GPADC (General Purpose A/D Converter) Support" + depends on TWL4030_CORE + default n + help + Say yes here if you want support for the TWL6030/TWL6032 General + Purpose A/D Converter. This will add support for battery type + detection, battery voltage and temperature measurement, die + temperature measurement, system supply voltage, audio accessory, + USB ID detection. + + This driver can also be built as a module. If so, the module will be + called twl6030-gpadc. + config VIPERBOARD_ADC tristate "Viperboard ADC support" depends on MFD_VIPERBOARD && USB diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile index 0a825be..996ba09 100644 --- a/drivers/iio/adc/Makefile +++ b/drivers/iio/adc/Makefile @@ -16,4 +16,5 @@ obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o obj-$(CONFIG_MAX1363) += max1363.o obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o +obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c new file mode 100644 index 000..658f35b --- /dev/null +++ b/drivers/iio/adc/twl6030-gpadc.c @@ -0,0 +1,1008 @@ +/* + * TWL6030 GPADC module driver + * + * Copyright (C) 2009-2013 Texas Instruments Inc. + * Nishant Kamat + * Balaji T K + * Graeme Gregory + * Girish S Ghongdemath + * Ambresh K + * Oleksandr Kozaruk + * + * 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. + * + * 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. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DRIVER_NAME"twl6030_gpadc" + +#define TWL6030_GPADC_MAX_CHANNELS 17 +#define TWL6032_GPADC_MAX_CHANNELS 19 + +#define TWL6030_GPADC_CTRL_P1 0x05 + +#define TWL6032_GPADC_GPSELECT_ISB 0x07 +#define TWL6032_GPADC_CTRL_P1 0x08 + +#define TWL6032_GPADC_GPCH0_LSB0x0d +#define TWL6032_GPADC_GPCH0_MSB0x0e + +#define TWL6030_GPADC_CTRL_P1_SP1 BIT(3) + +#define TWL6030_GPADC_GPCH0_LSB(0x29) + +#define TWL6030_GPADC_RT_SW1_EOC_MASK BIT(5) + +#define TWL6030_GPADC_TRIM10xCD + +#define TWL6030_REG_TOGGLE10x90 +#define TWL6030_GPADCS BIT(1) +#define TWL6030_GPADCR BIT(0) + +/** + * struct twl6030_chnl_calib - channel calibration + * @gain: slope coefficient for ideal curve + * @gain_error:
[PATCH 1/2] ARM: dts: twl: Add GPADC data to device tree
GPADC is the general purpose ADC present on twl6030.
The dt data is interrupt used to trigger end of ADC
conversion.
Signed-off-by: Oleksandr Kozaruk
---
arch/arm/boot/dts/twl6030.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 2e3bd31..434842c 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -103,4 +103,10 @@
compatible = "ti,twl6030-pwmled";
#pwm-cells = <2>;
};
+
+ gpadc: twl6030_gpadc {
+ compatible = "ti,twl6030_gpadc";
+ interrupts = <3>;
+ #io-channel-cells = <1>;
+ };
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 0/2] TWL6030, TWL6032 GPADC driver
Hello, v4 - addressed comments: fixed style violation, bug in freeing memory, added comments explaining calibration method, removed test network channels from exposing to userspace, error handling for wait_for_complition v3 - fixed compiler warning v2 - the driver put in drivers/iio, and converted using iio facilities as suggested by Graeme. TWL603[02] GPADC is used to measure battery voltage, battery temperature, battery presence ID, and could be used to measure twl603[02] die temperature. This is used on TI blaze, blaze tablet platforms. The TWL6030/TWL6032 is a PMIC that has a GPADC with 17/19 channels respectively. Some channels have current source and are used for measuring voltage drop on resistive load for detecting battery ID resistance, or measuring voltage drop on NTC resistors for external temperature measurements, other channels measure voltage, (i.e. battery voltage), and have inbuilt voltage dividers, thus, capable to scale voltage. Some channels are dedicated for measuring die temperature. Some channels could be calibrated in 2 points, having offsets from ideal values in trim registers. The difference between GPADC in TWL6030 and TWL6032: - 10 bit vs 12 bit ADC; - 17 vs 19 channels; - channels have different purpose(i. e. battery voltage channel 8 vs channel 18); - trim values are interpreted differently. The driver is derived from git://git.omapzoom.org/kernel/omap.git The original driver's authors and contributors are Balaji T K, Graeme Gregory, Ambresh K, Girish S Ghongdemath. The changes to the original driver: - device tree adaptation; - drop ioctl support - never been used; - unified measurement method for both devices; - get rid of "if (device == X)" code style to data driven; - drop polling end of conversion and use interrupt instead; - iio framework is used Tested with on blaze tablet 2 with OMAP4430(twl6030), and OMAP4470(twl6032) SOMs. The patches were tested against 3.10-rc7 Oleksandr Kozaruk (2): ARM: dts: twl: Add GPADC data to device tree iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver arch/arm/boot/dts/twl6030.dtsi |6 + drivers/iio/adc/Kconfig | 14 + drivers/iio/adc/Makefile|1 + drivers/iio/adc/twl6030-gpadc.c | 1008 +++ 4 files changed, 1029 insertions(+) create mode 100644 drivers/iio/adc/twl6030-gpadc.c -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC, known also as Phoenix and PhoenixLite. The TWL6030 and TWL6032 have GPADC with 17 and 19 channels respectively. Some channels have current source and are used for measuring voltage drop on resistive load for detecting battery ID resistance, or measuring voltage drop on NTC resistors for external temperature measurements. Some channels measure voltage, (i.e. battery voltage), and have voltage dividers, thus, capable to scale voltage. Some channels are dedicated for measuring die temperature. Some channels are calibrated in 2 points, having offsets from ideal values kept in trim registers. This is used to correct measurements. The differences between GPADC in TWL6030 and TWL6032: - 10 bit vs 12 bit ADC; - 17 vs 19 channels; - channels have different purpose(i.e. battery voltage channel 8 vs channel 18); - trim values are interpreted differently. Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K, Girish S Ghongdemath. Signed-off-by: Balaji T K Signed-off-by: Graeme Gregory Signed-off-by: Oleksandr Kozaruk --- drivers/iio/adc/Kconfig | 14 + drivers/iio/adc/Makefile|1 + drivers/iio/adc/twl6030-gpadc.c | 1008 +++ 3 files changed, 1023 insertions(+) create mode 100644 drivers/iio/adc/twl6030-gpadc.c diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index ab0767e6..3172461 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -150,6 +150,20 @@ config TI_AM335X_ADC Say yes here to build support for Texas Instruments ADC driver which is also a MFD client. +config TWL6030_GPADC + tristate "TWL6030 GPADC (General Purpose A/D Converter) Support" + depends on TWL4030_CORE + default n + help + Say yes here if you want support for the TWL6030/TWL6032 General + Purpose A/D Converter. This will add support for battery type + detection, battery voltage and temperature measurement, die + temperature measurement, system supply voltage, audio accessory, + USB ID detection. + + This driver can also be built as a module. If so, the module will be + called twl6030-gpadc. + config VIPERBOARD_ADC tristate "Viperboard ADC support" depends on MFD_VIPERBOARD && USB diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile index 0a825be..996ba09 100644 --- a/drivers/iio/adc/Makefile +++ b/drivers/iio/adc/Makefile @@ -16,4 +16,5 @@ obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o obj-$(CONFIG_MAX1363) += max1363.o obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o +obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c new file mode 100644 index 000..658f35b --- /dev/null +++ b/drivers/iio/adc/twl6030-gpadc.c @@ -0,0 +1,1008 @@ +/* + * TWL6030 GPADC module driver + * + * Copyright (C) 2009-2013 Texas Instruments Inc. + * Nishant Kamat + * Balaji T K + * Graeme Gregory + * Girish S Ghongdemath + * Ambresh K + * Oleksandr Kozaruk + * + * 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. + * + * 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. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DRIVER_NAME"twl6030_gpadc" + +#define TWL6030_GPADC_MAX_CHANNELS 17 +#define TWL6032_GPADC_MAX_CHANNELS 19 + +#define TWL6030_GPADC_CTRL_P1 0x05 + +#define TWL6032_GPADC_GPSELECT_ISB 0x07 +#define TWL6032_GPADC_CTRL_P1 0x08 + +#define TWL6032_GPADC_GPCH0_LSB0x0d +#define TWL6032_GPADC_GPCH0_MSB0x0e + +#define TWL6030_GPADC_CTRL_P1_SP1 BIT(3) + +#define TWL6030_GPADC_GPCH0_LSB(0x29) + +#define TWL6030_GPADC_RT_SW1_EOC_MASK BIT(5) + +#define TWL6030_GPADC_TRIM10xCD + +#define TWL6030_REG_TOGGLE10x90 +#define TWL6030_GPADCS BIT(1) +#define TWL6030_GPADCR BIT(0) + +/** + * struct twl6030_chnl_calib - channel calibration + * @gain: slope coefficient for ideal curve + * @gain_error:
[PATCH v4 1/2] ARM: dts: twl: Add GPADC data to device tree
GPADC is the general purpose ADC present on twl6030.
The dt data is interrupt used to trigger end of ADC
conversion.
Signed-off-by: Oleksandr Kozaruk
---
arch/arm/boot/dts/twl6030.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 2e3bd31..434842c 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -103,4 +103,10 @@
compatible = "ti,twl6030-pwmled";
#pwm-cells = <2>;
};
+
+ gpadc: twl6030_gpadc {
+ compatible = "ti,twl6030_gpadc";
+ interrupts = <3>;
+ #io-channel-cells = <1>;
+ };
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/2] ARM: dts: twl: Add GPADC data to device tree
GPADC is the general purpose ADC present on twl6030.
The dt data is interrupt used to trigger end of ADC
conversion.
Signed-off-by: Oleksandr Kozaruk
---
arch/arm/boot/dts/twl6030.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 2e3bd31..434842c 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -103,4 +103,10 @@
compatible = "ti,twl6030-pwmled";
#pwm-cells = <2>;
};
+
+ gpadc: twl6030_gpadc {
+ compatible = "ti,twl6030_gpadc";
+ interrupts = <3>;
+ #io-channel-cells = <1>;
+ };
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 0/2] TWL6030, TWL6032 GPADC driver
Hello, v4 - addressed comments: fixed style violation, bug in freeing memory, added comments explaining calibration method, removed test network channels from exposing to userspace, error handling for wait_for_complition v3 - fixed compiler warning v2 - the driver put in drivers/iio, and converted using iio facilities as suggested by Graeme. TWL603[02] GPADC is used to measure battery voltage, battery temperature, battery presence ID, and could be used to measure twl603[02] die temperature. This is used on TI blaze, blaze tablet platforms. The TWL6030/TWL6032 is a PMIC that has a GPADC with 17/19 channels respectively. Some channels have current source and are used for measuring voltage drop on resistive load for detecting battery ID resistance, or measuring voltage drop on NTC resistors for external temperature measurements, other channels measure voltage, (i.e. battery voltage), and have inbuilt voltage dividers, thus, capable to scale voltage. Some channels are dedicated for measuring die temperature. Some channels could be calibrated in 2 points, having offsets from ideal values in trim registers. The difference between GPADC in TWL6030 and TWL6032: - 10 bit vs 12 bit ADC; - 17 vs 19 channels; - channels have different purpose(i. e. battery voltage channel 8 vs channel 18); - trim values are interpreted differently. The driver is derived from git://git.omapzoom.org/kernel/omap.git The original driver's authors and contributors are Balaji T K, Graeme Gregory, Ambresh K, Girish S Ghongdemath. The changes to the original driver: - device tree adaptation; - drop ioctl support - never been used; - unified measurement method for both devices; - get rid of "if (device == X)" code style to data driven; - drop polling end of conversion and use interrupt instead; - iio framework is used Tested with on blaze tablet 2 with OMAP4430(twl6030), and OMAP4470(twl6032) SOMs. The patches were tested against 3.10-rc7 Oleksandr Kozaruk (2): ARM: dts: twl: Add GPADC data to device tree iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver arch/arm/boot/dts/twl6030.dtsi |6 + drivers/iio/adc/Kconfig | 14 + drivers/iio/adc/Makefile|1 + drivers/iio/adc/twl6030-gpadc.c | 1008 +++ 4 files changed, 1029 insertions(+) create mode 100644 drivers/iio/adc/twl6030-gpadc.c -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC, known also as Phoenix and PhoenixLite. The TWL6030 and TWL6032 have GPADC with 17 and 19 channels respectively. Some channels have current source and are used for measuring voltage drop on resistive load for detecting battery ID resistance, or measuring voltage drop on NTC resistors for external temperature measurements. Some channels measure voltage, (i.e. battery voltage), and have voltage dividers, thus, capable to scale voltage. Some channels are dedicated for measuring die temperature. Some channels are calibrated in 2 points, having offsets from ideal values kept in trim registers. This is used to correct measurements. The differences between GPADC in TWL6030 and TWL6032: - 10 bit vs 12 bit ADC; - 17 vs 19 channels; - channels have different purpose(i.e. battery voltage channel 8 vs channel 18); - trim values are interpreted differently. Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K, Girish S Ghongdemath. Signed-off-by: Balaji T K Signed-off-by: Graeme Gregory Signed-off-by: Oleksandr Kozaruk --- drivers/iio/adc/Kconfig | 14 + drivers/iio/adc/Makefile|1 + drivers/iio/adc/twl6030-gpadc.c | 1008 +++ 3 files changed, 1023 insertions(+) create mode 100644 drivers/iio/adc/twl6030-gpadc.c diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index ab0767e6..3172461 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -150,6 +150,20 @@ config TI_AM335X_ADC Say yes here to build support for Texas Instruments ADC driver which is also a MFD client. +config TWL6030_GPADC + tristate "TWL6030 GPADC (General Purpose A/D Converter) Support" + depends on TWL4030_CORE + default n + help + Say yes here if you want support for the TWL6030/TWL6032 General + Purpose A/D Converter. This will add support for battery type + detection, battery voltage and temperature measurement, die + temperature measurement, system supply voltage, audio accessory, + USB ID detection. + + This driver can also be built as a module. If so, the module will be + called twl6030-gpadc. + config VIPERBOARD_ADC tristate "Viperboard ADC support" depends on MFD_VIPERBOARD && USB diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile index 0a825be..996ba09 100644 --- a/drivers/iio/adc/Makefile +++ b/drivers/iio/adc/Makefile @@ -16,4 +16,5 @@ obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o obj-$(CONFIG_MAX1363) += max1363.o obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o +obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c new file mode 100644 index 000..658f35b --- /dev/null +++ b/drivers/iio/adc/twl6030-gpadc.c @@ -0,0 +1,1008 @@ +/* + * TWL6030 GPADC module driver + * + * Copyright (C) 2009-2013 Texas Instruments Inc. + * Nishant Kamat + * Balaji T K + * Graeme Gregory + * Girish S Ghongdemath + * Ambresh K + * Oleksandr Kozaruk + * + * 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. + * + * 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. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DRIVER_NAME"twl6030_gpadc" + +#define TWL6030_GPADC_MAX_CHANNELS 17 +#define TWL6032_GPADC_MAX_CHANNELS 19 + +#define TWL6030_GPADC_CTRL_P1 0x05 + +#define TWL6032_GPADC_GPSELECT_ISB 0x07 +#define TWL6032_GPADC_CTRL_P1 0x08 + +#define TWL6032_GPADC_GPCH0_LSB0x0d +#define TWL6032_GPADC_GPCH0_MSB0x0e + +#define TWL6030_GPADC_CTRL_P1_SP1 BIT(3) + +#define TWL6030_GPADC_GPCH0_LSB(0x29) + +#define TWL6030_GPADC_RT_SW1_EOC_MASK BIT(5) + +#define TWL6030_GPADC_TRIM10xCD + +#define TWL6030_REG_TOGGLE10x90 +#define TWL6030_GPADCS BIT(1) +#define TWL6030_GPADCR BIT(0) + +/** + * struct twl6030_chnl_calib - channel calibration + * @gain: slope coefficient for ideal curve + * @gain_error:
Re: [PATCH 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
Hello Jonathan, >Two very quick comments based on quick glance as it may be a while before I can do a full review. >We still have channels that are only usable for temperature being output to user space as voltage channels? Is the conversion so very hard? Can you please clarify what should return temperature channel for in_tempX_input (processed)? Is it voltage or Celsius degree? in_tempX_raw should return ADC code? Right? Regards, OK. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 1/2] ARM: dts: twl: Add GPADC data to device tree
GPADC is the general purpose ADC present on twl6030.
The dt data is interrupt used to trigger end of ADC
conversion.
Signed-off-by: Oleksandr Kozaruk
---
arch/arm/boot/dts/twl6030.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 2e3bd31..322aa8e 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -103,4 +103,10 @@
compatible = "ti,twl6030-pwmled";
#pwm-cells = <2>;
};
+
+ adc: twl6030_gpadc {
+ compatible = "ti,twl6030_gpadc";
+ interrupts = <3>;
+ #io-channel-cells = <1>;
+ };
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 0/2] TWL6030, TWL6032 GPADC driver
Hello, v5 - gpadc DT node renamed from "gpadc" to generic "adc", added temperature channels; raw code is corracted with calibration data. v4 - addressed comments: fixed style violation, bug in freeing memory, added comments explaining calibration method, removed test network channels from exposing to userspace, error handling for wait_for_complition v3 - fixed compiler warning v2 - the driver put in drivers/iio, and converted using iio facilities as suggested by Graeme. TWL603[02] GPADC is used to measure battery voltage, battery temperature, battery presence ID, and could be used to measure twl603[02] die temperature. This is used on TI blaze, blaze tablet platforms. The TWL6030/TWL6032 is a PMIC that has a GPADC with 17/19 channels respectively. Some channels have current source and are used for measuring voltage drop on resistive load for detecting battery ID resistance, or measuring voltage drop on NTC resistors for external temperature measurements, other channels measure voltage, (i.e. battery voltage), and have inbuilt voltage dividers, thus, capable to scale voltage. Some channels are dedicated for measuring die temperature. Some channels could be calibrated in 2 points, having offsets from ideal values in trim registers. The difference between GPADC in TWL6030 and TWL6032: - 10 bit vs 12 bit ADC; - 17 vs 19 channels; - channels have different purpose(i. e. battery voltage channel 8 vs channel 18); - trim values are interpreted differently. The driver is derived from git://git.omapzoom.org/kernel/omap.git The original driver's authors and contributors are Balaji T K, Graeme Gregory, Ambresh K, Girish S Ghongdemath. The changes to the original driver: - device tree adaptation; - drop ioctl support - never been used; - unified measurement method for both devices; - get rid of "if (device == X)" code style to data driven; - drop polling end of conversion and use interrupt instead; - iio framework is used Tested with on blaze tablet 2 with OMAP4430(twl6030), and OMAP4470(twl6032) SOMs. The patches were tested against 3.10-rc7 Oleksandr Kozaruk (2): ARM: dts: twl: Add GPADC data to device tree iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver arch/arm/boot/dts/twl6030.dtsi |6 + drivers/iio/adc/Kconfig | 14 + drivers/iio/adc/Makefile|1 + drivers/iio/adc/twl6030-gpadc.c | 1026 +++ 4 files changed, 1047 insertions(+) create mode 100644 drivers/iio/adc/twl6030-gpadc.c -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC, known also as Phoenix and PhoenixLite. The TWL6030 and TWL6032 have GPADC with 17 and 19 channels respectively. Some channels have current source and are used for measuring voltage drop on resistive load for detecting battery ID resistance, or measuring voltage drop on NTC resistors for external temperature measurements. Some channels measure voltage, (i.e. battery voltage), and have voltage dividers, thus, capable to scale voltage. Some channels are dedicated for measuring die temperature. Some channels are calibrated in 2 points, having offsets from ideal values kept in trim registers. This is used to correct measurements. The differences between GPADC in TWL6030 and TWL6032: - 10 bit vs 12 bit ADC; - 17 vs 19 channels; - channels have different purpose(i.e. battery voltage channel 8 vs channel 18); - trim values are interpreted differently. Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K, Girish S Ghongdemath. Signed-off-by: Balaji T K Signed-off-by: Graeme Gregory Signed-off-by: Oleksandr Kozaruk --- drivers/iio/adc/Kconfig | 14 + drivers/iio/adc/Makefile|1 + drivers/iio/adc/twl6030-gpadc.c | 1026 +++ 3 files changed, 1041 insertions(+) create mode 100644 drivers/iio/adc/twl6030-gpadc.c diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index ab0767e6..3172461 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -150,6 +150,20 @@ config TI_AM335X_ADC Say yes here to build support for Texas Instruments ADC driver which is also a MFD client. +config TWL6030_GPADC + tristate "TWL6030 GPADC (General Purpose A/D Converter) Support" + depends on TWL4030_CORE + default n + help + Say yes here if you want support for the TWL6030/TWL6032 General + Purpose A/D Converter. This will add support for battery type + detection, battery voltage and temperature measurement, die + temperature measurement, system supply voltage, audio accessory, + USB ID detection. + + This driver can also be built as a module. If so, the module will be + called twl6030-gpadc. + config VIPERBOARD_ADC tristate "Viperboard ADC support" depends on MFD_VIPERBOARD && USB diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile index 0a825be..996ba09 100644 --- a/drivers/iio/adc/Makefile +++ b/drivers/iio/adc/Makefile @@ -16,4 +16,5 @@ obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o obj-$(CONFIG_MAX1363) += max1363.o obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o +obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c new file mode 100644 index 000..97fad5b --- /dev/null +++ b/drivers/iio/adc/twl6030-gpadc.c @@ -0,0 +1,1026 @@ +/* + * TWL6030 GPADC module driver + * + * Copyright (C) 2009-2013 Texas Instruments Inc. + * Nishant Kamat + * Balaji T K + * Graeme Gregory + * Girish S Ghongdemath + * Ambresh K + * Oleksandr Kozaruk + * + * 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. + * + * 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. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DRIVER_NAME"twl6030_gpadc" + +#define TWL6030_GPADC_MAX_CHANNELS 17 +#define TWL6032_GPADC_MAX_CHANNELS 19 + +#define TWL6030_GPADC_CTRL_P1 0x05 + +#define TWL6032_GPADC_GPSELECT_ISB 0x07 +#define TWL6032_GPADC_CTRL_P1 0x08 + +#define TWL6032_GPADC_GPCH0_LSB0x0d +#define TWL6032_GPADC_GPCH0_MSB0x0e + +#define TWL6030_GPADC_CTRL_P1_SP1 BIT(3) + +#define TWL6030_GPADC_GPCH0_LSB(0x29) + +#define TWL6030_GPADC_RT_SW1_EOC_MASK BIT(5) + +#define TWL6030_GPADC_TRIM10xCD + +#define TWL6030_REG_TOGGLE10x90 +#define TWL6030_GPADCS BIT(1) +#define TWL6030_GPADCR BIT(0) + +/** + * struct twl6030_chnl_calib - channel calibration + * @gain: slope coefficient for ideal curve + * @gain_error:
Re: [PATCH v3 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
On Mon, Jul 15, 2013 at 01:33:53PM +0200, Lars-Peter Clausen wrote:
> On 07/15/2013 01:09 PM, Kozaruk, Oleksandr wrote:
> [...]
> >
> >>> + ret = devm_request_threaded_irq(dev, irq, NULL,
> >>> + twl6030_gpadc_irq_handler,
> >>> + IRQF_ONESHOT, "twl6030_gpadc", gpadc);
> >>
> >> You access memory in the interrupt handler which is freed before
the interrupt
> >> handler is freed.
> > Thanks for pointing this. devm_* will free memory for irq after the
driver
> > is removed and memory for the device is freed. I took me awhile to
understand
> > this. Is there going to be something like devm_iio_device_alloc?
whould it be helpfull?
> >
>
> Yes, I think it certainly makes sense to add a
devm_iio_device_alloc(), care
> to send a patch?
Anything like this? (of course it's not a patch)
struct iio_dev *devm_iio_device_alloc(struct device *dev, int sizeof_priv)
{
struct iio_dev *indio_dev;
size_t alloc_size;
alloc_size = sizeof(struct iio_dev);
if (sizeof_priv) {
alloc_size = ALIGN(alloc_size, IIO_ALIGN);
alloc_size += sizeof_priv;
}
/* ensure 32-byte alignment of whole construct ? */
alloc_size += IIO_ALIGN - 1;
indio_dev = devm_kzalloc(dev, alloc_size, GFP_KERNEL);
if (indio_dev) {
indio_dev->dev.groups = indio_dev->groups;
indio_dev->dev.type = &iio_device_type;
indio_dev->dev.bus = &iio_bus_type;
device_initialize(&indio_dev->dev);
dev_set_drvdata(&indio_dev->dev, (void *)indio_dev);
mutex_init(&indio_dev->mlock);
mutex_init(&indio_dev->info_exist_lock);
INIT_LIST_HEAD(&indio_dev->channel_attr_list);
indio_dev->id = ida_simple_get(&iio_ida, 0, 0, GFP_KERNEL);
if (indio_dev->id < 0) {
/* cannot use a dev_err as the name isn't available */
printk(KERN_ERR "Failed to get id\n");
kfree(dev);
return NULL;
}
dev_set_name(&indio_dev->dev, "iio:device%d", indio_dev->id);
INIT_LIST_HEAD(&indio_dev->buffer_list);
}
return indio_dev;
}
EXPORT_SYMBOL(devm_iio_device_alloc);
Regards,
OK
--
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] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
Hello Lars,
On Wed, Jul 17, 2013 at 9:04 PM, Lars-Peter Clausen wrote:
>> +static int twl6032_calibration(struct twl6030_gpadc_data *gpadc)
>> +{
>> + int chn, d1 = 0, d2 = 0, temp;
>> + u8 trim_regs[17];
>> + int ret;
>> +
>> + ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs + 1,
>> + TWL6030_GPADC_TRIM1, 16);
>> + if (ret < 0) {
>> + dev_err(gpadc->dev, "calibration failed\n");
>> + return ret;
>> + }
>> +
>> + /*
>> + * Loop to calculate the value needed for returning voltages from
>> + * GPADC not values.
>> + *
>> + * gain is calculated to 3 decimal places fixed point.
>> + */
>> + for (chn = 0; chn < TWL6032_GPADC_MAX_CHANNELS; chn++) {
>> +
>> + switch (chn) {
>> + case 0:
>> + case 1:
>> + case 2:
>> + case 3:
>> + case 4:
>> + case 5:
>> + case 6:
>> + case 11:
>> + case 12:
>> + case 13:
>> + case 14:
>> + /* D1 */
>> + d1 = (trim_regs[3] & 0x1F) << 2;
>> + d1 |= (trim_regs[1] & 0x06) >> 1;
>> + if (trim_regs[1] & 0x01)
>> + d1 = -d1;
>> +
>> + /* D2 */
>> + d2 = (trim_regs[4] & 0x3F) << 2;
>> + d2 |= (trim_regs[2] & 0x06) >> 1;
>> + if (trim_regs[2] & 0x01)
>> + d2 = -d2;
>> + break;
>> + case 8:
>> + /* D1 */
>> + temp = (trim_regs[3] & 0x1F) << 2;
>> + temp |= (trim_regs[1] & 0x06) >> 1;
>> + if (trim_regs[1] & 0x01)
>> + temp = -temp;
>> +
>> + d1 = (trim_regs[8] & 0x18) << 1;
>> + d1 |= (trim_regs[7] & 0x1E) >> 1;
>> + if (trim_regs[7] & 0x01)
>> + d1 = -d1;
>> +
>> + d1 += temp;
>> +
>> + /* D2 */
>> + temp = (trim_regs[4] & 0x3F) << 2;
>> + temp |= (trim_regs[2] & 0x06) >> 1;
>> + if (trim_regs[2] & 0x01)
>> + temp = -temp;
>> +
>> + d2 = (trim_regs[10] & 0x1F) << 2;
>> + d2 |= (trim_regs[8] & 0x06) >> 1;
>> + if (trim_regs[8] & 0x01)
>> + d2 = -d2;
>> +
>> + d2 += temp;
>> + break;
>> + case 9:
>> + /* D1 */
>> + temp = (trim_regs[3] & 0x1F) << 2;
>> + temp |= (trim_regs[1] & 0x06) >> 1;
>> + if (trim_regs[1] & 0x01)
>> + temp = -temp;
>> +
>> + d1 = (trim_regs[14] & 0x18) << 1;
>> + d1 |= (trim_regs[12] & 0x1E) >> 1;
>> + if (trim_regs[12] & 0x01)
>> + d1 = -d1;
>> +
>> + d1 += temp;
>> +
>> + /* D2 */
>> + temp = (trim_regs[4] & 0x3F) << 2;
>> + temp |= (trim_regs[2] & 0x06) >> 1;
>> + if (trim_regs[2] & 0x01)
>> + temp = -temp;
>> +
>> + d2 = (trim_regs[16] & 0x1F) << 2;
>> + d2 |= (trim_regs[14] & 0x06) >> 1;
>> + if (trim_regs[14] & 0x01)
>> + d2 = -d2;
>> +
>> + d2 += temp;
>> + case 10:
>> + /* D1 */
>> + d1 = (trim_regs[11] & 0x0F) << 3;
>> + d1 |= (trim_regs[9] & 0x0E) >> 1;
>> + if (trim_regs[9] & 0x01)
>> + d1 = -d1;
>> +
>> + /* D2 */
>> + d2 = (trim_regs[15] & 0x0F) << 3;
>> + d2 |= (trim_regs[13] & 0x0E) >> 1;
>> + if (trim_regs[13] & 0x01)
>> + d2 = -d2;
>> + break;
>> + case 7:
>> + case 18:
>> + /* D1 */
>> + temp = (trim_regs[3] & 0x1F) << 2;
>> + temp |= (trim_regs[1] & 0x06) >> 1;
>> + if (trim_regs[1] & 0x01)
>> + temp = -temp;
>> +
>> + d1 = (trim_regs[5] & 0x7E) >> 1;
>> + if (trim_regs[5] & 0x01)
>> + d1 = -d1;
>> +.
>> + d1 += temp;
>> +
>> + /* D2 */
>> + temp = (trim_regs[4] & 0x3F) << 2;
>> + temp |= (trim_regs[2] & 0x06) >> 1;
>> + if (trim_regs[2] & 0x01)
>
[PATCH 1/3] iio: core: implement devm_iio_device_alloc/devm_iio_device_free
From: Grygorii Strashko
Add a resource managed devm_iio_device_alloc()/devm_iio_device_free()
to automatically clean up any allocations made by IIO drivers,
thus leading to simplified IIO drivers code.
In addition, this will allow IIO drivers to use other devm_*() API
(like devm_request_irq) and don't care about the race between
iio_device_free() and the release of resources by Device core
during driver removing.
Signed-off-by: Grygorii Strashko
[o.v.kravche...@globallogic.com: fix return value ib devm_iio_device_alloc
in case if devres_alloc failed, remove unused variable "rc"]
Signed-off-by: Oleksandr Kravchenko
Tested-by: Oleksandr Kravchenko
---
drivers/iio/industrialio-core.c | 47 +++
include/linux/iio/iio.h | 25 +
2 files changed, 72 insertions(+)
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index e145931..d56d122 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -912,6 +912,53 @@ void iio_device_free(struct iio_dev *dev)
}
EXPORT_SYMBOL(iio_device_free);
+static void devm_iio_device_release(struct device *dev, void *res)
+{
+ iio_device_free(*(struct iio_dev **)res);
+}
+
+static int devm_iio_device_match(struct device *dev, void *res, void *data)
+{
+ struct iio_dev **r = res;
+ if (!r || !*r) {
+ WARN_ON(!r || !*r);
+ return 0;
+ }
+ return *r == data;
+}
+
+struct iio_dev *devm_iio_device_alloc(struct device *dev, int sizeof_priv)
+{
+ struct iio_dev **ptr, *iio_dev;
+
+ ptr = devres_alloc(devm_iio_device_release, sizeof(*ptr),
+ GFP_KERNEL);
+ if (!ptr)
+ return NULL;
+
+ /* use raw alloc_dr for kmalloc caller tracing */
+ iio_dev = iio_device_alloc(sizeof_priv);
+ if (iio_dev) {
+ *ptr = iio_dev;
+ devres_add(dev, ptr);
+ } else {
+ devres_free(ptr);
+ }
+
+ return iio_dev;
+}
+EXPORT_SYMBOL_GPL(devm_iio_device_alloc);
+
+void devm_iio_device_free(struct device *dev, struct iio_dev *iio_dev)
+{
+ int rc;
+
+ rc = devres_release(dev, devm_iio_device_release,
+ devm_iio_device_match, iio_dev);
+ WARN_ON(rc);
+}
+EXPORT_SYMBOL_GPL(devm_iio_device_free);
+
/**
* iio_chrdev_open() - chrdev file open for buffer access and ioctls
**/
diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
index 8d171f4..f1d99f6 100644
--- a/include/linux/iio/iio.h
+++ b/include/linux/iio/iio.h
@@ -532,6 +532,31 @@ static inline struct iio_dev *iio_priv_to_dev(void *priv)
void iio_device_free(struct iio_dev *indio_dev);
/**
+ * devm_iio_device_alloc - Resource-managed iio_device_alloc()
+ * @dev: Device to allocate iio_dev for
+ * @sizeof_priv: Space to allocate for private structure.
+ *
+ * Managed iio_device_alloc. iio_dev allocated with this function is
+ * automatically freed on driver detach.
+ *
+ * If an iio_dev allocated with this function needs to be freed separately,
+ * devm_iio_device_free() must be used.
+ *
+ * RETURNS:
+ * Pointer to allocated iio_dev on success, NULL on failure.
+ */
+struct iio_dev *devm_iio_device_alloc(struct device *dev, int sizeof_priv);
+
+/**
+ * devm_iio_device_free - Resource-managed iio_device_free()
+ * @dev: Device this iio_dev belongs to
+ * @indio_dev: the iio_dev associated with the device
+ *
+ * Free indio_dev allocated with devm_iio_device_alloc().
+ */
+void devm_iio_device_free(struct device *dev, struct iio_dev *iio_dev);
+
+/**
* iio_buffer_enabled() - helper function to test if the buffer is enabled
* @indio_dev: IIO device structure for device
**/
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] iio: add APDS9300 ambilent light sensor driver
From: Oleksandr Kravchenko
This patch adds IIO driver for APDS9300 ambient light sensor (ALS).
http://www.avagotech.com/docs/AV02-1077EN
The driver allows to read raw data from ADC registers or calculate
lux value. It also can handle threshold interrupt.
Signed-off-by: Oleksandr Kravchenko
---
.../devicetree/bindings/iio/light/apds9300.txt | 22 +
drivers/iio/light/Kconfig | 10 +
drivers/iio/light/Makefile |1 +
drivers/iio/light/apds9300.c | 520
4 files changed, 553 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/light/apds9300.txt
create mode 100644 drivers/iio/light/apds9300.c
diff --git a/Documentation/devicetree/bindings/iio/light/apds9300.txt
b/Documentation/devicetree/bindings/iio/light/apds9300.txt
new file mode 100644
index 000..d6f66c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/apds9300.txt
@@ -0,0 +1,22 @@
+* Avago APDS9300 ambient light sensor
+
+http://www.avagotech.com/docs/AV02-1077EN
+
+Required properties:
+
+ - compatible : should be "avago,apds9300"
+ - reg : the I2C address of the sensor
+
+Optional properties:
+
+ - interrupt-parent : should be the phandle for the interrupt controller
+ - interrupts : interrupt mapping for GPIO IRQ
+
+Example:
+
+apds9300@39 {
+ compatible = "avago,apds9300";
+ reg = <0x39>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <29 8>;
+};
diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
index 5ef1a39..fb6af1b 100644
--- a/drivers/iio/light/Kconfig
+++ b/drivers/iio/light/Kconfig
@@ -15,6 +15,16 @@ config ADJD_S311
This driver can also be built as a module. If so, the module
will be called adjd_s311.
+config APDS9300
+ tristate "APDS9300 ambient light sensor"
+ depends on I2C
+ help
+Say Y here if you want to build a driver for the Avago APDS9300
+ambient light sensor.
+
+To compile this driver as a module, choose M here: the
+module will be called apds9300.
+
config SENSORS_LM3533
tristate "LM3533 ambient light sensor"
depends on MFD_LM3533
diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
index 040d9c7..da58e12 100644
--- a/drivers/iio/light/Makefile
+++ b/drivers/iio/light/Makefile
@@ -6,4 +6,5 @@ obj-$(CONFIG_ADJD_S311) += adjd_s311.o
obj-$(CONFIG_SENSORS_LM3533) += lm3533-als.o
obj-$(CONFIG_SENSORS_TSL2563) += tsl2563.o
obj-$(CONFIG_VCNL4000) += vcnl4000.o
+obj-$(CONFIG_APDS9300) += apds9300.o
obj-$(CONFIG_HID_SENSOR_ALS) += hid-sensor-als.o
diff --git a/drivers/iio/light/apds9300.c b/drivers/iio/light/apds9300.c
new file mode 100644
index 000..3524cb1
--- /dev/null
+++ b/drivers/iio/light/apds9300.c
@@ -0,0 +1,520 @@
+/*
+ * apds9300.c - IIO driver for Avago APDS9300 ambient light sensor
+ *
+ * Copyright 2013 Oleksandr Kravchenko
+ *
+ * This file is subject to the terms and conditions of version 2 of
+ * the GNU General Public License. See the file COPYING in the main
+ * directory of this archive for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ALS_DRV_NAME "apds9300"
+#define ALS_IRQ_NAME "apds9300_event"
+
+/* Command register bits */
+#define ALS_CMDBIT(7) /* Select command register. Must write
as 1 */
+#define ALS_WORD BIT(5) /* I2C write/read: if 1 word, if 0 byte */
+#define ALS_CLEAR BIT(6) /* Interrupt clear. Clears pending interrupt */
+
+/* Register set */
+#define ALS_CONTROL0x00 /* Control of basic functions */
+#define ALS_THRESHLOWLOW 0x02 /* Low byte of low interrupt threshold */
+#define ALS_THRESHHIGHLOW 0x04 /* Low byte of high interrupt threshold */
+#define ALS_INTERRUPT 0x06 /* Interrupt control */
+#define ALS_DATA0LOW 0x0c /* Low byte of ADC channel 0 */
+#define ALS_DATA1LOW 0x0e /* Low byte of ADC channel 1 */
+
+/* Power on/off value for ALS_CONTROL register */
+#define ALS_POWER_ON 0x03
+#define ALS_POWER_OFF 0x00
+
+/* Interrupts */
+#define ALS_INTR_ENABLE0x10
+/* Interrupt Persist Function: Any value outside of threshold range */
+#define ALS_THRESH_INTR0x01
+
+#define ALS_THRESH_MAX 0x /* Max threshold value */
+
+struct als_data {
+ struct i2c_client *client;
+ struct mutex mutex;
+ int power_state;
+ int thresh_low;
+ int thresh_hi;
+ int intr_en;
+};
+
+/* Lux calculation */
+
+/* Calculated values 1000 * (CH1/CH0)^1.4 for CH1/CH0 from 0 to 0.52 */
+static const u16 lux_ratio[] = {
+ 0, 2, 4, 7, 11, 15, 19, 24, 29, 34, 40, 45, 51, 57, 64, 70, 77, 84, 91,
+ 98, 105, 112, 120, 128, 136, 144, 152, 160, 168,
[PATCH 2/3] of: Add Avago Technologies vendor prefix
From: Oleksandr Kravchenko This commit adds a device tree vendor prefix for Avago Technologies. Signed-off-by: Oleksandr Kravchenko --- .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index d5a79ca..8aab9c6 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -11,6 +11,7 @@ amcc Applied Micro Circuits Corporation (APM, formally AMCC) apmApplied Micro Circuits Corporation (APM) armARM Ltd. atmel Atmel Corporation +avago Avago Technologies bosch Bosch Sensortec GmbH brcm Broadcom Corporation cavium Cavium, Inc. -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] of: Add Avago Technologies vendor prefix
From: Oleksandr Kravchenko This commit adds a device tree vendor prefix for Avago Technologies. Signed-off-by: Oleksandr Kravchenko --- .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index d5a79ca..8aab9c6 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -11,6 +11,7 @@ amcc Applied Micro Circuits Corporation (APM, formally AMCC) apmApplied Micro Circuits Corporation (APM) armARM Ltd. atmel Atmel Corporation +avago Avago Technologies bosch Bosch Sensortec GmbH brcm Broadcom Corporation cavium Cavium, Inc. -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] iio: core: implement devm_iio_device_alloc/devm_iio_device_free
From: Grygorii Strashko
Add a resource managed devm_iio_device_alloc()/devm_iio_device_free()
to automatically clean up any allocations made by IIO drivers,
thus leading to simplified IIO drivers code.
In addition, this will allow IIO drivers to use other devm_*() API
(like devm_request_irq) and don't care about the race between
iio_device_free() and the release of resources by Device core
during driver removing.
Signed-off-by: Grygorii Strashko
[o.v.kravche...@globallogic.com: fix return value ib devm_iio_device_alloc
in case if devres_alloc failed, remove unused variable "rc"]
Signed-off-by: Oleksandr Kravchenko
Tested-by: Oleksandr Kravchenko
---
drivers/iio/industrialio-core.c | 47 +++
include/linux/iio/iio.h | 25 +
2 files changed, 72 insertions(+)
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index e145931..d56d122 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -912,6 +912,53 @@ void iio_device_free(struct iio_dev *dev)
}
EXPORT_SYMBOL(iio_device_free);
+static void devm_iio_device_release(struct device *dev, void *res)
+{
+ iio_device_free(*(struct iio_dev **)res);
+}
+
+static int devm_iio_device_match(struct device *dev, void *res, void *data)
+{
+ struct iio_dev **r = res;
+ if (!r || !*r) {
+ WARN_ON(!r || !*r);
+ return 0;
+ }
+ return *r == data;
+}
+
+struct iio_dev *devm_iio_device_alloc(struct device *dev, int sizeof_priv)
+{
+ struct iio_dev **ptr, *iio_dev;
+
+ ptr = devres_alloc(devm_iio_device_release, sizeof(*ptr),
+ GFP_KERNEL);
+ if (!ptr)
+ return NULL;
+
+ /* use raw alloc_dr for kmalloc caller tracing */
+ iio_dev = iio_device_alloc(sizeof_priv);
+ if (iio_dev) {
+ *ptr = iio_dev;
+ devres_add(dev, ptr);
+ } else {
+ devres_free(ptr);
+ }
+
+ return iio_dev;
+}
+EXPORT_SYMBOL_GPL(devm_iio_device_alloc);
+
+void devm_iio_device_free(struct device *dev, struct iio_dev *iio_dev)
+{
+ int rc;
+
+ rc = devres_release(dev, devm_iio_device_release,
+ devm_iio_device_match, iio_dev);
+ WARN_ON(rc);
+}
+EXPORT_SYMBOL_GPL(devm_iio_device_free);
+
/**
* iio_chrdev_open() - chrdev file open for buffer access and ioctls
**/
diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
index 8d171f4..f1d99f6 100644
--- a/include/linux/iio/iio.h
+++ b/include/linux/iio/iio.h
@@ -532,6 +532,31 @@ static inline struct iio_dev *iio_priv_to_dev(void *priv)
void iio_device_free(struct iio_dev *indio_dev);
/**
+ * devm_iio_device_alloc - Resource-managed iio_device_alloc()
+ * @dev: Device to allocate iio_dev for
+ * @sizeof_priv: Space to allocate for private structure.
+ *
+ * Managed iio_device_alloc. iio_dev allocated with this function is
+ * automatically freed on driver detach.
+ *
+ * If an iio_dev allocated with this function needs to be freed separately,
+ * devm_iio_device_free() must be used.
+ *
+ * RETURNS:
+ * Pointer to allocated iio_dev on success, NULL on failure.
+ */
+struct iio_dev *devm_iio_device_alloc(struct device *dev, int sizeof_priv);
+
+/**
+ * devm_iio_device_free - Resource-managed iio_device_free()
+ * @dev: Device this iio_dev belongs to
+ * @indio_dev: the iio_dev associated with the device
+ *
+ * Free indio_dev allocated with devm_iio_device_alloc().
+ */
+void devm_iio_device_free(struct device *dev, struct iio_dev *iio_dev);
+
+/**
* iio_buffer_enabled() - helper function to test if the buffer is enabled
* @indio_dev: IIO device structure for device
**/
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] iio: add APDS9300 ambilent light sensor driver
From: Oleksandr Kravchenko
This patch adds IIO driver for APDS9300 ambient light sensor (ALS).
http://www.avagotech.com/docs/AV02-1077EN
The driver allows to read raw data from ADC registers or calculate
lux value. It also can handle threshold interrupt.
Signed-off-by: Oleksandr Kravchenko
---
.../devicetree/bindings/iio/light/apds9300.txt | 22 +
drivers/iio/light/Kconfig | 10 +
drivers/iio/light/Makefile |1 +
drivers/iio/light/apds9300.c | 517
4 files changed, 550 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/light/apds9300.txt
create mode 100644 drivers/iio/light/apds9300.c
diff --git a/Documentation/devicetree/bindings/iio/light/apds9300.txt
b/Documentation/devicetree/bindings/iio/light/apds9300.txt
new file mode 100644
index 000..d6f66c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/apds9300.txt
@@ -0,0 +1,22 @@
+* Avago APDS9300 ambient light sensor
+
+http://www.avagotech.com/docs/AV02-1077EN
+
+Required properties:
+
+ - compatible : should be "avago,apds9300"
+ - reg : the I2C address of the sensor
+
+Optional properties:
+
+ - interrupt-parent : should be the phandle for the interrupt controller
+ - interrupts : interrupt mapping for GPIO IRQ
+
+Example:
+
+apds9300@39 {
+ compatible = "avago,apds9300";
+ reg = <0x39>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <29 8>;
+};
diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
index 5ef1a39..fb6af1b 100644
--- a/drivers/iio/light/Kconfig
+++ b/drivers/iio/light/Kconfig
@@ -15,6 +15,16 @@ config ADJD_S311
This driver can also be built as a module. If so, the module
will be called adjd_s311.
+config APDS9300
+ tristate "APDS9300 ambient light sensor"
+ depends on I2C
+ help
+Say Y here if you want to build a driver for the Avago APDS9300
+ambient light sensor.
+
+To compile this driver as a module, choose M here: the
+module will be called apds9300.
+
config SENSORS_LM3533
tristate "LM3533 ambient light sensor"
depends on MFD_LM3533
diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
index 040d9c7..da58e12 100644
--- a/drivers/iio/light/Makefile
+++ b/drivers/iio/light/Makefile
@@ -6,4 +6,5 @@ obj-$(CONFIG_ADJD_S311) += adjd_s311.o
obj-$(CONFIG_SENSORS_LM3533) += lm3533-als.o
obj-$(CONFIG_SENSORS_TSL2563) += tsl2563.o
obj-$(CONFIG_VCNL4000) += vcnl4000.o
+obj-$(CONFIG_APDS9300) += apds9300.o
obj-$(CONFIG_HID_SENSOR_ALS) += hid-sensor-als.o
diff --git a/drivers/iio/light/apds9300.c b/drivers/iio/light/apds9300.c
new file mode 100644
index 000..c06a59e
--- /dev/null
+++ b/drivers/iio/light/apds9300.c
@@ -0,0 +1,517 @@
+/*
+ * apds9300.c - IIO driver for Avago APDS9300 ambient light sensor
+ *
+ * Copyright 2013 Oleksandr Kravchenko
+ *
+ * This file is subject to the terms and conditions of version 2 of
+ * the GNU General Public License. See the file COPYING in the main
+ * directory of this archive for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ALS_DRV_NAME "apds9300"
+#define ALS_IRQ_NAME "apds9300_event"
+
+/* Command register bits */
+#define ALS_CMDBIT(7) /* Select command register. Must write
as 1 */
+#define ALS_WORD BIT(5) /* I2C write/read: if 1 word, if 0 byte */
+#define ALS_CLEAR BIT(6) /* Interrupt clear. Clears pending interrupt */
+
+/* Register set */
+#define ALS_CONTROL0x00 /* Control of basic functions */
+#define ALS_THRESHLOWLOW 0x02 /* Low byte of low interrupt threshold */
+#define ALS_THRESHHIGHLOW 0x04 /* Low byte of high interrupt threshold */
+#define ALS_INTERRUPT 0x06 /* Interrupt control */
+#define ALS_DATA0LOW 0x0c /* Low byte of ADC channel 0 */
+#define ALS_DATA1LOW 0x0e /* Low byte of ADC channel 1 */
+
+/* Power on/off value for ALS_CONTROL register */
+#define ALS_POWER_ON 0x03
+#define ALS_POWER_OFF 0x00
+
+/* Interrupts */
+#define ALS_INTR_ENABLE0x10
+/* Interrupt Persist Function: Any value outside of threshold range */
+#define ALS_THRESH_INTR0x01
+
+#define ALS_THRESH_MAX 0x /* Max threshold value */
+
+struct als_data {
+ struct i2c_client *client;
+ struct mutex mutex;
+ int power_state;
+ int thresh_low;
+ int thresh_hi;
+ int intr_en;
+};
+
+/* Lux calculation */
+
+/* Calculated values 1000 * (CH1/CH0)^1.4 for CH1/CH0 from 0 to 0.52 */
+static const u16 lux_ratio[] = {
+ 0, 2, 4, 7, 11, 15, 19, 24, 29, 34, 40, 45, 51, 57, 64, 70, 77, 84, 91,
+ 98, 105, 112, 120, 128, 136, 144, 152, 160, 168,
Re: [PATCH 3/3] iio: add APDS9300 ambilent light sensor driver
Please ignore this patch. It is wrong.
On Thu, Jul 18, 2013 at 12:44 PM, Oleksandr Kravchenko wrote:
> From: Oleksandr Kravchenko
>
> This patch adds IIO driver for APDS9300 ambient light sensor (ALS).
> http://www.avagotech.com/docs/AV02-1077EN
>
> The driver allows to read raw data from ADC registers or calculate
> lux value. It also can handle threshold interrupt.
>
> Signed-off-by: Oleksandr Kravchenko
> ---
> .../devicetree/bindings/iio/light/apds9300.txt | 22 +
> drivers/iio/light/Kconfig | 10 +
> drivers/iio/light/Makefile |1 +
> drivers/iio/light/apds9300.c | 520
>
> 4 files changed, 553 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/light/apds9300.txt
> create mode 100644 drivers/iio/light/apds9300.c
>
> diff --git a/Documentation/devicetree/bindings/iio/light/apds9300.txt
> b/Documentation/devicetree/bindings/iio/light/apds9300.txt
> new file mode 100644
> index 000..d6f66c7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/light/apds9300.txt
> @@ -0,0 +1,22 @@
> +* Avago APDS9300 ambient light sensor
> +
> +http://www.avagotech.com/docs/AV02-1077EN
> +
> +Required properties:
> +
> + - compatible : should be "avago,apds9300"
> + - reg : the I2C address of the sensor
> +
> +Optional properties:
> +
> + - interrupt-parent : should be the phandle for the interrupt controller
> + - interrupts : interrupt mapping for GPIO IRQ
> +
> +Example:
> +
> +apds9300@39 {
> + compatible = "avago,apds9300";
> + reg = <0x39>;
> + interrupt-parent = <&gpio2>;
> + interrupts = <29 8>;
> +};
> diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
> index 5ef1a39..fb6af1b 100644
> --- a/drivers/iio/light/Kconfig
> +++ b/drivers/iio/light/Kconfig
> @@ -15,6 +15,16 @@ config ADJD_S311
> This driver can also be built as a module. If so, the module
> will be called adjd_s311.
>
> +config APDS9300
> + tristate "APDS9300 ambient light sensor"
> + depends on I2C
> + help
> +Say Y here if you want to build a driver for the Avago APDS9300
> +ambient light sensor.
> +
> +To compile this driver as a module, choose M here: the
> +module will be called apds9300.
> +
> config SENSORS_LM3533
> tristate "LM3533 ambient light sensor"
> depends on MFD_LM3533
> diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
> index 040d9c7..da58e12 100644
> --- a/drivers/iio/light/Makefile
> +++ b/drivers/iio/light/Makefile
> @@ -6,4 +6,5 @@ obj-$(CONFIG_ADJD_S311) += adjd_s311.o
> obj-$(CONFIG_SENSORS_LM3533) += lm3533-als.o
> obj-$(CONFIG_SENSORS_TSL2563) += tsl2563.o
> obj-$(CONFIG_VCNL4000) += vcnl4000.o
> +obj-$(CONFIG_APDS9300) += apds9300.o
> obj-$(CONFIG_HID_SENSOR_ALS) += hid-sensor-als.o
> diff --git a/drivers/iio/light/apds9300.c b/drivers/iio/light/apds9300.c
> new file mode 100644
> index 000..3524cb1
> --- /dev/null
> +++ b/drivers/iio/light/apds9300.c
> @@ -0,0 +1,520 @@
> +/*
> + * apds9300.c - IIO driver for Avago APDS9300 ambient light sensor
> + *
> + * Copyright 2013 Oleksandr Kravchenko
> + *
> + * This file is subject to the terms and conditions of version 2 of
> + * the GNU General Public License. See the file COPYING in the main
> + * directory of this archive for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define ALS_DRV_NAME "apds9300"
> +#define ALS_IRQ_NAME "apds9300_event"
> +
> +/* Command register bits */
> +#define ALS_CMDBIT(7) /* Select command register. Must write
> as 1 */
> +#define ALS_WORD BIT(5) /* I2C write/read: if 1 word, if 0 byte */
> +#define ALS_CLEAR BIT(6) /* Interrupt clear. Clears pending interrupt */
> +
> +/* Register set */
> +#define ALS_CONTROL0x00 /* Control of basic functions */
> +#define ALS_THRESHLOWLOW 0x02 /* Low byte of low interrupt threshold */
> +#define ALS_THRESHHIGHLOW 0x04 /* Low byte of high interrupt threshold
> */
> +#define ALS_INTERRUPT 0x06 /* Interrupt control */
> +#define ALS_DATA0LOW 0x0c /* Low byte of ADC channel 0 */
> +#define ALS_DATA1LOW 0x0e /* Low byte of ADC channel 1 */
> +
> +/* Power on/off value for ALS_CONTROL register */
> +#define ALS_POWER_ON 0x03
[PATCH 1/2] ARM: OMAP4: Tablet: Add BMA180 sensor
From: Oleksandr Kravchenko
Add Bosch BMA180 acceleration sensor devicetree
Signed-off-by: Oleksandr Kravchenko
---
arch/arm/boot/dts/omap4-sdp.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index c9022df..13d8279 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -170,6 +170,7 @@
&dss_hdmi_pins
&tpd12s015_pins
&apds9300_pins
+ &bma180_pins
>;
uart2_pins: pinmux_uart2_pins {
@@ -305,6 +306,12 @@
0x50 (PIN_INPUT | MUX_MODE3)/*
gpmc_nbe1.gpio_61 */
>;
};
+
+ bma180_pins: pinmux_bma180_pins {
+ pinctrl-single,pins = <
+ 0x156 (PIN_INPUT_PULLUP | MUX_MODE3)/* gpmc_nbe1.gpio_178 */
+ >;
+ };
};
&i2c1 {
@@ -405,6 +412,17 @@
interrupt-parent = <&gpio2>;
interrupts = <29 8>; /* gpio line 61, low triggered */
};
+
+ bma180@40 {
+ compatible = "bosch,bma180";
+ reg = <0x40>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <18 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING)>;
+ range = <2>;
+ bw = <5>;
+ mode_config = <1>;
+ fuzz = <555>;
+ };
};
&mcspi1 {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] iio: add Bosch BMA180 acceleration sensor driver
From: Oleksandr Kravchenko
This patch adds IIO driver for Bosch BMA180 triaxial
acceleration sensor.
http://omapworld.com/BMA180_111_1002839.pdf
Signed-off-by: Oleksandr Kravchenko
---
.../devicetree/bindings/iio/accel/bma180.txt | 53 +++
drivers/iio/accel/Kconfig | 10 +
drivers/iio/accel/Makefile |2 +
drivers/iio/accel/bma180.c | 462
4 files changed, 527 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/accel/bma180.txt
create mode 100644 drivers/iio/accel/bma180.c
diff --git a/Documentation/devicetree/bindings/iio/accel/bma180.txt
b/Documentation/devicetree/bindings/iio/accel/bma180.txt
new file mode 100644
index 000..7c13c84
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/accel/bma180.txt
@@ -0,0 +1,53 @@
+* Bosch BMA180 triaxial acceleration sensor
+
+http://omapworld.com/BMA180_111_1002839.pdf
+
+Required properties:
+
+ - compatible : should be "bosch,bma180"
+ - reg : the I2C address of the sensor
+
+Optional properties:
+
+ - interrupt-parent : should be the phandle for the interrupt controller
+
+ - interrupts : interrupt mapping for GPIO IRQ, it shuld by configured with
+ flags IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING
+
+ - range : select the full scale acceleration range
+ 0 : -1g..+1g
+ 1 : -1.5g..+1.5g
+ 2 : -2g..+2g
+ 3 : -3g..+3g
+ 4 : -4g..+4g
+ 5 : -8g..+8g
+ 6 : -16g..+16g
+
+ - bw : select bandwidth bandwidth
+ 0 : 10Hz
+ 1 : 20Hz
+ 2 : 40Hz
+ 3 : 75Hz
+ 4 : 150Hz
+ 5 : 300Hz
+ Don't use bandwidth frequency more than 300Hz couse it
+ influences the frequency of generating new data interrupts
+ and i2c reading phase can be longer than pheriod of interrupt
+ generation.
+
+ - mode_config : 0 - select low noise mode, 1 - select low power mode
+
+ - fuzz : specifies fuzz value that is used to filter noise from the event
stream
+
+Example:
+
+bma180@40 {
+ compatible = "bosch,bma180";
+ reg = <0x40>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <18 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING)>;
+ range = <2>;
+ bw = <0>;
+ mode_config = <1>;
+ fuzz = <555>;
+};
diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
index 719d83f..61fd29f 100644
--- a/drivers/iio/accel/Kconfig
+++ b/drivers/iio/accel/Kconfig
@@ -3,6 +3,16 @@
#
menu "Accelerometers"
+config BMA180
+ tristate "Bosch BMA180 3-Axis Accelerometer Driver"
+ depends on I2C
+ help
+ Say Y here if you want to build a driver for the Bosch BMA180
+ triaxial acceleration sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called bma180.
+
config HID_SENSOR_ACCEL_3D
depends on HID_SENSOR_HUB
select IIO_BUFFER
diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
index 87d8fa2..31a36fa 100644
--- a/drivers/iio/accel/Makefile
+++ b/drivers/iio/accel/Makefile
@@ -12,3 +12,5 @@ obj-$(CONFIG_IIO_ST_ACCEL_I2C_3AXIS) += st_accel_i2c.o
obj-$(CONFIG_IIO_ST_ACCEL_SPI_3AXIS) += st_accel_spi.o
obj-$(CONFIG_KXSD9)+= kxsd9.o
+
+obj-$(CONFIG_BMA180) += bma180.o
diff --git a/drivers/iio/accel/bma180.c b/drivers/iio/accel/bma180.c
new file mode 100644
index 000..9f5341f
--- /dev/null
+++ b/drivers/iio/accel/bma180.c
@@ -0,0 +1,462 @@
+/*
+ * bma180.c - IIO driver for Bosch BMA180 triaxial acceleration sensor
+ *
+ * Copyright 2013 Oleksandr Kravchenko
+ *
+ * This file is subject to the terms and conditions of version 2 of
+ * the GNU General Public License. See the file COPYING in the main
+ * directory of this archive for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define BMA180_DRV_NAME "bma180"
+#define BMA180_IRQ_NAME "bma180_event"
+
+/* Register set */
+#define BMA180_CHIP_ID 0x00 /* Need to distinguish BMA180 from other */
+#define BMA180_ACC_X_LSB 0x02 /* First of 6 registers of accel data */
+#define BMA180_CTRL_REG0 0x0d
+#define BMA180_RESET 0x10
+#define BMA180_BW_TCS 0x20
+#define BMA180_CTRL_REG3 0x21
+#define BMA180_TCO_Z 0x30
+#define BMA180_OFFSET_LSB1 0x35
+
+/* Control bits */
+#define BMA180_SLEEP BIT(1) /* 1 - chip will sleep */
+#define BMA180_DIS_WAKE_UP BIT(0) /* Disable wake up mode */
+#define BMA180_EE_WBIT(4) /* Unlock writing to addr. from 0x20 */
+#define BMA180_NEW_DATA_INTBIT(1) /* Intr every new accel data is ready */
+#define BMA180
Re: [PATCH 2/2] iio: add Bosch BMA180 acceleration sensor driver
ds on I2C
>>> +help
>>> + Say Y here if you want to build a driver for the Bosch BMA180
>>> + triaxial acceleration sensor.
>>> +
>>> + To compile this driver as a module, choose M here: the
>>> + module will be called bma180.
>>> +
>>> config HID_SENSOR_ACCEL_3D
>>> depends on HID_SENSOR_HUB
>>> select IIO_BUFFER
>>> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
>>> index 87d8fa2..31a36fa 100644
>>> --- a/drivers/iio/accel/Makefile
>>> +++ b/drivers/iio/accel/Makefile
>>> @@ -12,3 +12,5 @@ obj-$(CONFIG_IIO_ST_ACCEL_I2C_3AXIS) += st_accel_i2c.o
>>> obj-$(CONFIG_IIO_ST_ACCEL_SPI_3AXIS) += st_accel_spi.o
>>>
>>> obj-$(CONFIG_KXSD9) += kxsd9.o
>>> +
>>> +obj-$(CONFIG_BMA180)+= bma180.o
>>
>> alphabetic order
>>
>>> diff --git a/drivers/iio/accel/bma180.c b/drivers/iio/accel/bma180.c
>>> new file mode 100644
>>> index 000..9f5341f
>>> --- /dev/null
>>> +++ b/drivers/iio/accel/bma180.c
>>> @@ -0,0 +1,462 @@
>>> +/*
>>> + * bma180.c - IIO driver for Bosch BMA180 triaxial acceleration sensor
>>> + *
>>> + * Copyright 2013 Oleksandr Kravchenko
>>> + *
>>> + * This file is subject to the terms and conditions of version 2 of
>>> + * the GNU General Public License. See the file COPYING in the main
>>> + * directory of this archive for more details.
>>> + */
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +#define BMA180_DRV_NAME "bma180"
>>> +#define BMA180_IRQ_NAME "bma180_event"
>>> +
>>> +/* Register set */
>>> +#define BMA180_CHIP_ID 0x00 /* Need to distinguish BMA180
>>> from other */
>>> +#define BMA180_ACC_X_LSB0x02 /* First of 6 registers of accel data */
>>> +#define BMA180_CTRL_REG00x0d
>>> +#define BMA180_RESET0x10
>>> +#define BMA180_BW_TCS 0x20
>>> +#define BMA180_CTRL_REG30x21
>>> +#define BMA180_TCO_Z0x30
>>> +#define BMA180_OFFSET_LSB1 0x35
>>> +
>>> +/* Control bits */
>>> +#define BMA180_SLEEPBIT(1) /* 1 - chip will sleep */
>>> +#define BMA180_DIS_WAKE_UP BIT(0) /* Disable wake up mode */
>>> +#define BMA180_EE_W BIT(4) /* Unlock writing to addr. from 0x20 */
>>> +#define BMA180_NEW_DATA_INT BIT(1) /* Intr every new accel data is ready */
>>> +#define BMA180_SMP_SKIP BIT(0) /* Sample skipping mode */
>>
>> maybe say which bits belong to which CTRL reg?
>>
>>> +
>>> +/* Bit masks fo registerts bit fields */
>>
>> typos: fo, registerts
>>
>>> +#define BMA180_RANGE0x0e /* Range of accel measurment */
>>> +#define BMA180_BW 0xf0 /* Accel measurmend bandwidth */
>>
>> typo: measurmend
>>
>>> +#define BMA180_MODE_CONFIG 0x03 /* Config operation modes */
>>> +
>>> +/* We have write this value in reset register to do soft reset */
>>
>> have 'to' write
>>
>>> +#define BMA180_RESET_VAL0xb6
>>> +
>>> +/* Chip operation modes */
>>> +#define BMA180_LOW_NOISE0x00
>>> +#define BMA180_LOW_POWER0x03
>>> +
>>> +struct bma180_data {
>>> +struct i2c_client *client;
>>> +struct input_dev *input_dev;
>>> +struct mutex mutex;
>>> +int sleep_state;
>>> +int range;
>>> +int bw;
>>> +int mode;
>>> +int fuzz;
>>> +int acc_reg[3];
>>> +};
>>> +
>>> +enum bma180_axis {
>>> +AXIS_X,
>>> +AXIS_Y,
>>> +AXIS_Z,
>>> +};
>>> +
>>> +struct bma180_range {
>>> +int g_range;
>>> +int ratio;
>>> +};
>>> +
>>> +static struct bma180_range bma180_range_table[7] = {
>>> +{ 1000, 130 },
>>> +{ 1500, 190 },
>>> +{ 2000, 250 },
>>> +{ 3000, 380 },
>>> +{ 4000, 500 },
>>> +{ 8000, 990 },
>>> +{ 16000, 1980 },
>>> +};
>>> +
>>> +static int bma180_get_acc_reg(struct bma180_data *data, enum bma1
Re: [PATCH] iio: adc: Add bindigs documentation for twl6030 GPADC
Hi Mark,
On Tue, Aug 20, 2013 at 12:12 PM, Mark Rutland wrote:
> Hi Oleksandr,
>
> [Adding Jonathan Cameron and Guenter Roeck to Cc]
>
> Apologies for the delay replying to this. In attempting to verify this
> made sense I went and read the IIO bindings documentation, and I'm
> somewhat confused by the model.
>
> As far as I can see, the only consumer of IIO channels is the
> "iio-hwmon" binding, which seems to be a binding for Linux-specific
> infrastructure rather than any actual device. This runs counter to the
> way DT is supposed to function (describing the hardware rather than how
> it's used). As far as I can see, this linkage is described because only
> a subset of the ADCs on the device are actually wired to something?
>
> I also see a couple of IIO bindings ("adi,adf435x*, and "adi,ad7303")
> which don't describe any iio channel cells at all, so I'm somewhat
> confused by what the IIO channels actually represent, and why they must
> be consumed elsewhere. As far as I can see, an IIO channel represents a
> single ADC's registers in an IIO device, so I'm not sure why this must
> be exported via the channel concept -- it's not physically wired.
The GPADC was used by battery driver and thermal subsystem.
In our local pre-DT branch battery driver reads channels 1 (battery
temperature),
7 (battery voltage), and 8 (battery backup voltage)
I'm guessing a consumer would be in some_board.dts, and describe it as
battery_consumer {
io-channels = <&adc 1>, <&adc 7>, <&adc 8>;
...
}
The purpose of the channels is not arbitrary but dedicated to certain functions
in twl6030.
Regards,
Sasha.
>
> Have I misunderstood something here?
>
> Thanks,
> Mark.
>
> On Mon, Aug 19, 2013 at 12:29:25PM +0100, Oleksandr Kozaruk wrote:
>> Add required documentation for twl6030 GPADC device tree
>> bindings.
>>
>> Signed-off-by: Oleksandr Kozaruk
>> ---
>> .../devicetree/bindings/iio/adc/twl6030-gpadc.txt | 45
>> ++
>> 1 file changed, 45 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/iio/adc/twl6030-gpadc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/iio/adc/twl6030-gpadc.txt
>> b/Documentation/devicetree/bindings/iio/adc/twl6030-gpadc.txt
>> new file mode 100644
>> index 000..6cd3ef3
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/adc/twl6030-gpadc.txt
>> @@ -0,0 +1,45 @@
>> +Texas Instruments twl6030/twl6032 GPADC device driver
>> +
>> +Required properties:
>> + - compatible: must be "ti,twl6030-gpadc" for TWL6030 or
>> + "ti,twl6032-gpadc" for TWL6032
>> + - interrupts: interrupt number associated with it
>> + - #io-channel-cells: must be <1> - multiple IIO outputs are present
>> + iio consumers can use following io-channels:
>> + twl6030:
>> + 0 - battery type
>> + 1 - battery temperature resistor value
>> + 2 - audio accessory/general purpose
>> + 3 - general purpose
>> + 4 - temperature/general purpose
>> + 5 - general purpose
>> + 6 - general purpose
>> + 7 - main battery
>> + 8 - backup battery
>> + 9 - charger input
>> + 10 - VBUS
>> + 11 - VBUS charging current
>> + 14 - USB ID
>> + twl6032:
>> + 0 - battery type
>> + 1 - battery temperature resistor value
>> + 2 - audio accessory/general purpose
>> + 3 - temperature with external diode/general purpose
>> + 4 - temperature/general purpose
>> + 5 - general purpose
>> + 6 - general purpose
>> + 7 - system supply
>> + 8 - backup battery
>> + 9 - charger input
>> + 10 - VBUS
>> + 11 - VBUS charging current
>> + 14 - USB ID
>> + 17 - battery charging current
>> + 18 - battery voltage
>> +
>> +Example:
>> + adc {
>> + compatible = "ti,twl6030-gpadc";
>> + interrupts = <3>;
>> + #io-channel-cells = <1>;
>
[PATCH] iio: core: Avoid double minus in sysfs output
From: Oleksandr Kravchenko This patch fixes the issue with double minus in output when reading channels from sysfs for IIO_VAL_INT_PLUS_MICRO and IIO_VAL_INT_PLUS_NANO cases. Until this patch if val and val2 both are negatives output string contains "--" before digits. It is result of "-%d..." in sprintf() format. Signed-off-by: Oleksandr Kravchenko --- drivers/iio/industrialio-core.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c index d56d122..b3d3959 100644 --- a/drivers/iio/industrialio-core.c +++ b/drivers/iio/industrialio-core.c @@ -383,14 +383,14 @@ static ssize_t iio_read_channel_info(struct device *dev, scale_db = true; case IIO_VAL_INT_PLUS_MICRO: if (val2 < 0) - return sprintf(buf, "-%d.%06u%s\n", val, -val2, + return sprintf(buf, "-%d.%06u%s\n", abs(val), -val2, scale_db ? " dB" : ""); else return sprintf(buf, "%d.%06u%s\n", val, val2, scale_db ? " dB" : ""); case IIO_VAL_INT_PLUS_NANO: if (val2 < 0) - return sprintf(buf, "-%d.%09u\n", val, -val2); + return sprintf(buf, "-%d.%09u\n", abs(val), -val2); else return sprintf(buf, "%d.%09u\n", val, val2); case IIO_VAL_FRACTIONAL: -- 1.7.9.5 -- 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] iio: core: Avoid double minus in sysfs output
On Thu, Jul 18, 2013 at 7:24 PM, Lars-Peter Clausen wrote: > On 07/18/2013 05:47 PM, Oleksandr Kravchenko wrote: >> From: Oleksandr Kravchenko >> >> This patch fixes the issue with double minus in output when >> reading channels from sysfs for IIO_VAL_INT_PLUS_MICRO and >> IIO_VAL_INT_PLUS_NANO cases. Until this patch if val and val2 >> both are negatives output string contains "--" before >> digits. It is result of "-%d..." in sprintf() format. >> > > Hm, this might be a bug in a driver that is triggering this. The idea is > that val2 is only allowed to be negative if val is 0. > > - Lars > If I calculate val and val2 in next way: *val = adc / 100; *val2 = adc % 100; both val and val2 could by negative. Do I have to check it in my driver? -- 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] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
Hello Lars,
On Thu, Jul 18, 2013 at 12:48 PM, Lars-Peter Clausen wrote:
> On 07/18/2013 10:36 AM, Oleksandr Kozaruk wrote:
>> Hello Lars,
>>
>> On Wed, Jul 17, 2013 at 9:04 PM, Lars-Peter Clausen wrote:
>>>> +static int twl6032_calibration(struct twl6030_gpadc_data *gpadc)
>>>> +{
>>>> + int chn, d1 = 0, d2 = 0, temp;
>>>> + u8 trim_regs[17];
>>>> + int ret;
>>>> +
>>>> + ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs + 1,
>>>> + TWL6030_GPADC_TRIM1, 16);
>>>> + if (ret < 0) {
>>>> + dev_err(gpadc->dev, "calibration failed\n");
>>>> + return ret;
>>>> + }
>>>> +
>>>> + /*
>>>> + * Loop to calculate the value needed for returning voltages from
>>>> + * GPADC not values.
>>>> + *
>>>> + * gain is calculated to 3 decimal places fixed point.
>>>> + */
>>>> + for (chn = 0; chn < TWL6032_GPADC_MAX_CHANNELS; chn++) {
>>>> +
>>>> + switch (chn) {
>>>> + case 0:
>>>> + case 1:
>>>> + case 2:
>>>> + case 3:
>>>> + case 4:
>>>> + case 5:
>>>> + case 6:
>>>> + case 11:
>>>> + case 12:
>>>> + case 13:
>>>> + case 14:
>>>> + /* D1 */
>>>> + d1 = (trim_regs[3] & 0x1F) << 2;
>>>> + d1 |= (trim_regs[1] & 0x06) >> 1;
>>>> + if (trim_regs[1] & 0x01)
>>>> + d1 = -d1;
>>>> +
>>>> + /* D2 */
>>>> + d2 = (trim_regs[4] & 0x3F) << 2;
>>>> + d2 |= (trim_regs[2] & 0x06) >> 1;
>>>> + if (trim_regs[2] & 0x01)
>>>> + d2 = -d2;
>>>> + break;
>>>> + case 8:
>>>> + /* D1 */
>>>> + temp = (trim_regs[3] & 0x1F) << 2;
>>>> + temp |= (trim_regs[1] & 0x06) >> 1;
>>>> + if (trim_regs[1] & 0x01)
>>>> + temp = -temp;
>>>> +
>>>> + d1 = (trim_regs[8] & 0x18) << 1;
>>>> + d1 |= (trim_regs[7] & 0x1E) >> 1;
>>>> + if (trim_regs[7] & 0x01)
>>>> + d1 = -d1;
>>>> +
>>>> + d1 += temp;
>>>> +
>>>> + /* D2 */
>>>> + temp = (trim_regs[4] & 0x3F) << 2;
>>>> + temp |= (trim_regs[2] & 0x06) >> 1;
>>>> + if (trim_regs[2] & 0x01)
>>>> + temp = -temp;
>>>> +
>>>> + d2 = (trim_regs[10] & 0x1F) << 2;
>>>> + d2 |= (trim_regs[8] & 0x06) >> 1;
>>>> + if (trim_regs[8] & 0x01)
>>>> + d2 = -d2;
>>>> +
>>>> + d2 += temp;
>>>> + break;
>>>> + case 9:
>>>> + /* D1 */
>>>> + temp = (trim_regs[3] & 0x1F) << 2;
>>>> + temp |= (trim_regs[1] & 0x06) >> 1;
>>>> + if (trim_regs[1] & 0x01)
>>>> + temp = -temp;
>>>> +
>>>> + d1 = (trim_regs[14] & 0x18) << 1;
>>>> + d1 |= (trim_regs[12] & 0x1E) >> 1;
>>>> + if (trim_regs[12] & 0x01)
>>>> + d1 = -d1;
>>>> +
>>>> + d1 += temp;
>>>> +
>>>> + /* D2 */
>>>> + temp = (trim_regs[4] & 0x3F) << 2;
>>>> + temp |= (trim_regs[2] & 0x06) &
[PATCH v6 1/2] ARM: dts: twl: Add GPADC data to device tree
GPADC is the general purpose ADC present on twl6030.
The dt data is interrupt used to trigger end of ADC
conversion.
Signed-off-by: Oleksandr Kozaruk
---
arch/arm/boot/dts/twl6030.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 2e3bd31..d7d4c28 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -103,4 +103,10 @@
compatible = "ti,twl6030-pwmled";
#pwm-cells = <2>;
};
+
+ adc: gpadc {
+ compatible = "ti,twl6030-gpadc";
+ interrupts = <3>;
+ #io-channel-cells = <1>;
+ };
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 0/2] TWL6030, TWL6032 GPADC driver
Hello, v6 - addressed comments about trim bits, checkpatch clean up v5 - gpadc DT node renamed from "gpadc" to generic "adc", added temperature channels; raw code is corracted with calibration data. v4 - addressed comments: fixed style violation, bug in freeing memory, added comments explaining calibration method, removed test network channels from exposing to userspace, error handling for wait_for_complition v3 - fixed compiler warning v2 - the driver put in drivers/iio, and converted using iio facilities as suggested by Graeme. TWL603[02] GPADC is used to measure battery voltage, battery temperature, battery presence ID, and could be used to measure twl603[02] die temperature. This is used on TI blaze, blaze tablet platforms. The TWL6030/TWL6032 is a PMIC that has a GPADC with 17/19 channels respectively. Some channels have current source and are used for measuring voltage drop on resistive load for detecting battery ID resistance, or measuring voltage drop on NTC resistors for external temperature measurements, other channels measure voltage, (i.e. battery voltage), and have inbuilt voltage dividers, thus, capable to scale voltage. Some channels are dedicated for measuring die temperature. Some channels could be calibrated in 2 points, having offsets from ideal values in trim registers. The difference between GPADC in TWL6030 and TWL6032: - 10 bit vs 12 bit ADC; - 17 vs 19 channels; - channels have different purpose(i. e. battery voltage channel 8 vs channel 18); - trim values are interpreted differently. The driver is derived from git://git.omapzoom.org/kernel/omap.git The original driver's authors and contributors are Balaji T K, Graeme Gregory, Ambresh K, Girish S Ghongdemath. The changes to the original driver: - device tree adaptation; - drop ioctl support - never been used; - unified measurement method for both devices; - get rid of "if (device == X)" code style to data driven; - drop polling end of conversion and use interrupt instead; - iio framework is used Tested with on blaze tablet 2 with OMAP4430(twl6030), and OMAP4470(twl6032) SOMs. The patches were tested against 3.10-rc7 Oleksandr Kozaruk (2): ARM: dts: twl: Add GPADC data to device tree iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver arch/arm/boot/dts/twl6030.dtsi | 6 + drivers/iio/adc/Kconfig | 14 + drivers/iio/adc/Makefile| 1 + drivers/iio/adc/twl6030-gpadc.c | 991 4 files changed, 1012 insertions(+) create mode 100644 drivers/iio/adc/twl6030-gpadc.c -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC, known also as Phoenix and PhoenixLite. The TWL6030 and TWL6032 have GPADC with 17 and 19 channels respectively. Some channels have current source and are used for measuring voltage drop on resistive load for detecting battery ID resistance, or measuring voltage drop on NTC resistors for external temperature measurements. Some channels measure voltage, (i.e. battery voltage), and have voltage dividers, thus, capable to scale voltage. Some channels are dedicated for measuring die temperature. Some channels are calibrated in 2 points, having offsets from ideal values kept in trim registers. This is used to correct measurements. The differences between GPADC in TWL6030 and TWL6032: - 10 bit vs 12 bit ADC; - 17 vs 19 channels; - channels have different purpose(i.e. battery voltage channel 8 vs channel 18); - trim values are interpreted differently. Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K, Girish S Ghongdemath. Signed-off-by: Balaji T K Signed-off-by: Graeme Gregory Signed-off-by: Oleksandr Kozaruk --- drivers/iio/adc/Kconfig | 14 + drivers/iio/adc/Makefile| 1 + drivers/iio/adc/twl6030-gpadc.c | 991 3 files changed, 1006 insertions(+) create mode 100644 drivers/iio/adc/twl6030-gpadc.c diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index ab0767e6..3172461 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -150,6 +150,20 @@ config TI_AM335X_ADC Say yes here to build support for Texas Instruments ADC driver which is also a MFD client. +config TWL6030_GPADC + tristate "TWL6030 GPADC (General Purpose A/D Converter) Support" + depends on TWL4030_CORE + default n + help + Say yes here if you want support for the TWL6030/TWL6032 General + Purpose A/D Converter. This will add support for battery type + detection, battery voltage and temperature measurement, die + temperature measurement, system supply voltage, audio accessory, + USB ID detection. + + This driver can also be built as a module. If so, the module will be + called twl6030-gpadc. + config VIPERBOARD_ADC tristate "Viperboard ADC support" depends on MFD_VIPERBOARD && USB diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile index 0a825be..996ba09 100644 --- a/drivers/iio/adc/Makefile +++ b/drivers/iio/adc/Makefile @@ -16,4 +16,5 @@ obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o obj-$(CONFIG_MAX1363) += max1363.o obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o +obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c new file mode 100644 index 000..b42cfd6 --- /dev/null +++ b/drivers/iio/adc/twl6030-gpadc.c @@ -0,0 +1,991 @@ +/* + * TWL6030 GPADC module driver + * + * Copyright (C) 2009-2013 Texas Instruments Inc. + * Nishant Kamat + * Balaji T K + * Graeme Gregory + * Girish S Ghongdemath + * Ambresh K + * Oleksandr Kozaruk + * + * 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. + * + * 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. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DRIVER_NAME"twl6030_gpadc" + +#define TWL6030_GPADC_MAX_CHANNELS 17 +#define TWL6032_GPADC_MAX_CHANNELS 19 + +#define TWL6030_GPADC_CTRL_P1 0x05 + +#define TWL6032_GPADC_GPSELECT_ISB 0x07 +#define TWL6032_GPADC_CTRL_P1 0x08 + +#define TWL6032_GPADC_GPCH0_LSB0x0d +#define TWL6032_GPADC_GPCH0_MSB0x0e + +#define TWL6030_GPADC_CTRL_P1_SP1 BIT(3) + +#define TWL6030_GPADC_GPCH0_LSB(0x29) + +#define TWL6030_GPADC_RT_SW1_EOC_MASK BIT(5) + +#define TWL6030_GPADC_TRIM10xCD + +#define TWL6030_REG_TOGGLE10x90 +#define TWL6030_GPADCS BIT(1) +#define TWL6030_GPADCR BIT(0) + +/** + * struct twl6030_chnl_calib - channel calibration + * @gain: slope coefficient for ideal curve + * @gain_error:
Re: [PATCH v6 1/2] ARM: dts: twl: Add GPADC data to device tree
Hi Sergei,
On Fri, Jul 19, 2013 at 1:18 PM, Sergei Shtylyov
wrote:
> Hello.
>
>
> On 07/19/2013 07:40 PM, Grygorii Strashko wrote:
>
>>>> GPADC is the general purpose ADC present on twl6030.
>>>> The dt data is interrupt used to trigger end of ADC
>>>> conversion.
>
>
>>>> Signed-off-by: Oleksandr Kozaruk
>>>> ---
>>>> arch/arm/boot/dts/twl6030.dtsi | 6 ++
>>>> 1 file changed, 6 insertions(+)
>
>
>>>> diff --git a/arch/arm/boot/dts/twl6030.dtsi
>>>> b/arch/arm/boot/dts/twl6030.dtsi
>>>> index 2e3bd31..d7d4c28 100644
>>>> --- a/arch/arm/boot/dts/twl6030.dtsi
>>>> +++ b/arch/arm/boot/dts/twl6030.dtsi
>>>> @@ -103,4 +103,10 @@
>>>> compatible = "ti,twl6030-pwmled";
>>>> #pwm-cells = <2>;
>>>> };
>>>> +
>>>> +adc: gpadc {
>
>
>>> Read my lips: the node should be called just "adc", not "gpadc".
>>
>> Are you sure?
>
>
>I didn't know how to express my disappointment from Oleksandr's inability
> to understand what I wanted to convey to him from 2 attempts... first,
How would you comment the following code, v3.10-rc7:
arch/arm/boot/dts/dbx5x0.dtsi, line 375
375 ab8500-gpadc {
376 compatible =
"stericsson,ab8500-gpadc";
377 interrupts = <32
IRQ_TYPE_LEVEL_HIGH
arch/arm/boot/dts/dbx5x0.dtsi: ab8500-gpadc {
arch/arm/boot/dts/dbx5x0.dtsi:
compatible = "stericsson,ab8500-gpadc";
arch/arm/boot/dts/dbx5x0.dtsi:
vddadc-supply = <&ab8500_ldo_tvout_reg>;
arch/arm/boot/dts/sama5d3.dtsi: tsadcc: tsadcc@f8018000 {
arch/arm/boot/dts/sama5d3.dtsi: compatible =
"atmel,at91sam9x5-tsadcc";
arch/arm/boot/dts/sama5d3.dtsi:
atmel,tsadcc_clock = <30>;
arch/arm/boot/dts/am33xx.dtsi: tscadc: tscadc@44e0d000 {
arch/arm/boot/dts/am33xx.dtsi: compatible = "ti,am3359-tscadc";
arch/arm/boot/dts/am33xx.dtsi: ti,hwmods = "adc_tsc";
arch/arm/boot/dts/am33xx.dtsi: am335x_adc: adc {
arch/arm/boot/dts/am33xx.dtsi: compatible =
"ti,am3359-adc";
Regards,
Sasha.
> changed the label instead of the node name, then he only dropped "twl6030_"
> prefix from the name. I should probably have been even more specific before.
>
>
>> Why? The name was selected according to the documentation on device
>> "General
>> purpose analog-to-digital converter (GPADC)".
>
>
>Sigh, we simply don't care whether this ADC is general-purpose or not.
> The main thing it is ADC.
>
>
>> PS. Following your logic - "GPIO" need to renamed to "IO" everywhere ;P
>
>
>GPIO is well known and established abbreviation, contrasted to GPADC.
> Moreover, ePAPR spec lists "gpio" as a generic node name.
>
>
> WBR, Sergei
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-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 v6 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
Hi Jonathan,
On Sat, Jul 20, 2013 at 1:43 PM, Jonathan Cameron wrote:
> On 07/19/2013 10:27 AM, Oleksandr Kozaruk wrote:
>> The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC,
>> known also as Phoenix and PhoenixLite.
>>
>> The TWL6030 and TWL6032 have GPADC with 17 and 19 channels
>> respectively. Some channels have current source and are used for
>> measuring voltage drop on resistive load for detecting battery ID
>> resistance, or measuring voltage drop on NTC resistors for external
>> temperature measurements. Some channels measure voltage, (i.e. battery
>> voltage), and have voltage dividers, thus, capable to scale voltage.
>> Some channels are dedicated for measuring die temperature.
>>
>> Some channels are calibrated in 2 points, having offsets from ideal
>> values kept in trim registers. This is used to correct measurements.
>>
>> The differences between GPADC in TWL6030 and TWL6032:
>> - 10 bit vs 12 bit ADC;
>> - 17 vs 19 channels;
>> - channels have different purpose(i.e. battery voltage
>> channel 8 vs channel 18);
>> - trim values are interpreted differently.
>>
>> Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K,
>> Girish S Ghongdemath.
>>
>> Signed-off-by: Balaji T K
>> Signed-off-by: Graeme Gregory
>> Signed-off-by: Oleksandr Kozaruk
> A few little bits and bobs inline.
>
> My only major query is about the lack of info for the temperature
> channels. How do you convert these to useful real world units?
If I get your question right: the ADC channels 1, 4 are dedicated for
measuring resistive value.
The temperature measurement will depend on:
1) the ADC code(provided by the driver);
2) value of the NTC resistor, its characteristics, the way it is
plugged in the circuit,
and may be some calibration data(platform dependent); How the driver can the
drive take care of these?
[...]
>> +static int twl6030_gpadc_read_raw(struct iio_dev *indio_dev,
>> + const struct iio_chan_spec *chan,
>> + int *val, int *val2, long mask)
>> +{
>> + struct twl6030_gpadc_data *gpadc = iio_priv(indio_dev);
>> + int ret = -EINVAL;
> I'm suprised you didn't get a warning about the assigment above
> being pointless as you overwrite ret just below.
Indeed, ret is overwritten, though, there is no warning from make C=2
and checkpatch is silent.
I'll remove the initialization.
[...]
>> +
>> +#define TWL6030_GPADC_CHAN(chn, _type, chan_info) { \
>> + .type = _type, \
>> + .channel = chn, \
>> + .info_mask_separate = BIT(chan_info), \
>> + .indexed = 1, \
>> +}
>> +
>
>
> Why list these at all? I see they are no longer visible from
> userspace, but they are still taking up memory etc without I
> think ever being used?
I've kept it because for twl6032 there is a gap if I drop channels 15, 16,
as channels 17, 18 are used.
>> +/* internal test network channel */
>> +#define TWL6030_GPADC_TEST_CHAN(chn, chan_info) {\
>> + .type = IIO_VOLTAGE,\
>> + .channel = chn, \
>> + .indexed = 1, \
>> +}
>> +
>> +static const struct iio_chan_spec twl6030_gpadc_iio_channels[] = {
>> + TWL6030_GPADC_CHAN(0, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
>> + TWL6030_GPADC_CHAN(1, IIO_TEMP, IIO_CHAN_INFO_RAW),
> So we have no other information about the temp channels other than
> raw adc counts? If so, how are these useful? I guess you might
> be intending to use iio-hwmon to get these into hwmon the use
> lm-sensors config files to convert to something useful.
> Otherwise, you probably want to get the board specific info on
> the calibration of these in here to make the data available to userspace
> in a useful format...
Hmm, it seems that info on the NTC type is board specific. And we
should get it from device tree?
I thought the driver just gives the ADC code, and consumer will know
what to do with the ADC data.
So, calculation for converting to temperature should be done in this driver?
I don't know how yet.
[...]
>> +MODULE_AUTHOR("Texas Instruments Inc.");
>
> I would normally expect an actual person for
> the module author. Is this TI policy or simply a case of no clear single
> author? Note I believe there is no problem with having multiple
> MODULE_AUTHOR lines so that everyone who made a major contribution is
> included.
Yes, this is because of having multiple authors. I will change it for
Balaji, Graeme and myself.
Regards,
OK.
--
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] iio: core: Avoid double minus in sysfs output
Please ignore this patch for now. I'll rework it soon. It issues warnings when compiling. On Sat, Jul 20, 2013 at 12:06 AM, Jonathan Cameron wrote: > On 07/19/2013 07:15 AM, Oleksandr Kravchenko wrote: >> On Thu, Jul 18, 2013 at 7:24 PM, Lars-Peter Clausen wrote: >>> On 07/18/2013 05:47 PM, Oleksandr Kravchenko wrote: >>>> From: Oleksandr Kravchenko >>>> >>>> This patch fixes the issue with double minus in output when >>>> reading channels from sysfs for IIO_VAL_INT_PLUS_MICRO and >>>> IIO_VAL_INT_PLUS_NANO cases. Until this patch if val and val2 >>>> both are negatives output string contains "--" before >>>> digits. It is result of "-%d..." in sprintf() format. >>>> >>> >>> Hm, this might be a bug in a driver that is triggering this. The idea is >>> that val2 is only allowed to be negative if val is 0. >>> >>> - Lars >>> >> If I calculate val and val2 in next way: >> *val = adc / 100; >> *val2 = adc % 100; >> both val and val2 could by negative. Do I have to check it in my driver? >> > I guess it is will happen occasionally. In the c89 standard, module for a > negative > is implementation specific. Anyone know if we can assume this will work in > all cases > within the kernel? -- Oleksandr Kravchenko GlobalLogic P +380633213187 P +380994930248 www.globallogic.com http://www.globallogic.com/email_disclaimer.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] iio: core: Avoid double minus in sysfs output
From: Oleksandr Kravchenko This patch fixes the issue with double minus in output when reading channels from sysfs for IIO_VAL_INT_PLUS_MICRO and IIO_VAL_INT_PLUS_NANO cases. Until this patch if val and val2 both are negatives output string contains "--" before digits. It is result of "-%d..." in sprintf() format. Signed-off-by: Oleksandr Kravchenko --- drivers/iio/industrialio-core.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c index d56d122..455c24b 100644 --- a/drivers/iio/industrialio-core.c +++ b/drivers/iio/industrialio-core.c @@ -383,14 +383,14 @@ static ssize_t iio_read_channel_info(struct device *dev, scale_db = true; case IIO_VAL_INT_PLUS_MICRO: if (val2 < 0) - return sprintf(buf, "-%d.%06u%s\n", val, -val2, - scale_db ? " dB" : ""); + return sprintf(buf, "-%d.%06u%s\n", (int)abs(val), + -val2, scale_db ? " dB" : ""); else return sprintf(buf, "%d.%06u%s\n", val, val2, scale_db ? " dB" : ""); case IIO_VAL_INT_PLUS_NANO: if (val2 < 0) - return sprintf(buf, "-%d.%09u\n", val, -val2); + return sprintf(buf, "-%d.%09u\n", (int)abs(val), -val2); else return sprintf(buf, "%d.%09u\n", val, val2); case IIO_VAL_FRACTIONAL: -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] iio: core: Avoid double minus in sysfs output
From: Oleksandr Kravchenko This patch fixes the issue with double minus in output when reading channels from sysfs for IIO_VAL_INT_PLUS_MICRO and IIO_VAL_INT_PLUS_NANO cases. Until this patch if val and val2 both are negatives output string contains "--" before digits. It is result of "-%d..." in sprintf() format. Signed-off-by: Oleksandr Kravchenko --- drivers/iio/industrialio-core.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c index d56d122..97f0297 100644 --- a/drivers/iio/industrialio-core.c +++ b/drivers/iio/industrialio-core.c @@ -383,14 +383,14 @@ static ssize_t iio_read_channel_info(struct device *dev, scale_db = true; case IIO_VAL_INT_PLUS_MICRO: if (val2 < 0) - return sprintf(buf, "-%d.%06u%s\n", val, -val2, + return sprintf(buf, "-%ld.%06u%s\n", abs(val), -val2, scale_db ? " dB" : ""); else return sprintf(buf, "%d.%06u%s\n", val, val2, scale_db ? " dB" : ""); case IIO_VAL_INT_PLUS_NANO: if (val2 < 0) - return sprintf(buf, "-%d.%09u\n", val, -val2); + return sprintf(buf, "-%ld.%09u\n", abs(val), -val2); else return sprintf(buf, "%d.%09u\n", val, val2); case IIO_VAL_FRACTIONAL: -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC, known also as Phoenix and PhoenixLite. The TWL6030 and TWL6032 have GPADC with 17 and 19 channels respectively. Some channels have current source and are used for measuring voltage drop on resistive load for detecting battery ID resistance, or measuring voltage drop on NTC resistors for external temperature measurements. Some channels measure voltage, (i.e. battery voltage), and have voltage dividers, thus, capable to scale voltage. Some channels are dedicated for measuring die temperature. Some channels are calibrated in 2 points, having offsets from ideal values kept in trim registers. This is used to correct measurements. The differences between GPADC in TWL6030 and TWL6032: - 10 bit vs 12 bit ADC; - 17 vs 19 channels; - channels have different purpose(i.e. battery voltage channel 8 vs channel 18); - trim values are interpreted differently. Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K, Girish S Ghongdemath. Signed-off-by: Balaji T K Signed-off-by: Graeme Gregory Signed-off-by: Oleksandr Kozaruk --- drivers/iio/adc/Kconfig | 14 + drivers/iio/adc/Makefile| 1 + drivers/iio/adc/twl6030-gpadc.c | 981 3 files changed, 996 insertions(+) create mode 100644 drivers/iio/adc/twl6030-gpadc.c diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index 93129ec..f8f9f18 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -160,6 +160,20 @@ config TI_AM335X_ADC Say yes here to build support for Texas Instruments ADC driver which is also a MFD client. +config TWL6030_GPADC + tristate "TWL6030 GPADC (General Purpose A/D Converter) Support" + depends on TWL4030_CORE + default n + help + Say yes here if you want support for the TWL6030/TWL6032 General + Purpose A/D Converter. This will add support for battery type + detection, battery voltage and temperature measurement, die + temperature measurement, system supply voltage, audio accessory, + USB ID detection. + + This driver can also be built as a module. If so, the module will be + called twl6030-gpadc. + config VIPERBOARD_ADC tristate "Viperboard ADC support" depends on MFD_VIPERBOARD && USB diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile index 8f475d3..db430bd 100644 --- a/drivers/iio/adc/Makefile +++ b/drivers/iio/adc/Makefile @@ -17,4 +17,5 @@ obj-$(CONFIG_MAX1363) += max1363.o obj-$(CONFIG_MCP320X) += mcp320x.o obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o +obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c new file mode 100644 index 000..1b1962e --- /dev/null +++ b/drivers/iio/adc/twl6030-gpadc.c @@ -0,0 +1,981 @@ +/* + * TWL6030 GPADC module driver + * + * Copyright (C) 2009-2013 Texas Instruments Inc. + * Nishant Kamat + * Balaji T K + * Graeme Gregory + * Girish S Ghongdemath + * Ambresh K + * Oleksandr Kozaruk + * + * 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. + * + * 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. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DRIVER_NAME"twl6030_gpadc" + +#define TWL6030_GPADC_MAX_CHANNELS 15 +#define TWL6032_GPADC_MAX_CHANNELS 19 +#define TWL6030_GPADC_NUM_TRIM_REGS16 + +#define TWL6030_GPADC_CTRL_P1 0x05 + +#define TWL6032_GPADC_GPSELECT_ISB 0x07 +#define TWL6032_GPADC_CTRL_P1 0x08 + +#define TWL6032_GPADC_GPCH0_LSB0x0d +#define TWL6032_GPADC_GPCH0_MSB0x0e + +#define TWL6030_GPADC_CTRL_P1_SP1 BIT(3) + +#define TWL6030_GPADC_GPCH0_LSB(0x29) + +#define TWL6030_GPADC_RT_SW1_EOC_MASK BIT(5) + +#define TWL6030_GPADC_TRIM10xCD + +#define TWL6030_REG_TOGGLE10x90 +#define TWL6030_GPADCS BIT(1) +#define TWL6030_GPADCR BIT(0) + +/** + * struct twl6030_chnl_calib - channel calibration + * @gain:
[PATCH v7 1/2] ARM: dts: twl: Add GPADC data to device tree
GPADC is the general purpose ADC present on twl6030.
The dt data is interrupt used to trigger end of ADC
conversion.
Signed-off-by: Oleksandr Kozaruk
---
arch/arm/boot/dts/twl6030.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 2e3bd31..b78e1d5 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -103,4 +103,10 @@
compatible = "ti,twl6030-pwmled";
#pwm-cells = <2>;
};
+
+ adc {
+ compatible = "ti,twl6030-gpadc";
+ interrupts = <3>;
+ #io-channel-cells = <1>;
+ };
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 0/2] TWL6030, TWL6032 GPADC driver
Hello, v7 - addressed clean up comments, removed test channels v6 - addressed comments about trim bits, checkpatch clean up v5 - gpadc DT node renamed from "gpadc" to generic "adc", added temperature channels; raw code is corracted with calibration data. v4 - addressed comments: fixed style violation, bug in freeing memory, added comments explaining calibration method, removed test network channels from exposing to userspace, error handling for wait_for_complition v3 - fixed compiler warning v2 - the driver put in drivers/iio, and converted using iio facilities as suggested by Graeme. TWL603[02] GPADC is used to measure battery voltage, battery temperature, battery presence ID, and could be used to measure twl603[02] die temperature. This is used on TI blaze, blaze tablet platforms. The TWL6030/TWL6032 is a PMIC that has a GPADC with 17/19 channels respectively. Some channels have current source and are used for measuring voltage drop on resistive load for detecting battery ID resistance, or measuring voltage drop on NTC resistors for external temperature measurements, other channels measure voltage, (i.e. battery voltage), and have inbuilt voltage dividers, thus, capable to scale voltage. Some channels are dedicated for measuring die temperature. Some channels could be calibrated in 2 points, having offsets from ideal values in trim registers. The difference between GPADC in TWL6030 and TWL6032: - 10 bit vs 12 bit ADC; - 17 vs 19 channels; - channels have different purpose(i. e. battery voltage channel 8 vs channel 18); - trim values are interpreted differently. The driver is derived from git://git.omapzoom.org/kernel/omap.git The original driver's authors and contributors are Balaji T K, Graeme Gregory, Ambresh K, Girish S Ghongdemath. The changes to the original driver: - device tree adaptation; - drop ioctl support - never been used; - unified measurement method for both devices; - get rid of "if (device == X)" code style to data driven; - drop polling end of conversion and use interrupt instead; - iio framework is used Tested with on blaze tablet 2 with OMAP4430(twl6030), and OMAP4470(twl6032) SOMs. The patches were tested against 3.11-rc2 Oleksandr Kozaruk (2): ARM: dts: twl: Add GPADC data to device tree iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver arch/arm/boot/dts/twl6030.dtsi | 6 + drivers/iio/adc/Kconfig | 14 + drivers/iio/adc/Makefile| 1 + drivers/iio/adc/twl6030-gpadc.c | 981 4 files changed, 1002 insertions(+) create mode 100644 drivers/iio/adc/twl6030-gpadc.c -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/2] of: Add Avago Technologies vendor prefix
From: Oleksandr Kravchenko This commit adds a device tree vendor prefix for Avago Technologies. Signed-off-by: Oleksandr Kravchenko --- .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index d5a79ca..8aab9c6 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -11,6 +11,7 @@ amcc Applied Micro Circuits Corporation (APM, formally AMCC) apmApplied Micro Circuits Corporation (APM) armARM Ltd. atmel Atmel Corporation +avago Avago Technologies bosch Bosch Sensortec GmbH brcm Broadcom Corporation cavium Cavium, Inc. -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/2] iio: add APDS9300 ambilent light sensor driver
From: Oleksandr Kravchenko
This patch adds IIO driver for APDS9300 ambient light sensor (ALS).
http://www.avagotech.com/docs/AV02-1077EN
The driver allows to read raw data from ADC registers or calculate
lux value. It also can handle threshold interrupt.
Signed-off-by: Oleksandr Kravchenko
---
.../devicetree/bindings/iio/light/apds9300.txt | 22 +
drivers/iio/light/Kconfig | 10 +
drivers/iio/light/Makefile |1 +
drivers/iio/light/apds9300.c | 512
4 files changed, 545 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/light/apds9300.txt
create mode 100644 drivers/iio/light/apds9300.c
diff --git a/Documentation/devicetree/bindings/iio/light/apds9300.txt
b/Documentation/devicetree/bindings/iio/light/apds9300.txt
new file mode 100644
index 000..d6f66c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/apds9300.txt
@@ -0,0 +1,22 @@
+* Avago APDS9300 ambient light sensor
+
+http://www.avagotech.com/docs/AV02-1077EN
+
+Required properties:
+
+ - compatible : should be "avago,apds9300"
+ - reg : the I2C address of the sensor
+
+Optional properties:
+
+ - interrupt-parent : should be the phandle for the interrupt controller
+ - interrupts : interrupt mapping for GPIO IRQ
+
+Example:
+
+apds9300@39 {
+ compatible = "avago,apds9300";
+ reg = <0x39>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <29 8>;
+};
diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
index 5ef1a39..fb6af1b 100644
--- a/drivers/iio/light/Kconfig
+++ b/drivers/iio/light/Kconfig
@@ -15,6 +15,16 @@ config ADJD_S311
This driver can also be built as a module. If so, the module
will be called adjd_s311.
+config APDS9300
+ tristate "APDS9300 ambient light sensor"
+ depends on I2C
+ help
+Say Y here if you want to build a driver for the Avago APDS9300
+ambient light sensor.
+
+To compile this driver as a module, choose M here: the
+module will be called apds9300.
+
config SENSORS_LM3533
tristate "LM3533 ambient light sensor"
depends on MFD_LM3533
diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
index 040d9c7..da58e12 100644
--- a/drivers/iio/light/Makefile
+++ b/drivers/iio/light/Makefile
@@ -6,4 +6,5 @@ obj-$(CONFIG_ADJD_S311) += adjd_s311.o
obj-$(CONFIG_SENSORS_LM3533) += lm3533-als.o
obj-$(CONFIG_SENSORS_TSL2563) += tsl2563.o
obj-$(CONFIG_VCNL4000) += vcnl4000.o
+obj-$(CONFIG_APDS9300) += apds9300.o
obj-$(CONFIG_HID_SENSOR_ALS) += hid-sensor-als.o
diff --git a/drivers/iio/light/apds9300.c b/drivers/iio/light/apds9300.c
new file mode 100644
index 000..66a58bd
--- /dev/null
+++ b/drivers/iio/light/apds9300.c
@@ -0,0 +1,512 @@
+/*
+ * apds9300.c - IIO driver for Avago APDS9300 ambient light sensor
+ *
+ * Copyright 2013 Oleksandr Kravchenko
+ *
+ * This file is subject to the terms and conditions of version 2 of
+ * the GNU General Public License. See the file COPYING in the main
+ * directory of this archive for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define APDS9300_DRV_NAME "apds9300"
+#define APDS9300_IRQ_NAME "apds9300_event"
+
+/* Command register bits */
+#define APDS9300_CMD BIT(7) /* Select command register. Must write as 1 */
+#define APDS9300_WORD BIT(5) /* I2C write/read: if 1 word, if 0 byte */
+#define APDS9300_CLEAR BIT(6) /* Interrupt clear. Clears pending interrupt */
+
+/* Register set */
+#define APDS9300_CONTROL 0x00 /* Control of basic functions */
+#define APDS9300_THRESHLOWLOW 0x02 /* Low byte of low interrupt threshold */
+#define APDS9300_THRESHHIGHLOW 0x04 /* Low byte of high interrupt threshold */
+#define APDS9300_INTERRUPT 0x06 /* Interrupt control */
+#define APDS9300_DATA0LOW 0x0c /* Low byte of ADC channel 0 */
+#define APDS9300_DATA1LOW 0x0e /* Low byte of ADC channel 1 */
+
+/* Power on/off value for APDS9300_CONTROL register */
+#define APDS9300_POWER_ON 0x03
+#define APDS9300_POWER_OFF 0x00
+
+/* Interrupts */
+#define APDS9300_INTR_ENABLE 0x10
+/* Interrupt Persist Function: Any value outside of threshold range */
+#define APDS9300_THRESH_INTR 0x01
+
+#define APDS9300_THRESH_MAX0x /* Max threshold value */
+
+struct apds9300_data {
+ struct i2c_client *client;
+ struct mutex mutex;
+ int power_state;
+ int thresh_low;
+ int thresh_hi;
+ int intr_en;
+};
+
+/* Lux calculation */
+
+/* Calculated values 1000 * (CH1/CH0)^1.4 for CH1/CH0 from 0 to 0.52 */
+static const u16 apds9300_lux_ratio[] = {
+ 0, 2, 4, 7, 11, 15, 19, 24, 29, 34, 40, 45, 51, 57, 64, 70, 77, 84, 91,
+ 98, 105, 112, 120, 128, 136, 144, 152, 160,
[PATCH] Documentation: devres: add IIO device alloc/free functions to list
From: Oleksandr Kravchenko Add devm_iio_device_alloc() and devm_iio_device_free() functions to list of supported calls. Signed-off-by: Oleksandr Kravchenko --- Documentation/driver-model/devres.txt |4 1 file changed, 4 insertions(+) diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt index b467145..1d32332 100644 --- a/Documentation/driver-model/devres.txt +++ b/Documentation/driver-model/devres.txt @@ -237,6 +237,10 @@ MEM devm_kzalloc() devm_kfree() +IIO + devm_iio_device_alloc() + devm_iio_device_free() + IO region devm_request_region() devm_request_mem_region() -- 1.7.9.5 -- 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/
