Re: [PATCH 2/4] [media] pxa_camera: Fix incorrect test in the image size generation

[Petr Cvek]

Dne 2.5.2017 v 16:43 Robert Jarzmik napsal(a):
> Petr Cvek  writes:
> 
>> During the transfer from the soc_camera a test in pxa_mbus_image_size()
>> got removed. Without it any PXA_MBUS_LAYOUT_PACKED format causes either
>> the return of a wrong value (PXA_MBUS_PACKING_2X8_PADHI doubles
>> the correct value) or EINVAL (PXA_MBUS_PACKING_NONE and
>> PXA_MBUS_PACKING_EXTEND16). This was observed in an error from the ffmpeg
>> (for some of the YUYV subvariants).
>>
>> This patch re-adds the same test as in soc_camera version.
>>
>> Signed-off-by: Petr Cvek 
> Did you test that with YUV422P format ?
> If yes, then you can have my ack.

pxa27x-camera pxa27x-camera.0: s_fmt_vid_cap(pix=320x240:50323234)

And mplayer to framebuffer "somewhat" works (it timeouts after some time but it 
does regardless on format, ffmpeg is fine).

Anyway the patch does not affect V4L2_PIX_FMT_YUV422P in any way as the .layout 
field is PXA_MBUS_LAYOUT_PLANAR_2Y_U_V and test is only for "== 
PXA_MBUS_LAYOUT_PACKED"

> 
> And you should add Hans to the reviewers list, it's his call ultimately, and 
> his
> tree which should carry it on.
> 
> Cheers.
> 
> --
> Robert
> 

Petr

cron job: media_tree daily build: ERRORS

[Hans Verkuil]

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 May  3 05:00:26 CEST 2017
media-tree git hash:3622d3e77ecef090b5111e3c5423313f11711dfa
media_build git hash:   1af19680bde3e227d64d99ff5fdc43eb343a3b28
v4l-utils git hash: 847bf8d62cd6b11defc1e4c3b30b68d3c66876e0
gcc version:i686-linux-gcc (GCC) 6.3.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.9.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: ERRORS
linux-3.12.67-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: OK
linux-4.9-i686: OK
linux-4.10.1-i686: OK
linux-4.11-rc1-i686: OK
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-x86_64: OK
linux-3.7.4-x86_64: OK
linux-3.8-x86_64: OK
linux-3.9.2-x86_64: OK
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: ERRORS
linux-3.12.67-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: WARNINGS
linux-4.9-x86_64: WARNINGS
linux-4.10.1-x86_64: WARNINGS
linux-4.11-rc1-x86_64: OK
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html

[PATCH v3 2/2] em28xx: add support for new of Terratec H6

[Mauro Carvalho Chehab]

There's a new version of Terratec H6 with uses USB ID
0ccd:10b2. This version is similar to the old one (with is
supported via the HTC entry), except that this one has the
eeprom on the second bus.

On this board, one side of this board is labeled with:
dvbc v2.0
The other side with:
94V-0, MO2, RK-4221 with huge digits: 1107

With those patches, the board is properly detected:

em28xx 1-1.5:1.0: New device TERRATEC TERRATCE H5 MKII @ 480 Mbps 
(0ccd:10b2, interface 0, class 0)
em28xx 1-1.5:1.0: Audio interface 0 found (Vendor Class)
em28xx 1-1.5:1.0: Video interface 0 found: isoc
em28xx 1-1.5:1.0: DVB interface 0 found: isoc
em28xx 1-1.5:1.0: chip ID is em2884
em28xx eeprom : 26 00 00 00 02 0b 0f e5 f5 64 01 60 09 e5 f5 64  
&d.`...d
em28xx eeprom 0010: 09 60 03 c2 c6 22 e5 f7 b4 03 13 e5 f6 b4 87 03  
.`..."..
em28xx eeprom 0020: 02 0a b9 e5 f6 b4 93 03 02 09 46 c2 c6 22 c2 c6  
..F.."..
em28xx eeprom 0030: 22 00 60 00 ef 70 08 85 3d 82 85 3c 83 93 ff ef  
".`..p..=..<
em28xx eeprom 0040: 60 19 85 3d 82 85 3c 83 e4 93 12 07 a3 12 0a fe  
`..=..<.
em28xx eeprom 0050: 05 3d e5 3d 70 02 05 3c 1f 80 e4 22 12 0b 06 02  
.=.=p..<..."
em28xx eeprom 0060: 07 e2 01 00 1a eb 67 95 cd 0c b2 10 f0 13 6b 03  
..g...k.
em28xx eeprom 0070: 98 22 6a 1c 86 12 27 57 4e 16 29 00 60 00 00 00  
."j...'WN.).`...
em28xx eeprom 0080: 02 00 00 00 5e 00 13 00 f0 10 44 82 82 00 00 00  
^.D.
em28xx eeprom 0090: 5b 81 c0 00 00 00 20 40 20 80 02 20 10 01 00 00  
[. @ .. 
em28xx eeprom 00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  

em28xx eeprom 00b0: c6 40 00 00 81 00 00 00 00 00 00 00 00 c4 00 00  
.@..
em28xx eeprom 00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1c 03  

em28xx eeprom 00d0: 31 00 32 00 33 00 34 00 35 00 36 00 37 00 38 00  
1.2.3.4.5.6.7.8.
em28xx eeprom 00e0: 39 00 41 00 42 00 43 00 44 00 12 03 54 00 45 00  
9.A.B.C.D...T.E.
em28xx eeprom 00f0: 52 00 52 00 41 00 54 00 45 00 43 00 22 03 54 00  
R.R.A.T.E.C.".T.
em28xx 1-1.5:1.0: eeprom 000100: ... (skipped)
em28xx 1-1.5:1.0: EEPROM ID = 26 00 00 00, EEPROM hash = 0xbcd5a8cf
em28xx 1-1.5:1.0: EEPROM info:
em28xx 1-1.5:1.0:   microcode start address = 0x0004, boot configuration = 
0x00
em28xx 1-1.5:1.0:   I2S audio, 5 sample rates
em28xx 1-1.5:1.0:   500mA max power
em28xx 1-1.5:1.0:   Table at offset 0x27, strings=0x2298, 0x1c6a, 0x1286
em28xx 1-1.5:1.0: Identified as Terratec Cinergy H6 rev. 2 (card=101)
em28xx 1-1.5:1.0: Currently, V4L2 is not supported on this model
em28xx 1-1.5:1.0: dvb set to isoc mode.
usbcore: registered new interface driver em28xx
em28xx 1-1.5:1.0: Binding audio extension
em28xx 1-1.5:1.0: em28xx-audio.c: Copyright (C) 2006 Markus Rechberger
em28xx 1-1.5:1.0: em28xx-audio.c: Copyright (C) 2007-2016 Mauro Carvalho 
Chehab
em28xx 1-1.5:1.0: Endpoint 0x83 high-speed on intf 0 alt 7 interval = 8, 
size 196
em28xx 1-1.5:1.0: Number of URBs: 1, with 64 packets and 192 size
em28xx 1-1.5:1.0: Audio extension successfully initialized
em28xx: Registered (Em28xx Audio Extension) extension
em28xx 1-1.5:1.0: Binding DVB extension
drxk: status = 0x639260d9
drxk: detected a drx-3926k, spin A3, xtal 20.250 MHz
drxk: DRXK driver version 0.9.4300
drxk: frontend initialized.
tda18271 4-0060: creating new instance
tda18271: TDA18271HD/C2 detected @ 4-0060
dvbdev: DVB: registering new adapter (1-1.5:1.0)
em28xx 1-1.5:1.0: DVB: registering adapter 0 frontend 0 (DRXK DVB-C 
DVB-T)...
dvbdev: dvb_create_media_entity: media entity 'DRXK DVB-C DVB-T' registered.
dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered.
em28xx 1-1.5:1.0: DVB extension successfully initialized
em28xx: Registered (Em28xx dvb Extension) extension
em28xx 1-1.5:1.0: Registering input extension
rc rc0: 1-1.5:1.0 IR as 
/devices/platform/soc/3f98.usb/usb1/1-1/1-1.5/1-1.5:1.0/rc/rc0
Registered IR keymap rc-nec-terratec-cinergy-xs
input: 1-1.5:1.0 IR as 
/devices/platform/soc/3f98.usb/usb1/1-1/1-1.5/1-1.5:1.0/rc/rc0/input0
em28xx 1-1.5:1.0: Input extension successfully initalized
em28xx: Registered (Em28xx Input Extension) extension
tda18271: performing RF tracking filter calibration
tda18271: RF tracking filter calibration complete

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/usb/em28xx/em28xx-cards.c | 18 ++
 drivers/media/usb/em28xx/em28xx-dvb.c   |  1 +
 drivers/media/usb/em28xx/em28xx.h   |  1 +
 3 files changed, 20 insertions(+)

diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
b/drivers/media/usb/em28xx/em28xx-cards.c
index a12b599a1fa2..25e952b176ae 100644
--- 

[PATCH v3 1/2] em28xx: Ignore errors while reading from eeprom

[Mauro Carvalho Chehab]

While testing support for Terratec H6 rev. 2, it was noticed
that reading from eeprom there causes a timeout error.

Apparently, this is due to the need of properly setting GPIOs.

In any case, the driver doesn't really require eeprom reading
to succeed, as this is currently used only for debug.

So, Ignore such errors.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/usb/em28xx/em28xx-i2c.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c 
b/drivers/media/usb/em28xx/em28xx-i2c.c
index 8c472d5adb50..60b195c157b8 100644
--- a/drivers/media/usb/em28xx/em28xx-i2c.c
+++ b/drivers/media/usb/em28xx/em28xx-i2c.c
@@ -982,8 +982,6 @@ int em28xx_i2c_register(struct em28xx *dev, unsigned bus,
dev_err(>intf->dev,
"%s: em28xx_i2_eeprom failed! retval [%d]\n",
__func__, retval);
-
-   return retval;
}
}
 
-- 
2.9.3

[PATCH v3 0/2] Add support for Terratec H6 version 2

[Mauro Carvalho Chehab]

That's the third version of this patch series. It adds support
for Terratec H6 version 2.

As on the past version, this board is identified as "H5 MKII".
There's a typo on the manufacturer's name, though:

[ 2970.196999] usb 1-1.5: Product: TERRATCE H5 MKII
[ 2970.197011] usb 1-1.5: Manufacturer: TERRATEC

While I wrote the patches, I don't have this verson of
this device. The tests were run by an IRC user. Thanks!

The first patch is actually not needed for this device to work,
but it fixes an issue: if something goes bad while reading
the eeprom, the device probe aborts. As we don't really need
to read the eeprom contents, we safely ignore any errors there.

While not certain why eeprom reading was failing with this
device, I suspect that this particular device require some
GPIO setting before being able to read its eeprom content.

The second patch in this series add support for the board.

-

v3: Improve patch documentation
v2: Ignore eeprom errors
v1: was assuming that eeprom would be at bus 1. such hipotesys
didn't confirm on the tests done today.

Mauro Carvalho Chehab (2):
  em28xx: Ignore errors while reading from eeprom
  em28xx: add support for new of Terratec H6

 drivers/media/usb/em28xx/em28xx-cards.c | 18 ++
 drivers/media/usb/em28xx/em28xx-dvb.c   |  1 +
 drivers/media/usb/em28xx/em28xx-i2c.c   |  2 --
 drivers/media/usb/em28xx/em28xx.h   |  1 +
 4 files changed, 20 insertions(+), 2 deletions(-)

-- 
2.9.3

Re: [PATCH] v4l2-async: add v4l2_async_match()

[Niklas Söderlund]

Hej Sakari,

Thanks for your feedback.

On 2017-05-02 23:23:47 +0300, Sakari Ailus wrote:
> Hi Niklas,
> 
> Niklas Söderlund wrote:
> > For drivers registering notifiers with more then one subdevices it's
> > difficult to know exactly which one is being bound in each call to the
> > notifiers bound callback. Comparing OF nodes became harder after the
> > introduction of fwnode where the two following comparisons are not equal
> > but where so previous to fwnode.
> > 
> > asd.match.fwnode.fwnode == of_fwnode_handle(subdev->dev->of_node)
> > 
> > asd.match.fwnode.fwnode == of_fwnode_handle(subdev->of_node)
> > 
> > It's also not ideal to directly access the asd.match union without first
> > checking the match_type. So to make it easier for drivers to perform
> > this type of matching export the v4l2 async match helpers with a new
> > symbol v4l2_async_match(). This wold replace the comparisons above with:
> > 
> > v4l2_async_match(subdev, )
> 
> Where do you need such a thing, i.e. what do you want to do? Do you have an
> example of where this is helpful?
> 
> The async framework has been designed to make it easy to store driver
> specific information to an async sub-device but I'm not sure if all drivers
> do this. Some do at least.

You are correct, there is no need for this patch. Please disregard it, 
and sorry for the noise.

Laurent also pointed this out to me and asked why I did not use the 
v4l2_async_subdev pointer provided to the notifier bound callback 
instead of the subdev->of_node to match. I now feel rather silly.. But 
with that modification my issue is solved without any v4l2 modifications 
and the code is more clear so I'm also happy.

> 
> -- 
> Kind regards,
> 
> Sakari Ailus
> sakari.ai...@linux.intel.com

-- 
Regards,
Niklas Söderlund

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

[Laurent Pinchart]

Hi Geert,

On Wednesday 22 Mar 2017 10:34:16 Geert Uytterhoeven wrote:
> On Thu, Mar 9, 2017 at 9:08 PM, Sergei Shtylyov wrote:
> > --- /dev/null
> > +++ media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
> > @@ -0,0 +1,27 @@
> > +Renesas R-Car Image Renderer (Distortion Correction Engine)
> > +---
> > +
> > +The image renderer, or the distortion correction engine, is a drawing
> > processor
> > +with a simple instruction system capable of referencing video capture
> > data or
> > +data in an external memory as 2D texture data and performing texture
> > mapping
> > +and drawing with respect to any shape that is split into triangular
> > objects.
> > +
> > +Required properties:
> > +
> > +- compatible: "renesas,-imr-lx4", "renesas,imr-lx4" as a
> > fallback for
> > +  the image renderer light extended 4 (IMR-LX4) found in the R-Car gen3
> > SoCs,
> > +  where the examples with  are:
> > +  - "renesas,r8a7795-imr-lx4" for R-Car H3,
> > +  - "renesas,r8a7796-imr-lx4" for R-Car M3-W.
> 
> Laurent: what do you think about the need for SoC-specific compatible
> values for the various IM* blocks?

There's no documented IP core version register, but when dumping all 
configuration registers on H3 and M3-W I noticed that register 0x002c, not 
documented in the datasheet, reads 0x14060514 on all four IMR instances in H3, 
and 0x20150505 on both instances in M3-W.

This looks like a version register to me. If my assumption is correct, we 
could do without any SoC-specific compatible string.

