Re: [PATCH RFC 2/2] dt-bindings: add binding documentation for Allwinner CSI

Hi Yong, On Wed, Jul 19, 2017 at 09:22:49AM +0800, Yong wrote: > On Tue, 18 Jul 2017 14:55:30 +0300 > Baruch Siach wrote: > > I am trying to get this driver working on the Olimex A33 OLinuXino. I > > didn't get it working yet, but I had some progress. See the comment below >

cron job: media_tree daily build: ERRORS

This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Wed Jul 19 05:00:16 CEST 2017 media-tree git hash:0e6fd95802e25b2428749703f76ea9d54ea743a3 media_build

[PATCH 2/2] [media] ov7670: Check the return value from clk_prepare_enable()

From: Fabio Estevam clk_prepare_enable() may fail, so we should better check its return value and propagate it in the case of error. Signed-off-by: Fabio Estevam --- drivers/media/i2c/ov7670.c | 4 +++- 1 file changed, 3 insertions(+), 1

[PATCH 1/2] [media] ov7670: Return the real error code

From: Fabio Estevam When devm_clk_get() fails the real error code should be propagated, instead of always returning -EPROBE_DEFER. Signed-off-by: Fabio Estevam --- drivers/media/i2c/ov7670.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH v3 08/12] intel-ipu3: params: compute and program ccs

A collection of routines that are mainly responsible to calculate the acc parameters. Signed-off-by: Yong Zhi --- drivers/media/pci/intel/ipu3/ipu3-css-params.c | 3114 drivers/media/pci/intel/ipu3/ipu3-css-params.h | 105 +

[PATCH v3 09/12] intel-ipu3: css hardware setup

The driver code that handles hw programming for clock, irq and power etc. Signed-off-by: Yong Zhi Signed-off-by: Tomasz Figa --- drivers/media/pci/intel/ipu3/ipu3-css.c | 521 drivers/media/pci/intel/ipu3/ipu3-css.h | 5

[PATCH v3 11/12] intel-ipu3: Add imgu v4l2 driver

ipu3 imgu video device based on v4l2, vb2 and media controller framework. Signed-off-by: Yong Zhi --- drivers/media/pci/intel/ipu3/ipu3-v4l2.c | 724 +++ 1 file changed, 724 insertions(+) create mode 100644

[PATCH v3 12/12] intel-ipu3: imgu top level pci device

This patch adds support for the Intel IPU v3 as found on Skylake and Kaby Lake SoCs. The driver has a dependency on the firmware binary to function properly. Signed-off-by: Yong Zhi Signed-off-by: Tomasz Figa --- drivers/media/pci/intel/ipu3/Kconfig |

[PATCH v3 10/12] intel-ipu3: css pipeline

Add css pipeline and v4l code. Signed-off-by: Yong Zhi Signed-off-by: Tomasz Figa --- drivers/media/pci/intel/ipu3/ipu3-css.c | 1765 ++- drivers/media/pci/intel/ipu3/ipu3-css.h | 84 ++ 2 files changed, 1843 insertions(+),

[PATCH v3 01/12] videodev2.h, v4l2-ioctl: add IPU3 meta buffer format

Add the IPU3 specific processing parameter format V4L2_META_FMT_IPU3_PARAMS and metadata formats for 3A and other statistics: V4L2_META_FMT_IPU3_PARAMS V4L2_META_FMT_IPU3_STAT_3A V4L2_META_FMT_IPU3_STAT_DVS V4L2_META_FMT_IPU3_STAT_LACE Signed-off-by: Yong Zhi ---

[PATCH v3 06/12] intel-ipu3: css: imgu dma buff pool

The pools are used to store previous parameters set by user with the parameter queue. Due to pipelining, there needs to be multiple sets (up to four) of parameters which are queued in a host-to-sp queue. Signed-off-by: Yong Zhi Signed-off-by: Tomasz Figa

[PATCH v3 07/12] intel-ipu3: css: firmware management

Functions to load and install imgu FW blobs Signed-off-by: Yong Zhi Signed-off-by: Tomasz Figa --- drivers/media/pci/intel/ipu3/ipu3-abi.h| 1578 drivers/media/pci/intel/ipu3/ipu3-css-fw.c | 270 +

[PATCH v3 04/12] intel-ipu3: Add user space ABI definitions

The UAPI header defines the structures and macros to be used by user space. Signed-off-by: Yong Zhi --- include/uapi/linux/intel-ipu3.h | 2182 +++ 1 file changed, 2182 insertions(+) create mode 100644 include/uapi/linux/intel-ipu3.h

