linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Welling <mwelling@ieee.org>
To: Felipe Balbi <balbi@ti.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Jonathan Cameron <jic23@kernel.org>,
	linux-iio@vger.kernel.org, pmeerw@pmeerw.net,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RESEND PATCH] iio: light: add support for TI's opt3001 light sensor
Date: Fri, 3 Oct 2014 22:17:21 -0500	[thread overview]
Message-ID: <20141004031721.GA2846@deathray> (raw)
In-Reply-To: <20141002180553.GI7933@saruman>

On Thu, Oct 02, 2014 at 01:05:53PM -0500, Felipe Balbi wrote:
> Hi,
> 
> On Tue, Sep 30, 2014 at 04:22:04PM -0500, Felipe Balbi wrote:
> > On Mon, Sep 29, 2014 at 06:41:59PM -0500, Michael Welling wrote:
> > > On Mon, Sep 29, 2014 at 05:46:38PM -0500, Felipe Balbi wrote:
> > > > Hi,
> > > > 
> > > > On Mon, Sep 29, 2014 at 05:38:33PM -0500, Michael Welling wrote:
> > > > > > > > Alright, this is already ridiculous. Andrew, if I resend the patch can
> > > > > > > > you apply it since maintainer has been ignoring this thread anyway ?
> > > > > > > > 
> > > > > > > 
> > > > > > > Do you reall think this is the best way to approach this?
> > > > > > 
> > > > > > when maintainer doesn't respond for weeks, yeah! Sure it is.
> > > > > > 
> > > > > > > Perhaps it would be better to explain what each field of the
> > > > > > > configuration register does and then we can move on.
> > > > > > 
> > > > > > perhaps Jonathan could tell me exactly what he wants because I can't
> > > > > > handle back-and-forth anymore. Specially when he complains about stuff
> > > > > > he asked me to modify himself.
> > > > > >
> > > > > > > In particular the OPT3001_CONFIGURATION_L field needs to be explained
> > > > > > > such that the ABI can be properly applied.
> > > > > > > 
> > > > > > > Looking at the docs for the Windows demo program the field is associated
> > > > > > > with a latch configuration. What does this bit field actually do?
> > > > > 
> > > > > Still no technical information. Without all the facts how can you expect
> > > > > him to tell you what he wants?
> > > > 
> > > > yeah, because clearly he doesn't know himself, right ?
> > > 
> > > Could you explain how it works to me then?
> > 
> > checking how much of the docs I can expose now, gimme a couple days.
> 
> alright, here's a snippet of what's on preliminary docs:
> 

Firstly, there is logical error in the latest code.
The hysteresis setting is 0 not 1.

+       if (opt->hysteresis)
+               reg |= OPT3001_CONFIGURATION_L;
+       else
+               reg &= ~OPT3001_CONFIGURATION_L;


> Latch field (read or write).
> The latch field controls the functionality of the interrupt reporting
> mechanisms: the INT pin, the flag high field (FH), and flag low field (FL).
> This bit selects the reporting style between a latched window-style comparison
> and a transparent hysteresis-style comparison.
> 
> 0 = The device functions in transparent hysteresis-style comparison operation,
> where the three interrupt reporting mechanisms directly reflect the comparison
> of the result register with the high- and low-limit registers with no
> user-controlled clearing event. See the Interrupt Operation, INT Pin, and
> Interrupt Reporting Mechanisms section for further details.
> 
> 1 = The device functions in latched window-style comparison operation, latching
> the interrupt reporting mechanisms until a user-controlled clearing event.
> 

How is the interrupt cleared in mode 1 in the latest version of your
code?

> [...]
> 
> 7.4.2.2 Transparent Hysteresis-Style Comparison Mode
> The transparent hysteresis-style comparison mode is typically used when a
> single digital signal is desired that indicates whether the input light is
> higher than or lower than a light level of interest. If the result register is
> higher than the high-limit register for a consecutive number of events set by
> the fault count field, the INT line is set to active, the flag high field is
> set to 1, and the flag low field is set to 0. If the result register is lower
> than the lowlimit register for a consecutive number of events set by the fault
> count field, the INT line is set to inactive, the flag low field is set to 1,
> and the flag high field is set to 0. The INT pin and flag high and flag low
> fields do not change state with configuration reads and writes. The INT pin and
> flag fields continually report the appropriate comparison of the light to the
> low-limit and high-limit registers. The device does not respond to the SMBus
> alert response protocol while in either of the two transparent comparison modes
> (configuration register, latch field = 0).
> 

The ABI confusion starts here.

You are dealing with a mode enable and IIO_EV_INFO_HYSTERESIS is associated
with a the hysteresis level of a threshold event.

http://lxr.free-electrons.com/source/Documentation/ABI/testing/sysfs-bus-iio#L605

You are going to have abstract the register access to conform to the ABI or add
to the ABI as Jonathan suggests.

> -- 
> balbi



  reply	other threads:[~2014-10-04  3:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20140915052137.GA11866@saruman.home>
     [not found] ` <20140916170316.GD19010@saruman.home>
     [not found]   ` <20140917150041.GA6903@saruman.home>
     [not found]     ` <20140918133631.GA24847@saruman.home>
     [not found]       ` <20140919162129.GE26946@saruman.home>
     [not found]         ` <20140922140914.GC25620@saruman>
     [not found]           ` <20140923140924.GA28592@saruman>
     [not found]             ` <20140924143610.GA17997@saruman>
     [not found]               ` <20140925221619.GA10644@saruman>
     [not found]                 ` <20140927041959.GA28445@saruman>
2014-09-29 14:02                   ` [RESEND PATCH] iio: light: add support for TI's opt3001 light sensor Felipe Balbi
2014-09-29 17:14                     ` Jonathan Cameron
2014-09-29 18:38                     ` Michael Welling
2014-09-29 18:53                       ` Felipe Balbi
2014-09-29 19:07                         ` Daniel Baluta
2014-09-29 19:45                           ` Felipe Balbi
2014-09-29 22:38                         ` Michael Welling
2014-09-29 22:46                           ` Felipe Balbi
2014-09-29 23:41                             ` Michael Welling
2014-09-30 21:22                               ` Felipe Balbi
2014-10-02 18:05                                 ` Felipe Balbi
2014-10-04  3:17                                   ` Michael Welling [this message]
2014-10-04  9:43                                     ` Jonathan Cameron
2014-10-06 19:54                                       ` Felipe Balbi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141004031721.GA2846@deathray \
    --to=mwelling@ieee.org \
    --cc=akpm@linux-foundation.org \
    --cc=balbi@ti.com \
    --cc=jic23@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmeerw@pmeerw.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).