> -----Original Message----- > From: Jonathan Cameron [mailto:jic23@xxxxxxxxxx] > Sent: Monday, August 31, 2015 9:56 AM > To: Michael Welling > Cc: Greg Wilson-Lindberg; linux-iio@xxxxxxxxxxxxxxx; Daniel Baluta > Subject: Re: Adding MAX1363 to BBB > > 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@xxxxxxxxx] On Behalf Of > >>>> Michael Welling > >>>> Sent: Friday, August 28, 2015 5:32 PM > >>>> To: Greg Wilson-Lindberg > >>>> Cc: linux-iio@xxxxxxxxxxxxxxx > >>>> 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. Not a problem, we don't need the monitor function. > > > > >>> > >>> 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. I'm converting back to that style, I should have it running in a bit. Greg > > Jonathan > > > >> > >> Jonathan > >>> -- > >>> To unsubscribe from this list: send the line "unsubscribe > linux-iio" > >>> in the body of a message to majordomo@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