[PATCH v3 03/12] intel-ipu3: Add DMA API implementation

From: Tomasz Figa This patch adds support for the IPU3 DMA mapping API. Signed-off-by: Tomasz Figa Signed-off-by: Yong Zhi --- drivers/media/pci/intel/ipu3/Kconfig | 8 + drivers/media/pci/intel/ipu3/Makefile | 2 +-

[PATCH v3 02/12] intel-ipu3: mmu: implement driver

From: Tomasz Figa This driver translates Intel IPU3 internal virtual address to physical address. Signed-off-by: Tomasz Figa Signed-off-by: Yong Zhi --- drivers/media/pci/intel/ipu3/Kconfig| 9 +

[PATCH v3 00/12] Intel IPU3 ImgU patchset

This patchset adds support for the Intel IPU3 (Image Processing Unit) ImgU, which is essentially a modern memory-to-memory ISP. It implements raw Bayer to YUV image format conversion as well as a large number of other pixel processing algorithms for improving the image quality. Meta data formats

Re: [PATCH RFC 2/2] dt-bindings: add binding documentation for Allwinner CSI

On Tue, 18 Jul 2017 14:55:30 +0300 Baruch Siach wrote: > Hi Yong, > > I am trying to get this driver working on the Olimex A33 OLinuXino. I didn't > get it working yet, but I had some progress. See the comment below on one > issue I encountered. > > On Tue, Jun 27, 2017 at

Re: [PATCH 4/4] drm/vc4: add HDMI CEC support

Hans Verkuil writes: > On 12/07/17 21:43, Hans Verkuil wrote: >> On 12/07/17 21:02, Eric Anholt wrote: +static int vc4_hdmi_cec_adap_transmit(struct cec_adapter *adap, u8 attempts, +u32 signal_free_time, struct cec_msg *msg)

[PATCH] media: Convert to using %pOF instead of full_name

Now that we have a custom printf format specifier, convert users of full_name to use %pOF instead. This is preparation to remove storing of the full path string for each node. Signed-off-by: Rob Herring Cc: Kyungmin Park Cc: Andrzej Hajda

Re: [PATCH 4/7] omap3isp: Return -EPROBE_DEFER if the required regulators can't be obtained

On Tue, Jul 18, 2017 at 11:27:12PM +0200, Pavel Machek wrote: > Hi! EHLO > > > > No idea really. I only have N900 working with linux at the moment. I'm > > > trying to get N9 and N950 working, but no luck so far. > > > > Still no? :-( > > > > Do you know if you get the kernel booting? Do you

Re: [RFC 02/19] v4l: async: add subnotifier registration for subdevices

Hi Sakari, Just a heads up, I posted a new version of this patch today which addresses a few short comings in v4l2_async_notifier_unregister() which exists in this patch. With the latest patches the re-probing of subdevices, disregarding if they are master or sub notifiers is addressed. Also

Re: [PATCH 4/7] omap3isp: Return -EPROBE_DEFER if the required regulators can't be obtained

Hi! > > No idea really. I only have N900 working with linux at the moment. I'm > > trying to get N9 and N950 working, but no luck so far. > > Still no? :-( > > Do you know if you get the kernel booting? Do you have access to the serial > console? I might have seen the e-mail chain but I lost

Re: [RFC 18/19] v4l2-fwnode: Add abstracted sub-device notifiers

Hi Sakari, Thanks for your hard work! On 2017-07-18 22:04:00 +0300, Sakari Ailus wrote: > Add notifiers for sub-devices. The notifiers themselves are not visible for > the sub-device drivers but instead are accessed through interface functions I might be missing it, but I can't find a interface

Re: [PATCH 4/7] omap3isp: Return -EPROBE_DEFER if the required regulators can't be obtained

On Tue, Jul 18, 2017 at 11:02:28PM +0200, Pavel Machek wrote: > Hi! > > > > > > diff --git a/drivers/media/platform/omap3isp/ispccp2.c > > > > > b/drivers/media/platform/omap3isp/ispccp2.c index > > > > > 4f8fd0c00748..47210b102bcb 100644 > > > > > --- a/drivers/media/platform/omap3isp/ispccp2.c

Re: [PATCH 4/7] omap3isp: Return -EPROBE_DEFER if the required regulators can't be obtained

Hi! > > > > diff --git a/drivers/media/platform/omap3isp/ispccp2.c > > > > b/drivers/media/platform/omap3isp/ispccp2.c index > > > > 4f8fd0c00748..47210b102bcb 100644 > > > > --- a/drivers/media/platform/omap3isp/ispccp2.c > > > > +++ b/drivers/media/platform/omap3isp/ispccp2.c > > > > @@ -1140,6

