Re: [PATCH v3 14/14] [media] cxd2880 : Update MAINTAINERS file for CXD2880 driver

From: Yasunari Takiguchi I add an e-mail address and re-send this mail again. This is MAINTAINERS file update about the driver for the Sony CXD2880 DVB-T2/T tuner + demodulator. [Change list] Changes in V3 MAINTAINERS -no change Signed-off-by: Yasunari

[PATCH] cec-pin: fix irq handling

The free_irq() function could be called from interrupt context, which is invalid. Move this to the thread. In the interrupt handler we just request that the thread disables the irq. This is done through an atomic so we don't need to add any spinlocks. Signed-off-by: Hans Verkuil

Re: [PATCHv2 1/3] dt-bindings: document the CEC GPIO bindings

On 08/10/2017 10:33 AM, Hans Verkuil wrote: > From: Hans Verkuil > > Document the bindings for the cec-gpio module for hardware where the > CEC pin is connected to a GPIO pin. No need to review this, there will be a v3 that will add a second optional HPD gpio. Regards,

[PATCH 1/1] et8ek8: Decrease stack usage

The et8ek8 driver combines I²C register writes to a single array that it passes to i2c_transfer(). The maximum number of writes is 48 at once, decrease it to 8 and make more transfers if needed, thus avoiding a warning on stack usage. Signed-off-by: Sakari Ailus ---

Re: [PATCH 1/1] et8ek8: Decrease stack usage

On Wed 2017-08-16 10:33:45, Sakari Ailus wrote: > The et8ek8 driver combines I²C register writes to a single array that it > passes to i2c_transfer(). The maximum number of writes is 48 at once, > decrease it to 8 and make more transfers if needed, thus avoiding a > warning on stack usage. Dunno.

Re: [PATCH v2] media: isl6421: add checks for current overflow

Em Tue, 15 Aug 2017 20:51:09 +0100 Jemma Denson escreveu: > Hi Mauro, > > On 13/08/17 20:35, Mauro Carvalho Chehab wrote: > > > This Kaffeine's BZ: > > https://bugs.kde.org/show_bug.cgi?id=374693 > > > > affects SkyStar S2 PCI DVB-S/S2 rev 3.3 device. It could be due to

Re: [PATCH 3/5] s5p-cec: use CEC_CAP_DEFAULTS

On 08/04/2017 12:41 PM, Hans Verkuil wrote: Use the new CEC_CAP_DEFAULTS define in the s5p-cec driver. Signed-off-by: Hans Verkuil Acked-by: Sylwester Nawrocki

Re: [PATCH 1/5] media/cec.h: add CEC_CAP_DEFAULTS

On 08/04/2017 12:41 PM, Hans Verkuil wrote: The CEC_CAP_LOG_ADDRS, CEC_CAP_TRANSMIT, CEC_CAP_PASSTHROUGH and CEC_CAP_RC capabilities are normally always present. Add a CEC_CAP_DEFAULTS define that ORs these four caps to simplify drivers. Signed-off-by: Hans Verkuil

[PATCH 2/2] [media] solo6x10: make snd_kcontrol_new const

Make this const as it is only used during a copy operation. Done using Coccinelle. Signed-off-by: Bhumika Goyal --- drivers/media/pci/solo6x10/solo6x10-g723.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/pci/solo6x10/solo6x10-g723.c

[PATCH 1/2] [media] cx88: make snd_kcontrol_new const

Make this const as it only passed as the 1st argument to the function snd_ctl_new1, which is of type const. Done using Coccinelle. Signed-off-by: Bhumika Goyal --- drivers/media/pci/cx88/cx88-alsa.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH 1/1] et8ek8: Decrease stack usage

On Wed, Aug 16, 2017 at 10:13:05AM +0200, Pavel Machek wrote: > On Wed 2017-08-16 10:33:45, Sakari Ailus wrote: > > The et8ek8 driver combines I²C register writes to a single array that it > > passes to i2c_transfer(). The maximum number of writes is 48 at once, > > decrease it to 8 and make more

[PATCH 0/2] [media]: make snd_kcontrol_new const

Make these const. Done using Coccinelle. Bhumika Goyal (2): [media] cx88: make snd_kcontrol_new const [media] solo6x10: make snd_kcontrol_new const drivers/media/pci/cx88/cx88-alsa.c | 2 +- drivers/media/pci/solo6x10/solo6x10-g723.c | 2 +- 2 files changed, 2 insertions(+), 2

[PATCH v2 0/2] Unified fwnode endpoint parser

Hi folks, We have a large influx of new, unmerged, drivers that are now parsing fwnode endpoints and each one of them is doing this a little bit differently. The needs are still exactly the same for the graph data structure is device independent. This is still a non-trivial task and the majority

