Re: [PATCH 14/15] media: s5p-mfc: Use preallocated block allocator always for MFC v6+

Hello Marek, On 02/14/2017 04:52 AM, Marek Szyprowski wrote: > It turned out that all versions of MFC v6+ hardware doesn't have a strict > requirement for ALL buffers to be allocated on higher addresses than the > firmware base like it was documented for MFC v5. This requirement is true > only

Re: Bug#854100: libdvbv5-0: fails to tune / scan

Hi, Am 13. Februar 2017 schrieb Mauro Carvalho Chehab: > Em Fri, 10 Feb 2017 22:02:01 +0100 > Gregor Jasny escreveu: > >> Bug report against libdvbv5 is here: >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854100 > > There was a bug at the logic that was checking

Re: [PATCH 00/15] Exynos MFC v6+ - remove the need for the reserved memory

Hello Marek, On 02/14/2017 04:51 AM, Marek Szyprowski wrote: > Dear All, > > This patchset is a result of my work on enabling full support for MFC device > (multimedia codec) on Exynos 5433 on ARM64 architecture. Initially I thought > that to let it working on ARM64 architecture with IOMMU, I

Re: [PATCH 02/15] media: s5p-mfc: Use generic of_device_get_match_data helper

Hello Marek, On 02/14/2017 04:51 AM, Marek Szyprowski wrote: > Replace custom code with generic helper to retrieve driver data. > > Signed-off-by: Marek Szyprowski > --- Reviewed-by: Javier Martinez Canillas Tested-by: Javier Martinez Canillas

Re: [PATCH 08/15] media: s5p-mfc: Move firmware allocation to DMA configure function

Hello Marek, On 02/14/2017 04:52 AM, Marek Szyprowski wrote: > To complete DMA memory configuration for MFC device, allocation of the > firmware buffer is needed, because some parameters are dependant on its base > address. Till now, this has been handled in the s5p_mfc_alloc_firmware() >

Re: [PATCH 11/15] media: s5p-mfc: Split variant DMA memory configuration into separate functions

Hello Marek, On 02/14/2017 04:52 AM, Marek Szyprowski wrote: > Move code for DMA memory configuration with IOMMU into separate function > to make it easier to compare what is being done in each case. > > Signed-off-by: Marek Szyprowski > --- >

Re: [PATCH 15/15] ARM: dts: exynos: Remove MFC reserved buffers

Hello Marek, On 02/14/2017 04:52 AM, Marek Szyprowski wrote: > During my research I found that some of the requirements for the memory > buffers for MFC v6+ devices were blindly copied from the previous (v5) > version and simply turned out to be excessive. The relaxed requirements > are applied

Re: [PATCH] [media] Staging: media/lirc: don't call put_ir_rx on rx twice

This one is a false positive. The original code is correct. I was looking through my mail boxes to see the history of this and why it hadn't been fixed earlier. Someone tried to fix it in 2011: https://www.spinics.net/lists/linux-driver-devel/msg17403.html Then I complained about it again in

Re: [PATCH v4 00/36] i.MX Media Driver

On Fri, 2017-02-17 at 14:22 +0200, Sakari Ailus wrote: > Hi Philipp, Steve and Russell, > > On Fri, Feb 17, 2017 at 12:43:38PM +0100, Philipp Zabel wrote: > > On Thu, 2017-02-16 at 14:27 -0800, Steve Longerbeam wrote: > > > > > > On 02/16/2017 02:20 PM, Russell King - ARM Linux wrote: > > > > On

[PATCH] [media] Staging: media/lirc: don't call put_ir_rx on rx twice

From: Colin Ian King There is an exit path where rx is kfree'd on put_ir_rx and then a jump to label out_put_xx will again kfree it with another call to put_ir_rx. Fix this by adding a new label that avoids this 2nd call to put_ir_rx for this specific case. Detected

Re: [PATCH 13/15] media: s5p-mfc: Remove special configuration of IOMMU domain

Hello Marek, On 02/14/2017 04:52 AM, Marek Szyprowski wrote: > The main reason for using special configuration of IOMMU domain was the > problem with MFC firmware, which failed to operate properly when placed > at 0 DMA address. Instead of adding custom code for configuring each > variant of