Re: [PATCH 07/14] proc/kcore: hide a harmless warning

On Tue, Jul 18, 2017 at 10:07 PM, Ard Biesheuvel wrote: > On 18 July 2017 at 21:01, Arnd Bergmann wrote: >> On Tue, Jul 18, 2017 at 9:55 PM, Ard Biesheuvel > > Ah, now it makes sense. I was a bit surprised that > -Wtautological-compare complains about

Re: [PATCH 07/14] proc/kcore: hide a harmless warning

On 18 July 2017 at 21:01, Arnd Bergmann wrote: > On Tue, Jul 18, 2017 at 9:55 PM, Ard Biesheuvel > wrote: >> On 18 July 2017 at 20:53, Arnd Bergmann wrote: >>> On Fri, Jul 14, 2017 at 2:28 PM, Ard Biesheuvel >>>

Re: [PATCH 07/14] proc/kcore: hide a harmless warning

On Tue, Jul 18, 2017 at 9:55 PM, Ard Biesheuvel wrote: > On 18 July 2017 at 20:53, Arnd Bergmann wrote: >> On Fri, Jul 14, 2017 at 2:28 PM, Ard Biesheuvel >> wrote: >>> On 14 July 2017 at 10:25, Arnd Bergmann

Re: [PATCH 07/14] proc/kcore: hide a harmless warning

On 18 July 2017 at 20:53, Arnd Bergmann wrote: > On Fri, Jul 14, 2017 at 2:28 PM, Ard Biesheuvel > wrote: >> On 14 July 2017 at 10:25, Arnd Bergmann wrote: >>> gcc warns when MODULES_VADDR/END is defined to the same value as >>>

Re: [PATCH 07/14] proc/kcore: hide a harmless warning

On Fri, Jul 14, 2017 at 2:28 PM, Ard Biesheuvel wrote: > On 14 July 2017 at 10:25, Arnd Bergmann wrote: >> gcc warns when MODULES_VADDR/END is defined to the same value as >> VMALLOC_START/VMALLOC_END, e.g. on x86-32: >> >> fs/proc/kcore.c: In function

Re: [PATCH v2 0/7] [PATCH v2 0/7] Add support of OV9655 camera

On Tue, Jul 18, 2017 at 12:53:12PM +, Hugues FRUCHET wrote: > > > On 07/18/2017 02:17 PM, H. Nikolaus Schaller wrote: > > Hi, > > > >> Am 18.07.2017 um 13:59 schrieb Hans Verkuil : > >> > >> On 12/07/17 22:01, Sylwester Nawrocki wrote: > >>> Hi Hugues, > >>> > >>> On

[PATCH v1.1 1/1] omap3isp: Skip CSI-2 receiver initialisation in CCP2 configuration

If the CSI-2 receiver isn't part of the pipeline (or isn't there to begin with), skip its initialisation. Signed-off-by: Sakari Ailus --- since v1: - Store the receiver entity per PHY. This way the function to obtain the pipeline became redundant and was removed.

Re: [PATCH 7/7] omap3isp: Skip CSI-2 receiver initialisation in CCP2 configuration

Hi Laurent, On Tue, Jul 18, 2017 at 11:54:21AM +0300, Laurent Pinchart wrote: > Hi Sakari, > > Thank you for the patch. > > On Tuesday 18 Jul 2017 01:01:16 Sakari Ailus wrote: > > If the CSI-2 receiver isn't part of the pipeline (or isn't there to begin > > with), skip its initialisation. > >

Re: [PATCH 6/7] omap3isp: Correctly put the last iterated endpoint fwnode always

On Tue, Jul 18, 2017 at 11:40:22AM +0300, Laurent Pinchart wrote: > Hi Sakari, > > Thank you for the patch. > > On Tuesday 18 Jul 2017 01:01:15 Sakari Ailus wrote: > > Put the last endpoint fwnode if there are too many endpoints to handle. > > Also tell the user about about the condition. > > >

Re: [PATCH 1/7] omap3isp: Ignore endpoints with invalid configuration

On Tue, Jul 18, 2017 at 01:03:33AM +0200, Sebastian Reichel wrote: > Hi, > > On Tue, Jul 18, 2017 at 01:01:10AM +0300, Sakari Ailus wrote: > > If endpoint has an invalid configuration, ignore it instead of happily > > proceeding to use it nonetheless. Ignoring such an endpoint is better than > >