-- 
Regards,

Laurent Pinchart

Re: [PATCH] libdvbv5: T2 delivery descriptor: fix wrong size of bandwidth field

[Mauro Carvalho Chehab]

Em Tue, 2 May 2017 22:30:29 +0200
Gregor Jasny  escreveu:

> Hello Clemens,
> 
> On 4/1/17 5:50 PM, Clemens Ladisch wrote:
> > ETSI EN 300 468 V1.11.1 § 6.4.4.2 defines the bandwith field as having
> > four bits.  
> 
> I just used your patch and another to hopefully fix
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859008
> 
> But I'm a little bit hesitant to merge it to v4l-utils git without
> Mauros acknowledgement.

I'll take a look on them likely tomorrow.

Thanks!
Mauro

Re: [PATCH 2/6] rc-core: cleanup rc_register_device

[Sean Young]

On Tue, May 02, 2017 at 08:53:02PM +0200, David Härdeman wrote:
> On Mon, May 01, 2017 at 07:47:25PM +0200, David Härdeman wrote:
> >On Mon, May 01, 2017 at 05:49:53PM +0100, Sean Young wrote:
> >>On Thu, Apr 27, 2017 at 10:34:03PM +0200, David Härdeman wrote:
> >>> The device core infrastructure is based on the presumption that
> >>> once a driver calls device_add(), it must be ready to accept
> >>> userspace interaction.
> >>> 
> >>> This requires splitting rc_setup_rx_device() into two functions
> >>> and reorganizing rc_register_device() so that as much work
> >>> as possible is performed before calling device_add().
> >>> 
> >>
> >>With this patch applied, I'm no longer getting any scancodes from
> >>my rc devices.
> >>
> >>David, please can you test your patches before submitting. I have to go
> >>over them meticulously because I cannot assume you've tested them.
> >
> >I did test this patch and I just redid the tests, both with rc-loopback
> >and with a mceusb receiver. I'm seeing scancodes on the input device as
> >well as pulse-space readings on the lirc device in both tests.
> >
> >I did the tests with only this patch applied and the lirc-use-after-free
> >(v3). What hardware did you test with?
> >
> >Meanwhile, I'll try rebasing my patches to the latest version of the
> >media-master git tree and test again.
> 
> I rebased the patches onto media-master (commit
> 3622d3e77ecef090b5111e3c5423313f11711dfa) and tested again. I still
> can't reproduce the problems you're having :/

The protocol is not set properly. In rc_prepare_rx_device(), 
dev->change_protocol() is call if not null. At this point it still is
null, since it will only be set up in ir_raw_event_prepare(), which
is called afterwards.

Presumably you have udev set up to execute ir-keytable, which sets the
protocol up (again).

There is another problem with your patches, you've introduced a race
condition. When device_add() is called, the protocol is not set up yet.
So anyone reading the protocols sysfs attribute early enough will get
false information. Is it not possible to make sure that it is all setup
correctly at the point of device_add()?


Sean

Re: [PATCH] libdvbv5: T2 delivery descriptor: fix wrong size of bandwidth field

[Gregor Jasny]

Hello Clemens,

On 4/1/17 5:50 PM, Clemens Ladisch wrote:
> ETSI EN 300 468 V1.11.1 § 6.4.4.2 defines the bandwith field as having
> four bits.

I just used your patch and another to hopefully fix
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859008

But I'm a little bit hesitant to merge it to v4l-utils git without
Mauros acknowledgement.

Thanks,
Gregor

Re: [PATCH] v4l2-async: add v4l2_async_match()

[Sakari Ailus]

Hi Niklas,

Niklas Söderlund wrote:

For drivers registering notifiers with more then one subdevices it's
difficult to know exactly which one is being bound in each call to the
notifiers bound callback. Comparing OF nodes became harder after the
introduction of fwnode where the two following comparisons are not equal
but where so previous to fwnode.

asd.match.fwnode.fwnode == of_fwnode_handle(subdev->dev->of_node)

asd.match.fwnode.fwnode == of_fwnode_handle(subdev->of_node)

It's also not ideal to directly access the asd.match union without first
checking the match_type. So to make it easier for drivers to perform
this type of matching export the v4l2 async match helpers with a new
symbol v4l2_async_match(). This wold replace the comparisons above with:

v4l2_async_match(subdev, )


Where do you need such a thing, i.e. what do you want to do? Do you have 
an example of where this is helpful?


The async framework has been designed to make it easy to store driver 
specific information to an async sub-device but I'm not sure if all 
drivers do this. Some do at least.


--
Kind regards,

Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH v8 01/10] firmware: qcom_scm: Fix to allow COMPILE_TEST-ing

[Bjorn Andersson]

On Fri 28 Apr 02:13 PDT 2017, Stanimir Varbanov wrote:

> Unfortunatly previous attempt to allow consumer drivers to
> use COMPILE_TEST option in Kconfig is not enough, because in the
> past the consumer drivers used 'depends on' Kconfig option but
> now they are using 'select' Kconfig option which means on non ARM
> arch'es compilation is triggered. Thus we need to move the ifdefery
> one level below by touching the private qcom_scm.h header.
> 
> To: Andy Gross 

"To" should not be listed in the commit message and "Cc" means that you
really do expect Stephen and myself to say something - i.e. it's not the
same as To and Cc in the email header.

> Cc: Stephen Boyd 
> Cc: Bjorn Andersson 
> Signed-off-by: Stanimir Varbanov 
> ---
>  drivers/firmware/Kconfig|  2 +-
>  drivers/firmware/qcom_scm.h | 72 
> ++---
>  include/linux/qcom_scm.h| 32 
>  3 files changed, 62 insertions(+), 44 deletions(-)
> 
> diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
> index 6e4ed5a9c6fd..480578c3691a 100644
> --- a/drivers/firmware/Kconfig
> +++ b/drivers/firmware/Kconfig
> @@ -204,7 +204,7 @@ config FW_CFG_SYSFS_CMDLINE
>  
>  config QCOM_SCM
>   bool
> - depends on ARM || ARM64
> + depends on ARM || ARM64 || COMPILE_TEST
>   select RESET_CONTROLLER
>  
>  config QCOM_SCM_32
> diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h
> index 9bea691f30fb..d2b5723afb3f 100644
> --- a/drivers/firmware/qcom_scm.h
> +++ b/drivers/firmware/qcom_scm.h
> @@ -12,6 +12,7 @@
>  #ifndef __QCOM_SCM_INT_H
>  #define __QCOM_SCM_INT_H
>  
> +#if IS_ENABLED(CONFIG_ARM) || IS_ENABLED(CONFIG_ARM64)
>  #define QCOM_SCM_SVC_BOOT0x1
>  #define QCOM_SCM_BOOT_ADDR   0x1
>  #define QCOM_SCM_BOOT_ADDR_MC0x11
> @@ -58,6 +59,66 @@ extern int  __qcom_scm_pas_auth_and_reset(struct device 
> *dev, u32 peripheral);
>  extern int  __qcom_scm_pas_shutdown(struct device *dev, u32 peripheral);
>  extern int  __qcom_scm_pas_mss_reset(struct device *dev, bool reset);
>  
> +#define QCOM_SCM_SVC_MP  0xc
> +#define QCOM_SCM_RESTORE_SEC_CFG 2
> +extern int __qcom_scm_restore_sec_cfg(struct device *dev, u32 device_id,
> +   u32 spare);
> +#define QCOM_SCM_IOMMU_SECURE_PTBL_SIZE  3
> +#define QCOM_SCM_IOMMU_SECURE_PTBL_INIT  4

Don't you need these constants in the COMPILE_TEST case?

> +extern int __qcom_scm_iommu_secure_ptbl_size(struct device *dev, u32 spare,
> +  size_t *size);
> +extern int __qcom_scm_iommu_secure_ptbl_init(struct device *dev, u64 addr,
> +  u32 size, u32 spare);
> +#else
> +static inline int __qcom_scm_set_remote_state(struct device *dev, u32 state,
> +   u32 id)
> +{ return -ENODEV; }

Please space this out over 3 lines with proper indentation.

> +static inline int __qcom_scm_set_warm_boot_addr(struct device *dev, void 
> *entry,
> + const cpumask_t *cpus)
> +{ return -ENODEV; }
> +static inline int __qcom_scm_set_cold_boot_addr(void *entry,
> + const cpumask_t *cpus)
> +{ return -ENODEV; }
> +static inline void __qcom_scm_cpu_power_down(u32 flags) {}
> +static inline int __qcom_scm_is_call_available(struct device *dev, u32 
> svc_id,
> +u32 cmd_id)
> +{ return -ENODEV; }
> +#define QCOM_SCM_SVC_HDCP0x11
> +#define QCOM_SCM_CMD_HDCP0x01
> +static inline int __qcom_scm_hdcp_req(struct device *dev,
> +   struct qcom_scm_hdcp_req *req,
> +   u32 req_cnt, u32 *resp)
> +{ return -ENODEV; }
> +static inline void __qcom_scm_init(void) {}
> +#define QCOM_SCM_SVC_PIL 0x2
> +#define QCOM_SCM_PAS_IS_SUPPORTED_CMD0x7

Do we only need 4 service-related defines in the COMPILE_TEST case?


I don't think we want to duplicate all the defines, so please prepend a
separate patch grouping them at the top.

Regards,
Bjorn

[PATCH v2 2/2] em28xx: add support for new of Terratec H6

[Mauro Carvalho Chehab]

There's a new version of Terratec H6 with uses USB ID
0ccd:10b2. This version is similar to the old one (with is
supported via the HTC entry), except that this one has the
eeprom on the second bus.

On this board, one side of this board is labeled with:
dvbc v2.0
The other side with:
94V-0, MO2, RK-4221 with huge digits: 1107

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/usb/em28xx/em28xx-cards.c | 18 ++
 drivers/media/usb/em28xx/em28xx-dvb.c   |  1 +
 drivers/media/usb/em28xx/em28xx.h   |  1 +
 3 files changed, 20 insertions(+)

diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
b/drivers/media/usb/em28xx/em28xx-cards.c
index a12b599a1fa2..25e952b176ae 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -1193,6 +1193,22 @@ struct em28xx_board em28xx_boards[] = {
.i2c_speed= EM28XX_I2C_CLK_WAIT_ENABLE |
EM28XX_I2C_FREQ_400_KHZ,
},
+   [EM2884_BOARD_TERRATEC_H6] = {
+   .name = "Terratec Cinergy H6 rev. 2",
+   .has_dvb  = 1,
+   .ir_codes = RC_MAP_NEC_TERRATEC_CINERGY_XS,
+#if 0
+   .tuner_type   = TUNER_PHILIPS_TDA8290,
+   .tuner_addr   = 0x41,
+   .dvb_gpio = terratec_h5_digital, /* FIXME: probably wrong */
+   .tuner_gpio   = terratec_h5_gpio,
+#else
+   .tuner_type   = TUNER_ABSENT,
+#endif
+   .def_i2c_bus  = 1,
+   .i2c_speed= EM28XX_I2C_CLK_WAIT_ENABLE |
+   EM28XX_I2C_FREQ_400_KHZ,
+   },
[EM2884_BOARD_HAUPPAUGE_WINTV_HVR_930C] = {
.name = "Hauppauge WinTV HVR 930C",
.has_dvb  = 1,
@@ -2496,6 +2512,8 @@ struct usb_device_id em28xx_id_table[] = {
.driver_info = EM2884_BOARD_TERRATEC_H5 },
{ USB_DEVICE(0x0ccd, 0x10b6),   /* H5 Rev. 3 */
.driver_info = EM2884_BOARD_TERRATEC_H5 },
+   { USB_DEVICE(0x0ccd, 0x10b2),   /* H6 */
+   .driver_info = EM2884_BOARD_TERRATEC_H6 },
{ USB_DEVICE(0x0ccd, 0x0084),
.driver_info = EM2860_BOARD_TERRATEC_AV350 },
{ USB_DEVICE(0x0ccd, 0x0096),
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c 
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 82edd37f0d73..4a7db623fe29 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -1522,6 +1522,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
break;
case EM2884_BOARD_ELGATO_EYETV_HYBRID_2008:
case EM2884_BOARD_CINERGY_HTC_STICK:
+   case EM2884_BOARD_TERRATEC_H6:
terratec_htc_stick_init(dev);
 
/* attach demodulator */
diff --git a/drivers/media/usb/em28xx/em28xx.h 
b/drivers/media/usb/em28xx/em28xx.h
index e8d97d5ec161..88084f24f033 100644
--- a/drivers/media/usb/em28xx/em28xx.h
+++ b/drivers/media/usb/em28xx/em28xx.h
@@ -148,6 +148,7 @@
 #define EM28178_BOARD_PLEX_PX_BCUD98
 #define EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_DVB  99
 #define EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_01595 100
+#define EM2884_BOARD_TERRATEC_H6 101
 
 /* Limits minimum and default number of buffers */
 #define EM28XX_MIN_BUF 4
-- 
2.9.3

[PATCH v2 1/2] em28xx: Ignore errors while reading from eeprom

[Mauro Carvalho Chehab]

On some newer devices (newer Terratec H6 rev. 2), reading
from eeprom fails.

Ignore such errors, as we don't really need it to succeed.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/usb/em28xx/em28xx-i2c.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c 
b/drivers/media/usb/em28xx/em28xx-i2c.c
index 8c472d5adb50..60b195c157b8 100644
--- a/drivers/media/usb/em28xx/em28xx-i2c.c
+++ b/drivers/media/usb/em28xx/em28xx-i2c.c
@@ -982,8 +982,6 @@ int em28xx_i2c_register(struct em28xx *dev, unsigned bus,
dev_err(>intf->dev,
"%s: em28xx_i2_eeprom failed! retval [%d]\n",
__func__, retval);
-
-   return retval;
}
}
 
-- 
2.9.3

Re: [PATCH v8 05/10] media: venus: adding core part and helper functions

[Bjorn Andersson]

On Tue 02 May 01:52 PDT 2017, Stanimir Varbanov wrote:

> Hei Sakari,
> 
> On 04/30/2017 01:21 AM, Sakari Ailus wrote:
> > Hi, Stan!!
> > 
> > On Fri, Apr 28, 2017 at 12:13:52PM +0300, Stanimir Varbanov wrote:
> > ...
> >> +int helper_get_bufreq(struct venus_inst *inst, u32 type,
> >> +struct hfi_buffer_requirements *req)
> >> +{
> >> +  u32 ptype = HFI_PROPERTY_CONFIG_BUFFER_REQUIREMENTS;
> >> +  union hfi_get_property hprop;
> >> +  int ret, i;
> > 
> > unsigned int i ? It's an array index...
> 
> Thanks for pointing that out, I have to revisit all similar places as
> well ...
> 

It's perfectly fine to index an array with an int and you are comparing
the index with a integer constant in the loop - so don't clutter the
code unnecessarily.

Regards,
Bjorn

Re: [PATCH 2/6] rc-core: cleanup rc_register_device

[David Härdeman]

On Mon, May 01, 2017 at 07:47:25PM +0200, David Härdeman wrote:
>On Mon, May 01, 2017 at 05:49:53PM +0100, Sean Young wrote:
>>On Thu, Apr 27, 2017 at 10:34:03PM +0200, David Härdeman wrote:
>>> The device core infrastructure is based on the presumption that
>>> once a driver calls device_add(), it must be ready to accept
>>> userspace interaction.
>>> 
>>> This requires splitting rc_setup_rx_device() into two functions
>>> and reorganizing rc_register_device() so that as much work
>>> as possible is performed before calling device_add().
>>> 
>>
>>With this patch applied, I'm no longer getting any scancodes from
>>my rc devices.
>>
>>David, please can you test your patches before submitting. I have to go
>>over them meticulously because I cannot assume you've tested them.
>
>I did test this patch and I just redid the tests, both with rc-loopback
>and with a mceusb receiver. I'm seeing scancodes on the input device as
>well as pulse-space readings on the lirc device in both tests.
>
>I did the tests with only this patch applied and the lirc-use-after-free
>(v3). What hardware did you test with?
>
>Meanwhile, I'll try rebasing my patches to the latest version of the
>media-master git tree and test again.

I rebased the patches onto media-master (commit
3622d3e77ecef090b5111e3c5423313f11711dfa) and tested again. I still
can't reproduce the problems you're having :/

-- 
David Härdeman

Re: [PATCH 15/16] lirc_dev: remove name from struct lirc_driver

[David Härdeman]

On Tue, May 02, 2017 at 06:04:18PM +0100, Sean Young wrote:
>On Mon, May 01, 2017 at 06:04:52PM +0200, David Härdeman wrote:
>> The name is only used for a few debug messages and the name of the parent
>> device as well as the name of the lirc device (e.g. "lirc0") are sufficient
>> anyway.
>>...
>> @@ -207,8 +204,7 @@ lirc_register_driver(struct lirc_driver *d)
>>  if (err)
>>  goto out_cdev;
>>  
>> -dev_info(ir->d.dev, "lirc_dev: driver %s registered at minor = %d\n",
>> - ir->d.name, ir->d.minor);
>> +dev_info(ir->d.dev, "lirc device registered as lirc%d\n", minor);
>
>I'm not so sure this is a good idea. First of all, the documentation says
>you can use "dmesg |grep lirc_dev" to find your lirc devices and you've
>just replaced lirc_dev with lirc.

Sure, no strong preferences here, you could change the line to say
"lirc_dev device...", or drop the patch.

>https://linuxtv.org/downloads/v4l-dvb-apis/uapi/rc/lirc-dev-intro.html
>
>It's useful having the driver name in the message. For example, I have
>two rc devices connected usually:
>
>[sean@bigcore ~]$ dmesg | grep lirc_dev
>[5.938284] lirc_dev: IR Remote Control driver registered, major 239
>[5.945324] rc rc0: lirc_dev: driver ir-lirc-codec (winbond-cir) registered 
>at minor = 0
>[ 5111.830118] rc rc1: lirc_dev: driver ir-lirc-codec (mceusb) registered at 
>minor = 1

winbond-cirgood man :)

How about "dmesg | grep lirc -A2 -B2"?

I don't think the situation is that different from how you'd know which
input dev is allocated to any given rc_dev? With this patch applied the
relevant output will be:

[0.393494] rc rc0: rc-core loopback device as /devices/virtual/rc/rc0
[0.394458] input: rc-core loopback device as /devices/virtual/rc/rc0/input2
[0.395717] rc rc0: lirc device registered as lirc0
[   12.612313] rc rc1: mceusb device as /devices/virtual/rc/rc1
[   12.612768] input: mceusb device as /devices/virtual/rc/rc1/input4
[   12.613112] rc rc1: lirc device registered as lirc1

(and we might want to change the lirc line to include the sysfs path?)

But realistically, how much dmesg grepping are we expecting normal
end-users to be doing?

Anyway, as I said, this patch isn't crucial, and we can revisit printk's
later (I'm looking at the ioctl locking right now and I think an
ir-lirc-codec and lirc_dev merger might be a good idea once the fate of
lirc_zilog has been decided).

>With the driver name I know which one is which.
>
>Maybe lirc_driver.name should be a "const char*" so no strcpy is needed
>(the ir-lirc-codec does not seem necessary).

Not that it really pertains to whether d->name should be kept or not,
but I think that lirc_dev shouldn't copy the lirc_driver struct into an
irctl struct internal copy at all, but just keep a normal pointer. I
haven't gotten around to vetting the (ab)use of the lirc_driver struct
yet though.

Regards,
David

Re: [PATCH 2/2] [media] platform: add video-multiplexer subdevice driver

[Peter Rosin]

On 2017-05-02 17:21, Philipp Zabel wrote:
> On Sat, 2017-04-29 at 23:42 +0200, Peter Rosin wrote:
>> On 2017-04-29 23:29, Peter Rosin wrote:
>>> On 2017-04-28 16:13, Philipp Zabel wrote:
 This driver can handle SoC internal and external video bus multiplexers,
 controlled by mux controllers provided by the mux controller framework,
 such as MMIO register bitfields or GPIOs. The subdevice passes through
 the mbus configuration of the active input to the output side.

 Signed-off-by: Sascha Hauer 
 Signed-off-by: Philipp Zabel 
 Signed-off-by: Steve Longerbeam 
 ---
 This has been last sent as part of the i.MX media series.

 Changes since https://patchwork.kernel.org/patch/9647869/:
  - Split out the actual mux operation to be provided by the mux controller
framework [1]. GPIO and MMIO control can be provided by individual mux
controller drivers [2][3].
[1] https://patchwork.kernel.org/patch/9695837/
[2] https://patchwork.kernel.org/patch/9695839/
[3] https://patchwork.kernel.org/patch/9704509/
  - Shortened 'video-multiplexer' to 'video-mux', replaced all instances of
vidsw with video_mux.
  - Made the mux inactive by default, only activated by user interaction.
  - Added CONFIG_OF and CONFIG_MULTIPLEXER dependencies.
  - Reuse subdev.entity.num_pads instead of keeping our own count.
  - Removed implicit link disabling. Instead, trying to enable a second
sink pad link yields -EBUSY.
  - Merged _async_init into _probe.
  - Removed superfluous pad index check from _set_format.
  - Added is_source_pad helper to tell source and sink pads apart.
  - Removed test for status property in endpoint nodes. Disable the remote
device or sever the endpoint link to disable a sink pad.
 ---
  drivers/media/platform/Kconfig |   6 +
  drivers/media/platform/Makefile|   2 +
  drivers/media/platform/video-mux.c | 341 
 +
  3 files changed, 349 insertions(+)
  create mode 100644 drivers/media/platform/video-mux.c

 diff --git a/drivers/media/platform/Kconfig 
 b/drivers/media/platform/Kconfig
 index c9106e105baba..b046a6d39fee5 100644
 --- a/drivers/media/platform/Kconfig
 +++ b/drivers/media/platform/Kconfig
 @@ -74,6 +74,12 @@ config VIDEO_M32R_AR_M64278
  To compile this driver as a module, choose M here: the
  module will be called arv.
  
 +config VIDEO_MUX
 +  tristate "Video Multiplexer"
 +  depends on OF && VIDEO_V4L2_SUBDEV_API && MEDIA_CONTROLLER && 
 MULTIPLEXER
 +  help
 +This driver provides support for N:1 video bus multiplexers.
 +
  config VIDEO_OMAP3
tristate "OMAP 3 Camera support"
depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3
 diff --git a/drivers/media/platform/Makefile 
 b/drivers/media/platform/Makefile
 index 349ddf6a69da2..fd2735ca3ff75 100644
 --- a/drivers/media/platform/Makefile
 +++ b/drivers/media/platform/Makefile
 @@ -27,6 +27,8 @@ obj-$(CONFIG_VIDEO_SH_VEU)   += sh_veu.o
  
  obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)   += m2m-deinterlace.o
  
 +obj-$(CONFIG_VIDEO_MUX)   += video-mux.o
 +
  obj-$(CONFIG_VIDEO_S3C_CAMIF) += s3c-camif/
  obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS)+= exynos4-is/
  obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG)  += s5p-jpeg/
 diff --git a/drivers/media/platform/video-mux.c 
 b/drivers/media/platform/video-mux.c
 new file mode 100644
 index 0..419541729f67e
 --- /dev/null
 +++ b/drivers/media/platform/video-mux.c
 @@ -0,0 +1,341 @@
 +/*
 + * video stream multiplexer controlled via mux control
 + *
 + * Copyright (C) 2013 Pengutronix, Sascha Hauer 
 + * Copyright (C) 2016 Pengutronix, Philipp Zabel 
>>>
>>> 2017?
>>>
 + *
 + * This program is free software; you can redistribute it and/or
 + * modify it under the terms of the GNU General Public License
 + * as published by the Free Software Foundation; either version 2
 + * of the License, or (at your option) any later version.
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + */
 +
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +
 +struct video_mux {
 +  struct v4l2_subdev subdev;
 +  struct media_pad *pads;
 +  struct 

Re: [PATCH 15/16] lirc_dev: remove name from struct lirc_driver

[Sean Young]

On Mon, May 01, 2017 at 06:04:52PM +0200, David Härdeman wrote:
> The name is only used for a few debug messages and the name of the parent
> device as well as the name of the lirc device (e.g. "lirc0") are sufficient
> anyway.
> 
> Signed-off-by: David Härdeman 
> ---
>  drivers/media/rc/ir-lirc-codec.c|2 --
>  drivers/media/rc/lirc_dev.c |   25 -
>  drivers/staging/media/lirc/lirc_zilog.c |1 -
>  include/media/lirc_dev.h|3 ---
>  4 files changed, 8 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/media/rc/ir-lirc-codec.c 
> b/drivers/media/rc/ir-lirc-codec.c
> index 2c1221a61ea1..74ce27f92901 100644
> --- a/drivers/media/rc/ir-lirc-codec.c
> +++ b/drivers/media/rc/ir-lirc-codec.c
> @@ -380,8 +380,6 @@ static int ir_lirc_register(struct rc_dev *dev)
>   if (dev->max_timeout)
>   features |= LIRC_CAN_SET_REC_TIMEOUT;
>  
> - snprintf(drv->name, sizeof(drv->name), "ir-lirc-codec (%s)",
> -  dev->driver_name);
>   drv->features = features;
>   drv->data = >raw->lirc;
>   drv->rbuf = NULL;
> diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
> index 4ba6c7e2d41b..10783ef75a25 100644
> --- a/drivers/media/rc/lirc_dev.c
> +++ b/drivers/media/rc/lirc_dev.c
> @@ -28,8 +28,6 @@
>  #include 
>  #include 
>  
> -#define LOGHEAD  "lirc_dev (%s[%d]): "
> -
>  static dev_t lirc_base_dev;
>  
>  /**
> @@ -160,7 +158,6 @@ lirc_register_driver(struct lirc_driver *d)
>   return -EBADRQC;
>   }
>  
> - d->name[sizeof(d->name)-1] = '\0';
>   if (d->features == 0)
>   d->features = LIRC_CAN_REC_LIRCCODE;
>  
> @@ -207,8 +204,7 @@ lirc_register_driver(struct lirc_driver *d)
>   if (err)
>   goto out_cdev;
>  
> - dev_info(ir->d.dev, "lirc_dev: driver %s registered at minor = %d\n",
> -  ir->d.name, ir->d.minor);
> + dev_info(ir->d.dev, "lirc device registered as lirc%d\n", minor);

I'm not so sure this is a good idea. First of all, the documentation says
you can use "dmesg |grep lirc_dev" to find your lirc devices and you've
just replaced lirc_dev with lirc.

https://linuxtv.org/downloads/v4l-dvb-apis/uapi/rc/lirc-dev-intro.html

It's useful having the driver name in the message. For example, I have
two rc devices connected usually:

[sean@bigcore ~]$ dmesg | grep lirc_dev
[5.938284] lirc_dev: IR Remote Control driver registered, major 239
[5.945324] rc rc0: lirc_dev: driver ir-lirc-codec (winbond-cir) registered 
at minor = 0
[ 5111.830118] rc rc1: lirc_dev: driver ir-lirc-codec (mceusb) registered at 
minor = 1

With the driver name I know which one is which.

Maybe lirc_driver.name should be a "const char*" so no strcpy is needed
(the ir-lirc-codec does not seem necessary).

Thanks

Sean

>  
>   d->lirc_internal = ir;
>   return 0;
> @@ -242,13 +238,11 @@ lirc_unregister_driver(struct lirc_driver *d)
>  
>   mutex_lock(>mutex);
>  
> - dev_dbg(ir->d.dev, "lirc_dev: driver %s unregistered from minor = %d\n",
> - ir->d.name, ir->d.minor);
> + dev_dbg(>dev, "unregistered\n");
>  
>   ir->dead = true;
>   if (ir->users) {
> - dev_dbg(ir->d.dev, LOGHEAD "releasing opened driver\n",
> - ir->d.name, ir->d.minor);
> + dev_dbg(>dev, "releasing opened driver\n");
>   wake_up_interruptible(>buf->wait_poll);
>   }
>  
> @@ -278,7 +272,7 @@ int lirc_dev_fop_open(struct inode *inode, struct file 
> *file)
>  
>   mutex_unlock(>mutex);
>  
> - dev_dbg(ir->d.dev, LOGHEAD "open called\n", ir->d.name, ir->d.minor);
> + dev_dbg(>dev, "open called\n");
>  
>   if (ir->d.rdev) {
>   retval = rc_open(ir->d.rdev);
> @@ -332,8 +326,7 @@ unsigned int lirc_dev_fop_poll(struct file *file, 
> poll_table *wait)
>   else
>   ret = POLLIN | POLLRDNORM;
>  
> - dev_dbg(ir->d.dev, LOGHEAD "poll result = %d\n",
> - ir->d.name, ir->d.minor, ret);
> + dev_dbg(>dev, "poll result = %d\n", ret);
>  
>   return ret;
>  }
> @@ -345,12 +338,10 @@ long lirc_dev_fop_ioctl(struct file *file, unsigned int 
> cmd, unsigned long arg)
>   __u32 mode;
>   int result = 0;
>  
> - dev_dbg(ir->d.dev, LOGHEAD "ioctl called (0x%x)\n",
> - ir->d.name, ir->d.minor, cmd);
> + dev_dbg(>dev, "ioctl called (0x%x)\n", cmd);
>  
>   if (ir->dead) {
> - dev_err(ir->d.dev, LOGHEAD "ioctl result = -ENODEV\n",
> - ir->d.name, ir->d.minor);
> + dev_err(>dev, "ioctl result = -ENODEV\n");
>   return -ENODEV;
>   }
>  
> @@ -428,7 +419,7 @@ ssize_t lirc_dev_fop_read(struct file *file,
>   if (!LIRC_CAN_REC(ir->d.features))
>   return -EINVAL;
>  
> - dev_dbg(ir->d.dev, LOGHEAD "read called\n", ir->d.name, ir->d.minor);
> + dev_dbg(>dev, "read called\n");
>  
>

Re: [PATCH 1/2] em28xx: allow setting the eeprom bus at cards struct

[Frank Schäfer]

Am 01.05.2017 um 19:54 schrieb Mauro Carvalho Chehab:
> Hi Frank,
>
> Em Mon, 1 May 2017 16:11:51 +0200
> Frank Schäfer  escreveu:
>
>> Am 01.05.2017 um 13:38 schrieb Mauro Carvalho Chehab:
>>> Right now, all devices use bus 0 for eeprom. However, newer
>>> versions of Terratec H6 use a different buffer for eeprom.
>>>
>>> So, add support to use a different I2C address for eeprom.  
>> Has this been tested ?
>> Did you read my reply to the previous patch version ?:
>> See http://www.spinics.net/lists/linux-media/msg114860.html
>>
>> I doubt it will work. At least not for the device from the thread in the
>> Kodi-forum.
> Yes. Someone at IRC were complaining about this device (his nick is
> buxy81). 
Ahh, you are in contact with him ? That's good.

> According with the tests he did, with both patches his
> device is now working.
I guess it works because (due to the first patch) no eeprom is detected
anymore.
In this case the driver prints a "board has no eeprom" message to the
log and continues.

> That's said, it would be great if he could provide us more details
> about the tests he did, with the logs enabled, in order for us to see
> if the eeprom contents is properly read.
Yes, further tests/details are required.
Can you ask him to join the list ?

Regards,
Frank



>
>
> Thanks,
> Mauro

[PATCH] v4l2-async: add v4l2_async_match()

[Niklas Söderlund]

For drivers registering notifiers with more then one subdevices it's
difficult to know exactly which one is being bound in each call to the
notifiers bound callback. Comparing OF nodes became harder after the
introduction of fwnode where the two following comparisons are not equal
but where so previous to fwnode.

asd.match.fwnode.fwnode == of_fwnode_handle(subdev->dev->of_node)

asd.match.fwnode.fwnode == of_fwnode_handle(subdev->of_node)

It's also not ideal to directly access the asd.match union without first
checking the match_type. So to make it easier for drivers to perform
this type of matching export the v4l2 async match helpers with a new
symbol v4l2_async_match(). This wold replace the comparisons above with:

v4l2_async_match(subdev, )

Suggested-by: Kieran Bingham 
Signed-off-by: Niklas Söderlund 
---
 drivers/media/v4l2-core/v4l2-async.c | 52 +---
 include/media/v4l2-async.h   | 11 
 2 files changed, 41 insertions(+), 22 deletions(-)

Depends on '[PATCH v3 0/7] V4L2 fwnode support' and tested on Renesas 
R-Car H3 and M3-W together with rcar-vin Gen3 patches.

diff --git a/drivers/media/v4l2-core/v4l2-async.c 
b/drivers/media/v4l2-core/v4l2-async.c
index cbd919d4edd27e17..c291ffda4d18202b 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -60,6 +60,35 @@ static bool match_custom(struct v4l2_subdev *sd, struct 
v4l2_async_subdev *asd)
return asd->match.custom.match(sd->dev, asd);
 }
 
+bool v4l2_async_match(struct v4l2_subdev *sd,
+ struct v4l2_async_subdev *asd)
+{
+   bool (*match)(struct v4l2_subdev *, struct v4l2_async_subdev *);
+
+   switch (asd->match_type) {
+   case V4L2_ASYNC_MATCH_CUSTOM:
+   match = match_custom;
+   break;
+   case V4L2_ASYNC_MATCH_DEVNAME:
+   match = match_devname;
+   break;
+   case V4L2_ASYNC_MATCH_I2C:
+   match = match_i2c;
+   break;
+   case V4L2_ASYNC_MATCH_FWNODE:
+   match = match_fwnode;
+   break;
+   default:
+   /* Cannot happen, unless someone breaks us */
+   WARN_ON(true);
+   return false;
+   }
+
+   /* match cannot be NULL here */
+   return match(sd, asd);
+}
+EXPORT_SYMBOL(v4l2_async_match);
+
 static LIST_HEAD(subdev_list);
 static LIST_HEAD(notifier_list);
 static DEFINE_MUTEX(list_lock);
