On 6 August 2015 16:03:56 BST, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: >On Wed, Aug 5, 2015 at 10:15 PM, Jonathan Cameron ><jic23@xxxxxxxxxxxxxxxxxxxxx> wrote: >> On 5 August 2015 10:28:15 BST, Linus Walleij ><linus.walleij@xxxxxxxxxx> wrote: >>> >>>The triggers from ST sensors are named <iio_device_name>-trigger >>>instead of the standard <iio_device_name>-dev<iio_dev_id> as >>>used by most and also in the iio-tools. Change this to match >>>the norm. >>> >>>After this I can do tests with generic_buffer -n <dev_name> >>>without having to manually specify the trigger with the -t >>>option. >> >> Hmm ABI change... Not a requirement that this naming be followed... > >Unless someone can provide a userspace that actually have the >ST sensors working (with mainline) I think we can make this change. > >I've really struggled to get generic_buffer going with the ST sensors >to no avail. Right now it seems to be because the *_en files in >/scan_elements are not ever written with "1" so consequently >iio_buffer_store_enable >__iio_update_buffers >iio_buffer_request_update >iio_buffer_update_bytes_per_datum > >Doesn't happen and bytes per datum is zero and it bails out. > >I don't know if it's a problem with generic_buffer though, is there >another userspace that everyone is using without telling me? Documentation problem rather than anything else. Those need setting manually prior to run as adding a configurable interface to enable them in generic buffer is way too fiddly. > >> Could register the trigger twice I suppose so as to keep old name >available.... > >Hm there are a couple of more actually using -trigger if there is a >single one. > >Maybe we should have generic_buffer looking for both rather, or >do you want to keep that tool simple? No objection to the little bit of extra code that would need. > >Yours, >Linus Walleij -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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