Re: [PATCH 2/2] v4l2-flash-led-class: Create separate sub-devices for indicators

Hi Sakari, Thanks for the patch. On 07/18/2017 08:41 PM, Sakari Ailus wrote: > The V4L2 flash interface allows controlling multiple LEDs through a single > sub-devices if, and only if, these LEDs are of different types. This > approach scales badly for flash controllers that drive multiple flash

Re: [RFC 08/19] arm: dts: omap3: N9/N950: Add AS3645A camera flash

On Tue, Jul 18, 2017 at 10:03:50PM +0300, Sakari Ailus wrote: > From: Sakari Ailus > > Add the as3645a flash controller to the DT source as well as the flash > property with the as3645a device phandle to the sensor DT node. > > Signed-off-by: Sakari Ailus

[RFC 04/19] dt: bindings: Add lens-focus binding for image sensors

The lens-focus property contains a phandle to the lens voice coil driver that is associated to the sensor; typically both are contained in the same camera module. Signed-off-by: Sakari Ailus Acked-by: Pavel Machek Reviewed-by: Sebastian Reichel

[RFC 06/19] leds: as3645a: Separate flash and indicator LED sub-devices

To be merged to the as3645a driver patch. Signed-off-by: Sakari Ailus --- drivers/leds/leds-as3645a.c | 64 + 1 file changed, 42 insertions(+), 22 deletions(-) diff --git a/drivers/leds/leds-as3645a.c

[RFC 09/19] v4l2-fwnode: Add conveniences function for parsing generic references

Add function v4l2_fwnode_reference_count() for counting external references and v4l2_fwnode_reference_parse() for parsing them as async sub-devices. This can be done on e.g. flash or lens async sub-devices that are not part of but are associated with a sensor. struct

[RFC 05/19] leds: as3645a: Add LED flash class driver

From: Sakari Ailus Add a LED flash class driver for the as3654a flash controller. A V4L2 flash driver for it already exists (drivers/media/i2c/as3645a.c), and this driver is based on that. Signed-off-by: Sakari Ailus --- MAINTAINERS

[RFC 02/19] v4l: async: add subnotifier registration for subdevices

From: Niklas Söderlund When the registered() callback of v4l2_subdev_internal_ops is called the subdevice has access to the master devices v4l2_dev and it's called with the async frameworks list_lock held. In this context the subdevice can register its own

[RFC 07/19] v4l: fwnode: Support generic parsing of graph endpoints in V4L2

The current practice is that drivers iterate over their endpoints and parse each endpoint separately. This is very similar in a number of drivers, implement a generic function for the job. Driver specific matters can be taken into account in the driver specific callback. Convert the omap3isp as

[RFC 08/19] arm: dts: omap3: N9/N950: Add AS3645A camera flash

From: Sakari Ailus Add the as3645a flash controller to the DT source as well as the flash property with the as3645a device phandle to the sensor DT node. Signed-off-by: Sakari Ailus Reviewed-by: Sebastian Reichel

[RFC 13/19] v4l2-device: Register sub-device nodes at sub-device registration time

Signed-off-by: Sakari Ailus --- drivers/media/v4l2-core/v4l2-device.c | 146 -- include/media/v4l2-device.h | 12 --- 2 files changed, 67 insertions(+), 91 deletions(-) diff --git a/drivers/media/v4l2-core/v4l2-device.c

[RFC 19/19] smiapp: Add support for flash and lens devices

Parse async sub-devices by using v4l2_subdev_fwnode_reference_parse_sensor_common(). These types devices aren't directly related to the sensor, but are nevertheless handled by the smiapp driver due to the relationship of these component to the main part of the camera module --- the sensor. This

[RFC 10/19] v4l2-fwnode: Add convenience function for parsing common external refs

Add v4l2_fwnode_parse_reference_sensor_common for parsing common sensor properties that refer to adjacent devices such as flash or lens driver chips. As this is an association only, there's little a regular driver needs to know about these devices as such. Signed-off-by: Sakari Ailus

[RFC 12/19] v4l2-subdev: Support registering V4L2 sub-device nodes one by one

Just like video devices, V4L2 sub-device nodes can and should be registered as soon as possible. Support this by providing v4l2_device_register_subdev_node() function. v4l2_device_register_subdev_nodes() continues to work just as it used to. Signed-off-by: Sakari Ailus

[RFC 14/19] omap3isp: Move sub-device link creation to notifier bound callback

The external sub-device links may well be created from the bound callback. Don't postpone creation to the complete callback. Signed-off-by: Sakari Ailus --- drivers/media/platform/omap3isp/isp.c | 20 ++-- 1 file changed, 6 insertions(+), 14

