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

On Mon, 4 Dec 2017 22:05:41 + Mark Brown wrote: > On Sun, Dec 03, 2017 at 08:43:47PM +0100, Wolfram Sang wrote: > > > > It's a bit different in that it's much more likely that a SPI controller > > > will actually do DMA than an I2C one since the speeds are higher and > >

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

<wsa+rene...@sang-engineering.com> Hmm. Interesting balance here as this adds allocations to paths where the i2c master can't take advantage. Not ideal, but perhaps not worth the hassle of working around it? It's only for the block calls I guess so not that major an issue. Reviewed-by: Jonatha

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

m> Can't really argue with such a simple patch ;) Acked-by: Jonathan Cameron <jonathan.came...@huawei.com> > --- > include/linux/i2c.h | 31 +++ > 1 file changed, 31 insertions(+) > > diff --git a/include/linux/i2c.h b/include/linux/i2c.h > index ef1a8791c1a

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

e thing a macro, I can't see a better way. > > Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> Reviewed-by: Jonathan Cameron <jonathan.came...@huawei.com> > --- > drivers/i2c/i2c-core-base.c | 64 > + > include/

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

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

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

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 other drivers. Feel free to add Reviewed-by: Jonathan Cameron <jonathan.came...@huawei.com> t

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

> > Documentation looks OK on my eyes. So: > > Reviewed-by: Mauro Carvalho Chehab <mche...@s-opensource.com> Really minor suggestion inline. I don't really care either way as what you had is perfectly comprehensible. Reviewed-by: Jonathan Cameron <jonathan.came...@huawei.com&

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

On Thu, 21 Sep 2017 14:59:22 +0100 Jonathan Cameron <jonathan.came...@huawei.com> wrote: > On Wed, 20 Sep 2017 20:59:52 +0200 > Wolfram Sang <wsa+rene...@sang-engineering.com> wrote: > > > One helper checks if DMA is suitable and optionally creates a bounce > > b

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

to the message. > > Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> One minor suggestion for wording. Otherwise looks good to me. Reviewed-by: Jonathan Cameron <jonathan.came...@huawei.com> > --- > drivers/i2c/i2c-core-base.c | 45 > ++

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

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

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

