<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in Kconfig</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>c8283ba8 - iio: buffer: Kconfig: add title for IIO_TRIGGERED_BUFFER symbol</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/iio/buffer/Kconfig#c8283ba8</link>
        <description>iio: buffer: Kconfig: add title for IIO_TRIGGERED_BUFFER symbolFor some embedded systems, a workflow involving external kernel modulesthat implement IIO devices is more practical than working with in-treesources.Kconfig symbols without any titles do not show up in menuconfig, and assuch are more difficult to configure granularly, as they need to beselected by potentially unused/un-needed drivers.This change adds a title to the IIO_TRIGGERED_BUFFER Kconfig symbol.Signed-off-by: Alexandru Ardelean &lt;alexandru.ardelean@analog.com&gt;Link: https://lore.kernel.org/r/20200924111758.196367-4-alexandru.ardelean@analog.comSigned-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;

            List of files:
            /linux-6.15/drivers/iio/buffer/Kconfig</description>
        <pubDate>Thu, 24 Sep 2020 11:17:58 +0000</pubDate>
        <dc:creator>Alexandru Ardelean &lt;alexandru.ardelean@analog.com&gt;</dc:creator>
    </item>
<item>
        <title>3cd137f5 - iio: dma-buffer: Kconfig: Provide titles for IIO DMA Kconfig symbols</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/iio/buffer/Kconfig#3cd137f5</link>
        <description>iio: dma-buffer: Kconfig: Provide titles for IIO DMA Kconfig symbolsFor some embedded systems, a workflow involving external kernel modulesthat implement IIO devices is more practical than working with in-treesources.Kconfig symbols without any titles do not show up in menuconfig, and assuch are more difficult to configure granularly, as they need to beselected by potentially unused/un-needed drivers.This change adds titles to the IIO DMA Kconfig symbols to address this.This change also updates DMAengine -&gt; DMAEngine, which is thecorrect/nitpick-y name of the framework.Signed-off-by: Alexandru Ardelean &lt;alexandru.ardelean@analog.com&gt;Link: https://lore.kernel.org/r/20200924111758.196367-2-alexandru.ardelean@analog.comSigned-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;

            List of files:
            /linux-6.15/drivers/iio/buffer/Kconfig</description>
        <pubDate>Thu, 24 Sep 2020 11:17:56 +0000</pubDate>
        <dc:creator>Alexandru Ardelean &lt;alexandru.ardelean@analog.com&gt;</dc:creator>
    </item>
<item>
        <title>ec8f24b7 - treewide: Add SPDX license identifier - Makefile/Kconfig</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/iio/buffer/Kconfig#ec8f24b7</link>
        <description>treewide: Add SPDX license identifier - Makefile/KconfigAdd SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any formThese files fall under the project license, GPL v2 only. The resulting SPDXlicense identifier is:  GPL-2.0-onlySigned-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

            List of files:
            /linux-6.15/drivers/iio/buffer/Kconfig</description>
        <pubDate>Sun, 19 May 2019 12:07:45 +0000</pubDate>
        <dc:creator>Thomas Gleixner &lt;tglx@linutronix.de&gt;</dc:creator>
    </item>
<item>
        <title>48b66f8f - iio: Add hardware consumer buffer support</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/iio/buffer/Kconfig#48b66f8f</link>
        <description>iio: Add hardware consumer buffer supportHardware consumer interface can be used when one IIO device hasa direct connection to another device in hardware.Signed-off-by: Lars-Peter Clausen &lt;lars@metafoo.de&gt;Signed-off-by: Arnaud Pouliquen &lt;arnaud.pouliquen@st.com&gt;Reviewed-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;

            List of files:
            /linux-6.15/drivers/iio/buffer/Kconfig</description>
        <pubDate>Wed, 10 Jan 2018 10:13:03 +0000</pubDate>
        <dc:creator>Lars-Peter Clausen &lt;lars@metafoo.de&gt;</dc:creator>
    </item>
<item>
        <title>2d6ca60f - iio: Add a DMAengine framework based buffer</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/iio/buffer/Kconfig#2d6ca60f</link>
        <description>iio: Add a DMAengine framework based bufferAdd a generic fully device independent DMA buffer implementation that usesthe DMAegnine framework to perform the DMA transfers. This can be used byconverter drivers that whish to provide a DMA buffer for converters thatare connected to a DMA core that implements the DMAengine API.Apart from allocating the buffer using iio_dmaengine_buffer_alloc() andfreeing it using iio_dmaengine_buffer_free() no additional converter driverspecific code is required when using this DMA buffer implementation.Signed-off-by: Lars-Peter Clausen &lt;lars@metafoo.de&gt;Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;

            List of files:
            /linux-6.15/drivers/iio/buffer/Kconfig</description>
        <pubDate>Tue, 13 Oct 2015 16:10:29 +0000</pubDate>
        <dc:creator>Lars-Peter Clausen &lt;lars@metafoo.de&gt;</dc:creator>
    </item>