[RFC 03/19] dt: bindings: Add a binding for flash devices associated to a sensor

Camera flash drivers (and LEDs) are separate from the sensor devices in DT. In order to make an association between the two, provide the association information to the software. Signed-off-by: Sakari Ailus Acked-by: Rob Herring Acked-by: Pavel

[RFC 01/19] device property: Introduce fwnode_property_get_reference_args

The new fwnode_property_get_reference_args() interface amends the fwnode property API with the functionality of both of_parse_phandle_with_args() and __acpi_node_get_property_reference(). The semantics is slightly different: the cells property is ignored on ACPI as the number of arguments can be

[RFC 00/19] Async sub-notifiers and how to use them

Hi folks, This RFC patchset achieves a number of things which I've put to the same patchset for they need to be show together to demonstrate the use cases. I don't really intend this to compete with Niklas's patchset but much of the problem area addressed by the two is the same. Comments would

[RFC 15/19] omap3isp: Initialise "crashed" media entity enum in probe

Initialise the struct isp_device.crashed media entity enum field when the ISP's local media entities have been registered, in probe. This is to make sure that the enumeration is initialised and large enough when the media device is made visible. Signed-off-by: Sakari Ailus

[RFC 17/19] omap3isp: Drop the async notifier callback

v4l2_device_register_subdev_nodes() is now nop and can be dropped without side effects. Do so. Signed-off-by: Sakari Ailus --- drivers/media/platform/omap3isp/isp.c | 13 - 1 file changed, 13 deletions(-) diff --git

[RFC 16/19] omap3isp: Move media device registration to probe

Register the media device in probe, thus making the omap3isp device usable once the driver is registered. Signed-off-by: Sakari Ailus --- drivers/media/platform/omap3isp/isp.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git

[RFC 11/19] v4l2-async: Register sub-devices before calling bound callback

The async notifier supports three callbacks to the notifier: bound, unbound and complete. The complete callback has been traditionally used for creating the sub-device nodes. This approach has an inherent weakness: if registration of a single sub-device fails for whatever reason, it renders the

[RFC 18/19] v4l2-fwnode: Add abstracted sub-device notifiers

Add notifiers for sub-devices. The notifiers themselves are not visible for the sub-device drivers but instead are accessed through interface functions v4l2_subdev_fwnode_endpoints_parse() and v4l2_subdev_fwnode_reference_parse_sensor_common(). Signed-off-by: Sakari Ailus

[PATCH 0/2] Create sub-device per LED

Hi folks, The original design decision in the V4L2 flash API allows controlling a two LEDs (an indicator and a flash) through a single sub-device. This covered virtually all flash driver chips back then but this no longer holds as there are many LED driver chips with multiple flash LED outputs.

[PATCH 1/2] staging: greybus: light: Don't leak memory for no gain

Memory for struct v4l2_flash_config is allocated in gb_lights_light_v4l2_register() for no gain and yet the allocated memory is leaked; the struct isn't used outside the function. Fix this. Signed-off-by: Sakari Ailus --- drivers/staging/greybus/light.c | 17

[PATCH 2/2] v4l2-flash-led-class: Create separate sub-devices for indicators

The V4L2 flash interface allows controlling multiple LEDs through a single sub-devices if, and only if, these LEDs are of different types. This approach scales badly for flash controllers that drive multiple flash LEDs or for LED specific associations. Essentially, the original assumption of a LED

[PATCH v1.1 1/1] v4l2-flash: Flash ops aren't mandatory

None of the flash operations are mandatory and therefore there should be no need for the flash ops structure either. Accept NULL. Signed-off-by: Sakari Ailus Reviewed-by: Sebastian Reichel Reviewed-by: Jacek Anaszewski

Re: [PATCH v4 3/3] v4l: async: add subnotifier to subdevices

