On Thu, 8 May 2025 15:06:07 +0200
Markus Burri wrote:
> The buffer is set to 80 character. If a caller write more characters,
> count is truncated to the max available space in "simple_write_to_buffer".
> But afterwards a string terminator is written to the buffer at offset count
> without bound
On Wed, 5 Mar 2025 16:18:38 +0200
Svyatoslav Ryhel wrote:
> ср, 5 бер. 2025 р. о 15:45 Jonathan Cameron пише:
> >
> > On Fri, 28 Feb 2025 11:30:51 +0200
> > Svyatoslav Ryhel wrote:
> >
> > > пт, 28 лют. 2025 р. о 10:59 Lee Jones пише:
> > > &g
On Fri, 28 Feb 2025 11:30:51 +0200
Svyatoslav Ryhel wrote:
> пт, 28 лют. 2025 р. о 10:59 Lee Jones пише:
> >
> > On Mon, 24 Feb 2025, Svyatoslav Ryhel wrote:
> >
> > > Remove platform data and fully relay on OF and device tree
> > > parsing and binding devices.
> > >
> > > Signed-off-by: Svyat
On Sat, 22 Feb 2025 16:39:31 +0200
Svyatoslav Ryhel wrote:
> сб, 22 лют. 2025 р. о 16:29 Jonathan Cameron пише:
> >
> > On Tue, 18 Feb 2025 15:26:59 +0200
> > Svyatoslav Ryhel wrote:
> >
> > > Add bindings for the LM3533 - a complete power source for
&g
On Tue, 18 Feb 2025 15:26:59 +0200
Svyatoslav Ryhel wrote:
> Add bindings for the LM3533 - a complete power source for
> backlight, keypad, and indicator LEDs in smartphone handsets.
> The high-voltage inductive boost converter provides the
> power for two series LED strings display backlight and
On Sat, 22 Feb 2025 09:01:18 +0200
Svyatoslav Ryhel wrote:
> пт, 21 лют. 2025 р. о 22:38 Rob Herring пише:
> >
> > On Tue, Feb 18, 2025 at 03:26:59PM +0200, Svyatoslav Ryhel wrote:
> > > Add bindings for the LM3533 - a complete power source for
> > > backlight, keypad, and indicator LEDs in sm
On Wed, 12 Feb 2025 09:58:42 +0200
Svyatoslav Ryhel wrote:
> Add ability to fill pdata from device tree. Common stuff is
> filled from core driver and then pdata is filled per-device
> since all cells are optional.
>
> Signed-off-by: Svyatoslav Ryhel
Focusing on just the IIO bit. (backlog of r
On Tue, 24 Dec 2024 21:05:10 +0800
Zijun Hu wrote:
> From: Zijun Hu
>
> Remove is_cxl_nvdimm_bridge() which has no caller now.
>
> Signed-off-by: Zijun Hu
Reviewed-by: Jonathan Cameron
vice_match_type().
>
> Replace match_nvdimm_bridge() usage with device_match_type().
>
> Reviewed-by: Alison Schofield
> Signed-off-by: Zijun Hu
With new follow up, I'm fine with this.
Reviewed-by: Jonathan Cameron
mplest
> changes to complement squashing shortcoming, and that may bring extra
> code improvement.
>
> Reviewed-by: Alison Schofield
> Reviewed-by: Takashi Sakamoto
> Acked-by: Uwe Kleine-König # for drivers/pwm
> Signed-off-by: Zijun Hu
Reviewed-by: Jonathan Cameron
On Wed, 11 Dec 2024 08:08:13 +0800
Zijun Hu wrote:
> From: Zijun Hu
>
> cable_match(), as matching function of device_find_child(), matches
> a device with device type @typec_cable_dev_type, and its task can be
> simplified by the recently introduced API device_match_type().
>
> partner_match(
On Wed, 11 Dec 2024 08:08:12 +0800
Zijun Hu wrote:
> From: Zijun Hu
>
> Static match_nvdimm_bridge(), as matching function of device_find_child()
> matches a device with device type @cxl_nvdimm_bridge_type, and its task
> can be simplified by the recently introduced API device_match_type().
>
> specified type.
>
> device_find_child() will use it to simplify operations later.
>
> Signed-off-by: Zijun Hu
Seems useful enough to have a generic helper.
Reviewed-by: Jonathan Cameron
> ---
> drivers/base/core.c| 6 ++
> include/linux/device/bus.h | 1 +
> 2 files chang
On Wed, 11 Dec 2024 08:08:10 +0800
Zijun Hu wrote:
> From: Zijun Hu
>
> gpio_sim_dev_match_fwnode() is a simple wrapper of API
> device_match_fwnode().
>
> Remove the needless wrapper and use the API instead.
>
> Signed-off-by: Zijun Hu
Reviewed-by: Jonathan Cameron
is dance up and down containing structure
to exactly
the same device it started with.
Reviewed-by: Jonathan Cameron
> ---
> drivers/slimbus/core.c | 10 +-
> 1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/drivers/slimbus/cor
-by: Zijun Hu
Reviewed-by: Jonathan Cameron
> ---
> drivers/base/core.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index
> 8116bc8dd6e9eba0653ca686a90c7008de9e2840..289f2dafa8f3831931d0f316d66
;p == NULL, now it can't. Sounds at most like a harmless change but
maybe you should mention it.
Otherwise LGTM
Reviewed-by: Jonathan Cameron
>
> Signed-off-by: Zijun Hu
> ---
> drivers/base/core.c | 13 +
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
On Wed, 11 Dec 2024 08:08:06 +0800
Zijun Hu wrote:
> From: Zijun Hu
>
> Constify the following API:
> struct device *device_find_child(struct device *dev, void *data,
> int (*match)(struct device *dev, void *data));
> To :
> struct device *device_find_child(struct device *dev, con
7;d say why you are making this change.
There are may places in the kernel where pointers are constant but
not marked so. Why does this one matter?
With that info added
Reviewed-by: Jonathan Cameron
> ---
> drivers/bus/fsl-mc/dprc-driver.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 de
;.
>
> Signed-off-by: Zijun Hu
Absolutely makes sense given later patches mean one of the inputs
is of type constant pointer, but maybe worth calling that out as
the reason for the change here.
Other than that looks good.
Reviewed-by: Jonathan Cameron
> ---
> drivers/slimbus/core.c |
On Wed, 11 Dec 2024 08:08:03 +0800
Zijun Hu wrote:
> From: Zijun Hu
>
> Simplify nd_namespace_store() implementation by
> using device_find_child_by_name().
>
> Reviewed-by: Alison Schofield
> Signed-off-by: Zijun Hu
LGTM
Reviewed-by: Jonathan Cameron
> ---
>
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 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 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 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
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 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 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
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: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, 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
;
> 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 -
;
> 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 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, 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 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
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).
> > > + 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
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 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 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
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
> > > +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 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
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: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: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: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: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: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: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
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 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
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: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 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: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: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: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: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: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 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
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, 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
& 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
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
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, 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, 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: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
> >
> > > +
> > > +#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
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
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 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: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: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: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, 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: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 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 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 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&#x
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, 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 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: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: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: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: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: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 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
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
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:
> 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
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.
>
>
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
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-
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
1 - 100 of 123 matches
Mail list logo