@@ -67,32 +96,11 @@ static DEFINE_MUTEX(list_lock);
 static struct v4l2_async_subdev *v4l2_async_belongs(struct v4l2_async_notifier 
*notifier,
struct v4l2_subdev *sd)
 {
-   bool (*match)(struct v4l2_subdev *, struct v4l2_async_subdev *);
struct v4l2_async_subdev *asd;
 
list_for_each_entry(asd, >waiting, list) {
/* bus_type has been verified valid before */
-   switch (asd->match_type) {
-   case V4L2_ASYNC_MATCH_CUSTOM:
-   match = match_custom;
-   break;
-   case V4L2_ASYNC_MATCH_DEVNAME:
-   match = match_devname;
-   break;
-   case V4L2_ASYNC_MATCH_I2C:
-   match = match_i2c;
-   break;
-   case V4L2_ASYNC_MATCH_FWNODE:
-   match = match_fwnode;
-   break;
-   default:
-   /* Cannot happen, unless someone breaks us */
-   WARN_ON(true);
-   return NULL;
-   }
-
-   /* match cannot be NULL here */
-   if (match(sd, asd))
+   if (v4l2_async_match(sd, asd))
return asd;
}
 
diff --git a/include/media/v4l2-async.h b/include/media/v4l2-async.h
index c69d8c8a66d0093a..45677387282919d7 100644
--- a/include/media/v4l2-async.h
+++ b/include/media/v4l2-async.h
@@ -135,4 +135,15 @@ int v4l2_async_register_subdev(struct v4l2_subdev *sd);
  * @sd: pointer to  v4l2_subdev
  */
 void v4l2_async_unregister_subdev(struct v4l2_subdev *sd);
+
+/**
+ * v4l2_async_match - match a subdevice with a asynchronous subdevice 
descriptor
+ *
+ * @sd: pointer to  v4l2_subdev
+ * @asd: pointer to  v4l2_async_subdev
+ *
+ * Return: true if @asd matches @sd else false
+ */
+bool v4l2_async_match(struct v4l2_subdev *sd,
+ struct v4l2_async_subdev *asd);
 #endif
-- 
2.12.2

Re: [PATCH v4 2/7] dt-bindings: media: Add MAX2175 binding description

[Geert Uytterhoeven]

Hi Ramesh,

On Tue, May 2, 2017 at 3:26 PM, Ramesh Shanmugasundaram
 wrote:
> --- a/Documentation/devicetree/bindings/property-units.txt
> +++ b/Documentation/devicetree/bindings/property-units.txt
> @@ -28,6 +28,7 @@ Electricity
>  -ohms  : Ohms
>  -micro-ohms: micro Ohms
>  -microvolt : micro volts
> +-pF: pico farads

All electrical units seem to use long(er) names.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 2/2] [media] platform: add video-multiplexer subdevice driver

[Philipp Zabel]

On Sat, 2017-04-29 at 23:42 +0200, Peter Rosin wrote:
> On 2017-04-29 23:29, Peter Rosin wrote:
> > On 2017-04-28 16:13, Philipp Zabel wrote:
> >> This driver can handle SoC internal and external video bus multiplexers,
> >> controlled by mux controllers provided by the mux controller framework,
> >> such as MMIO register bitfields or GPIOs. The subdevice passes through
> >> the mbus configuration of the active input to the output side.
> >>
> >> Signed-off-by: Sascha Hauer 
> >> Signed-off-by: Philipp Zabel 
> >> Signed-off-by: Steve Longerbeam 
> >> ---
> >> This has been last sent as part of the i.MX media series.
> >>
> >> Changes since https://patchwork.kernel.org/patch/9647869/:
> >>  - Split out the actual mux operation to be provided by the mux controller
> >>framework [1]. GPIO and MMIO control can be provided by individual mux
> >>controller drivers [2][3].
> >>[1] https://patchwork.kernel.org/patch/9695837/
> >>[2] https://patchwork.kernel.org/patch/9695839/
> >>[3] https://patchwork.kernel.org/patch/9704509/
> >>  - Shortened 'video-multiplexer' to 'video-mux', replaced all instances of
> >>vidsw with video_mux.
> >>  - Made the mux inactive by default, only activated by user interaction.
> >>  - Added CONFIG_OF and CONFIG_MULTIPLEXER dependencies.
> >>  - Reuse subdev.entity.num_pads instead of keeping our own count.
> >>  - Removed implicit link disabling. Instead, trying to enable a second
> >>sink pad link yields -EBUSY.
> >>  - Merged _async_init into _probe.
> >>  - Removed superfluous pad index check from _set_format.
> >>  - Added is_source_pad helper to tell source and sink pads apart.
> >>  - Removed test for status property in endpoint nodes. Disable the remote
> >>device or sever the endpoint link to disable a sink pad.
> >> ---
> >>  drivers/media/platform/Kconfig |   6 +
> >>  drivers/media/platform/Makefile|   2 +
> >>  drivers/media/platform/video-mux.c | 341 
> >> +
> >>  3 files changed, 349 insertions(+)
> >>  create mode 100644 drivers/media/platform/video-mux.c
> >>
> >> diff --git a/drivers/media/platform/Kconfig 
> >> b/drivers/media/platform/Kconfig
> >> index c9106e105baba..b046a6d39fee5 100644
> >> --- a/drivers/media/platform/Kconfig
> >> +++ b/drivers/media/platform/Kconfig
> >> @@ -74,6 +74,12 @@ config VIDEO_M32R_AR_M64278
> >>  To compile this driver as a module, choose M here: the
> >>  module will be called arv.
> >>  
> >> +config VIDEO_MUX
> >> +  tristate "Video Multiplexer"
> >> +  depends on OF && VIDEO_V4L2_SUBDEV_API && MEDIA_CONTROLLER && 
> >> MULTIPLEXER
> >> +  help
> >> +This driver provides support for N:1 video bus multiplexers.
> >> +
> >>  config VIDEO_OMAP3
> >>tristate "OMAP 3 Camera support"
> >>depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3
> >> diff --git a/drivers/media/platform/Makefile 
> >> b/drivers/media/platform/Makefile
> >> index 349ddf6a69da2..fd2735ca3ff75 100644
> >> --- a/drivers/media/platform/Makefile
> >> +++ b/drivers/media/platform/Makefile
> >> @@ -27,6 +27,8 @@ obj-$(CONFIG_VIDEO_SH_VEU)   += sh_veu.o
> >>  
> >>  obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)   += m2m-deinterlace.o
> >>  
> >> +obj-$(CONFIG_VIDEO_MUX)   += video-mux.o
> >> +
> >>  obj-$(CONFIG_VIDEO_S3C_CAMIF) += s3c-camif/
> >>  obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS)+= exynos4-is/
> >>  obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG)  += s5p-jpeg/
> >> diff --git a/drivers/media/platform/video-mux.c 
> >> b/drivers/media/platform/video-mux.c
> >> new file mode 100644
> >> index 0..419541729f67e
> >> --- /dev/null
> >> +++ b/drivers/media/platform/video-mux.c
> >> @@ -0,0 +1,341 @@
> >> +/*
> >> + * video stream multiplexer controlled via mux control
> >> + *
> >> + * Copyright (C) 2013 Pengutronix, Sascha Hauer 
> >> + * Copyright (C) 2016 Pengutronix, Philipp Zabel 
> > 
> > 2017?
> > 
> >> + *
> >> + * This program is free software; you can redistribute it and/or
> >> + * modify it under the terms of the GNU General Public License
> >> + * as published by the Free Software Foundation; either version 2
> >> + * of the License, or (at your option) any later version.
> >> + * This program is distributed in the hope that it will be useful,
> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> >> + * GNU General Public License for more details.
> >> + */
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +struct video_mux {
> >> +  struct v4l2_subdev subdev;
> >> +  struct media_pad *pads;
> >> +  struct v4l2_mbus_framefmt *format_mbus;
> >> +  struct 

[PATCH v2 2/2] [media] platform: add video-multiplexer subdevice driver

[Philipp Zabel]

This driver can handle SoC internal and external video bus multiplexers,
controlled by mux controllers provided by the mux controller framework,
such as MMIO register bitfields or GPIOs. The subdevice passes through
the mbus configuration of the active input to the output side.

Signed-off-by: Sascha Hauer 
Signed-off-by: Philipp Zabel 
Signed-off-by: Steve Longerbeam 
---
Changes since v1 [1]:
 - Protect vmux->active with a mutex in link_setup and set_format.
   s_stream does not need to be locked; it is called when the pipeline
   is started and thus the link setup can not be changed anymore.
 - Remove the unused g_mbus_config.

This was previously sent as part of Steve's i.MX media series [2].

[1] https://patchwork.kernel.org/patch/9704791/
[2] https://patchwork.kernel.org/patch/9647869/
---
 drivers/media/platform/Kconfig |   6 +
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/video-mux.c | 312 +
 3 files changed, 320 insertions(+)
 create mode 100644 drivers/media/platform/video-mux.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index c9106e105baba..b046a6d39fee5 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -74,6 +74,12 @@ config VIDEO_M32R_AR_M64278
  To compile this driver as a module, choose M here: the
  module will be called arv.
 
+config VIDEO_MUX
+   tristate "Video Multiplexer"
+   depends on OF && VIDEO_V4L2_SUBDEV_API && MEDIA_CONTROLLER && 
MULTIPLEXER
+   help
+ This driver provides support for N:1 video bus multiplexers.
+
 config VIDEO_OMAP3
tristate "OMAP 3 Camera support"
depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 349ddf6a69da2..fd2735ca3ff75 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -27,6 +27,8 @@ obj-$(CONFIG_VIDEO_SH_VEU)+= sh_veu.o
 
 obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)+= m2m-deinterlace.o
 