Re: [PATCH 01/15] media: s5p-mfc: Remove unused structures and dead code

Hello Marek, On 02/14/2017 04:51 AM, Marek Szyprowski wrote: > Remove unused structures, definitions and functions that are no longer > called from the driver code. > > Signed-off-by: Marek Szyprowski > --- Reviewed-by: Javier Martinez Canillas

RE: Dead code in v4l2-mem2mem.c?

Hi Laurent, Thanks a lot for your reply. I would like to also point out the inconsistency of using `v4l2_m2m_get_vq` inside drivers/media/v4l2-core/v4l2-mem2mem.c and inside other files. It appears to me almost all call sites of `v4l2_m2m_get_vq` in drivers/media/v4l2-core/v4l2-mem2mem.c does

Re: [PATCH 09/15] media: s5p-mfc: Allocate firmware with internal private buffer alloc function

Hell Marek, On 02/14/2017 04:52 AM, Marek Szyprowski wrote: > Once firmware buffer has been converted to use s5p_mfc_priv_buf structure, > it is possible to allocate it with existing s5p_mfc_alloc_priv_buf() > function. This change will help to reduce code variants in the next > patches. > >

Re: [PATCH 12/15] media: s5p-mfc: Add support for probe-time preallocated block based allocator

Hello Marek, On 02/14/2017 04:52 AM, Marek Szyprowski wrote: > Current MFC driver depends on the fact that when IOMMU is available, the > DMA-mapping framework and its IOMMU glue will use first-fit allocator. > This was true for ARM architecture, but its not for ARM64 arch. However, in > case of

Re: [PATCH 03/15] media: s5p-mfc: Replace mem_dev_* entries with an array

Hello Marek, On 02/14/2017 04:51 AM, Marek Szyprowski wrote: > Internal MFC driver device structure contains two pointers to devices used > for DMA memory allocation: mem_dev_l and mem_dev_r. Replace them with the > mem_dev[] array and use defines for accessing particular banks. This will > help

Re: [PATCH 04/15] media: s5p-mfc: Replace bank1/bank2 entries with an array

Hello Marek, On 02/14/2017 04:51 AM, Marek Szyprowski wrote: > Internal MFC driver device structure contains two entries for keeping > addresses of the DMA memory banks. Replace them with the dma_base[] array > and use defines for accessing particular banks. This will help to simplify > code in

Re: [PATCH 10/15] media: s5p-mfc: Reduce firmware buffer size for MFC v6+ variants

Hello Marek, On 02/14/2017 04:52 AM, Marek Szyprowski wrote: > Firmware for MFC v6+ variants is not larger than 400 KiB, so there is no > need to allocate a full 1 MiB buffer for it. Reduce it to 512 KiB to keep > proper alignment of allocated buffer. > > Signed-off-by: Marek Szyprowski

Re: [PATCH 06/15] media: s5p-mfc: Move setting DMA max segmetn size to DMA configure function

Hello Marek, On 02/14/2017 04:51 AM, Marek Szyprowski wrote: > Setting DMA max segment size to 32 bit mask is a part of DMA memory > configuration, so move those calls to s5p_mfc_configure_dma_memory() > function. > > Signed-off-by: Marek Szyprowski > --- Reviewed-by:

Re: [PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver

On 02/17/2017 06:16 AM, Philipp Zabel wrote: On Fri, 2017-02-17 at 11:47 +0100, Philipp Zabel wrote: On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote: +static void csi2_dphy_init(struct csi2_dev *csi2) +{ + /* +* FIXME: 0x14 is derived from a fixed D-PHY reference +

Dead code or otherwise invalid memory access in drivers/media/v4l2-core/videobuf-core.c

Hey guys, I found that the definition and usage of macro `CALLPTR` may be problematic. Its definition is, 54 #define CALLPTR(q, f, arg...) \ 55 ((q->int_ops->f) ? q->int_ops->f(arg) : NULL) , which means it can evaluate to NULL. It has two

Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates

On 02/15/2017 06:19 PM, Steve Longerbeam wrote: From: Russell King Setting and getting frame rates is part of the negotiation mechanism between subdevs. The lack of support means that a frame rate at the sensor can't be negotiated through the subdev path. Add

[patch v2] staging: bcm2835-camera: fix error handling in init

The unwinding here isn't right. We don't free gdev[0] and instead free 1 step past what was allocated. Also we can't allocate "dev" then we should unwind instead of returning directly. Fixes: 7b3ad5abf027 ("staging: Import the BCM2835 MMAL-based V4L2 camera driver.") Signed-off-by: Dan

[patch] staging: bcm2835/mmal-vchiq: unlock on error in buffer_from_host()

We should unlock before returning on this error path. Fixes: 7b3ad5abf027 ("staging: Import the BCM2835 MMAL-based V4L2 camera driver.") Signed-off-by: Dan Carpenter diff --git a/drivers/staging/media/platform/bcm2835/mmal-vchiq.c

[PATCH] [media] dvb-usb-dibusb-mc-common: Add MODULE_LICENSE

dvb-usb-dibusb-mc-common is licensed under GPLv2, and if we don't say so then it won't even load since it needs a GPL-only symbol. Reported-by: Dominique Dumont References: https://bugs.debian.org/853110 Cc: sta...@vger.kernel.org # 4.9+ Fixes: e91455a1495a ("[media] dvb-usb:

Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates

On 02/15/2017 06:19 PM, Steve Longerbeam wrote: From: Russell King Setting and getting frame rates is part of the negotiation mechanism between subdevs. The lack of support means that a frame rate at the sensor can't be negotiated through the subdev path. Add

cx231xx: disagrees about version of symbol videobuf_streamoff

I have downloaded the V4L git tree and complied it (apparently) successfully. I did "sudo make install", and (at the end) I see the message that several items of firmware are installed in /lib/firmware. v4l-cx231xx-avcore-01.fw is one of those: -rw-r--r-- 1 root root 16382 Feb 17 17:46

[PATCH] bcm2048: Fix checkpatch checks

Fix following checks: CHECK: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() + BUG_ON((index+2) >= BCM2048_MAX_RDS_RT); CHECK: spaces preferred around that '+' (ctx:VxV) + BUG_ON((index+2) >= BCM2048_MAX_RDS_RT); ^

RE: [PATCH] media: uvcvideo: Add support for changing UVC_URBS/UVC_MAX_PACKETS from sysfs

Ping ! >-Original Message- >From: Anurag Kumar Vulisha [mailto:anurag.kumar.vuli...@xilinx.com] >Sent: Friday, February 03, 2017 10:10 PM >To: Laurent Pinchart ; Mauro Carvalho >Chehab >Cc: Punnaiah Choudary Kalluri

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: Sat Feb 18 05:00:17 CET 2017 media-tree git hash:9eeb0ed0f30938f31a3d9135a88b9502192c18dd media_build

v4l2: Adding support for multiple MIPI CSI-2 virtual channels

Hi, I have a v4l2_subdev that provides multiple MIPI CSI-2 Virtual Channels. I want to configure each virtual channel individually (e.g. set_fmt), but the v4l2 interface does not seem to have a clear way to access configuration on a virtual channel level, but only the v4l2_subdev as a whole.

Re: [PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver

On Fri, 2017-02-17 at 11:47 +0100, Philipp Zabel wrote: > On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote: > > Adds MIPI CSI-2 Receiver subdev driver. This subdev is required > > for sensors with a MIPI CSI2 interface. > > > > Signed-off-by: Steve Longerbeam

Re: [PATCH 05/15] media: s5p-mfc: Simplify alloc/release private buffer functions

Hello Marek, On 02/14/2017 04:51 AM, Marek Szyprowski wrote: > Change parameters for s5p_mfc_alloc_priv_buf() and s5p_mfc_release_priv_buf() > functions. Instead of DMA device pointer and a base, provide common MFC > device structure and memory bank context identifier. > > Signed-off-by: Marek

Re: [PATCH 07/15] media: s5p-mfc: Put firmware to private buffer structure

Hello Marek, On 02/14/2017 04:52 AM, Marek Szyprowski wrote: > Use s5p_mfc_priv_buf structure for keeping the firmware image. This will > help handling of firmware buffer allocation in the next patches. > > Signed-off-by: Marek Szyprowski > --- Reviewed-by: Javier

Re: [Patch 0/2] media: ti-vpe: allow user specified stride

On 13/02/17 15:06, Benoit Parrot wrote: > This patch series enables user specified buffer stride to be used > instead of always forcing the stride from the driver side. > > Benoit Parrot (2): > media: ti-vpe: vpdma: add support for user specified stride > media: ti-vpe: vpe: allow use of user

Re: Dead code in v4l2-mem2mem.c?

Hi Shaobo, First of all, could you please make sure you send future mails to the linux- media mailing list in plain text only (no HTML) ? The mailing list server rejects HTML e-mails. On Thursday 16 Feb 2017 16:08:25 Shaobo wrote: > Hi there, > > My name is Shaobo He and I am a graduate

[PATCH] v4l-utils: fix invalid protocol in streamzap keymap

ir-keytable can't load the streamzap keymap because the protocol type RC5_SZ is invalid: ./ir-keytable -w rc_keymaps/streamzap Protocol RC5_SZ invalid ... Fix this by changing the protocol type to RC-5-SZ which matches the kernel protocol rc-5-sz Signed-off-by: Matthias Reichl

[no subject]

Good morning sir/madam, we are presently offering business and personal loans at low rates at Al Futtaim GE Finance for 2 percent per year and you are qualified to received the loan. if interested, send request now to: aeonthan...@gmail.com

Re: [PATCH v4 18/36] media: Add i.MX media core driver

On Thu, 2017-02-16 at 17:33 -0800, Steve Longerbeam wrote: > > On 02/16/2017 05:02 AM, Philipp Zabel wrote: > > On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote: > > >> + > >> +- Clean up and move the ov5642 subdev driver to drivers/media/i2c, and > >> + create the binding docs for it.

Re: [PATCH v4 00/36] i.MX Media Driver

Hi Philipp, Steve and Russell, On Fri, Feb 17, 2017 at 12:43:38PM +0100, Philipp Zabel wrote: > On Thu, 2017-02-16 at 14:27 -0800, Steve Longerbeam wrote: > > > > On 02/16/2017 02:20 PM, Russell King - ARM Linux wrote: > > > On Wed, Feb 15, 2017 at 06:19:02PM -0800, Steve Longerbeam wrote: > >

Re: [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

On Fri, Feb 17, 2017 at 8:11 AM, Joe Perches wrote: > There are ~4300 uses of pr_warn and ~250 uses of the older > pr_warning in the kernel source tree. > > Make the use of pr_warn consistent across all kernel files. > > This excludes all files in tools/ as there is a separate >

Re: [PATCH v4 00/36] i.MX Media Driver

On Fri, Feb 17, 2017 at 02:22:14PM +0200, Sakari Ailus wrote: > Hi Philipp, Steve and Russell, > > On Fri, Feb 17, 2017 at 12:43:38PM +0100, Philipp Zabel wrote: > > I think with Russell's explanation of how the imx219 sensor operates, > > we'll have to do something before calling the sensor

[PATCH v3 2/3] stih-cec: add HPD notifier support

By using the HPD 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 documentation the new hdmi phandle. Signed-off-by: Benjamin

Re: [PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver

On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote: > Adds MIPI CSI-2 Receiver subdev driver. This subdev is required > for sensors with a MIPI CSI2 interface. > > Signed-off-by: Steve Longerbeam > --- > drivers/staging/media/imx/Makefile | 1 + >

Re: [PATCH v4 00/36] i.MX Media Driver

On Fri, 2017-02-17 at 10:56 +, Russell King - ARM Linux wrote: > On Fri, Feb 17, 2017 at 11:39:11AM +0100, Philipp Zabel wrote: > > On Thu, 2017-02-16 at 22:57 +, Russell King - ARM Linux wrote: > > > On Thu, Feb 16, 2017 at 02:27:41PM -0800, Steve Longerbeam wrote: > > > > > > > > > > >

Re: [PATCH v4 00/36] i.MX Media Driver

On Thu, 2017-02-16 at 14:27 -0800, Steve Longerbeam wrote: > > On 02/16/2017 02:20 PM, Russell King - ARM Linux wrote: > > On Wed, Feb 15, 2017 at 06:19:02PM -0800, Steve Longerbeam wrote: > >> In version 4: > > > > With this version, I get: > > > > [28762.892053] imx6-mipi-csi2: LP-11 timeout,

Re: [PATCH v4 00/36] i.MX Media Driver

On Thu, 2017-02-16 at 22:57 +, Russell King - ARM Linux wrote: > On Thu, Feb 16, 2017 at 02:27:41PM -0800, Steve Longerbeam wrote: > > > > > > On 02/16/2017 02:20 PM, Russell King - ARM Linux wrote: > > >On Wed, Feb 15, 2017 at 06:19:02PM -0800, Steve Longerbeam wrote: > > >>In version 4: >

[PATCH v3 3/3] arm: sti: update sti-cec for HPD notifier support

To use HPD notifier sti CEC driver needs to get phandle of the hdmi device. Signed-off-by: Benjamin Gaignard Signed-off-by: Hans Verkuil CC: devicet...@vger.kernel.org version 3: - change hdmi phandle from "st,hdmi-handle" to "hdmi-handle"

[PATCH v3 1/3] sti: hdmi: add HPD notifier support

Implement the HPD 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: Benjamin Gaignard Signed-off-by: Hans Verkuil --- drivers/gpu/drm/sti/Kconfig| 1 +

[PATCH v3 0/3] video/sti/cec: add HPD notifier support

This patch series following what Hans is doing on exynos to support hotplug detect notifier code. It add support of HPD in sti_hdmi drm driver and stih-cec driver which move out of staging. Those patches should be applied on top of Hans branch exynos4-cec. I have tested hdmi notifier by

Re: [PATCH v4 00/36] i.MX Media Driver

On Fri, Feb 17, 2017 at 11:39:11AM +0100, Philipp Zabel wrote: > On Thu, 2017-02-16 at 22:57 +, Russell King - ARM Linux wrote: > > On Thu, Feb 16, 2017 at 02:27:41PM -0800, Steve Longerbeam wrote: > > > > > > > > > On 02/16/2017 02:20 PM, Russell King - ARM Linux wrote: > > > >On Wed, Feb

Re: [PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver

On Fri, Feb 17, 2017 at 11:47:59AM +0100, Philipp Zabel wrote: > On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote: > > +static void csi2_dphy_init(struct csi2_dev *csi2) > > +{ > > + /* > > +* FIXME: 0x14 is derived from a fixed D-PHY reference > > +* clock from the HSI_TX PLL,

[PATCH] CEC documentation fixes

Fixed a few spelling mistakes, but mostly incorrect rst syntax that caused wrong references or font style. No actual documentation changes, just fixes. Signed-off-by: Hans Verkuil --- diff --git a/Documentation/media/uapi/cec/cec-func-ioctl.rst

Re: [PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver

On Fri, 2017-02-17 at 11:06 +, Russell King - ARM Linux wrote: > On Fri, Feb 17, 2017 at 11:47:59AM +0100, Philipp Zabel wrote: > > On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote: > > > +static void csi2_dphy_init(struct csi2_dev *csi2) > > > +{ > > > + /* > > > + * FIXME: 0x14 is

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

The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8 and RAW 10 output formats, and MIPI CSI-2 interface. The driver adds support for 640x480 RAW 8. Signed-off-by: Ramiro Oliveira --- MAINTAINERS| 7 + drivers/media/i2c/Kconfig |

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

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

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

Hello, This patchset adds support for the Omnivision OV5647 sensor. At the moment it only supports 640x480 in RAW 8. This is the ninth version of the OV5647 camera driver patchset. v9: - Remove unused struct - Remove comments - Refactor error handling in i2c r/w functions - Change