[PATCH v2 2/2] v4l: fwnode: Support generic parsing of graph endpoints in a single port

This is the preferred way to parse the endpoints. Signed-off-by: Sakari Ailus --- drivers/media/v4l2-core/v4l2-fwnode.c | 51 +++ include/media/v4l2-fwnode.h | 7 + 2 files changed, 58 insertions(+) diff --git

Re: [PATCH] drm/bridge/sii8620: add remote control support

On 03.08.2017 10:28, Hans Verkuil wrote: > Hi Maciej, > > Unfortunately I do not have the MHL spec, but I was wondering what the > relationship between RCP and CEC is. CEC has remote control support as > well, so is RCP that subset of the CEC specification or is it completely > separate? We also

Re: [RFC PATCH] media: vb2: add bidirectional flag in vb2_queue

Hi Stan, On Wednesday 16 Aug 2017 14:46:50 Stanimir Varbanov wrote: > On 08/15/2017 01:04 PM, Hans Verkuil wrote: > > On 08/14/17 10:41, Stanimir Varbanov wrote: > >> Hi, > >> > >> This RFC patch is intended to give to the drivers a choice to change > >> the default behavior of the v4l2-core DMA

[RESEND PATCH v2 1/2] v4l: fwnode: Support generic parsing of graph endpoints in a device

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

[RESEND PATCH v2 0/2] Unified fwnode endpoint parser

