All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Michael Welling <mwelling@ieee.org>
Cc: Greg Wilson-Lindberg <GWilson@sakuraus.com>,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
	Daniel Baluta <daniel.baluta@intel.com>
Subject: Re: Adding MAX1363 to BBB
Date: Mon, 31 Aug 2015 17:56:10 +0100	[thread overview]
Message-ID: <55E4872A.9080103@kernel.org> (raw)
In-Reply-To: <20150831165217.GB11095@deathstar>

On 31/08/15 17:52, Michael Welling wrote:
> On Mon, Aug 31, 2015 at 05:24:21PM +0100, Jonathan Cameron wrote:
>> On 31/08/15 17:01, Greg Wilson-Lindberg wrote:
>>>  
>>>
>>>> -----Original Message-----
>>>> From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
>>>> Of Michael Welling
>>>> Sent: Friday, August 28, 2015 5:32 PM
>>>> To: Greg Wilson-Lindberg
>>>> Cc: linux-iio@vger.kernel.org
>>>> Subject: Re: Adding MAX1363 to BBB
>>>>
>>>> On Fri, Aug 28, 2015 at 04:56:20PM -0700, Greg Wilson-Lindberg wrote:
>>>>>
>>>>> I've got the system running, but I get an invalid argument 
>>>> error on the call to iio_buffer_refill().  I'm basically 
>>>> using the same code as for the tsadc, just added in a fourth 
>>>> channel, and none of the setup calls are returning errors, 
>>>> but the first iio_buffer_refill() call returns an error.  
>>>> I've dumped out the parameter that is being passed to the 
>>>> iio_buffer_refill() call and it is the same as the value that 
>>>> was returned from the iio_device_create_buffer() call.
>>>>>
>>>>> I've looked at the libiio source and I don't see anything 
>>>> obvious that should return invalid argument for the 
>>>> iio_buffer_refill() call.
>>>>>
>>>>
>>>> I believe that you need to register an interrupt for buffered 
>>>> access to work.
>>>>
>>>> Do you have an interrupt connected and registered?
>>>>
>>>
>>> Nope, no interrupt.  So I guess I would need to ask, how would I register the interrupt in the Device Tree?
>> The max1363 (and similar) don't have a dataready interrupt as they
>> are clocked of the actual clock cycles of the i2c transfers.  So
>> they only read on demand.
>>
> 
> Ah, yes. Looking at the datasheet the interrupt is triggered by a window
> comparator not end of sample.
That takes me back. It was one of my first drivers ;)  They monitor
stuff is real pain as it does output normal readings when monitor
is running but only after a whole load of other stuff.  I think I got
lazy and decided not to unwind that but just to make the driver not
read the channels when monitor was enabled.

> 
>>>
>>> Or, alternatively, can I just get individual readings through IIO?
>> Either via sysfs, or by adding a sysfs trigger and poking that.
>> To add a sysfs trigger you'll need to probe the module, then poke
>> a number into the add_trigger attribute to create a trigger which can
>> then be associated with the max1363 (as normal).
>>
>> Then to 'fire' the trigger write to the trigger_now attribute of the
>> relevant trigger.
>>
>> Ideally Daniel will be back soonish with a final version of the
>> high resolution timer trigger that would also work well here.
>> (it's rather tied up with some configfs support which wis
>> trickier!).
> 
> It is probably easiest to sample using sysfs directly.
> 
> This would be same as the last method we tried while trying to
> access to TI ADC and touchscreen simultaneously.
> 
> http://www.spinics.net/lists/linux-iio/msg20577.html
That should work fine.

Jonathan
> 
>>
>> Jonathan
>>>  --
>>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


  reply	other threads:[~2015-08-31 16:56 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-24 16:26 Adding MAX1363 to BBB Greg Wilson-Lindberg
2015-08-24 16:54 ` Michael Welling
2015-08-24 17:09   ` Greg Wilson-Lindberg
2015-08-27 19:10   ` Greg Wilson-Lindberg
2015-08-27 19:16     ` Michael Welling
2015-08-27 20:40       ` Greg Wilson-Lindberg
2015-08-27 20:42         ` Michael Welling
2015-08-27 21:06           ` Greg Wilson-Lindberg
2015-08-27 21:44             ` Greg Wilson-Lindberg
2015-08-28 23:56               ` Greg Wilson-Lindberg
2015-08-29  0:32                 ` Michael Welling
2015-08-31 16:01                   ` Greg Wilson-Lindberg
2015-08-31 16:24                     ` Jonathan Cameron
2015-08-31 16:52                       ` Michael Welling
2015-08-31 16:56                         ` Jonathan Cameron [this message]
2015-08-31 16:59                           ` Greg Wilson-Lindberg

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=55E4872A.9080103@kernel.org \
    --to=jic23@kernel.org \
    --cc=GWilson@sakuraus.com \
    --cc=daniel.baluta@intel.com \
    --cc=linux-iio@vger.kernel.org \
    --cc=mwelling@ieee.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.