+obj-$(CONFIG_VIDEO_MUX)+= video-mux.o
+
 obj-$(CONFIG_VIDEO_S3C_CAMIF)  += s3c-camif/
 obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS) += exynos4-is/
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG)   += s5p-jpeg/
diff --git a/drivers/media/platform/video-mux.c 
b/drivers/media/platform/video-mux.c
new file mode 100644
index 0..a857f5e89deff
--- /dev/null
+++ b/drivers/media/platform/video-mux.c
@@ -0,0 +1,312 @@
+/*
+ * video stream multiplexer controlled via mux control
+ *
+ * Copyright (C) 2013 Pengutronix, Sascha Hauer 
+ * Copyright (C) 2016-2017 Pengutronix, Philipp Zabel 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct video_mux {
+   struct v4l2_subdev subdev;
+   struct media_pad *pads;
+   struct v4l2_mbus_framefmt *format_mbus;
+   struct v4l2_of_endpoint *endpoint;
+   struct mux_control *mux;
+   struct mutex lock;
+   int active;
+};
+
+static inline struct video_mux *v4l2_subdev_to_video_mux(struct v4l2_subdev 
*sd)
+{
+   return container_of(sd, struct video_mux, subdev);
+}
+
+static inline bool is_source_pad(struct video_mux *vmux, unsigned int pad)
+{
+   return pad == vmux->subdev.entity.num_pads - 1;
+}
+
+static int video_mux_link_setup(struct media_entity *entity,
+   const struct media_pad *local,
+   const struct media_pad *remote, u32 flags)
+{
+   struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
+   struct video_mux *vmux = v4l2_subdev_to_video_mux(sd);
+   int ret = 0;
+
+   /*
+* The mux state is determined by the enabled sink pad link.
+* Enabling or disabling the source pad link has no effect.
+*/
+   if (is_source_pad(vmux, local->index))
+   return 0;
+
+   dev_dbg(sd->dev, "link setup '%s':%d->'%s':%d[%d]",
+   remote->entity->name, remote->index, local->entity->name,
+   local->index, flags & MEDIA_LNK_FL_ENABLED);
+
+   mutex_lock(>lock);
+
+   if (flags & MEDIA_LNK_FL_ENABLED) {
+   if (vmux->active == local->index)
+   goto out;
+
+ 

[PATCH v2 1/2] [media] dt-bindings: Add bindings for video-multiplexer device

[Philipp Zabel]

Add bindings documentation for the video multiplexer device.

Signed-off-by: Sascha Hauer 
Signed-off-by: Philipp Zabel 
Signed-off-by: Steve Longerbeam 
Acked-by: Peter Rosin 
---
No changes since v1 [1].

This was previously sent as part of Steve's i.MX media series [2].

[1] https://patchwork.kernel.org/patch/9704789/
[2] https://patchwork.kernel.org/patch/9647951/
---
 .../devicetree/bindings/media/video-mux.txt| 60 ++
 1 file changed, 60 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/video-mux.txt

diff --git a/Documentation/devicetree/bindings/media/video-mux.txt 
b/Documentation/devicetree/bindings/media/video-mux.txt
new file mode 100644
index 0..63b9dc913e456
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/video-mux.txt
@@ -0,0 +1,60 @@
+Video Multiplexer
+=
+
+Video multiplexers allow to select between multiple input ports. Video received
+on the active input port is passed through to the output port. Muxes described
+by this binding are controlled by a multiplexer controller that is described by
+the bindings in Documentation/devicetree/bindings/mux/mux-controller.txt
+
+Required properties:
+- compatible : should be "video-mux"
+- mux-controls : mux controller node to use for operating the mux
+- #address-cells: should be <1>
+- #size-cells: should be <0>
+- port@*: at least three port nodes containing endpoints connecting to the
+  source and sink devices according to of_graph bindings. The last port is
+  the output port, all others are inputs.
+
+Optionally, #address-cells, #size-cells, and port nodes can be grouped under a
+ports node as described in Documentation/devicetree/bindings/graph.txt.
+
+Example:
+
+   mux: mux-controller {
+   compatible = "gpio-mux";
+   #mux-control-cells = <0>;
+
+   mux-gpios = < 15 GPIO_ACTIVE_HIGH>;
+   };
+
+   video-mux {
+   compatible = "video-mux";
+   mux-controls = <>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   mux_in0: endpoint {
+   remote-endpoint = <_source0_out>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   mux_in1: endpoint {
+   remote-endpoint = <_source1_out>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+
+   mux_out: endpoint {
+   remote-endpoint = <_interface_in>;
+   };
+   };
+   };
+};
-- 
2.11.0

Re: [RFC] [PATCH 0/4] [media] pxa_camera: Fixing bugs and missing colorformats

[Robert Jarzmik]

Petr Cvek  writes:

> Dne 1.5.2017 v 06:20 Petr Cvek napsal(a):
>> This patchset is just a grouping of a few bugfixes I've found during
>> the ov9640 sensor support re-adding. 
>
> P.S. I've manually calculated every format variant for the image size
> calculation functions, but still these functions are not too robust (for every
> hypothetical bps/packing/layout combination). For example:
>
> MEDIA_BUS_FMT_Y8_1X8
>   .name   = "Grey",
>   .bits_per_sample= 8,
>   .packing= PXA_MBUS_PACKING_NONE,
>   .order  = PXA_MBUS_ORDER_LE,
>   .layout = PXA_MBUS_LAYOUT_PACKED,
>
> seems to me as a little bit misleading. The better solution would be to have 
> something like bytes_per_line and image_size coefficients. Is my idea worth a 
> try?
>
> Anyway the .order field seems to be unused (it is a pxa_camera defined 
> structure). I'm for removing it (I can create a patch and test it on the real 
> hardware). Unless there are plans for it.
>
> The pxa_camera_get_formats() could be probably simplified even up to the point
> of a removal of the soc_camera_format_xlate structure. If no one works on it 
> (in
> like 2 months) I can try to simplify it.

Yes, simplifing get soc_camera_format_xlate struct would be great. And yeah,
nobody will be working on it in the next 2 monthes. Besides, Hans had expressed
interest in having it removed.

On my side, as long as the format translation happens, ie. pxa_camera provides a
list of formats which is a _superset_ of the sensor formats as today (especially
YUV422P, YUYV and its permutations, RGB), I'll be totally fine with it, even
if it was my idea several years ago to have a translation...

Let's see what new ideas can provide, new blood etc ...

Cheers.

-- 
Robert

Re: [PATCH 4/4] [media] pxa_camera: Fix a call with an uninitialized device pointer

[Robert Jarzmik]

Petr Cvek  writes:

> In 'commit 295ab497d6357 ("[media] media: platform: pxa_camera: make
> printk consistent")' a pointer to the device structure in
> mclk_get_divisor() was changed to pcdev_to_dev(pcdev). The pointer used
> by pcdev_to_dev() is still uninitialized during the call to
> mclk_get_divisor() as it happens in v4l2_device_register() at the end
> of the probe. The dev_warn and dev_dbg caused a line in the log:
>
>   (NULL device *): Limiting master clock to 2600
>
> Fix this by using an initialized pointer from the platform_device
> (as before the old patch).
>
> Signed-off-by: Petr Cvek 
Right, would be good to add to the commit message :
Fixes: 295ab497d635 ("[media] media: platform: pxa_camera: make printk 
consistent")

And :
Acked-by: Robert Jarzmik 

Cheers.

--
Robert

> ---
>  drivers/media/platform/pxa_camera.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/pxa_camera.c 
> b/drivers/media/platform/pxa_camera.c
> index 79fd7269d1e6..c8466c63be22 100644
> --- a/drivers/media/platform/pxa_camera.c
> +++ b/drivers/media/platform/pxa_camera.c
> @@ -1124,7 +1124,7 @@ static u32 mclk_get_divisor(struct platform_device 
> *pdev,
>   /* mclk <= ciclk / 4 (27.4.2) */
>   if (mclk > lcdclk / 4) {
>   mclk = lcdclk / 4;
> - dev_warn(pcdev_to_dev(pcdev),
> + dev_warn(>dev,
>"Limiting master clock to %lu\n", mclk);
>   }
>  
> @@ -1135,7 +1135,7 @@ static u32 mclk_get_divisor(struct platform_device 
> *pdev,
>   if (pcdev->platform_flags & PXA_CAMERA_MCLK_EN)
>   pcdev->mclk = lcdclk / (2 * (div + 1));
>  
> - dev_dbg(pcdev_to_dev(pcdev), "LCD clock %luHz, target freq %luHz, 
> divisor %u\n",
> + dev_dbg(>dev, "LCD clock %luHz, target freq %luHz, divisor %u\n",
>   lcdclk, mclk, div);
>  
>   return div;

Re: [PATCH 3/4] [media] pxa_camera: Add (un)subscribe_event ioctl

[Robert Jarzmik]

Petr Cvek  writes:

> The v4l2-compliance complains about nonexistent vidioc_subscribe_event
> and vidioc_unsubscribe_event calls. Add them to fix the complaints.
>
> Signed-off-by: Petr Cvek 
Don't know on that one, let others on the mailing list comment, I'm not familiar
with the event interface of v4l2.

Cheers.

--
Robert

> ---
>  drivers/media/platform/pxa_camera.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/media/platform/pxa_camera.c 
> b/drivers/media/platform/pxa_camera.c
> index f71e7e0a652b..79fd7269d1e6 100644
> --- a/drivers/media/platform/pxa_camera.c
> +++ b/drivers/media/platform/pxa_camera.c
> @@ -37,7 +37,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -2089,6 +2091,8 @@ static const struct v4l2_ioctl_ops pxa_camera_ioctl_ops 
> = {
>   .vidioc_g_register  = pxac_vidioc_g_register,
>   .vidioc_s_register  = pxac_vidioc_s_register,
>  #endif
> + .vidioc_subscribe_event = v4l2_ctrl_subscribe_event,
> + .vidioc_unsubscribe_event   = v4l2_event_unsubscribe,
>  };
>  
>  static struct v4l2_clk_ops pxa_camera_mclk_ops = {

Re: [PATCH 2/4] [media] pxa_camera: Fix incorrect test in the image size generation

[Robert Jarzmik]

Petr Cvek  writes:

> During the transfer from the soc_camera a test in pxa_mbus_image_size()
> got removed. Without it any PXA_MBUS_LAYOUT_PACKED format causes either
> the return of a wrong value (PXA_MBUS_PACKING_2X8_PADHI doubles
> the correct value) or EINVAL (PXA_MBUS_PACKING_NONE and
> PXA_MBUS_PACKING_EXTEND16). This was observed in an error from the ffmpeg
> (for some of the YUYV subvariants).
>
> This patch re-adds the same test as in soc_camera version.
>
> Signed-off-by: Petr Cvek 
Did you test that with YUV422P format ?
If yes, then you can have my ack.

And you should add Hans to the reviewers list, it's his call ultimately, and his
tree which should carry it on.

Cheers.

--
Robert

Re: [PATCH 1/4] [media] pxa_camera: Add remaining Bayer 8 formats

[Robert Jarzmik]

Petr Cvek  writes:

> This patch adds Bayer 8 GBRG and RGGB support and move GRBG definition
> close to BGGR (so all Bayer 8 variants are together). No other changes are
> needed as the driver handles them as RAW data stream.
>
> The RGGB variant was tested in a modified OV9640 driver.
>
> Signed-off-by: Petr Cvek 
Acked-by: Robert Jarzmik 

Cheers.

--
Robert

[PATCH v4 5/7] doc_rst: media: New SDR formats PC16, PC18 & PC20

[Ramesh Shanmugasundaram]

This patch adds documentation for the three new SDR formats

V4L2_SDR_FMT_PCU16BE
V4L2_SDR_FMT_PCU18BE
V4L2_SDR_FMT_PCU20BE

Signed-off-by: Ramesh Shanmugasundaram 
---
 .../media/uapi/v4l/pixfmt-sdr-pcu16be.rst  | 55 ++
 .../media/uapi/v4l/pixfmt-sdr-pcu18be.rst  | 55 ++
 .../media/uapi/v4l/pixfmt-sdr-pcu20be.rst  | 54 +
 Documentation/media/uapi/v4l/sdr-formats.rst   |  3 ++
 4 files changed, 167 insertions(+)
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst

diff --git a/Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst 
b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst
new file mode 100644
index ..2de1b1a0f517
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst
@@ -0,0 +1,55 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-SDR-FMT-PCU16BE:
+
+**
+V4L2_SDR_FMT_PCU16BE ('PC16')
+**
+
+Planar complex unsigned 16-bit big endian IQ sample
+
+Description
+===
+
+This format contains a sequence of complex number samples. Each complex
+number consist of two parts called In-phase and Quadrature (IQ). Both I
+and Q are represented as a 16 bit unsigned big endian number stored in
+32 bit space. The remaining unused bits within the 32 bit space will be
+padded with 0. I value starts first and Q value starts at an offset
+equalling half of the buffer size (i.e.) offset = buffersize/2. Out of
+the 16 bits, bit 15:2 (14 bit) is data and bit 1:0 (2 bit) can be any
+value.
+
+**Byte Order.**
+Each cell is one byte.
+
+.. flat-table::
+:header-rows:  1
+:stub-columns: 0
+
+* -  Offset:
+  -  Byte B0
+  -  Byte B1
+  -  Byte B2
+  -  Byte B3
+* -  start + 0:
+  -  I'\ :sub:`0[13:6]`
+  -  I'\ :sub:`0[5:0]; B1[1:0]=pad`
+  -  pad
+  -  pad
+* -  start + 4:
+  -  I'\ :sub:`1[13:6]`
+  -  I'\ :sub:`1[5:0]; B1[1:0]=pad`
+  -  pad
+  -  pad
+* -  ...
+* - start + offset:
+  -  Q'\ :sub:`0[13:6]`
+  -  Q'\ :sub:`0[5:0]; B1[1:0]=pad`
+  -  pad
+  -  pad
+* - start + offset + 4:
+  -  Q'\ :sub:`1[13:6]`
+  -  Q'\ :sub:`1[5:0]; B1[1:0]=pad`
+  -  pad
+  -  pad
diff --git a/Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst 
b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst
new file mode 100644
index ..da8b26bf6b95
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst
@@ -0,0 +1,55 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-SDR-FMT-PCU18BE:
+
+**
+V4L2_SDR_FMT_PCU18BE ('PC18')
+**
+
+Planar complex unsigned 18-bit big endian IQ sample
+
+Description
+===
+
+This format contains a sequence of complex number samples. Each complex
+number consist of two parts called In-phase and Quadrature (IQ). Both I
+and Q are represented as a 18 bit unsigned big endian number stored in
+32 bit space. The remaining unused bits within the 32 bit space will be
+padded with 0. I value starts first and Q value starts at an offset
+equalling half of the buffer size (i.e.) offset = buffersize/2. Out of
+the 18 bits, bit 17:2 (16 bit) is data and bit 1:0 (2 bit) can be any
+value.
+
+**Byte Order.**
+Each cell is one byte.
+
+.. flat-table::
+:header-rows:  1
+:stub-columns: 0
+
+* -  Offset:
+  -  Byte B0
+  -  Byte B1
+  -  Byte B2
+  -  Byte B3
+* -  start + 0:
+  -  I'\ :sub:`0[17:10]`
+  -  I'\ :sub:`0[9:2]`
+  -  I'\ :sub:`0[1:0]; B2[5:0]=pad`
+  -  pad
+* -  start + 4:
+  -  I'\ :sub:`1[17:10]`
+  -  I'\ :sub:`1[9:2]`
+  -  I'\ :sub:`1[1:0]; B2[5:0]=pad`
+  -  pad
+* -  ...
+* - start + offset:
+  -  Q'\ :sub:`0[17:10]`
+  -  Q'\ :sub:`0[9:2]`
+  -  Q'\ :sub:`0[1:0]; B2[5:0]=pad`
+  -  pad
+* - start + offset + 4:
+  -  Q'\ :sub:`1[17:10]`
+  -  Q'\ :sub:`1[9:2]`
+  -  Q'\ :sub:`1[1:0]; B2[5:0]=pad`
+  -  pad
diff --git a/Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst 
b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst
new file mode 100644
index ..5499eed39477
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst
@@ -0,0 +1,54 @@
+.. -*- coding: utf-8; mode: rst -*-
+.. _V4L2-SDR-FMT-PCU20BE:
+
+**
+V4L2_SDR_FMT_PCU20BE ('PC20')
+**
+
+Planar complex unsigned 20-bit big endian IQ sample
+
+Description
+===
+
+This format contains a sequence of complex number samples. Each complex
+number consist of two parts called In-phase and Quadrature (IQ). Both I
+and Q are represented as a 20 bit unsigned big endian number stored in
+32 

[PATCH v4 7/7] media: platform: rcar_drif: Add DRIF support

[Ramesh Shanmugasundaram]

This patch adds Digital Radio Interface (DRIF) support to R-Car Gen3 SoCs.
The driver exposes each instance of DRIF as a V4L2 SDR device. A DRIF
device represents a channel and each channel can have one or two
sub-channels respectively depending on the target board.

DRIF supports only Rx functionality. It receives samples from a RF
frontend tuner chip it is interfaced with. The combination of DRIF and the
tuner device, which is registered as a sub-device, determines the receive
sample rate and format.

In order to be compliant as a V4L2 SDR device, DRIF needs to bind with
the tuner device, which can be provided by a third party vendor. DRIF acts
as a slave device and the tuner device acts as a master transmitting the
samples. The driver allows asynchronous binding of a tuner device that
is registered as a v4l2 sub-device. The driver can learn about the tuner
it is interfaced with based on port endpoint properties of the device in
device tree. The V4L2 SDR device inherits the controls exposed by the
tuner device.

The device can also be configured to use either one or both of the data
pins at runtime based on the master (tuner) configuration.

Signed-off-by: Ramesh Shanmugasundaram 
---
v4:
 - Number of agreed review comments from Laurent are addressed.
   
(https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg13340.html)
---
 drivers/media/platform/Kconfig |   25 +
 drivers/media/platform/Makefile|1 +
 drivers/media/platform/rcar_drif.c | 1488 
 3 files changed, 1514 insertions(+)
 create mode 100644 drivers/media/platform/rcar_drif.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 73c3bc5deadf..433397802ef2 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -520,3 +520,28 @@ menuconfig DVB_PLATFORM_DRIVERS
 if DVB_PLATFORM_DRIVERS
 source "drivers/media/platform/sti/c8sectpfe/Kconfig"
 endif #DVB_PLATFORM_DRIVERS
+
+menuconfig SDR_PLATFORM_DRIVERS
+   bool "SDR platform devices"
+   depends on MEDIA_SDR_SUPPORT
+   default n
+   ---help---
+ Say Y here to enable support for platform-specific SDR Drivers.
+
+if SDR_PLATFORM_DRIVERS
+
+config VIDEO_RCAR_DRIF
+   tristate "Renesas Digitial Radio Interface (DRIF)"
+   depends on VIDEO_V4L2 && HAS_DMA
+   depends on ARCH_RENESAS
+   select VIDEOBUF2_VMALLOC
+   ---help---
+ Say Y if you want to enable R-Car Gen3 DRIF support. DRIF is Digital
+ Radio Interface that interfaces with an RF front end chip. It is a
+ receiver of digital data which uses DMA to transfer received data to
+ a configured location for an application to use.
+
+ To compile this driver as a module, choose M here; the module
+ will be called rcar_drif.
+
+endif # SDR_PLATFORM_DRIVERS
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 63303d63c64c..6349698bb37a 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_VIDEO_SH_VOU)+= sh_vou.o
 
 obj-$(CONFIG_SOC_CAMERA)   += soc_camera/
 
+obj-$(CONFIG_VIDEO_RCAR_DRIF)  += rcar_drif.o
 obj-$(CONFIG_VIDEO_RENESAS_FCP)+= rcar-fcp.o
 obj-$(CONFIG_VIDEO_RENESAS_FDP1)   += rcar_fdp1.o
 obj-$(CONFIG_VIDEO_RENESAS_JPU)+= rcar_jpu.o
diff --git a/drivers/media/platform/rcar_drif.c 
b/drivers/media/platform/rcar_drif.c
new file mode 100644
index ..d357e247f339
--- /dev/null
+++ b/drivers/media/platform/rcar_drif.c
@@ -0,0 +1,1488 @@
+/*
+ * R-Car Gen3 Digital Radio Interface (DRIF) driver
+ *
+ * Copyright (C) 2017 Renesas Electronics Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+/*
+ * The R-Car DRIF is a receive only MSIOF like controller with an
+ * external master device driving the SCK. It receives data into a FIFO,
+ * then this driver uses the SYS-DMAC engine to move the data from
+ * the device to memory.
+ *
+ * Each DRIF channel DRIFx (as per datasheet) contains two internal
+ * channels DRIFx0 & DRIFx1 within itself with each having its own resources
+ * like module clk, register set, irq and dma. These internal channels share
+ * common CLK & SYNC from master. The two data pins D0 & D1 shall be
+ * considered to represent the two internal channels. This internal split
+ * is not visible to the master device.
+ *
+ * Depending on the master device, a 

[PATCH v4 6/7] dt-bindings: media: Add Renesas R-Car DRIF binding

[Ramesh Shanmugasundaram]

Add binding documentation for Renesas R-Car Digital Radio Interface
(DRIF) controller.

Signed-off-by: Ramesh Shanmugasundaram 
---
v4:
 - port property description modified as suggested by Laurent.
 - removed renesas vendor tag from sync-active end-point property (Rob)
---
 .../devicetree/bindings/media/renesas,drif.txt | 187 +
 1 file changed, 187 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/renesas,drif.txt

diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt 
b/Documentation/devicetree/bindings/media/renesas,drif.txt
new file mode 100644
index ..12428f969958
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
@@ -0,0 +1,187 @@
+Renesas R-Car Gen3 Digital Radio Interface controller (DRIF)
+
+
+R-Car Gen3 DRIF is a SPI like receive only slave device. A general
+representation of DRIF interfacing with a master device is shown below.
+
++-++-+
+| |-SCK--->|CLK  |
+|   Master|-SS>|SYNC  DRIFn (slave)  |
+| |-SD0--->|D0   |
+| |-SD1--->|D1   |
++-++-+
+
+As per datasheet, each DRIF channel (drifn) is made up of two internal
+channels (drifn0 & drifn1). These two internal channels share the common
+CLK & SYNC. Each internal channel has its own dedicated resources like
+irq, dma channels, address space & clock. This internal split is not
+visible to the external master device.
+
+The device tree model represents each internal channel as a separate node.
+The internal channels sharing the CLK & SYNC are tied together by their
+phandles using a new property called "renesas,bonding". For the rest of
+the documentation, unless explicitly stated, the word channel implies an
+internal channel.
+
+When both internal channels are enabled they need to be managed together
+as one (i.e.) they cannot operate alone as independent devices. Out of the
+two, one of them needs to act as a primary device that accepts common
+properties of both the internal channels. This channel is identified by a
+new property called "renesas,primary-bond".
+
+To summarize,
+   - When both the internal channels that are bonded together are enabled,
+ the zeroth channel is selected as primary-bond. This channels accepts
+ properties common to all the members of the bond.
+   - When only one of the bonded channels need to be enabled, the property
+ "renesas,bonding" or "renesas,primary-bond" will have no effect. That
+ enabled channel can act alone as any other independent device.
+
+Required properties of an internal channel:
+---
+- compatible: "renesas,r8a7795-drif" if DRIF controller is a part of R8A7795 
SoC.
+ "renesas,rcar-gen3-drif" for a generic R-Car Gen3 compatible 
device.
+ When compatible with the generic version, nodes must list the
+ SoC-specific version corresponding to the platform first
+ followed by the generic version.
+- reg: offset and length of that channel.
+- interrupts: associated with that channel.
+- clocks: phandle and clock specifier of that channel.
+- clock-names: clock input name string: "fck".
+- dmas: phandles to the DMA channels.
+- dma-names: names of the DMA channel: "rx".
+- renesas,bonding: phandle to the other channel.
+
+Optional properties of an internal channel:
+---
+- power-domains: phandle to the respective power domain.
+
+Required properties of an internal channel when:
+   - It is the only enabled channel of the bond (or)
+   - If it acts as primary among enabled bonds
+
+- pinctrl-0: pin control group to be used for this channel.
+- pinctrl-names: must be "default".
+- renesas,primary-bond: empty property indicating the channel acts as primary
+   among the bonded channels.
+- port: child port node corresponding to the data input, in accordance with
+   the video interface bindings defined in
+   Documentation/devicetree/bindings/media/video-interfaces.txt. The port
+   node must contain at least one endpoint.
+
+Optional endpoint property:
+---
+- sync-active: Indicates sync signal polarity, 0/1 for low/high respectively.
+  This property maps to SYNCAC bit in the hardware manual. The
+  default is 1 (active high).
+
+Example
+
+
+SoC common dtsi file
+
+   drif00: rif@e6f4 {
+   compatible = "renesas,r8a7795-drif",
+"renesas,rcar-gen3-drif";
+  

[PATCH v4 3/7] media: i2c: max2175: Add MAX2175 support

[Ramesh Shanmugasundaram]

This patch adds driver support for the MAX2175 chip. This is Maxim
Integrated's RF to Bits tuner front end chip designed for software-defined
radio solutions. This driver exposes the tuner as a sub-device instance
with standard and custom controls to configure the device.

Signed-off-by: Ramesh Shanmugasundaram 
---
v4:
 - Addressed v4l2_ctrl name string convention (Hans)
  - "HSLS above/below" to "HSLS Above/Below"
  - "RX MODE" to "RX Mode"
---
 Documentation/media/v4l-drivers/index.rst   |1 +
 Documentation/media/v4l-drivers/max2175.rst |   60 ++
 drivers/media/i2c/Kconfig   |4 +
 drivers/media/i2c/Makefile  |2 +
 drivers/media/i2c/max2175/Kconfig   |8 +
 drivers/media/i2c/max2175/Makefile  |4 +
 drivers/media/i2c/max2175/max2175.c | 1437 +++
 drivers/media/i2c/max2175/max2175.h |  108 ++
 8 files changed, 1624 insertions(+)
 create mode 100644 Documentation/media/v4l-drivers/max2175.rst
 create mode 100644 drivers/media/i2c/max2175/Kconfig
 create mode 100644 drivers/media/i2c/max2175/Makefile
 create mode 100644 drivers/media/i2c/max2175/max2175.c
 create mode 100644 drivers/media/i2c/max2175/max2175.h

diff --git a/Documentation/media/v4l-drivers/index.rst 
b/Documentation/media/v4l-drivers/index.rst
index a606d1cdac13..d8cade53d496 100644
--- a/Documentation/media/v4l-drivers/index.rst
+++ b/Documentation/media/v4l-drivers/index.rst
@@ -42,6 +42,7 @@ For more details see the file COPYING in the source 
distribution of Linux.
davinci-vpbe
fimc
ivtv
+max2175
meye
omap3isp
omap4_camera
diff --git a/Documentation/media/v4l-drivers/max2175.rst 
b/Documentation/media/v4l-drivers/max2175.rst
new file mode 100644
index ..201af8f217e9
--- /dev/null
+++ b/Documentation/media/v4l-drivers/max2175.rst
@@ -0,0 +1,60 @@
+Maxim Integrated MAX2175 RF to bits tuner driver
+
+
+The MAX2175 driver implements the following driver-specific controls:
+
+``V4L2_CID_MAX2175_I2S_ENABLE``
+---
+Enable/Disable I2S output of the tuner.
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 4
+
+* - ``(0)``
+  - I2S output is disabled.
+* - ``(1)``
+  - I2S output is enabled.
+
+``V4L2_CID_MAX2175_HSLS``
+-
+The high-side/low-side (HSLS) control of the tuner for a given band.
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 4
+
+* - ``(0)``
+  - The LO frequency position is below the desired frequency.
+* - ``(1)``
+  - The LO frequency position is above the desired frequency.
+
+``V4L2_CID_MAX2175_RX_MODE (menu)``
+---
+The Rx mode controls a number of preset parameters of the tuner like sck
+rate, sampling rate etc. These multiple settings are provided under one
+single label called Rx mode in the datasheet. The list below shows the
+supported modes with a brief description.
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 4
+
+* - ``"Europe modes"``
+* - ``"FM 1.2" (0)``
+  - This configures FM band with a sample rate of 0.512 million
+samples/sec with a 10.24 MHz sck.
+* - ``"DAB 1.2" (1)``
+  - This configures VHF band with a sample rate of 2.048 million
+samples/sec with a 32.768 MHz sck.
+
+* - ``"North America modes"``
+* - ``"FM 1.0" (0)``
+  - This configures FM band with a sample rate of 0.7441875 million
+samples/sec with a 14.88375 MHz sck.
+* - ``"DAB 1.2" (1)``
+  - This configures FM band with a sample rate of 0.372 million
+samples/sec with a 7.441875 MHz sck.
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index b358d1a40688..d9fc1311794f 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -785,6 +785,10 @@ config VIDEO_SAA6752HS
  To compile this driver as a module, choose M here: the
  module will be called saa6752hs.
 
+comment "SDR tuner chips"
+
+source "drivers/media/i2c/max2175/Kconfig"
+
 comment "Miscellaneous helper chips"
 
 config VIDEO_THS7303
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 62323ec66be8..39567c415425 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -7,6 +7,8 @@ obj-$(CONFIG_VIDEO_CX25840) += cx25840/
 obj-$(CONFIG_VIDEO_M5MOLS) += m5mols/
 obj-y  += soc_camera/
 
+obj-$(CONFIG_SDR_MAX2175)  += max2175/
+
 obj-$(CONFIG_VIDEO_APTINA_PLL) += aptina-pll.o
 obj-$(CONFIG_VIDEO_TVAUDIO) += tvaudio.o
 obj-$(CONFIG_VIDEO_TDA7432) += tda7432.o
diff --git a/drivers/media/i2c/max2175/Kconfig 
b/drivers/media/i2c/max2175/Kconfig
new file mode 100644
index ..93a8f837d79f
--- 

[PATCH v4 2/7] dt-bindings: media: Add MAX2175 binding description

[Ramesh Shanmugasundaram]

Add device tree binding documentation for MAX2175 RF to bits tuner
device.

Signed-off-by: Ramesh Shanmugasundaram 
Acked-by: Rob Herring 
---
v4:
 - port property description modified as suggested by Laurent.
 - Renamed property name slave to master (Laurent).
 - Renamed property name am-hiz to am-hiz-filter and modified description.
---
 .../devicetree/bindings/media/i2c/max2175.txt  | 61 ++
 .../devicetree/bindings/property-units.txt |  1 +
 2 files changed, 62 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/max2175.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/max2175.txt 
b/Documentation/devicetree/bindings/media/i2c/max2175.txt
new file mode 100644
index ..a5e3bc8f6753
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/max2175.txt
@@ -0,0 +1,61 @@
+Maxim Integrated MAX2175 RF to Bits tuner
+-
+
+The MAX2175 IC is an advanced analog/digital hybrid-radio receiver with
+RF to Bits® front-end designed for software-defined radio solutions.
+
+Required properties:
+
+- compatible: "maxim,max2175" for MAX2175 RF-to-bits tuner.
+- clocks: phandle to the fixed xtal clock.
+- clock-names: name of the fixed xtal clock, shall be "xtal".
+- port: child port node corresponding to the I2S output, in accordance with
+   the video interface bindings defined in
+   Documentation/devicetree/bindings/media/video-interfaces.txt. The port
+   node must contain at least one endpoint.
+
+Optional properties:
+
+- maxim,master   : phandle to the master tuner if it is a slave. This
+   is used to define two tuners in diversity mode
+   (1 master, 1 slave). By default each tuner is an
+   individual master.
+- maxim,refout-load-pF: load capacitance value (in pF) on reference
+   output drive level. The possible load values are:
+0 (default - refout disabled)
+   10
+   20
+   30
+   40
+   60
+   70
+- maxim,am-hiz-filter : empty property indicates the AM Hi-Z filter is used
+   in this hardware for AM antenna input.
+
+Example:
+
+
+Board specific DTS file
+
+/* Fixed XTAL clock node */
+maxim_xtal: clock {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <36864000>;
+};
+
+/* A tuner device instance under i2c bus */
+max2175_0: tuner@60 {
+   compatible = "maxim,max2175";
+   reg = <0x60>;
+   clocks = <_xtal>;
+   clock-names = "xtal";
+   maxim,refout-load-pF = <10>;
+
+   port {
+   max2175_0_ep: endpoint {
+   remote-endpoint = <_rx_device>;
+   };
+   };
+
+};
diff --git a/Documentation/devicetree/bindings/property-units.txt 
b/Documentation/devicetree/bindings/property-units.txt
index 12278d79f6c0..f1f1c22aa5de 100644
--- a/Documentation/devicetree/bindings/property-units.txt
+++ b/Documentation/devicetree/bindings/property-units.txt
@@ -28,6 +28,7 @@ Electricity
 -ohms  : Ohms
 -micro-ohms: micro Ohms
 -microvolt : micro volts
+-pF: pico farads
 
 Temperature
 
-- 
2.12.2

[PATCH v4 4/7] media: Add new SDR formats PC16, PC18 & PC20

[Ramesh Shanmugasundaram]

This patch adds support for the three new SDR formats. These formats
were prefixed with "planar" indicating I & Q data are not interleaved
as in other formats. Here, I & Q data constitutes the top half and bottom
half of the received buffer respectively.

V4L2_SDR_FMT_PCU16BE - 14-bit complex (I & Q) unsigned big-endian sample
inside 16-bit. V4L2 FourCC: PC16

V4L2_SDR_FMT_PCU18BE - 16-bit complex (I & Q) unsigned big-endian sample
inside 18-bit. V4L2 FourCC: PC18

V4L2_SDR_FMT_PCU20BE - 18-bit complex (I & Q) unsigned big-endian sample
inside 20-bit. V4L2 FourCC: PC20

Signed-off-by: Ramesh Shanmugasundaram 
---
 drivers/media/v4l2-core/v4l2-ioctl.c | 3 +++
 include/uapi/linux/videodev2.h   | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index e5a2187381db..ca1e920d3e7c 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1229,6 +1229,9 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_SDR_FMT_CS8:  descr = "Complex S8"; break;
case V4L2_SDR_FMT_CS14LE:   descr = "Complex S14LE"; break;
case V4L2_SDR_FMT_RU12LE:   descr = "Real U12LE"; break;
+   case V4L2_SDR_FMT_PCU16BE:  descr = "Planar Complex U16BE"; break;
+   case V4L2_SDR_FMT_PCU18BE:  descr = "Planar Complex U18BE"; break;
+   case V4L2_SDR_FMT_PCU20BE:  descr = "Planar Complex U20BE"; break;
case V4L2_TCH_FMT_DELTA_TD16:   descr = "16-bit signed deltas"; break;
case V4L2_TCH_FMT_DELTA_TD08:   descr = "8-bit signed deltas"; break;
case V4L2_TCH_FMT_TU16: descr = "16-bit unsigned touch data"; 
break;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 2b8feb86d09e..45cf7359822c 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -669,6 +669,9 @@ struct v4l2_pix_format {
 #define V4L2_SDR_FMT_CS8  v4l2_fourcc('C', 'S', '0', '8') /* complex 
s8 */
 #define V4L2_SDR_FMT_CS14LE   v4l2_fourcc('C', 'S', '1', '4') /* complex 
s14le */
 #define V4L2_SDR_FMT_RU12LE   v4l2_fourcc('R', 'U', '1', '2') /* real 
u12le */
+#define V4L2_SDR_FMT_PCU16BE v4l2_fourcc('P', 'C', '1', '6') /* planar 
complex u16be */
+#define V4L2_SDR_FMT_PCU18BE v4l2_fourcc('P', 'C', '1', '8') /* planar 
complex u18be */
+#define V4L2_SDR_FMT_PCU20BE v4l2_fourcc('P', 'C', '2', '0') /* planar 
complex u20be */
 
 /* Touch formats - used for Touch devices */
 #define V4L2_TCH_FMT_DELTA_TD16v4l2_fourcc('T', 'D', '1', '6') /* 
16-bit signed deltas */
-- 
2.12.2

[PATCH v4 1/7] media: v4l2-ctrls: Reserve controls for MAX217X

[Ramesh Shanmugasundaram]

Reserve controls for MAX217X RF to Bits tuner family. These hybrid
radio receiver chips are highly programmable and hence reserving 32
controls.

Signed-off-by: Ramesh Shanmugasundaram 
Acked-by: Laurent Pinchart 
---
 include/uapi/linux/v4l2-controls.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/uapi/linux/v4l2-controls.h 
b/include/uapi/linux/v4l2-controls.h
index 0d2e1e01fbd5..83b28b41123f 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -180,6 +180,11 @@ enum v4l2_colorfx {
  * We reserve 16 controls for this driver. */
 #define V4L2_CID_USER_TC358743_BASE(V4L2_CID_USER_BASE + 0x1080)
 
+/* The base for the max217x driver controls.
+ * We reserve 32 controls for this driver
+ */
+#define V4L2_CID_USER_MAX217X_BASE (V4L2_CID_USER_BASE + 0x1090)
+
 /* MPEG-class control IDs */
 /* The MPEG controls are applicable to all codec controls
  * and the 'MPEG' part of the define is historical */
-- 
2.12.2

[PATCH v4 0/7] Add V4L2 SDR (DRIF & MAX2175) driver

[Ramesh Shanmugasundaram]

Hi Media, DT maintainers, All,

This patch set contains two drivers
 - Renesas R-Car Digital Radio Interface (DRIF) driver
 - Maxim's MAX2175 RF to Bits tuner driver

These patches were based on top of media-next repo
commit:6d95b3f24881c0fd0f345eca959a2a803a040930

These two drivers combined together expose a V4L2 SDR device that is compliant 
with the V4L2 framework [1]. Agreed review comments are incorporated in this 
series.

The rcar_drif device is modelled using "renesas,bonding" property. The 
discussion on this property is available here [2].

Change history:

v3 -> v4:
 - Added ACKs
rcar_drif:
 - Incorporated a number of review comments from Laurent on DRIF driver.
 - Addressed comments from Rob and Laurent on bindings.
max2175:
 - Minor changes addressing Hans and Laurent's comments

v2 -> v3:
rcar_drif:
 - Reduced DRIF DT properties to expose tested I2S mode only (Hans - discussion 
on #v4l)
 - Fixed error path clean up of ctrl_hdl on rcar_drif

v1 -> v2:
 - SDR formats renamed as "planar" instead of sliced (Hans)
 - Documentation formatting correction (Laurent)

 rcar_drif:
 - DT model using "bonding" property
 - Addressed Laurent's coments on bindings - DT optional parameters rename & 
rework
 - Addressed Han's comments on driver
 - Addressed Geert's comments on DT

 max2175:
 - Avoided scaling using method proposed by Antti. Thanks
 - Bindings is a separate patch (Rob)
 - Addressed Rob's comment on bindings
 - Added Custom controls documentation (Laurent)

[1] v4l2-compliance report:
root@salvator-x:~# v4l2-compliance -S /dev/swradio0
v4l2-compliance SHA   : b514d615166bdc0901a4c71261b87db31e89f464

Driver Info:
Driver name   : rcar_drif
Card type : R-Car DRIF
Bus info  : platform:R-Car DRIF
Driver version: 4.11.0
Capabilities  : 0x8531
SDR Capture
Tuner
Read/Write
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x0531
SDR Capture
Tuner
Read/Write
Streaming
Extended Pix Format

Compliance test for device /dev/swradio0 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second sdr open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK
test VIDIOC_LOG_STATUS: OK

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK
test VIDIOC_G/S_FREQUENCY: OK
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 1

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 5 Private Controls: 3

Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK (Not Supported)
test Scaling: OK (Not Supported)

Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test VIDIOC_EXPBUF: OK (Not Supported)

Test input 0:


Total: 43, Succeeded: 43, Failed: 0, Warnings: 0
root@salvator-x:~#

[2] "bonding" DT property discussion 
(https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg09415.html)

Ramesh 

Re: [PATCH v4 23/27] rcar-vin: parse Gen3 OF and setup media graph

[Kieran Bingham]

Hi Niklas

Just a quick comment here, as I've come across it while looking at the fw_node
topic.

On 27/04/17 23:41, Niklas Söderlund wrote:
> Parse the VIN Gen3 OF graph and register all CSI-2 devices in the VIN
> group common media device. Once a CSI-2 subdevice is added to the common
> media device list as many links as possible are added.
> 
> The parsing and registering CSI-2 subdevices is a collaborative effort
> shared between all rcar-vin instances which are part of the group.  The
> rcar-vin instance that first sees a new CSI-2 subdevice adds it to its
> private v4l2 async notifier and once it's bound it will be
> available for the whole group.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 340 
> ++--
>  1 file changed, 327 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index c10770d5ec37816c..9b9da9a419d0b7e1 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -158,21 +158,32 @@ static int rvin_parse_v4l2(struct rvin_dev *vin,
>  
>   mbus_cfg->type = v4l2_ep.bus_type;
>  
> - switch (mbus_cfg->type) {
> - case V4L2_MBUS_PARALLEL:
> - vin_dbg(vin, "Found PARALLEL media bus\n");
> - mbus_cfg->flags = v4l2_ep.bus.parallel.flags;
> - break;
> - case V4L2_MBUS_BT656:
> - vin_dbg(vin, "Found BT656 media bus\n");
> - mbus_cfg->flags = 0;
> - break;
> - default:
> - vin_err(vin, "Unknown media bus type\n");
> - return -EINVAL;
> + if (vin->info->chip == RCAR_GEN3) {
> + switch (mbus_cfg->type) {
> + case V4L2_MBUS_CSI2:
> + vin_dbg(vin, "Found CSI-2 media bus\n");
> + mbus_cfg->flags = 0;
> + return 0;
> + default:
> + break;
> + }
> + } else {
> + switch (mbus_cfg->type) {
> + case V4L2_MBUS_PARALLEL:
> + vin_dbg(vin, "Found PARALLEL media bus\n");
> + mbus_cfg->flags = v4l2_ep.bus.parallel.flags;
> + return 0;
> + case V4L2_MBUS_BT656:
> + vin_dbg(vin, "Found BT656 media bus\n");
> + mbus_cfg->flags = 0;
> + return 0;
> + default:
> + break;
> + }
>   }
>  
> - return 0;
> + vin_err(vin, "Unknown media bus type\n");
> + return -EINVAL;
>  }
>  
>  /* 
> -
> @@ -357,6 +368,299 @@ static int rvin_digital_graph_init(struct rvin_dev *vin)
>   * Group async notifier
>   */
>  
> +/* group lock should be held when calling this function */
> +static int rvin_group_add_link(struct rvin_dev *vin,
> +struct media_entity *source,
> +unsigned int source_idx,
> +struct media_entity *sink,
> +unsigned int sink_idx,
> +u32 flags)
> +{
> + struct media_pad *source_pad, *sink_pad;
> + int ret = 0;
> +
> + source_pad = >pads[source_idx];
> + sink_pad = >pads[sink_idx];
> +
> + if (!media_entity_find_link(source_pad, sink_pad))
> + ret = media_create_pad_link(source, source_idx,
> + sink, sink_idx, flags);
> +
> + if (ret)
> + vin_err(vin, "Error adding link from %s to %s\n",
> + source->name, sink->name);
> +
> + return ret;
> +}
> +
> +static int rvin_group_update_links(struct rvin_dev *vin)
> +{
> + struct media_entity *source, *sink;
> + struct rvin_dev *master;
> + unsigned int i, n, idx, chsel, csi;
> + u32 flags;
> + int ret;
> +
> + mutex_lock(>group->lock);
> +
> + for (n = 0; n < RCAR_VIN_NUM; n++) {
> +
> + /* Check that VIN is part of the group */
> + if (!vin->group->vin[n])
> + continue;
> +
> + /* Check that subgroup master is part of the group */
> + master = vin->group->vin[n < 4 ? 0 : 4];
> + if (!master)
> + continue;
> +
> + chsel = rvin_get_chsel(master);
> +
> + for (i = 0; i < vin->info->num_chsels; i++) {
> + csi = vin->info->chsels[n][i].csi;
> +
> + /* If the CSI-2 is out of bounds it's a noop, skip */
> + if (csi >= RVIN_CSI_MAX)
> + continue;
> +
> + /* Check that CSI-2 are part of the group */
> + if (!vin->group->csi[csi].subdev)
> + 

Re: [PATCH 3/3] [media] intel-ipu3: cio2: Add new MIPI-CSI2 driver

[Sakari Ailus]

Hi Yong,

Thanks for the patches! Some comments below.

On Sat, Apr 29, 2017 at 06:34:36PM -0500, Yong Zhi wrote:
> This patch adds CIO2 CSI-2 device driver for
> Intel's IPU3 camera sub-system support.
> 
> The V4L2 fwnode matching depends on the following work:
> 
> 
> 
> Signed-off-by: Yong Zhi 
> ---
>  drivers/media/pci/Kconfig  |2 +
>  drivers/media/pci/Makefile |3 +-
>  drivers/media/pci/ipu3/Kconfig |   17 +
>  drivers/media/pci/ipu3/Makefile|1 +
>  drivers/media/pci/ipu3/ipu3-cio2.c | 1813 
> 
>  drivers/media/pci/ipu3/ipu3-cio2.h |  425 +
>  6 files changed, 2260 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/media/pci/ipu3/Kconfig
>  create mode 100644 drivers/media/pci/ipu3/Makefile
>  create mode 100644 drivers/media/pci/ipu3/ipu3-cio2.c
>  create mode 100644 drivers/media/pci/ipu3/ipu3-cio2.h
> 
> diff --git a/drivers/media/pci/Kconfig b/drivers/media/pci/Kconfig
> index da28e68..63ece75 100644
> --- a/drivers/media/pci/Kconfig
> +++ b/drivers/media/pci/Kconfig
> @@ -54,5 +54,7 @@ source "drivers/media/pci/smipcie/Kconfig"
>  source "drivers/media/pci/netup_unidvb/Kconfig"
>  endif
>  
> +source "drivers/media/pci/ipu3/Kconfig"
> +
>  endif #MEDIA_PCI_SUPPORT
>  endif #PCI
> diff --git a/drivers/media/pci/Makefile b/drivers/media/pci/Makefile
> index a7e8af0..8d5e8db 100644
> --- a/drivers/media/pci/Makefile
> +++ b/drivers/media/pci/Makefile
> @@ -13,7 +13,8 @@ obj-y+= ttpci/  \
>   ddbridge/   \
>   saa7146/\
>   smipcie/\
> - netup_unidvb/
> + netup_unidvb/   \
> + ipu3/
>  
>  obj-$(CONFIG_VIDEO_IVTV) += ivtv/
>  obj-$(CONFIG_VIDEO_ZORAN) += zoran/
> diff --git a/drivers/media/pci/ipu3/Kconfig b/drivers/media/pci/ipu3/Kconfig
> new file mode 100644
> index 000..2a895d6
> --- /dev/null
> +++ b/drivers/media/pci/ipu3/Kconfig
> @@ -0,0 +1,17 @@
> +config VIDEO_IPU3_CIO2
> + tristate "Intel ipu3-cio2 driver"
> + depends on VIDEO_V4L2 && PCI
> + depends on MEDIA_CONTROLLER
> + depends on HAS_DMA
> + depends on ACPI
> + select V4L2_FWNODE
> + select VIDEOBUF2_DMA_SG
> +
> + ---help---
> + This is the Intel IPU3 CIO2 CSI-2 receiver unit, found in Intel
> + Skylake and Kaby Lake SoCs and used for capturing images and
> + video from a camera sensor.
> +
> + Say Y or M here if you have a Skylake/Kaby Lake SoC with MIPI CSI-2
> + connected camera.
> + The module will be called ipu3-cio2.
> diff --git a/drivers/media/pci/ipu3/Makefile b/drivers/media/pci/ipu3/Makefile
> new file mode 100644
> index 000..20186e3
> --- /dev/null
> +++ b/drivers/media/pci/ipu3/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_VIDEO_IPU3_CIO2) += ipu3-cio2.o
> diff --git a/drivers/media/pci/ipu3/ipu3-cio2.c 
> b/drivers/media/pci/ipu3/ipu3-cio2.c
> new file mode 100644
> index 000..2b641ad
> --- /dev/null
> +++ b/drivers/media/pci/ipu3/ipu3-cio2.c
> @@ -0,0 +1,1813 @@
> +/*
> + * Copyright (c) 2017 Intel Corporation.
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Based partially on Intel IPU4 driver written by
> + *  Sakari Ailus 
> + *  Samu Onkalo 
> + *  Jouni Högander 
> + *  Jouni Ukkonen 
> + *  Antti Laakso 
> + * et al.
> + *
> + */
> +
> +#include 

I believe you shouldn't need this one.

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Alphabetical order, please.

> +#include "ipu3-cio2.h"
> +
> +MODULE_AUTHOR("Tianshu Qiu ");
> +MODULE_AUTHOR("Jian Xu Zheng ");
> +MODULE_AUTHOR("Yuning Pu ");
> +MODULE_AUTHOR("Tuukka Toivonen ");
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("IPU3 CIO2 driver");
> +
> +/*
> + * These are raw formats used in Intel's third generation of
> + * Image Processing Unit known as IPU3.
> + * 10bit raw bayer packed, 32 bytes for every 25 pixels, last 6 bits unused
> + */
> +static const u32 cio2_csi2_fmts[] = {
> + V4L2_PIX_FMT_IPU3_SRGGB10,
> + V4L2_PIX_FMT_IPU3_SGBRG10,
> + V4L2_PIX_FMT_IPU3_SGRBG10,
> + V4L2_PIX_FMT_IPU3_SBGGR10,
> +};
> +
> +static inline 

[GIT PULL FOR v4.12] RC bugfixes

[Sean Young]

Hi Mauro,

Please pull these two fixes. One is for a repeat regression which was
introduced in v4.11, another is for the lirc_buffer being freed on
lirc_unregister even though a user can still have an fd open (this
fix depends on "74c839b [media] lirc: use refcounting for lirc devices",
so it's not for stable).

Thanks,
Sean

The following changes since commit 3622d3e77ecef090b5111e3c5423313f11711dfa:

  [media] ov2640: print error if devm_*_optional*() fails (2017-04-25 07:08:21 
-0300)

are available in the git repository at:

  git://linuxtv.org/syoung/media_tree.git for-v4.12d

for you to fetch changes up to 5a285b2dd0c3d36ee2ca6b17826f643c6b4415fc:

  [media] ir-lirc-codec: let lirc_dev handle the lirc_buffer (2017-05-01 
15:56:05 +0100)


David Härdeman (2):
  [media] rc-core: fix input repeat handling
  [media] ir-lirc-codec: let lirc_dev handle the lirc_buffer

 drivers/media/rc/ir-lirc-codec.c | 25 +++--
 drivers/media/rc/lirc_dev.c  | 13 -
 drivers/media/rc/rc-main.c   | 20 ++--
 3 files changed, 29 insertions(+), 29 deletions(-)

[RFC 2/3] dt: bindings: Add lens-focus binding for image sensors

[Sakari Ailus]

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 
---
 Documentation/devicetree/bindings/media/video-interfaces.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt 
b/Documentation/devicetree/bindings/media/video-interfaces.txt
index d6c62bc..e52aefc 100644
--- a/Documentation/devicetree/bindings/media/video-interfaces.txt
+++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
@@ -77,6 +77,9 @@ Optional properties
   the child nodes of the LED driver describing individual LEDs. Only
   valid for device nodes that are related to an image sensor.
 
+- lens-focus: A phandle to the node of the lens. Only valid for device
+  nodes that are related to an image sensor.
+
 
 Optional endpoint properties
 
-- 
2.7.4

[RFC 0/3] Document bindings for camera modules and associated flash devices

[Sakari Ailus]

Hi folks,

This RFC patchset documents properties commonly required by camera modules
and associated camera flash devices.

The camera module is essentially a package consisting of an image sensor,
a lens, possibly a voice coil to move the lens and a number of other
things that at least the drivers need not to know of. All the devices in a
camera module are declared separately in the system and as such the fact
that they come in a single package isn't generally very useful to driver
software.

I'm sending the set as RFC as there's no driver implementation, and a
dependency to the V4L2 async changes:



-- 
Regards,
Sakari

[RFC 3/3] dt: bindings: Add a binding for referencing EEPROM from camera sensors

[Sakari Ailus]

Many camera sensor devices contain EEPROM chips that describe the
properties of a given unit --- the data is specific to a given unit can
thus is not stored e.g. in user space or the driver.

Some sensors embed the EEPROM chip and it can be accessed through the
sensor's I²C interface. This property is to be used for devices where the
EEPROM chip is accessed through a different I²C address than the sensor.

The intent is to later provide this information to the user space.

Signed-off-by: Sakari Ailus 
---
 Documentation/devicetree/bindings/media/video-interfaces.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt 
b/Documentation/devicetree/bindings/media/video-interfaces.txt
index e52aefc..9bd2005 100644
--- a/Documentation/devicetree/bindings/media/video-interfaces.txt
+++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
@@ -80,6 +80,9 @@ Optional properties
 - lens-focus: A phandle to the node of the lens. Only valid for device
   nodes that are related to an image sensor.
 
+- eeprom: A phandle to the node of the related EEPROM. Only valid for
+  device nodes that are related to an image sensor.
+
 
 Optional endpoint properties
 
-- 
2.7.4

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

[Sakari Ailus]

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 
---
 Documentation/devicetree/bindings/media/video-interfaces.txt | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt 
b/Documentation/devicetree/bindings/media/video-interfaces.txt
index 9cd2a36..d6c62bc 100644
--- a/Documentation/devicetree/bindings/media/video-interfaces.txt
+++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
@@ -67,6 +67,17 @@ are required in a relevant parent node:
identifier, should be 1.
  - #size-cells: should be zero.
 
+
+Optional properties
+---
+
+- flash: An array of phandles that refer to the flash light sources
+  related to an image sensor. These could be e.g. LEDs. In case the LED
+  driver drives more than a single LED, then the phandles here refer to
+  the child nodes of the LED driver describing individual LEDs. Only
+  valid for device nodes that are related to an image sensor.
+
+
 Optional endpoint properties
 
 
-- 
2.7.4

Re: [PATCH v8 05/10] media: venus: adding core part and helper functions

[Stanimir Varbanov]

Hi,

On 04/29/2017 11:22 PM, Bjorn Andersson wrote:
> On Fri 28 Apr 15:02 PDT 2017, Jordan Crouse wrote:
> 
>> On Fri, Apr 28, 2017 at 12:13:52PM +0300, Stanimir Varbanov wrote:
>>> +int venus_boot(struct device *parent, struct device *fw_dev)
>>> +{
>>> +   const struct firmware *mdt;
>>> +   phys_addr_t mem_phys;
>>> +   ssize_t fw_size;
>>> +   size_t mem_size;
>>> +   void *mem_va;
>>> +   int ret;
>>> +
>>> +   if (!qcom_scm_is_available())
>>> +   return -EPROBE_DEFER;
>>> +
>>> +   fw_dev->parent = parent;
>>> +   fw_dev->release = device_release_dummy;
>>> +
>>> +   ret = dev_set_name(fw_dev, "%s:%s", dev_name(parent), "firmware");
>>> +   if (ret)
>>> +   return ret;
>>> +
>>> +   ret = device_register(fw_dev);
>>> +   if (ret < 0)
>>> +   return ret;
>>> +
>>> +   ret = of_reserved_mem_device_init_by_idx(fw_dev, parent->of_node, 0);
>>> +   if (ret)
>>> +   goto err_unreg_device;
>>> +
>>> +   mem_size = VENUS_FW_MEM_SIZE;
>>> +
>>> +   mem_va = dmam_alloc_coherent(fw_dev, mem_size, _phys, GFP_KERNEL);
>>> +   if (!mem_va) {
>>> +   ret = -ENOMEM;
>>> +   goto err_unreg_device;
>>> +   }
>>> +
>>> +   ret = request_firmware(, VENUS_FIRMWARE_NAME, fw_dev);
>>> +   if (ret < 0)
>>> +   goto err_unreg_device;
>>> +
>>> +   fw_size = qcom_mdt_get_size(mdt);
>>> +   if (fw_size < 0) {
>>> +   ret = fw_size;
>>> +   release_firmware(mdt);
>>> +   goto err_unreg_device;
>>> +   }
>>> +
>>> +   ret = qcom_mdt_load(fw_dev, mdt, VENUS_FIRMWARE_NAME, VENUS_PAS_ID,
>>> +   mem_va, mem_phys, mem_size);
>>> +
>>> +   release_firmware(mdt);
>>> +
>>> +   if (ret)
>>> +   goto err_unreg_device;
>>> +
>>> +   ret = qcom_scm_pas_auth_and_reset(VENUS_PAS_ID);
>>> +   if (ret)
>>> +   goto err_unreg_device;
>>> +
>>> +   return 0;
>>> +
>>> +err_unreg_device:
>>> +   device_unregister(fw_dev);
>>> +   return ret;
>>> +}
>>
>> Hey, this looks familiar - almost line for line identical to what we'll need 
>> to
>> do for GPU.
>>
>> Bjorn - Is this enough to qualify for generic status in the mdt_loader code?
>> I know its just two consumers, but it would save 50 or 60 lines of code 
>> between
>> the two drivers and be easier to maintain.
>>
> 
> I think the code setting up the struct device for memory allocation
> should be done during probe of the parent, so that I don't think should
> be shared.
> 
> The part that allocates memory from a device, loads the mdt into that
> memory and calls auth_and_reset() sounds like a useful thing to move to
> the mdt_loader.c

I agree, who is going to do that?

-- 
regards,
Stan

Re: [PATCH v8 05/10] media: venus: adding core part and helper functions

[Stanimir Varbanov]

Hei Sakari,

On 04/30/2017 01:21 AM, Sakari Ailus wrote:
> Hi, Stan!!
> 
> On Fri, Apr 28, 2017 at 12:13:52PM +0300, Stanimir Varbanov wrote:
> ...
>> +int helper_get_bufreq(struct venus_inst *inst, u32 type,
>> +  struct hfi_buffer_requirements *req)
>> +{
>> +u32 ptype = HFI_PROPERTY_CONFIG_BUFFER_REQUIREMENTS;
>> +union hfi_get_property hprop;
>> +int ret, i;
> 
> unsigned int i ? It's an array index...

Thanks for pointing that out, I have to revisit all similar places as
well ...

> 
>> +
>> +if (req)
>> +memset(req, 0, sizeof(*req));
>> +
>> +ret = hfi_session_get_property(inst, ptype, );
>> +if (ret)
>> +return ret;
>> +
>> +ret = -EINVAL;
>> +
>> +for (i = 0; i < HFI_BUFFER_TYPE_MAX; i++) {
>> +if (hprop.bufreq[i].type != type)
>> +continue;
>> +
>> +if (req)
>> +memcpy(req, [i], sizeof(*req));
>> +ret = 0;
>> +break;
>> +}
>> +
>> +return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(helper_get_bufreq);
> 
> As these are global symbols but still specific to a single driver, it'd be
> good to have them prefixed with a common prefix. How about "venus"? You
> actually already have that in a macro in the header. :-)

You are damned right, will rework that in next version.



-- 
regards,
Stan