Re: [RFC v3 00/21] Make use of kref in media device, grab references as needed

Hi Sakari and Mauro, On 12/13/2016 05:24 AM, Mauro Carvalho Chehab wrote: > Em Tue, 13 Dec 2016 12:53:05 +0200 > Sakari Ailus escreveu: > >> Hi Mauro, >> >> On Tue, Nov 29, 2016 at 09:13:05AM -0200, Mauro Carvalho Chehab wrote: >>> Hi Sakari, >>> >>> I answered you point

Re: [PATCHv3 RFC 4/4] media: Catch null pipes on pipeline stop

Hi Kieran, On Tue, Dec 13, 2016 at 05:59:44PM +, Kieran Bingham wrote: > media_entity_pipeline_stop() can be called through error paths with a > NULL entity pipe object. In this instance, stopping is a no-op, so > simply return without any action The approach of returning silently is wrong;

Re: [PATCH v8 2/4] vcodec: mediatek: Add Mediatek JPEG Decoder Driver

Hi Rick, Can you upload patchset v9 to address the issue? Thanks! On Mon, Dec 12, 2016 at 5:07 PM, Rick Chang wrote: > Hi Ricky, > > Thanks for your feedback. We will fix the problem in another patch. > > On Mon, 2016-12-12 at 12:34 +0800, Ricky Liang wrote: >> Hi Rick,

cron job: media_tree daily build: WARNINGS

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 Dec 14 05:00:35 CET 2016 media-tree git hash:d183e4efcae8d88a2f252e546978658ca6d273cc media_build

[no subject]

Good Day, This is the second time i am sending you this mail. I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me personally for more details. Regards. Friedrich Mayrhofer -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to

[PATCH] media: platform: exynos4-is: constify v4l2_subdev_ops strcutures

Check for v4l2_subdev_ops structures that are only passed as an argument to the function v4l2_subdev_init. This argument is of type const, so v4l2_subdev_ops structures having this property can also be declared const. Done using Coccinelle: @r1 disable optional_qualifier @ identifier i; position

Re: em28xx - Hauppauge WinTV Dualhd atsc/qam

On 12/13/2016 06:05 AM, Kevin Cheng wrote: Hi all, I'm working on support in the em8xx module for the Hauppauge WinTV dualhd atsc/qam usb stick. I'vey got the first tuner+fe working so far, but would appreciate any suggestions/feedback on the items below. the device has: 2x LGDT3306A frontend

Re: [PATCH RFC] [media] s5k6aa: set usleep_range greater 0

Hi Nicholas, On Tue, Dec 13, 2016 at 02:58:02AM +0100, Nicholas Mc Guire wrote: > As this is not in atomic context and it does not seem like a critical > timing setting a range of 1ms allows the timer subsystem to optimize > the hrtimer here. I'd suggest not to. These delays are often directly

[PATCH] media: i2c: m5mols: m5mols_core: constify v4l2_subdev_pad_ops structures

v4l2_subdev_pad_ops structures are stored in the pad field of the v4l2_subdev_ops structure and this field is of type const. As the v4l2_subdev_pad_ops structures are never modified, they can be declared as const. Done using Coccinelle: @r1 disable optional_qualifier @ identifier i; position p;

Re: [PATCH RFC] [media] s5k6aa: set usleep_range greater 0