Hi Hans, On 2017-07-18 17:06:15 +0200, Hans Verkuil wrote: > On 18/07/17 16:47, Niklas Söderlund wrote: > >>> void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier) > >>> { > >>> - struct v4l2_subdev *sd, *tmp; > >>> + struct v4l2_subdev *sd, *tmp, **subdev; > >>> unsigned

Re: [PATCH 00/11] drm/sun4i: add CEC support

Hi, On Tue, Jul 11, 2017 at 11:06:52PM +0200, Hans Verkuil wrote: > On 11/07/17 22:39, Maxime Ripard wrote: > > On Tue, Jul 11, 2017 at 08:30:33AM +0200, Hans Verkuil wrote: > >> From: Hans Verkuil > >> > >> This patch series adds CEC support for the sun4i HDMI

[ragnatech:media-tree] BUILD INCOMPLETE a3db9d60a118571e696b684a6e8c692a2b064941

git://git.ragnatech.se/linux media-tree a3db9d60a118571e696b684a6e8c692a2b064941 Merge tag 'v4.13-rc1' into patchwork TIMEOUT after 1349m Sorry we cannot finish the testset for your branch within a reasonable time. It's our fault -- either some build server is down or some build worker is

[PATCH] v4l: omap3isp: Get the parallel bus type from DT

The OMAP3 ISP supports both external and embedded BT.656 synchronization for parallel buses. It currently gets the bus type information from the source subdev through the .g_mbus_config() operation, but should instead get it from DT as that's the authoritative source of bus configuration

[GIT PULL FOR v4.14] Various fixes, improvements.

Mauro, feel free to cherry-pick from this series if needed. Regards, Hans The following changes since commit a3db9d60a118571e696b684a6e8c692a2b064941: Merge tag 'v4.13-rc1' into patchwork (2017-07-17 11:17:36 -0300) are available in the git repository at:

Re: [PATCH v4 2/3] v4l: async: do not hold list_lock when reprobing devices

On 2017-07-18 16:50:15 +0200, Hans Verkuil wrote: > On 18/07/17 16:39, Niklas Söderlund wrote: > > Hi Hans, > > > > Thanks for your feedback. > > > > On 2017-07-18 16:22:14 +0200, Hans Verkuil wrote: > >> On 17/07/17 18:59, Niklas Söderlund wrote: > >>> There is no good reason to hold the

Re: [PATCH v4 3/3] v4l: async: add subnotifier to subdevices

On 18/07/17 16:47, Niklas Söderlund wrote: >>> void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier) >>> { >>> - struct v4l2_subdev *sd, *tmp; >>> + struct v4l2_subdev *sd, *tmp, **subdev; >>> unsigned int notif_n_subdev = notifier->num_subdevs; >>> unsigned int

Re: [PATCH v4 2/3] v4l: async: do not hold list_lock when reprobing devices

On 18/07/17 16:39, Niklas Söderlund wrote: > Hi Hans, > > Thanks for your feedback. > > On 2017-07-18 16:22:14 +0200, Hans Verkuil wrote: >> On 17/07/17 18:59, Niklas Söderlund wrote: >>> There is no good reason to hold the list_lock when reprobing the devices >>> and it prevents a clean

Re: [PATCH v4 3/3] v4l: async: add subnotifier to subdevices

Hi Hans, Thanks for your feedback. On 2017-07-18 16:22:43 +0200, Hans Verkuil wrote: > On 17/07/17 18:59, Niklas Söderlund wrote: > > Add a subdevice specific notifier which can be used by a subdevice > > driver to compliment the master device notifier to extend the subdevice > > compliment ->

Re: [PATCH v4 2/3] v4l: async: do not hold list_lock when reprobing devices

Hi Hans, Thanks for your feedback. On 2017-07-18 16:22:14 +0200, Hans Verkuil wrote: > On 17/07/17 18:59, Niklas Söderlund wrote: > > There is no good reason to hold the list_lock when reprobing the devices > > and it prevents a clean implementation of subdevice notifiers. Move the > > actual

Re: [PATCH v4 2/2] media: entity: Add media_entity_get_fwnode_pad() function

Hi Niklas, Small spelling error discovered in here: On 15/06/17 10:17, Niklas Söderlund wrote: > This is a wrapper around the media entity get_fwnode_pad operation. > > Signed-off-by: Niklas Söderlund > Acked-by: Sakari Ailus

Re: [RFC PATCH] media: i2c: mt9p031: Add 8-bit support

Hi Adam, Thank you for the patch. On Tuesday 18 Jul 2017 09:00:54 Adam Ford wrote: > From: Adam Ford > > By default the camera driver only supports monochrome or color at 12-bit. > This patch will allow the camera to choose between 12-bit or 8-bit > resolution. Tested on

Attention To me and get back to me urgent

Attention:Beneficiary I am Meliana Trump, and I am writing to inform you about your Bank Check Draft brought back 16/07/2017 by the United Embassy Mr John Moore from the government of Benin Republic in the white house Washington DC been mandated to be deliver to your home address once you

Re: [PATCH v4 3/3] v4l: async: add subnotifier to subdevices

On 17/07/17 18:59, Niklas Söderlund wrote: > Add a subdevice specific notifier which can be used by a subdevice > driver to compliment the master device notifier to extend the subdevice compliment -> complement Just one character difference, but a wildly different meaning :-) Although it was

