linux-toradex.git/include/linux/iio/iio.h, branch v6.2-rc8

iio: core: move 'mlock' to 'struct iio_dev_opaque'

2022-11-23T19:44:00+00:00

Now that there are no more users accessing 'mlock' directly, we can move
it to the iio_dev private structure. Hence, it's now explicit that new
driver's should not directly use this lock.

Signed-off-by: Nuno Sá 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20221012151620.1725215-5-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron

iio: core: introduce iio_device_{claim|release}_buffer_mode() APIs

2022-11-23T19:43:59+00:00

These APIs are analogous to iio_device_claim_direct_mode() and
iio_device_release_direct_mode() but, as the name suggests, with the
logic flipped. While this looks odd enough, it will have at least two
users (in following changes) and it will be important to move the IIO
mlock to the private struct.

Signed-off-by: Nuno Sá 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20221012151620.1725215-2-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron

iio: inkern: remove OF dependencies

2022-08-15T21:30:00+00:00

Since all users of the OF dependendent API are now converted to use the
firmware agnostic alternative, we can drop OF dependencies from the IIO
in kernel interface.

Signed-off-by: Nuno Sá 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20220715122903.332535-15-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron

iio: inkern: move to fwnode properties

2022-08-15T21:29:59+00:00

This moves the IIO in kernel interface to use fwnode properties and thus
be firmware agnostic.

Note that the interface is still not firmware agnostic. At this point we
have both OF and fwnode interfaces so that we don't break any user. On
top of this we also want to have a per driver conversion and that is the
main reason we have both of_xlate() and fwnode_xlate() support.

Signed-off-by: Nuno Sá 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20220715122903.332535-6-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron

iio: trigger: move trig->owner init to trigger allocate() stage

2022-07-16T15:24:19+00:00

To provide a new IIO trigger to the IIO core, usually driver executes the
following pipeline: allocate()/register()/get(). Before, IIO core assigned
trig->owner as a pointer to the module which registered this trigger at
the register() stage. But actually the trigger object is owned by the
module earlier, on the allocate() stage, when trigger object is
successfully allocated for the driver.

This patch moves trig->owner initialization from register()
stage of trigger initialization pipeline to allocate() stage to
eliminate all misunderstandings and time gaps between trigger object
creation and owner acquiring.

Signed-off-by: Dmitry Rokosov 
Link: https://lore.kernel.org/r/20220601174837.20292-1-ddrokosov@sberdevices.ru
Signed-off-by: Jonathan Cameron

iio: core: drop of.h from iio.h

2022-06-15T21:07:09+00:00

There is no reason to include OF as we only need to forward declare
'of_phandle_args'. Previously, some drivers were actually relying on
this for some headers (those were already fixed).

Signed-off-by: Nuno Sá 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20220610084545.547700-20-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron

iio: core: Fix IIO_ALIGN and rename as it was not sufficiently large

2022-06-14T10:53:11+00:00

Discussion of the series:
https://lore.kernel.org/all/20220405135758.774016-1-catalin.marinas@arm.com/
mm, arm64: Reduce ARCH_KMALLOC_MINALIGN brought to my attention that
our current IIO usage of L1CACHE_ALIGN is insufficient as their are Arm
platforms out their with non coherent DMA and larger cache lines at
at higher levels of their cache hierarchy.

Rename the define to make it's purpose more explicit. It will be used
much more widely going forwards (to replace incorrect ____cacheline_aligned
markings.

Note this patch will greatly reduce the padding on some architectures
that have smaller requirements for DMA safe buffers.

The history of changing values of ARCH_KMALLOC_MINALIGN via
ARCH_DMA_MINALIGN on arm64 is rather complex. I'm not tagging this
as fixing a particular patch from that route as it's not clear what to tag.

Most recently a change to bring them back inline was reverted because
of some Qualcomm Kryo cores with an L2 cache with 128-byte lines
sitting above the point of coherency.

c1132702c71f Revert "arm64: cache: Lower ARCH_DMA_MINALIGN to 64 (L1_CACHE_BYTES)"
That reverts:
65688d2a05de arm64: cache: Lower ARCH_DMA_MINALIGN to 64 (L1_CACHE_BYTES) which
refers to the change originally being motivated by Thunder x1 performance
rather than correctness.

Fixes: 6f7c8ee585e9d ("staging:iio: Add ability to allocate private data space to iio_allocate_device")
Signed-off-by: Jonathan Cameron
Acked-by: Nuno Sá
Link: https://lore.kernel.org/r/20220508175712.647246-2-jic23@kernel.org

iio: core: drop iio_get_time_res()

2022-06-14T10:53:09+00:00

This function was introduced with the ability to pick a clock.
There are no upstream users so presumably it isn't as obviously useful
as it seemed at the time.  Hence drop it.

Signed-off-by: Jonathan Cameron 
Link: https://lore.kernel.org/r/20220220163327.424696-1-jic23@kernel.org

iio: core: Clarify the modes

2022-04-28T18:22:48+00:00

As part of a previous discussion with Jonathan Cameron [1], it appeared
necessary to clarify the meaning of each mode so that new developers
could understand better what they should use or not use and when.

The idea of renaming these modes as been let aside because naming is a
big deal and requires a lot of thinking. So for now let's focus on
correctly explaining what each mode implies.

[1] https://lore.kernel.org/linux-iio/20210930165510.2295e6c4@jic23-huawei/

Suggested-by: Jonathan Cameron 
Signed-off-by: Miquel Raynal 
Link: https://lore.kernel.org/r/20220207143840.707510-14-miquel.raynal@bootlin.com
Signed-off-by: Jonathan Cameron

iio: core: Move the currentmode entry to the opaque structure

2022-04-10T15:23:01+00:00

This entry should, under no situation, be modified by device
drivers. Now that we have limited its read access to device drivers
really needing it and did so through a dedicated helper, we can
easily move this variable to the opaque structure in order to
prevent any further modification from non-authorized code (out of the
core, basically).

Signed-off-by: Miquel Raynal 
Reviewed-by: Alexandru Ardelean 
Link: https://lore.kernel.org/r/20220207143840.707510-12-miquel.raynal@bootlin.com
Signed-off-by: Jonathan Cameron