On 12/13/2016 02:58 AM, Nicholas Mc Guire wrote: > As this is not in atomic context and it does not seem like a critical > timing setting a range of 1ms allows the timer subsystem to optimize > the hrtimer here. > > Fixes: commit bfa8dd3a0524 ("[media] v4l: Add v4l2 subdev driver for S5K6AAFX

Re: [RFC v3 00/21] Make use of kref in media device, grab references as needed

Hi Mauro, On Tue, Nov 29, 2016 at 09:13:05AM -0200, Mauro Carvalho Chehab wrote: > Hi Sakari, > > I answered you point to point below, but I suspect that you missed how the > current approach works. So, I decided to write a quick summary here. > > The character devices /dev/media? are created

Re: [PATCH RFC] [media] s5k6aa: set usleep_range greater 0

On Tue, Dec 13, 2016 at 10:10:51AM +, Ian Arkver wrote: > On 13/12/16 09:43, Sakari Ailus wrote: > >Hi Nicholas, > > > >On Tue, Dec 13, 2016 at 02:58:02AM +0100, Nicholas Mc Guire wrote: > >>As this is not in atomic context and it does not seem like a critical > >>timing setting a range of 1ms

Re: [PATCH RFC] [media] s5k6aa: set usleep_range greater 0

On 13/12/16 09:43, Sakari Ailus wrote: Hi Nicholas, On Tue, Dec 13, 2016 at 02:58:02AM +0100, Nicholas Mc Guire wrote: As this is not in atomic context and it does not seem like a critical timing setting a range of 1ms allows the timer subsystem to optimize the hrtimer here. I'd suggest not

Re: [RFC v3 00/21] Make use of kref in media device, grab references as needed

Em Tue, 13 Dec 2016 12:53:05 +0200 Sakari Ailus escreveu: > Hi Mauro, > > On Tue, Nov 29, 2016 at 09:13:05AM -0200, Mauro Carvalho Chehab wrote: > > Hi Sakari, > > > > I answered you point to point below, but I suspect that you missed how the > > current approach works.

Re: [PATCH v5 02/18] [media] img-ir: use new wakeup_protocols sysfs mechanism

Hi Sean, On Tue, Dec 13, 2016 at 07:54:16AM +, Sean Young wrote: > So that leaves the question open of whether we want to guess the protocol > variant from the scancode for img-ir or if we can live with having to > select this using wakeup_protocols. Having to do this does solve the issue >

[RFT PATCH] [media] partial revert of "[media] tvp5150: add HW input connectors support"

Commit f7b4b54e6364 ("[media] tvp5150: add HW input connectors support") added input signals support for the tvp5150, but the approach was found to be incorrect so the corresponding DT binding commit 82c2ffeb217a ("[media] tvp5150: document input connectors DT bindings") was reverted. This left

[PATCH 4/4] s5p-cec: add hdmi-notifier support, move out of staging

From: Hans Verkuil By using the HDMI notifier framework there is no longer any reason to manually set the physical address. This was the one blocking issue that prevented this driver from going out of staging, so do this move as well. Update the bindings documenting the

[PATCH 1/4] video: add HDMI state notifier support

From: Hans Verkuil Add support for HDMI hotplug and EDID notifiers, which is used to convey information from HDMI drivers to their CEC and audio counterparts. Based on an earlier version from Russell King: https://patchwork.kernel.org/patch/9277043/ The hdmi_notifier

[PATCH 3/4] cec: integrate HDMI notifier support

From: Hans Verkuil Support the HDMI notifier framework, simplifying drivers that depend on this. Signed-off-by: Hans Verkuil --- drivers/media/cec/cec-core.c | 50 include/media/cec.h | 15

[PATCH 2/4] exynos_hdmi: add HDMI notifier support

From: Hans Verkuil Implement the HDMI notifier support to allow CEC drivers to be informed when there is a new EDID and when a connect or disconnect happens. Signed-off-by: Hans Verkuil --- drivers/gpu/drm/exynos/Kconfig | 1 +

[PATCH 0/4] video/exynos/cec: add HDMI state notifier & use in s5p-cec

From: Hans Verkuil This patch series adds the HDMI notifier code, based on Russell's code: https://patchwork.kernel.org/patch/9277043/ It adds support for it to the exynos_hdmi drm driver, adds support for it to the CEC framework and finally adds support to the s5p-cec

[PATCH v6 2/2] Add support for OV5647 sensor.

Modes supported: - 640x480 RAW 8 Signed-off-by: Ramiro Oliveira --- MAINTAINERS| 7 + drivers/media/i2c/Kconfig | 12 + drivers/media/i2c/Makefile | 1 + drivers/media/i2c/ov5647.c | 718 + 4 files

[PATCH v6 1/2] Add OV5647 device tree documentation

Create device tree bindings documentation. Signed-off-by: Ramiro Oliveira --- .../devicetree/bindings/media/i2c/ov5647.txt | 35 ++ 1 file changed, 35 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt diff

Re: [PATCH RFC] [media] s5k6aa: set usleep_range greater 0

Hi Laurent, On 12/13/2016 03:10 PM, Laurent Pinchart wrote: > As pointed out by Ian Arkver, the datasheet states the delay should be >50µs. > Would it make sense to reduce the sleep duration to (3000, 4000) for instance > (or possibly even lower), instead of increasing it ? Theoretically it

Re: [PATCH RFC] [media] s5k6aa: set usleep_range greater 0

Hi Sylwester, On Tuesday 13 Dec 2016 13:38:52 Sylwester Nawrocki wrote: > On 12/13/2016 02:58 AM, Nicholas Mc Guire wrote: > > As this is not in atomic context and it does not seem like a critical > > timing setting a range of 1ms allows the timer subsystem to optimize > > the hrtimer here. > >

[PATCH v6 0/2] Add support for Omnivision OV5647

Hello, This patch adds support for the Omnivision OV5647 sensor. At the moment it only supports 640x480 in Raw 8. This is the sixth version of the OV5647 camera driver patchset. v6: - Add example to DT documentation - Remove data-lanes and clock-lane property from DT - Add external clock

Re: Sony imx219 driver?

Hi Dave On 07/21/2016 08:19 PM, Dave Stevenson wrote: > Just a quick query to avoid duplicating effort. Has anyone worked on a > Sony IMX219 (or other Sony sensor) subdevice driver as yet? > > With the new Raspberry Pi camera being IMX219, and as Broadcom have > released an soc_camera based

[PATCH] drivers: media: i2c: ak881x: constify v4l2_subdev_* structures

v4l2_subdev_{core/video}_ops structures are stored in the fields of the v4l2_subdev_ops structure which are of type const. Also, v4l2_subdev_ops structure is passed to a function having its argument of type const. As these structures are never modified, so declare them as const. Done using

Re: Sony imx219 driver?

Hi Ramiro On 13/12/16 13:47, Ramiro Oliveira wrote: Hi Dave On 07/21/2016 08:19 PM, Dave Stevenson wrote: Just a quick query to avoid duplicating effort. Has anyone worked on a Sony IMX219 (or other Sony sensor) subdevice driver as yet? With the new Raspberry Pi camera being IMX219, and as

[PATCH] drivers: media: i2c: ml86v7667: constify v4l2_subdev_* structures

v4l2_subdev_{core/video}_ops structures are stored in the fields of the v4l2_subdev_ops structure which are of type const. Also, v4l2_subdev_ops structure is passed to a function having its argument of type const. As these structures are never modified, so declare them as const. Done using

[PATCH] drivers: media: i2c: mt9m111: constify v4l2_subdev_* structures

v4l2_subdev_{core/video}_ops structures are stored in the fields of the v4l2_subdev_ops structure which are of type const. Also, v4l2_subdev_ops structure is passed to a function having its argument of type const. As these structures are never modified, so declare them as const. Done using

[PATCH v2] drivers: media: i2c: mt9m111: constify v4l2_subdev_* structures

v4l2_subdev_{core/video}_ops structures are stored in the fields of the v4l2_subdev_ops structure which are of type const. Also, v4l2_subdev_ops structure is passed to a function having its argument of type const. As these structures are never modified, so declare them as const. Done using

[PATCHv3 2/4] v4l: vsp1: Refactor video pipeline configuration

With multiple inputs through the BRU it is feasible for the streams to race each other at stream-on. In the case of the video pipelines, this can present two serious issues. 1) A null-dereference if the pipe->dl is committed at the same time as the vsp1_video_setup_pipeline() is processing