Re: [PATCH v4 2/3] v4l: async: do not hold list_lock when reprobing devices

On 17/07/17 18:59, Niklas Söderlund wrote: > There is no good reason to hold the list_lock when reprobing the devices > and it prevents a clean implementation of subdevice notifiers. Move the > actual release of the devices outside of the loop which requires the > lock to be held. > >

[RFC PATCH] media: i2c: mt9p031: Add 8-bit support

From: Adam Ford By default the camera driver only supports monochrome or color at 12-bit. This patch will allow the camera to choose between 12-bit or 8-bit resolution. Tested on Logic PD DM3730 Torpedo Development Kit. Signed-off-by: Adam Ford

[PATCH v2] [media] platform: video-mux: convert to multiplexer framework

Now that the multiplexer framework is merged, drop the temporary mmio-mux implementation from the video-mux driver and convert it to use the multiplexer API. Signed-off-by: Philipp Zabel --- Changes since v1: - Select CONFIG_MULTIPLEXER. ---

Re: [PATCH] [media] platform: video-mux: convert to multiplexer framework

On Tue, 2017-07-18 at 12:03 +0200, Hans Verkuil wrote: > On 17/07/17 12:55, Philipp Zabel wrote: > > Now that the multiplexer framework is merged, drop the temporary > > mmio-mux implementation from the video-mux driver and convert it to use > > the multiplexer API. > > > > Signed-off-by: Philipp

Re: [PATCH v2 00/14] Renesas R-Car VSP: Add H3 ES2.0 support

On 26/06/17 20:12, Laurent Pinchart wrote: > Hello, > > This patch series implements support for the R-Car H3 ES2.0 SoC in the VSP > and DU drivers. > > Compared to the H3 ES1.1, the H3 ES2.0 has a new VSP2-DL instance that > includes two blending units, a BRU and a BRS. The BRS is similar to

Re: [PATCH v2 0/7] [PATCH v2 0/7] Add support of OV9655 camera

On 07/18/2017 02:17 PM, H. Nikolaus Schaller wrote: > Hi, > >> Am 18.07.2017 um 13:59 schrieb Hans Verkuil : >> >> On 12/07/17 22:01, Sylwester Nawrocki wrote: >>> Hi Hugues, >>> >>> On 07/03/2017 11:16 AM, Hugues Fruchet wrote: This patchset enables OV9655 camera

Re: [PATCH v2 0/7] [PATCH v2 0/7] Add support of OV9655 camera

Hi, > Am 18.07.2017 um 13:59 schrieb Hans Verkuil : > > On 12/07/17 22:01, Sylwester Nawrocki wrote: >> Hi Hugues, >> >> On 07/03/2017 11:16 AM, Hugues Fruchet wrote: >>> This patchset enables OV9655 camera support. >>> >>> OV9655 support has been tested using

Re: [PATCH v2 0/7] [PATCH v2 0/7] Add support of OV9655 camera

On 12/07/17 22:01, Sylwester Nawrocki wrote: > Hi Hugues, > > On 07/03/2017 11:16 AM, Hugues Fruchet wrote: >> This patchset enables OV9655 camera support. >> >> OV9655 support has been tested using STM32F4DIS-CAM extension board >> plugged on connector P1 of STM32F746G-DISCO board. >> Due to

Re: [PATCH RFC 2/2] dt-bindings: add binding documentation for Allwinner CSI

Hi Yong, I am trying to get this driver working on the Olimex A33 OLinuXino. I didn't get it working yet, but I had some progress. See the comment below on one issue I encountered. On Tue, Jun 27, 2017 at 07:07:34PM +0800, Yong Deng wrote: > Add binding documentation for Allwinner CSI. > >

Re: [PATCH v6] media: platform: Renesas IMR driver

On 08/07/17 15:31, Konstantin Kozhevnikov wrote: > Hello all, > > the sample is made publicly available, and can be taken from > https://github.com/CogentEmbedded/imr-sv-utest/blob/master/utest/utest-imr.c. > > It doesn't show how luminance/chrominance correction actually works, however. >

Re: [PATCH v2 3/7] [media] ov9650: add device tree support

Hi Sakari, thks for review. On 07/09/2017 01:06 AM, Sakari Ailus wrote: > Hi Hugues, > > On Mon, Jul 03, 2017 at 11:16:04AM +0200, Hugues Fruchet wrote: >> Allows use of device tree configuration data. >> If no device tree data is there, configuration is taken from platform data. >> In order to

