Re: Kernel wishlist item: Better IIO API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On 16 Nov 2014, at 23:12, Jonathan Cameron <jic23@xxxxxxxxxx> wrote:
> 
>> The driver used in the Onda tablet I have is far less featureful.
>> - find the accelerometer iio device (this time called "i2c-SMO8500:00")
>> - build the channel array (?? I haven't found how)
>> - read the scale of each axis
>> - read directly from the sysfs files for each axis (?? surely not) on a
>> regular basis, scale the values, and we have the 3 dimensions
> On this second one, the driver has trigger and buffer support
> (not all drivers have as it's optional - doesn't make any sense for very
> slow devices and adds some complexity).
> 
> However, looking at that driver - the interrupt is optional. If
> it's not there (i.e. either the pin isn't connected, or the relevant
> information isn't supplied to the driver to tell it which interrupt
> is in use) then the driver does indeed only enable the polled mode.
> That is, it doesn't set up either the trigger or the buffer.
> 
> So the question is whether the tablet really doesn't route that pin
> or whether there is an issue in the driver identifying it.
> 
> Looking briefly back at the patch that added support for the SM08500
> it was clear then that we didn't have the interrupt.
> Hence we are into the realms of polling at some level...

I'll try to ask somebody with Windows on that tablet whether there is an interrupt associated with the device or not. It could very well be a problem with the ACPI support on that tablet (I'm still chasing battery reporting...)

> It would be fine to add support to the driver for a trigger that
> instead of using the interrupt simply polls the device - ugly but
> about all we can do here.  Looks like reading the int_source1 register
> will tell us whether new data is available...
> 
> So in conclusion - the issue here is that a rather nasty work around
> is needed for either a bad configuration or non optimal hardware design.
> 
> Still I guess there isn't much we can do about it...

But without the scan_elements subdir, I can't know what the device would spit out, so I need to use sysfs directly, not the dev node. Is that correct?

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




[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Input]     [Linux Kernel]     [Linux SCSI]     [X.org]

  Powered by Linux