[PATCHv3 RFC 4/4] media: Catch null pipes on pipeline stop

media_entity_pipeline_stop() can be called through error paths with a NULL entity pipe object. In this instance, stopping is a no-op, so simply return without any action Signed-off-by: Kieran Bingham --- I've marked this patch as RFC, although if deemed

[PATCHv3 3/4] v4l: vsp1: Use local display lists and remove global pipe->dl

The usage of pipe->dl is susceptible to races, and it is redundant to keep this pointer in a larger scoped context. Now that the calling order of vsp1_video_setup_pipeline() has been adapted, it is possible to remove the pipe->dl and pass the variable as required. Currently the pipe->dl is set

[PATCHv3 1/4] v4l: vsp1: Move vsp1_video_setup_pipeline()

Move the static vsp1_video_setup_pipeline() function in preparation for the callee updates so that the vsp1_video_pipeline_run() call can configure pipelines following suspend resume actions. This commit is just a code move for clarity performing no functional change. Signed-off-by: Kieran

[PATCHv3 0/4] v4l: vsp1: Fix suspend/resume and race on M2M pipelines

This small patchset helps rework the VSP1 driver to repair an issue on suspend/resume operations whereby the pipeline does not get reconfigured after it has been re-initialised following a resume operation. Along side this, there was an intrinsic race in the vsp1_video_start_streaming() function