though. Acked-by: Jonathan Cameron <jonathan.came...@huawei.com> > --- > Changes since v2: > > * documentation updates. Hopefully better wording now > > Documentation/i2c/DMA-considerations | 38 > > 1 file changed, 38 insertions(+

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

On Tue, 18 Jul 2017 12:23:36 +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 > sure the data is properly copied back to the message. > >

Re: [PATCH 10/14] staging:iio:resolver:ad2s1210 fix negative IIO_ANGL_VEL read

On Fri, 14 Jul 2017 11:31:03 +0200 Arnd Bergmann wrote: > gcc-7 points out an older regression: > > drivers/staging/iio/resolver/ad2s1210.c: In function 'ad2s1210_read_raw': > drivers/staging/iio/resolver/ad2s1210.c:515:42: error: '<<' in boolean > context, did you mean '<' ?

Re: [PATCH 8/9] iio: gyro: mpu3050: stop double error reporting

On 03/04/17 18:56, Linus Walleij wrote: > On Mon, Apr 3, 2017 at 10:38 AM, Peter Rosin wrote: > >> i2c_mux_add_adapter already logs a message on failure. >> >> Signed-off-by: Peter Rosin > > Reviewed-by: Linus Walleij Applied to the

Re: [PATCH v2 00/11] getting back -Wmaybe-uninitialized

On 11/11/16 19:49, Arnd Bergmann wrote: > On Friday, November 11, 2016 9:13:00 AM CET Linus Torvalds wrote: >> On Thu, Nov 10, 2016 at 8:44 AM, Arnd Bergmann wrote: >>> >>> Please merge these directly if you are happy with the result. >> >> I will take this. > > Thanks a lot! >

Re: [PATCH v6 08/24] iio: imu: inv_mpu6050: convert to use an explicit i2c mux core

On 03/04/16 12:51, Peter Rosin wrote: > On 2016-04-03 12:51, Jonathan Cameron wrote: >> On 03/04/16 09:52, Peter Rosin wrote: >>> From: Peter Rosin <p...@axentia.se> >>> >>> Allocate an explicit i2c mux core to handle parent and child adapters >>>

Re: [PATCH v6 19/24] i2c-mux: document i2c muxes and elaborate on parent-/mux-locked muxes

On 03/04/16 09:52, Peter Rosin wrote: > From: Peter Rosin > > Signed-off-by: Peter Rosin Very nice, one typo that I could see. > --- > Documentation/i2c/i2c-topology | 370 > + > MAINTAINERS| 1 +

Re: [PATCH v6 20/24] iio: imu: inv_mpu6050: change the i2c gate to be mux-locked

t; i2c adapter lock until the very end (and grabs the newfangled i2c mux > lock where it previously grabbed the i2c adapter lock). > > Signed-off-by: Peter Rosin <p...@axentia.se> This one obviously wants a ack from Adriana or Daniel in addition to mine. I'm more than happ

Re: [PATCH v6 08/24] iio: imu: inv_mpu6050: convert to use an explicit i2c mux core

t looks to be a fairly mechanical change so if no one is currently setup to test it, then don't let it hold up the series too long! Acked-by: Jonathan Cameron <ji...@kernel.org> Jonathan > --- > drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c | 2 +- > drivers/iio/imu/inv_mpu6050/inv_

Re: [PATCH v3 0/8] i2c mux cleanup and locking update

On 02/03/16 17:29, Wolfram Sang wrote: > On Fri, Jan 08, 2016 at 04:04:48PM +0100, Peter Rosin wrote: >> From: Peter Rosin >> >> Hi! >> >> [doing a v3 even if there is no "big picture" feedback yet, but >> previous versions has bugs that make them harder to test than >> needed,

Re: Is IIO the appropriate subsystem for a thermal camera sensor?

On 26 October 2015 08:21:07 GMT+00:00, Jean-Michel Hautbois wrote: >Hi Lucas, > >2015-10-26 8:53 GMT+01:00 Daniel Baluta : >> Hi Lucas, >> >> Adding linux-iio and linux-media, I hope you don't mind. >> >> On 10/23/2015 06:58 PM, Lucas

Re: [PATCH 1/3] staging: iio: Drop owner assignment from i2c_driver

On 10/07/15 07:34, Krzysztof Kozlowski wrote: i2c_driver does not need to set an owner because i2c_register_driver() will set it. Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com Applied to the togreg branch of iio.git Thanks, Jonathan --- The coccinelle script which

Re: [RFC PATCH 0/3] Introduce IIO interface for fingerprint sensors

at 02:15 +, Jonathan Cameron wrote: On 04/12/14 13:00, Teodora Baluta wrote: This patchset adds support for fingerprint sensors through the IIO interface. This way userspace applications collect information in a uniform way. All processing would be done in the upper layers as suggested in [0

Re: [PATCH] v4l: mt9p031/mt9t001: Use i2c_smbus_{read|write}_word_swapped()

Acked-by: Jonathan Cameron ji...@cam.ac.uk --- drivers/media/video/mt9p031.c |5 ++--- drivers/media/video/mt9t001.c |5 ++--- 2 files changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c index 5cfa39f..aa01c4b 100644

[PATCH] v4l: use i2c_smbus_read_word_swapped

Function ensures that error codes don't get mangled. Dependant on: i2c: boilerplate function for byte swapped smbus_write/read_word_data which is working it's way through the i2c tree. Signed-off-by: Jonathan Cameron ji...@cam.ac.uk --- In some cases the now largely pointless boiler plate

[PATCH V2] v4l: use i2c_smbus_read_word_swapped

Function ensures that error codes don't get mangled. Dependant on: i2c: boilerplate function for byte swapped smbus_write/read_word_data which is working it's way through the i2c tree. Signed-off-by: Jonathan Cameron ji...@cam.ac.uk Acked-by: Jean Delvare kh...@linux-fr.org --- V2: Stray line

Error routes through omap3isp ccdc.

of the tree may be fine. [PATCH] omap3isp: check if there is actually a source for ispccdc when setting up the link. Without this if no source actually exists and the ccdc is configured to output to memory, a read from userspace will cause a null pointer exception. Signed-off-by: Jonathan Cameron ji

Re: Error routes through omap3isp ccdc.

On 07/11/11 11:57, Laurent Pinchart wrote: On Monday 11 July 2011 12:54:42 Laurent Pinchart wrote: On Monday 11 July 2011 12:41:49 Jonathan Cameron wrote: [snip] I think we should try to fix it in ispvideo.c instead. You could add a check to isp_video_validate_pipeline() to make sure

Re: omap3isp: known causes of CCDC won't become idle!

On 07/05/11 17:35, Jonathan Cameron wrote: On 07/05/11 16:22, Jonathan Cameron wrote: On 07/05/11 16:02, Laurent Pinchart wrote: On Tuesday 05 July 2011 16:38:07 Sakari Ailus wrote: On Tue, Jul 05, 2011 at 02:48:57PM +0100, Jonathan Cameron wrote: On 07/05/11 13:19, Sakari Ailus wrote

omap3isp: known causes of CCDC won't become idle!

Hi Laurent, I'm just trying to get an mt9v034 sensor working on a beagle xm. Everything more or less works, except that after a random number of frames of capture, I tend to get won't become idle messages and the vd0 and vd1 interrupts tend to turn up at same time. I was just wondering if there

Re: omap3isp: known causes of CCDC won't become idle!

On 07/05/11 13:19, Sakari Ailus wrote: On Tue, Jul 05, 2011 at 12:22:06PM +0100, Jonathan Cameron wrote: Hi Laurent, I'm just trying to get an mt9v034 sensor working on a beagle xm. Everything more or less works, except that after a random number of frames of capture, I tend to get won't

Re: omap3isp: known causes of CCDC won't become idle!

On 07/05/11 16:02, Laurent Pinchart wrote: On Tuesday 05 July 2011 16:38:07 Sakari Ailus wrote: On Tue, Jul 05, 2011 at 02:48:57PM +0100, Jonathan Cameron wrote: On 07/05/11 13:19, Sakari Ailus wrote: On Tue, Jul 05, 2011 at 12:22:06PM +0100, Jonathan Cameron wrote: Hi Laurent, I'm just

Re: omap3isp: known causes of CCDC won't become idle!

On 07/05/11 16:22, Jonathan Cameron wrote: On 07/05/11 16:02, Laurent Pinchart wrote: On Tuesday 05 July 2011 16:38:07 Sakari Ailus wrote: On Tue, Jul 05, 2011 at 02:48:57PM +0100, Jonathan Cameron wrote: On 07/05/11 13:19, Sakari Ailus wrote: On Tue, Jul 05, 2011 at 12:22:06PM +0100

Re: pxa_camera + ov9655: image shifted on first capture after reset

On 04/16/10 09:25, Stefan Herbrechtsmeier wrote: Hi, I have updated my ov9655 driver to kernel 2.6.33 and did some test regarding the image shift problem on pxa. (http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/10773/focus=11810) - The image was shifted 32 pixels

Re: RFC: exposing controls in sysfs

On 04/06/10 15:32, Mauro Carvalho Chehab wrote: Hans Verkuil wrote: Hans Verkuil wrote: $ ls /sys/class/video4linux/video1/controls balance mpeg_insert_navigation_packets mpeg_video_aspect brightnessmpeg_median_chroma_filter_maximum

Re: RFC: exposing controls in sysfs

On 04/06/10 15:41, Mike Isely wrote: On Tue, 6 Apr 2010, Hans Verkuil wrote: [...] One thing that might be useful is to prefix the name with the control class name. E.g. hue becomes user_hue and audio_crc becomes mpeg_audio_crc. It would groups them better. Or one could make a

Re: adv7180 as SoC camera device

On 02/22/10 16:16, Guennadi Liakhovetski wrote: On Mon, 22 Feb 2010, Rodolfo Giometti wrote: On Fri, Feb 19, 2010 at 08:36:38PM +0100, Guennadi Liakhovetski wrote: On Fri, 19 Feb 2010, Rodolfo Giometti wrote: Hello, on my pxa27x based board I have a adv7180 connected with the CIF

Re: [PULL] soc-camera and mediabus

Hi All, 3) it would be interesting to patch the other sensor drivers to be compatible with soc_camera (mt9v011/ov7670); Well, this could be done, yes, but does it make sense to do this blindly without any hardware to test? I would rather add such conversions on a one-by-one basis as

pxa-camera: build error 2.6.32-rc4

Error was drivers/media/video/pxa_camera.c: In function 'pxa_camera_wakeup': drivers/media/video/pxa_camera.c:683: error: 'TASK_NORMAL' undeclared (first use in this function) drivers/media/video/pxa_camera.c:683: error: (Each undeclared identifier is reported only once

Re: pxa-camera: build error 2.6.32-rc4

Jonathan Cameron wrote: Error was drivers/media/video/pxa_camera.c: In function 'pxa_camera_wakeup': drivers/media/video/pxa_camera.c:683: error: 'TASK_NORMAL' undeclared (first use in this function) drivers/media/video/pxa_camera.c:683: error: (Each undeclared identifier is reported

Re: soc-camera: Handling hardware reset?

Guennadi Liakhovetski wrote: On Tue, 1 Sep 2009, Jonathan Cameron wrote: Dear all, With an ov7670 I have been using soc_camera_link.reset to pass in board specific hardware reset of the sensor. (Is this a correct usage? The reset must occur before the chip is used.) Unfortunately

Re: soc-camera: status, roadmap

Guennadi Liakhovetski wrote: On Wed, 10 Jun 2009, Guennadi Liakhovetski wrote: 2. The above means, I'll have to maintain and update my patches for a whole 2.6.31 development cycle. In this time I'll try to update and upload them as a quilt patch series and announce it on the list a couple

Re: OV7670: getting it working with soc-camera.

Hi All, Turns out that, in addition the below, one more soc-camera ops function is still needed. Init is required in my case to make a call to the subdev-ops-core_ops-init function in order to put the register contents back after the reset callback in soc_camera_open. I'm guessing down the line

Re: OV7670: getting it working with soc-camera.

Guennadi Liakhovetski wrote: On Wed, 17 Jun 2009, Jonathan Cameron wrote: This is purely for info of anyone else wanting to use the ov7670 with Guennadi's recent work on converted soc-camera to v4l2-subdevs. It may not be completely minimal, but it's letting me take pictures ;) Cool, I

Re: OV7670: getting it working with soc-camera.

Updated temporary patch to get ov7670 working with soc camera. --- Basically this is the original patch with the changes Guennadi suggested. Again this is only for info, not a formal patch submission. diff --git a/drivers/media/video/ov7670.c b/drivers/media/video/ov7670.c index

Re: [PATCH] soc-camera: ov7670 merged multiple drivers and moved over to v4l2-subdev

Hans Verkuil wrote: On Tuesday 16 June 2009 16:45:04 Jonathan Cameron wrote: Guennadi Liakhovetski wrote: On Mon, 15 Jun 2009, Jonathan Cameron wrote: From: Jonathan Cameron ji...@cam.ac.uk OV7670 soc-camera driver. Merge of drivers from Jonathan Corbet, Darius Augulis and Jonathan Cameron

typo: v4l2_bound_align_image name mismatch.

Just came across a build error with pxa_camera with Mauro's linux-next tree. pxa-camera calls v4l2_bound_align_image whereas the function is called v4l_bound_align_image. Cheers, --- Jonathan Cameron -- To unsubscribe from this list: send the line unsubscribe linux-media in the body

OV7670: getting it working with soc-camera.

@@ -0,0 +1,21 @@ +/* ov7670_soc Camera + * + * Copyright (C) 2009 Jonathan Cameron ji...@cam.ac.uk + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation

Re: [PATCH] soc-camera: ov7670 merged multiple drivers and moved over to v4l2-subdev

Guennadi Liakhovetski wrote: On Mon, 15 Jun 2009, Jonathan Cameron wrote: From: Jonathan Cameron ji...@cam.ac.uk OV7670 soc-camera driver. Merge of drivers from Jonathan Corbet, Darius Augulis and Jonathan Cameron Could you please, describe in more detail how you merged them? Mostly

Re: [PATCH] soc-camera: ov7670 merged multiple drivers and moved over to v4l2-subdev

Darius Augulis wrote: On 06/16/2009 05:45 PM, Jonathan Cameron wrote: Guennadi Liakhovetski wrote: On Mon, 15 Jun 2009, Jonathan Cameron wrote: From: Jonathan Cameron ji...@cam.ac.uk OV7670 soc-camera driver. Merge of drivers from Jonathan Corbet, Darius Augulis and Jonathan Cameron

[PATCH] soc-camera: ov7670 merged multiple drivers and moved over to v4l2-subdev

From: Jonathan Cameron ji...@cam.ac.uk OV7670 soc-camera driver. Merge of drivers from Jonathan Corbet, Darius Augulis and Jonathan Cameron Signed-off-by: Jonathan Cameron ji...@cam.ac.uk --- This is my first cut at a merge of the various ov7670 drivers to work with Guennadi Liakhovetski's work

soc-camera: Why are exposure and gain handled via special cases?

Hi All, Whilst working on merging the various ov7670 drivers posted recently, I came across the following in soc-camera: static int soc_camera_g_ctrl(struct file *file, void *priv, struct v4l2_control *ctrl) { struct soc_camera_file *icf = file-private_data;

OV7670 Soc-camera driver (anyone else want to merge versions?)

at the moment and ideally we want to support everything the individual drivers do. Is anyone else doing or aiming to do the same? Thanks, --- Jonathan Cameron -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info

Re: RFC: ov7670 soc-camera driver

Guennadi Liakhovetski wrote: On Sun, 15 Mar 2009, Hans Verkuil wrote: On Sunday 15 March 2009 19:50:39 Guennadi Liakhovetski wrote: On Sun, 15 Mar 2009, Jonathan Cameron wrote: From: Jonathan Cameron ji...@cam.ac.uk OV7670 driver for soc-camera interfaces. Much appreciated, thanks

Re: RFC: ov7670 soc-camera driver

Jonathan Corbet wrote: On Sun, 15 Mar 2009 17:10:01 + Jonathan Cameron ji...@cam.ac.uk wrote: The primary control on this chip related to shutter rate is actualy the frame rate. There are rather complex (and largerly undocumented) interactions between this setting and the auto