rivers/hid/wacom_sys.c | 2 +-
> include/linux/intel-ish-client-if.h | 8 +++-
> 24 files changed, 90 insertions(+), 81 deletions(-)
>
> Cc: Alexandre Torgue
> Cc: Anssi Hannula
> Cc: Benjamin Tissoires
> Cc: "Bruno Prémont"
> Cc:
On Mon, 14 Mar 2022 15:16:29 +0100
Uwe Kleine-König wrote:
> When a driver keeps a clock prepared (or enabled) during the whole
> lifetime of the driver, these helpers allow to simplify the drivers.
>
> Reviewed-by: Jonathan Cameron
> Reviewed-by: Alexandru Ardelean
On Mon, 7 Feb 2022 12:59:22 +
Paul Cercueil wrote:
> The buffer-dma code was using two queues, incoming and outgoing, to
> manage the state of the blocks in use.
>
> While this totally works, it adds some complexity to the code,
> especially since the code only manages 2 blocks. It is much
On Mon, 7 Feb 2022 12:59:23 +
Paul Cercueil wrote:
> Adding write support to the buffer-dma code is easy - the write()
> function basically needs to do the exact same thing as the read()
> function: dequeue a block, read or write the data, enqueue the block
> when entirely processed.
>
> Th
On Mon, 7 Feb 2022 12:59:25 +
Paul Cercueil wrote:
> Use the iio_dma_buffer_write() and iio_dma_buffer_space_available()
> functions provided by the buffer-dma core, to enable write support in
> the buffer-dmaengine code.
>
> Signed-off-by: Paul Cercueil
> Reviewed-by: Alexandru Ardelean
On Mon, 7 Feb 2022 12:59:26 +
Paul Cercueil wrote:
> Add the necessary infrastructure to the IIO core to support a new
> optional DMABUF based interface.
>
> The advantage of this new DMABUF based interface vs. the read()
> interface, is that it avoids an extra copy of the data between the
On Mon, 7 Feb 2022 12:59:28 +
Paul Cercueil wrote:
> Enhance the current fileio code by using DMABUF objects instead of
> custom buffers.
>
> This adds more code than it removes, but:
> - a lot of the complexity can be dropped, e.g. custom kref and
> iio_buffer_block_put_atomic() are not
On Tue, 16 Nov 2021 12:59:30 +0200
Alexandru Ardelean wrote:
> On Mon, Nov 15, 2021 at 4:20 PM Paul Cercueil wrote:
> >
> > From: Alexandru Ardelean
> >
> > A part of the logic in the iio_dma_buffer_exit() is required for the change
> > to add mmap support to IIO buffers.
> > This change splits
On Mon, 15 Nov 2021 14:19:10 +
Paul Cercueil wrote:
> Hi Jonathan,
>
> This patchset introduces a new userspace interface based on DMABUF
> objects, to complement the existing fileio based API.
>
> The advantage of this DMABUF based interface vs. the fileio
> interface, is that it avoids an
On Mon, 15 Nov 2021 14:19:11 +
Paul Cercueil wrote:
> The buffer-dma code was using two queues, incoming and outgoing, to
> manage the state of the blocks in use.
>
> While this totally works, it adds some complexity to the code,
> especially since the code only manages 2 blocks. It is much
On Mon, 15 Nov 2021 14:19:13 +
Paul Cercueil wrote:
> We know that the buffer's alignment will always be a power of two;
> therefore, we can use the faster round_down() macro.
>
> Signed-off-by: Paul Cercueil
*groan*. I don't want to know where the naming of these two came from but that
is
On Mon, 15 Nov 2021 14:19:14 +
Paul Cercueil wrote:
> Adding write support to the buffer-dma code is easy - the write()
> function basically needs to do the exact same thing as the read()
> function: dequeue a block, read or write the data, enqueue the block
> when entirely processed.
>
> Th
On Mon, 15 Nov 2021 14:19:17 +
Paul Cercueil wrote:
> Add the necessary infrastructure to the IIO core to support a new DMABUF
> based interface.
>
> The advantage of this new DMABUF based interface vs. the read()
> interface, is that it avoids an extra copy of the data between the
> kernel
On Mon, 15 Nov 2021 14:19:21 +
Paul Cercueil wrote:
> We can be certain that the input buffers will only be accessed by
> userspace for reading, and output buffers will mostly be accessed by
> userspace for writing.
Mostly? Perhaps a little more info on why that's not 'only'.
>
> Therefor
On Mon, 15 Nov 2021 14:22:43 +
Paul Cercueil wrote:
> Document the new DMABUF based API.
>
> Signed-off-by: Paul Cercueil
Hi Paul,
A few trivial things inline but looks good to me if we do end up using DMABUF
anyway.
Jonathan
> ---
> Documentation/driver-api/dma-buf.rst | 2 +
> Docum
On Sun, 21 Nov 2021 17:43:20 +
Paul Cercueil wrote:
> Hi Jonathan,
>
> Le dim., nov. 21 2021 at 15:00:37 +, Jonathan Cameron
> a écrit :
> > On Mon, 15 Nov 2021 14:19:21 +
> > Paul Cercueil wrote:
> >
> >> We can be certain that the
On Mon, 22 Nov 2021 10:00:19 +
Paul Cercueil wrote:
> Hi Jonathan,
>
> Le dim., nov. 21 2021 at 14:08:23 +, Jonathan Cameron
> a écrit :
> > On Mon, 15 Nov 2021 14:19:13 +
> > Paul Cercueil wrote:
> >
> >> We know that the buffer
On Sun, 21 Nov 2021 17:19:32 +
Paul Cercueil wrote:
> Hi Jonathan,
>
> Le dim., nov. 21 2021 at 14:20:49 +, Jonathan Cameron
> a écrit :
> > On Mon, 15 Nov 2021 14:19:14 +
> > Paul Cercueil wrote:
> >
> >> Adding write support to
On Thu, 25 Nov 2021 17:29:58 +
Paul Cercueil wrote:
> Hi Jonathan,
>
> Le dim., nov. 21 2021 at 17:43:20 +, Paul Cercueil
> a écrit :
> > Hi Jonathan,
> >
> > Le dim., nov. 21 2021 at 15:00:37 +, Jonathan Cameron
> > a écrit :
> >>
On Mon, 21 Dec 2020 16:46:59 -0700
Rob Herring wrote:
> *-supply properties are always a single phandle, so binding schemas
> don't need a type $ref nor 'maxItems'.
>
> A meta-schema check for this is pending once these existing cases are
> fixed.
>
>
> Cc: Thierry Reding
> Cc: MyungJoo Ham
> Cc: Chanwoo Choi
> Cc: Linus Walleij
> Cc: Bartosz Golaszewski
> Cc: Jonathan Cameron
> Cc: Dmitry Torokhov
> Cc: Thomas Gleixner
> Cc: Marc Zyngier
> Cc: Mauro Carvalho Chehab
> Cc: Chen-Yu Tsai
> Cc: Ulf H
> >
> > > +
> > > +#define MT6370_AICR_400MA0x6
> > > +#define MT6370_ICHG_500MA0x4
> > > +#define MT6370_ICHG_900MA0x8
> > > +
> > > +#define ADC_CONV_TIME_US 35000
> > > +#define ADC_CONV_POLLING_TIME1000
> > > +
> > > +struct mt63
On Mon, 13 Jun 2022 19:11:38 +0800
ChiaEn Wu wrote:
> From: ChiaEn Wu
>
> Add ABI documentation for mt6370 non-standard ADC sysfs interfaces.
>
> Signed-off-by: ChiaEn Wu
> ---
> .../ABI/testing/sysfs-bus-iio-adc-mt6370 | 36 +++
> 1 file changed, 36 insertions(+)
> cre
On Mon, 13 Jun 2022 19:11:39 +0800
ChiaEn Wu wrote:
> From: ChiYuan Huang
>
> Add Mediatek MT6370 MFD support.
>
> Signed-off-by: ChiYuan Huang
Hi.
A few trivial things that probably overlap with other reviewer
comments.
> +static int mt6370_check_vendor_info(struct mt6370_info *info)
> +{
On Mon, 13 Jun 2022 19:11:42 +0800
ChiaEn Wu wrote:
> From: ChiaEn Wu
>
> Add Mediatek MT6370 ADC support.
>
> Signed-off-by: ChiaEn Wu
Hi ChiaEn Wu,
A few comments inline, but mostly looks good to me
with the exception of the scales which look far too large.
Thanks,
Jonathan
> ---
> dr
On Mon, 20 Jun 2022 14:00:43 +0800
ChiaEn Wu wrote:
> Hi Jonathan,
>
> Thanks for your helpful comments, and I have some questions want to
> ask you below.
>
> Jonathan Cameron 於 2022年6月18日 週六 晚上11:39寫道:
> >
> > On Mon, 13 Jun 2022 19:11:38 +0800
> > ChiaEn
On Mon, 7 Feb 2022 12:59:21 +
Paul Cercueil wrote:
> Hi Jonathan,
>
> This is the V2 of my patchset that introduces a new userspace interface
> based on DMABUF objects to complement the fileio API, and adds write()
> support to the existing fileio API.
Hi Paul,
It's been a little while. P
On Mon, 7 Feb 2022 12:59:22 +
Paul Cercueil wrote:
> The buffer-dma code was using two queues, incoming and outgoing, to
> manage the state of the blocks in use.
>
> While this totally works, it adds some complexity to the code,
> especially since the code only manages 2 blocks. It is much
ms' list, then a 'minItems' or 'maxItems' with the
> same size as the list is redundant and can be dropped. Note that is DT
> schema specific behavior and not standard json-schema behavior. The tooling
> will fixup the final schema adding any unspecified minItems/ma
and include instead in the SPI controller bindings. The controller
> bindings will provide CPHA/CPOL type validation and one place for
> description. Each device schema must list the properties if they are
> applicable.
>
> Suggested-by: Jonathan Cameron
> Suggested-by
& Power Delivery controller in
> > MediaTek MT6370 IC.
>
> Reviewed-by: Andy Shevchenko
Oops. I just noticed I replied only to Andy due to a misclick.
Acked-by: Jonathan Cameron
I took a quick glance through, and with Andy's comments now all answered
to his satisfaction
On Tue, 9 Aug 2022 14:14:14 +0100
Lee Jones wrote:
> On Fri, 05 Aug 2022, ChiaEn Wu wrote:
>
> > From: ChiYuan Huang
> >
> > Add MediaTek MT6370 binding documentation.
> >
> > Reviewed-by: Krzysztof Kozlowski
> > Signed-off-by: ChiYuan Huang
> > Signed-off-by: ChiaEn Wu
> > ---
> > .../de
improved meta-schema is pending.
>
...
> .../devicetree/bindings/iio/adc/amlogic,meson-saradc.yaml | 1 -
For this one, the fact it overrides maxItems elsewhere makes this a little
bit odd. I guess we can get used to it being implicit.
> .../devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml | 2 --
Acked-by: Jonathan Cameron
s_gpiod
> members of the spi_device structure would be converted to arrays & the
> "idx" parameter of the APIs would be used as array index i.e.,
> spi->chip_select[idx] & spi->cs_gpiod[idx] respectively.
>
> Signed-off-by: Amit Kumar Mahapatra
Acked-by:
eck for this is pending, so hopefully the last time to
> fix these.
>
> Fix the indentation in intel,phy-thunderbay-emmc while we're here.
>
> Signed-off-by: Rob Herring
Acked-by: Jonathan Cameron #for-iio
> ---
> .../arm/tegra/nvidia,tegra-ccplex-cluster.yaml|
On Tue, 18 Apr 2023 10:08:21 +0200
Paul Cercueil wrote:
> Hi Jonathan,
>
> Le dimanche 16 avril 2023 à 15:24 +0100, Jonathan Cameron a écrit :
> > On Mon, 3 Apr 2023 17:47:52 +0200
> > Paul Cercueil wrote:
> >
> > > The buffer-dma code was using t
On Mon, 3 Apr 2023 17:47:52 +0200
Paul Cercueil wrote:
> The buffer-dma code was using two queues, incoming and outgoing, to
> manage the state of the blocks in use.
>
> While this totally works, it adds some complexity to the code,
> especially since the code only manages 2 blocks. It is much
On Mon, 3 Apr 2023 17:47:53 +0200
Paul Cercueil wrote:
> Adding write support to the buffer-dma code is easy - the write()
> function basically needs to do the exact same thing as the read()
> function: dequeue a block, read or write the data, enqueue the block
> when entirely processed.
>
> Th
On Mon, 3 Apr 2023 17:47:54 +0200
Paul Cercueil wrote:
> Update the devm_iio_dmaengine_buffer_setup() function to support
> specifying the buffer direction.
>
> Update the iio_dmaengine_buffer_submit() function to handle input
> buffers as well as output buffers.
>
> Signed-off-by: Paul Cercue
On Mon, 3 Apr 2023 17:47:55 +0200
Paul Cercueil wrote:
> Use the iio_dma_buffer_write() and iio_dma_buffer_space_available()
> functions provided by the buffer-dma core, to enable write support in
> the buffer-dmaengine code.
>
> Signed-off-by: Paul Cercueil
> Reviewed-by: Alexandru Ardelean
On Mon, 3 Apr 2023 17:47:56 +0200
Paul Cercueil wrote:
> Add the necessary infrastructure to the IIO core to support a new
> optional DMABUF based interface.
>
> With this new interface, DMABUF objects (externally created) can be
> attached to a IIO buffer, and subsequently used for data transf
On Mon, 3 Apr 2023 17:47:58 +0200
Paul Cercueil wrote:
> Implement iio_dma_buffer_attach_dmabuf(), iio_dma_buffer_detach_dmabuf()
> and iio_dma_buffer_transfer_dmabuf(), which can then be used by the IIO
> DMA buffer implementations.
>
> Signed-off-by: Paul Cercueil
Hi Paul,
A few superficial
On Mon, 3 Apr 2023 17:49:54 +0200
Paul Cercueil wrote:
> Use the functions provided by the buffer-dma core to implement the
> DMABUF userspace API in the buffer-dmaengine IIO buffer implementation.
>
> Since we want to be able to transfer an arbitrary number of bytes and
> not necesarily the fu
On Fri, 17 Mar 2023 16:40:16 +0200
Matti Vaittinen wrote:
> Support ROHM BU27034 ALS sensor
Hi Matti,
For ease of when this is ready to apply, better to just keep
key mailing lists and individuals cc'd on all patches.
Mind you cc list is random enough I'm guessing it wasn't
deliberate (like th
On Sun, 2 Jul 2023 20:23:08 +0200
Krzysztof Kozlowski wrote:
> The DTS code coding style expects spaces around '=' sign.
>
> Signed-off-by: Krzysztof Kozlowski
>
For the IIO one.
Acked-by: Jonathan Cameron
Thanks for tidying these up.
Jonathan
> ---
>
> Ro
ect.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-...@lists.infradead.org
> Cc: linux-ser...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Rob Herring
Acked-by: Jonathan Cameron #for-iio
> ---
> .../display/bridge/toshiba,tc358775.yaml | 18
so let's fix all
> those occurrences.
>
> Cc: Stephen Boyd
> Cc: Linus Walleij
> Cc: Bartosz Golaszewski
> Cc: Masahiro Yamada
> Cc: Jonathan Cameron
> Cc: Hartmut Knaack
> Cc: Lars-Peter Clausen
> Cc: Peter Meerwald-Stadler
> Cc: Neil Armstrong
> Cc:
ree/bindings/iio/accel/adi,adxl345.yaml
> >
> > The trivial-devices binding doesn't capture that 'adi,adxl346' has a
> > fallback compatible 'adi,adxl345', so let's add it to adi,adxl345.yaml.
> >
>
> Acked-by: Alexandru Ardelean
Ack
bus specific properties such as 'spi-max-frequency' that go into
> bus child nodes, but aren't defined in the child node's schema.
>
> So let's stick with the json-schema defined default and add
> 'additionalProperties: false' where needed. This will be
On Thu, 16 Apr 2020 12:30:56 +0200
Geert Uytterhoeven wrote:
> According to https://www.analog.com/, the company name is spelled
> "Analog Devices".
>
> Signed-off-by: Geert Uytterhoeven
Applied to the togreg branch of iio.git and pushed out as testing as there
are other things in that tree th
m. I guess the chances of this causing merge problems are fairly low so
perhaps not worth doing additions of headers via individual subsystems and
actually dropping the header include after another cycle.
So on that basis
Acked-by: Jonathan Cameron #for-iio
> ---
> v2: add include to of_pla
scripts which do transforms on the schema files.
>
> Signed-off-by: Rob Herring
> ---
...
> .../bindings/iio/adc/adi,ad7124.yaml | 4 +-
> .../bindings/iio/adc/lltc,ltc2496.yaml | 6 +-
Acked-by: Jonathan Cameron #for-iio
> .../input/allwinner,sun4i-a10-lrad
ments, so let's change this
> treewide so everyone copies the simpler syntax.
>
> Signed-off-by: Rob Herring
A few unrelated white space changes in enums in the IIO chunks.
Don't suppose they matter but maybe need the description to mention there
may be some minor formatting chang
Acked-by: Dan Murphy
>
Not sure who will pick this one up, but
Acked-by: Jonathan Cameron
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
> Cc: Shawn Guo
> Cc: Bjorn Andersson
> Cc: Baolin Wang
> Cc: Guenter Roeck
> Cc: Jonathan Cameron
> Cc: Mauro Carvalho Chehab
> Cc: Laurent Pinchart
> Cc: Lee Jones
> Cc: Ulf Hansson
> Cc: "David S. Miller"
> Cc: Bjorn Helgaas
> Cc: Vinod Koul
&g
alProperties.
>
> Signed-off-by: Rob Herring
> Documentation/devicetree/bindings/iio/common.yaml| 2 ++
For IIO
Acked-by: Jonathan Cameron
> ...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesk
n a few cases, this means adding some missing property definitions of
> which most are for SPI bus properties. 'unevaluatedProperties' is not going
> to work for the SPI bus properties anyways as they are evaluated from the
> parent node, not the SPI child node.
>
> Signed-off-
> With these points considered:
> Acked-by: Sam Ravnborg
Replying here as the patch doesn't seem to have made it to linux-iio
at least. I'm not sure why...
Anyhow, found it in an lkml archive so for the iio changes
Acked-by: Jonathan Cameron
>
> I expect only some (few) of my
checked all these drivers to ensure that all ioctl arguments
> are used as pointers or are ignored, but are not interpreted as integer
> values.
>
> Signed-off-by: Arnd Bergmann
> ---
For IIO part.
Acked-by: Jonathan Cameron
Thanks,
> diff --git a/drivers/iio/industri
On Fri, 23 Aug 2024 17:20:49 +0800
Jinjie Ruan wrote:
> Avoids the need for manual cleanup of_node_put() in early exits
> from the loop.
>
> Signed-off-by: Jinjie Ruan
There is more to do here, and looking at the code, I'm far from
sure it isn't releasing references it never had.
> ---
> dri
On Tue, 27 Aug 2024 09:40:07 +0800
Jinjie Ruan wrote:
> On 2024/8/23 19:32, Jonathan Cameron wrote:
> > On Fri, 23 Aug 2024 17:20:49 +0800
> > Jinjie Ruan wrote:
> >
> >> Avoids the need for manual cleanup of_node_put() in early exits
> >> from the loo
On Tue, 27 Aug 2024 08:54:51 -0500
Rob Herring wrote:
> +Jonathan C for the naming
>
> On Mon, Aug 26, 2024 at 7:14 PM Kuninori Morimoto
> wrote:
> >
> >
> > Hi Rob
> >
> > > > We already have of_graph_get_next_endpoint(), but it is not
> > > > intuitive to use in some case.
> > >
> > > Can
On Fri, 8 Mar 2024 18:00:40 +0100
Paul Cercueil wrote:
> Hi Jonathan,
>
> Here's the final(tm) version of the IIO DMABUF patchset.
>
> This v8 fixes the remaining few issues that Christian reported.
>
> I also updated the documentation patch as there has been changes to
> index.rst.
>
> This
On Sun, 10 Mar 2024 13:48:29 +0100
Paul Cercueil wrote:
> Hi Jonathan,
>
> Here's the final-er version of the IIO DMABUF patchset.
>
> This v9 fixes the few issues reported by the kernel bot.
>
> This was based on next-20240308.
>
> Changelog:
>
> - [3/6]:
> - Select DMA_SHARED_BUFFER in
On Fri, 23 Feb 2024 13:13:58 +0100
Nuno Sa wrote:
> Hi Jonathan, likely you're wondering why I'm sending v7. Well, to be
> honest, we're hoping to get this merged this for the 6.9 merge window.
> Main reason is because the USB part is already in (so it would be nice
> to get the whole thing in).
On Mon, 04 Mar 2024 08:59:47 +0100
Nuno Sá wrote:
> On Sun, 2024-03-03 at 17:42 +0000, Jonathan Cameron wrote:
> > On Fri, 23 Feb 2024 13:13:58 +0100
> > Nuno Sa wrote:
> >
> > > Hi Jonathan, likely you're wondering why I'm sending v7. Well, to b
> > > + iio_buffer_dmabuf_put(attach);
> > > +
> > > +out_dmabuf_put:
> > > + dma_buf_put(dmabuf);
> > As below. Feels like a __free(dma_buf_put) bit of magic would be a
> > nice to have.
>
> I'm working on the patches right now, just one quick question.
>
> Having a __free(dma_buf_put) req
tation/devicetree/bindings/writing-bindings.rst state that:
> 1. Compatibles should be specific.
> 2. We should add new compatibles in case of bugs or features.
>
> Add compatibles specific to each SoC in front of all old-SoC-like
> compatibles.
>
> Signed-off-by: Krzysztof
On Thu, 20 Jun 2024 21:50:41 +0530
Vinod Koul wrote:
> On 20-06-24, 14:27, Paul Cercueil wrote:
> > Hi Jonathan,
>
> Hey Jonathan,
>
> Assuming we are fine with this series, how would you like to proceed.
> Would you be fine with me picking the dmaengine bits and providing a
> signed tag for
On Thu, 20 Jun 2024 20:11:50 +0100
Jonathan Cameron wrote:
> On Thu, 20 Jun 2024 21:50:41 +0530
> Vinod Koul wrote:
>
> > On 20-06-24, 14:27, Paul Cercueil wrote:
> > > Hi Jonathan,
> >
> > Hey Jonathan,
> >
> > Assuming we are fine
On Fri, 21 Jun 2024 15:36:24 +0530
Vinod Koul wrote:
> On Thu, 20 Jun 2024 14:27:19 +0200, Paul Cercueil wrote:
> > Here's the v12 of my patchset that introduces DMABUF support to IIO.
> >
> > Apart from a small documentation fix, it reverts to using
> > mutex_lock/mutex_unlock in one particular
;
> Note: Class-based device instantiation is a legacy mechanism which
> shouldn't be used in new code, so we can rule out that this argument
> may be needed again in the future.
>
> Signed-off-by: Heiner Kallweit
For iio
Acked-by: Jonathan Cameron
> ---
>
On Thu, 17 Aug 2017 16:14:43 +0200
Wolfram Sang wrote:
> So, after revisiting old mail threads, taking part in a similar discussion on
> the USB list, and implementing a not-convincing solution before, here is what
> I
> cooked up to document and ease DMA handling for I2C within Linux. Please ha
suggestion inline. I don't really care either way as
what you had is perfectly comprehensible.
Reviewed-by: Jonathan Cameron
>
> > ---
> > Documentation/i2c/DMA-considerations | 58
> >
> > 1 file changed, 58 insertions(+)
&
On Thu, 21 Sep 2017 14:59:22 +0100
Jonathan Cameron wrote:
> On Wed, 20 Sep 2017 20:59:52 +0200
> Wolfram Sang wrote:
>
> > One helper checks if DMA is suitable and optionally creates a bounce
> > buffer, if not. The other function returns the bounce buffer and makes
fram Sang
One minor suggestion for wording. Otherwise looks good to me.
Reviewed-by: Jonathan Cameron
> ---
> drivers/i2c/i2c-core-base.c | 45
> +
> include/linux/i2c.h | 3 +++
> 2 files changed, 48 insertions(+)
>
&g
On Wed, 20 Sep 2017 20:59:56 +0200
Wolfram Sang wrote:
> Signed-off-by: Wolfram Sang
Makes sense as do the other drivers.
Feel free to add
Reviewed-by: Jonathan Cameron
to all of them (though they hardly took a lot of reviewing given how simple
the patches were :)
> ---
> driver
On Thu, 21 Sep 2017 16:15:28 +0200
Wolfram Sang wrote:
> > > > +/**
> > > > + * i2c_release_dma_safe_msg_buf - release DMA safe buffer and sync
> > > > with i2c_msg
> > > > + * @msg: the message to be synced with
> > > > + * @buf: the buffer obtained from i2c_get_dma_safe_msg_buf(). May be
> >
On Mon, 22 Jan 2024 18:18:22 +
Mark Brown wrote:
> On Mon, Jan 22, 2024 at 07:06:55PM +0100, Uwe Kleine-König wrote:
>
> > Note that Jonathan Cameron has already applied patch 3 to his tree, it
> > didn't appear in a public tree though yet. I still included it here
On Mon, 22 Jan 2024 19:23:43 +
Jonathan Cameron wrote:
> On Mon, 22 Jan 2024 18:18:22 +
> Mark Brown wrote:
>
> > On Mon, Jan 22, 2024 at 07:06:55PM +0100, Uwe Kleine-König wrote:
> >
> > > Note that Jonathan Cameron has already applied patch 3 to his t
On Tue, 19 Dec 2023 18:50:02 +0100
Paul Cercueil wrote:
> The buffer-dma code was using two queues, incoming and outgoing, to
> manage the state of the blocks in use.
>
> While this totally works, it adds some complexity to the code,
> especially since the code only manages 2 blocks. It is much
On Tue, 19 Dec 2023 18:50:03 +0100
Paul Cercueil wrote:
> From: Alexandru Ardelean
>
> This change splits the logic into a separate function, which will be
> re-used later.
>
> Signed-off-by: Alexandru Ardelean
> Cc: Alexandru Ardelean
> Signed-off-by: Paul Cercueil
Harmless refactor so I'm
On Tue, 19 Dec 2023 18:50:04 +0100
Paul Cercueil wrote:
> This function can be used to initiate a scatter-gather DMA transfer,
> where the address and size of each segment is located in one entry of
> the dma_vec array.
>
> The major difference with dmaengine_prep_slave_sg() is that it supports
On Tue, 19 Dec 2023 18:50:06 +0100
Paul Cercueil wrote:
> Add the necessary infrastructure to the IIO core to support a new
> optional DMABUF based interface.
>
> With this new interface, DMABUF objects (externally created) can be
> attached to a IIO buffer, and subsequently used for data transf
On Tue, 19 Dec 2023 18:50:07 +0100
Paul Cercueil wrote:
> Implement iio_dma_buffer_attach_dmabuf(), iio_dma_buffer_detach_dmabuf()
> and iio_dma_buffer_transfer_dmabuf(), which can then be used by the IIO
> DMA buffer implementations.
>
> Signed-off-by: Paul Cercueil
>
Hi Paul,
A few comments
On Tue, 19 Dec 2023 18:50:08 +0100
Paul Cercueil wrote:
> Use the functions provided by the buffer-dma core to implement the
> DMABUF userspace API in the buffer-dmaengine IIO buffer implementation.
>
> Since we want to be able to transfer an arbitrary number of bytes and
> not necesarily the fu
On Tue, 19 Dec 2023 18:50:09 +0100
Paul Cercueil wrote:
> Document the new DMABUF based API.
>
> Signed-off-by: Paul Cercueil
One minor comment inline.
>
> ---
> v2: - Explicitly state that the new interface is optional and is
> not implemented by all drivers.
> - The IOCTLs can now
On Tue, 19 Dec 2023 18:50:01 +0100
Paul Cercueil wrote:
> [V4 was: "iio: Add buffer write() support"][1]
>
> Hi Jonathan,
>
Hi Paul,
> This is a respin of the V3 of my patchset that introduced a new
> interface based on DMABUF objects [2].
Great to see this moving forwards.
>
> The V4 was a
> > > +struct iio_dma_buffer_block *
> > > +iio_dma_buffer_attach_dmabuf(struct iio_buffer *buffer,
> > > + struct dma_buf_attachment *attach)
> > > +{
> > > + struct iio_dma_buffer_queue *queue = iio_buffer_to_queue(buffer);
> > > + struct iio_dma_buffer_bl
On Fri, 22 Dec 2023 09:58:29 +0100
Nuno Sá wrote:
> On Thu, 2023-12-21 at 18:30 +0100, Paul Cercueil wrote:
> > Hi Jonathan,
> >
> > Le jeudi 21 décembre 2023 à 16:12 +0000, Jonathan Cameron a écrit :
> > > On Tue, 19 Dec 2023 18:50:08 +0100
> > > Pau
On Thu, 21 Dec 2023 18:56:52 +0100
Paul Cercueil wrote:
> Hi Jonathan,
>
> Le jeudi 21 décembre 2023 à 16:30 +, Jonathan Cameron a écrit :
> > On Tue, 19 Dec 2023 18:50:01 +0100
> > Paul Cercueil wrote:
> >
> > > [V4 was: "iio: Add buffer writ
;
> Signed-off-by: Andy Shevchenko
Given the header removal in patch 4, I assume these all need to go together
via mfd.
Acked-by: Jonathan Cameron
> ---
> drivers/iio/light/Kconfig | 17 -
> drivers/iio/light/Makefile | 1 -
> drivers/iio/light/lm3533-als.c | 922 -
On Wed, 05 Jun 2024 12:50:25 -0400
Nícolas F. R. A. Prado wrote:
> Use dev_err_probe() in the component_add() error path to prevent
> printing an error when the probe is deferred. This was observed on
> mt8195 with the disp-rdma driver:
>
> mediatek-disp-rdma 1c002000.rdma: Failed to add compo
On Wed, 5 Jun 2024 13:08:42 +0200
Paul Cercueil wrote:
> Add the necessary infrastructure to the IIO core to support a new
> optional DMABUF based interface.
>
> With this new interface, DMABUF objects (externally created) can be
> attached to a IIO buffer, and subsequently used for data transf
On Wed, 5 Jun 2024 13:08:43 +0200
Paul Cercueil wrote:
> Implement iio_dma_buffer_attach_dmabuf(), iio_dma_buffer_detach_dmabuf()
> and iio_dma_buffer_transfer_dmabuf(), which can then be used by the IIO
> DMA buffer implementations.
>
> Signed-off-by: Paul Cercueil
> Signed-off-by: Nuno Sa
>
On Wed, 5 Jun 2024 13:08:39 +0200
Paul Cercueil wrote:
> Hi Jonathan,
>
> Here is a revised (and hopefully final?) version of my DMABUF patchset.
Fingers crossed it's just docs changes for v11.
So on to the details of how to merge this...
For the DMAEngine maintainers:
Given IIO changes domin
broken at least one driver
doing this so please take a close look.
Rusty, Tejun. I kept your sign of an ack for the first patch. Could
you quickly verify that's fine?
Thanks,
Jonathan
Jonathan Cameron (7):
hwmon: convert idr to ida and use ida_simple interface.
hwmon: ibmaem: conver
From: Rusty Russell
The current hyper-optimized functions are overkill if you simply want
to allocate an id for a device. Create versions which use an internal
lock.
Thanks to Tejun for feedback.
Signed-off-by: Rusty Russell
Acked-by: Tejun Heo
Acked-by: Jonathan Cameron
---
include/linux
Some messing with error codes to return 0 on out id's and match
current situation. Is this necessary? Looks a touch 'interesting'.
Signed-off-by: Jonathan Cameron
---
drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 34 ++---
1 files changed, 8 insertions(+
broken at least one driver
doing this so please take a close look.
Rusty, Tejun. I kept your sign of an ack for the first patch. Could
you quickly verify that's fine?
Thanks,
Jonathan
Jonathan Cameron (7):
hwmon: convert idr to ida and use ida_simple interface.
hwmon: ibmaem: conver
1 - 100 of 122 matches
Mail list logo