Re: [PATCH v2 1/7] ARM: dts: imx6qdl: Add VDOA compatible and clocks properties

On Fri, Dec 09, 2016 at 05:58:57PM +0100, Michael Tretter wrote: > From: Philipp Zabel > > This adds a compatible property and the correct clock for the > i.MX6Q Video Data Order Adapter. This comment matches the dts change, but not the binding change. >

Re: [PATCH v6 2/2] Add support for OV5647 sensor.

On Tue 2016-12-13 14:32:37, Ramiro Oliveira wrote: > Modes supported: > - 640x480 RAW 8 > > Signed-off-by: Ramiro Oliveira Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures)

Re: [PATCH v6 1/2] Add OV5647 device tree documentation

On Tue 2016-12-13 14:32:36, Ramiro Oliveira wrote: > Create device tree bindings documentation. > > Signed-off-by: Ramiro Oliveira > --- > .../devicetree/bindings/media/i2c/ov5647.txt | 35 > ++ > 1 file changed, 35 insertions(+) > create mode

Re: [PATCH v4] media: Driver for Toshiba et8ek8 5MP sensor

Hi! I have finally found the old mail you were refering to. Let me go through it. > > +/* > > + * Convert exposure time `us' to rows. Modify `us' to make it to > > + * correspond to the actual exposure time. > > + */ > > +static int et8ek8_exposure_us_to_rows(struct et8ek8_sensor *sensor, u32 >

[PATCH] vsp1: remove UAPI support for R-Car gen2 VSPDs

We are going to use the R-Car gen2 VSPDs as the DU compositors, so will have to disable the UAPI support for them... Signed-off-by: Sergei Shtylyov --- This patch is against the 'media_tree.git' repo's 'master' branch.

Re: [PATCH] vsp1: remove UAPI support for R-Car gen2 VSPDs

Hi Sergei, On Wednesday 14 Dec 2016 00:15:34 Sergei Shtylyov wrote: > We are going to use the R-Car gen2 VSPDs as the DU compositors, so will > have to disable the UAPI support for them... I'm glad to know that you have a use case for the Gen3 VSP-based DU composition on Gen2, but the VSPD

[PATCH] [media] dib7000p: avoid division by zero

dib7000p_read_word() may return zero on i2c errors, resulting in dib7000p_get_internal_freq() returning zero. So don't divide by the result of dib7000p_get_internal_freq() without checking it for zero in dib7000p_set_dds(). On one of my machines the device ID 2304:0229 Pinnacle Systems, Inc. PCTV