[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 --- drivers/i2c/busses/i2c-sh_mobile.c | 8

[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 --- Changes since v2: * rebased to

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

Handling this is special for this driver. Because the hardware needs to initialize the next message in interrupt context, we cannot use the i2c_check_msg_for_dma() directly. This helper only works reliably in process context. So, we need to check during initial preparation of the whole transfer

Re: [PATCH 0/7] Omap3isp CCP2 support

Hi! > I rebased the ccp2 branch and went through the patches. I didn't find > anything really alarming there; I changed one commit description of > "omap3isp: Correctly set IO_OUT_SEL and VP_CLK_POL for CCP2 mode" that had > some junk in it as well as in the last patch changed the condition in >

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

So, after revisiting old mail threads and taking part in a similar discussion on the USB list, here is what I cooked up to document and ease DMA handling for I2C within Linux. Please have a look at the documentation introduced in patch 2 for further details. All patches have been tested with a

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

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

Re: [PATCH 4/7] omap3isp: Return -EPROBE_DEFER if the required regulators can't be obtained

Hi Pavel, On Tue, Jul 18, 2017 at 12:03:52PM +0200, Pavel Machek wrote: > Hi! > > > > diff --git a/drivers/media/platform/omap3isp/ispccp2.c > > > b/drivers/media/platform/omap3isp/ispccp2.c index > > > 4f8fd0c00748..47210b102bcb 100644 > > > --- a/drivers/media/platform/omap3isp/ispccp2.c > > >

Re: [PATCH 4/7] omap3isp: Return -EPROBE_DEFER if the required regulators can't be obtained

Hi Pavel, On Tuesday 18 Jul 2017 12:03:52 Pavel Machek wrote: > Hi! > > >> diff --git a/drivers/media/platform/omap3isp/ispccp2.c > >> b/drivers/media/platform/omap3isp/ispccp2.c index > >> 4f8fd0c00748..47210b102bcb 100644 > >> --- a/drivers/media/platform/omap3isp/ispccp2.c > >> +++

Re: [PATCH 4/7] omap3isp: Return -EPROBE_DEFER if the required regulators can't be obtained

Hi! > > diff --git a/drivers/media/platform/omap3isp/ispccp2.c > > b/drivers/media/platform/omap3isp/ispccp2.c index > > 4f8fd0c00748..47210b102bcb 100644 > > --- a/drivers/media/platform/omap3isp/ispccp2.c > > +++ b/drivers/media/platform/omap3isp/ispccp2.c > > @@ -1140,6 +1140,11 @@ int

Re: [PATCH] [media] platform: video-mux: convert to multiplexer framework

On 17/07/17 12:55, Philipp Zabel wrote: > Now that the multiplexer framework is merged, drop the temporary > mmio-mux implementation from the video-mux driver and convert it to use > the multiplexer API. > > Signed-off-by: Philipp Zabel > --- >

Re: [RFC 11/13] gpio-switch is for some reason neccessary for camera to work.

On Tue 2017-07-18 11:27:53, Pavel Machek wrote: > Hi! > > > On Tue, Feb 14, 2017 at 02:40:19PM +0100, Pavel Machek wrote: > > > Probably something fun happening in userspace. > > > > What's the status of this one? > > > > I don't think it has a chance to be merged in the foreseeable future. Why

Re: [RFC 11/13] gpio-switch is for some reason neccessary for camera to work.

Hi! > On Tue, Feb 14, 2017 at 02:40:19PM +0100, Pavel Machek wrote: > > Probably something fun happening in userspace. > > What's the status of this one? > > I don't think it has a chance to be merged in the foreseeable future. Why > is it needed? Good question. And agreed that this one is not

Re: [PATCH 4/7] omap3isp: Return -EPROBE_DEFER if the required regulators can't be obtained

Hi Sakari, Thank you for the patch. On Tuesday 18 Jul 2017 01:01:13 Sakari Ailus wrote: > From: Pavel Machek > > If regulator returns -EPROBE_DEFER, we need to return it too, so that > omap3isp will be re-probed when regulator is ready. > > Signed-off-by: Pavel Machek

Re: [PATCH 2/7] omap3isp: Parse CSI1 configuration from the device tree

Hi Sakari, Thank you for the patch. On Tuesday 18 Jul 2017 01:01:11 Sakari Ailus wrote: > From: Pavel Machek > > Add support for parsing CSI1 configuration. > > Signed-off-by: Pavel Machek > Signed-off-by: Sakari Ailus > --- >

  1   2   >