Hi folks, (Resending, got Niklas's e-mail wrong.) We have a large influx of new, unmerged, drivers that are now parsing fwnode endpoints and each one of them is doing this a little bit differently. The needs are still exactly the same for the graph data structure is device independent. This is

[PATCH v2 1/2] v4l: fwnode: Support generic parsing of graph endpoints in a device

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

[PATCH v2 2/2] docs-rst: media: Document broken frame handling in stream stop for CSI-2

Some CSI-2 transmitters will finish an ongoing frame whereas others will not. Document that receiver drivers should not assume a particular behaviour but to work in both cases. Signed-off-by: Sakari Ailus --- Documentation/media/kapi/csi2.rst | 10 ++ 1

[PATCH v2 1/2] docs-rst: media: Document s_stream() video op usage for MC enabled devices

As we begin to add support for systems with Media controller pipelines controlled by more than one device driver, it is essential that we precisely define the responsibilities of each component in the stream control and common practices. Specifically, streaming control is done per sub-device and

[PATCH v2 0/2] Document s_stream video op calling (MC only) and CSI-2 stream stopping

Hi folks, I've updated the patch documenting the s_stream() video op calling for MC enabled devices based on the review comments. since v1: - Split "stopping the transmitter" documentation to a separate patch and move it to csi2.rst which is a better place for it. - Precise that the added

Re: [PATCH v2 0/2] Unified fwnode endpoint parser

The patches depend on the ccp2 patches here: On Wed, Aug 16, 2017 at 02:20:17PM +0300, Sakari Ailus wrote: > Hi folks, > > We have a large influx of new, unmerged, drivers that are now parsing > fwnode endpoints and each one of

[PATCH v2 5/5] omap3isp: Correctly configure routing in PHY release

The PHY configuration was obtained from DT when the PHY was acquired but the same was not done when it was released. Fix this. Signed-off-by: Sakari Ailus --- drivers/media/platform/omap3isp/ispcsiphy.c | 19 +-- 1 file changed, 13 insertions(+), 6

[PATCH v2 2/5] omap3isp: Correctly set IO_OUT_SEL and VP_CLK_POL for CCP2 mode

From: Pavel Machek ISP CSI1 module needs all the bits correctly set to work. Signed-off-by: Ivaylo Dimitrov Signed-off-by: Pavel Machek Signed-off-by: Sakari Ailus Tested-by: Laurent Pinchart

[PATCH v2 4/5] omap3isp: csiphy: Don't assume the CSI receiver is a CSI2 module

The CSI PHY is associated with a CSI receiver. The code assumes this receiver is a CSI2 module and relies on the CSI2 module object heavily to access the ISP or pipeline objects. However, the receiver could also be a CSI1/CCP2 module. Pass a new CSI receiver entity pointer to the CSI PHY acquire

[PATCH v2 1/5] omap3isp: Parse CSI1 configuration from the device tree

From: Pavel Machek Add support for parsing CSI1 configuration. Signed-off-by: Pavel Machek Signed-off-by: Sakari Ailus Reviewed-by: Laurent Pinchart Reviewed-by: Sebastian Reichel

[PATCH v2 0/5] Omap3isp CCP2 support

Hi folks, Here's a respin of the omap3isp ccp2 support patches. since v1: - Root out patches already merged or not needed (omapisp: Ignore endpoints with invalid configuration). - Rework the patch skipping CSI-2 receiver configuration for CCP2 ("omap3isp: Skip CSI-2 receiver initialisation

[PATCH v2 3/5] omap3isp: Always initialise isp and mutex for csiphy1

The PHY is still relevant for CCP2. Signed-off-by: Sakari Ailus Tested-by: Laurent Pinchart # on Beagleboard-xM + MPT9P031 --- drivers/media/platform/omap3isp/ispcsiphy.c | 5 +++-- 1 file changed, 3 insertions(+), 2

[RESEND PATCH v2 2/2] v4l: fwnode: Support generic parsing of graph endpoints in a single port

This is the preferred way to parse the endpoints. Signed-off-by: Sakari Ailus --- drivers/media/v4l2-core/v4l2-fwnode.c | 51 +++ include/media/v4l2-fwnode.h | 7 + 2 files changed, 58 insertions(+) diff --git

Re: [RFC PATCH] media: vb2: add bidirectional flag in vb2_queue

Hi Hans, On 08/15/2017 01:04 PM, Hans Verkuil wrote: > On 08/14/17 10:41, Stanimir Varbanov wrote: >> Hi, >> >> This RFC patch is intended to give to the drivers a choice to change >> the default behavior of the v4l2-core DMA mapping direction from >> DMA_TO/FROM_DEVICE (depending on the buffer

Re: [PATCH v2 4/5] omap3isp: csiphy: Don't assume the CSI receiver is a CSI2 module

Hi Sakari, Thank you for the patch. On Wednesday 16 Aug 2017 15:51:49 Sakari Ailus wrote: > The CSI PHY is associated with a CSI receiver. The code assumes this > receiver is a CSI2 module and relies on the CSI2 module object heavily to > access the ISP or pipeline objects. However, the receiver

[PATCH] [media] ivtv: Fix incompatible type for argument error

The first argument of function snd_ctl_new1 is of type const struct snd_kcontrol_new * but in this file the variable is passed by value to this function. This generated ""incompatible type for argument" error. So, pass the variable by reference. Signed-off-by: Bhumika Goyal

Re: [PATCH 2/3] leds: as3645a: Add LED flash class driver

Hello Sakari, I haven't looked at the driver, but just have a comment about the I2C subsystem. On Wed, Aug 16, 2017 at 2:55 PM, Sakari Ailus wrote: [snip] > + > +static const struct of_device_id as3645a_of_table[] = { > + { .compatible = "ams,as3645a" }, >

[PATCH 3/3] 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

[PATCH 1/3] dt: bindings: Document DT bindings for Analog devices as3645a

From: Sakari Ailus Signed-off-by: Sakari Ailus --- .../devicetree/bindings/leds/ams,as3645a.txt | 56 ++ 1 file changed, 56 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/ams,as3645a.txt

[PATCH 2/3] 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

[PATCH 0/3] AS3645A flash support

Hi everyone, This set adds support for the AS3645A flash driver which can be found e.g. in Nokia N9. The set depeds on the flash patches here so I'd prefer to merge this through mediatree. Jacek: would that be ok for you? Since

[PATCH] [media] cx18: Fix incompatible type for argument error

The first argument of function snd_ctl_new1 is of type const struct snd_kcontrol_new * but in this file the variable is passed by value to this function. This generated ""incompatible type for argument" error. So, pass the variable by reference. Signed-off-by: Bhumika Goyal

Re: [PATCH] uvcvideo: Apply flags from device to actual properties

Hi Edgar, Thank you for the patch. On Tuesday 15 Aug 2017 12:59:47 Edgar Thier wrote: > Use flags the device exposes for UVC controls. In addition to explaining what the patch does, the commit message should explain why the change is needed. What is the problem you're trying to address here ?

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

Hi Wolfram, On Tue, Jul 18, 2017 at 12:23 PM, 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

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

Re: [PATCH 1/2] media: ov7670: Add entity pads initialization

Hi Sakari, On 2017/8/16 0:23, Sakari Ailus wrote: Hi Wenyou, On Thu, Aug 10, 2017 at 05:06:44PM +0800, Wenyou Yang wrote: Add the media entity pads initialization. Signed-off-by: Wenyou Yang The patch itself seems fine. However the driver is lacking support for

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: Thu Aug 17 05:00:15 CEST 2017 media-tree git hash:ec0c3ec497cabbf3bfa03a9eb5edcc252190a4e0 media_build

[PATCH v2.4 5/5] omap3isp: Quit using struct v4l2_subdev.host_priv field

struct v4l2_subdev.host_priv is intended to be used by another driver. This is hardly good design but back in the days of platform data was a quick hack to get things done. As the sub-device specific bus information can be stored to the ISP driver specific struct allocated along with

Re: [PATCH v2.3 5/5] omap3isp: Quit using struct v4l2_subdev.host_priv field

Hi Sakari, Thank you for the patch. On Wednesday 16 Aug 2017 20:39:43 Sakari Ailus wrote: > struct v4l2_subdev.host_priv is intended to be used by another driver. This > is hardly good design but back in the days of platform data was a quick > hack to get things done. > > As the sub-device

Re: [PATCH v2.2 5/5] omap3isp: Quit using struct v4l2_subdev.host_priv field

On Wed, Aug 16, 2017 at 08:24:19PM +0300, Laurent Pinchart wrote: > Hi Sakari, > > Thank you for the patch. > > On Wednesday 16 Aug 2017 20:05:52 Sakari Ailus wrote: > > struct v4l2_subdev.host_priv is intended to be used by another driver. This > > is hardly good design but back in the days of

[PATCH v2.2 5/5] omap3isp: Quit using struct v4l2_subdev.host_priv field

struct v4l2_subdev.host_priv is intended to be used by another driver. This is hardly good design but back in the days of platform data was a quick hack to get things done. As the sub-device specific bus information can be stored to the ISP driver specific struct allocated along with

Re: [PATCH] keytable: ensure udev rule fires on rc input device

On Mon, Aug 07, 2017 at 09:09:26AM +0200, Matthias Reichl wrote: > Hi Sean! > > On Sun, Aug 06, 2017 at 09:56:55AM +0100, Sean Young wrote: > > The rc device is created before the input device, so if ir-keytable runs > > too early the input device does not exist yet. > > > > Ensure that rule

[PATCH v2.1 5/5] omap3isp: Quit using struct v4l2_subdev.host_priv field

struct v4l2_subdev.host_priv is intended to be used by another driver. This is hardly good design but back in the days of platform data was a quick hack to get things done. As the sub-device specific bus information can be stored to the ISP driver specific struct allocated along with

Re: [PATCH v2.2 5/5] omap3isp: Quit using struct v4l2_subdev.host_priv field

Hi Sakari, Thank you for the patch. On Wednesday 16 Aug 2017 20:05:52 Sakari Ailus wrote: > struct v4l2_subdev.host_priv is intended to be used by another driver. This > is hardly good design but back in the days of platform data was a quick > hack to get things done. > > As the sub-device

[PATCH v2.3 5/5] omap3isp: Quit using struct v4l2_subdev.host_priv field

struct v4l2_subdev.host_priv is intended to be used by another driver. This is hardly good design but back in the days of platform data was a quick hack to get things done. As the sub-device specific bus information can be stored to the ISP driver specific struct allocated along with

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 >

[PATCH] [media] coda/imx-vdoa: Check for platform_get_resource() error

From: Fabio Estevam platform_get_resource() may fail and in this case a NULL dereference will occur. Prevent this from happening by returning an error on platform_get_resource() failure. Fixes: b0444f18e0b18abce ("[media] coda: add i.MX6 VDOA driver") Signed-off-by:

Re: [PATCH v2 1/8] v4l: vsp1: Protect fragments against overflow

Hi Kieran, Thank you for the patch. On Monday 14 Aug 2017 16:13:24 Kieran Bingham wrote: > The fragment write function relies on the code never asking it to > write more than the entries available in the list. > > Currently with each list body containing 256 entries, this is fine, > but we can

Re: [PATCH 1/3] dt: bindings: Document DT bindings for Analog devices as3645a

Hi Jacek, Thanks for the review. On Wed, Aug 16, 2017 at 10:27:27PM +0200, Jacek Anaszewski wrote: > Hi Sakari, > > Thanks for the patch. One issue below. > > On 08/16/2017 02:55 PM, Sakari Ailus wrote: > > From: Sakari Ailus > > > > Signed-off-by: Sakari Ailus

Re: [PATCH 2/3] leds: as3645a: Add LED flash class driver

Hi Sakari, Thanks for the patch. I have few more remarks regarding LED class device naming and pm handling below. On 08/16/2017 02:55 PM, Sakari Ailus wrote: > From: Sakari Ailus > > Add a LED flash class driver for the as3654a flash controller. A V4L2 flash > driver for

Re: [PATCH 1/3] dt: bindings: Document DT bindings for Analog devices as3645a

Hi Sakari, Thanks for the patch. One issue below. On 08/16/2017 02:55 PM, Sakari Ailus wrote: > From: Sakari Ailus > > Signed-off-by: Sakari Ailus > --- > .../devicetree/bindings/leds/ams,as3645a.txt | 56 > ++ > 1

Re: [PATCH 0/3] AS3645A flash support

Hi Sakari, On 08/16/2017 02:54 PM, Sakari Ailus wrote: > Hi everyone, > > This set adds support for the AS3645A flash driver which can be found e.g. > in Nokia N9. > > The set depeds on the flash patches here so I'd prefer to merge this > through mediatree. > >