Re: [PATCH -next v3 2/2] media: ov772x: use SCCB helpers

> > I think it would be even better to introduce a SSCB regmap layer > > and use that. > > I'm fine with introducing a SCCB regmap layer. I am fine with this approach, too. > But do we need to provide both a SCCB regmap and these SCCB helpers? I don't know much about the OV sensor drivers.

Re: [PATCH -next v3 1/2] i2c: add SCCB helpers

> even when not used. I think it will also cause the compiler to emit warnings > for unused functions. I don't think that's a good idea. Where is my brown paper bag? :/ > > But if you insist on drivers/i2c/i2c-sccb.c, then it should be a > > seperate module, I'd think? > > Given how small the

Re: [PATCH -next v3 1/2] i2c: add SCCB helpers

> > +static inline int sccb_read_byte(struct i2c_client *client, u8 addr) > > +{ > > + int ret; > > + union i2c_smbus_data data; > > + > > + i2c_lock_bus(client->adapter, I2C_LOCK_SEGMENT); > > + > > + ret = __i2c_smbus_xfer(client->adapter, client->addr, client->flags, > > +

Re: [PATCH -next v3 2/2] media: ov772x: use SCCB helpers

> static int ov772x_read(struct i2c_client *client, u8 addr) > { > - int ret; > - u8 val; > - > - ret = i2c_master_send(client, , 1); > - if (ret < 0) > - return ret; > - ret = i2c_master_recv(client, , 1); > - if (ret < 0) > - return ret; > - > -

Re: [PATCH -next v3 1/2] i2c: add SCCB helpers

Hi, yes! From a first look this nails it for me. Thanks for doing it. Minor comments follow... > +#if 0 > + /* > + * sccb_xfer not needed yet, since there is no driver support currently. > + * Just showing how it should be done if we ever need it. > + */ > + if

Re: [RFC PATCH v2] media: i2c: add SCCB helpers

> > I'd prefer this file to be in the i2c realm. Maybe > > 'include/linux/i2c-sccb.h" or something. I will come back to this. > > And while at it, I think we also need a .c file, the functions (and > especially > sccb_read_byte()) should not be static inline. Before we discuss this, we should

Re: [RFC PATCH v2] media: i2c: add SCCB helpers

> > It sounds tempting, yet I am concerned about regressions. From that > > point of view, it is safer to introduce i2c_lock_segment() and convert the > > users which would benefit from that. How many drivers would be affected? > > Right, there is also the aspect that changing a function like

Re: [RFC PATCH v2] media: i2c: add SCCB helpers

> So, maybe the easier thing to do is change i2c_lock_adapter to only > lock the segment, and then have the callers beneath drivers/i2c/ > (plus the above mlx90614 driver) that really want to lock the root > adapter instead of the segment adapter call a new function named > i2c_lock_root (or

Re: [RFC PATCH v2] media: i2c: add SCCB helpers

On Wed, Jun 13, 2018 at 12:34:46AM +0900, Akinobu Mita wrote: > (This is 2nd version of SCCB helpers patch. After 1st version was > submitted, I sent alternative patch titled "i2c: add I2C_M_FORCE_STOP". > But it wasn't accepted because it makes the I2C core code unreadable. > I couldn't find out

Re: [PATCH v5 03/14] media: ov772x: allow i2c controllers without I2C_FUNC_PROTOCOL_MANGLING

> It is a very bad idea to replace an i2c xfer by a pair of i2c > send()/recv(), as, if are there any other device at the bus managed > by an independent driver, you may end by mangling i2c transfers and > eventually cause device malfunctions. For I2C, this is true and a very important detail.

[PATCH 3/7] media: cx231xx: don't check number of messages in the driver

Since commit 1eace8344c02 ("i2c: add param sanity check to i2c_transfer()"), the I2C core does this check now. We can remove it from drivers. Signed-off-by: Wolfram Sang <w...@the-dreams.de> --- Only build tested. drivers/media/usb/cx231xx/cx231xx-i2c.c | 2 -- 1 file chan

[PATCH 1/7] media: netup_unidvb: don't check number of messages in the driver

Since commit 1eace8344c02 ("i2c: add param sanity check to i2c_transfer()"), the I2C core does this check now. We can remove it from drivers. Signed-off-by: Wolfram Sang <w...@the-dreams.de> --- Only build tested. drivers/media/pci/netup_unidvb/netup_unidvb_i2c.c | 5 - 1

[PATCH 4/7] media: em28xx: don't check number of messages in the driver

Since commit 1eace8344c02 ("i2c: add param sanity check to i2c_transfer()"), the I2C core does this check now. We can remove it from drivers. Signed-off-by: Wolfram Sang <w...@the-dreams.de> --- Only build tested. drivers/media/usb/em28xx/em28xx-i2c.c | 4 1 file chan

[PATCH 2/7] media: si4713: don't check number of messages in the driver

Since commit 1eace8344c02 ("i2c: add param sanity check to i2c_transfer()"), the I2C core does this check now. We can remove it from drivers. Signed-off-by: Wolfram Sang <w...@the-dreams.de> --- Only build tested. drivers/media/radio/si4713/radio-usb-si4713.c | 3 --- 1

[PATCH 0/7] don't check number of I2C messages in drivers

The core does it now, we can simplify drivers. Based on v4.17-rc5. buildbot is happy. I'd suggest the media tree. Thanks, Wolfram Wolfram Sang (7): media: netup_unidvb: don't check number of messages in the driver media: si4713: don't check number of messages in the driver media

[PATCH 5/7] media: hdpvr: don't check number of messages in the driver

Since commit 1eace8344c02 ("i2c: add param sanity check to i2c_transfer()"), the I2C core does this check now. We can remove it from drivers. Signed-off-by: Wolfram Sang <w...@the-dreams.de> --- Only build tested. drivers/media/usb/hdpvr/hdpvr-i2c.c | 3 --- 1 file chan

[PATCH 7/7] media: dvb-usb: don't check number of messages in the driver

Since commit 1eace8344c02 ("i2c: add param sanity check to i2c_transfer()"), the I2C core does this check now. We can remove it from drivers. Signed-off-by: Wolfram Sang <w...@the-dreams.de> --- Only build tested. drivers/media/usb/dvb-usb/m920x.c | 3 --- 1 file changed, 3 de

[PATCH 6/7] media: tm6000: don't check number of messages in the driver

Since commit 1eace8344c02 ("i2c: add param sanity check to i2c_transfer()"), the I2C core does this check now. We can remove it from drivers. Signed-off-by: Wolfram Sang <w...@the-dreams.de> --- Only build tested. drivers/media/usb/tm6000/tm6000-i2c.c | 2 -- 1 file chan

Re: [PATCH 0/7] i2c: clean up include/linux/i2c-*

On Thu, Apr 19, 2018 at 10:00:06PM +0200, Wolfram Sang wrote: > Move all plain platform_data includes to the platform_data-dir > (except for i2c-pnx which can be moved into the driver itself). > > My preference is to take these patches via the i2c tree. I can provide an > i

Re: [PATCH 1/7] i2c: i2c-gpio: move header to platform_data

> arch/arm/mach-ks8695/board-acs5k.c | 2 +- > arch/arm/mach-sa1100/simpad.c| 2 +- > arch/mips/alchemy/board-gpr.c| 2 +- Those still need acks... > diff --git a/arch/arm/mach-ks8695/board-acs5k.c > b/arch/arm/mach-ks8695/board-acs5k.c >

Re: [PATCH] v4l: vsp1: Fix vsp1_regs.h license header

it. > > Cc: Nobuhiro Iwamatsu <nobuhiro.iwamatsu...@renesas.com> > Cc: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com> > Cc: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com> > Cc: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se> > Cc: Wo

Re: [PATCH v3 02/11] media: ov772x: allow i2c controllers without I2C_FUNC_PROTOCOL_MANGLING

> > Ah, didn't notice that so far. Can't find it in drivers/i2c/busses. > > Where are those? > > IIRC the OMAP I2C adapter supports SCCB natively. I'm not sure the driver > implements that though. It doesn't currently. And seeing how long it sits in HW without a driver for it, I don't have

Re: [PATCH v3 02/11] media: ov772x: allow i2c controllers without I2C_FUNC_PROTOCOL_MANGLING

> SCCB helpers would work too. It would be easy to just move the functions > defined in this patch to helpers and be done with it. However, there are I2C > adapters that have native SCCB support, so to take advantage of that feature Ah, didn't notice that so far. Can't find it in

Re: [PATCH v3 02/11] media: ov772x: allow i2c controllers without I2C_FUNC_PROTOCOL_MANGLING

> How about i2c_smbus_xfer_emulated() ? The tricky part will be to handle the > I2C adapters that implement .smbus_xfer(), as those won't go through > i2c_smbus_xfer_emulated(). i2c_smbus_xfer_emulated() relies on > i2c_transfer(), > which itself relies on the I2C adapter's .master_xfer()

[PATCH 1/7] i2c: i2c-gpio: move header to platform_data

This header only contains platform_data. Move it to the proper directory. Signed-off-by: Wolfram Sang <w...@the-dreams.de> --- MAINTAINERS | 2 +- arch/arm/mach-ks8695/board-acs5k.c | 2 +- arch/arm/mach-omap1/board-htcherald.c

[PATCH 0/7] i2c: clean up include/linux/i2c-*

if dependencies are against us. The current branch can be found here: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/platform_data and buildbot had no complaints. Looking forward to comments or Acks, Revs... Kind regards, Wolfram Wolfram Sang (7): i2c: i2c-gpio: move header

[PATCH 00/61] tree-wide: simplify getting .drvdata

t_drvdata(pdev) + dev_get_drvdata(d) <... when != pdev - >dev + d ...> Kind regards, Wolfram Wolfram Sang (61): ARM: plat-samsung: simplify getting .drvdata ata: simplify getting .drvdata auxdisplay: simplify getting .drvdata bus: simplif

[PATCH 25/61] media: platform: am437x: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- Build tested only. buildbot is happy. Please apply individually. drivers/media/platform/am437x/am437x-vpfe

[PATCH 26/61] media: platform: exynos4-is: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- Build tested only. buildbot is happy. Please apply individually. drivers/media/platform/exynos4-is/media-dev

[PATCH 27/61] media: platform: s5p-mfc: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- Build tested only. buildbot is happy. Please apply individually. drivers/media/platform/s5p-mfc/s5p_mfc

Re: [PATCHv2 6/7] cec-pin-error-inj.rst: document CEC Pin Error Injection

> > I'll wait for a v3 with the debugfs ABI documentation in order to merge > > it. Feel free to put it on a separate patch. > > debugfs ABI? Sounds like an oxymoron to me. Heh, thought the same :) signature.asc Description: PGP signature

Re: [PATCHv2 0/7] cec: add error injection support

Hans, > Special thanks go to Wolfram Sang since his i2c error injection > presentation at the Embedded Linux Conference Europe 2017 inspired > me to switch to debugfs for this instead of using ioctls. You are very welcome! I am glad the presentation did inspire you. Happy hacking,

Re: [PATCH 0/4] tree-wide: fix comparison to bitshift when dealing with a mask

> I did that too but got no results. Perhaps right shifting constants is > pretty uncommon. I can put that in the complete rule though. Please do. Even if rare, we would want this bug pointed out, right? :) signature.asc Description: PGP signature

Re: [PATCH 0/4] tree-wide: fix comparison to bitshift when dealing with a mask

Hi Julia, > and got the results below. I can make a version for the kernel shortly. It should probably take care of right-shifting, too? Thanks, Wolfram signature.asc Description: PGP signature

Re: [PATCH 0/4] tree-wide: fix comparison to bitshift when dealing with a mask

> I found two more using "git grep 'define.*0x[0-9a-f]* < '": I added '[0-9]\+' at the end of the regex to reduce the number of false positives... > drivers/net/can/m_can/m_can.c:#define RXFC_FWM_MASK (0x7f < > RXFC_FWM_SHIFT) > drivers/usb/gadget/udc/goku_udc.h:#define INT_EPnNAK(n) >

[PATCH 3/4] v4l: dvb-frontends: stb0899: fix comparison to bitshift when dealing with a mask

Due to a typo, the mask was destroyed by a comparison instead of a bit shift. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- Only build tested. To be applied individually per subsystem. drivers/media/dvb-frontends/stb0899_reg.h | 8 1 file changed, 4 inse

[PATCH 1/4] v4l: vsp1: fix mask creation for MULT_ALPHA_RATIO

Due to a typo, the mask was destroyed by a comparison instead of a bit shift. No regression since the mask has not been used yet. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- Only build tested. To be applied individually per subsystem. drivers/media/platfor

[PATCH 0/4] tree-wide: fix comparison to bitshift when dealing with a mask

low prio. Wolfram Sang (4): v4l: vsp1: fix mask creation for MULT_ALPHA_RATIO drm/exynos: fix comparison to bitshift when dealing with a mask v4l: dvb-frontends: stb0899: fix comparison to bitshift when dealing with a mask net: amd-xgbe: fix comparison to bitshift when dealing with a mask

Re: [PATCH v6 0/9] i2c: document DMA handling and add helpers for it

On Sat, Nov 04, 2017 at 09:20:00PM +0100, 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

Re: [PATCH v6 0/9] i2c: document DMA handling and add helpers for it

> > > We pretty much assume everything is DMA safe already, the majority of > > > transfers go to/from kmalloc()ed scratch buffers so actually are DMA > > > safe but for bulk transfers we use the caller buffer and there might be > > > some problem users. > > > So, pretty much the situation I2C

Re: [PATCH v6 0/9] i2c: document DMA handling and add helpers for it

On Wed, Nov 08, 2017 at 10:50:37PM +, Mark Brown wrote: > On Sat, Nov 04, 2017 at 09:20:00PM +0100, Wolfram Sang wrote: > > > While previous versions until v3 tried to magically apply bounce buffers > > when > > needed, it became clear that detecting DMA saf

[PATCH v6 0/9] i2c: document DMA handling and add helpers for it

suggestions from Jonathan Cameron (thanks!) * rebased the patches v4.14-rc6+i2c/for-next, reordered patches Wolfram Sang (9): i2c: add a message flag for DMA safe buffers i2c: add helpers to ease DMA handling i2c: dev: mark RDWR buffers as DMA_SAFE i2c: refactor i2c_master_{send_recv} i2c: add

[PATCH v6 5/9] i2c: add i2c_master_{send|recv}_dmasafe

Use the new helper to create variants of i2c_master_{send|recv} which mark their buffers as DMA safe. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- include/linux/i2c.h | 31 +++ 1 file changed, 31 insertions(+) diff --git a/include/linux/i

[PATCH v6 6/9] i2c: smbus: use DMA safe buffers for emulated SMBus transactions

For all block commands, try to allocate a DMA safe buffer and mark it accordingly. Only use the stack, if the buffers cannot be allocated. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drivers/i2c/i2c-core-smbus.c | 45 ++--

[PATCH v6 9/9] i2c: rcar: skip DMA if buffer is not safe

This HW is prone to races, so it needs to setup new messages in irq context. That means we can't alloc bounce buffers if a message buffer is not DMA safe. So, in that case, simply fall back to PIO. Reviewed-by: Jonathan Cameron <jonathan.came...@huawei.com> Signed-off-by: Wolfram Sang <

[PATCH v6 7/9] i2c: add docs to clarify DMA handling

Reviewed-by: Jonathan Cameron <jonathan.came...@huawei.com> Reviewed-by: Mauro Carvalho Chehab <mche...@s-opensource.com> Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- Documentation/i2c/DMA-considerations | 67

[PATCH v6 2/9] i2c: add helpers to ease DMA handling

One helper checks if DMA is suitable and optionally creates a bounce buffer, if not. The other function returns the bounce buffer and makes sure the data is properly copied back to the message. Reviewed-by: Jonathan Cameron <jonathan.came...@huawei.com> Signed-off-by: Wolfram Sang <

[PATCH v6 8/9] i2c: sh_mobile: use core helper to decide when to use DMA

This ensures that we fall back to PIO if the message length is too small for DMA being useful. Otherwise, we use DMA. A bounce buffer might be applied by the helper if the original message buffer is not DMA safe. Reviewed-by: Jonathan Cameron <jonathan.came...@huawei.com> Signed-off-by: W

[PATCH v6 1/9] i2c: add a message flag for DMA safe buffers

I2C has no requirement that the buffer of a message needs to be DMA safe. In case it is, it can now be flagged, so drivers wishing to do DMA can use the buffer directly. Reviewed-by: Jonathan Cameron <jonathan.came...@huawei.com> Signed-off-by: Wolfram Sang <wsa+rene...@sang-engine

[PATCH v6 3/9] i2c: dev: mark RDWR buffers as DMA_SAFE

Reviewed-by: Jonathan Cameron <jonathan.came...@huawei.com> Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drivers/i2c/i2c-dev.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/i2c/i2c-dev.c b/drivers/i2c/i2c-dev.c index 6f638bbc922db4..bbc7aadb4

[PATCH v6 4/9] i2c: refactor i2c_master_{send_recv}

) and let the casting be done in the inlining fuctions which are now calling the new helper function. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drivers/i2c/i2c-core-base.c | 64 + include/linux/i2c.h

Re: [RFC PATCH v5 6/6] i2c: dev: mark RDWR buffers as DMA_SAFE

On Thu, Sep 21, 2017 at 03:17:44PM +0100, Jonathan Cameron wrote: > On Wed, 20 Sep 2017 20:59:56 +0200 > Wolfram Sang <wsa+rene...@sang-engineering.com> wrote: > > > Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> > > Makes sense as do the oth

Re: [RFC PATCH v5 2/6] i2c: add helpers to ease DMA handling

> > > +/** > > > + * 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 > > > NULL. > > > + */ > > > +void

[RFC PATCH v5 2/6] i2c: add helpers to ease DMA handling

One helper checks if DMA is suitable and optionally creates a bounce buffer, if not. The other function returns the bounce buffer and makes sure the data is properly copied back to the message. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drivers/i2c/i2c-core-base.

[RFC PATCH v5 0/6] i2c: document DMA handling and add helpers for it

basic RST syntax to the docs This is mainly an update to agree on the docs. Missing code is still missing and will be added in v6. Changes since v3: * completely redesigned Wolfram Sang (6): i2c: add a message flag for DMA safe buffers i2c: add helpers to ease DMA handling i2c: add

[RFC PATCH v5 4/6] i2c: sh_mobile: use helper to decide if DMA is useful

This ensures that we fall back to PIO if the message length is too small for DMA being useful. Otherwise, we use DMA. A bounce buffer might be applied by the helper if the original message buffer is not DMA safe. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drive

[RFC PATCH v5 3/6] i2c: add docs to clarify DMA handling

Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- Documentation/i2c/DMA-considerations | 58 1 file changed, 58 insertions(+) create mode 100644 Documentation/i2c/DMA-considerations diff --git a/Documentation/i2c/DMA-considerati

[RFC PATCH v5 1/6] i2c: add a message flag for DMA safe buffers

I2C has no requirement that the buffer of a message needs to be DMA safe. In case it is, it can now be flagged, so drivers wishing to do DMA can use the buffer directly. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- include/uapi/linux/i2c.h | 3 +++ 1 file chan

[RFC PATCH v5 5/6] i2c: rcar: skip DMA if buffer is not safe

This HW is prone to races, so it needs to setup new messages in irq context. That means we can't alloc bounce buffers if a message buffer is not DMA safe. So, in that case, simply fall back to PIO. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drivers/i2c/busses/i2c-

[RFC PATCH v5 6/6] i2c: dev: mark RDWR buffers as DMA_SAFE

Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drivers/i2c/i2c-dev.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/i2c/i2c-dev.c b/drivers/i2c/i2c-dev.c index 6f638bbc922db4..bbc7aadb4c899d 100644 --- a/drivers/i2c/i2c-dev.c +++ b/drivers/i2c/i2c

Re: [RFC PATCH v4 3/6] i2c: add docs to clarify DMA handling

> In order to avoid that, and to place them into a box using monotonic fonts, > I usually add "::" at the preceding line, e. g.: Just in time: I added the '::' and will resubmit the new version in a minute. Thanks for the pointers! signature.asc Description: PGP signature

Re: [RFC PATCH v4 3/6] i2c: add docs to clarify DMA handling

Hi Mauro, > > +Linux I2C and DMA > > +- > > I would use, instead: > > = > Linux I2C and DMA > = > > As this is the way we're starting document titles, after converted to > ReST. So, better to have it already using the right format, as one day I

Re: [RFC PATCH v4 3/6] i2c: add docs to clarify DMA handling

> Yes, but the statistics that 10% of I2C bus master drivers > are DMA-safe is not true, if you take those into account ;-) > > Perhaps you could write it as (or something similar): > > At this time of writing, only +10% of I2C bus master > drivers for non-remote boards have DMA

Re: [RFC PATCH v4 3/6] i2c: add docs to clarify DMA handling

Hi Mauro, thanks for your comments. Much appreciated! > There are also a couple of things here that Sphinx would complain. > So, it could be worth to rename it to *.rst, while you're writing > it, and see what: > make htmldocs > will complain and how it will look in html. OK, I'll check

Re: [PATCH 2/4] [media] media: pci: make i2c_adapter const

On Sat, Aug 19, 2017 at 04:04:13PM +0530, Bhumika Goyal wrote: > Make these const as they are only used in a copy operation. > Done using Coccinelle > > Signed-off-by: Bhumika Goyal <bhumi...@gmail.com> Acked-by: Wolfram Sang <w...@the-dreams.de> signature.asc Description: PGP signature

Re: [PATCH 3/4] [media] radio-usb-si4713: make i2c_adapter const

On Sat, Aug 19, 2017 at 04:04:14PM +0530, Bhumika Goyal wrote: > Make this const as it is only used in a copy operation. > Done using Coccinelle > > Signed-off-by: Bhumika Goyal <bhumi...@gmail.com> Acked-by: Wolfram Sang <w...@the-dreams.de> signature.asc Description: PGP signature

Re: [PATCH 4/4] [media] usb: make i2c_adapter const

On Sat, Aug 19, 2017 at 04:04:15PM +0530, Bhumika Goyal wrote: > Make these const as they are only used in a copy operation. > Done using Coccinelle > > Signed-off-by: Bhumika Goyal <bhumi...@gmail.com> Acked-by: Wolfram Sang <w...@the-dreams.de> signature.asc Description: PGP signature

Re: [PATCH 1/4] i2c: busses: make i2c_adapter const

On Sat, Aug 19, 2017 at 04:04:12PM +0530, Bhumika Goyal wrote: > Make these const as they are only used in a copy operation. > Done using Coccinelle. > > Signed-off-by: Bhumika Goyal Applied to for-next, thanks! signature.asc Description: PGP signature

Re: [PATCH 1/2] i2c: busses: make i2c_algorithm const

On Fri, Aug 18, 2017 at 09:36:57PM +0530, Bhumika Goyal wrote: > Make these const as they are only stored in the algo field of > i2c_adapter structure, which is const. > > Signed-off-by: Bhumika Goyal Applied to for-next, thanks! signature.asc Description: PGP signature

[RFC PATCH v4 0/6] i2c: document DMA handling and add helpers for it

this work, thank you very much! Regards, Wolfram Changes since v3: * completely redesigned Wolfram Sang (6): i2c: add a message flag for DMA safe buffers i2c: add helpers to ease DMA handling i2c: add docs to clarify DMA handling i2c: sh_mobile: use helper to decide if DMA is useful

[RFC PATCH v4 4/6] i2c: sh_mobile: use helper to decide if DMA is useful

This ensures that we fall back to PIO if the message length is too small for DMA being useful. Otherwise, we use DMA. A bounce buffer might be applied by the helper if the original message buffer is not DMA safe. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drive

[RFC PATCH v4 6/6] i2c: dev: mark RDWR buffers as DMA_SAFE

Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drivers/i2c/i2c-dev.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/i2c/i2c-dev.c b/drivers/i2c/i2c-dev.c index 6f638bbc922db4..bbc7aadb4c899d 100644 --- a/drivers/i2c/i2c-dev.c +++ b/drivers/i2c/i2c

[RFC PATCH v4 5/6] i2c: rcar: skip DMA if buffer is not safe

This HW is prone to races, so it needs to setup new messages in irq context. That means we can't alloc bounce buffers if a message buffer is not DMA safe. So, in that case, simply fall back to PIO. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drivers/i2c/busses/i2c-

[RFC PATCH v4 1/6] i2c: add a message flag for DMA safe buffers

I2C has no requirement that the buffer of a message needs to be DMA safe. In case it is, it can now be flagged, so drivers wishing to do DMA can use the buffer directly. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- include/uapi/linux/i2c.h | 3 +++ 1 file chan

[RFC PATCH v4 2/6] i2c: add helpers to ease DMA handling

One helper checks if DMA is suitable and optionally creates a bounce buffer, if not. The other function returns the bounce buffer and makes sure the data is properly copied back to the message. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drivers/i2c/i2c-core-base.

[RFC PATCH v4 3/6] i2c: add docs to clarify DMA handling

Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- Documentation/i2c/DMA-considerations | 50 1 file changed, 50 insertions(+) create mode 100644 Documentation/i2c/DMA-considerations diff --git a/Documentation/i2c/DMA-considerati

Re: [PATCH v3 1/4] i2c: add helpers to ease DMA handling

Hi Jonathan, > I like the basic idea of this patch set a lot btw! Thanks! > Jonathan Could you delete irrelevant parts of the message, please? I nearly missed your other comment which would have been a great loss! > I'm trying to get my head around whether this is a sufficient set of >

Re: [PATCH v3 1/4] i2c: add helpers to ease DMA handling

> Right: > > drivers/i2c/i2c-core-base.c:2310:15: error: 'i2c_release_bounce_buf' > undeclared here (not in a function) > EXPORT_SYMBOL_GPL(i2c_release_bounce_buf); Thanks. I am just now working on V4 currently which is a redesign. I'll write more in an hour or so. signature.asc

[PATCH v3 3/4] i2c: sh_mobile: use helper to decide if DMA is useful

This ensures that we fall back to PIO if the buffer is too small for DMA being useful. Otherwise, we use DMA. A bounce buffer might be applied if the original message buffer is not DMA safe Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drivers/i2c/busses/i2c-sh_mobile

[PATCH v3 1/4] i2c: add helpers to ease DMA handling

One helper checks if DMA is suitable and optionally creates a bounce buffer, if not. The other function returns the bounce buffer and makes sure the data is properly copied back to the message. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- Changes since v2: * r

[PATCH v3 4/4] i2c: rcar: check for DMA-capable buffers

and need to disable DMA completely for the whole transfer once a message with a not-DMA-capable buffer is found. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drivers/i2c/busses/i2c-rcar.c | 18 +- 1 file changed, 13 insertions(+), 5 deletions(-) diff

[PATCH v3 0/4] i2c: document DMA handling and add helpers for it

to contain 'dma' as well * documentation updates. Hopefully better wording now * removed the doubled Signed-offs * adding more potentially interested parties to CC Wolfram Sang (4): i2c: add helpers to ease DMA handling i2c: add docs to clarify DMA handling i2c: sh_mobile: use helper

[PATCH v3 2/4] i2c: add docs to clarify DMA handling

Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- Changes since v2: * documentation updates. Hopefully better wording now Documentation/i2c/DMA-considerations | 38 1 file changed, 38 insertions(+) create mode 100644 Documentation/i

Re: [PATCH 6/7] [media] soc_camera: rcar_vin: use proper name for the R-Car SoC

> Btw, I'm seeing only patches 6 and 7 here at media ML (and patchwork). > As those are trivial changes, I'll just apply what I have. Perfect, thanks! signature.asc Description: PGP signature

Re: [PATCH 6/7] [media] soc_camera: rcar_vin: use proper name for the R-Car SoC

>Why "soc_camera:" in the subject? I used 'git log $file' and copied the most recent entry. Do I need to resend? signature.asc Description: PGP signature

[PATCH 0/7] tree-wide: use proper 'R-Car' product name

Small series to get the R-Car product name proper. Based on renesas-drivers/master, but can be applied to current linus/master as well. Except for the MMC patch, which depends on mmc/next. Please apply. Wolfram Sang (7): dmaengine: use proper name for the R-Car SoC i2c: use proper name

[PATCH 7/7] [media] v4l: rcar_fdp1: use proper name for the R-Car SoC

It is 'R-Car', not 'RCar'. No code or binding changes, only descriptive text. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- I suggest this trivial patch should be picked individually per susbsystem. drivers/media/platform/rcar_fdp1.c | 2 +- 1 file changed, 1 ins

[PATCH 6/7] [media] soc_camera: rcar_vin: use proper name for the R-Car SoC

It is 'R-Car', not 'RCar'. No code or binding changes, only descriptive text. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- I suggest this trivial patch should be picked individually per susbsystem. Documentation/devicetree/bindings/media/rcar_vin.txt | 4 ++--

Re: [PATCH] media: i2c: ov772x: Force use of SCCB protocol

> i2c-sh_mobile i2c-sh_mobile.0: Transfer request timed out > ov772x 0-0021: Product ID error 92:92 > > With this patch applied: > > soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0 > ov772x 0-0021: ov7725 Product ID 77:21 Manufacturer ID 7f:a2 > > Signed-off-

Re: [PATCH 0/9] Unify i2c_mux_add_adapter error reporting

he central failure message. > > So, first fix the central error reporting to provide as much > information as any current user, and then remove the surplus > error reporting at the call sites. Yes, I like. Reviewed-by: Wolfram Sang <w...@the-dreams.de> signature.asc Description: PGP signature

Re: [PATCH 9/9] [media] cx231xx: stop double error reporting

On Mon, Apr 03, 2017 at 10:38:38AM +0200, Peter Rosin wrote: > i2c_mux_add_adapter already logs a message on failure. > > Signed-off-by: Peter Rosin > --- > drivers/media/usb/cx231xx/cx231xx-i2c.c | 15 --- > 1 file changed, 4 insertions(+), 11 deletions(-) > >

Re: [PATCH 00/11] media: rcar-vin: fix OPS and format/pad index issues

ing capabilites. But since rebinding was a major motivation for this series to be factored out of a bigger one: Tested-by: Wolfram Sang <wsa+rene...@sang-engineering.com> signature.asc Description: PGP signature

Re: [PATCH 1/4] exynos4-is: Clear isp-i2c adapter power.ignore_children flag

On Thu, Sep 01, 2016 at 01:39:16PM +0200, Sylwester Nawrocki wrote: > Since commit 04f59143b571161d25315dd52d7a2ecc022cb71a > ("i2c: let I2C masters ignore their children for PM") > the power.ignore_children flag is set when registering an I2C > adapter. Since I2C transfers are not managed by the

[PATCH 2/6] staging: media: lirc: lirc_imon: don't print error when allocating urb fails

kmalloc will print enough information in case of failure. Signed-off-by: Wolfram Sang <wsa-...@sang-engineering.com> --- drivers/staging/media/lirc/lirc_imon.c | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/staging/media/lirc/lirc_imon.c b/drivers/s

[PATCH 3/6] staging: media: lirc: lirc_sasem: don't print error when allocating urb fails

kmalloc will print enough information in case of failure. Signed-off-by: Wolfram Sang <wsa-...@sang-engineering.com> --- drivers/staging/media/lirc/lirc_sasem.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/staging/media/lirc/lirc_sasem.c b/drivers/staging/medi

[PATCH 0/6] staging: don't print error when allocating urb fails

we talked about it at LCJ in Tokyo a few weeks ago. Wolfram Sang (6): staging: comedi: drivers: usbduxfast: don't print error when allocating urb fails staging: media: lirc: lirc_imon: don't print error when allocating urb fails staging: media: lirc: lirc_sasem: don't print error when

[PATCH 18/28] media: usb: hackrf: hackrf: don't print error when allocating urb fails

kmalloc will print enough information in case of failure. Signed-off-by: Wolfram Sang <wsa-...@sang-engineering.com> --- drivers/media/usb/hackrf/hackrf.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/media/usb/hackrf/hackrf.c b/drivers/media/usb/hackrf/hackrf.c

[PATCH 23/28] media: usb: stk1160: stk1160-video: don't print error when allocating urb fails

kmalloc will print enough information in case of failure. Signed-off-by: Wolfram Sang <wsa-...@sang-engineering.com> --- drivers/media/usb/stk1160/stk1160-video.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/media/usb/stk1160/stk1160-video.c b/drivers/med

[PATCH 19/28] media: usb: hdpvr: hdpvr-video: don't print error when allocating urb fails

kmalloc will print enough information in case of failure. Signed-off-by: Wolfram Sang <wsa-...@sang-engineering.com> --- drivers/media/usb/hdpvr/hdpvr-video.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/media/usb/hdpvr/hdpvr-video.c b/drivers/media/usb

[PATCH 14/28] media: usb: em28xx: em28xx-core: don't print error when allocating urb fails

kmalloc will print enough information in case of failure. Signed-off-by: Wolfram Sang <wsa-...@sang-engineering.com> --- drivers/media/usb/em28xx/em28xx-core.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/media/usb/em28xx/em28xx-core.c b/drivers/media/usb/em28xx/em28xx-

  1   2   3   >