<item>
        <title>670b19ae - iio: Add generic DMA buffer infrastructure</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/iio/buffer/Kconfig#670b19ae</link>
        <description>iio: Add generic DMA buffer infrastructureThe traditional approach used in IIO to implement buffered capture requiresthe generation of at least one interrupt per sample. In the interrupthandler the driver reads the sample from the device and copies it to asoftware buffer. This approach has a rather large per sample overheadassociated with it. And while it works fine for samplerates in the range ofup to 1000 samples per second it starts to consume a rather large share ofthe available CPU processing time once we go beyond that, this isespecially true on an embedded system with limited processing power. Theregular interrupt also causes increased power consumption by not allowingthe hardware into deeper sleep states, which is something that becomes moreand more important on mobile battery powered devices.And while the recently added watermark support mitigates some of the issuesby allowing the device to generate interrupts at a rate lower than the dataoutput rate, this still requires a storage buffer inside the device andeven if it exists it is only a few 100 samples deep at most.DMA support on the other hand allows to capture multiple millions or evenmore samples without any CPU interaction. This allows the CPU to either goto sleep for longer periods or focus on other tasks which increases overallsystem performance and power consumption. In addition to that some devicesmight not even offer a way to read the data other than using DMA, whichmakes DMA mandatory to use for them.The tasks involved in implementing a DMA buffer can be divided into twocategories. The first category is memory buffer management (allocation,mapping, etc.) and hooking this up the IIO buffer callbacks like read(),enable(), disable(), etc. The second category of tasks is to setup theDMA hardware and manage the DMA transfers. Tasks from the first categorywill be very similar for all IIO drivers supporting DMA buffers, while thetasks from the second category will be hardware specific.This patch implements a generic infrastructure that take care of the formertasks. It provides a set of functions that implement the standard IIObuffer iio_buffer_access_funcs callbacks. These can either be used as is orbe overloaded and augmented with driver specific code where necessary.For the DMA buffer support infrastructure that is introduced in this seriessample data is grouped by so called blocks. A block is the basic unit atwhich data is exchanged between the application and the hardware. Theapplication is responsible for allocating the memory associated with theblock and then passes the block to the hardware. When the hardware hascaptured the amount of samples equal to size of a block it will notify theapplication, which can then read the data from the block and process it.The block size can freely chosen (within the constraints of the hardware).This allows to make a trade-off between latency and management overhead.The larger the block size the lower the per sample overhead but the latencybetween when the data was captured and when the application will be able toaccess it increases, in a similar way smaller block sizes have a larger persample management overhead but a lower latency. The ideal block size thusdepends on system and application requirements.For the time being the infrastructure only implements a simple doublebuffered scheme which allocates two blocks each with half the size of theconfigured buffer size. This provides basic support for capturingcontinuous uninterrupted data over the existing file-IO ABI. Futureextensions to the DMA buffer infrastructure will give applications a morefine grained control over how many blocks are allocated and the size ofeach block. But this requires userspace ABI additions which areintentionally not part of this patch and will be added separately.Tasks of the second category need to be implemented by a device specificdriver. They can be hooked up into the generic infrastructure using twosimple callbacks, submit() and abort().The submit() callback is used to schedule DMA transfers for blocks. Once aDMA transfer has been completed it is expected that the buffer driver callsiio_dma_buffer_block_done() to notify. The abort() callback is used forstopping all pending and active DMA transfers when the buffer is disabled.Signed-off-by: Lars-Peter Clausen &lt;lars@metafoo.de&gt;Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;

            List of files:
            /linux-6.15/drivers/iio/buffer/Kconfig</description>
        <pubDate>Tue, 13 Oct 2015 16:10:28 +0000</pubDate>
        <dc:creator>Lars-Peter Clausen &lt;lars@metafoo.de&gt;</dc:creator>
    </item>
<item>
        <title>8548a63b - iio: Move generic buffer implementations to sub-directory</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/iio/buffer/Kconfig#8548a63b</link>
        <description>iio: Move generic buffer implementations to sub-directoryFor generic IIO trigger implementations we already have a sub-directory,but the generic buffer implementations currently reside in the IIOtop-level directory. The main reason is that things have historically growninto this form.With more generic buffer implementations on its way now is the perfect timeto clean this up and introduce a sub-directory for generic bufferimplementations to avoid too much clutter in the top-level directory.Signed-off-by: Lars-Peter Clausen &lt;lars@metafoo.de&gt;Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;

            List of files:
            /linux-6.15/drivers/iio/buffer/Kconfig</description>
        <pubDate>Fri, 14 Aug 2015 14:54:55 +0000</pubDate>
        <dc:creator>Lars-Peter Clausen &lt;lars@metafoo.de&gt;</dc:creator>
    </item>
</channel>
</rss>
