Re: Cine CT V6.1 code change request

[Hans Verkuil]

On 02/14/2017 09:59 PM, Martin Herrman wrote:
> All,
> 
> I have a Cine CT V6.1 in my fedora 25 based media center. It is now
> running a default fedora 4.9 kernel. I install the driver as follows:
> 
> hg clone https://linuxtv.org/hg/~endriss/media_build_experimental

I'm not sure what this media_build directory is. It certainly is
outdated. The latest media_build is here: 
https://git.linuxtv.org/media_build.git/

> cd media_build_experimental
> make download
> make untar
> make menuconfig
> make
> make install
> 
> However, I have to make two changes to the source to make it work.
> 
> Change 1: in media_build_experimental/v4l/Kconfig line 6936 I have to
> remove the whitespace in '--- help ---', otherwise make menuconfig
> fails.

Can you show that line and the surrounding lines? I.e. the whole menu
entry?

> Change 2: during compilation the following error occurs (since about
> kernel 4.5?):

Most likely because the media build you use is outdated.

> 
> make -C /lib/modules/4.9.7-201.fc25.x86_64/build
> SUBDIRS=/home/htpc/Downloads/media_build_experimental/v4l  modules
> make[2]: Entering directory '/usr/src/kernels/4.9.7-201.fc25.x86_64'
>   CC [M]  /home/htpc/Downloads/media_build_experimental/v4l/tuner-xc2028.o
> In file included from :0:0:
> /home/htpc/Downloads/media_build_experimental/v4l/compat.h:1463:1:
> error: redefinition of 'pci_zalloc_consistent'
>  pci_zalloc_consistent(struct pci_dev *hwdev, size_t size,
>  ^
> In file included from ./include/linux/pci.h:2145:0,
>  from
> /home/htpc/Downloads/media_build_experimental/v4l/compat.h:1459,
>  from :0:
> ./include/linux/pci-dma-compat.h:23:1: note: previous definition of
> 'pci_zalloc_consistent' was here
>  pci_zalloc_consistent(struct pci_dev *hwdev, size_t size,
>  ^
> In file included from :0:0:
> /home/htpc/Downloads/media_build_experimental/v4l/compat.h:1552:0:
> warning: "DMA_ATTR_SKIP_CPU_SYNC" redefined
>  #define DMA_ATTR_SKIP_CPU_SYNC 0
> 
> In file included from ./include/linux/pci-dma-compat.h:7:0,
>  from ./include/linux/pci.h:2145,
>  from
> /home/htpc/Downloads/media_build_experimental/v4l/compat.h:1459,
>  from :0:
> ./include/linux/dma-mapping.h:47:0: note: this is the location of the
> previous definition
>  #define DMA_ATTR_SKIP_CPU_SYNC  (1UL << 5)
> 
> scripts/Makefile.build:299: recipe for target
> '/home/htpc/Downloads/media_build_experimental/v4l/tuner-xc2028.o'
> failed
> make[3]: *** 
> [/home/htpc/Downloads/media_build_experimental/v4l/tuner-xc2028.o]
> Error 1
> Makefile:1494: recipe for target
> '_module_/home/htpc/Downloads/media_build_experimental/v4l' failed
> make[2]: *** [_module_/home/htpc/Downloads/media_build_experimental/v4l] 
> Error 2
> make[2]: Leaving directory '/usr/src/kernels/4.9.7-201.fc25.x86_64'
> Makefile:51: recipe for target 'default' failed
> make[1]: *** [default] Error 2
> make[1]: Leaving directory '/home/htpc/Downloads/media_build_experimental/v4l'
> Makefile:28: recipe for target 'all' failed
> make: *** [all] Error 2
> 
> Which I fix by commenting out lines 1462 up to 1468 in
> media_build_experimental/v4l/compat.h:
> 
> //static inline void *
> //pci_zalloc_consistent(struct pci_dev *hwdev, size_t size,
> // dma_addr_t *dma_handle)
> //{
> // return dma_alloc_coherent(hwdev == NULL ? NULL : >dev,
> // size, dma_handle, GFP_ATOMIC | __GFP_ZERO);
> //}
> 
> Now it compiles and works fine. I still get these warnings:
> 
> media_build_experimental/v4l/compat.h:1552:0: warning:
> "DMA_ATTR_SKIP_CPU_SYNC" redefined
>  #define DMA_ATTR_SKIP_CPU_SYNC 0
> 
> Which I can easily remove by commenting out the specific line as well.
> 
> Now my questions are:
> - is this the correct way to fix these compile errors? (I'm definately
> not a professional developer)
> - what can I do to have this solved in the source?
> 
> Besides that, I'm also wondering if these drivers have any change of
> getting into kernel mainline?

Which driver?

Regards,

Hans

Re: [PATCH v3 1/2] v4l: Add camera voice coil lens control class, current control

[Sakari Ailus]

Hi Pavel,

On 02/15/17 00:47, Pavel Machek wrote:
> On Tue 2017-02-14 14:20:22, Sakari Ailus wrote:
>> Add a V4L2 control class for voice coil lens driver devices. These are
>> simple devices that are used to move a camera lens from its resting
>> position.
>>
>> Signed-off-by: Sakari Ailus 
> 
> Looks good to me.
> 
> I wonder... should we somehow expose the range of diopters to
> userspace? I believe userland camera application will need that
> information.

It'd certainly be useful to be able to provide more information.

The question is: where to store it, and how? It depends on the voice
coil, the spring constant, the lens and the distance of the lens from
the sensor --- at least. Probably the sensor size as well.

On voice coil lenses it is also somewhat inexact.

-- 
Kind regards,

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



signature.asc
Description: OpenPGP digital signature

cron job: media_tree daily build: WARNINGS

[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 Feb 15 05:00:18 CET 2017
media-tree git hash:9eeb0ed0f30938f31a3d9135a88b9502192c18dd
media_build git hash:   785cdf7f0798964681b33aad44fc2ff4d734733d
v4l-utils git hash: 90257a21f8f73f4616b3572402eaf490b4f71f79
gcc version:i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.8.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: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.2.37-i686: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.4.27-i686: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: WARNINGS
linux-3.12.67-i686: WARNINGS
linux-3.13.11-i686: WARNINGS
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-rc3-i686: OK
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.37-x86_64: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: WARNINGS
linux-3.12.67-x86_64: WARNINGS
linux-3.13.11-x86_64: WARNINGS
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: OK
linux-4.9-x86_64: OK
linux-4.10-rc3-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

Re: [PATCH v3 00/24] i.MX Media Driver

[Steve Longerbeam]

Hi Philipp,

I've created a test branch off my imx-media-staging-md-wip called tc358743,
which cherry-picks a couple of your commits from your 
imx-media-staging-md-wip

branch:

[media] tc358743: set entity function to video interface bridge
[media] tc358743: put lanes in STOP state before starting streaming

And one more commit that enables the tc358743 in the DT for sabrelite:

ARM: dts: imx6-sabrelite: switch to tc358743

which is based off your work in imx6qdl-nitrogen6x-bd-hdmi-mipi.dtsi.

With that the tc358743 is loading fine, and is present in the media graph:

root@mx6q:~# dmesg | grep -i tc358
[   11.056799] imx-media: Registered subdev tc358743 1-000f
[   11.122133] imx-media: imx_media_create_link: tc358743 1-000f:0 -> 
imx6-mipi-csi2:0

[   11.490274] tc358743 1-000f: tc358743 found @ 0x1e (21a4000.i2c)


But I'm not able to get to testing streaming yet, see below.


On 01/31/2017 05:54 AM, Philipp Zabel wrote:

Hi Steve,

I have just tested the imx-media-staging-md-wip branch on a Nitrogen6X
with a tc358743 (BD_HDMI_MIPI HDMI to MIPI CSI-2 receiver board). Some
observations:

# Link pipeline
media-ctl -l "'tc358743 1-000f':0->'imx6-mipi-csi2':0[1]"
media-ctl -l "'imx6-mipi-csi2':1->'ipu1_csi0_mux':0[1]"
media-ctl -l "'ipu1_csi0_mux':2->'ipu1_csi0':0[1]"
media-ctl -l "'ipu1_csi0':2->'ipu1_csi0 capture':0[1]"


This works fine, I can create these links.



# Provide an EDID to the HDMI source
v4l2-ctl -d /dev/v4l-subdev2 --set-edid=file=edid-1080p.hex


I can probably generate this Intel hex file myself from sysfs
edid outputs, but for convenience do you mind sending me this
file? I have a 1080p HDMI source I can plug into the tc358743.

The other problem here is that my version of v4l2-ctl, built from
master branch of g...@github.com:gjasny/v4l-utils.git, does not
support taking a subdev node:

root@mx6q:~# v4l2-ctl -d /dev/v4l-subdev15 --get-edid=format=hex
VIDIOC_QUERYCAP: failed: Inappropriate ioctl for device
/dev/v4l-subdev15: not a v4l2 node

Is this something you added yourself, or where can I find this version
of v4l2-ctrl?

Thanks,
Steve


# At this point the HDMI source is enabled and sends a 1080p60 signal
# Configure detected DV timings
media-ctl --set-dv "'tc358743 1-000f':0"

# Set pad formats
media-ctl --set-v4l2 "'tc358743 1-000f':0[fmt:UYVY/1920x1080]"
media-ctl --set-v4l2 "'imx6-mipi-csi2':1[fmt:UYVY2X8/1920x1080]"
media-ctl --set-v4l2 "'ipu1_csi0_mux':2[fmt:UYVY2X8/1920x1080]"
media-ctl --set-v4l2 "'ipu1_csi0':2[fmt:AYUV32/1920x1080]"

v4l2-ctl -d /dev/video4 -V
# This still is configured to 640x480, which is inconsistent with
# the 'ipu1_csi0':2 pad format. The pad set_fmt above should
# have set this, too.

v4l2-ctl --list-formats -d /dev/video4
# This lists all the RGB formats, which it shouldn't. There is
# no CSC in this pipeline, so we should be limited to YUV formats
# only.

# Set capture format
v4l2-ctl -d /dev/video4 -v width=1920,height=1080,pixelformat=UYVY

v4l2-ctl -d /dev/video4 -V
# Now the capture format is correctly configured to 1920x1080.

v4l2-ctl -d 4 --list-frameintervals=width=1920,height=1080,pixelformat=UYVY
# This lists nothing. We should at least provide the 'ipu1_csi0':2 pad
# frame interval. In the future this should list fractions achievable
# via frame skipping.

v4l2-compliance -d /dev/video4
# This fails two tests:
# fail: v4l2-test-input-output.cpp(383): std == 0
# fail: v4l2-test-input-output.cpp(449): invalid attributes for input 0
# test VIDIOC_G/S/ENUMINPUT: FAIL
# and
# fail: v4l2-test-controls.cpp(782): subscribe event for control 'User 
Controls' failed
# test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: FAIL

# (Slowly) stream JPEG images to a display host:
gst-launch-1.0 -v v4l2src device=/dev/video4 ! jpegenc ! rtpjpegpay ! udpsink

I've done this a few times, and sometimes I only get a "ipu1_csi0: EOF
timeout" message when starting streaming.

regards
Philipp

[PATCH v2 1/3] [media] si2157: Add support for Si2141-A10

[Stefan Brüns]

The Si2141 needs two distinct commands for powerup/reset, otherwise it
will not respond to chip revision requests. It also needs a firmware
to run properly.

Signed-off-by: Stefan Brüns 
---
 drivers/media/tuners/si2157.c  | 23 +--
 drivers/media/tuners/si2157_priv.h |  2 ++
 2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c
index 57b250847cd3..e35b1faf0ddc 100644
--- a/drivers/media/tuners/si2157.c
+++ b/drivers/media/tuners/si2157.c
@@ -106,6 +106,9 @@ static int si2157_init(struct dvb_frontend *fe)
if (dev->chiptype == SI2157_CHIPTYPE_SI2146) {
memcpy(cmd.args, "\xc0\x05\x01\x00\x00\x0b\x00\x00\x01", 9);
cmd.wlen = 9;
+   } else if (dev->chiptype == SI2157_CHIPTYPE_SI2141) {
+   memcpy(cmd.args, "\xc0\x00\x0d\x0e\x00\x01\x01\x01\x01\x03", 
10);
+   cmd.wlen = 10;
} else {
memcpy(cmd.args, 
"\xc0\x00\x0c\x00\x00\x01\x01\x01\x01\x01\x01\x02\x00\x00\x01", 15);
cmd.wlen = 15;
@@ -115,6 +118,15 @@ static int si2157_init(struct dvb_frontend *fe)
if (ret)
goto err;
 
+   /* Si2141 needs a second command before it answers the revision query */
+   if (dev->chiptype == SI2157_CHIPTYPE_SI2141) {
+   memcpy(cmd.args, "\xc0\x08\x01\x02\x00\x00\x01", 7);
+   cmd.wlen = 7;
+   ret = si2157_cmd_execute(client, );
+   if (ret)
+   goto err;
+   }
+
/* query chip revision */
memcpy(cmd.args, "\x02", 1);
cmd.wlen = 1;
@@ -131,12 +143,16 @@ static int si2157_init(struct dvb_frontend *fe)
#define SI2157_A30 ('A' << 24 | 57 << 16 | '3' << 8 | '0' << 0)
#define SI2147_A30 ('A' << 24 | 47 << 16 | '3' << 8 | '0' << 0)
#define SI2146_A10 ('A' << 24 | 46 << 16 | '1' << 8 | '0' << 0)
+   #define SI2141_A10 ('A' << 24 | 41 << 16 | '1' << 8 | '0' << 0)
 
switch (chip_id) {
case SI2158_A20:
case SI2148_A20:
fw_name = SI2158_A20_FIRMWARE;
break;
+   case SI2141_A10:
+   fw_name = SI2141_A10_FIRMWARE;
+   break;
case SI2157_A30:
case SI2147_A30:
case SI2146_A10:
@@ -371,7 +387,7 @@ static int si2157_get_if_frequency(struct dvb_frontend *fe, 
u32 *frequency)
 
 static const struct dvb_tuner_ops si2157_ops = {
.info = {
-   .name   = "Silicon Labs Si2146/2147/2148/2157/2158",
+   .name   = "Silicon Labs 
Si2141/Si2146/2147/2148/2157/2158",
.frequency_min  = 4200,
.frequency_max  = 87000,
},
@@ -471,6 +487,7 @@ static int si2157_probe(struct i2c_client *client,
 #endif
 
dev_info(>dev, "Silicon Labs %s successfully attached\n",
+   dev->chiptype == SI2157_CHIPTYPE_SI2141 ?  "Si2141" :
dev->chiptype == SI2157_CHIPTYPE_SI2146 ?
"Si2146" : "Si2147/2148/2157/2158");
 
@@ -508,6 +525,7 @@ static int si2157_remove(struct i2c_client *client)
 static const struct i2c_device_id si2157_id_table[] = {
{"si2157", SI2157_CHIPTYPE_SI2157},
{"si2146", SI2157_CHIPTYPE_SI2146},
+   {"si2141", SI2157_CHIPTYPE_SI2141},
{}
 };
 MODULE_DEVICE_TABLE(i2c, si2157_id_table);
@@ -524,7 +542,8 @@ static struct i2c_driver si2157_driver = {
 
 module_i2c_driver(si2157_driver);
 
-MODULE_DESCRIPTION("Silicon Labs Si2146/2147/2148/2157/2158 silicon tuner 
driver");
+MODULE_DESCRIPTION("Silicon Labs Si2141/Si2146/2147/2148/2157/2158 silicon 
tuner driver");
 MODULE_AUTHOR("Antti Palosaari ");
 MODULE_LICENSE("GPL");
 MODULE_FIRMWARE(SI2158_A20_FIRMWARE);
+MODULE_FIRMWARE(SI2141_A10_FIRMWARE);
diff --git a/drivers/media/tuners/si2157_priv.h 
b/drivers/media/tuners/si2157_priv.h
index d6b2c7b44053..e6436f74abaa 100644
--- a/drivers/media/tuners/si2157_priv.h
+++ b/drivers/media/tuners/si2157_priv.h
@@ -42,6 +42,7 @@ struct si2157_dev {
 
 #define SI2157_CHIPTYPE_SI2157 0
 #define SI2157_CHIPTYPE_SI2146 1
+#define SI2157_CHIPTYPE_SI2141 2
 
 /* firmware command struct */
 #define SI2157_ARGLEN  30
@@ -52,5 +53,6 @@ struct si2157_cmd {
 };
 
 #define SI2158_A20_FIRMWARE "dvb-tuner-si2158-a20-01.fw"
+#define SI2141_A10_FIRMWARE "dvb-tuner-si2141-a10-01.fw"
 
 #endif
-- 
2.11.0

[PATCH v2 3/3] [media] dvbsky: MyGica T230C support

[Stefan Brüns]

Mygica T230 DVB-T/T2/C USB stick support. It uses the same FX2/Si2168
bridge/demodulator combo as the other devices supported by the driver,
but uses the Si2141 tuner.
Several DVB-T (MPEG2) and DVB-T2 (H.265) channels were tested, as well as
the include remote control.

Signed-off-by: Stefan Brüns 
---
v2: add support to the dvbsky driver instead of cxusb, correct RC
model
---
 drivers/media/dvb-core/dvb-usb-ids.h  |  1 +
 drivers/media/usb/dvb-usb-v2/dvbsky.c | 91 +++
 2 files changed, 92 insertions(+)

diff --git a/drivers/media/dvb-core/dvb-usb-ids.h 
b/drivers/media/dvb-core/dvb-usb-ids.h
index a7a4674ccc40..ce4a3d574dd7 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -380,6 +380,7 @@
 #define USB_PID_SONY_PLAYTV0x0003
 #define USB_PID_MYGICA_D6890xd811
 #define USB_PID_MYGICA_T2300xc688
+#define USB_PID_MYGICA_T230C   0xc689
 #define USB_PID_ELGATO_EYETV_DIVERSITY 0x0011
 #define USB_PID_ELGATO_EYETV_DTT   0x0021
 #define USB_PID_ELGATO_EYETV_DTT_2 0x003f
diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c 
b/drivers/media/usb/dvb-usb-v2/dvbsky.c
index 02dbc6c45423..729496e5a52e 100644
--- a/drivers/media/usb/dvb-usb-v2/dvbsky.c
+++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c
@@ -665,6 +665,68 @@ static int dvbsky_t330_attach(struct dvb_usb_adapter *adap)
return ret;
 }
 
+static int dvbsky_mygica_t230c_attach(struct dvb_usb_adapter *adap)
+{
+   struct dvbsky_state *state = adap_to_priv(adap);
+   struct dvb_usb_device *d = adap_to_d(adap);
+   int ret = 0;
+   struct i2c_adapter *i2c_adapter;
+   struct i2c_client *client_demod, *client_tuner;
+   struct i2c_board_info info;
+   struct si2168_config si2168_config;
+   struct si2157_config si2157_config;
+
+   /* attach demod */
+   memset(_config, 0, sizeof(si2168_config));
+   si2168_config.i2c_adapter = _adapter;
+   si2168_config.fe = >fe[0];
+   si2168_config.ts_mode = SI2168_TS_PARALLEL;
+   si2168_config.ts_clock_inv = 1;
+   memset(, 0, sizeof(struct i2c_board_info));
+   strlcpy(info.type, "si2168", I2C_NAME_SIZE);
+   info.addr = 0x64;
+   info.platform_data = _config;
+
+   request_module(info.type);
+   client_demod = i2c_new_device(>i2c_adap, );
+   if (client_demod == NULL ||
+   client_demod->dev.driver == NULL)
+   goto fail_demod_device;
+   if (!try_module_get(client_demod->dev.driver->owner))
+   goto fail_demod_module;
+
+   /* attach tuner */
+   memset(_config, 0, sizeof(si2157_config));
+   si2157_config.fe = adap->fe[0];
+   si2157_config.if_port = 0;
+   memset(, 0, sizeof(struct i2c_board_info));
+   strlcpy(info.type, "si2141", I2C_NAME_SIZE);
+   info.addr = 0x60;
+   info.platform_data = _config;
+
+   request_module("si2157");
+   client_tuner = i2c_new_device(i2c_adapter, );
+   if (client_tuner == NULL ||
+   client_tuner->dev.driver == NULL)
+   goto fail_tuner_device;
+   if (!try_module_get(client_tuner->dev.driver->owner))
+   goto fail_tuner_module;
+
+   state->i2c_client_demod = client_demod;
+   state->i2c_client_tuner = client_tuner;
+   return ret;
+fail_tuner_module:
+   i2c_unregister_device(client_tuner);
+fail_tuner_device:
+   module_put(client_demod->dev.driver->owner);
+fail_demod_module:
+   i2c_unregister_device(client_demod);
+fail_demod_device:
+   ret = -ENODEV;
+   return ret;
+}
+
+
 static int dvbsky_identify_state(struct dvb_usb_device *d, const char **name)
 {
dvbsky_gpio_ctrl(d, 0x04, 1);
@@ -830,6 +892,32 @@ static struct dvb_usb_device_properties dvbsky_t330_props 
= {
}
 };
 
+static struct dvb_usb_device_properties mygica_t230c_props = {
+   .driver_name = KBUILD_MODNAME,
+   .owner = THIS_MODULE,
+   .adapter_nr = adapter_nr,
+   .size_of_priv = sizeof(struct dvbsky_state),
+
+   .generic_bulk_ctrl_endpoint = 0x01,
+   .generic_bulk_ctrl_endpoint_response = 0x81,
+   .generic_bulk_ctrl_delay = DVBSKY_MSG_DELAY,
+
+   .i2c_algo = _i2c_algo,
+   .frontend_attach  = dvbsky_mygica_t230c_attach,
+   .init = dvbsky_init,
+   .get_rc_config= dvbsky_get_rc_config,
+   .streaming_ctrl   = dvbsky_streaming_ctrl,
+   .identify_state   = dvbsky_identify_state,
+   .exit = dvbsky_exit,
+
+   .num_adapters = 1,
+   .adapter = {
+   {
+   .stream = DVB_USB_STREAM_BULK(0x82, 8, 4096),
+   }
+   }
+};
+
 static const struct usb_device_id dvbsky_id_table[] = {
{ DVB_USB_DEVICE(0x0572, 0x6831,

[PATCH v2 2/3] [media] si2168: add support for Si2168-D60

[Stefan Brüns]

Add handling for new revision, requiring new firmware.

Signed-off-by: Stefan Brüns 
---
 drivers/media/dvb-frontends/si2168.c  | 4 
 drivers/media/dvb-frontends/si2168_priv.h | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/drivers/media/dvb-frontends/si2168.c 
b/drivers/media/dvb-frontends/si2168.c
index 20b4a659e2e4..28f3bbe0af25 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -674,6 +674,9 @@ static int si2168_probe(struct i2c_client *client,
case SI2168_CHIP_ID_B40:
dev->firmware_name = SI2168_B40_FIRMWARE;
break;
+   case SI2168_CHIP_ID_D60:
+   dev->firmware_name = SI2168_D60_FIRMWARE;
+   break;
default:
dev_dbg(>dev, "unknown chip version Si21%d-%c%c%c\n",
cmd.args[2], cmd.args[1], cmd.args[3], cmd.args[4]);
@@ -761,3 +764,4 @@ MODULE_LICENSE("GPL");
 MODULE_FIRMWARE(SI2168_A20_FIRMWARE);
 MODULE_FIRMWARE(SI2168_A30_FIRMWARE);
 MODULE_FIRMWARE(SI2168_B40_FIRMWARE);
+MODULE_FIRMWARE(SI2168_D60_FIRMWARE);
diff --git a/drivers/media/dvb-frontends/si2168_priv.h 
b/drivers/media/dvb-frontends/si2168_priv.h
index 7843ccb448a0..4baa95b7d648 100644
--- a/drivers/media/dvb-frontends/si2168_priv.h
+++ b/drivers/media/dvb-frontends/si2168_priv.h
@@ -25,6 +25,7 @@
 #define SI2168_A20_FIRMWARE "dvb-demod-si2168-a20-01.fw"
 #define SI2168_A30_FIRMWARE "dvb-demod-si2168-a30-01.fw"
 #define SI2168_B40_FIRMWARE "dvb-demod-si2168-b40-01.fw"
+#define SI2168_D60_FIRMWARE "dvb-demod-si2168-d60-01.fw"
 #define SI2168_B40_FIRMWARE_FALLBACK "dvb-demod-si2168-02.fw"
 
 /* state struct */
@@ -37,6 +38,7 @@ struct si2168_dev {
#define SI2168_CHIP_ID_A20 ('A' << 24 | 68 << 16 | '2' << 8 | '0' << 0)
#define SI2168_CHIP_ID_A30 ('A' << 24 | 68 << 16 | '3' << 8 | '0' << 0)
#define SI2168_CHIP_ID_B40 ('B' << 24 | 68 << 16 | '4' << 8 | '0' << 0)
+   #define SI2168_CHIP_ID_D60 ('D' << 24 | 68 << 16 | '6' << 8 | '0' << 0)
unsigned int chip_id;
unsigned int version;
const char *firmware_name;
-- 
2.11.0

[PATCH v2 0/3] Add support for MyGica T230C DVB-T2 stick

[Stefan Brüns]

The required command sequence for the new tuner (Si2141) was traced from the
current Windows driver and verified with a small python script/libusb.
The changes to the Si2168 and dvbsky driver are mostly additions of the
required IDs and some glue code.

Stefan Brüns (3):
  [media] si2157: Add support for Si2141-A10
  [media] si2168: add support for Si2168-D60
  [media] dvbsky: MyGica T230C support

 drivers/media/dvb-core/dvb-usb-ids.h  |  1 +
 drivers/media/dvb-frontends/si2168.c  |  4 ++
 drivers/media/dvb-frontends/si2168_priv.h |  2 +
 drivers/media/tuners/si2157.c | 23 +++-
 drivers/media/tuners/si2157_priv.h|  2 +
 drivers/media/usb/dvb-usb-v2/dvbsky.c | 91 +++
 6 files changed, 121 insertions(+), 2 deletions(-)

-- 
2.11.0

[PATCH 1/1] hdpvr: code cleanup

[Jonathan Sims]

This is a code cleanup after recent changes introduced by commit 
a503ff812430e104f591287b512aa4e3a83f20b1.

Signed-off-by: Jonathan Sims 
---

 drivers/media/usb/hdpvr/hdpvr-video.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/media/usb/hdpvr/hdpvr-video.c 
b/drivers/media/usb/hdpvr/hdpvr-video.c
index 7fb036d6a86e..b2ce5c0807fb 100644
--- a/drivers/media/usb/hdpvr/hdpvr-video.c
+++ b/drivers/media/usb/hdpvr/hdpvr-video.c
@@ -449,7 +449,7 @@ static ssize_t hdpvr_read(struct file *file, char __user 
*buffer, size_t count,
 
if (buf->status != BUFSTAT_READY &&
dev->status != STATUS_DISCONNECTED) {
-   int err;
+
/* return nonblocking */
if (file->f_flags & O_NONBLOCK) {
if (!ret)
@@ -457,23 +457,19 @@ static ssize_t hdpvr_read(struct file *file, char
__user *buffer, size_t count, goto err;
}
 
-   err =
wait_event_interruptible_timeout(dev->wait_data,
+   ret =
wait_event_interruptible_timeout(dev->wait_data, buf->status ==
BUFSTAT_READY, msecs_to_jiffies(1000));
-   if (err < 0) {
-   ret = err;
+   if (ret < 0)
goto err;
-   }
-   if (!err) {
+   if (!ret) {
v4l2_dbg(MSG_INFO, hdpvr_debug,
>v4l2_dev, "timeout: restart streaming\n");
hdpvr_stop_streaming(dev);
-   msecs_to_jiffies(4000);
-   err = hdpvr_start_streaming(dev);
-   if (err) {
-   ret = err;
+   msleep(4000);
+   ret = hdpvr_start_streaming(dev);
+   if (ret)
goto err;
-   }
}
}
 
-- 
2.11.1

Re: [PATCH v3 1/2] v4l: Add camera voice coil lens control class, current control

[Pavel Machek]

On Tue 2017-02-14 14:20:22, Sakari Ailus wrote:
> Add a V4L2 control class for voice coil lens driver devices. These are
> simple devices that are used to move a camera lens from its resting
> position.
> 
> Signed-off-by: Sakari Ailus 

Looks good to me.

I wonder... should we somehow expose the range of diopters to
userspace? I believe userland camera application will need that
information.

Thanks,
Pavel

> ---
>  Documentation/media/uapi/v4l/extended-controls.rst | 28 
> ++
>  include/uapi/linux/v4l2-controls.h |  8 +++
>  2 files changed, 36 insertions(+)
> 
> diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
> b/Documentation/media/uapi/v4l/extended-controls.rst
> index abb1057..a75451a 100644
> --- a/Documentation/media/uapi/v4l/extended-controls.rst
> +++ b/Documentation/media/uapi/v4l/extended-controls.rst
> @@ -3022,6 +3022,34 @@ Image Process Control IDs
>  driver specific and are documented in :ref:`v4l-drivers`.
>  
>  
> +.. _voice-coil-lens-controls:
> +
> +Voice Coil Lens Control Reference
> +=
> +
> +The Voice Coil class controls are used to control voice coil lens
> +devices. These are very simple devices that consist of a voice coil, a
> +spring and a lens. The current applied on the voice coil is used to
> +move the lens away from the resting position which typically is (close
> +to) infinity. The higher the current applied, the closer the lens is
> +typically focused.
> +
> +.. _voice-coil-lens-control-is:
> +
> +Voice Coil Lens Control IDs
> +---
> +
> +``V4L2_CID_VOICE_COIL_CLASS (class)``
> +The VOICE_COIL class descriptor.
> +
> +``V4L2_CID_VOICE_COIL_CURRENT (integer)``
> +Current applied on a voice coil. The more current is applied, the
> +more is the position of the lens moved from its resting position.
> +Do note that there may be a ringing effect; the lens will
> +oscillate after changing the current applied unless the device
> +implements ringing compensation.
> +
> +
>  .. _dv-controls:
>  
>  Digital Video Control Reference
> diff --git a/include/uapi/linux/v4l2-controls.h 
> b/include/uapi/linux/v4l2-controls.h
> index 0d2e1e0..9ef152b 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -62,6 +62,7 @@
>  #define V4L2_CTRL_CLASS_FM_RX0x00a1  /* FM Receiver 
> controls */
>  #define V4L2_CTRL_CLASS_RF_TUNER 0x00a2  /* RF tuner controls */
>  #define V4L2_CTRL_CLASS_DETECT   0x00a3  /* Detection 
> controls */
> +#define V4L2_CTRL_CLASS_VOICE_COIL   0x00a4  /* Voice coil lens 
> driver controls */
>  
>  /* User-class control IDs */
>  
> @@ -894,6 +895,13 @@ enum v4l2_jpeg_chroma_subsampling {
>  #define V4L2_CID_TEST_PATTERN
> (V4L2_CID_IMAGE_PROC_CLASS_BASE + 3)
>  #define V4L2_CID_DEINTERLACING_MODE  (V4L2_CID_IMAGE_PROC_CLASS_BASE 
> + 4)
>  
> +/* Voice coil lens driver controls */
> +
> +#define V4L2_CID_VOICE_COIL_CLASS_BASE   
> (V4L2_CTRL_CLASS_VOICE_COIL | 0x900)
> +#define V4L2_CID_VOICE_COIL_CLASS(V4L2_CTRL_CLASS_VOICE_COIL | 1)
> +
> +#define V4L2_CID_VOICE_COIL_CURRENT  (V4L2_CID_VOICE_COIL_CLASS_BASE 
> + 1)
> +
>  
>  /*  DV-class control IDs defined by V4L2 */
>  #define V4L2_CID_DV_CLASS_BASE   (V4L2_CTRL_CLASS_DV | 
> 0x900)

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[PATCH 4/4] v4l: split lane parsing code

[Pavel Machek]

From: Sakari Ailus 

The function to parse CSI2 bus parameters was called
v4l2_of_parse_csi_bus(), rename it as v4l2_of_parse_csi2_bus() in
anticipation of CSI1/CCP2 support.

Obtain data bus type from bus-type property. Only try parsing bus
specific properties in this case.

Separate lane parsing from CSI-2 bus parameter parsing. The CSI-1 will
need these as well, separate them into a different
function. have_clk_lane and num_data_lanes arguments may be NULL; the
CSI-1 bus will have no use for them.

Add support for parsing of CSI-1 and CCP2 bus related properties
documented in video-interfaces.txt.

Signed-off-by: Sakari Ailus 
Signed-off-by: Ivaylo Dimitrov 
Signed-off-by: Pavel Machek 
---
 drivers/media/v4l2-core/v4l2-of.c | 138 ++
 1 file changed, 111 insertions(+), 27 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-of.c 
b/drivers/media/v4l2-core/v4l2-of.c
index 4f59f44..85629de 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -20,64 +20,103 @@
 
 #include 
 
-static int v4l2_of_parse_csi_bus(const struct device_node *node,
-struct v4l2_of_endpoint *endpoint)
+/* This has to match values in the device tree. */
+
+enum v4l2_of_bus_type {
+   V4L2_OF_BUS_TYPE_GUESS = 0, /* CSI-2 D-PHY, parallel or Bt.656 */
+   V4L2_OF_BUS_TYPE_CSI2_CPHY,
+   V4L2_OF_BUS_TYPE_CSI1,
+   V4L2_OF_BUS_TYPE_CCP2,
+};
+
+static int v4l2_of_parse_lanes(const struct device_node *node,
+  unsigned char *clock_lane,
+  bool *have_clk_lane,
+  unsigned char *data_lanes,
+  bool *lane_polarities,
+  unsigned short *__num_data_lanes,
+  unsigned int max_data_lanes)
 {
-   struct v4l2_of_bus_mipi_csi2 *bus = >bus.mipi_csi2;
struct property *prop;
-   bool have_clk_lane = false;
-   unsigned int flags = 0, lanes_used = 0;
+   unsigned int lanes_used = 0;
+   short num_data_lanes = 0;
u32 v;
 
prop = of_find_property(node, "data-lanes", NULL);
if (prop) {
const __be32 *lane = NULL;
-   unsigned int i;
 
-   for (i = 0; i < ARRAY_SIZE(bus->data_lanes); i++) {
+   for (num_data_lanes = 0; num_data_lanes < max_data_lanes;
+num_data_lanes++) {
lane = of_prop_next_u32(prop, lane, );
if (!lane)
break;
+   data_lanes[num_data_lanes] = v;
 
if (lanes_used & BIT(v))
pr_warn("%s: duplicated lane %u in 
data-lanes\n",
node->full_name, v);
lanes_used |= BIT(v);
-
-   bus->data_lanes[i] = v;
}
-   bus->num_data_lanes = i;
}
+   if (__num_data_lanes)
+   *__num_data_lanes = num_data_lanes;
 
prop = of_find_property(node, "lane-polarities", NULL);
if (prop) {
const __be32 *polarity = NULL;
unsigned int i;
 
-   for (i = 0; i < ARRAY_SIZE(bus->lane_polarities); i++) {
+   for (i = 0; i < 1 + max_data_lanes; i++) {
polarity = of_prop_next_u32(prop, polarity, );
if (!polarity)
break;
-   bus->lane_polarities[i] = v;
+   lane_polarities[i] = v;
}
 
-   if (i < 1 + bus->num_data_lanes /* clock + data */) {
+   if (i < 1 + num_data_lanes /* clock + data */) {
pr_warn("%s: too few lane-polarities entries (need %u, 
got %u)\n",
-   node->full_name, 1 + bus->num_data_lanes, i);
+   node->full_name, 1 + num_data_lanes, i);
return -EINVAL;
}
}
 
+   if (have_clk_lane)
+   *have_clk_lane = false;
+
if (!of_property_read_u32(node, "clock-lanes", )) {
+   *clock_lane = v;
+   if (have_clk_lane)
+   *have_clk_lane = true;
+
if (lanes_used & BIT(v))
pr_warn("%s: duplicated lane %u in clock-lanes\n",
node->full_name, v);
lanes_used |= BIT(v);
-
-   bus->clock_lane = v;
-   have_clk_lane = true;
}
 
+   return 0;
+}
+
+static int v4l2_of_parse_csi2_bus(const struct device_node *node,
+struct v4l2_of_endpoint *endpoint)
+{
+   struct v4l2_of_bus_mipi_csi2 *bus = >bus.mipi_csi2;
+   bool 

[PATCH 3/4] smiapp: add CCP2 support

[Pavel Machek]

Add support for CCP2 connected SMIA sensors as found
on the Nokia N900.

Signed-off-by: Sebastian Reichel 
Signed-off-by: Ivaylo Dimitrov 
Signed-off-by: Pavel Machek 
---
 drivers/media/i2c/smiapp/smiapp-core.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
b/drivers/media/i2c/smiapp/smiapp-core.c
index f4e92bd..212293f 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -2807,13 +2807,19 @@ static struct smiapp_hwconfig 
*smiapp_get_hwconfig(struct device *dev)
switch (bus_cfg->bus_type) {
case V4L2_MBUS_CSI2:
hwcfg->csi_signalling_mode = SMIAPP_CSI_SIGNALLING_MODE_CSI2;
+   hwcfg->lanes = bus_cfg->bus.mipi_csi2.num_data_lanes;
+   break;
+   case V4L2_MBUS_CCP2:
+   hwcfg->csi_signalling_mode = (bus_cfg->bus.mipi_csi1.strobe) ?
+   SMIAPP_CSI_SIGNALLING_MODE_CCP2_DATA_STROBE :
+   SMIAPP_CSI_SIGNALLING_MODE_CCP2_DATA_CLOCK;
+   hwcfg->lanes = 1;
break;
-   /* FIXME: add CCP2 support. */
default:
+   dev_err(dev, "unknown bus protocol\n");
goto out_err;
}
 
-   hwcfg->lanes = bus_cfg->bus.mipi_csi2.num_data_lanes;
dev_dbg(dev, "lanes %u\n", hwcfg->lanes);
 
/* NVM size is not mandatory */
@@ -2827,8 +2833,8 @@ static struct smiapp_hwconfig *smiapp_get_hwconfig(struct 
device *dev)
goto out_err;
}
 
-   dev_dbg(dev, "nvm %d, clk %d, csi %d\n", hwcfg->nvm_size,
-   hwcfg->ext_clk, hwcfg->csi_signalling_mode);
+   dev_dbg(dev, "nvm %d, clk %d, mode %d\n",
+   hwcfg->nvm_size, hwcfg->ext_clk, hwcfg->csi_signalling_mode);
 
if (!bus_cfg->nr_of_link_frequencies) {
dev_warn(dev, "no link frequencies defined\n");
-- 
2.1.4


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[PATCH 1/4] v4l2: device_register_subdev_nodes: allow calling multiple times

[Pavel Machek]

From: Sebastian Reichel 

If v4l2_device_register_subdev_nodes() is called multiple times, it is
better to return early than corrupt memory.

Without this, exposure / gain controls do not work in the camera
application on N900.

Signed-off-by: Sebastian Reichel 
Signed-off-by: Ivaylo Dimitrov 
Signed-off-by: Pavel Machek 
---
 drivers/media/v4l2-core/v4l2-device.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-device.c 
b/drivers/media/v4l2-core/v4l2-device.c
index f364cc1..937c6de 100644
--- a/drivers/media/v4l2-core/v4l2-device.c
+++ b/drivers/media/v4l2-core/v4l2-device.c
@@ -235,6 +235,9 @@ int v4l2_device_register_subdev_nodes(struct v4l2_device 
*v4l2_dev)
if (!(sd->flags & V4L2_SUBDEV_FL_HAS_DEVNODE))
continue;
 
+   if (sd->devnode)
+   continue;
+
vdev = kzalloc(sizeof(*vdev), GFP_KERNEL);
if (!vdev) {
err = -ENOMEM;
-- 
2.1.4


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[PATCH 2/4] Core changes for CCP2/CSI1 support.

[Pavel Machek]

From: Sakari Ailus 

CCP2, or CSI-1, is an older single data lane serial bus. Add core
support neccessary for it.

Signed-off-by: Sakari Ailus 
Signed-off-by: Ivaylo Dimitrov 
Signed-off-by: Pavel Machek 
---
 include/media/v4l2-mediabus.h |  4 
 include/media/v4l2-of.h   | 17 +
 2 files changed, 21 insertions(+)

diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h
index 34cc99e..315c167 100644
--- a/include/media/v4l2-mediabus.h
+++ b/include/media/v4l2-mediabus.h
@@ -69,11 +69,15 @@
  * @V4L2_MBUS_PARALLEL:parallel interface with hsync and vsync
  * @V4L2_MBUS_BT656:   parallel interface with embedded synchronisation, can
  * also be used for BT.1120
+ * @V4L2_MBUS_CSI1:MIPI CSI-1 serial interface
+ * @V4L2_MBUS_CCP2:CCP2 (Compact Camera Port 2)
  * @V4L2_MBUS_CSI2:MIPI CSI-2 serial interface
  */
 enum v4l2_mbus_type {
V4L2_MBUS_PARALLEL,
V4L2_MBUS_BT656,
+   V4L2_MBUS_CSI1,
+   V4L2_MBUS_CCP2,
V4L2_MBUS_CSI2,
 };
 
diff --git a/include/media/v4l2-of.h b/include/media/v4l2-of.h
index 4dc34b2..63a52ee 100644
--- a/include/media/v4l2-of.h
+++ b/include/media/v4l2-of.h
@@ -53,6 +53,22 @@ struct v4l2_of_bus_parallel {
 };
 
 /**
+ * struct v4l2_of_bus_csi1 - CSI-1/CCP2 data bus structure
+ * @clock_inv: polarity of clock/strobe signal
+ *false - not inverted, true - inverted
+ * @strobe: false - data/clock, true - data/strobe
+ * @data_lane: the number of the data lane
+ * @clock_lane: the number of the clock lane
+ */
+struct v4l2_of_bus_mipi_csi1 {
+   bool clock_inv;
+   bool strobe;
+   bool lane_polarity[2];
+   unsigned char data_lane;
+   unsigned char clock_lane;
+};
+
+/**
  * struct v4l2_of_endpoint - the endpoint data structure
  * @base: struct of_endpoint containing port, id, and local of_node
  * @bus_type: bus type
@@ -66,6 +82,7 @@ struct v4l2_of_endpoint {
enum v4l2_mbus_type bus_type;
union {
struct v4l2_of_bus_parallel parallel;
+   struct v4l2_of_bus_mipi_csi1 mipi_csi1;
struct v4l2_of_bus_mipi_csi2 mipi_csi2;
} bus;
u64 *link_frequencies;
-- 
2.1.4


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [RFC 03/13] v4l: split lane parsing code

[Pavel Machek]

Hi!

> On Tue, Feb 14, 2017 at 02:39:41PM +0100, Pavel Machek wrote:
> > From: Sakari Ailus 
> > 
> > The function to parse CSI2 bus parameters was called
> > v4l2_of_parse_csi_bus(), rename it as v4l2_of_parse_csi2_bus() in
> > anticipation of CSI1/CCP2 support.
> > 
> > Obtain data bus type from bus-type property. Only try parsing bus
> > specific properties in this case.
> > 
> > Separate lane parsing from CSI-2 bus parameter parsing. The CSI-1 will
> > need these as well, separate them into a different
> > function. have_clk_lane and num_data_lanes arguments may be NULL; the
> > CSI-1 bus will have no use for them.
> > 
> > Add support for parsing of CSI-1 and CCP2 bus related properties
> > documented in video-interfaces.txt.
> 
> One more thing: this conflicts badly with the V4L2 fwnode patchset.
> 
> Assuming things go well and that can be merged somewhat soonish, can I take
> this and rebase it on the fwnode set? The two first patches in the set look
> pretty good to me.

Actually, I'd say that first four patches should be ready. Feel free
to take them/rebase them/etc. I can then continue working on the
rest

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [RFC 07/13] v4l2: device_register_subdev_nodes: allow calling multiple times

[Pavel Machek]

On Wed 2017-02-15 00:02:57, Sakari Ailus wrote:
> Hi Pavel and Sebastian,
> 
> On Tue, Feb 14, 2017 at 02:40:00PM +0100, Pavel Machek wrote:
> > From: Sebastian Reichel 
> > 
> > Without this, exposure / gain controls do not work in the camera 
> > application.
> 
> :-)
> 
> > 
> > Signed-off-by: Sebastian Reichel 
> > Signed-off-by: Ivaylo Dimitrov 
> > Signed-off-by: Pavel Machek 
> > ---
> >  drivers/media/v4l2-core/v4l2-device.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-device.c 
> > b/drivers/media/v4l2-core/v4l2-device.c
> > index f364cc1..b3afbe8 100644
> > --- a/drivers/media/v4l2-core/v4l2-device.c
> > +++ b/drivers/media/v4l2-core/v4l2-device.c
> > @@ -235,6 +235,9 @@ int v4l2_device_register_subdev_nodes(struct 
> > v4l2_device *v4l2_dev)
> > if (!(sd->flags & V4L2_SUBDEV_FL_HAS_DEVNODE))
> > continue;
> >  
> > +   if(sd->devnode)
> > +   continue;
> 
> This has been recognised as a problem but you're the first to submit a patch
> I believe. Please add an appropriate description. :-)

Ugh. Will try :-).

> s/if\(/if (/
> 
> I think this one should go in before the rest.

Easy enough, and I'll move it to the first in the series.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [RFC 03/13] v4l: split lane parsing code

[Pavel Machek]

Hi!

> And you can remove CSI2 and PARALLEL cases.

Ok, that's all easy enough.

Thanks,
Pavel


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [RFC 08/13] smiapp-pll: Take existing divisor into account in minimum divisor check

[Laurent Pinchart]

Hi Sakari,

On Wednesday 15 Feb 2017 00:05:03 Sakari Ailus wrote:
> On Tue, Feb 14, 2017 at 02:40:04PM +0100, Pavel Machek wrote:
> > From: Sakari Ailus 
> > 
> > Required added multiplier (and divisor) calculation did not take into
> > account the existing divisor when checking the values against the
> > minimum divisor. Do just that.
> > 
> > Signed-off-by: Sakari Ailus 
> > Signed-off-by: Ivaylo Dimitrov 
> > Signed-off-by: Pavel Machek 
> 
> I need to understand again why did I write this patch. :-)

I was about to mention that a more detailed commit message (or possibly event 
comments in the source code) would be good :-)

> Could you send me the smiapp driver output with debug level messages
> enabled, please?
> 
> I think the problem was with the secondary sensor.
>
> > diff --git a/drivers/media/i2c/smiapp-pll.c
> > b/drivers/media/i2c/smiapp-pll.c
> > index 771db56..166bbaf 100644
> > --- a/drivers/media/i2c/smiapp-pll.c
> > +++ b/drivers/media/i2c/smiapp-pll.c
> > @@ -16,6 +16,8 @@
> >   * General Public License for more details.
> >   */
> > 
> > +#define DEBUG
> > +

This should be removed.

> >  #include 
> >  #include 
> >  #include 
> > @@ -227,7 +229,8 @@ static int __smiapp_pll_calculate(
> > more_mul_factor = lcm(div, pll->pre_pll_clk_div) / div;
> > dev_dbg(dev, "more_mul_factor: %u\n", more_mul_factor);
> > 
> > -   more_mul_factor = lcm(more_mul_factor, op_limits->min_sys_clk_div);
> > +   more_mul_factor = lcm(more_mul_factor,
> > + DIV_ROUND_UP(op_limits->min_sys_clk_div, div));
> > dev_dbg(dev, "more_mul_factor: min_op_sys_clk_div: %d\n",
> > more_mul_factor);
> > i = roundup(more_mul_min, more_mul_factor);
> > @@ -456,6 +459,10 @@ int smiapp_pll_calculate(struct device *dev,
> > i = gcd(pll->pll_op_clk_freq_hz, pll->ext_clk_freq_hz);
> > mul = div_u64(pll->pll_op_clk_freq_hz, i);
> > div = pll->ext_clk_freq_hz / i;
> > +   if (!mul) {
> > +   dev_err(dev, "forcing mul to 1\n");
> > +   mul = 1;
> > +   }
> > dev_dbg(dev, "mul %u / div %u\n", mul, div);
> > 
> > min_pre_pll_clk_div =
-- 
Regards,

Laurent Pinchart

Re: [RFC 07/13] v4l2: device_register_subdev_nodes: allow calling multiple times

[Sakari Ailus]

Hi Laurent,

On Wed, Feb 15, 2017 at 12:06:17AM +0200, Laurent Pinchart wrote:
> Hi Sakari,
> 
> On Wednesday 15 Feb 2017 00:02:57 Sakari Ailus wrote:
> > On Tue, Feb 14, 2017 at 02:40:00PM +0100, Pavel Machek wrote:
> > > From: Sebastian Reichel 
> > > 
> > > Without this, exposure / gain controls do not work in the camera
> > > application.:
> > :-)
> > :
> > > Signed-off-by: Sebastian Reichel 
> > > Signed-off-by: Ivaylo Dimitrov 
> > > Signed-off-by: Pavel Machek 
> > > ---
> > > 
> > >  drivers/media/v4l2-core/v4l2-device.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > > 
> > > diff --git a/drivers/media/v4l2-core/v4l2-device.c
> > > b/drivers/media/v4l2-core/v4l2-device.c index f364cc1..b3afbe8 100644
> > > --- a/drivers/media/v4l2-core/v4l2-device.c
> > > +++ b/drivers/media/v4l2-core/v4l2-device.c
> > > @@ -235,6 +235,9 @@ int v4l2_device_register_subdev_nodes(struct
> > > v4l2_device *v4l2_dev)
> > >   if (!(sd->flags & V4L2_SUBDEV_FL_HAS_DEVNODE))
> > >   continue;
> > > 
> > > + if(sd->devnode)
> > > + continue;
> > 
> > This has been recognised as a problem but you're the first to submit a patch
> > I believe. Please add an appropriate description. :-)
> > 
> > s/if\(/if (/
> > 
> > I think this one should go in before the rest.
> 
> But how can this happen ? Is v4l2_device_register_subdev_nodes() called 
> multiple times ? Do we want to allow that ?

A driver could do this even accidentally. It's much better to do the right
thing than to start corrupting system memory sooner or later.

In the future we'll need to be able to dynamically register device nodes
after the registration of the original device nodes in a media device has
completed anyway. I don't think this would be the means for that though.

What happens here though is that both the video bus switch and isp notifiers
completing will call the function, thus ending up trying to register many of
the nodes twice. Philipp had a different approach to the problem ---
postponing the complete until add the sub-devices have been bound. The patch
is called "v4l2-async: allow subdevices to add further subdevices to the
notifier waiting list".

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [RFC 07/13] v4l2: device_register_subdev_nodes: allow calling multiple times

[Laurent Pinchart]

Hi Sakari,

On Wednesday 15 Feb 2017 00:02:57 Sakari Ailus wrote:
> On Tue, Feb 14, 2017 at 02:40:00PM +0100, Pavel Machek wrote:
> > From: Sebastian Reichel 
> > 
> > Without this, exposure / gain controls do not work in the camera
> > application.:
> :-)
> :
> > Signed-off-by: Sebastian Reichel 
> > Signed-off-by: Ivaylo Dimitrov 
> > Signed-off-by: Pavel Machek 
> > ---
> > 
> >  drivers/media/v4l2-core/v4l2-device.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-device.c
> > b/drivers/media/v4l2-core/v4l2-device.c index f364cc1..b3afbe8 100644
> > --- a/drivers/media/v4l2-core/v4l2-device.c
> > +++ b/drivers/media/v4l2-core/v4l2-device.c
> > @@ -235,6 +235,9 @@ int v4l2_device_register_subdev_nodes(struct
> > v4l2_device *v4l2_dev)
> > if (!(sd->flags & V4L2_SUBDEV_FL_HAS_DEVNODE))
> > continue;
> > 
> > +   if(sd->devnode)
> > +   continue;
> 
> This has been recognised as a problem but you're the first to submit a patch
> I believe. Please add an appropriate description. :-)
> 
> s/if\(/if (/
> 
> I think this one should go in before the rest.

But how can this happen ? Is v4l2_device_register_subdev_nodes() called 
multiple times ? Do we want to allow that ?

> > +
> > vdev = kzalloc(sizeof(*vdev), GFP_KERNEL);
> > if (!vdev) {
> > err = -ENOMEM;

-- 
Regards,

Laurent Pinchart

Re: [RFC 08/13] smiapp-pll: Take existing divisor into account in minimum divisor check

[Sakari Ailus]

Hi Pavel,

On Tue, Feb 14, 2017 at 02:40:04PM +0100, Pavel Machek wrote:
> From: Sakari Ailus 
> 
> Required added multiplier (and divisor) calculation did not take into
> account the existing divisor when checking the values against the
> minimum divisor. Do just that.
> 
> Signed-off-by: Sakari Ailus 
> Signed-off-by: Ivaylo Dimitrov 
> Signed-off-by: Pavel Machek 

I need to understand again why did I write this patch. :-)

Could you send me the smiapp driver output with debug level messages
enabled, please?

I think the problem was with the secondary sensor.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [RFC 07/13] v4l2: device_register_subdev_nodes: allow calling multiple times

[Sakari Ailus]

Hi Pavel and Sebastian,

On Tue, Feb 14, 2017 at 02:40:00PM +0100, Pavel Machek wrote:
> From: Sebastian Reichel 
> 
> Without this, exposure / gain controls do not work in the camera application.

:-)

> 
> Signed-off-by: Sebastian Reichel 
> Signed-off-by: Ivaylo Dimitrov 
> Signed-off-by: Pavel Machek 
> ---
>  drivers/media/v4l2-core/v4l2-device.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-device.c 
> b/drivers/media/v4l2-core/v4l2-device.c
> index f364cc1..b3afbe8 100644
> --- a/drivers/media/v4l2-core/v4l2-device.c
> +++ b/drivers/media/v4l2-core/v4l2-device.c
> @@ -235,6 +235,9 @@ int v4l2_device_register_subdev_nodes(struct v4l2_device 
> *v4l2_dev)
>   if (!(sd->flags & V4L2_SUBDEV_FL_HAS_DEVNODE))
>   continue;
>  
> + if(sd->devnode)
> + continue;

This has been recognised as a problem but you're the first to submit a patch
I believe. Please add an appropriate description. :-)

s/if\(/if (/

I think this one should go in before the rest.

> +
>   vdev = kzalloc(sizeof(*vdev), GFP_KERNEL);
>   if (!vdev) {
>   err = -ENOMEM;

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [RFC 06/13] v4l2-async: per notifier locking

[Sakari Ailus]

Hi Pavel and Sebastian,

On Tue, Feb 14, 2017 at 02:39:56PM +0100, Pavel Machek wrote:
> From: Sebastian Reichel 
> 
> Without this, camera support breaks boot on N900.
> 
> Signed-off-by: Ivaylo Dimitrov 
> ---
>  drivers/media/v4l2-core/v4l2-async.c | 54 
> ++--
>  include/media/v4l2-async.h   |  2 ++
>  2 files changed, 29 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> b/drivers/media/v4l2-core/v4l2-async.c
> index 96cc733..26492a2 100644
> --- a/drivers/media/v4l2-core/v4l2-async.c
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -57,7 +57,6 @@ static bool match_custom(struct v4l2_subdev *sd, struct 
> v4l2_async_subdev *asd)
>  
>  static LIST_HEAD(subdev_list);
>  static LIST_HEAD(notifier_list);
> -static DEFINE_MUTEX(list_lock);
>  
>  static struct v4l2_async_subdev *v4l2_async_belongs(struct 
> v4l2_async_notifier *notifier,
>   struct v4l2_subdev *sd)
> @@ -102,12 +101,15 @@ static int v4l2_async_test_notify(struct 
> v4l2_async_notifier *notifier,
>  
>   if (notifier->bound) {
>   ret = notifier->bound(notifier, sd, asd);
> - if (ret < 0)
> + if (ret < 0) {
> + dev_warn(notifier->v4l2_dev->dev, "subdev bound 
> failed\n");
>   return ret;
> + }
>   }
>  
>   ret = v4l2_device_register_subdev(notifier->v4l2_dev, sd);
>   if (ret < 0) {
> + dev_warn(notifier->v4l2_dev->dev, "subdev register failed\n");
>   if (notifier->unbind)
>   notifier->unbind(notifier, sd, asd);
>   return ret;
> @@ -141,7 +143,7 @@ int v4l2_async_notifier_register(struct v4l2_device 
> *v4l2_dev,
>  {
>   struct v4l2_subdev *sd, *tmp;
>   struct v4l2_async_subdev *asd;
> - int i;
> + int ret = 0, i;
>  
>   if (!notifier->num_subdevs || notifier->num_subdevs > V4L2_MAX_SUBDEVS)
>   return -EINVAL;
> @@ -149,6 +151,7 @@ int v4l2_async_notifier_register(struct v4l2_device 
> *v4l2_dev,
>   notifier->v4l2_dev = v4l2_dev;
>   INIT_LIST_HEAD(>waiting);
>   INIT_LIST_HEAD(>done);
> + mutex_init(>lock);
>  
>   for (i = 0; i < notifier->num_subdevs; i++) {
>   asd = notifier->subdevs[i];
> @@ -168,28 +171,22 @@ int v4l2_async_notifier_register(struct v4l2_device 
> *v4l2_dev,
>   list_add_tail(>list, >waiting);
>   }
>  
> - mutex_lock(_lock);
> + /* Keep also completed notifiers on the list */
> + list_add(>list, _list);
> + mutex_lock(>lock);
>  
>   list_for_each_entry_safe(sd, tmp, _list, async_list) {
> - int ret;
> -
>   asd = v4l2_async_belongs(notifier, sd);
>   if (!asd)
>   continue;
>  
>   ret = v4l2_async_test_notify(notifier, sd, asd);
> - if (ret < 0) {
> - mutex_unlock(_lock);
> - return ret;
> - }
> + if (ret < 0)
> + break;
>   }
> + mutex_unlock(>lock);
>  
> - /* Keep also completed notifiers on the list */
> - list_add(>list, _list);
> -
> - mutex_unlock(_lock);
> -
> - return 0;
> + return ret;
>  }
>  EXPORT_SYMBOL(v4l2_async_notifier_register);
>  
> @@ -210,7 +207,7 @@ void v4l2_async_notifier_unregister(struct 
> v4l2_async_notifier *notifier)
>   "Failed to allocate device cache!\n");
>   }
>  
> - mutex_lock(_lock);
> + mutex_lock(>lock);
>  
>   list_del(>list);
>  
> @@ -237,7 +234,7 @@ void v4l2_async_notifier_unregister(struct 
> v4l2_async_notifier *notifier)
>   put_device(d);
>   }
>  
> - mutex_unlock(_lock);
> + mutex_unlock(>lock);
>  
>   /*
>* Call device_attach() to reprobe devices
> @@ -262,6 +259,7 @@ void v4l2_async_notifier_unregister(struct 
> v4l2_async_notifier *notifier)
>   }
>   kfree(dev);
>  
> + mutex_destroy(>lock);
>   notifier->v4l2_dev = NULL;
>  
>   /*
> @@ -274,6 +272,7 @@ EXPORT_SYMBOL(v4l2_async_notifier_unregister);
>  int v4l2_async_register_subdev(struct v4l2_subdev *sd)
>  {
>   struct v4l2_async_notifier *notifier;
> + struct v4l2_async_notifier *tmp;
>  
>   /*
>* No reference taken. The reference is held by the device
> @@ -283,24 +282,25 @@ int v4l2_async_register_subdev(struct v4l2_subdev *sd)
>   if (!sd->of_node && sd->dev)
>   sd->of_node = sd->dev->of_node;
>  
> - mutex_lock(_lock);
> -
>   INIT_LIST_HEAD(>async_list);
>  
> - list_for_each_entry(notifier, _list, list) {
> - struct v4l2_async_subdev *asd = v4l2_async_belongs(notifier, 
> sd);
> + list_for_each_entry_safe(notifier, tmp, _list, list) {

You still need to serialise access to the global notifier list.

The _safe 

Re: [RFC 03/13] v4l: split lane parsing code

[Sakari Ailus]

Hi Pavel,

On Tue, Feb 14, 2017 at 02:39:41PM +0100, Pavel Machek wrote:
> From: Sakari Ailus 
> 
> The function to parse CSI2 bus parameters was called
> v4l2_of_parse_csi_bus(), rename it as v4l2_of_parse_csi2_bus() in
> anticipation of CSI1/CCP2 support.
> 
> Obtain data bus type from bus-type property. Only try parsing bus
> specific properties in this case.
> 
> Separate lane parsing from CSI-2 bus parameter parsing. The CSI-1 will
> need these as well, separate them into a different
> function. have_clk_lane and num_data_lanes arguments may be NULL; the
> CSI-1 bus will have no use for them.
> 
> Add support for parsing of CSI-1 and CCP2 bus related properties
> documented in video-interfaces.txt.

One more thing: this conflicts badly with the V4L2 fwnode patchset.

Assuming things go well and that can be merged somewhat soonish, can I take
this and rebase it on the fwnode set? The two first patches in the set look
pretty good to me.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [RFC 03/13] v4l: split lane parsing code

[Sakari Ailus]

Hi Pavel,

On Tue, Feb 14, 2017 at 02:39:41PM +0100, Pavel Machek wrote:
> From: Sakari Ailus 
> 
> The function to parse CSI2 bus parameters was called
> v4l2_of_parse_csi_bus(), rename it as v4l2_of_parse_csi2_bus() in
> anticipation of CSI1/CCP2 support.
> 
> Obtain data bus type from bus-type property. Only try parsing bus
> specific properties in this case.
> 
> Separate lane parsing from CSI-2 bus parameter parsing. The CSI-1 will
> need these as well, separate them into a different
> function. have_clk_lane and num_data_lanes arguments may be NULL; the
> CSI-1 bus will have no use for them.
> 
> Add support for parsing of CSI-1 and CCP2 bus related properties
> documented in video-interfaces.txt.
> 
> Signed-off-by: Sakari Ailus 
> Signed-off-by: Ivaylo Dimitrov 
> Signed-off-by: Pavel Machek 
> ---
>  drivers/media/v4l2-core/v4l2-of.c | 141 
> ++
>  1 file changed, 114 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-of.c 
> b/drivers/media/v4l2-core/v4l2-of.c
> index 4f59f44..9ffe2d3 100644
> --- a/drivers/media/v4l2-core/v4l2-of.c
> +++ b/drivers/media/v4l2-core/v4l2-of.c
> @@ -20,64 +20,101 @@
>  
>  #include 
>  
> -static int v4l2_of_parse_csi_bus(const struct device_node *node,
> -  struct v4l2_of_endpoint *endpoint)
> +enum v4l2_of_bus_type {
> + V4L2_OF_BUS_TYPE_CSI2 = 0,
> + V4L2_OF_BUS_TYPE_PARALLEL,
> + V4L2_OF_BUS_TYPE_CSI1,
> + V4L2_OF_BUS_TYPE_CCP2,
> +};

This no longer matches the bus-type values in DT bindings. How about:

V4L2_OF_BUS_TYPE_GUESS, /* CSI-2 D-PHY, parallel or Bt.656 */
V4L2_OF_BUS_TYPE_CSI2_CPHY,
V4L2_OF_BUS_TYPE_CSI1,
V4L2_OF_BUS_TYPE_CCP2

> +
> +static int v4l2_of_parse_lanes(const struct device_node *node,
> +unsigned char *clock_lane,
> +bool *have_clk_lane,
> +unsigned char *data_lanes,
> +bool *lane_polarities,
> +unsigned short *__num_data_lanes,
> +unsigned int max_data_lanes)
>  {
> - struct v4l2_of_bus_mipi_csi2 *bus = >bus.mipi_csi2;
>   struct property *prop;
> - bool have_clk_lane = false;
> - unsigned int flags = 0, lanes_used = 0;
> + unsigned int lanes_used = 0;
> + short num_data_lanes = 0;
>   u32 v;
>  
>   prop = of_find_property(node, "data-lanes", NULL);
>   if (prop) {
>   const __be32 *lane = NULL;
> - unsigned int i;
>  
> - for (i = 0; i < ARRAY_SIZE(bus->data_lanes); i++) {
> + for (num_data_lanes = 0; num_data_lanes < max_data_lanes;
> +  num_data_lanes++) {
>   lane = of_prop_next_u32(prop, lane, );
>   if (!lane)
>   break;
> + data_lanes[num_data_lanes] = v;
>  
>   if (lanes_used & BIT(v))
>   pr_warn("%s: duplicated lane %u in 
> data-lanes\n",
>   node->full_name, v);
>   lanes_used |= BIT(v);
> -
> - bus->data_lanes[i] = v;
>   }
> - bus->num_data_lanes = i;
>   }
> + if (__num_data_lanes)
> + *__num_data_lanes = num_data_lanes;
>  
>   prop = of_find_property(node, "lane-polarities", NULL);
>   if (prop) {
>   const __be32 *polarity = NULL;
>   unsigned int i;
>  
> - for (i = 0; i < ARRAY_SIZE(bus->lane_polarities); i++) {
> + for (i = 0; i < 1 + max_data_lanes; i++) {
>   polarity = of_prop_next_u32(prop, polarity, );
>   if (!polarity)
>   break;
> - bus->lane_polarities[i] = v;
> + lane_polarities[i] = v;
>   }
>  
> - if (i < 1 + bus->num_data_lanes /* clock + data */) {
> + if (i < 1 + num_data_lanes /* clock + data */) {
>   pr_warn("%s: too few lane-polarities entries (need %u, 
> got %u)\n",
> - node->full_name, 1 + bus->num_data_lanes, i);
> + node->full_name, 1 + num_data_lanes, i);
>   return -EINVAL;
>   }
>   }
>  
> + if (have_clk_lane)
> + *have_clk_lane = false;
> +
>   if (!of_property_read_u32(node, "clock-lanes", )) {
> + *clock_lane = v;
> + if (have_clk_lane)
> + *have_clk_lane = true;
> +
>   if (lanes_used & BIT(v))
>   pr_warn("%s: duplicated lane %u in clock-lanes\n",
>   node->full_name, v);
>   lanes_used |= BIT(v);
> -
> - bus->clock_lane = v;
> 

Cine CT V6.1 code change request

[Martin Herrman]

All,

I have a Cine CT V6.1 in my fedora 25 based media center. It is now
running a default fedora 4.9 kernel. I install the driver as follows:

hg clone https://linuxtv.org/hg/~endriss/media_build_experimental
cd media_build_experimental
make download
make untar
make menuconfig
make
make install

However, I have to make two changes to the source to make it work.

Change 1: in media_build_experimental/v4l/Kconfig line 6936 I have to
remove the whitespace in '--- help ---', otherwise make menuconfig
fails.
Change 2: during compilation the following error occurs (since about
kernel 4.5?):

make -C /lib/modules/4.9.7-201.fc25.x86_64/build
SUBDIRS=/home/htpc/Downloads/media_build_experimental/v4l  modules
make[2]: Entering directory '/usr/src/kernels/4.9.7-201.fc25.x86_64'
  CC [M]  /home/htpc/Downloads/media_build_experimental/v4l/tuner-xc2028.o
In file included from :0:0:
/home/htpc/Downloads/media_build_experimental/v4l/compat.h:1463:1:
error: redefinition of 'pci_zalloc_consistent'
 pci_zalloc_consistent(struct pci_dev *hwdev, size_t size,
 ^
In file included from ./include/linux/pci.h:2145:0,
 from
/home/htpc/Downloads/media_build_experimental/v4l/compat.h:1459,
 from :0:
./include/linux/pci-dma-compat.h:23:1: note: previous definition of
'pci_zalloc_consistent' was here
 pci_zalloc_consistent(struct pci_dev *hwdev, size_t size,
 ^
In file included from :0:0:
/home/htpc/Downloads/media_build_experimental/v4l/compat.h:1552:0:
warning: "DMA_ATTR_SKIP_CPU_SYNC" redefined
 #define DMA_ATTR_SKIP_CPU_SYNC 0

In file included from ./include/linux/pci-dma-compat.h:7:0,
 from ./include/linux/pci.h:2145,
 from
/home/htpc/Downloads/media_build_experimental/v4l/compat.h:1459,
 from :0:
./include/linux/dma-mapping.h:47:0: note: this is the location of the
previous definition
 #define DMA_ATTR_SKIP_CPU_SYNC  (1UL << 5)

scripts/Makefile.build:299: recipe for target
'/home/htpc/Downloads/media_build_experimental/v4l/tuner-xc2028.o'
failed
make[3]: *** [/home/htpc/Downloads/media_build_experimental/v4l/tuner-xc2028.o]
Error 1
Makefile:1494: recipe for target
'_module_/home/htpc/Downloads/media_build_experimental/v4l' failed
make[2]: *** [_module_/home/htpc/Downloads/media_build_experimental/v4l] Error 2
make[2]: Leaving directory '/usr/src/kernels/4.9.7-201.fc25.x86_64'
Makefile:51: recipe for target 'default' failed
make[1]: *** [default] Error 2
make[1]: Leaving directory '/home/htpc/Downloads/media_build_experimental/v4l'
Makefile:28: recipe for target 'all' failed
make: *** [all] Error 2

Which I fix by commenting out lines 1462 up to 1468 in
media_build_experimental/v4l/compat.h:

//static inline void *
//pci_zalloc_consistent(struct pci_dev *hwdev, size_t size,
// dma_addr_t *dma_handle)
//{
// return dma_alloc_coherent(hwdev == NULL ? NULL : >dev,
// size, dma_handle, GFP_ATOMIC | __GFP_ZERO);
//}

Now it compiles and works fine. I still get these warnings:

media_build_experimental/v4l/compat.h:1552:0: warning:
"DMA_ATTR_SKIP_CPU_SYNC" redefined
 #define DMA_ATTR_SKIP_CPU_SYNC 0

Which I can easily remove by commenting out the specific line as well.

Now my questions are:
- is this the correct way to fix these compile errors? (I'm definately
not a professional developer)
- what can I do to have this solved in the source?

Besides that, I'm also wondering if these drivers have any change of
getting into kernel mainline?

Regards,

Martin

Re: [RFC simple allocator v2 1/2] Create Simple Allocator module

[Laurent Pinchart]

Hi Daniel,

On Tuesday 14 Feb 2017 20:44:44 Daniel Vetter wrote:
> On Tue, Feb 14, 2017 at 8:39 PM, Laurent Pinchart wrote:
> > On Tuesday 14 Feb 2017 20:33:58 Daniel Vetter wrote:
> >> On Mon, Feb 13, 2017 at 3:45 PM, Benjamin Gaignard wrote:
> >>> This is the core of simple allocator module.
> >>> It aim to offert one common ioctl to allocate specific memory.
> >>> 
> >>> version 2:
> >>> - rebased on 4.10-rc7
> >>> 
> >>> Signed-off-by: Benjamin Gaignard 
> >> 
> >> Why not ION? It's a bit a broken record question, but if there is a
> >> clear answer it should be in the patch ...
> > 
> > There's a bit of love & hate relationship between Linux developers and
> > ION. The API has shortcomings, and attempts to fix the issues went
> > nowhere. As Laura explained, starting from a blank slate (obviously
> > keeping in mind the lessons learnt so far with ION and other similar APIs)
> > and then adding a wrapper to expose ION on Android systems (at least as an
> > interim measure) was thought to be a better option. I still believe it is,
> > but we seem to lack traction. The problem has been around for so long that
> > I feel everybody has lost hope.
> > 
> > I don't think this is unsolvable, but we need to regain motivation. In my
> > opinion the first step would be to define the precise extent of the
> > problem we want to solve.
> 
> I'm not sure anyone really tried hard enough (in the same way no one
> tried hard enough to destage android syncpts, until last year). And
> anything new should at least very clearly explain why ION (even with
> the various todo items we collected at a few conferences) won't work,
> and how exactly the new allocator is different from ION. I don't think
> we need a full design doc (like you say, buffer allocation is hard,
> we'll get it wrong anyway), but at least a proper comparison with the
> existing thing. Plus explanation why we can't reuse the uabi.

I've explained several of my concerns (including open questions that need 
answers) in another reply to this patch, let's discuss them there to avoid 
splitting the discussion.

> Because ime when you rewrite something, you generally get one thing
> right (the one thing that pissed you off about the old solution), plus
> lots and lots of things that the old solution got right, wrong
> (because it's all lost in the history).

History, repeating mistakes, all that. History never repeats itself though. We 
might make similar or identical mistakes, but there's no fatality, unless we 
decide not to try before even starting :-)

> ADF was probably the best example in this. KMS also took a while until all
> the fbdev wheels have been properly reinvented (some are still the same old
> squeaky onces as fbdev had, e.g. fbcon).
> 
> And I don't think destaging ION is going to be hard, just a bit of
> work (could be a nice gsoc or whatever).

Oh, technically speaking, it would be pretty simple. The main issue is to 
decide whether we want to commit to the existing ION API. I don't :-)

-- 
Regards,

Laurent Pinchart

[PATCH v2] siano: make it work again with CONFIG_VMAP_STACK

[Mauro Carvalho Chehab]

Reported as a Kaffeine bug:
https://bugs.kde.org/show_bug.cgi?id=375811

The USB control messages require DMA to work. We cannot pass
a stack-allocated buffer, as it is not warranted that the
stack would be into a DMA enabled area.

On Kernel 4.9, the default is to not accept DMA on stack anymore
on x86 architecture. On other architectures, this has been a
requirement since Kernel 2.2. So, after this patch, this driver
should likely work fine on all archs.

Tested with USB ID 2040:5510: Hauppauge Windham

Cc: sta...@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/usb/siano/smsusb.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/media/usb/siano/smsusb.c b/drivers/media/usb/siano/smsusb.c
index a4dcaec31d02..8c1f926567ec 100644
--- a/drivers/media/usb/siano/smsusb.c
+++ b/drivers/media/usb/siano/smsusb.c
@@ -218,22 +218,30 @@ static int smsusb_start_streaming(struct smsusb_device_t 
*dev)
 static int smsusb_sendrequest(void *context, void *buffer, size_t size)
 {
struct smsusb_device_t *dev = (struct smsusb_device_t *) context;
-   struct sms_msg_hdr *phdr = (struct sms_msg_hdr *) buffer;
-   int dummy;
+   struct sms_msg_hdr *phdr;
+   int dummy, ret;
 
if (dev->state != SMSUSB_ACTIVE) {
pr_debug("Device not active yet\n");
return -ENOENT;
}
 
+   phdr = kmalloc(size, GFP_KERNEL);
+   if (!phdr)
+   return -ENOMEM;
+   memcpy(phdr, buffer, size);
+
pr_debug("sending %s(%d) size: %d\n",
  smscore_translate_msg(phdr->msg_type), phdr->msg_type,
  phdr->msg_length);
 
smsendian_handle_tx_message((struct sms_msg_data *) phdr);
-   smsendian_handle_message_header((struct sms_msg_hdr *)buffer);
-   return usb_bulk_msg(dev->udev, usb_sndbulkpipe(dev->udev, 2),
-   buffer, size, , 1000);
+   smsendian_handle_message_header((struct sms_msg_hdr *)phdr);
+   ret = usb_bulk_msg(dev->udev, usb_sndbulkpipe(dev->udev, 2),
+   phdr, size, , 1000);
+
+   kfree(phdr);
+   return ret;
 }
 
 static char *smsusb1_fw_lkup[] = {
-- 
2.9.3

Re: [RFC simple allocator v2 1/2] Create Simple Allocator module

[Laurent Pinchart]

Hi Daniel,

On Tuesday 14 Feb 2017 20:33:58 Daniel Vetter wrote:
> On Mon, Feb 13, 2017 at 3:45 PM, Benjamin Gaignard wrote:
> > This is the core of simple allocator module.
> > It aim to offert one common ioctl to allocate specific memory.
> > 
> > version 2:
> > - rebased on 4.10-rc7
> > 
> > Signed-off-by: Benjamin Gaignard 
> 
> Why not ION? It's a bit a broken record question, but if there is a
> clear answer it should be in the patch ...

There's a bit of love & hate relationship between Linux developers and ION. 
The API has shortcomings, and attempts to fix the issues went nowhere. As 
Laura explained, starting from a blank slate (obviously keeping in mind the 
lessons learnt so far with ION and other similar APIs) and then adding a 
wrapper to expose ION on Android systems (at least as an interim measure) was 
thought to be a better option. I still believe it is, but we seem to lack 
traction. The problem has been around for so long that I feel everybody has 
lost hope.

I don't think this is unsolvable, but we need to regain motivation. In my 
opinion the first step would be to define the precise extent of the problem we 
want to solve.

> > ---
> > 
> >  Documentation/simple-allocator.txt  |  81 +++
> >  drivers/Kconfig |   2 +
> >  drivers/Makefile|   1 +
> >  drivers/simpleallocator/Kconfig |  10 ++
> >  drivers/simpleallocator/Makefile|   1 +
> >  drivers/simpleallocator/simple-allocator-priv.h |  33 +
> >  drivers/simpleallocator/simple-allocator.c  | 180 +++
> >  include/uapi/linux/simple-allocator.h   |  35 +
> >  8 files changed, 343 insertions(+)
> >  create mode 100644 Documentation/simple-allocator.txt
> >  create mode 100644 drivers/simpleallocator/Kconfig
> >  create mode 100644 drivers/simpleallocator/Makefile
> >  create mode 100644 drivers/simpleallocator/simple-allocator-priv.h
> >  create mode 100644 drivers/simpleallocator/simple-allocator.c
> >  create mode 100644 include/uapi/linux/simple-allocator.h
> > 
> > diff --git a/Documentation/simple-allocator.txt
> > b/Documentation/simple-allocator.txt new file mode 100644
> > index 000..89ba883
> > --- /dev/null
> > +++ b/Documentation/simple-allocator.txt
> > @@ -0,0 +1,81 @@
> > +Simple Allocator Framework
> > +
> > +Simple Allocator offer a single ioctl SA_IOC_ALLOC to allocate buffers
> > +on dedicated memory regions and export them as a dmabuf file descriptor.
> > +Using dmabuf file descriptor allow to share this memory between processes
> > +and/or import it into other frameworks like v4l2 or drm/kms (prime).
> > +When userland wants to free the memory only a call to close() in needed
> > +so it could done even without knowing that buffer has been allocated by
> > +simple allocator ioctl.
> > +
> > +Each memory regions will be seen as a filein /dev/.
> > +For example CMA regions will exposed has /dev/cmaX.
> > +
> > +Implementing a simple allocator
> > +---
> > +
> > +Simple Allocator provide helpers functions to register/unregister an
> > +allocator:
> > +- simple_allocator_register(struct sa_device *sadev)
> > +  Register simple_allocator_device using sa_device structure where name,
> > +  owner and allocate fields must be set.
> > +
> > +- simple_allocator_unregister(struct sa_device *sadev)
> > +  Unregister a simple allocator device.
> > +
> > +Using Simple Allocator /dev interface example
> > +-
> > +
> > +This example of code allocate a buffer on the first CMA region
> > (/dev/cma0)
> > +before mmap and close it.
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "simple-allocator.h"
> > +
> > +#define LENGTH 1024*16
> > +
> > +void main (void)
> > +{
> > +   struct simple_allocate_data data;
> > +   int fd = open("/dev/cma0", O_RDWR, 0);
> > +   int ret;
> > +   void *mem;
> > +
> > +   if (fd < 0) {
> > +   printf("Can't open /dev/cma0\n");
> > +   return;
> > +   }
> > +
> > +   memset(, 0, sizeof(data));
> > +
> > +   data.length = LENGTH;
> > +   data.flags = O_RDWR | O_CLOEXEC;
> > +
> > +   ret = ioctl(fd, SA_IOC_ALLOC, );
> > +   if (ret) {
> > +   printf("Buffer allocation failed\n");
> > +   goto end;
> > +   }
> > +
> > +   mem = mmap(0, LENGTH, PROT_READ | PROT_WRITE, MAP_SHARED, data.fd,
> > 0); +   if (mem == MAP_FAILED) {
> > +   printf("mmap failed\n");
> > +   }
> > +
> > +   memset(mem, 0xFF, LENGTH);
> > +   munmap(mem, LENGTH);
> > +
> > +   printf("test simple allocator CMA OK\n");
> > +end:
> > +   close(fd);
> > +}
> > diff --git a/drivers/Kconfig b/drivers/Kconfig
> > index 

Re: [PATCH] siano: make it work again with CONFIG_VMAP_STACK

[Mauro Carvalho Chehab]

Em Tue, 14 Feb 2017 11:41:46 -0800
Greg KH  escreveu:

> On Tue, Feb 14, 2017 at 05:32:11PM -0200, Mauro Carvalho Chehab wrote:
> > Reported as a Kaffeine bug:
> > https://bugs.kde.org/show_bug.cgi?id=375811
> > 
> > The USB control messages require DMA to work. We cannot pass
> > a stack-allocated buffer, as it is not warranted that the
> > stack would be into a DMA enabled area.
> > 
> > On Kernel 4.9, the default is to not accept DMA on stack anymore.
> > 
> > Tested with USB ID 2040:5510: Hauppauge Windham
> > 
> > Cc: sta...@vger.kernel.org # For 4.9+  
> 
> Unless there is some major reason, this should go into _all_ stable
> releases, as the driver would be broken on them all for platforms that
> can't handle USB data that is not DMA-able.  This has been a requirement
> for USB drivers since the 2.2 days.

Good point! No, there's no particular reason why not backporting it
to older Kernel releases. I suspect that this particular part of
the driver hasn't changed for a while. So, it can very likely be
backported to all stable releases.

I'll fix the C/C message when submitting it upstream.

Thanks,
Mauro

Re: [RFC simple allocator v2 1/2] Create Simple Allocator module

[Daniel Vetter]

On Tue, Feb 14, 2017 at 8:39 PM, Laurent Pinchart
 wrote:
> Hi Daniel,
>
> On Tuesday 14 Feb 2017 20:33:58 Daniel Vetter wrote:
>> On Mon, Feb 13, 2017 at 3:45 PM, Benjamin Gaignard wrote:
>> > This is the core of simple allocator module.
>> > It aim to offert one common ioctl to allocate specific memory.
>> >
>> > version 2:
>> > - rebased on 4.10-rc7
>> >
>> > Signed-off-by: Benjamin Gaignard 
>>
>> Why not ION? It's a bit a broken record question, but if there is a
>> clear answer it should be in the patch ...
>
> There's a bit of love & hate relationship between Linux developers and ION.
> The API has shortcomings, and attempts to fix the issues went nowhere. As
> Laura explained, starting from a blank slate (obviously keeping in mind the
> lessons learnt so far with ION and other similar APIs) and then adding a
> wrapper to expose ION on Android systems (at least as an interim measure) was
> thought to be a better option. I still believe it is, but we seem to lack
> traction. The problem has been around for so long that I feel everybody has
> lost hope.
>
> I don't think this is unsolvable, but we need to regain motivation. In my
> opinion the first step would be to define the precise extent of the problem we
> want to solve.

I'm not sure anyone really tried hard enough (in the same way no one
tried hard enough to destage android syncpts, until last year). And
anything new should at least very clearly explain why ION (even with
the various todo items we collected at a few conferences) won't work,
and how exactly the new allocator is different from ION. I don't think
we need a full design doc (like you say, buffer allocation is hard,
we'll get it wrong anyway), but at least a proper comparison with the
existing thing. Plus explanation why we can't reuse the uabi.

Because ime when you rewrite something, you generally get one thing
right (the one thing that pissed you off about the old solution), plus
lots and lots of things that the old solution got right, wrong
(because it's all lost in the history). ADF was probably the best
example in this. KMS also took a while until all the fbdev wheels have
been properly reinvented (some are still the same old squeaky onces as
fbdev had, e.g. fbcon).

And I don't think destaging ION is going to be hard, just a bit of
work (could be a nice gsoc or whatever).
-Daniel

>
>> > ---
>> >
>> >  Documentation/simple-allocator.txt  |  81 +++
>> >  drivers/Kconfig |   2 +
>> >  drivers/Makefile|   1 +
>> >  drivers/simpleallocator/Kconfig |  10 ++
>> >  drivers/simpleallocator/Makefile|   1 +
>> >  drivers/simpleallocator/simple-allocator-priv.h |  33 +
>> >  drivers/simpleallocator/simple-allocator.c  | 180 +++
>> >  include/uapi/linux/simple-allocator.h   |  35 +
>> >  8 files changed, 343 insertions(+)
>> >  create mode 100644 Documentation/simple-allocator.txt
>> >  create mode 100644 drivers/simpleallocator/Kconfig
>> >  create mode 100644 drivers/simpleallocator/Makefile
>> >  create mode 100644 drivers/simpleallocator/simple-allocator-priv.h
>> >  create mode 100644 drivers/simpleallocator/simple-allocator.c
>> >  create mode 100644 include/uapi/linux/simple-allocator.h
>> >
>> > diff --git a/Documentation/simple-allocator.txt
>> > b/Documentation/simple-allocator.txt new file mode 100644
>> > index 000..89ba883
>> > --- /dev/null
>> > +++ b/Documentation/simple-allocator.txt
>> > @@ -0,0 +1,81 @@
>> > +Simple Allocator Framework
>> > +
>> > +Simple Allocator offer a single ioctl SA_IOC_ALLOC to allocate buffers
>> > +on dedicated memory regions and export them as a dmabuf file descriptor.
>> > +Using dmabuf file descriptor allow to share this memory between processes
>> > +and/or import it into other frameworks like v4l2 or drm/kms (prime).
>> > +When userland wants to free the memory only a call to close() in needed
>> > +so it could done even without knowing that buffer has been allocated by
>> > +simple allocator ioctl.
>> > +
>> > +Each memory regions will be seen as a filein /dev/.
>> > +For example CMA regions will exposed has /dev/cmaX.
>> > +
>> > +Implementing a simple allocator
>> > +---
>> > +
>> > +Simple Allocator provide helpers functions to register/unregister an
>> > +allocator:
>> > +- simple_allocator_register(struct sa_device *sadev)
>> > +  Register simple_allocator_device using sa_device structure where name,
>> > +  owner and allocate fields must be set.
>> > +
>> > +- simple_allocator_unregister(struct sa_device *sadev)
>> > +  Unregister a simple allocator device.
>> > +
>> > +Using Simple Allocator /dev interface example
>> > +-
>> > +
>> > +This example of code allocate a buffer on the first CMA region
>> > (/dev/cma0)
>> > +before mmap and close it.

Re: [PATCH] siano: make it work again with CONFIG_VMAP_STACK

[Greg KH]

On Tue, Feb 14, 2017 at 05:32:11PM -0200, Mauro Carvalho Chehab wrote:
> Reported as a Kaffeine bug:
>   https://bugs.kde.org/show_bug.cgi?id=375811
> 
> The USB control messages require DMA to work. We cannot pass
> a stack-allocated buffer, as it is not warranted that the
> stack would be into a DMA enabled area.
> 
> On Kernel 4.9, the default is to not accept DMA on stack anymore.
> 
> Tested with USB ID 2040:5510: Hauppauge Windham
> 
> Cc: sta...@vger.kernel.org # For 4.9+

Unless there is some major reason, this should go into _all_ stable
releases, as the driver would be broken on them all for platforms that
can't handle USB data that is not DMA-able.  This has been a requirement
for USB drivers since the 2.2 days.

thanks,

greg k-h

Re: [RFC simple allocator v2 1/2] Create Simple Allocator module

[Daniel Vetter]

On Mon, Feb 13, 2017 at 3:45 PM, Benjamin Gaignard
 wrote:
> This is the core of simple allocator module.
> It aim to offert one common ioctl to allocate specific memory.
>
> version 2:
> - rebased on 4.10-rc7
>
> Signed-off-by: Benjamin Gaignard 

Why not ION? It's a bit a broken record question, but if there is a
clear answer it should be in the patch ...
-Daniel

> ---
>  Documentation/simple-allocator.txt  |  81 +++
>  drivers/Kconfig |   2 +
>  drivers/Makefile|   1 +
>  drivers/simpleallocator/Kconfig |  10 ++
>  drivers/simpleallocator/Makefile|   1 +
>  drivers/simpleallocator/simple-allocator-priv.h |  33 +
>  drivers/simpleallocator/simple-allocator.c  | 180 
> 
>  include/uapi/linux/simple-allocator.h   |  35 +
>  8 files changed, 343 insertions(+)
>  create mode 100644 Documentation/simple-allocator.txt
>  create mode 100644 drivers/simpleallocator/Kconfig
>  create mode 100644 drivers/simpleallocator/Makefile
>  create mode 100644 drivers/simpleallocator/simple-allocator-priv.h
>  create mode 100644 drivers/simpleallocator/simple-allocator.c
>  create mode 100644 include/uapi/linux/simple-allocator.h
>
> diff --git a/Documentation/simple-allocator.txt 
> b/Documentation/simple-allocator.txt
> new file mode 100644
> index 000..89ba883
> --- /dev/null
> +++ b/Documentation/simple-allocator.txt
> @@ -0,0 +1,81 @@
> +Simple Allocator Framework
> +
> +Simple Allocator offer a single ioctl SA_IOC_ALLOC to allocate buffers
> +on dedicated memory regions and export them as a dmabuf file descriptor.
> +Using dmabuf file descriptor allow to share this memory between processes
> +and/or import it into other frameworks like v4l2 or drm/kms (prime).
> +When userland wants to free the memory only a call to close() in needed
> +so it could done even without knowing that buffer has been allocated by
> +simple allocator ioctl.
> +
> +Each memory regions will be seen as a filein /dev/.
> +For example CMA regions will exposed has /dev/cmaX.
> +
> +Implementing a simple allocator
> +---
> +
> +Simple Allocator provide helpers functions to register/unregister an
> +allocator:
> +- simple_allocator_register(struct sa_device *sadev)
> +  Register simple_allocator_device using sa_device structure where name,
> +  owner and allocate fields must be set.
> +
> +- simple_allocator_unregister(struct sa_device *sadev)
> +  Unregister a simple allocator device.
> +
> +Using Simple Allocator /dev interface example
> +-
> +
> +This example of code allocate a buffer on the first CMA region (/dev/cma0)
> +before mmap and close it.
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "simple-allocator.h"
> +
> +#define LENGTH 1024*16
> +
> +void main (void)
> +{
> +   struct simple_allocate_data data;
> +   int fd = open("/dev/cma0", O_RDWR, 0);
> +   int ret;
> +   void *mem;
> +
> +   if (fd < 0) {
> +   printf("Can't open /dev/cma0\n");
> +   return;
> +   }
> +
> +   memset(, 0, sizeof(data));
> +
> +   data.length = LENGTH;
> +   data.flags = O_RDWR | O_CLOEXEC;
> +
> +   ret = ioctl(fd, SA_IOC_ALLOC, );
> +   if (ret) {
> +   printf("Buffer allocation failed\n");
> +   goto end;
> +   }
> +
> +   mem = mmap(0, LENGTH, PROT_READ | PROT_WRITE, MAP_SHARED, data.fd, 0);
> +   if (mem == MAP_FAILED) {
> +   printf("mmap failed\n");
> +   }
> +
> +   memset(mem, 0xFF, LENGTH);
> +   munmap(mem, LENGTH);
> +
> +   printf("test simple allocator CMA OK\n");
> +end:
> +   close(fd);
> +}
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index e1e2066..a6d8828 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -202,4 +202,6 @@ source "drivers/hwtracing/intel_th/Kconfig"
>
>  source "drivers/fpga/Kconfig"
>
> +source "drivers/simpleallocator/Kconfig"
> +
>  endmenu
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 060026a..5081eb8 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -173,3 +173,4 @@ obj-$(CONFIG_STM)   += hwtracing/stm/
>  obj-$(CONFIG_ANDROID)  += android/
>  obj-$(CONFIG_NVMEM)+= nvmem/
>  obj-$(CONFIG_FPGA) += fpga/
> +obj-$(CONFIG_SIMPLE_ALLOCATOR) += simpleallocator/
> diff --git a/drivers/simpleallocator/Kconfig b/drivers/simpleallocator/Kconfig
> new file mode 100644
> index 000..c6fc2e3
> --- /dev/null
> +++ b/drivers/simpleallocator/Kconfig
> @@ -0,0 +1,10 @@
> +menu "Simple Allocator"
> +
> +config SIMPLE_ALLOCATOR
> +   tristate "Simple Alllocator Framework"
> +   select DMA_SHARED_BUFFER
> +   

[PATCH] siano: make it work again with CONFIG_VMAP_STACK

[Mauro Carvalho Chehab]

Reported as a Kaffeine bug:
https://bugs.kde.org/show_bug.cgi?id=375811

The USB control messages require DMA to work. We cannot pass
a stack-allocated buffer, as it is not warranted that the
stack would be into a DMA enabled area.

On Kernel 4.9, the default is to not accept DMA on stack anymore.

Tested with USB ID 2040:5510: Hauppauge Windham

Cc: sta...@vger.kernel.org # For 4.9+
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/usb/siano/smsusb.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/media/usb/siano/smsusb.c b/drivers/media/usb/siano/smsusb.c
index a4dcaec31d02..8c1f926567ec 100644
--- a/drivers/media/usb/siano/smsusb.c
+++ b/drivers/media/usb/siano/smsusb.c
@@ -218,22 +218,30 @@ static int smsusb_start_streaming(struct smsusb_device_t 
*dev)
 static int smsusb_sendrequest(void *context, void *buffer, size_t size)
 {
struct smsusb_device_t *dev = (struct smsusb_device_t *) context;
-   struct sms_msg_hdr *phdr = (struct sms_msg_hdr *) buffer;
-   int dummy;
+   struct sms_msg_hdr *phdr;
+   int dummy, ret;
 
if (dev->state != SMSUSB_ACTIVE) {
pr_debug("Device not active yet\n");
return -ENOENT;
}
 
+   phdr = kmalloc(size, GFP_KERNEL);
+   if (!phdr)
+   return -ENOMEM;
+   memcpy(phdr, buffer, size);
+
pr_debug("sending %s(%d) size: %d\n",
  smscore_translate_msg(phdr->msg_type), phdr->msg_type,
  phdr->msg_length);
 
smsendian_handle_tx_message((struct sms_msg_data *) phdr);
-   smsendian_handle_message_header((struct sms_msg_hdr *)buffer);
-   return usb_bulk_msg(dev->udev, usb_sndbulkpipe(dev->udev, 2),
-   buffer, size, , 1000);
+   smsendian_handle_message_header((struct sms_msg_hdr *)phdr);
+   ret = usb_bulk_msg(dev->udev, usb_sndbulkpipe(dev->udev, 2),
+   phdr, size, , 1000);
+
+   kfree(phdr);
+   return ret;
 }
 
 static char *smsusb1_fw_lkup[] = {
-- 
2.9.3

Re: [RFC simple allocator v2 1/2] Create Simple Allocator module

[Laurent Pinchart]

Hi Benjamin,

Thank you for the patch. I've CC'ed the linux-api mailing list.

On Monday 13 Feb 2017 15:45:05 Benjamin Gaignard wrote:
> This is the core of simple allocator module.
> It aim to offert one common ioctl to allocate specific memory.
> 
> version 2:
> - rebased on 4.10-rc7
> 
> Signed-off-by: Benjamin Gaignard 
> ---
>  Documentation/simple-allocator.txt  |  81 +++
>  drivers/Kconfig |   2 +
>  drivers/Makefile|   1 +
>  drivers/simpleallocator/Kconfig |  10 ++
>  drivers/simpleallocator/Makefile|   1 +
>  drivers/simpleallocator/simple-allocator-priv.h |  33 +
>  drivers/simpleallocator/simple-allocator.c  | 180 +
>  include/uapi/linux/simple-allocator.h   |  35 +
>  8 files changed, 343 insertions(+)
>  create mode 100644 Documentation/simple-allocator.txt
>  create mode 100644 drivers/simpleallocator/Kconfig
>  create mode 100644 drivers/simpleallocator/Makefile
>  create mode 100644 drivers/simpleallocator/simple-allocator-priv.h
>  create mode 100644 drivers/simpleallocator/simple-allocator.c
>  create mode 100644 include/uapi/linux/simple-allocator.h
> 
> diff --git a/Documentation/simple-allocator.txt
> b/Documentation/simple-allocator.txt new file mode 100644
> index 000..89ba883
> --- /dev/null
> +++ b/Documentation/simple-allocator.txt
> @@ -0,0 +1,81 @@
> +Simple Allocator Framework

There's nothing simple in buffer allocation, otherwise we would have solved 
the problem a long time ago. Let's not use a misleading name.

> +Simple Allocator offer a single ioctl SA_IOC_ALLOC to allocate buffers
> +on dedicated memory regions and export them as a dmabuf file descriptor.
> +Using dmabuf file descriptor allow to share this memory between processes
> +and/or import it into other frameworks like v4l2 or drm/kms (prime).
> +When userland wants to free the memory only a call to close() in needed
> +so it could done even without knowing that buffer has been allocated by
> +simple allocator ioctl.
> +
> +Each memory regions will be seen as a filein /dev/.
> +For example CMA regions will exposed has /dev/cmaX.

Why do you need multiple devices ? Furthermore, given how central this API 
will become, I believe it needs very strict review, and would be a candidate 
for a syscall.

Without diving into details yet, there are a few particular points I'm 
concerned about.

- What is the scope of this API ? What problems do you want to solve, plan to 
solve in the future, and consider as out of scope ?

- How should we handle permissions and resource limits ? Is file-based 
permission on a device node a good model ? How do we prevent or at least 
mitigate memory-related DoS ?

- How should such a central allocator API interact with containers and 
virtualization in general ?

- What model do we want to expose to applications to select a memory type ? 
You still haven't convinced me that we should expose memory pools explicitly 
to application (à la ION), and I believe a usage/constraint model would be 
better.

> +Implementing a simple allocator
> +---
> +
> +Simple Allocator provide helpers functions to register/unregister an
> +allocator:
> +- simple_allocator_register(struct sa_device *sadev)
> +  Register simple_allocator_device using sa_device structure where name,
> +  owner and allocate fields must be set.
> +
> +- simple_allocator_unregister(struct sa_device *sadev)
> +  Unregister a simple allocator device.
> +
> +Using Simple Allocator /dev interface example
> +-
> +
> +This example of code allocate a buffer on the first CMA region (/dev/cma0)
> +before mmap and close it.
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "simple-allocator.h"
> +
> +#define LENGTH 1024*16
> +
> +void main (void)
> +{
> + struct simple_allocate_data data;
> + int fd = open("/dev/cma0", O_RDWR, 0);
> + int ret;
> + void *mem;
> +
> + if (fd < 0) {
> + printf("Can't open /dev/cma0\n");
> + return;
> + }
> +
> + memset(, 0, sizeof(data));
> +
> + data.length = LENGTH;
> + data.flags = O_RDWR | O_CLOEXEC;
> +
> + ret = ioctl(fd, SA_IOC_ALLOC, );
> + if (ret) {
> + printf("Buffer allocation failed\n");
> + goto end;
> + }
> +
> + mem = mmap(0, LENGTH, PROT_READ | PROT_WRITE, MAP_SHARED, data.fd, 0);
> + if (mem == MAP_FAILED) {
> + printf("mmap failed\n");
> + }
> +
> + memset(mem, 0xFF, LENGTH);
> + munmap(mem, LENGTH);
> +
> + printf("test simple allocator CMA OK\n");
> +end:
> + close(fd);
> +}
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index e1e2066..a6d8828 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> 

Re: Suffering Children

[Mrs. Queennet Hitachimo]

Greetings From My Sick Bed.

I Want To Donate USD15.5Million To Charity Through A Trusted And Sincere Person 
In Your Country. 

I Am Deeply Depressed After The Doctor Showed Up With The Results Of My 
Diagnoses Confirming That I Have Little Time To Live On Earth.

For Now, My Ailment Cannot Permit Me To Write Much, Other Detailed 
Information's Will Come Your Way As Soon As I Hear From You.

Reply If You Can Be Trusted.

Mrs. Queennet Hitachimo

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

[Krzysztof Kozlowski]

On Tue, Feb 14, 2017 at 08:52:08AM +0100, Marek Szyprowski wrote:
> During my research I found that some of the requirements for the memory
> buffers for MFC v6+ devices were blindly copied from the previous (v5)
> version and simply turned out to be excessive. The relaxed requirements
> are applied by the recent patches to the MFC driver and the driver is
> now fully functional even without the reserved memory blocks for all
> v6+ variants. This patch removes those reserved memory nodes from all
> boards having MFC v6+ hardware block.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  arch/arm/boot/dts/exynos5250-arndale.dts   | 1 -
>  arch/arm/boot/dts/exynos5250-smdk5250.dts  | 1 -
>  arch/arm/boot/dts/exynos5250-spring.dts| 1 -
>  arch/arm/boot/dts/exynos5420-arndale-octa.dts  | 1 -
>  arch/arm/boot/dts/exynos5420-peach-pit.dts | 1 -
>  arch/arm/boot/dts/exynos5420-smdk5420.dts  | 1 -
>  arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 1 -
>  arch/arm/boot/dts/exynos5800-peach-pi.dts  | 1 -
>  8 files changed, 8 deletions(-)
>

Looks okay (for v4.12). Full bisectability depends on changes in MFC
driver, right?  I will need a stable branch/tag with driver changes
(although recently Arnd did not want driver changes mixed with DTS...).


Best regards,
Krzysztof

Re: [PATCH v3 21/24] media: imx: Add MIPI CSI-2 Receiver subdev driver

[Philipp Zabel]

Hi Steve,

On Mon, 2017-02-13 at 15:20 -0800, Steve Longerbeam wrote:
[...]
> > It seems the OV5640 driver never puts its the CSI-2 lanes into stop
> > state while not streaming.
> 
> Yes I found that as well.
> 
> But good news, I finally managed to coax the OV5640's clock lane
> into LP-11 state! It was accomplished by setting bit 5 in OV5640 register
> 0x4800. The datasheet describes this bit as "Gate clock lane when no
> packet to transmit". But I may have also got this to work with the 
> additional
> write 1 to bits 4-6 in register 0x3019 ("MIPI CLK/data lane state in sleep
> mode" - setting 1 to these bits selects LP-11 for sleep mode).
> 
> So I am now finally able to call csi2_dphy_wait_stopstate() in
> csi2_s_stream(ON).

That's good news.

> So for the TC35874, you shouldn't see a timeout in csi2_s_stream(ON)
> any longer.
> 
> I have updated both ov5640.c and imx6-mipi-csi2.c in the wip branch.
> Can you try again? I have not applied your patch below, because I
> don't think that is needed anymore.

Thanks, I'll test tomorrow.

> And speaking of the TC35874, I received this module for the SabreLite
> from Boundary Devices (thanks BD!). So I can finally help you with
> debug/test. Are there any patches you need to send to me (against
> wip branch) for this support, or can I use what exists now in media
> tree? Also any scripts or help with running.

That's even better news. I have pushed my my wip branch, which contains
some colorspace work and experiments to pass through query/g_/s_std
subdev calls so bypassing the pipeline can be avoided. Also, there's the
Nitrogen6X device tree that I've been using to test:

https://git.pengutronix.de/git/pza/linux imx-media-staging-md-wip

> >   With the recent s_stream reordering,
> > streaming from TC358743 does not work anymore, since imx6-mipi-csi2
> > s_stream is called before tc358743 s_stream, while all lanes are still
> > in stop state. Then it waits for the clock lane to become active and
> > fails. I have applied the following patch to revert the reordering
> > locally to get it to work again.
> >
> > The initialization order, as Russell pointed out, should be:
> >
> > 1. reset the D-PHY.
> > 2. place MIPI sensor in LP-11 state
> > 3. perform D-PHY initialisation
> > 4. configure CSI2 lanes and de-assert resets and shutdown signals
> >
> > So csi2_s_stream should wait for stop state on all lanes (the result of
> > 2.) before dphy_init (3.), not wait for active clock afterwards. That
> > should happen only after sensor_s_stream was called. So unless we are
> > allowed to reorder steps 1. and 2., we might need the prepare_stream
> > callback after all.
> 
> Agreed!
> 
> See my new FIXME comment in imx6-mipi-csi2.c.

Looks good. I wonder if enabling the phy clock isn't part of step 3.
though.

> I agree we might need a new subdev op .prepare_stream(). This
> op would be implemented by imx6-mipi-csi2.c, and would carry
> out steps 3, 4, 5 (instead of currently by csi2_s_stream()). Then
> step 6 would finally become available as csi2_s_stream().
> 
> And then we must re-order stream on to start sensor first, then
> csi2, as in your patch below.

regards
Philipp

Re: [RFC simple allocator v2 0/2] Simple allocator

[Mark Brown]

On Mon, Feb 13, 2017 at 11:01:14AM -0800, Laura Abbott wrote:
> On 02/13/2017 10:18 AM, Mark Brown wrote:

> > The software defined networking people seemed to think they had a use
> > case for this as well.  They're not entirely upstream of course but
> > still...

> This is the first I've heard of anything like this. Do you have any more
> details/reading?

No, unfortunately it was in a meeting and I was asking for more details
on what specifically the hardware was doing myself.  My understanding is
that it's very similar to the GPU/video needs.


signature.asc
Description: PGP signature

Re: [PATCH] media: s5p-mfc: Fix initialization of internal structures

[Javier Martinez Canillas]

Hello Marek,

On 02/03/2017 11:05 AM, Marek Szyprowski wrote:
> Initialize members of the internal device and context structures as early
> as possible to avoid access to uninitialized objects on initialization
> failures. If loading firmware or creating of the hardware instance fails,
> driver will access device or context queue in error handling path, which
> might not be initialized yet, what causes kernel panic. Fix this by moving
> initialization of all static members as early as possible.
> 
> Signed-off-by: Marek Szyprowski 
> ---

Reviewed-by: Javier Martinez Canillas 

Also tested on an Exynos5422 Odroid XU4 and Exynos5800 Peach Pi:

Tested-by: Javier Martinez Canillas 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

Re: [RFC 06/13] v4l2-async: per notifier locking

[Sebastian Reichel]

Hi,

On Tue, Feb 14, 2017 at 02:39:56PM +0100, Pavel Machek wrote:
> From: Sebastian Reichel 
> 
> Without this, camera support breaks boot on N900.

That's kind of vague. I just checked my original patch and it looks
like I did not bother to write a proper patch description. I suggest
to make this

"Fix v4l2-async locking, so that v4l2_async_notifiers can be used
recursively. This is important for sensors, that are only reachable
by the image signal processor through some intermediate device."

You should probably move move this patch directly before the
video-bus-switch patch, since its a preparation for it.

Also this is missing my SoB:

Signed-off-by: Sebastian Reichel 

> Signed-off-by: Ivaylo Dimitrov 
> ---
>  drivers/media/v4l2-core/v4l2-async.c | 54 
> ++--
>  include/media/v4l2-async.h   |  2 ++
>  2 files changed, 29 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> b/drivers/media/v4l2-core/v4l2-async.c
> index 96cc733..26492a2 100644
> --- a/drivers/media/v4l2-core/v4l2-async.c
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -57,7 +57,6 @@ static bool match_custom(struct v4l2_subdev *sd, struct 
> v4l2_async_subdev *asd)
>  
>  static LIST_HEAD(subdev_list);
>  static LIST_HEAD(notifier_list);
> -static DEFINE_MUTEX(list_lock);
>  
>  static struct v4l2_async_subdev *v4l2_async_belongs(struct 
> v4l2_async_notifier *notifier,
>   struct v4l2_subdev *sd)
> @@ -102,12 +101,15 @@ static int v4l2_async_test_notify(struct 
> v4l2_async_notifier *notifier,
>  
>   if (notifier->bound) {
>   ret = notifier->bound(notifier, sd, asd);
> - if (ret < 0)
> + if (ret < 0) {
> + dev_warn(notifier->v4l2_dev->dev, "subdev bound 
> failed\n");
>   return ret;
> + }
>   }
>  
>   ret = v4l2_device_register_subdev(notifier->v4l2_dev, sd);
>   if (ret < 0) {
> + dev_warn(notifier->v4l2_dev->dev, "subdev register failed\n");
>   if (notifier->unbind)
>   notifier->unbind(notifier, sd, asd);
>   return ret;
> @@ -141,7 +143,7 @@ int v4l2_async_notifier_register(struct v4l2_device 
> *v4l2_dev,
>  {
>   struct v4l2_subdev *sd, *tmp;
>   struct v4l2_async_subdev *asd;
> - int i;
> + int ret = 0, i;
>  
>   if (!notifier->num_subdevs || notifier->num_subdevs > V4L2_MAX_SUBDEVS)
>   return -EINVAL;
> @@ -149,6 +151,7 @@ int v4l2_async_notifier_register(struct v4l2_device 
> *v4l2_dev,
>   notifier->v4l2_dev = v4l2_dev;
>   INIT_LIST_HEAD(>waiting);
>   INIT_LIST_HEAD(>done);
> + mutex_init(>lock);
>  
>   for (i = 0; i < notifier->num_subdevs; i++) {
>   asd = notifier->subdevs[i];
> @@ -168,28 +171,22 @@ int v4l2_async_notifier_register(struct v4l2_device 
> *v4l2_dev,
>   list_add_tail(>list, >waiting);
>   }
>  
> - mutex_lock(_lock);
> + /* Keep also completed notifiers on the list */
> + list_add(>list, _list);
> + mutex_lock(>lock);
>  
>   list_for_each_entry_safe(sd, tmp, _list, async_list) {
> - int ret;
> -
>   asd = v4l2_async_belongs(notifier, sd);
>   if (!asd)
>   continue;
>  
>   ret = v4l2_async_test_notify(notifier, sd, asd);
> - if (ret < 0) {
> - mutex_unlock(_lock);
> - return ret;
> - }
> + if (ret < 0)
> + break;
>   }
> + mutex_unlock(>lock);
>  
> - /* Keep also completed notifiers on the list */
> - list_add(>list, _list);
> -
> - mutex_unlock(_lock);
> -
> - return 0;
> + return ret;
>  }
>  EXPORT_SYMBOL(v4l2_async_notifier_register);
>  
> @@ -210,7 +207,7 @@ void v4l2_async_notifier_unregister(struct 
> v4l2_async_notifier *notifier)
>   "Failed to allocate device cache!\n");
>   }
>  
> - mutex_lock(_lock);
> + mutex_lock(>lock);
>  
>   list_del(>list);
>  
> @@ -237,7 +234,7 @@ void v4l2_async_notifier_unregister(struct 
> v4l2_async_notifier *notifier)
>   put_device(d);
>   }
>  
> - mutex_unlock(_lock);
> + mutex_unlock(>lock);
>  
>   /*
>* Call device_attach() to reprobe devices
> @@ -262,6 +259,7 @@ void v4l2_async_notifier_unregister(struct 
> v4l2_async_notifier *notifier)
>   }
>   kfree(dev);
>  
> + mutex_destroy(>lock);
>   notifier->v4l2_dev = NULL;
>  
>   /*
> @@ -274,6 +272,7 @@ EXPORT_SYMBOL(v4l2_async_notifier_unregister);
>  int v4l2_async_register_subdev(struct v4l2_subdev *sd)
>  {
>   struct v4l2_async_notifier *notifier;
> + struct v4l2_async_notifier *tmp;
>  
>   /*
>* No reference taken. The reference is held 

Re: [PATCH v4 1/4] [media] exynos-gsc: Use 576p instead 720p as a threshold for colorspaces

[Fabien DESSENNE]

Hi Thibault


On 13/02/17 20:08, Thibault Saunier wrote:
> From: Javier Martinez Canillas 
>
> The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace
> should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV. But drivers
> don't agree on the display resolution that should be used as a threshold.
>
>  From EIA CEA 861B about colorimetry for various resolutions:
>
>- 5.1 480p, 480i, 576p, 576i, 240p, and 288p
>  The color space used by the 480-line, 576-line, 240-line, and 288-line
>  formats will likely be based on SMPTE 170M [1].
>- 5.2 1080i, 1080p, and 720p
>  The color space used by the high definition formats will likely be
>  based on ITU-R BT.709-4
>
> This indicates that in the case that userspace does not specify what
> colorspace should be used, we should use 576p  as a threshold to set
> V4L2_COLORSPACE_REC709 instead of V4L2_COLORSPACE_REC709. Even if it is

typo -> "V4L2_COLORSPACE_REC709 instead of V4L2_COLORSPACE_SMPTE170M"


> only 'likely' and not a requirement it is the best guess we can make.
>
> The stream should have been encoded with the information and userspace
> has to pass it to the driver if it is not the case, otherwise we won't be
> able to handle it properly anyhow.
>
> Also, check for the resolution in G_FMT instead unconditionally setting
> the V4L2_COLORSPACE_REC709 colorspace.
>
> Signed-off-by: Javier Martinez Canillas 
> Signed-off-by: Thibault Saunier 
> Reviewed-by: Andrzej Hajda 
>
> ---
>
> Changes in v4:
> - Reword commit message to better back our assumptions on specifications
>
> Changes in v3:
> - Do not check values in the g_fmt functions as Andrzej explained in previous 
> review
> - Added 'Reviewed-by: Andrzej Hajda '
>
> Changes in v2: None
>
>   drivers/media/platform/exynos-gsc/gsc-core.c | 8 ++--
>   1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
> b/drivers/media/platform/exynos-gsc/gsc-core.c
> index 59a634201830..db7d9883861b 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-core.c
> +++ b/drivers/media/platform/exynos-gsc/gsc-core.c
> @@ -472,7 +472,7 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
> v4l2_format *f)
>   
>   pix_mp->num_planes = fmt->num_planes;
>   
> - if (pix_mp->width >= 1280) /* HD */
> + if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
>   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
>   else /* SD */
>   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
> @@ -519,9 +519,13 @@ int gsc_g_fmt_mplane(struct gsc_ctx *ctx, struct 
> v4l2_format *f)
>   pix_mp->height  = frame->f_height;
>   pix_mp->field   = V4L2_FIELD_NONE;
>   pix_mp->pixelformat = frame->fmt->pixelformat;
> - pix_mp->colorspace  = V4L2_COLORSPACE_REC709;
>   pix_mp->num_planes  = frame->fmt->num_planes;
>   
> + if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
> + pix_mp->colorspace = V4L2_COLORSPACE_REC709;
> + else /* SD */
> + pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
> +
>   for (i = 0; i < pix_mp->num_planes; ++i) {
>   pix_mp->plane_fmt[i].bytesperline = (frame->f_width *
>   frame->fmt->depth[i]) / 8;

BR
Fabien

[RFC 04/13] omap3isp: add support for CSI1 bus

[Pavel Machek]

Obtain the CSI1/CCP2 bus parameters from the OF node.

ISP CSI1 module needs all the bits correctly set to work.

OMAP3430 needs various syscon CONTROL_CSIRXFE bits set in order to
operate. Implement the missing functionality.

[FIXME: Laurent has some comments here]

Signed-off-by: Sakari Ailus 
Signed-off-by: Ivaylo Dimitrov 
Signed-off-by: Pavel Machek 
---
 drivers/media/platform/omap3isp/isp.c  | 158 +
 drivers/media/platform/omap3isp/isp.h  |   2 +-
 drivers/media/platform/omap3isp/ispccp2.c  |  42 +++-
 drivers/media/platform/omap3isp/ispreg.h   |   4 +
 drivers/media/platform/omap3isp/omap3isp.h |   1 +
 5 files changed, 159 insertions(+), 48 deletions(-)

diff --git a/drivers/media/platform/omap3isp/isp.c 
b/drivers/media/platform/omap3isp/isp.c
index 084ecf4a..61b7359 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -2024,21 +2024,92 @@ enum isp_of_phy {
ISP_OF_PHY_CSIPHY2,
 };
 
-static int isp_of_parse_node(struct device *dev, struct device_node *node,
-struct isp_async_subdev *isd)
+void __isp_of_parse_node_csi1(struct device *dev,
+  struct isp_ccp2_cfg *buscfg,
+  struct v4l2_of_endpoint *vep)
+{
+   buscfg->lanecfg.clk.pos = vep->bus.mipi_csi1.clock_lane;
+   buscfg->lanecfg.clk.pol =
+   vep->bus.mipi_csi1.lane_polarity[0];
+   dev_dbg(dev, "clock lane polarity %u, pos %u\n",
+   buscfg->lanecfg.clk.pol,
+   buscfg->lanecfg.clk.pos);
+
+   buscfg->lanecfg.data[0].pos = vep->bus.mipi_csi2.data_lanes[0];
+   buscfg->lanecfg.data[0].pol =
+   vep->bus.mipi_csi2.lane_polarities[1];
+   dev_dbg(dev, "data lane polarity %u, pos %u\n",
+   buscfg->lanecfg.data[0].pol,
+   buscfg->lanecfg.data[0].pos);
+
+   buscfg->strobe_clk_pol = vep->bus.mipi_csi1.clock_inv;
+   buscfg->phy_layer = vep->bus.mipi_csi1.strobe;
+   buscfg->ccp2_mode = vep->bus_type == V4L2_MBUS_CCP2;
+
+   dev_dbg(dev, "clock_inv %u strobe %u ccp2 %u\n",
+   buscfg->strobe_clk_pol,
+   buscfg->phy_layer,
+   buscfg->ccp2_mode);
+   /*
+* FIXME: now we assume the CRC is always there.
+* Implement a way to obtain this information from the
+* sensor. Frame descriptors, perhaps?
+*/
+   buscfg->crc = 1;
+
+   buscfg->vp_clk_pol = 1;
+}
+
+static void isp_of_parse_node_csi1(struct device *dev,
+  struct isp_bus_cfg *buscfg,
+  struct v4l2_of_endpoint *vep)
+{
+   if (vep->base.port == ISP_OF_PHY_CSIPHY1)
+   buscfg->interface = ISP_INTERFACE_CCP2B_PHY1;
+   else
+   buscfg->interface = ISP_INTERFACE_CCP2B_PHY2;
+   __isp_of_parse_node_csi1(dev, >bus.ccp2, vep);
+}
+
+static void isp_of_parse_node_csi2(struct device *dev,
+  struct isp_bus_cfg *buscfg,
+  struct v4l2_of_endpoint *vep)
 {
-   struct isp_bus_cfg *buscfg = >bus;
-   struct v4l2_of_endpoint vep;
unsigned int i;
-   int ret;
 
-   ret = v4l2_of_parse_endpoint(node, );
-   if (ret)
-   return ret;
+   if (vep->base.port == ISP_OF_PHY_CSIPHY1)
+   buscfg->interface = ISP_INTERFACE_CSI2C_PHY1;
+   else
+   buscfg->interface = ISP_INTERFACE_CSI2A_PHY2;
+   buscfg->bus.csi2.lanecfg.clk.pos = vep->bus.mipi_csi2.clock_lane;
+   buscfg->bus.csi2.lanecfg.clk.pol =
+   vep->bus.mipi_csi2.lane_polarities[0];
+   dev_dbg(dev, "clock lane polarity %u, pos %u\n",
+   buscfg->bus.csi2.lanecfg.clk.pol,
+   buscfg->bus.csi2.lanecfg.clk.pos);
+
+   for (i = 0; i < ISP_CSIPHY2_NUM_DATA_LANES; i++) {
+   buscfg->bus.csi2.lanecfg.data[i].pos =
+   vep->bus.mipi_csi2.data_lanes[i];
+   buscfg->bus.csi2.lanecfg.data[i].pol =
+   vep->bus.mipi_csi2.lane_polarities[i + 1];
+   dev_dbg(dev, "data lane %u polarity %u, pos %u\n", i,
+   buscfg->bus.csi2.lanecfg.data[i].pol,
+   buscfg->bus.csi2.lanecfg.data[i].pos);
+   }
 
-   dev_dbg(dev, "parsing endpoint %s, interface %u\n", node->full_name,
-   vep.base.port);
+   /*
+* FIXME: now we assume the CRC is always there.
+* Implement a way to obtain this information from the
+* sensor. Frame descriptors, perhaps?
+*/
+   buscfg->bus.csi2.crc = 1;
+}
 
+static int isp_endpoint_to_buscfg(struct device *dev,
+ struct v4l2_of_endpoint vep,
+ struct isp_bus_cfg *buscfg)
+{

Re: [RFC 04/13] omap3isp: add support for CSI1 bus

[Pavel Machek]

Hi!

> Obtain the CSI1/CCP2 bus parameters from the OF node.
> 
> ISP CSI1 module needs all the bits correctly set to work.
> 
> OMAP3430 needs various syscon CONTROL_CSIRXFE bits set in order to
> operate. Implement the missing functionality.
> 
> [FIXME: Laurent has some comments here]
> 
> Signed-off-by: Sakari Ailus 
> Signed-off-by: Ivaylo Dimitrov 
> Signed-off-by: Pavel Machek 

Ok, Sakari wanted patch series, so here it goes.

Patches from this one on are for illustration -- I still need to fix
them up. 1-3, I'd like to see merged, so if you have some comments
there, go on.

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v3 0/7] Add V4L2 SDR (DRIF & MAX2175) driver

[Laurent Pinchart]

Hi Hans,

On Monday 13 Feb 2017 13:46:08 Hans Verkuil wrote:
> On 02/07/2017 04:02 PM, Ramesh Shanmugasundaram wrote:
> > 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-tree repo
> > commit: 47b037a0512d9f8675ec2693bed46c8ea6a884ab
> > 
> > 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].
> Other than the single comment I had it all looks good. Once I have Acks for
> the bindings and from Laurent for the rcar part I can merge it.

Just FYI, I won't have time to review this before March at the earliest.

-- 
Regards,

Laurent Pinchart

[RFC 05/13] omap3isp: Add subdevices support

[Pavel Machek]

Add subdevices support to omap3isp. It is neccessary for connecting
subdevices (camera flash and autofocus coil) for N900 camera subsystem.

Signed-off-by: Sakari Ailus 
Signed-off-by: Pavel Machek 
---
 drivers/media/platform/omap3isp/isp.c   | 128 ++--
 drivers/media/platform/omap3isp/isp.h   |   1 +
 drivers/media/platform/omap3isp/ispcsiphy.c |   2 +-
 3 files changed, 102 insertions(+), 29 deletions(-)

diff --git a/drivers/media/platform/omap3isp/isp.c 
b/drivers/media/platform/omap3isp/isp.c
index 61b7359..edc4300 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -42,6 +42,8 @@
  * published by the Free Software Foundation.
  */
 
+#define DEBUG
+
 #include 
 
 #include 
@@ -699,7 +701,7 @@ static int isp_pipeline_enable(struct isp_pipeline *pipe,
spin_unlock_irqrestore(>lock, flags);
 
pipe->do_propagation = false;
-
+   
entity = >output->video.entity;
while (1) {
pad = >pads[0];
@@ -2059,7 +2061,7 @@ void __isp_of_parse_node_csi1(struct device *dev,
 
buscfg->vp_clk_pol = 1;
 }
-
+   
 static void isp_of_parse_node_csi1(struct device *dev,
   struct isp_bus_cfg *buscfg,
   struct v4l2_of_endpoint *vep)
@@ -2106,9 +2108,7 @@ static void isp_of_parse_node_csi2(struct device *dev,
buscfg->bus.csi2.crc = 1;
 }
 
-static int isp_endpoint_to_buscfg(struct device *dev,
- struct v4l2_of_endpoint vep,
- struct isp_bus_cfg *buscfg)
+static int isp_endpoint_to_buscfg(struct device *dev, struct v4l2_of_endpoint 
vep, struct isp_bus_cfg *buscfg)
 {
switch (vep.base.port) {
case ISP_OF_PHY_PARALLEL:
@@ -2170,10 +2170,51 @@ static int isp_of_parse_node_endpoint(struct device 
*dev,
return 0;
 }
 
+static int isp_of_parse_node(struct device *dev, struct device_node *node,
+struct v4l2_async_notifier *notifier,
+u32 group_id, bool link)
+{
+   struct isp_async_subdev *isd;
+
+   isd = devm_kzalloc(dev, sizeof(*isd), GFP_KERNEL);
+   if (!isd) {
+   of_node_put(node);
+   return -ENOMEM;
+   }
+
+   notifier->subdevs[notifier->num_subdevs] = >asd;
+
+   if (link) {
+   if (isp_of_parse_node_endpoint(dev, node, isd)) {
+   of_node_put(node);
+   return -EINVAL;
+   }
+
+   isd->asd.match.of.node = of_graph_get_remote_port_parent(node);
+   of_node_put(node);
+   } else {
+   isd->asd.match.of.node = node;
+   }
+
+   if (!isd->asd.match.of.node) {
+   dev_warn(dev, "bad remote port parent\n");
+   return -EINVAL;
+   }
+
+   isd->asd.match_type = V4L2_ASYNC_MATCH_OF;
+   isd->group_id = group_id;
+   notifier->num_subdevs++;
+
+   return 0;
+}
+
 static int isp_of_parse_nodes(struct device *dev,
  struct v4l2_async_notifier *notifier)
 {
struct device_node *node = NULL;
+   int ret;
+   unsigned int flash = 0;
+   u32 group_id = 0;
 
notifier->subdevs = devm_kcalloc(
dev, ISP_MAX_SUBDEVS, sizeof(*notifier->subdevs), GFP_KERNEL);
@@ -2182,32 +2223,60 @@ static int isp_of_parse_nodes(struct device *dev,
 
while (notifier->num_subdevs < ISP_MAX_SUBDEVS &&
   (node = of_graph_get_next_endpoint(dev->of_node, node))) {
-   struct isp_async_subdev *isd;
+   ret = isp_of_parse_node(dev, node, notifier, group_id++, true);
+   if (ret)
+   return ret;
+   }
 
-   isd = devm_kzalloc(dev, sizeof(*isd), GFP_KERNEL);
-   if (!isd)
-   goto error;
+   while (notifier->num_subdevs < ISP_MAX_SUBDEVS &&
+  (node = of_parse_phandle(dev->of_node, "ti,camera-flashes",
+   flash++))) {
+   struct device_node *sensor_node =
+   of_parse_phandle(dev->of_node, "ti,camera-flashes",
+flash++);
+   unsigned int i;
+   u32 flash_group_id;
 
-   notifier->subdevs[notifier->num_subdevs] = >asd;
+   if (!sensor_node)
+   return -EINVAL;
 
-   if (isp_of_parse_node_endpoint(dev, node, isd))
-   goto error;
+   for (i = 0; i < notifier->num_subdevs; i++) {
+   struct isp_async_subdev *isd = container_of(
+   notifier->subdevs[i], struct isp_async_subdev,
+   asd);
 
-   isd->asd.match.of.node = of_graph_get_remote_port_parent(node);
-   

[RFC 06/13] v4l2-async: per notifier locking

[Pavel Machek]

From: Sebastian Reichel 

Without this, camera support breaks boot on N900.

Signed-off-by: Ivaylo Dimitrov 
---
 drivers/media/v4l2-core/v4l2-async.c | 54 ++--
 include/media/v4l2-async.h   |  2 ++
 2 files changed, 29 insertions(+), 27 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-async.c 
b/drivers/media/v4l2-core/v4l2-async.c
index 96cc733..26492a2 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -57,7 +57,6 @@ static bool match_custom(struct v4l2_subdev *sd, struct 
v4l2_async_subdev *asd)
 
 static LIST_HEAD(subdev_list);
 static LIST_HEAD(notifier_list);
-static DEFINE_MUTEX(list_lock);
 
 static struct v4l2_async_subdev *v4l2_async_belongs(struct v4l2_async_notifier 
*notifier,
struct v4l2_subdev *sd)
@@ -102,12 +101,15 @@ static int v4l2_async_test_notify(struct 
v4l2_async_notifier *notifier,
 
if (notifier->bound) {
ret = notifier->bound(notifier, sd, asd);
-   if (ret < 0)
+   if (ret < 0) {
+   dev_warn(notifier->v4l2_dev->dev, "subdev bound 
failed\n");
return ret;
+   }
}
 
ret = v4l2_device_register_subdev(notifier->v4l2_dev, sd);
if (ret < 0) {
+   dev_warn(notifier->v4l2_dev->dev, "subdev register failed\n");
if (notifier->unbind)
notifier->unbind(notifier, sd, asd);
return ret;
@@ -141,7 +143,7 @@ int v4l2_async_notifier_register(struct v4l2_device 
*v4l2_dev,
 {
struct v4l2_subdev *sd, *tmp;
struct v4l2_async_subdev *asd;
-   int i;
+   int ret = 0, i;
 
if (!notifier->num_subdevs || notifier->num_subdevs > V4L2_MAX_SUBDEVS)
return -EINVAL;
@@ -149,6 +151,7 @@ int v4l2_async_notifier_register(struct v4l2_device 
*v4l2_dev,
notifier->v4l2_dev = v4l2_dev;
INIT_LIST_HEAD(>waiting);
INIT_LIST_HEAD(>done);
+   mutex_init(>lock);
 
for (i = 0; i < notifier->num_subdevs; i++) {
asd = notifier->subdevs[i];
@@ -168,28 +171,22 @@ int v4l2_async_notifier_register(struct v4l2_device 
*v4l2_dev,
list_add_tail(>list, >waiting);
}
 
-   mutex_lock(_lock);
+   /* Keep also completed notifiers on the list */
+   list_add(>list, _list);
+   mutex_lock(>lock);
 
list_for_each_entry_safe(sd, tmp, _list, async_list) {
-   int ret;
-
asd = v4l2_async_belongs(notifier, sd);
if (!asd)
continue;
 
ret = v4l2_async_test_notify(notifier, sd, asd);
-   if (ret < 0) {
-   mutex_unlock(_lock);
-   return ret;
-   }
+   if (ret < 0)
+   break;
}
+   mutex_unlock(>lock);
 
-   /* Keep also completed notifiers on the list */
-   list_add(>list, _list);
-
-   mutex_unlock(_lock);
-
-   return 0;
+   return ret;
 }
 EXPORT_SYMBOL(v4l2_async_notifier_register);
 
@@ -210,7 +207,7 @@ void v4l2_async_notifier_unregister(struct 
v4l2_async_notifier *notifier)
"Failed to allocate device cache!\n");
}
 
-   mutex_lock(_lock);
+   mutex_lock(>lock);
 
list_del(>list);
 
@@ -237,7 +234,7 @@ void v4l2_async_notifier_unregister(struct 
v4l2_async_notifier *notifier)
put_device(d);
}
 
-   mutex_unlock(_lock);
+   mutex_unlock(>lock);
 
/*
 * Call device_attach() to reprobe devices
@@ -262,6 +259,7 @@ void v4l2_async_notifier_unregister(struct 
v4l2_async_notifier *notifier)
}
kfree(dev);
 
+   mutex_destroy(>lock);
notifier->v4l2_dev = NULL;
 
/*
@@ -274,6 +272,7 @@ EXPORT_SYMBOL(v4l2_async_notifier_unregister);
 int v4l2_async_register_subdev(struct v4l2_subdev *sd)
 {
struct v4l2_async_notifier *notifier;
+   struct v4l2_async_notifier *tmp;
 
/*
 * No reference taken. The reference is held by the device
@@ -283,24 +282,25 @@ int v4l2_async_register_subdev(struct v4l2_subdev *sd)
if (!sd->of_node && sd->dev)
sd->of_node = sd->dev->of_node;
 
-   mutex_lock(_lock);
-
INIT_LIST_HEAD(>async_list);
 
-   list_for_each_entry(notifier, _list, list) {
-   struct v4l2_async_subdev *asd = v4l2_async_belongs(notifier, 
sd);
+   list_for_each_entry_safe(notifier, tmp, _list, list) {
+   struct v4l2_async_subdev *asd;
+
+   /* TODO: FIXME: if this is called by ->bound() we will also 
iterate over the locked notifier */
+   mutex_lock_nested(>lock, SINGLE_DEPTH_NESTING);
+   asd = v4l2_async_belongs(notifier, sd);
if 

[RFC 01/13] Core changes for CCP2/CSI1 support.

[Pavel Machek]

From: Sakari Ailus 

CCP2, or CSI-1, is an older single data lane serial bus. Add core
support neccessary for it.

Signed-off-by: Sakari Ailus 
Signed-off-by: Ivaylo Dimitrov 
Signed-off-by: Pavel Machek 
---
 include/media/v4l2-mediabus.h |  4 
 include/media/v4l2-of.h   | 17 +
 2 files changed, 21 insertions(+)

diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h
index 34cc99e..315c167 100644
--- a/include/media/v4l2-mediabus.h
+++ b/include/media/v4l2-mediabus.h
@@ -69,11 +69,15 @@
  * @V4L2_MBUS_PARALLEL:parallel interface with hsync and vsync
  * @V4L2_MBUS_BT656:   parallel interface with embedded synchronisation, can
  * also be used for BT.1120
+ * @V4L2_MBUS_CSI1:MIPI CSI-1 serial interface
+ * @V4L2_MBUS_CCP2:CCP2 (Compact Camera Port 2)
  * @V4L2_MBUS_CSI2:MIPI CSI-2 serial interface
  */
 enum v4l2_mbus_type {
V4L2_MBUS_PARALLEL,
V4L2_MBUS_BT656,
+   V4L2_MBUS_CSI1,
+   V4L2_MBUS_CCP2,
V4L2_MBUS_CSI2,
 };
 
diff --git a/include/media/v4l2-of.h b/include/media/v4l2-of.h
index 4dc34b2..63a52ee 100644
--- a/include/media/v4l2-of.h
+++ b/include/media/v4l2-of.h
@@ -53,6 +53,22 @@ struct v4l2_of_bus_parallel {
 };
 
 /**
+ * struct v4l2_of_bus_csi1 - CSI-1/CCP2 data bus structure
+ * @clock_inv: polarity of clock/strobe signal
+ *false - not inverted, true - inverted
+ * @strobe: false - data/clock, true - data/strobe
+ * @data_lane: the number of the data lane
+ * @clock_lane: the number of the clock lane
+ */
+struct v4l2_of_bus_mipi_csi1 {
+   bool clock_inv;
+   bool strobe;
+   bool lane_polarity[2];
+   unsigned char data_lane;
+   unsigned char clock_lane;
+};
+
+/**
  * struct v4l2_of_endpoint - the endpoint data structure
  * @base: struct of_endpoint containing port, id, and local of_node
  * @bus_type: bus type
@@ -66,6 +82,7 @@ struct v4l2_of_endpoint {
enum v4l2_mbus_type bus_type;
union {
struct v4l2_of_bus_parallel parallel;
+   struct v4l2_of_bus_mipi_csi1 mipi_csi1;
struct v4l2_of_bus_mipi_csi2 mipi_csi2;
} bus;
u64 *link_frequencies;
-- 
2.1.4


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

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

[Pavel Machek]

Probably something fun happening in userspace.
---
 arch/arm/mach-omap2/Makefile |  1 +
 arch/arm/mach-omap2/board-rx51-peripherals.c | 51 
 2 files changed, 52 insertions(+)
 create mode 100644 arch/arm/mach-omap2/board-rx51-peripherals.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 4698940..d536b1a 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -229,6 +229,7 @@ obj-$(CONFIG_SOC_OMAP2420)  += msdi.o
 # Specific board support
 obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o 
pdata-quirks.o
 obj-$(CONFIG_MACH_NOKIA_N8X0)  += board-n8x0.o
+obj-y  += board-rx51-peripherals.o
 
 # Platform specific device init code
 
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c 
b/arch/arm/mach-omap2/board-rx51-peripherals.c
new file mode 100644
index 000..641c2be
--- /dev/null
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -0,0 +1,51 @@
+/*
+ * linux/arch/arm/mach-omap2/board-rx51-peripherals.c
+ *
+ * Copyright (C) 2008-2009 Nokia
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct platform_driver gpio_sw_driver = {
+   .driver = {
+   .name   = "gpio-switch",
+   },
+};
+
+static int __init gpio_sw_init(void)
+{
+   int r;
+
+   printk(KERN_INFO "OMAP GPIO switch handler initializing\n");
+
+   r = platform_driver_register(_sw_driver);
+   if (r)
+   return r;
+
+   platform_device_register_simple("gpio-switch",
+  -1, NULL, 0);
+   return 0;
+}
+
+static void __exit gpio_sw_exit(void)
+{
+}
+
+#ifndef MODULE
+late_initcall(gpio_sw_init);
+#else
+module_init(gpio_sw_init);
+#endif
+module_exit(gpio_sw_exit);
-- 
2.1.4


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[RFC 10/13] omap3isp: fix capture

[Pavel Machek]

This is neccessary for capture (not preview) to work properly on
N900. Why is unknown.
---
 drivers/media/platform/omap3isp/ispccdc.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/omap3isp/ispccdc.c 
b/drivers/media/platform/omap3isp/ispccdc.c
index 7207558..2fb755f 100644
--- a/drivers/media/platform/omap3isp/ispccdc.c
+++ b/drivers/media/platform/omap3isp/ispccdc.c
@@ -1186,7 +1186,8 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
/* Use the raw, unprocessed data when writing to memory. The H3A and
 * histogram modules are still fed with lens shading corrected data.
 */
-   syn_mode &= ~ISPCCDC_SYN_MODE_VP2SDR;
+// syn_mode &= ~ISPCCDC_SYN_MODE_VP2SDR;
+   syn_mode |= ISPCCDC_SYN_MODE_VP2SDR;
 
if (ccdc->output & CCDC_OUTPUT_MEMORY)
syn_mode |= ISPCCDC_SYN_MODE_WEN;
@@ -1253,6 +1254,8 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
<< ISPCCDC_VERT_LINES_NLV_SHIFT,
   OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VERT_LINES);
 
+   printk("configuring for %d(%d)x%d\n", crop->width, 
ccdc->video_out.bpl_value, crop->height);
+
ccdc_config_outlineoffset(ccdc, ccdc->video_out.bpl_value,
  format->field);
 
-- 
2.1.4


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[RFC 12/13] Enable camera on N900.

[Pavel Machek]

---
 arch/arm/boot/dts/omap3-n900.dts | 158 ++-
 1 file changed, 157 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 87ca50b..aa4170f9 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -144,6 +144,59 @@
io-channel-names = "temp", "bsi", "vbat";
};
 
+   rear_camera: camera@0 {
+   compatible = "linux,camera";
+
+   module {
+   model = "TCM8341MD";
+   sensor = <>;
+   };
+   };
+
+   front_camera: camera@1 {
+   compatible = "linux,camera";
+
+   module {
+   model = "VS6555";
+   sensor = <>;
+   };
+   };
+
+   video-bus-switch {
+   compatible = "video-bus-switch-gpio";
+
+   switch-gpios = < 1 GPIO_ACTIVE_HIGH>; /* 97 */
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   csi_switch_in: endpoint {
+   remote-endpoint = <_isp>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   csi_switch_out1: endpoint {
+   remote-endpoint = <_cam1>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+
+   csi_switch_out2: endpoint {
+   remote-endpoint = <_cam2>;
+   };
+   };
+   };
+   };
+
pwm9: dmtimer-pwm {
compatible = "ti,omap-dmtimer-pwm";
#pwm-cells = <3>;
@@ -157,6 +210,32 @@
};
 };
 
+ {
+   vdds_csib-supply = <>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   ti,camera-flashes = <   >;
+
+   ports {
+   port@1 {
+   reg = <1>;
+
+   csi_isp: endpoint {
+   remote-endpoint = <_switch_in>;
+   bus-type = <3>; /* CCP2 */
+   clock-lanes = <0>;
+   data-lanes = <1>;
+   lane-polarity = <0 0>;
+   clock-inv = <0>;
+   /* Select strobe = <1> for back camera, <0> for 
front camera */
+   strobe = <1>;
+   crc = <0>;
+   };
+   };
+   };
+};
+
 _pmx_core {
pinctrl-names = "default";
 
@@ -319,6 +398,22 @@
OMAP3_CORE1_IOPAD(0x218e, PIN_OUTPUT | MUX_MODE4)   
/* gpio 157 => cmt_bsi */
>;
};
+
+   camera_pins: pinmux_camera {
+   pinctrl-single,pins = <
+   OMAP3_CORE1_IOPAD(0x210c, PIN_OUTPUT | MUX_MODE7)   
/* cam_hs */
+   OMAP3_CORE1_IOPAD(0x210e, PIN_OUTPUT | MUX_MODE7)   
/* cam_vs */
+   OMAP3_CORE1_IOPAD(0x2110, PIN_OUTPUT | MUX_MODE0)   
/* cam_xclka */
+   OMAP3_CORE1_IOPAD(0x211e, PIN_OUTPUT | MUX_MODE7)   
/* cam_d4 */
+   OMAP3_CORE1_IOPAD(0x2122, PIN_INPUT | MUX_MODE0)
/* cam_d6 */
+   OMAP3_CORE1_IOPAD(0x2124, PIN_INPUT | MUX_MODE0)
/* cam_d7 */
+   OMAP3_CORE1_IOPAD(0x2126, PIN_INPUT | MUX_MODE0)
/* cam_d8 */
+   OMAP3_CORE1_IOPAD(0x2128, PIN_INPUT | MUX_MODE0)
/* cam_d9 */
+   OMAP3_CORE1_IOPAD(0x212a, PIN_OUTPUT | MUX_MODE7)   
/* cam_d10 */
+   OMAP3_CORE1_IOPAD(0x212e, PIN_OUTPUT | MUX_MODE7)   
/* cam_xclkb */
+   OMAP3_CORE1_IOPAD(0x2132, PIN_OUTPUT | MUX_MODE0)   
/* cam_strobe */
+   >;
+   };
 };
 
  {
@@ -507,6 +602,28 @@
 
clock-frequency = <10>;
 
+   cam2: camera@10 {
+   compatible = "nokia,smia";
+   reg = <0x10>;
+
+   vana-supply = <>;
+
+   clocks = < 0>;
+   clock-frequency = <960>;
+
+   port {
+   csi_cam2: endpoint {
+   link-frequencies = /bits/ 64 <6000>;
+   bus-type = <3>; /* CCP2 */
+   strobe = <0>;
+   clock-inv = <0>;
+   crc = <0>;
+
+   remote-endpoint = <_switch_out2>;

[RFC 09/13] media: Add video bus switch

[Pavel Machek]

N900 contains front and back camera, with a switch between the
two. This adds support for the switch component, and it is now
possible to select between front and back cameras during runtime.

FIXME: need to get acks and merge device tree support.

Signed-off-by: Sebastian Reichel 
Signed-off-by: Ivaylo Dimitrov 
Signed-off-by: Pavel Machek 
---
 .config   |   1 +
 drivers/media/platform/Kconfig|  10 +
 drivers/media/platform/Makefile   |   2 +
 drivers/media/platform/omap3isp/ispccp2.c |  23 +-
 drivers/media/platform/video-bus-switch.c | 389 ++
 include/media/v4l2-subdev.h   |   9 +-
 include/uapi/linux/media.h|   2 +
 7 files changed, 432 insertions(+), 4 deletions(-)
 create mode 100644 drivers/media/platform/video-bus-switch.c

diff --git a/.config b/.config
index 611fdb8..0f2bdd8 100644
--- a/.config
+++ b/.config
@@ -2128,6 +2128,7 @@ CONFIG_V4L_PLATFORM_DRIVERS=y
 # CONFIG_VIDEO_OMAP2_VOUT is not set
 CONFIG_VIDEO_OMAP3=y
 # CONFIG_VIDEO_OMAP3_DEBUG is not set
+CONFIG_VIDEO_BUS_SWITCH=y
 # CONFIG_SOC_CAMERA is not set
 # CONFIG_VIDEO_XILINX is not set
 # CONFIG_V4L_MEM2MEM_DRIVERS is not set
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index c9106e1..b35f11b 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -91,6 +91,16 @@ config VIDEO_OMAP3_DEBUG
---help---
  Enable debug messages on OMAP 3 camera controller driver.
 
+config VIDEO_BUS_SWITCH
+   tristate "Video Bus switch"
+   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   depends on MEDIA_CONTROLLER
+   depends on OF
+   ---help---
+ Driver for a GPIO controlled video bus switch, which is used to
+ connect two camera sensors to the same port a the image signal
+ processor.
+
 config VIDEO_PXA27x
tristate "PXA27x Quick Capture Interface driver"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 349ddf6..6981319 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -11,6 +11,8 @@ obj-$(CONFIG_VIDEO_MMP_CAMERA) += marvell-ccic/
 obj-$(CONFIG_VIDEO_OMAP3)  += omap3isp/
 obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o
 
+obj-$(CONFIG_VIDEO_BUS_SWITCH) += video-bus-switch.o
+
 obj-$(CONFIG_VIDEO_VIU) += fsl-viu.o
 
 obj-$(CONFIG_VIDEO_VIVID)  += vivid/
diff --git a/drivers/media/platform/omap3isp/ispccp2.c 
b/drivers/media/platform/omap3isp/ispccp2.c
index 4edb55a..c2bc6b7 100644
--- a/drivers/media/platform/omap3isp/ispccp2.c
+++ b/drivers/media/platform/omap3isp/ispccp2.c
@@ -171,7 +171,7 @@ static int ccp2_if_enable(struct isp_ccp2_device *ccp2, u8 
enable)
 
pad = media_entity_remote_pad(>pads[CCP2_PAD_SINK]);
sensor = media_entity_to_v4l2_subdev(pad->entity);
-   /* Struct isp_bus_cfg has union inside */
+   /* Struct isp_bus_cfg has union inside */ 
buscfg = &((struct isp_bus_cfg *)sensor->host_priv)->bus.ccp2;
 
 
@@ -383,7 +383,7 @@ void __isp_of_parse_node_csi1(struct device *dev,
  */
 static int ccp2_if_configure(struct isp_ccp2_device *ccp2)
 {
-   const struct isp_bus_cfg *buscfg;
+   struct isp_bus_cfg *buscfg;
struct v4l2_mbus_framefmt *format;
struct media_pad *pad;
struct v4l2_subdev *sensor;
@@ -396,6 +396,25 @@ static int ccp2_if_configure(struct isp_ccp2_device *ccp2)
sensor = media_entity_to_v4l2_subdev(pad->entity);
buscfg = sensor->host_priv;
 
+   {
+   struct v4l2_subdev *subdev2;
+   struct v4l2_of_endpoint vep;
+   
+   subdev2 = media_entity_to_v4l2_subdev(pad->entity);
+
+   printk("if_configure... subdev %p\n", subdev2);
+   /* fixme: vep.base.port is wrong? */
+   ret = v4l2_subdev_call(subdev2, video, g_endpoint_config, );
+   printk("if_configure ret %d\n", ret);
+   if (ret == 0) {
+   struct isp_ccp2_cfg prev_cfg = buscfg->bus.ccp2;
+   printk("Success: have configuration\n");
+   printk("Compare: %d\n", memcmp(_cfg, 
>bus.ccp2, sizeof(prev_cfg)));
+   __isp_of_parse_node_csi1(NULL, >bus.ccp2, );
+   printk("Configured ok?\n");
+   }
+   }
+
ret = ccp2_phyif_config(ccp2, >bus.ccp2);
if (ret < 0)
return ret;
diff --git a/drivers/media/platform/video-bus-switch.c 
b/drivers/media/platform/video-bus-switch.c
new file mode 100644
index 000..1de611d
--- /dev/null
+++ b/drivers/media/platform/video-bus-switch.c
@@ -0,0 +1,389 @@
+/*
+ * Generic driver for video bus switches
+ *
+ * 

[RFC 13/13] adp1653: add subdevs

[Pavel Machek]

Needed for number of camera devices to match and fcam-dev to work.
---
 drivers/media/i2c/adp1653.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/adp1653.c b/drivers/media/i2c/adp1653.c
index ba1ec4a..b3d8e60 100644
--- a/drivers/media/i2c/adp1653.c
+++ b/drivers/media/i2c/adp1653.c
@@ -497,11 +497,13 @@ static int adp1653_probe(struct i2c_client *client,
flash->platform_data = client->dev.platform_data;
}
 
+   dev_info(>dev, "adp1653 probe: subdev\n");  
mutex_init(>power_lock);
 
v4l2_i2c_subdev_init(>subdev, client, _ops);
flash->subdev.internal_ops = _internal_ops;
flash->subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
+   strcpy(flash->subdev.name, "adp1653 flash");
 
ret = adp1653_init_controls(flash);
if (ret)
@@ -509,12 +511,21 @@ static int adp1653_probe(struct i2c_client *client,
 
ret = media_entity_pads_init(>subdev.entity, 0, NULL);
if (ret < 0)
-   goto free_and_quit;
+   goto free_pads;
+
+   dev_info(>dev, "adp1653 probe: should be ok\n");
+
+   ret = v4l2_async_register_subdev(>subdev);
+   if (ret < 0)
+   goto free_pads;
+
+   dev_info(>dev, "adp1653 probe: async register subdev ok\n");
 
flash->subdev.entity.function = MEDIA_ENT_F_FLASH;
 
return 0;
-
+free_pads:
+   media_entity_cleanup(>subdev.entity);
 free_and_quit:
dev_err(>dev, "adp1653: failed to register device\n");
v4l2_ctrl_handler_free(>ctrls);
-- 
2.1.4


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[RFC 08/13] smiapp-pll: Take existing divisor into account in minimum divisor check

[Pavel Machek]

From: Sakari Ailus 

Required added multiplier (and divisor) calculation did not take into
account the existing divisor when checking the values against the
minimum divisor. Do just that.

Signed-off-by: Sakari Ailus 
Signed-off-by: Ivaylo Dimitrov 
Signed-off-by: Pavel Machek 
---
 drivers/media/i2c/smiapp-pll.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/smiapp-pll.c b/drivers/media/i2c/smiapp-pll.c
index 771db56..166bbaf 100644
--- a/drivers/media/i2c/smiapp-pll.c
+++ b/drivers/media/i2c/smiapp-pll.c
@@ -16,6 +16,8 @@
  * General Public License for more details.
  */
 
+#define DEBUG
+
 #include 
 #include 
 #include 
@@ -227,7 +229,8 @@ static int __smiapp_pll_calculate(
 
more_mul_factor = lcm(div, pll->pre_pll_clk_div) / div;
dev_dbg(dev, "more_mul_factor: %u\n", more_mul_factor);
-   more_mul_factor = lcm(more_mul_factor, op_limits->min_sys_clk_div);
+   more_mul_factor = lcm(more_mul_factor,
+ DIV_ROUND_UP(op_limits->min_sys_clk_div, div));
dev_dbg(dev, "more_mul_factor: min_op_sys_clk_div: %d\n",
more_mul_factor);
i = roundup(more_mul_min, more_mul_factor);
@@ -456,6 +459,10 @@ int smiapp_pll_calculate(struct device *dev,
i = gcd(pll->pll_op_clk_freq_hz, pll->ext_clk_freq_hz);
mul = div_u64(pll->pll_op_clk_freq_hz, i);
div = pll->ext_clk_freq_hz / i;
+   if (!mul) {
+   dev_err(dev, "forcing mul to 1\n");
+   mul = 1;
+   }
dev_dbg(dev, "mul %u / div %u\n", mul, div);
 
min_pre_pll_clk_div =
-- 
2.1.4


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[RFC 07/13] v4l2: device_register_subdev_nodes: allow calling multiple times

[Pavel Machek]

From: Sebastian Reichel 

Without this, exposure / gain controls do not work in the camera application.

Signed-off-by: Sebastian Reichel 
Signed-off-by: Ivaylo Dimitrov 
Signed-off-by: Pavel Machek 
---
 drivers/media/v4l2-core/v4l2-device.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-device.c 
b/drivers/media/v4l2-core/v4l2-device.c
index f364cc1..b3afbe8 100644
--- a/drivers/media/v4l2-core/v4l2-device.c
+++ b/drivers/media/v4l2-core/v4l2-device.c
@@ -235,6 +235,9 @@ int v4l2_device_register_subdev_nodes(struct v4l2_device 
*v4l2_dev)
if (!(sd->flags & V4L2_SUBDEV_FL_HAS_DEVNODE))
continue;
 
+   if(sd->devnode)
+   continue;
+
vdev = kzalloc(sizeof(*vdev), GFP_KERNEL);
if (!vdev) {
err = -ENOMEM;
-- 
2.1.4


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[RFC 02/13] smiapp: add CCP2 support

[Pavel Machek]

Add support for CCP2 connected SMIA sensors as found
on the Nokia N900.

Signed-off-by: Sebastian Reichel 
Signed-off-by: Ivaylo Dimitrov 
Signed-off-by: Pavel Machek 
---
 drivers/media/i2c/smiapp/smiapp-core.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
b/drivers/media/i2c/smiapp/smiapp-core.c
index f4e92bd..212293f 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -2807,13 +2807,19 @@ static struct smiapp_hwconfig 
*smiapp_get_hwconfig(struct device *dev)
switch (bus_cfg->bus_type) {
case V4L2_MBUS_CSI2:
hwcfg->csi_signalling_mode = SMIAPP_CSI_SIGNALLING_MODE_CSI2;
+   hwcfg->lanes = bus_cfg->bus.mipi_csi2.num_data_lanes;
+   break;
+   case V4L2_MBUS_CCP2:
+   hwcfg->csi_signalling_mode = (bus_cfg->bus.mipi_csi1.strobe) ?
+   SMIAPP_CSI_SIGNALLING_MODE_CCP2_DATA_STROBE :
+   SMIAPP_CSI_SIGNALLING_MODE_CCP2_DATA_CLOCK;
+   hwcfg->lanes = 1;
break;
-   /* FIXME: add CCP2 support. */
default:
+   dev_err(dev, "unknown bus protocol\n");
goto out_err;
}
 
-   hwcfg->lanes = bus_cfg->bus.mipi_csi2.num_data_lanes;
dev_dbg(dev, "lanes %u\n", hwcfg->lanes);
 
/* NVM size is not mandatory */
@@ -2827,8 +2833,8 @@ static struct smiapp_hwconfig *smiapp_get_hwconfig(struct 
device *dev)
goto out_err;
}
 
-   dev_dbg(dev, "nvm %d, clk %d, csi %d\n", hwcfg->nvm_size,
-   hwcfg->ext_clk, hwcfg->csi_signalling_mode);
+   dev_dbg(dev, "nvm %d, clk %d, mode %d\n",
+   hwcfg->nvm_size, hwcfg->ext_clk, hwcfg->csi_signalling_mode);
 
if (!bus_cfg->nr_of_link_frequencies) {
dev_warn(dev, "no link frequencies defined\n");
-- 
2.1.4


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[RFC 03/13] v4l: split lane parsing code

[Pavel Machek]

From: Sakari Ailus 

The function to parse CSI2 bus parameters was called
v4l2_of_parse_csi_bus(), rename it as v4l2_of_parse_csi2_bus() in
anticipation of CSI1/CCP2 support.

Obtain data bus type from bus-type property. Only try parsing bus
specific properties in this case.

Separate lane parsing from CSI-2 bus parameter parsing. The CSI-1 will
need these as well, separate them into a different
function. have_clk_lane and num_data_lanes arguments may be NULL; the
CSI-1 bus will have no use for them.

Add support for parsing of CSI-1 and CCP2 bus related properties
documented in video-interfaces.txt.

Signed-off-by: Sakari Ailus 
Signed-off-by: Ivaylo Dimitrov 
Signed-off-by: Pavel Machek 
---
 drivers/media/v4l2-core/v4l2-of.c | 141 ++
 1 file changed, 114 insertions(+), 27 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-of.c 
b/drivers/media/v4l2-core/v4l2-of.c
index 4f59f44..9ffe2d3 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -20,64 +20,101 @@
 
 #include 
 
-static int v4l2_of_parse_csi_bus(const struct device_node *node,
-struct v4l2_of_endpoint *endpoint)
+enum v4l2_of_bus_type {
+   V4L2_OF_BUS_TYPE_CSI2 = 0,
+   V4L2_OF_BUS_TYPE_PARALLEL,
+   V4L2_OF_BUS_TYPE_CSI1,
+   V4L2_OF_BUS_TYPE_CCP2,
+};
+
+static int v4l2_of_parse_lanes(const struct device_node *node,
+  unsigned char *clock_lane,
+  bool *have_clk_lane,
+  unsigned char *data_lanes,
+  bool *lane_polarities,
+  unsigned short *__num_data_lanes,
+  unsigned int max_data_lanes)
 {
-   struct v4l2_of_bus_mipi_csi2 *bus = >bus.mipi_csi2;
struct property *prop;
-   bool have_clk_lane = false;
-   unsigned int flags = 0, lanes_used = 0;
+   unsigned int lanes_used = 0;
+   short num_data_lanes = 0;
u32 v;
 
prop = of_find_property(node, "data-lanes", NULL);
if (prop) {
const __be32 *lane = NULL;
-   unsigned int i;
 
-   for (i = 0; i < ARRAY_SIZE(bus->data_lanes); i++) {
+   for (num_data_lanes = 0; num_data_lanes < max_data_lanes;
+num_data_lanes++) {
lane = of_prop_next_u32(prop, lane, );
if (!lane)
break;
+   data_lanes[num_data_lanes] = v;
 
if (lanes_used & BIT(v))
pr_warn("%s: duplicated lane %u in 
data-lanes\n",
node->full_name, v);
lanes_used |= BIT(v);
-
-   bus->data_lanes[i] = v;
}
-   bus->num_data_lanes = i;
}
+   if (__num_data_lanes)
+   *__num_data_lanes = num_data_lanes;
 
prop = of_find_property(node, "lane-polarities", NULL);
if (prop) {
const __be32 *polarity = NULL;
unsigned int i;
 
-   for (i = 0; i < ARRAY_SIZE(bus->lane_polarities); i++) {
+   for (i = 0; i < 1 + max_data_lanes; i++) {
polarity = of_prop_next_u32(prop, polarity, );
if (!polarity)
break;
-   bus->lane_polarities[i] = v;
+   lane_polarities[i] = v;
}
 
-   if (i < 1 + bus->num_data_lanes /* clock + data */) {
+   if (i < 1 + num_data_lanes /* clock + data */) {
pr_warn("%s: too few lane-polarities entries (need %u, 
got %u)\n",
-   node->full_name, 1 + bus->num_data_lanes, i);
+   node->full_name, 1 + num_data_lanes, i);
return -EINVAL;
}
}
 
+   if (have_clk_lane)
+   *have_clk_lane = false;
+
if (!of_property_read_u32(node, "clock-lanes", )) {
+   *clock_lane = v;
+   if (have_clk_lane)
+   *have_clk_lane = true;
+
if (lanes_used & BIT(v))
pr_warn("%s: duplicated lane %u in clock-lanes\n",
node->full_name, v);
lanes_used |= BIT(v);
-
-   bus->clock_lane = v;
-   have_clk_lane = true;
}
 
+   return 0;
+}
+
+static int v4l2_of_parse_csi2_bus(const struct device_node *node,
+struct v4l2_of_endpoint *endpoint)
+{
+   struct v4l2_of_bus_mipi_csi2 *bus = >bus.mipi_csi2;
+   bool have_clk_lane = false;
+   unsigned int flags = 0;
+   int rval;
+   u32 v;
+
+   rval = 

[PATCH v3 1/2] v4l: Add camera voice coil lens control class, current control

[Sakari Ailus]

Add a V4L2 control class for voice coil lens driver devices. These are
simple devices that are used to move a camera lens from its resting
position.

Signed-off-by: Sakari Ailus 
---
 Documentation/media/uapi/v4l/extended-controls.rst | 28 ++
 include/uapi/linux/v4l2-controls.h |  8 +++
 2 files changed, 36 insertions(+)

diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
b/Documentation/media/uapi/v4l/extended-controls.rst
index abb1057..a75451a 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -3022,6 +3022,34 @@ Image Process Control IDs
 driver specific and are documented in :ref:`v4l-drivers`.
 
 
+.. _voice-coil-lens-controls:
+
+Voice Coil Lens Control Reference
+=
+
+The Voice Coil class controls are used to control voice coil lens
+devices. These are very simple devices that consist of a voice coil, a
+spring and a lens. The current applied on the voice coil is used to
+move the lens away from the resting position which typically is (close
+to) infinity. The higher the current applied, the closer the lens is
+typically focused.
+
+.. _voice-coil-lens-control-is:
+
+Voice Coil Lens Control IDs
+---
+
+``V4L2_CID_VOICE_COIL_CLASS (class)``
+The VOICE_COIL class descriptor.
+
+``V4L2_CID_VOICE_COIL_CURRENT (integer)``
+Current applied on a voice coil. The more current is applied, the
+more is the position of the lens moved from its resting position.
+Do note that there may be a ringing effect; the lens will
+oscillate after changing the current applied unless the device
+implements ringing compensation.
+
+
 .. _dv-controls:
 
 Digital Video Control Reference
diff --git a/include/uapi/linux/v4l2-controls.h 
b/include/uapi/linux/v4l2-controls.h
index 0d2e1e0..9ef152b 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -62,6 +62,7 @@
 #define V4L2_CTRL_CLASS_FM_RX  0x00a1  /* FM Receiver controls 
*/
 #define V4L2_CTRL_CLASS_RF_TUNER   0x00a2  /* RF tuner controls */
 #define V4L2_CTRL_CLASS_DETECT 0x00a3  /* Detection controls */
+#define V4L2_CTRL_CLASS_VOICE_COIL 0x00a4  /* Voice coil lens 
driver controls */
 
 /* User-class control IDs */
 
@@ -894,6 +895,13 @@ enum v4l2_jpeg_chroma_subsampling {
 #define V4L2_CID_TEST_PATTERN  (V4L2_CID_IMAGE_PROC_CLASS_BASE 
+ 3)
 #define V4L2_CID_DEINTERLACING_MODE(V4L2_CID_IMAGE_PROC_CLASS_BASE 
+ 4)
 
+/* Voice coil lens driver controls */
+
+#define V4L2_CID_VOICE_COIL_CLASS_BASE (V4L2_CTRL_CLASS_VOICE_COIL | 
0x900)
+#define V4L2_CID_VOICE_COIL_CLASS  (V4L2_CTRL_CLASS_VOICE_COIL | 1)
+
+#define V4L2_CID_VOICE_COIL_CURRENT(V4L2_CID_VOICE_COIL_CLASS_BASE 
+ 1)
+
 
 /*  DV-class control IDs defined by V4L2 */
 #define V4L2_CID_DV_CLASS_BASE (V4L2_CTRL_CLASS_DV | 0x900)
-- 
2.7.4

[PATCH v3 2/2] ad5820: Use VOICE_COIL_CURRENT control

[Sakari Ailus]

Add V4L2_CID_VOICE_COIL_CURRENT control support to the ad5820 driver. The
usage of the control is equivalent to how V4L2_CID_FOCUS_ABSOLUTE was used
by the driver. The old control remains supported.

Signed-off-by: Sakari Ailus 
---
 drivers/media/i2c/ad5820.c | 27 +--
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/drivers/media/i2c/ad5820.c b/drivers/media/i2c/ad5820.c
index a9026a91..e5ff1a2 100644
--- a/drivers/media/i2c/ad5820.c
+++ b/drivers/media/i2c/ad5820.c
@@ -51,7 +51,7 @@ struct ad5820_device {
struct regulator *vana;
 
struct v4l2_ctrl_handler ctrls;
-   u32 focus_absolute;
+   struct v4l2_ctrl *focus, *curr;
u32 focus_ramp_time;
u32 focus_ramp_mode;
 
@@ -59,6 +59,7 @@ struct ad5820_device {
int power_count;
 
bool standby;
+   bool in_set_ctrl;
 };
 
 static int ad5820_write(struct ad5820_device *coil, u16 data)
@@ -98,7 +99,7 @@ static int ad5820_update_hw(struct ad5820_device *coil)
status = RAMP_US_TO_CODE(coil->focus_ramp_time);
status |= coil->focus_ramp_mode
? AD5820_RAMP_MODE_64_16 : AD5820_RAMP_MODE_LINEAR;
-   status |= coil->focus_absolute << AD5820_DAC_SHIFT;
+   status |= coil->curr->val << AD5820_DAC_SHIFT;
 
if (coil->standby)
status |= AD5820_POWER_DOWN;
@@ -160,9 +161,16 @@ static int ad5820_set_ctrl(struct v4l2_ctrl *ctrl)
struct ad5820_device *coil =
container_of(ctrl->handler, struct ad5820_device, ctrls);
 
+   if (coil->in_set_ctrl)
+   return 0;
+
switch (ctrl->id) {
case V4L2_CID_FOCUS_ABSOLUTE:
-   coil->focus_absolute = ctrl->val;
+   case V4L2_CID_VOICE_COIL_CURRENT:
+   coil->in_set_ctrl = true;
+   __v4l2_ctrl_s_ctrl(ctrl == coil->focus ?
+  coil->curr : coil->focus, ctrl->val);
+   coil->in_set_ctrl = false;
return ad5820_update_hw(coil);
}
 
@@ -189,14 +197,21 @@ static int ad5820_init_controls(struct ad5820_device 
*coil)
 * will just use abstract codes here. In any case, smaller value = focus
 * position farther from camera. The default zero value means focus at
 * infinity, and also least current consumption.
+*
+* The two controls below control the current. The
+* FOCUS_ABSOLUTE is there for compatibility with old user
+* space whereas the VOICE_COIL_CURRENT should be used by both
+* new applications and drivers.
 */
-   v4l2_ctrl_new_std(>ctrls, _ctrl_ops,
- V4L2_CID_FOCUS_ABSOLUTE, 0, 1023, 1, 0);
+   coil->focus = v4l2_ctrl_new_std(>ctrls, _ctrl_ops,
+   V4L2_CID_FOCUS_ABSOLUTE, 0, 1023, 1, 0);
+   coil->curr = v4l2_ctrl_new_std(>ctrls, _ctrl_ops,
+ V4L2_CID_VOICE_COIL_CURRENT,
+ 0, 1023, 1, 0);
 
if (coil->ctrls.error)
return coil->ctrls.error;
 
-   coil->focus_absolute = 0;
coil->focus_ramp_time = 0;
coil->focus_ramp_mode = 0;
 
-- 
2.7.4

[PATCH v3 0/2] v4l: Add camera voice coil lens control class, current control

[Sakari Ailus]

Hello everyone,

I wanted to refresh my voice coil lens patchset before we have more voice 
coil lens controller drivers. The VOCUS_ABSOLUTE control really is not a
best control ID to control a voice coil driver's current. 

There may be additional controls in the class: the hardware I'm familiar
with provides other controls (PWM vs. linear mode, resonance frequency and
ringing compensation formula to name a few) but I'm not fully certain 
they're something that even should be told to the user --- let alone
giving the user write access to them. 

My expectation is still that there will be more controls in the class. The
PWM / linear mode might be one candidate: PWM saves power but it may cause
other issues. These other issues might be something to ignore, depending
on the use case. That will be anyway left for the future. 

since v2:

- Don't remove the newline after control class definitions.

- Move all ad5820 related changes to the second patch. Some were
  accidentally left to the patch adding the new control class.

-- 
Kind regards,
Sakari

[PATCH v2 2/2] ad5820: Use VOICE_COIL_CURRENT control

[Sakari Ailus]

Add V4L2_CID_VOICE_COIL_CURRENT control support to the ad5820 driver. The
usage of the control is equivalent to how V4L2_CID_FOCUS_ABSOLUTE was used
by the driver. The old control remains supported.

Signed-off-by: Sakari Ailus 
---
 drivers/media/i2c/ad5820.c | 28 
 1 file changed, 20 insertions(+), 8 deletions(-)

diff --git a/drivers/media/i2c/ad5820.c b/drivers/media/i2c/ad5820.c
index 7167b26..e5ff1a2 100644
--- a/drivers/media/i2c/ad5820.c
+++ b/drivers/media/i2c/ad5820.c
@@ -51,7 +51,7 @@ struct ad5820_device {
struct regulator *vana;
 
struct v4l2_ctrl_handler ctrls;
-   u32 focus_absolute;
+   struct v4l2_ctrl *focus, *curr;
u32 focus_ramp_time;
u32 focus_ramp_mode;
 
@@ -59,6 +59,7 @@ struct ad5820_device {
int power_count;
 
bool standby;
+   bool in_set_ctrl;
 };
 
 static int ad5820_write(struct ad5820_device *coil, u16 data)
@@ -98,7 +99,7 @@ static int ad5820_update_hw(struct ad5820_device *coil)
status = RAMP_US_TO_CODE(coil->focus_ramp_time);
status |= coil->focus_ramp_mode
? AD5820_RAMP_MODE_64_16 : AD5820_RAMP_MODE_LINEAR;
-   status |= coil->focus_absolute << AD5820_DAC_SHIFT;
+   status |= coil->curr->val << AD5820_DAC_SHIFT;
 
if (coil->standby)
status |= AD5820_POWER_DOWN;
@@ -160,10 +161,16 @@ static int ad5820_set_ctrl(struct v4l2_ctrl *ctrl)
struct ad5820_device *coil =
container_of(ctrl->handler, struct ad5820_device, ctrls);
 
+   if (coil->in_set_ctrl)
+   return 0;
+
switch (ctrl->id) {
case V4L2_CID_FOCUS_ABSOLUTE:
case V4L2_CID_VOICE_COIL_CURRENT:
-   coil->focus_absolute = ctrl->val;
+   coil->in_set_ctrl = true;
+   __v4l2_ctrl_s_ctrl(ctrl == coil->focus ?
+  coil->curr : coil->focus, ctrl->val);
+   coil->in_set_ctrl = false;
return ad5820_update_hw(coil);
}
 
@@ -190,16 +197,21 @@ static int ad5820_init_controls(struct ad5820_device 
*coil)
 * will just use abstract codes here. In any case, smaller value = focus
 * position farther from camera. The default zero value means focus at
 * infinity, and also least current consumption.
+*
+* The two controls below control the current. The
+* FOCUS_ABSOLUTE is there for compatibility with old user
+* space whereas the VOICE_COIL_CURRENT should be used by both
+* new applications and drivers.
 */
-   v4l2_ctrl_new_std(>ctrls, _ctrl_ops,
- V4L2_CID_FOCUS_ABSOLUTE, 0, 1023, 1, 0);
-   v4l2_ctrl_new_std(>ctrls, _ctrl_ops,
- V4L2_CID_VOICE_COIL_CURRENT, 0, 1023, 1, 0);
+   coil->focus = v4l2_ctrl_new_std(>ctrls, _ctrl_ops,
+   V4L2_CID_FOCUS_ABSOLUTE, 0, 1023, 1, 0);
+   coil->curr = v4l2_ctrl_new_std(>ctrls, _ctrl_ops,
+ V4L2_CID_VOICE_COIL_CURRENT,
+ 0, 1023, 1, 0);
 
if (coil->ctrls.error)
return coil->ctrls.error;
 
-   coil->focus_absolute = 0;
coil->focus_ramp_time = 0;
coil->focus_ramp_mode = 0;
 
-- 
2.7.4

[PATCH v2 1/2] v4l: Add camera voice coil lens control class, current control

[Sakari Ailus]

Add a V4L2 control class for voice coil lens driver devices. These are
simple devices that are used to move a camera lens from its resting
position.

Signed-off-by: Sakari Ailus 
---
 Documentation/media/uapi/v4l/extended-controls.rst | 28 ++
 drivers/media/i2c/ad5820.c |  3 +++
 include/uapi/linux/v4l2-controls.h |  9 ++-
 3 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
b/Documentation/media/uapi/v4l/extended-controls.rst
index abb1057..a75451a 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -3022,6 +3022,34 @@ Image Process Control IDs
 driver specific and are documented in :ref:`v4l-drivers`.
 
 
+.. _voice-coil-lens-controls:
+
+Voice Coil Lens Control Reference
+=
+
+The Voice Coil class controls are used to control voice coil lens
+devices. These are very simple devices that consist of a voice coil, a
+spring and a lens. The current applied on the voice coil is used to
+move the lens away from the resting position which typically is (close
+to) infinity. The higher the current applied, the closer the lens is
+typically focused.
+
+.. _voice-coil-lens-control-is:
+
+Voice Coil Lens Control IDs
+---
+
+``V4L2_CID_VOICE_COIL_CLASS (class)``
+The VOICE_COIL class descriptor.
+
+``V4L2_CID_VOICE_COIL_CURRENT (integer)``
+Current applied on a voice coil. The more current is applied, the
+more is the position of the lens moved from its resting position.
+Do note that there may be a ringing effect; the lens will
+oscillate after changing the current applied unless the device
+implements ringing compensation.
+
+
 .. _dv-controls:
 
 Digital Video Control Reference
diff --git a/drivers/media/i2c/ad5820.c b/drivers/media/i2c/ad5820.c
index a9026a91..7167b26 100644
--- a/drivers/media/i2c/ad5820.c
+++ b/drivers/media/i2c/ad5820.c
@@ -162,6 +162,7 @@ static int ad5820_set_ctrl(struct v4l2_ctrl *ctrl)
 
switch (ctrl->id) {
case V4L2_CID_FOCUS_ABSOLUTE:
+   case V4L2_CID_VOICE_COIL_CURRENT:
coil->focus_absolute = ctrl->val;
return ad5820_update_hw(coil);
}
@@ -192,6 +193,8 @@ static int ad5820_init_controls(struct ad5820_device *coil)
 */
v4l2_ctrl_new_std(>ctrls, _ctrl_ops,
  V4L2_CID_FOCUS_ABSOLUTE, 0, 1023, 1, 0);
+   v4l2_ctrl_new_std(>ctrls, _ctrl_ops,
+ V4L2_CID_VOICE_COIL_CURRENT, 0, 1023, 1, 0);
 
if (coil->ctrls.error)
return coil->ctrls.error;
diff --git a/include/uapi/linux/v4l2-controls.h 
b/include/uapi/linux/v4l2-controls.h
index 0d2e1e0..c1efbc5 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -62,7 +62,7 @@
 #define V4L2_CTRL_CLASS_FM_RX  0x00a1  /* FM Receiver controls 
*/
 #define V4L2_CTRL_CLASS_RF_TUNER   0x00a2  /* RF tuner controls */
 #define V4L2_CTRL_CLASS_DETECT 0x00a3  /* Detection controls */
-
+#define V4L2_CTRL_CLASS_VOICE_COIL 0x00a4  /* Voice coil lens 
driver controls */
 /* User-class control IDs */
 
 #define V4L2_CID_BASE  (V4L2_CTRL_CLASS_USER | 0x900)
@@ -894,6 +894,13 @@ enum v4l2_jpeg_chroma_subsampling {
 #define V4L2_CID_TEST_PATTERN  (V4L2_CID_IMAGE_PROC_CLASS_BASE 
+ 3)
 #define V4L2_CID_DEINTERLACING_MODE(V4L2_CID_IMAGE_PROC_CLASS_BASE 
+ 4)
 
+/* Voice coil lens driver controls */
+
+#define V4L2_CID_VOICE_COIL_CLASS_BASE (V4L2_CTRL_CLASS_VOICE_COIL | 
0x900)
+#define V4L2_CID_VOICE_COIL_CLASS  (V4L2_CTRL_CLASS_VOICE_COIL | 1)
+
+#define V4L2_CID_VOICE_COIL_CURRENT(V4L2_CID_VOICE_COIL_CLASS_BASE 
+ 1)
+
 
 /*  DV-class control IDs defined by V4L2 */
 #define V4L2_CID_DV_CLASS_BASE (V4L2_CTRL_CLASS_DV | 0x900)
-- 
2.7.4

v4l: Add camera voice coil lens control class, current control

[Sakari Ailus]

Hi folks,

I wanted to refresh my voice coil lens patchset before we have more voice
coil lens controller drivers. The VOCUS_ABSOLUTE control really is not a
best control ID to control a voice coil driver's current.

There may be additional controls in the class: the hardware I'm familiar
with provides other controls (PWM vs. linear mode, resonance frequency and
ringing compensation formula to name a few) but I'm not fully certain
they're something that even should be told to the user --- let alone
giving the user write access to them.

My expectation is still that there will be more controls in the class. The
PWM / linear mode might be one candidate: PWM saves power but it may cause
other issues. These other issues might be something to ignore, depending
on the use case. That will be anyway left for the future.

-- 
Kind regards,
Sakari

[GIT PULL for v4.10] media fixes

[Mauro Carvalho Chehab]

Hi Linus,

Please pull from:
  git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
tags/media/v4.10-4

For a regression fix on colorspace at V4L2 core and a CEC core bug that
makes it discard valid messages.

Thanks!
Mauro

The following changes since commit f9f96fc10c09ca16e336854c08bc1563eed97985:

  [media] cec: fix wrong last_la determination (2017-01-30 11:42:31 -0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
tags/media/v4.10-4

for you to fetch changes up to 42980da2eb7eb9695d8efc0c0ef145cbbb993b2c:

  [media] cec: initiator should be the same as the destination for, poll 
(2017-02-13 14:34:11 -0200)


media fixes for v4.10-rc8


Hans Verkuil (2):
  [media] videodev2.h: go back to limited range Y'CbCr for SRGB and, 
ADOBERGB
  [media] cec: initiator should be the same as the destination for, poll

 Documentation/media/uapi/v4l/pixfmt-007.rst | 23 +--
 drivers/media/cec/cec-adap.c|  7 +++
 include/uapi/linux/videodev2.h  |  7 +++
 3 files changed, 23 insertions(+), 14 deletions(-)