cron job: media_tree daily build: ERRORS

[Hans Verkuil]

This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Fri May  5 05:00:17 CEST 2017
media-tree git hash:3622d3e77ecef090b5111e3c5423313f11711dfa
media_build git hash:   1af19680bde3e227d64d99ff5fdc43eb343a3b28
v4l-utils git hash: eb9dcc3e1d4805c382e244397df2290051179601
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.9.0-164

linux-git-arm-at91: WARNINGS
linux-git-arm-davinci: WARNINGS
linux-git-arm-multi: WARNINGS
linux-git-arm-pxa: WARNINGS
linux-git-blackfin-bf561: OK
linux-git-i686: WARNINGS
linux-git-m32r: WARNINGS
linux-git-mips: WARNINGS
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: WARNINGS
linux-2.6.36.4-i686: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: 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: ERRORS
linux-3.12.67-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: WARNINGS
linux-4.9-i686: WARNINGS
linux-4.10.1-i686: WARNINGS
linux-4.11-rc1-i686: WARNINGS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: 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: ERRORS
linux-3.12.67-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: WARNINGS
linux-4.9-x86_64: WARNINGS
linux-4.10.1-x86_64: WARNINGS
linux-4.11-rc1-x86_64: WARNINGS
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

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

[Petr Cvek]

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

I was trying to add RGB888 and then I've noticed that "YVYU 16bit" formats (and 
permutation) and "Bayer 12" formats have incorrect values in the 
bits_per_sample field. I didn't notice it in the patch creation, because it 
doesn't affect the computations of the image size. And later in the code it 
just defaults to 8.

A comment for a switch in the pxa_camera_setup_cicr() function:

"Datawidth is now guaranteed to be equal to one of the three values..."

Values are 10, 9 and 8 and they describe a bit-vector length of the interface 
for a sensor.

So I will include a fix for the patchset v2 for this. I will test the YUYV 
formats, but my sensor does not support the Bayer 12 formats. 

In the addition I propose a patch for an enum type (or define) of the interface 
configuration field. Something like:
#define PXA_MBUS_BUSWIDTH_8 8
#define PXA_MBUS_BUSWIDTH_9 9
#define PXA_MBUS_BUSWIDTH_1010
and a patch for something like:
s/bits_per_sample/buswidth/g
and a formatting patch for excessive tabulators in the mbus_fmt structure 
initialization ;-).

Petr

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

[Petr Cvek]

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

OK I will add it in v2.

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

[Mauro Carvalho Chehab]

Em Fri, 5 May 2017 01:14:29 +0200
Reinhard Speyerer  escreveu:

> On Thu, May 04, 2017 at 09:11:47AM -0300, Mauro Carvalho Chehab wrote:
> > Em Thu, 4 May 2017 09:55:04 +0200
> > Gregor Jasny  escreveu:
> >   
> > > Hello Mauro,
> > > 
> > > On 04.05.17 00:33, Mauro Carvalho Chehab wrote:  
> > > > Em Wed, 3 May 2017 09:53:03 -0300
> > > > Mauro Carvalho Chehab  escreveu:
> > > >> Em Tue, 2 May 2017 22:30:29 +0200
> > > >> Gregor Jasny  escreveu:
> > > >>> I just used your patch and another to hopefully fix
> > > >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859008
> > > >>>
> > > >>> But I'm a little bit hesitant to merge it to v4l-utils git without
> > > >>> Mauros acknowledgement.
> > >   
> > > >> Patches look correct, but the T2 parser has a more serious issue that
> > > >> will require breaking ABI/API compatibility.
> > >   
> > > > I'll cherry-pick the corresponding patches to the stable branch.
> > > 
> > > Reinhard, could you please test the latest patches on
> > > https://git.linuxtv.org/v4l-utils.git/log/?h=stable-1.12
> > > 
> > > If they work for you, I'd release a new stable version and upload it to 
> > > Debian Sid afterwards.  
> > 
> > I found one additional bug there, at the code that handles subcells.
> > 
> > Fix applied. Reinhard/Clemens, if you find some channel that use
> > subcells on this descriptor and/or tfs_flag == 1, it would be really cool
> > if you could store ~60 seconds of the transponder and send it to me, as it
> > would allow me to have a testing stream. With that, I can input the stream
> > on my RF generator and test if this is parsed well with libdvbv5,
> > dvbv5-tools and Kaffeine.  
> 
> Hi Gregor and Mauro,
> 
> the created dvb_channel.conf files look good to me with both stable-1.12
> and master. Thanks!
> 
> I noticed that the dvb_channel.conf created by dvbv5-scan from the master
> branch already contains VIDE0_PID = ... while the one created by the
> stable-1.12 version still contains PID_24 = ... . Perhaps it might make
> sense to cherry-pick this for stable-1.12 if the changes are small.

Just cherry-picked. It is a small patch, but it is important in order
to handle HEVC channels.

> For some reason several/most(?) programs from freenet.TV (connect) which
> are distributed via the Internet instead of DVB-T2 have duplicate entries.

The dvb scan logic has some code to avoid parsing twice the
same transponder, but it doesn't have any logic to detect if
the same channel is announced multiple times. Perhaps this is
what's happening.

The best would be if you could record 60 seconds of the
transponder with the freenet (connect) channel. From the
dvb_channel.conf, it is located at frequency 57800.
So, this should do the trick:

$ dvbv5-zap -c dvb_channel.conf 'freenet. TV (connect )' -r -P -t60 -o 
freenet.ts
or
$ dvbv5-zap -c de-scan_file 57800 -r -P -t60 -o freenet.ts

(where de-scan_file is the name of the file you're using for 
dvbv5-scan)

Running dvbv5-scan with "-vv" could give some glue why it is
duplicating the channels, but if you send me the channel dump,
it would be easier for me to produce a patch and test it
locally.

> None of the channels available to me uses subcells or tfs_flag == 1.

Ok.


Thanks,
Mauro

[PATCH] staging: media: atomisp: Fix unnecessary initialization of static

[Fabrizio Perria]

Fix checkpatch warning: removed unnecessary initialization of
static variable "skip_fwload" to 0 in source atomisp_v4l2.c

Signed-off-by: Fabrizio Perria 
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
index e3fdbdb..a047807 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
@@ -51,7 +51,7 @@
 /* G-Min addition: pull this in from intel_mid_pm.h */
 #define CSTATE_EXIT_LATENCY_C1  1
 
-static uint skip_fwload = 0;
+static uint skip_fwload;
 module_param(skip_fwload, uint, 0644);
 MODULE_PARM_DESC(skip_fwload, "Skip atomisp firmware load");
 
-- 
1.9.1

Re: [PATCH] [media] em28xx: support for Sundtek MediaTV Digital Home

[Markus Rechberger]

On Fri, May 5, 2017 at 6:21 AM, Thomas Hollstegge
 wrote:
> Sundtek MediaTV Digital Home is a rebranded MaxMedia UB425-TC with the
> following components:
>
> USB bridge: Empia EM2874B
> Demodulator: Micronas DRX 3913KA2
> Tuner: NXP TDA18271HDC2
>

Not that it matters a lot anymore for those units however the USB ID
is allocated for multiple different units, this patch will break some
of them.
If you want to use that use the unit with this driver you're on your
own and have to assign it via sysfs and usb/bind.

It was a joint project many years ago before we also started to design
and manufacture our own units.

Best Regards,
Markus Rechberger

> Signed-off-by: Thomas Hollstegge 
> ---
>  drivers/media/usb/em28xx/em28xx-cards.c | 15 +++
>  drivers/media/usb/em28xx/em28xx-dvb.c   |  1 +
>  drivers/media/usb/em28xx/em28xx.h   |  1 +
>  3 files changed, 17 insertions(+)
>
> diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
> b/drivers/media/usb/em28xx/em28xx-cards.c
> index 5f90d08..4effbda 100644
> --- a/drivers/media/usb/em28xx/em28xx-cards.c
> +++ b/drivers/media/usb/em28xx/em28xx-cards.c
> @@ -415,6 +415,7 @@ static struct em28xx_reg_seq hauppauge_930c_digital[] = {
>
>  /* 1b80:e425 MaxMedia UB425-TC
>   * 1b80:e1cc Delock 61959
> + * eb1a:51b2 Sundtek MediaTV Digital Home
>   * GPIO_6 - demod reset, 0=active
>   * GPIO_7 - LED, 0=active
>   */
> @@ -2405,6 +2406,18 @@ struct em28xx_board em28xx_boards[] = {
> .ir_codes  = RC_MAP_HAUPPAUGE,
> .leds  = hauppauge_dualhd_leds,
> },
> +   /* eb1a:51b2 Sundtek MediaTV Digital Home
> +* Empia EM2874B + Micronas DRX 3913KA2 + NXP TDA18271HDC2 */
> +   [EM2874_BOARD_SUNDTEK_MEDIATV_DIGITAL_HOME] = {
> +   .name  = "Sundtek MediaTV Digital Home",
> +   .tuner_type= TUNER_ABSENT,
> +   .tuner_gpio= maxmedia_ub425_tc,
> +   .has_dvb   = 1,
> +   .ir_codes  = RC_MAP_REDDO,
> +   .def_i2c_bus   = 1,
> +   .i2c_speed = EM28XX_I2C_CLK_WAIT_ENABLE |
> +   EM28XX_I2C_FREQ_400_KHZ,
> +   },
>  };
>  EXPORT_SYMBOL_GPL(em28xx_boards);
>
> @@ -2600,6 +2613,8 @@ struct usb_device_id em28xx_id_table[] = {
> .driver_info = EM28178_BOARD_TERRATEC_T2_STICK_HD },
> { USB_DEVICE(0x3275, 0x0085),
> .driver_info = EM28178_BOARD_PLEX_PX_BCUD },
> +   { USB_DEVICE(0xeb1a, 0x51b2),
> +   .driver_info = 
> EM2874_BOARD_SUNDTEK_MEDIATV_DIGITAL_HOME },
> { },
>  };
>  MODULE_DEVICE_TABLE(usb, em28xx_id_table);
> diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c 
> b/drivers/media/usb/em28xx/em28xx-dvb.c
> index 82edd37..e7fa25d 100644
> --- a/drivers/media/usb/em28xx/em28xx-dvb.c
> +++ b/drivers/media/usb/em28xx/em28xx-dvb.c
> @@ -1482,6 +1482,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
> break;
> }
> case EM2874_BOARD_DELOCK_61959:
> +   case EM2874_BOARD_SUNDTEK_MEDIATV_DIGITAL_HOME:
> case EM2874_BOARD_MAXMEDIA_UB425_TC:
> /* attach demodulator */
> dvb->fe[0] = dvb_attach(drxk_attach, _ub425_tc_drxk,
> diff --git a/drivers/media/usb/em28xx/em28xx.h 
> b/drivers/media/usb/em28xx/em28xx.h
> index e9f3799..72f1468 100644
> --- a/drivers/media/usb/em28xx/em28xx.h
> +++ b/drivers/media/usb/em28xx/em28xx.h
> @@ -148,6 +148,7 @@
>  #define EM28178_BOARD_PLEX_PX_BCUD98
>  #define EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_DVB  99
>  #define EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_01595 100
> +#define EM2874_BOARD_SUNDTEK_MEDIATV_DIGITAL_HOME 101
>
>  /* Limits minimum and default number of buffers */
>  #define EM28XX_MIN_BUF 4
> --
> 2.7.4
>

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

[Reinhard Speyerer]

On Thu, May 04, 2017 at 09:11:47AM -0300, Mauro Carvalho Chehab wrote:
> Em Thu, 4 May 2017 09:55:04 +0200
> Gregor Jasny  escreveu:
> 
> > Hello Mauro,
> > 
> > On 04.05.17 00:33, Mauro Carvalho Chehab wrote:
> > > Em Wed, 3 May 2017 09:53:03 -0300
> > > Mauro Carvalho Chehab  escreveu:  
> > >> Em Tue, 2 May 2017 22:30:29 +0200
> > >> Gregor Jasny  escreveu:  
> > >>> I just used your patch and another to hopefully fix
> > >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859008
> > >>>
> > >>> But I'm a little bit hesitant to merge it to v4l-utils git without
> > >>> Mauros acknowledgement.  
> > 
> > >> Patches look correct, but the T2 parser has a more serious issue that
> > >> will require breaking ABI/API compatibility.  
> > 
> > > I'll cherry-pick the corresponding patches to the stable branch.  
> > 
> > Reinhard, could you please test the latest patches on
> > https://git.linuxtv.org/v4l-utils.git/log/?h=stable-1.12
> > 
> > If they work for you, I'd release a new stable version and upload it to 
> > Debian Sid afterwards.
> 
> I found one additional bug there, at the code that handles subcells.
> 
> Fix applied. Reinhard/Clemens, if you find some channel that use
> subcells on this descriptor and/or tfs_flag == 1, it would be really cool
> if you could store ~60 seconds of the transponder and send it to me, as it
> would allow me to have a testing stream. With that, I can input the stream
> on my RF generator and test if this is parsed well with libdvbv5,
> dvbv5-tools and Kaffeine.

Hi Gregor and Mauro,

the created dvb_channel.conf files look good to me with both stable-1.12
and master. Thanks!

I noticed that the dvb_channel.conf created by dvbv5-scan from the master
branch already contains VIDE0_PID = ... while the one created by the
stable-1.12 version still contains PID_24 = ... . Perhaps it might make
sense to cherry-pick this for stable-1.12 if the changes are small.

For some reason several/most(?) programs from freenet.TV (connect) which
are distributed via the Internet instead of DVB-T2 have duplicate entries.

None of the channels available to me uses subcells or tfs_flag == 1.

Regards,
Reinhard
[ProSieben HD]
SERVICE_ID = 16929
AUDIO_PID = 866 870 871
PID_24 = 865
PID_0b = 872
FREQUENCY = 49800
MODULATION = QAM/AUTO
BANDWIDTH_HZ = 800
INVERSION = AUTO
CODE_RATE_HP = AUTO
CODE_RATE_LP = AUTO
GUARD_INTERVAL = AUTO
TRANSMISSION_MODE = AUTO
HIERARCHY = AUTO
STREAM_ID = 0
DELIVERY_SYSTEM = DVBT2

[kabel eins HD]
SERVICE_ID = 16930
AUDIO_PID = 882 886 887
PID_24 = 881
PID_0b = 888
FREQUENCY = 49800
MODULATION = QAM/AUTO
BANDWIDTH_HZ = 800
INVERSION = AUTO
CODE_RATE_HP = AUTO
CODE_RATE_LP = AUTO
GUARD_INTERVAL = AUTO
TRANSMISSION_MODE = AUTO
HIERARCHY = AUTO
STREAM_ID = 0
DELIVERY_SYSTEM = DVBT2

[SIXX HD]
SERVICE_ID = 16931
AUDIO_PID = 898 902 903
PID_24 = 897
PID_0b = 904
FREQUENCY = 49800
MODULATION = QAM/AUTO
BANDWIDTH_HZ = 800
INVERSION = AUTO
CODE_RATE_HP = AUTO
CODE_RATE_LP = AUTO
GUARD_INTERVAL = AUTO
TRANSMISSION_MODE = AUTO
HIERARCHY = AUTO
STREAM_ID = 0
DELIVERY_SYSTEM = DVBT2

[Pro7 MAXX HD]
SERVICE_ID = 16932
AUDIO_PID = 914 918 919
PID_24 = 913
FREQUENCY = 49800
MODULATION = QAM/AUTO
BANDWIDTH_HZ = 800
INVERSION = AUTO
CODE_RATE_HP = AUTO
CODE_RATE_LP = AUTO
GUARD_INTERVAL = AUTO
TRANSMISSION_MODE = AUTO
HIERARCHY = AUTO
STREAM_ID = 0
DELIVERY_SYSTEM = DVBT2

[SAT.1 Gold HD]
SERVICE_ID = 16933
AUDIO_PID = 930 934 935
PID_24 = 929
FREQUENCY = 49800
MODULATION = QAM/AUTO
BANDWIDTH_HZ = 800
INVERSION = AUTO
CODE_RATE_HP = AUTO
CODE_RATE_LP = AUTO
GUARD_INTERVAL = AUTO
TRANSMISSION_MODE = AUTO
HIERARCHY = AUTO
STREAM_ID = 0
DELIVERY_SYSTEM = DVBT2

[Sport1 HD]
SERVICE_ID = 16934
AUDIO_PID = 946 950 951
PID_24 = 945
FREQUENCY = 49800
MODULATION = QAM/AUTO
BANDWIDTH_HZ = 800
INVERSION = AUTO
CODE_RATE_HP = AUTO
CODE_RATE_LP = AUTO
GUARD_INTERVAL = AUTO
TRANSMISSION_MODE = AUTO
HIERARCHY = AUTO
STREAM_ID = 0
DELIVERY_SYSTEM = DVBT2

[SAT.1 HD Bayern]
SERVICE_ID = 16939
AUDIO_PID = 1026 1030 1033
PID_24 = 1025
PID_0b = 1032
FREQUENCY = 49800
MODULATION = QAM/AUTO
BANDWIDTH_HZ = 800
INVERSION = AUTO

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

[Sakari Ailus]

On Thu, May 04, 2017 at 11:32:08PM +0300, Sakari Ailus wrote:
> Hi Philipp,
> 
> On Thu, May 04, 2017 at 03:38:57PM +0200, Philipp Zabel wrote:
> ...
> > +static const struct of_device_id video_mux_dt_ids[] = {
> > +   { .compatible = "video-mux", },
> > +   { /* sentinel */ }
> > +};
> > +MODULE_DEVICE_TABLE(of, video_mux_dt_ids);
> > +
> > +static struct platform_driver video_mux_driver = {
> 
> Shouldn't this be const?

To reply myself --- no. Driver registration requires that, which makes
perfect sense. Please ignore the comment.

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

[PATCH] [media] em28xx: support for Sundtek MediaTV Digital Home

[Thomas Hollstegge]

Sundtek MediaTV Digital Home is a rebranded MaxMedia UB425-TC with the
following components:

USB bridge: Empia EM2874B
Demodulator: Micronas DRX 3913KA2
Tuner: NXP TDA18271HDC2

Signed-off-by: Thomas Hollstegge 
---
 drivers/media/usb/em28xx/em28xx-cards.c | 15 +++
 drivers/media/usb/em28xx/em28xx-dvb.c   |  1 +
 drivers/media/usb/em28xx/em28xx.h   |  1 +
 3 files changed, 17 insertions(+)

diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
b/drivers/media/usb/em28xx/em28xx-cards.c
index 5f90d08..4effbda 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -415,6 +415,7 @@ static struct em28xx_reg_seq hauppauge_930c_digital[] = {
 
 /* 1b80:e425 MaxMedia UB425-TC
  * 1b80:e1cc Delock 61959
+ * eb1a:51b2 Sundtek MediaTV Digital Home
  * GPIO_6 - demod reset, 0=active
  * GPIO_7 - LED, 0=active
  */
@@ -2405,6 +2406,18 @@ struct em28xx_board em28xx_boards[] = {
.ir_codes  = RC_MAP_HAUPPAUGE,
.leds  = hauppauge_dualhd_leds,
},
+   /* eb1a:51b2 Sundtek MediaTV Digital Home
+* Empia EM2874B + Micronas DRX 3913KA2 + NXP TDA18271HDC2 */
+   [EM2874_BOARD_SUNDTEK_MEDIATV_DIGITAL_HOME] = {
+   .name  = "Sundtek MediaTV Digital Home",
+   .tuner_type= TUNER_ABSENT,
+   .tuner_gpio= maxmedia_ub425_tc,
+   .has_dvb   = 1,
+   .ir_codes  = RC_MAP_REDDO,
+   .def_i2c_bus   = 1,
+   .i2c_speed = EM28XX_I2C_CLK_WAIT_ENABLE |
+   EM28XX_I2C_FREQ_400_KHZ,
+   },
 };
 EXPORT_SYMBOL_GPL(em28xx_boards);
 
@@ -2600,6 +2613,8 @@ struct usb_device_id em28xx_id_table[] = {
.driver_info = EM28178_BOARD_TERRATEC_T2_STICK_HD },
{ USB_DEVICE(0x3275, 0x0085),
.driver_info = EM28178_BOARD_PLEX_PX_BCUD },
+   { USB_DEVICE(0xeb1a, 0x51b2),
+   .driver_info = 
EM2874_BOARD_SUNDTEK_MEDIATV_DIGITAL_HOME },
{ },
 };
 MODULE_DEVICE_TABLE(usb, em28xx_id_table);
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c 
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 82edd37..e7fa25d 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -1482,6 +1482,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
break;
}
case EM2874_BOARD_DELOCK_61959:
+   case EM2874_BOARD_SUNDTEK_MEDIATV_DIGITAL_HOME:
case EM2874_BOARD_MAXMEDIA_UB425_TC:
/* attach demodulator */
dvb->fe[0] = dvb_attach(drxk_attach, _ub425_tc_drxk,
diff --git a/drivers/media/usb/em28xx/em28xx.h 
b/drivers/media/usb/em28xx/em28xx.h
index e9f3799..72f1468 100644
--- a/drivers/media/usb/em28xx/em28xx.h
+++ b/drivers/media/usb/em28xx/em28xx.h
@@ -148,6 +148,7 @@
 #define EM28178_BOARD_PLEX_PX_BCUD98
 #define EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_DVB  99
 #define EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_01595 100
+#define EM2874_BOARD_SUNDTEK_MEDIATV_DIGITAL_HOME 101
 
 /* Limits minimum and default number of buffers */
 #define EM28XX_MIN_BUF 4
-- 
2.7.4

Re: [PATCH v6 2/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

[Sakari Ailus]

Hi Niklas,

On Thu, May 04, 2017 at 11:30:19PM +0200, Niklas Söderlund wrote:
> Hi Sakari,
> 
> Thanks for your feedback.

You're welcome!

> On 2017-05-04 16:35:26 +0300, Sakari Ailus wrote:
> > Hi Niklas,
> > 
> > On Fri, Apr 28, 2017 at 12:36:58AM +0200, Niklas Söderlund wrote:
> > > A V4L2 driver for Renesas R-Car MIPI CSI-2 receiver. The driver
> > > supports the rcar-vin driver on R-Car Gen3 SoCs where separate CSI-2
> > > hardware blocks are connected between the video sources and the video
> > > grabbers (VIN).
> > > 
> > > Driver is based on a prototype by Koji Matsuoka in the Renesas BSP.
> > > 
> > > Signed-off-by: Niklas Söderlund 
> > > ---
> > >  drivers/media/platform/rcar-vin/Kconfig |  11 +
> > >  drivers/media/platform/rcar-vin/Makefile|   1 +
> > >  drivers/media/platform/rcar-vin/rcar-csi2.c | 872 
> > > 
> > >  3 files changed, 884 insertions(+)
> > >  create mode 100644 drivers/media/platform/rcar-vin/rcar-csi2.c
> > > 
> > > diff --git a/drivers/media/platform/rcar-vin/Kconfig 
> > > b/drivers/media/platform/rcar-vin/Kconfig
> > > index 111d2a151f6a4d44..f1df85d526e96a74 100644
> > > --- a/drivers/media/platform/rcar-vin/Kconfig
> > > +++ b/drivers/media/platform/rcar-vin/Kconfig
> > > @@ -1,3 +1,14 @@
> > > +config VIDEO_RCAR_CSI2
> > > + tristate "R-Car MIPI CSI-2 Receiver"
> > > + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF
> > > + depends on ARCH_RENESAS || COMPILE_TEST
> > > + ---help---
> > > +   Support for Renesas R-Car MIPI CSI-2 receiver.
> > > +   Supports R-Car Gen3 SoCs.
> > > +
> > > +   To compile this driver as a module, choose M here: the
> > > +   module will be called rcar-csi2.
> > > +
> > >  config VIDEO_RCAR_VIN
> > >   tristate "R-Car Video Input (VIN) Driver"
> > >   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF && HAS_DMA && 
> > > MEDIA_CONTROLLER
> > > diff --git a/drivers/media/platform/rcar-vin/Makefile 
> > > b/drivers/media/platform/rcar-vin/Makefile
> > > index 48c5632c21dc060b..5ab803d3e7c1aa57 100644
> > > --- a/drivers/media/platform/rcar-vin/Makefile
> > > +++ b/drivers/media/platform/rcar-vin/Makefile
> > > @@ -1,3 +1,4 @@
> > >  rcar-vin-objs = rcar-core.o rcar-dma.o rcar-v4l2.o
> > >  
> > > +obj-$(CONFIG_VIDEO_RCAR_CSI2) += rcar-csi2.o
> > >  obj-$(CONFIG_VIDEO_RCAR_VIN) += rcar-vin.o
> > > diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c 
> > > b/drivers/media/platform/rcar-vin/rcar-csi2.c
> > > new file mode 100644
> > > index ..53601e171aa179b7
> > > --- /dev/null
> > > +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
> > > @@ -0,0 +1,872 @@
> > > +/*
> > > + * Driver for Renesas R-Car MIPI CSI-2 Receiver
> > > + *
> > > + * Copyright (C) 2017 Renesas Electronics Corp.
> > > + *
> > > + * This program is free software; you can redistribute  it and/or modify 
> > > it
> > > + * under  the terms of  the GNU General  Public License as published by 
> > > the
> > > + * Free Software Foundation;  either version 2 of the  License, or (at 
> > > your
> > > + * option) any later version.
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > 
> > Could you rebase also this on the V4L2 fwnode patchset?
> > 
> > 
> 
> Yes, I rebased the series on top of v4l2-acpi-merge. I like the fwnode 
> patches, nice work!

I'm glad you like it. :-)

> 
> > 
> > > +#include 
> > > +
> > > +/* Register offsets and bits */
> > > +
> > > +/* Control Timing Select */
> > > +#define TREF_REG 0x00
> > > +#define TREF_TREF(1 << 0)
> > > +
> > > +/* Software Reset */
> > > +#define SRST_REG 0x04
> > > +#define SRST_SRST(1 << 0)
> > > +
> > > +/* PHY Operation Control */
> > > +#define PHYCNT_REG   0x08
> > > +#define PHYCNT_SHUTDOWNZ (1 << 17)
> > > +#define PHYCNT_RSTZ  (1 << 16)
> > > +#define PHYCNT_ENABLECLK (1 << 4)
> > > +#define PHYCNT_ENABLE_3  (1 << 3)
> > > +#define PHYCNT_ENABLE_2  (1 << 2)
> > > +#define PHYCNT_ENABLE_1  (1 << 1)
> > > +#define PHYCNT_ENABLE_0  (1 << 0)
> > > +
> > > +/* Checksum Control */
> > > +#define CHKSUM_REG   0x0c
> > > +#define CHKSUM_ECC_EN(1 << 1)
> > > +#define CHKSUM_CRC_EN(1 << 0)
> > > +
> > > +/*
> > > + * Channel Data Type Select
> > > + * VCDT[0-15]:  Channel 1 VCDT[16-31]:  Channel 2
> > > + * VCDT2[0-15]: Channel 3 VCDT2[16-31]: Channel 4
> > > + */
> > > +#define VCDT_REG 0x10
> > > +#define VCDT2_REG0x14
> > > +#define VCDT_VCDTN_EN(1 << 15)
> > > +#define 

[PATCH] media: platform: s3c-camif: fix function prototype

[Gustavo A. R. Silva]

Fix function prototype so the position of arguments camif->colorfx_cb and
camif->colorfx_cr match the order of the parameters when calling
camif_hw_set_effect() function.

Addresses-Coverity-ID: 1248800
Addresses-Coverity-ID: 1269141
Cc: Sylwester Nawrocki 
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/media/platform/s3c-camif/camif-regs.c | 2 +-
 drivers/media/platform/s3c-camif/camif-regs.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/s3c-camif/camif-regs.c 
b/drivers/media/platform/s3c-camif/camif-regs.c
index 812fb3a..d70ffef 100644
--- a/drivers/media/platform/s3c-camif/camif-regs.c
+++ b/drivers/media/platform/s3c-camif/camif-regs.c
@@ -58,7 +58,7 @@ void camif_hw_set_test_pattern(struct camif_dev *camif, 
unsigned int pattern)
 }
 
 void camif_hw_set_effect(struct camif_dev *camif, unsigned int effect,
-   unsigned int cr, unsigned int cb)
+   unsigned int cb, unsigned int cr)
 {
static const struct v4l2_control colorfx[] = {
{ V4L2_COLORFX_NONE,CIIMGEFF_FIN_BYPASS },
diff --git a/drivers/media/platform/s3c-camif/camif-regs.h 
b/drivers/media/platform/s3c-camif/camif-regs.h
index 5ad36c1..dfb49a5 100644
--- a/drivers/media/platform/s3c-camif/camif-regs.h
+++ b/drivers/media/platform/s3c-camif/camif-regs.h
@@ -255,7 +255,7 @@ void camif_hw_set_output_dma(struct camif_vp *vp);
 void camif_hw_set_target_format(struct camif_vp *vp);
 void camif_hw_set_test_pattern(struct camif_dev *camif, unsigned int pattern);
 void camif_hw_set_effect(struct camif_dev *camif, unsigned int effect,
-   unsigned int cr, unsigned int cb);
+   unsigned int cb, unsigned int cr);
 void camif_hw_set_output_addr(struct camif_vp *vp, struct camif_addr *paddr,
  int index);
 void camif_hw_dump_regs(struct camif_dev *camif, const char *label);
-- 
2.5.0

[PATCH v3.2 4/7] v4l: Switch from V4L2 OF not V4L2 fwnode API

[Sakari Ailus]

Switch users of the v4l2_of_ APIs to the more generic v4l2_fwnode_ APIs.
Async OF matching is replaced by fwnode matching and OF matching support
is removed.

Signed-off-by: Sakari Ailus 
Acked-by: Benoit Parrot  # i2c/ov2569.c, am437x/am437x-vpfe.c 
and ti-vpe/cal.c
Tested-by: Hans Verkuil  # Atmel sama5d3 board + ov2640 
sensor
---
since v3.1:

- Remove unused struct v4l2_subdev.of_node field.

 drivers/media/i2c/Kconfig  | 11 +
 drivers/media/i2c/adv7604.c|  7 +--
 drivers/media/i2c/mt9v032.c|  7 +--
 drivers/media/i2c/ov2659.c |  8 ++--
 drivers/media/i2c/ov5645.c |  7 +--
 drivers/media/i2c/ov5647.c |  7 +--
 drivers/media/i2c/s5c73m3/s5c73m3-core.c   |  7 +--
 drivers/media/i2c/s5k5baf.c|  6 +--
 drivers/media/i2c/smiapp/Kconfig   |  1 +
 drivers/media/i2c/smiapp/smiapp-core.c | 29 ++--
 drivers/media/i2c/tc358743.c   | 11 +++--
 drivers/media/i2c/tvp514x.c|  6 +--
 drivers/media/i2c/tvp5150.c|  7 +--
 drivers/media/i2c/tvp7002.c|  6 +--
 drivers/media/platform/Kconfig |  3 ++
 drivers/media/platform/am437x/Kconfig  |  1 +
 drivers/media/platform/am437x/am437x-vpfe.c| 15 +++---
 drivers/media/platform/atmel/Kconfig   |  2 +
 drivers/media/platform/atmel/atmel-isc.c   | 13 --
 drivers/media/platform/atmel/atmel-isi.c   | 11 +++--
 drivers/media/platform/exynos4-is/Kconfig  |  2 +
 drivers/media/platform/exynos4-is/media-dev.c  | 13 +++---
 drivers/media/platform/exynos4-is/mipi-csis.c  |  6 +--
 drivers/media/platform/omap3isp/isp.c  | 49 ++--
 drivers/media/platform/pxa_camera.c| 11 +++--
 drivers/media/platform/rcar-vin/Kconfig|  1 +
 drivers/media/platform/rcar-vin/rcar-core.c| 19 
 drivers/media/platform/soc_camera/soc_camera.c |  7 +--
 drivers/media/platform/ti-vpe/cal.c| 15 +++---
 drivers/media/platform/xilinx/Kconfig  |  1 +
 drivers/media/platform/xilinx/xilinx-vipp.c| 63 ++
 drivers/media/v4l2-core/v4l2-async.c   | 14 +-
 include/media/v4l2-async.h |  5 --
 include/media/v4l2-subdev.h|  2 -
 34 files changed, 204 insertions(+), 169 deletions(-)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index fd181c9..7c23b7a 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -209,6 +209,7 @@ config VIDEO_ADV7604
depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
depends on GPIOLIB || COMPILE_TEST
select HDMI
+   select V4L2_FWNODE
---help---
  Support for the Analog Devices ADV7604 video decoder.
 
@@ -322,6 +323,7 @@ config VIDEO_TC358743
tristate "Toshiba TC358743 decoder"
depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
select HDMI
+   select V4L2_FWNODE
---help---
  Support for the Toshiba TC358743 HDMI to MIPI CSI-2 bridge.
 
@@ -331,6 +333,7 @@ config VIDEO_TC358743
 config VIDEO_TVP514X
tristate "Texas Instruments TVP514x video decoder"
depends on VIDEO_V4L2 && I2C
+   select V4L2_FWNODE
---help---
  This is a Video4Linux2 sensor-level driver for the TI TVP5146/47
  decoder. It is currently working with the TI OMAP3 camera
@@ -342,6 +345,7 @@ config VIDEO_TVP514X
 config VIDEO_TVP5150
tristate "Texas Instruments TVP5150 video decoder"
depends on VIDEO_V4L2 && I2C
+   select V4L2_FWNODE
---help---
  Support for the Texas Instruments TVP5150 video decoder.
 
@@ -351,6 +355,7 @@ config VIDEO_TVP5150
 config VIDEO_TVP7002
tristate "Texas Instruments TVP7002 video decoder"
depends on VIDEO_V4L2 && I2C
+   select V4L2_FWNODE
---help---
  Support for the Texas Instruments TVP7002 video decoder.
 
@@ -532,6 +537,7 @@ config VIDEO_OV2659
tristate "OmniVision OV2659 sensor support"
depends on VIDEO_V4L2 && I2C
depends on MEDIA_CAMERA_SUPPORT
+   select V4L2_FWNODE
---help---
  This is a Video4Linux2 sensor-level driver for the OmniVision
  OV2659 camera.
@@ -544,6 +550,7 @@ config VIDEO_OV5645
depends on OF
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
depends on MEDIA_CAMERA_SUPPORT
+   select V4L2_FWNODE
---help---
  This is a Video4Linux2 sensor-level driver for the OmniVision
  OV5645 camera.
@@ -555,6 +562,7 @@ config VIDEO_OV5647
tristate "OmniVision OV5647 sensor support"
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
depends on MEDIA_CAMERA_SUPPORT
+   select V4L2_FWNODE

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

[Pavel Machek]

Hi!

> This RFC patchset documents properties commonly required by camera modules
> and associated camera flash devices.
> 
> The camera module is essentially a package consisting of an image sensor,
> a lens, possibly a voice coil to move the lens and a number of other
> things that at least the drivers need not to know of. All the devices in a
> camera module are declared separately in the system and as such the fact
> that they come in a single package isn't generally very useful to driver
> software.
> 
> I'm sending the set as RFC as there's no driver implementation, and a
> dependency to the V4L2 async changes:
> 
> 

For the series,

Acked-by: Pavel Machek 

In 3/3, I'd avoid using strange characters in the changelog. Just
write it as I2C... If someone ever tries to grep the changelogs, this
could bite them.

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: [PATCH] [media] imx: switch from V4L2 OF to V4L2 fwnode API

[Sakari Ailus]

Hi Philipp,

Thanks for the patch!

On Thu, May 04, 2017 at 03:37:30PM +0200, Philipp Zabel wrote:
...
> @@ -194,11 +195,11 @@ static int imx_media_subdev_bound(struct 
> v4l2_async_notifier *notifier,
> struct v4l2_async_subdev *asd)
>  {
>   struct imx_media_dev *imxmd = notifier2dev(notifier);
> + struct device_node *np = to_of_node(dev_fwnode(sd->dev));

dev_fwnode(sd->dev) isn't necessarily the same as sd->fwnode. How about
to_of_node(sd->fwnode) instead?

I realised I had left both v4l2_subdev->of_node and v4l2_subdev->fwnode;
v4l2_subdev->of_node is unused. I'll remove it.

The other changes seem good to me.

>   struct imx_media_subdev *imxsd;
>   int ret = -EINVAL;
>  
> - imxsd = imx_media_find_async_subdev(imxmd, sd->of_node,
> - dev_name(sd->dev));
> + imxsd = imx_media_find_async_subdev(imxmd, np, dev_name(sd->dev));
>   if (!imxsd)
>   goto out;
>  

-- 
Kind regards,

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

Re: [PATCH v6 2/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

[Niklas Söderlund]

Hi Sakari,

Thanks for your feedback.

On 2017-05-04 16:35:26 +0300, Sakari Ailus wrote:
> Hi Niklas,
> 
> On Fri, Apr 28, 2017 at 12:36:58AM +0200, Niklas Söderlund wrote:
> > A V4L2 driver for Renesas R-Car MIPI CSI-2 receiver. The driver
> > supports the rcar-vin driver on R-Car Gen3 SoCs where separate CSI-2
> > hardware blocks are connected between the video sources and the video
> > grabbers (VIN).
> > 
> > Driver is based on a prototype by Koji Matsuoka in the Renesas BSP.
> > 
> > Signed-off-by: Niklas Söderlund 
> > ---
> >  drivers/media/platform/rcar-vin/Kconfig |  11 +
> >  drivers/media/platform/rcar-vin/Makefile|   1 +
> >  drivers/media/platform/rcar-vin/rcar-csi2.c | 872 
> > 
> >  3 files changed, 884 insertions(+)
> >  create mode 100644 drivers/media/platform/rcar-vin/rcar-csi2.c
> > 
> > diff --git a/drivers/media/platform/rcar-vin/Kconfig 
> > b/drivers/media/platform/rcar-vin/Kconfig
> > index 111d2a151f6a4d44..f1df85d526e96a74 100644
> > --- a/drivers/media/platform/rcar-vin/Kconfig
> > +++ b/drivers/media/platform/rcar-vin/Kconfig
> > @@ -1,3 +1,14 @@
> > +config VIDEO_RCAR_CSI2
> > +   tristate "R-Car MIPI CSI-2 Receiver"
> > +   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF
> > +   depends on ARCH_RENESAS || COMPILE_TEST
> > +   ---help---
> > + Support for Renesas R-Car MIPI CSI-2 receiver.
> > + Supports R-Car Gen3 SoCs.
> > +
> > + To compile this driver as a module, choose M here: the
> > + module will be called rcar-csi2.
> > +
> >  config VIDEO_RCAR_VIN
> > tristate "R-Car Video Input (VIN) Driver"
> > depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF && HAS_DMA && 
> > MEDIA_CONTROLLER
> > diff --git a/drivers/media/platform/rcar-vin/Makefile 
> > b/drivers/media/platform/rcar-vin/Makefile
> > index 48c5632c21dc060b..5ab803d3e7c1aa57 100644
> > --- a/drivers/media/platform/rcar-vin/Makefile
> > +++ b/drivers/media/platform/rcar-vin/Makefile
> > @@ -1,3 +1,4 @@
> >  rcar-vin-objs = rcar-core.o rcar-dma.o rcar-v4l2.o
> >  
> > +obj-$(CONFIG_VIDEO_RCAR_CSI2) += rcar-csi2.o
> >  obj-$(CONFIG_VIDEO_RCAR_VIN) += rcar-vin.o
> > diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c 
> > b/drivers/media/platform/rcar-vin/rcar-csi2.c
> > new file mode 100644
> > index ..53601e171aa179b7
> > --- /dev/null
> > +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
> > @@ -0,0 +1,872 @@
> > +/*
> > + * Driver for Renesas R-Car MIPI CSI-2 Receiver
> > + *
> > + * Copyright (C) 2017 Renesas Electronics Corp.
> > + *
> > + * This program is free software; you can redistribute  it and/or modify it
> > + * under  the terms of  the GNU General  Public License as published by the
> > + * Free Software Foundation;  either version 2 of the  License, or (at your
> > + * option) any later version.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> 
> Could you rebase also this on the V4L2 fwnode patchset?
> 
> 

Yes, I rebased the series on top of v4l2-acpi-merge. I like the fwnode 
patches, nice work!

> 
> > +#include 
> > +
> > +/* Register offsets and bits */
> > +
> > +/* Control Timing Select */
> > +#define TREF_REG   0x00
> > +#define TREF_TREF  (1 << 0)
> > +
> > +/* Software Reset */
> > +#define SRST_REG   0x04
> > +#define SRST_SRST  (1 << 0)
> > +
> > +/* PHY Operation Control */
> > +#define PHYCNT_REG 0x08
> > +#define PHYCNT_SHUTDOWNZ   (1 << 17)
> > +#define PHYCNT_RSTZ(1 << 16)
> > +#define PHYCNT_ENABLECLK   (1 << 4)
> > +#define PHYCNT_ENABLE_3(1 << 3)
> > +#define PHYCNT_ENABLE_2(1 << 2)
> > +#define PHYCNT_ENABLE_1(1 << 1)
> > +#define PHYCNT_ENABLE_0(1 << 0)
> > +
> > +/* Checksum Control */
> > +#define CHKSUM_REG 0x0c
> > +#define CHKSUM_ECC_EN  (1 << 1)
> > +#define CHKSUM_CRC_EN  (1 << 0)
> > +
> > +/*
> > + * Channel Data Type Select
> > + * VCDT[0-15]:  Channel 1 VCDT[16-31]:  Channel 2
> > + * VCDT2[0-15]: Channel 3 VCDT2[16-31]: Channel 4
> > + */
> > +#define VCDT_REG   0x10
> > +#define VCDT2_REG  0x14
> > +#define VCDT_VCDTN_EN  (1 << 15)
> > +#define VCDT_SEL_VC(n) (((n) & 0x3) << 8)
> > +#define VCDT_SEL_DTN_ON(1 << 6)
> > +#define VCDT_SEL_DT(n) (((n) & 0x1f) << 0)
> > +
> > +/* Frame Data Type Select */
> > +#define FRDT_REG   0x18
> > +
> > +/* Field Detection Control */
> > +#define FLD_REG0x1c
> > +#define FLD_FLD_NUM(n)   

Re: [media-s3c-camif] question about arguments position

[Gustavo A. R. Silva]

Hello Sylwester,

Quoting Sylwester Nawrocki :


Hi Gustavo,

On 05/04/2017 09:05 PM, Gustavo A. R. Silva wrote:

The issue here is that the position of arguments in the call to
camif_hw_set_effect() function do not match the order of the parameters:

camif->colorfx_cb is passed to cr
camif->colorfx_cr is passed to cb

This is the function prototype:

void camif_hw_set_effect(struct camif_dev *camif, unsigned int effect,
unsigned int cr, unsigned int cb)

My question here is if this is intentional?

In case it is not, I will send a patch to fix it. But first it would be
great to hear any comment about it.


You are right, it seems you have found a real bug. Feel free to send a patch.
The best thing to do now might be to change the function prototype to:

void camif_hw_set_effect(struct camif_dev *camif, unsigned int effect,
 unsigned int cb, unsigned int cr)



OK, I'll send a patch for this shortly.

Thanks for clarifying.
--
Gustavo A. R. Silva

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

[Sakari Ailus]

Hi Philipp,

On Thu, May 04, 2017 at 03:38:57PM +0200, Philipp Zabel wrote:
...
> +static const struct of_device_id video_mux_dt_ids[] = {
> + { .compatible = "video-mux", },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, video_mux_dt_ids);
> +
> +static struct platform_driver video_mux_driver = {

Shouldn't this be const?

With that,

Acked-by: Sakari Ailus 

> + .probe  = video_mux_probe,
> + .remove = video_mux_remove,
> + .driver = {
> + .of_match_table = video_mux_dt_ids,
> + .name = "video-mux",
> + },
> +};
> +
> +module_platform_driver(video_mux_driver);
> +
> +MODULE_DESCRIPTION("video stream multiplexer");
> +MODULE_AUTHOR("Sascha Hauer, Pengutronix");
> +MODULE_AUTHOR("Philipp Zabel, Pengutronix");
> +MODULE_LICENSE("GPL");

-- 
Regards,

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

Re: [PATCH 2/3] [media] af9035: init i2c already in it930x_frontend_attach

[Andreas Kemnade]

On Wed, 15 Mar 2017 23:22:09 +0100
Andreas Kemnade  wrote:

> i2c bus is already needed when the frontend is probed,
> so init it already in it930x_frontend_attach
> That prevents errors like
>  si2168: probe of 6-0067 failed with error -5
> 
> Signed-off-by: Andreas Kemnade 

seems to be also needed for the
CINERGY TC2 Stick
Quoting from 
https://www.linuxmintusers.de/index.php?topic=41074.30

Mar 26 12:44:14 minimoose kernel: [  732.884876] usb 1-3: dvb_usb_v2: found a 
'TerraTec Cinergy TC2 Stick' in warm state
Mar 26 12:44:14 minimoose kernel: [  732.885012] usb 1-3: dvb_usb_v2: will pass 
the complete MPEG2 transport stream to the software demuxer
Mar 26 12:44:14 minimoose kernel: [  732.885245] dvbdev: DVB: registering new 
adapter (TerraTec Cinergy TC2 Stick)
Mar 26 12:44:14 minimoose kernel: [  732.885254] usb 1-3: media controller 
created
Mar 26 12:44:14 minimoose kernel: [  732.886117] dvbdev: 
dvb_create_media_entity: media entity 'dvb-demux' registered.
Mar 26 12:44:14 minimoose kernel: [  732.890589] si2168: probe of 8-0067 failed 
with error -5


Regards,
Andreas Kemnade


pgpF5dcxduV9N.pgp
Description: OpenPGP digital signature

Re: [media-s3c-camif] question about arguments position

[Sylwester Nawrocki]

Hi Gustavo,

On 05/04/2017 09:05 PM, Gustavo A. R. Silva wrote:
> The issue here is that the position of arguments in the call to
> camif_hw_set_effect() function do not match the order of the parameters:
> 
> camif->colorfx_cb is passed to cr
> camif->colorfx_cr is passed to cb
> 
> This is the function prototype:
> 
> void camif_hw_set_effect(struct camif_dev *camif, unsigned int effect,
> unsigned int cr, unsigned int cb)
> 
> My question here is if this is intentional?
> 
> In case it is not, I will send a patch to fix it. But first it would be
> great to hear any comment about it.

You are right, it seems you have found a real bug. Feel free to send a patch.
The best thing to do now might be to change the function prototype to:

void camif_hw_set_effect(struct camif_dev *camif, unsigned int effect,
 unsigned int cb, unsigned int cr)

--
Regards,
Sylwester

[media-s3c-camif] question about arguments position

[Gustavo A. R. Silva]

Hello everybody,

While looking into Coverity ID 1248800 I ran into the following piece  
of code at drivers/media/platform/s3c-camif/camif-capture.c:67:


/* Locking: called with camif->slock spinlock held */
static int s3c_camif_hw_init(struct camif_dev *camif, struct camif_vp *vp)
{
const struct s3c_camif_variant *variant = camif->variant;

if (camif->sensor.sd == NULL || vp->out_fmt == NULL)
return -EINVAL;

if (variant->ip_revision == S3C244X_CAMIF_IP_REV)
camif_hw_clear_fifo_overflow(vp);
camif_hw_set_camera_bus(camif);
camif_hw_set_source_format(camif);
camif_hw_set_camera_crop(camif);
camif_hw_set_test_pattern(camif, camif->test_pattern);
if (variant->has_img_effect)
camif_hw_set_effect(camif, camif->colorfx,
camif->colorfx_cb, camif->colorfx_cr);
if (variant->ip_revision == S3C6410_CAMIF_IP_REV)
camif_hw_set_input_path(vp);
camif_cfg_video_path(vp);
vp->state &= ~ST_VP_CONFIG;

return 0;
}


The issue here is that the position of arguments in the call to  
camif_hw_set_effect() function do not match the order of the parameters:


camif->colorfx_cb is passed to cr
camif->colorfx_cr is passed to cb

This is the function prototype:

void camif_hw_set_effect(struct camif_dev *camif, unsigned int effect,
unsigned int cr, unsigned int cb)

My question here is if this is intentional?

In case it is not, I will send a patch to fix it. But first it would  
be great to hear any comment about it.


By the way... the same is happening at  
drivers/media/platform/s3c-camif/camif-capture.c:366


Thank you
--
Gustavo A. R. Silva

[PATCH] [media] bdisp-debug: Replace a seq_puts() call by seq_putc() in seven functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 4 May 2017 19:14:15 +0200

Seven single characters (line breaks) should be put into a sequence.
Thus use the corresponding function "seq_putc".

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/media/platform/sti/bdisp/bdisp-debug.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/sti/bdisp/bdisp-debug.c 
b/drivers/media/platform/sti/bdisp/bdisp-debug.c
index 7af66860d624..2cc289e4dea1 100644
--- a/drivers/media/platform/sti/bdisp/bdisp-debug.c
+++ b/drivers/media/platform/sti/bdisp/bdisp-debug.c
@@ -104,7 +104,7 @@ static void bdisp_dbg_dump_ins(struct seq_file *s, u32 val)
if (val & BLT_INS_IRQ)
seq_puts(s, "IRQ - ");
 
-   seq_puts(s, "\n");
+   seq_putc(s, '\n');
 }
 
 static void bdisp_dbg_dump_tty(struct seq_file *s, u32 val)
@@ -153,7 +153,7 @@ static void bdisp_dbg_dump_tty(struct seq_file *s, u32 val)
if (val & BLT_TTY_BIG_END)
seq_puts(s, "BigEndian - ");
 
-   seq_puts(s, "\n");
+   seq_putc(s, '\n');
 }
 
 static void bdisp_dbg_dump_xy(struct seq_file *s, u32 val, char *name)
@@ -230,7 +230,7 @@ static void bdisp_dbg_dump_sty(struct seq_file *s,
seq_puts(s, "BigEndian - ");
 
 done:
-   seq_puts(s, "\n");
+   seq_putc(s, '\n');
 }
 
 static void bdisp_dbg_dump_fctl(struct seq_file *s, u32 val)
@@ -247,7 +247,7 @@ static void bdisp_dbg_dump_fctl(struct seq_file *s, u32 val)
else if ((val & BLT_FCTL_HV_SCALE) == BLT_FCTL_HV_SAMPLE)
seq_puts(s, "Sample Chroma");
 
-   seq_puts(s, "\n");
+   seq_putc(s, '\n');
 }
 
 static void bdisp_dbg_dump_rsf(struct seq_file *s, u32 val, char *name)
@@ -266,7 +266,7 @@ static void bdisp_dbg_dump_rsf(struct seq_file *s, u32 val, 
char *name)
seq_printf(s, "V: %d(6.10) / scale~%dx0.1", inc, 1024 * 10 / inc);
 
 done:
-   seq_puts(s, "\n");
+   seq_putc(s, '\n');
 }
 
 static void bdisp_dbg_dump_rzi(struct seq_file *s, u32 val, char *name)
@@ -281,7 +281,7 @@ static void bdisp_dbg_dump_rzi(struct seq_file *s, u32 val, 
char *name)
seq_printf(s, "V: init=%d repeat=%d", val & 0x3FF, (val >> 12) & 7);
 
 done:
-   seq_puts(s, "\n");
+   seq_putc(s, '\n');
 }
 
 static void bdisp_dbg_dump_ivmx(struct seq_file *s,
@@ -293,7 +293,7 @@ static void bdisp_dbg_dump_ivmx(struct seq_file *s,
seq_printf(s, "IVMX3\t0x%08X\t", c3);
 
if (!c0 && !c1 && !c2 && !c3) {
-   seq_puts(s, "\n");
+   seq_putc(s, '\n');
return;
}
 
-- 
2.12.2

Re: [PATCH] [media] tc358743: fix register i2c_rd/wr function fix

[Arnd Bergmann]

On Thu, May 4, 2017 at 5:36 PM, Philipp Zabel  wrote:
> Hi Arnd,
>
> On Thu, 2017-05-04 at 17:24 +0200, Arnd Bergmann wrote:
>> On Thu, May 4, 2017 at 5:20 PM, Philipp Zabel  wrote:
>> > The below mentioned fix contains a small but severe bug,
>> > fix it to make the driver work again.
>> >
>> > Fixes: 3538aa6ecfb2 ("[media] tc358743: fix register i2c_rd/wr functions")
>> > Cc: Arnd Bergmann 
>> > Cc: Hans Verkuil 
>> > Cc: Mauro Carvalho Chehab 
>> > Signed-off-by: Philipp Zabel 
>> > ---
>>
>> Cc: sta...@vger.kernel.org # v4.11
>>
>> Acked-by: Arnd Bergmann 
>>
>> Sorry about the typo
>
> Thanks, the original fix currently is only in the media-tree master
> branch. I don't see any indication that it is queued for
> stable/linux-4.11.y though. Should it be?

Sorry, my mistake (again). I looked it up wrong.

  Arnd

[PATCH 1/4] lib/scatterlist: Fix offset type in sg_alloc_table_from_pages

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Scatterlist entries have an unsigned int for the offset so
correct the sg_alloc_table_from_pages function accordingly.

Since these are offsets withing a page, unsigned int is
wide enough.

Also converts callers which were using unsigned long locally
with the lower_32_bits annotation to make it explicitly
clear what is happening.

v2: Use offset_in_page. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
Cc: Masahiro Yamada 
Cc: Pawel Osciak 
Cc: Marek Szyprowski 
Cc: Kyungmin Park 
Cc: Tomasz Stanislawski 
Cc: Matt Porter 
Cc: Alexandre Bounine 
Cc: linux-media@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Acked-by: Marek Szyprowski  (v1)
Reviewed-by: Chris Wilson 
Reviewed-by: Mauro Carvalho Chehab 
---
 drivers/media/v4l2-core/videobuf2-dma-contig.c | 4 ++--
 drivers/rapidio/devices/rio_mport_cdev.c   | 4 ++--
 include/linux/scatterlist.h| 2 +-
 lib/scatterlist.c  | 2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 2db0413f5d57..b5009c1649bc 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -478,7 +478,7 @@ static void *vb2_dc_get_userptr(struct device *dev, 
unsigned long vaddr,
 {
struct vb2_dc_buf *buf;
struct frame_vector *vec;
-   unsigned long offset;
+   unsigned int offset;
int n_pages, i;
int ret = 0;
struct sg_table *sgt;
@@ -506,7 +506,7 @@ static void *vb2_dc_get_userptr(struct device *dev, 
unsigned long vaddr,
buf->dev = dev;
buf->dma_dir = dma_dir;
 
-   offset = vaddr & ~PAGE_MASK;
+   offset = lower_32_bits(offset_in_page(vaddr));
vec = vb2_create_framevec(vaddr, size, dma_dir == DMA_FROM_DEVICE);
if (IS_ERR(vec)) {
ret = PTR_ERR(vec);
diff --git a/drivers/rapidio/devices/rio_mport_cdev.c 
b/drivers/rapidio/devices/rio_mport_cdev.c
index 50b617af81bd..a8b6696ab6cb 100644
--- a/drivers/rapidio/devices/rio_mport_cdev.c
+++ b/drivers/rapidio/devices/rio_mport_cdev.c
@@ -876,10 +876,10 @@ rio_dma_transfer(struct file *filp, u32 transfer_mode,
 * offset within the internal buffer specified by handle parameter.
 */
if (xfer->loc_addr) {
-   unsigned long offset;
+   unsigned int offset;
long pinned;
 
-   offset = (unsigned long)(uintptr_t)xfer->loc_addr & ~PAGE_MASK;
+   offset = lower_32_bits(offset_in_page(xfer->loc_addr));
nr_pages = PAGE_ALIGN(xfer->length + offset) >> PAGE_SHIFT;
 
page_list = kmalloc_array(nr_pages,
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index cb3c8fe6acd7..c981bee1a3ae 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -263,7 +263,7 @@ int __sg_alloc_table(struct sg_table *, unsigned int, 
unsigned int,
 int sg_alloc_table(struct sg_table *, unsigned int, gfp_t);
 int sg_alloc_table_from_pages(struct sg_table *sgt,
struct page **pages, unsigned int n_pages,
-   unsigned long offset, unsigned long size,
+   unsigned int offset, unsigned long size,
gfp_t gfp_mask);
 
 size_t sg_copy_buffer(struct scatterlist *sgl, unsigned int nents, void *buf,
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index c6cf82242d65..11f172c383cb 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -391,7 +391,7 @@ EXPORT_SYMBOL(sg_alloc_table);
  */
 int sg_alloc_table_from_pages(struct sg_table *sgt,
struct page **pages, unsigned int n_pages,
-   unsigned long offset, unsigned long size,
+   unsigned int offset, unsigned long size,
gfp_t gfp_mask)
 {
unsigned int chunks;
-- 
2.9.3

Re: [PATCH] [media] tc358743: fix register i2c_rd/wr function fix

[Philipp Zabel]

Hi Arnd,

On Thu, 2017-05-04 at 17:24 +0200, Arnd Bergmann wrote:
> On Thu, May 4, 2017 at 5:20 PM, Philipp Zabel  wrote:
> > The below mentioned fix contains a small but severe bug,
> > fix it to make the driver work again.
> >
> > Fixes: 3538aa6ecfb2 ("[media] tc358743: fix register i2c_rd/wr functions")
> > Cc: Arnd Bergmann 
> > Cc: Hans Verkuil 
> > Cc: Mauro Carvalho Chehab 
> > Signed-off-by: Philipp Zabel 
> > ---
> 
> Cc: sta...@vger.kernel.org # v4.11
>
> Acked-by: Arnd Bergmann 
> 
> Sorry about the typo

Thanks, the original fix currently is only in the media-tree master
branch. I don't see any indication that it is queued for
stable/linux-4.11.y though. Should it be?

regards
Philipp

Re: [PATCH] [media] tc358743: fix register i2c_rd/wr function fix

[Arnd Bergmann]

On Thu, May 4, 2017 at 5:20 PM, Philipp Zabel  wrote:
> The below mentioned fix contains a small but severe bug,
> fix it to make the driver work again.
>
> Fixes: 3538aa6ecfb2 ("[media] tc358743: fix register i2c_rd/wr functions")
> Cc: Arnd Bergmann 
> Cc: Hans Verkuil 
> Cc: Mauro Carvalho Chehab 
> Signed-off-by: Philipp Zabel 
> ---

Cc: sta...@vger.kernel.org # v4.11
Acked-by: Arnd Bergmann 

Sorry about the typo

Re: [PATCH v4 16/27] rcar-vin: add functions to manipulate Gen3 CHSEL value

[Geert Uytterhoeven]

Hi Sakari,

On Thu, May 4, 2017 at 4:45 PM, Sakari Ailus  wrote:
>> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
>> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
>> @@ -16,6 +16,7 @@
>>
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include 
>>
>> @@ -1240,3 +1241,45 @@ int rvin_dma_probe(struct rvin_dev *vin, int irq)
>>
>>   return ret;
>>  }
>> +
>> +/* 
>> -
>> + * Gen3 CHSEL manipulation
>> + */
>> +
>> +int rvin_set_chsel(struct rvin_dev *vin, u8 chsel)
>> +{
>> + u32 ifmd;
>> +
>> + pm_runtime_get_sync(vin->dev);
>
> Can this fail? Just wondering.

In theory, yes.
In practice, no, unless the system is completely broken.

Gr{oetje,eeting}s,

Geert

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

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

[PATCH] [media] tc358743: fix register i2c_rd/wr function fix

[Philipp Zabel]

The below mentioned fix contains a small but severe bug,
fix it to make the driver work again.

Fixes: 3538aa6ecfb2 ("[media] tc358743: fix register i2c_rd/wr functions")
Cc: Arnd Bergmann 
Cc: Hans Verkuil 
Cc: Mauro Carvalho Chehab 
Signed-off-by: Philipp Zabel 
---
 drivers/media/i2c/tc358743.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c
index acef4eca269f1..3251cba89e8f6 100644
--- a/drivers/media/i2c/tc358743.c
+++ b/drivers/media/i2c/tc358743.c
@@ -223,7 +223,7 @@ static void i2c_wr8(struct v4l2_subdev *sd, u16 reg, u8 val)
 static void i2c_wr8_and_or(struct v4l2_subdev *sd, u16 reg,
u8 mask, u8 val)
 {
-   i2c_wrreg(sd, reg, (i2c_rdreg(sd, reg, 2) & mask) | val, 2);
+   i2c_wrreg(sd, reg, (i2c_rdreg(sd, reg, 1) & mask) | val, 1);
 }
 
 static u16 i2c_rd16(struct v4l2_subdev *sd, u16 reg)
-- 
2.11.0

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

[Philipp Zabel]

Add bindings documentation for the video multiplexer device.

Signed-off-by: Sascha Hauer 
Signed-off-by: Philipp Zabel 
Signed-off-by: Steve Longerbeam 
Acked-by: Sakari Ailus 
Reviewed-by: Sebastian Reichel 
---
No changes since v3 [1].

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

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

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

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

[Philipp Zabel]

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

Signed-off-by: Sascha Hauer 
Signed-off-by: Philipp Zabel 
Signed-off-by: Steve Longerbeam 
---
Changes since v3 [1]:
 - Dropped v4l2-fwnode dependency and endpoint parsing for now.
 - Use devm_kcalloc to allocate arrays.

This was previously sent as part of Steve's i.MX media series [2].
Tested against
https://git.linuxtv.org/sailus/media_tree.git/log/?h=v4l2-acpi-merge

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

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

Re: [PATCH v4 21/27] rcar-vin: add group allocator functions

[Sakari Ailus]

Hi Niklas,

On Fri, Apr 28, 2017 at 12:41:57AM +0200, Niklas Söderlund wrote:
> In media controller mode all VIN instances needs to be part of the same
> media graph. There is also a need to each VIN instance to know and in
> some cases be able to communicate with other VIN instances.
> 
> Add a allocator framework where the first VIN instance to be probed
> creates a shared data structure and creates a media device.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 112 
> +++-
>  drivers/media/platform/rcar-vin/rcar-vin.h  |  38 ++
>  2 files changed, 147 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index f560d27449b84882..c10770d5ec37816c 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -20,12 +20,110 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
>  #include "rcar-vin.h"
>  
>  /* 
> -
> + * Gen3 CSI2 Group Allocator
> + */
> +
> +static DEFINE_MUTEX(rvin_group_lock);
> +static struct rvin_group *rvin_group_data;

Uh-oh.

It'd be nice to find a way for managing the group of devices without a
global list for the group.

Do all the callers operating on a group have some kind of identifying
information, e.g. OF node or struct device? Could it be used to obtain the
group?

I'm not sure if this would be a real problem though as long as you have only
a single group in a system.

> +
> +static void rvin_group_release(struct kref *kref)
> +{
> + struct rvin_group *group =
> + container_of(kref, struct rvin_group, refcount);
> +
> + mutex_lock(_group_lock);
> +
> + media_device_unregister(>mdev);
> + media_device_cleanup(>mdev);
> +
> + rvin_group_data = NULL;
> +
> + mutex_unlock(_group_lock);
> +
> + kfree(group);
> +}
> +
> +static struct rvin_group *__rvin_group_allocate(struct rvin_dev *vin)
> +{
> + struct rvin_group *group;
> +
> + if (rvin_group_data) {
> + group = rvin_group_data;
> + kref_get(>refcount);
> + vin_dbg(vin, "%s: get group=%p\n", __func__, group);
> + return group;
> + }
> +
> + group = kzalloc(sizeof(*group), GFP_KERNEL);
> + if (!group)
> + return NULL;
> +
> + kref_init(>refcount);
> + rvin_group_data = group;
> +
> + vin_dbg(vin, "%s: alloc group=%p\n", __func__, group);
> + return group;
> +}
> +
> +static struct rvin_group *rvin_group_allocate(struct rvin_dev *vin)
> +{
> + struct rvin_group *group;
> + struct media_device *mdev;
> + int ret;
> +
> + mutex_lock(_group_lock);
> +
> + group = __rvin_group_allocate(vin);
> + if (!group) {
> + mutex_unlock(_group_lock);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + /* Init group data if its not already initialized */
> + mdev = >mdev;
> + if (!mdev->dev) {
> + mutex_init(>lock);
> + mdev->dev = vin->dev;
> +
> + strlcpy(mdev->driver_name, "Renesas VIN",
> + sizeof(mdev->driver_name));
> + strlcpy(mdev->model, vin->dev->of_node->name,
> + sizeof(mdev->model));
> + strlcpy(mdev->bus_info, of_node_full_name(vin->dev->of_node),
> + sizeof(mdev->bus_info));
> + mdev->driver_version = LINUX_VERSION_CODE;
> + media_device_init(mdev);
> +
> + ret = media_device_register(mdev);
> + if (ret) {
> + vin_err(vin, "Failed to register media device\n");
> + kref_put(>refcount, rvin_group_release);
> + mutex_unlock(_group_lock);
> + return ERR_PTR(ret);
> + }
> + }
> +
> + vin->v4l2_dev.mdev = mdev;
> +
> + mutex_unlock(_group_lock);
> +
> + return group;
> +}
> +
> +static void rvin_group_delete(struct rvin_dev *vin)
> +{
> + vin_dbg(vin, "%s: group=%p\n", __func__, >group);
> + kref_put(>group->refcount, rvin_group_release);
> +}
> +
> +/* 
> -
>   * Async notifier
>   */
>  
> @@ -263,9 +361,13 @@ static int rvin_group_init(struct rvin_dev *vin)
>  {
>   int ret;
>  
> + vin->group = rvin_group_allocate(vin);
> + if (IS_ERR(vin->group))
> + return PTR_ERR(vin->group);
> +
>   ret = rvin_v4l2_mc_probe(vin);
>   if (ret)
> - return ret;
> + goto error_group;
>  
>   vin->pad.flags = MEDIA_PAD_FL_SINK;
>   ret = media_entity_pads_init(>vdev->entity, 1, >pad);
> @@ -275,6 +377,8 @@ static int rvin_group_init(struct rvin_dev *vin)
>   return 0;
>  error_v4l2:
>  

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

[Philipp Zabel]

Hi Sebastian,

On Thu, 2017-05-04 at 16:21 +0200, Sebastian Reichel wrote:
> Hi,
> 
> On Thu, May 04, 2017 at 03:38:57PM +0200, Philipp Zabel wrote:
> > This driver can handle SoC internal and external video bus multiplexers,
> > controlled by mux controllers provided by the mux controller framework,
> > such as MMIO register bitfields or GPIOs. The subdevice passes through
> > the mbus configuration of the active input to the output side.
> > 
> > Signed-off-by: Sascha Hauer 
> > Signed-off-by: Philipp Zabel 
> > Signed-off-by: Steve Longerbeam 
> > ---
> > Changes since v2 [1]:
> >  - Extend vmux->lock to protect mbus format against simultaneous access
> >from get/set_format calls.
> >  - Drop is_source_pad(), check pad->flags & MEDIA_PAD_FL_SOURCE directly.
> >  - Replace v4l2_of_parse_endpoint call with v4l2_fwnode_endpoint_parse,
> >include media/v4l2-fwnode.h instead of media/v4l2-of.h.
> >  - Constify ops structures.
> > 
> > This was previously sent as part of Steve's i.MX media series [2].
> > Tested against
> > https://git.linuxtv.org/sailus/media_tree.git/log/?h=v4l2-acpi-merge
> > 
> > [1] https://patchwork.kernel.org/patch/9708237/
> > [2] https://patchwork.kernel.org/patch/9647869/
> 
> Looks fine to me. Just one nitpick:
> 
> > +static int video_mux_probe(struct platform_device *pdev)
> > +{
> 
> [...]
> 
> > +   vmux->pads = devm_kzalloc(dev, sizeof(*vmux->pads) * num_pads,
> > + GFP_KERNEL);
> > +   vmux->format_mbus = devm_kzalloc(dev, sizeof(*vmux->format_mbus) *
> > +num_pads, GFP_KERNEL);
> > +   vmux->endpoint = devm_kzalloc(dev, sizeof(*vmux->endpoint) *
> > + (num_pads - 1), GFP_KERNEL);
> 
> devm_kcalloc(dev, num_pads, sizeof(*foo), GFP_KERNEL).

thank you, I'll fix this.

regards
Philipp

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

[Philipp Zabel]

Hi Kieran,

On Thu, 2017-05-04 at 15:59 +0100, Kieran Bingham wrote:
> Hi Philipp,
> 
> Thankyou for the patch,

thank you for reviewing.

> On 04/05/17 14:38, Philipp Zabel wrote:
> > This driver can handle SoC internal and external video bus multiplexers,
> > controlled by mux controllers provided by the mux controller framework,
> > such as MMIO register bitfields or GPIOs. The subdevice passes through
> > the mbus configuration of the active input to the output side.
> > 
> > Signed-off-by: Sascha Hauer 
> > Signed-off-by: Philipp Zabel 
> > Signed-off-by: Steve Longerbeam 
> > ---
> > Changes since v2 [1]:
> >  - Extend vmux->lock to protect mbus format against simultaneous access
> >from get/set_format calls.
> >  - Drop is_source_pad(), check pad->flags & MEDIA_PAD_FL_SOURCE directly.
> >  - Replace v4l2_of_parse_endpoint call with v4l2_fwnode_endpoint_parse,
> >include media/v4l2-fwnode.h instead of media/v4l2-of.h.
> >  - Constify ops structures.
> > 
> > This was previously sent as part of Steve's i.MX media series [2].
> > Tested against
> > https://git.linuxtv.org/sailus/media_tree.git/log/?h=v4l2-acpi-merge
> > 
> > [1] https://patchwork.kernel.org/patch/9708237/
> > [2] https://patchwork.kernel.org/patch/9647869/
> > ---
> >  drivers/media/platform/Kconfig |   6 +
> >  drivers/media/platform/Makefile|   2 +
> >  drivers/media/platform/video-mux.c | 318 
> > +
> >  3 files changed, 326 insertions(+)
> >  create mode 100644 drivers/media/platform/video-mux.c
> > 
> > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> > index 317f8d41e4ad6..2fea699962624 100644
> > --- a/drivers/media/platform/Kconfig
> > +++ b/drivers/media/platform/Kconfig
> > @@ -74,6 +74,12 @@ config VIDEO_M32R_AR_M64278
> >   To compile this driver as a module, choose M here: the
> >   module will be called arv.
> >  
> > +config VIDEO_MUX
> > +   tristate "Video Multiplexer"
> > +   depends on OF && VIDEO_V4L2_SUBDEV_API && MEDIA_CONTROLLER && 
> > MULTIPLEXER
> > +   help
> > + This driver provides support for N:1 video bus multiplexers.
> > +
> >  config VIDEO_OMAP3
> > tristate "OMAP 3 Camera support"
> > depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3
> > diff --git a/drivers/media/platform/Makefile 
> > b/drivers/media/platform/Makefile
> > index 63303d63c64cf..a6363023f981e 100644
> > --- a/drivers/media/platform/Makefile
> > +++ b/drivers/media/platform/Makefile
> > @@ -28,6 +28,8 @@ obj-$(CONFIG_VIDEO_SH_VEU)+= sh_veu.o
> >  
> >  obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)+= m2m-deinterlace.o
> >  
> > +obj-$(CONFIG_VIDEO_MUX)+= video-mux.o
> > +
> >  obj-$(CONFIG_VIDEO_S3C_CAMIF)  += s3c-camif/
> >  obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS) += exynos4-is/
> >  obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG)   += s5p-jpeg/
> > diff --git a/drivers/media/platform/video-mux.c 
> > b/drivers/media/platform/video-mux.c
> > new file mode 100644
> > index 0..afa06febf6c33
> > --- /dev/null
> > +++ b/drivers/media/platform/video-mux.c
> > @@ -0,0 +1,318 @@
> > +/*
> > + * video stream multiplexer controlled via mux control
> > + *
> > + * Copyright (C) 2013 Pengutronix, Sascha Hauer 
> > + * Copyright (C) 2016-2017 Pengutronix, Philipp Zabel 
> > 
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > + * as published by the Free Software Foundation; either version 2
> > + * of the License, or (at your option) any later version.
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +struct video_mux {
> > +   struct v4l2_subdev subdev;
> > +   struct media_pad *pads;
> > +   struct v4l2_mbus_framefmt *format_mbus;
> > +   struct v4l2_fwnode_endpoint *endpoint;
> > +   struct mux_control *mux;
> > +   struct mutex lock;
> > +   int active;
> > +};
> > +
> > +static inline struct video_mux *v4l2_subdev_to_video_mux(struct 
> > v4l2_subdev *sd)
> > +{
> > +   return container_of(sd, struct video_mux, subdev);
> > +}
> > +
> > +static int video_mux_link_setup(struct media_entity *entity,
> > +   const struct media_pad *local,
> > +   const struct media_pad *remote, u32 flags)
> > +{
> > +   struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
> > +   struct video_mux *vmux = 

Re: [PATCH v4 19/27] rcar-vin: use different v4l2 operations in media controller mode

[Sakari Ailus]

Hi Niklas,

On Fri, Apr 28, 2017 at 12:41:55AM +0200, Niklas Söderlund wrote:
> When the driver runs in media controller mode it should not directly
> control the subdevice instead userspace will be responsible for
> configuring the pipeline. To be able to run in this mode a different set
> of v4l2 operations needs to be used.
> 
> Add a new set of v4l2 operations to support the running without directly
> interacting with the source subdevice.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-core.c |  25 ++-
>  drivers/media/platform/rcar-vin/rcar-dma.c  |   3 +-
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 239 
> 
>  drivers/media/platform/rcar-vin/rcar-vin.h  |   3 +
>  4 files changed, 268 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index 8b30d8d3ec7d9c04..7aaa01dee014d64b 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -256,6 +256,21 @@ static int rvin_digital_graph_init(struct rvin_dev *vin)
>  }
>  
>  /* 
> -
> + * Group async notifier
> + */
> +
> +static int rvin_group_init(struct rvin_dev *vin)
> +{
> + int ret;
> +
> + ret = rvin_v4l2_mc_probe(vin);
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +
> +/* 
> -
>   * Platform Device Driver
>   */
>  
> @@ -347,7 +362,10 @@ static int rcar_vin_probe(struct platform_device *pdev)
>   if (ret)
>   return ret;
>  
> - ret = rvin_digital_graph_init(vin);
> + if (vin->info->use_mc)
> + ret = rvin_group_init(vin);
> + else
> + ret = rvin_digital_graph_init(vin);
>   if (ret < 0)
>   goto error;
>  
> @@ -371,6 +389,11 @@ static int rcar_vin_remove(struct platform_device *pdev)
>  
>   v4l2_async_notifier_unregister(>notifier);
>  
> + if (vin->info->use_mc)
> + rvin_v4l2_mc_remove(vin);
> + else
> + rvin_v4l2_remove(vin);
> +
>   rvin_dma_remove(vin);
>  
>   return 0;
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index fef31aac0ed40979..34f01f32bab7bd32 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -628,7 +628,8 @@ static int rvin_setup(struct rvin_dev *vin)
>   /* Default to TB */
>   vnmc = VNMC_IM_FULL;
>   /* Use BT if video standard can be read and is 60 Hz format */
> - if (!v4l2_subdev_call(vin_to_source(vin), video, g_std, )) {
> + if (!vin->info->use_mc &&
> + !v4l2_subdev_call(vin_to_source(vin), video, g_std, )) {
>   if (std & V4L2_STD_525_60)
>   vnmc = VNMC_IM_FULL | VNMC_FOC;
>   }
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index 1ee9dcb621350f77..ae6910ac87ec7f6a 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -23,6 +23,9 @@
>  #include "rcar-vin.h"
>  
>  #define RVIN_DEFAULT_FORMAT  V4L2_PIX_FMT_YUYV
> +#define RVIN_DEFAULT_WIDTH   800
> +#define RVIN_DEFAULT_HEIGHT  600
> +#define RVIN_DEFAULT_COLORSPACE  V4L2_COLORSPACE_SRGB
>  
>  /* 
> -
>   * Format Conversions
> @@ -694,6 +697,126 @@ static const struct v4l2_ioctl_ops rvin_ioctl_ops = {
>  };
>  
>  /* 
> -
> + * V4L2 Media Controller
> + */
> +
> +static int __rvin_mc_try_format(struct rvin_dev *vin,
> + struct v4l2_pix_format *pix)
> +{
> + const struct rvin_video_format *info;
> + u32 walign;
> +
> + /* Keep current field if no specific one is asked for */
> + if (pix->field == V4L2_FIELD_ANY)
> + pix->field = vin->format.field;
> +
> + switch (pix->field) {
> + case V4L2_FIELD_TOP:
> + case V4L2_FIELD_BOTTOM:
> + case V4L2_FIELD_ALTERNATE:
> + case V4L2_FIELD_NONE:
> + case V4L2_FIELD_INTERLACED_TB:
> + case V4L2_FIELD_INTERLACED_BT:
> + case V4L2_FIELD_INTERLACED:
> + break;
> + default:
> + pix->field = V4L2_FIELD_NONE;
> + break;
> + }
> +
> + /* Check that colorspace is resonable, if not keep current */
> + if (!pix->colorspace || pix->colorspace >= 0xff)
> + pix->colorspace = vin->format.colorspace;
> +
> + info = rvin_format_from_pixel(pix->pixelformat);
> + if (!info) {
> + vin_dbg(vin, 

Re: [PATCH v4 20/27] rcar-vin: register a media pad if running in media controller mode

[Sakari Ailus]

On Fri, Apr 28, 2017 at 12:41:56AM +0200, Niklas Söderlund wrote:
> When running in media controller mode a media pad is needed, register
> one.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 9 +
>  drivers/media/platform/rcar-vin/rcar-vin.h  | 4 
>  2 files changed, 13 insertions(+)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index 7aaa01dee014d64b..f560d27449b84882 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -267,7 +267,16 @@ static int rvin_group_init(struct rvin_dev *vin)
>   if (ret)
>   return ret;
>  
> + vin->pad.flags = MEDIA_PAD_FL_SINK;
> + ret = media_entity_pads_init(>vdev->entity, 1, >pad);
> + if (ret)
> + goto error_v4l2;
> +
>   return 0;

This would benefit from an extra newline.

> +error_v4l2:
> + rvin_v4l2_mc_remove(vin);
> +
> + return ret;
>  }
>  
>  /* 
> -
> diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
> b/drivers/media/platform/rcar-vin/rcar-vin.h
> index 6f2b1e28381678a9..06934313950253f4 100644
> --- a/drivers/media/platform/rcar-vin/rcar-vin.h
> +++ b/drivers/media/platform/rcar-vin/rcar-vin.h
> @@ -103,6 +103,8 @@ struct rvin_info {
>   * @notifier:V4L2 asynchronous subdevs notifier
>   * @digital: entity in the DT for local digital subdevice
>   *
> + * @pad: pad for media controller
> + *
>   * @lock:protects @queue
>   * @queue:   vb2 buffers queue
>   *
> @@ -132,6 +134,8 @@ struct rvin_dev {
>   struct v4l2_async_notifier notifier;
>   struct rvin_graph_entity digital;
>  
> + struct media_pad pad;
> +
>   struct mutex lock;
>   struct vb2_queue queue;
>  

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

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

[Kieran Bingham]

Hi Philipp,

Thankyou for the patch,

On 04/05/17 14:38, Philipp Zabel wrote:
> This driver can handle SoC internal and external video bus multiplexers,
> controlled by mux controllers provided by the mux controller framework,
> such as MMIO register bitfields or GPIOs. The subdevice passes through
> the mbus configuration of the active input to the output side.
> 
> Signed-off-by: Sascha Hauer 
> Signed-off-by: Philipp Zabel 
> Signed-off-by: Steve Longerbeam 
> ---
> Changes since v2 [1]:
>  - Extend vmux->lock to protect mbus format against simultaneous access
>from get/set_format calls.
>  - Drop is_source_pad(), check pad->flags & MEDIA_PAD_FL_SOURCE directly.
>  - Replace v4l2_of_parse_endpoint call with v4l2_fwnode_endpoint_parse,
>include media/v4l2-fwnode.h instead of media/v4l2-of.h.
>  - Constify ops structures.
> 
> This was previously sent as part of Steve's i.MX media series [2].
> Tested against
> https://git.linuxtv.org/sailus/media_tree.git/log/?h=v4l2-acpi-merge
> 
> [1] https://patchwork.kernel.org/patch/9708237/
> [2] https://patchwork.kernel.org/patch/9647869/
> ---
>  drivers/media/platform/Kconfig |   6 +
>  drivers/media/platform/Makefile|   2 +
>  drivers/media/platform/video-mux.c | 318 
> +
>  3 files changed, 326 insertions(+)
>  create mode 100644 drivers/media/platform/video-mux.c
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 317f8d41e4ad6..2fea699962624 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -74,6 +74,12 @@ config VIDEO_M32R_AR_M64278
> To compile this driver as a module, choose M here: the
> module will be called arv.
>  
> +config VIDEO_MUX
> + tristate "Video Multiplexer"
> + depends on OF && VIDEO_V4L2_SUBDEV_API && MEDIA_CONTROLLER && 
> MULTIPLEXER
> + help
> +   This driver provides support for N:1 video bus multiplexers.
> +
>  config VIDEO_OMAP3
>   tristate "OMAP 3 Camera support"
>   depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 63303d63c64cf..a6363023f981e 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -28,6 +28,8 @@ obj-$(CONFIG_VIDEO_SH_VEU)  += sh_veu.o
>  
>  obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)  += m2m-deinterlace.o
>  
> +obj-$(CONFIG_VIDEO_MUX)  += video-mux.o
> +
>  obj-$(CONFIG_VIDEO_S3C_CAMIF)+= s3c-camif/
>  obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS)   += exynos4-is/
>  obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG) += s5p-jpeg/
> diff --git a/drivers/media/platform/video-mux.c 
> b/drivers/media/platform/video-mux.c
> new file mode 100644
> index 0..afa06febf6c33
> --- /dev/null
> +++ b/drivers/media/platform/video-mux.c
> @@ -0,0 +1,318 @@
> +/*
> + * video stream multiplexer controlled via mux control
> + *
> + * Copyright (C) 2013 Pengutronix, Sascha Hauer 
> + * Copyright (C) 2016-2017 Pengutronix, Philipp Zabel 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct video_mux {
> + struct v4l2_subdev subdev;
> + struct media_pad *pads;
> + struct v4l2_mbus_framefmt *format_mbus;
> + struct v4l2_fwnode_endpoint *endpoint;
> + struct mux_control *mux;
> + struct mutex lock;
> + int active;
> +};
> +
> +static inline struct video_mux *v4l2_subdev_to_video_mux(struct v4l2_subdev 
> *sd)
> +{
> + return container_of(sd, struct video_mux, subdev);
> +}
> +
> +static int video_mux_link_setup(struct media_entity *entity,
> + const struct media_pad *local,
> + const struct media_pad *remote, u32 flags)
> +{
> + struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
> + struct video_mux *vmux = v4l2_subdev_to_video_mux(sd);
> + int ret = 0;
> +
> + /*
> +  * The mux state is determined by the enabled sink pad link.
> +  * Enabling or disabling the source pad link has no effect.
> +  */
> + if (local->flags & MEDIA_PAD_FL_SOURCE)
> + return 0;
> +
> + dev_dbg(sd->dev, "link setup 

Re: [PATCH v4 16/27] rcar-vin: add functions to manipulate Gen3 CHSEL value

[Sakari Ailus]

Hi Niklas,

On Fri, Apr 28, 2017 at 12:41:52AM +0200, Niklas Söderlund wrote:
> On Gen3 the CSI-2 routing is controlled by the VnCSI_IFMD register. One
> feature of this register is that it's only present in the VIN0 and VIN4
> instances. The register in VIN0 controls the routing for VIN0-3 and the
> register in VIN4 controls routing for VIN4-7.
> 
> To be able to control routing from a media device these functions need
> to control runtime PM for the subgroup master (VIN0 and VIN4). The
> subgroup master must be switched on before the register is manipulated,
> once the operation is complete it's safe to switch the master off and
> the new routing will still be in effect.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-dma.c | 43 
> ++
>  drivers/media/platform/rcar-vin/rcar-vin.h |  3 +++
>  2 files changed, 46 insertions(+)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index 7fecb616b6c45a32..fef31aac0ed40979 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -16,6 +16,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -1240,3 +1241,45 @@ int rvin_dma_probe(struct rvin_dev *vin, int irq)
>  
>   return ret;
>  }
> +
> +/* 
> -
> + * Gen3 CHSEL manipulation
> + */
> +
> +int rvin_set_chsel(struct rvin_dev *vin, u8 chsel)
> +{
> + u32 ifmd;
> +
> + pm_runtime_get_sync(vin->dev);

Can this fail? Just wondering.

> +
> + /*
> +  * Undocumented feature: Writing to VNCSI_IFMD_REG will go
> +  * through and on read back look correct but won't have
> +  * any effect if VNMC_REG is not first set to 0.
> +  */
> + rvin_write(vin, 0, VNMC_REG);
> +
> + ifmd = VNCSI_IFMD_DES2 | VNCSI_IFMD_DES1 | VNCSI_IFMD_DES0 |
> + VNCSI_IFMD_CSI_CHSEL(chsel);
> +
> + rvin_write(vin, ifmd, VNCSI_IFMD_REG);
> +
> + vin_dbg(vin, "Set IFMD 0x%x\n", ifmd);
> +
> + pm_runtime_put(vin->dev);
> +
> + return 0;

If you always return zero, how about void instead?

> +}
> +
> +int rvin_get_chsel(struct rvin_dev *vin)
> +{
> + int chsel;
> +
> + pm_runtime_get_sync(vin->dev);

Same here.

> +
> + chsel = rvin_read(vin, VNCSI_IFMD_REG) & VNCSI_IFMD_CSI_CHSEL_MASK;
> +
> + pm_runtime_put(vin->dev);
> +
> + return chsel;
> +}
> diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
> b/drivers/media/platform/rcar-vin/rcar-vin.h
> index 09fc70e192699f35..b1cd0abba9ca9c94 100644
> --- a/drivers/media/platform/rcar-vin/rcar-vin.h
> +++ b/drivers/media/platform/rcar-vin/rcar-vin.h
> @@ -163,4 +163,7 @@ void rvin_v4l2_remove(struct rvin_dev *vin);
>  
>  const struct rvin_video_format *rvin_format_from_pixel(u32 pixelformat);
>  
> +int rvin_set_chsel(struct rvin_dev *vin, u8 chsel);
> +int rvin_get_chsel(struct rvin_dev *vin);
> +
>  #endif

-- 
Kind regards,

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

Re: [PATCH v4 12/27] rcar-vin: read subdevice format for crop only when needed

[Sakari Ailus]

Hi Niklas,

On Fri, Apr 28, 2017 at 12:41:48AM +0200, Niklas Söderlund wrote:
> Instead of caching the subdevice format each time the video device
> format is set read it directly when its needed. As it turns out the
> format is only needed when figuring out the max rectangle for cropping.
> 
> This simplify the code and makes it clearer what the source format is
> used for.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 76 
> -
>  drivers/media/platform/rcar-vin/rcar-vin.h  | 12 -
>  2 files changed, 42 insertions(+), 46 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index 919040e40aec60f6..80421421625e6f6f 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -90,6 +90,24 @@ static u32 rvin_format_sizeimage(struct v4l2_pix_format 
> *pix)
>   * V4L2
>   */
>  
> +static int rvin_get_sd_format(struct rvin_dev *vin, struct v4l2_pix_format 
> *pix)
> +{
> + struct v4l2_subdev_format fmt = {
> + .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> + };
> + int ret;
> +
> + fmt.pad = vin->digital.source_pad;

You can assign .pad in declaration, too.

> +
> + ret = v4l2_subdev_call(vin_to_source(vin), pad, get_fmt, NULL, );
> + if (ret)
> + return ret;
> +
> + v4l2_fill_pix_format(pix, );
> +
> + return 0;
> +}

-- 
Regards,

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

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

[Sebastian Reichel]

Hi,

On Tue, May 02, 2017 at 01:25:49PM +0300, Sakari Ailus wrote:
> Many camera sensor devices contain EEPROM chips that describe the
> properties of a given unit --- the data is specific to a given unit can
> thus is not stored e.g. in user space or the driver.
> 
> Some sensors embed the EEPROM chip and it can be accessed through the
> sensor's I²C interface. This property is to be used for devices where the
> EEPROM chip is accessed through a different I²C address than the sensor.
> 
> The intent is to later provide this information to the user space.
> 
> Signed-off-by: Sakari Ailus 
> ---
>  Documentation/devicetree/bindings/media/video-interfaces.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt 
> b/Documentation/devicetree/bindings/media/video-interfaces.txt
> index e52aefc..9bd2005 100644
> --- a/Documentation/devicetree/bindings/media/video-interfaces.txt
> +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
> @@ -80,6 +80,9 @@ Optional properties
>  - lens-focus: A phandle to the node of the lens. Only valid for device
>nodes that are related to an image sensor.
>  
> +- eeprom: A phandle to the node of the related EEPROM. Only valid for
> +  device nodes that are related to an image sensor.

Here it's even more obvious, that the second sentence is redundant.
The requirement is already in the first sentence :) Instead it
should be mentioned, that this is to be used by devices not having
their own embedded eeprom. How about:

eeprom: A phandle to the node of the EEPROM describing the camera
sensor (i.e. device specific calibration data), in case it differs
from the sensor node.

-- Sebastian


signature.asc
Description: PGP signature

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

[Sebastian Reichel]

Hi,

On Tue, May 02, 2017 at 01:25:48PM +0300, Sakari Ailus wrote:
> The lens-focus property contains a phandle to the lens voice coil driver
> that is associated to the sensor; typically both are contained in the same
> camera module.
> 
> Signed-off-by: Sakari Ailus 
> ---
>  Documentation/devicetree/bindings/media/video-interfaces.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt 
> b/Documentation/devicetree/bindings/media/video-interfaces.txt
> index d6c62bc..e52aefc 100644
> --- a/Documentation/devicetree/bindings/media/video-interfaces.txt
> +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
> @@ -77,6 +77,9 @@ Optional properties
>the child nodes of the LED driver describing individual LEDs. Only
>valid for device nodes that are related to an image sensor.
>  
> +- lens-focus: A phandle to the node of the lens. Only valid for device
> +  nodes that are related to an image sensor.

s/of the lens/of the focus lens controller/

Also I wonder about the second sentence. That sentence could
basically be added to every property, so can't we just drop it?

-- Sebastian


signature.asc
Description: PGP signature

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

[Sebastian Reichel]

Hi Sakari,

On Tue, May 02, 2017 at 01:25:47PM +0300, Sakari Ailus wrote:
> Camera flash drivers (and LEDs) are separate from the sensor devices in
> DT. In order to make an association between the two, provide the
> association information to the software.
> 
> Signed-off-by: Sakari Ailus 
> ---
>  Documentation/devicetree/bindings/media/video-interfaces.txt | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt 
> b/Documentation/devicetree/bindings/media/video-interfaces.txt
> index 9cd2a36..d6c62bc 100644
> --- a/Documentation/devicetree/bindings/media/video-interfaces.txt
> +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
> @@ -67,6 +67,17 @@ are required in a relevant parent node:
>   identifier, should be 1.
>   - #size-cells: should be zero.
>  
> +
> +Optional properties
> +---
> +
> +- flash: An array of phandles that refer to the flash light sources
> +  related to an image sensor. These could be e.g. LEDs. In case the LED
> +  driver drives more than a single LED, then the phandles here refer to
> +  the child nodes of the LED driver describing individual LEDs. Only
> +  valid for device nodes that are related to an image sensor.

s/driver/controller/g - DT describes HW. Otherwise

Reviewed-by: Sebastian Reichel 

-- Sebastian


signature.asc
Description: PGP signature

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

[Sebastian Reichel]

Hi,

On Thu, May 04, 2017 at 03:38:57PM +0200, Philipp Zabel wrote:
> This driver can handle SoC internal and external video bus multiplexers,
> controlled by mux controllers provided by the mux controller framework,
> such as MMIO register bitfields or GPIOs. The subdevice passes through
> the mbus configuration of the active input to the output side.
> 
> Signed-off-by: Sascha Hauer 
> Signed-off-by: Philipp Zabel 
> Signed-off-by: Steve Longerbeam 
> ---
> Changes since v2 [1]:
>  - Extend vmux->lock to protect mbus format against simultaneous access
>from get/set_format calls.
>  - Drop is_source_pad(), check pad->flags & MEDIA_PAD_FL_SOURCE directly.
>  - Replace v4l2_of_parse_endpoint call with v4l2_fwnode_endpoint_parse,
>include media/v4l2-fwnode.h instead of media/v4l2-of.h.
>  - Constify ops structures.
> 
> This was previously sent as part of Steve's i.MX media series [2].
> Tested against
> https://git.linuxtv.org/sailus/media_tree.git/log/?h=v4l2-acpi-merge
> 
> [1] https://patchwork.kernel.org/patch/9708237/
> [2] https://patchwork.kernel.org/patch/9647869/

Looks fine to me. Just one nitpick:

> +static int video_mux_probe(struct platform_device *pdev)
> +{

[...]

> + vmux->pads = devm_kzalloc(dev, sizeof(*vmux->pads) * num_pads,
> +   GFP_KERNEL);
> + vmux->format_mbus = devm_kzalloc(dev, sizeof(*vmux->format_mbus) *
> +  num_pads, GFP_KERNEL);
> + vmux->endpoint = devm_kzalloc(dev, sizeof(*vmux->endpoint) *
> +   (num_pads - 1), GFP_KERNEL);

devm_kcalloc(dev, num_pads, sizeof(*foo), GFP_KERNEL).

-- Sebastian


signature.asc
Description: PGP signature

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

[Sebastian Reichel]

Hi,

On Thu, May 04, 2017 at 03:38:56PM +0200, Philipp Zabel wrote:
> Add bindings documentation for the video multiplexer device.
> 
> Signed-off-by: Sascha Hauer 
> Signed-off-by: Philipp Zabel 
> Signed-off-by: Steve Longerbeam 
> Acked-by: Peter Rosin 
> Acked-by: Sakari Ailus 

Reviewed-by: Sebastian Reichel 

-- Sebastian

> ---
> No changes since v2 [1].
> 
> This was previously sent as part of Steve's i.MX media series [2].
> 
> [1] https://patchwork.kernel.org/patch/9708235/
> [2] https://patchwork.kernel.org/patch/9647951/
> ---
>  .../devicetree/bindings/media/video-mux.txt| 60 
> ++
>  1 file changed, 60 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/video-mux.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/video-mux.txt 
> b/Documentation/devicetree/bindings/media/video-mux.txt
> new file mode 100644
> index 0..63b9dc913e456
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/video-mux.txt
> @@ -0,0 +1,60 @@
> +Video Multiplexer
> +=
> +
> +Video multiplexers allow to select between multiple input ports. Video 
> received
> +on the active input port is passed through to the output port. Muxes 
> described
> +by this binding are controlled by a multiplexer controller that is described 
> by
> +the bindings in Documentation/devicetree/bindings/mux/mux-controller.txt
> +
> +Required properties:
> +- compatible : should be "video-mux"
> +- mux-controls : mux controller node to use for operating the mux
> +- #address-cells: should be <1>
> +- #size-cells: should be <0>
> +- port@*: at least three port nodes containing endpoints connecting to the
> +  source and sink devices according to of_graph bindings. The last port is
> +  the output port, all others are inputs.
> +
> +Optionally, #address-cells, #size-cells, and port nodes can be grouped under 
> a
> +ports node as described in Documentation/devicetree/bindings/graph.txt.
> +
> +Example:
> +
> + mux: mux-controller {
> + compatible = "gpio-mux";
> + #mux-control-cells = <0>;
> +
> + mux-gpios = < 15 GPIO_ACTIVE_HIGH>;
> + };
> +
> + video-mux {
> + compatible = "video-mux";
> + mux-controls = <>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + mux_in0: endpoint {
> + remote-endpoint = <_source0_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + mux_in1: endpoint {
> + remote-endpoint = <_source1_out>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> +
> + mux_out: endpoint {
> + remote-endpoint = <_interface_in>;
> + };
> + };
> + };
> +};
> -- 
> 2.11.0
> 


signature.asc
Description: PGP signature

Re: [PATCH v3.1 4/7] v4l: Switch from V4L2 OF not V4L2 fwnode API

[Elizar Alcantara]

UNSUBSCRIBE linux-media@vger.kernel.org


On Thu, May 4, 2017 at 9:57 PM, Elizar Alcantara  wrote:
> UNSUBSCRIBE
> linux-media@vger.kernel.org
>
>
>
>
>
> On Thu, May 4, 2017 at 9:43 PM, Philipp Zabel 
> wrote:
>>
>> On Tue, 2017-04-25 at 14:56 +0300, Sakari Ailus wrote:
>> > Switch users of the v4l2_of_ APIs to the more generic v4l2_fwnode_ APIs.
>> > Async OF matching is replaced by fwnode matching and OF matching support
>> > is removed.
>> >
>> > Signed-off-by: Sakari Ailus 
>> > Acked-by: Benoit Parrot  # i2c/ov2569.c,
>> > am437x/am437x-vpfe.c and ti-vpe/cal.c
>> > Tested-by: Hans Verkuil  # Atmel sama5d3 board +
>> > ov2640 sensor
>>
>> Tested and works on v4.11 with Steve's imx-media-staging-md branch on
>> Nitrogen6X i.MX6Q + Toshiba TC358743 HDMI to MIPI CSI-2 bridge.
>>
>> Tested-by: Philipp Zabel 
>>
>> regards
>> Philipp
>>
>

Re: [PATCH v3.1 4/7] v4l: Switch from V4L2 OF not V4L2 fwnode API

[Philipp Zabel]

On Tue, 2017-04-25 at 14:56 +0300, Sakari Ailus wrote:
> Switch users of the v4l2_of_ APIs to the more generic v4l2_fwnode_ APIs.
> Async OF matching is replaced by fwnode matching and OF matching support
> is removed.
> 
> Signed-off-by: Sakari Ailus 
> Acked-by: Benoit Parrot  # i2c/ov2569.c, am437x/am437x-vpfe.c 
> and ti-vpe/cal.c
> Tested-by: Hans Verkuil  # Atmel sama5d3 board + 
> ov2640 sensor

Tested and works on v4.11 with Steve's imx-media-staging-md branch on
Nitrogen6X i.MX6Q + Toshiba TC358743 HDMI to MIPI CSI-2 bridge.

Tested-by: Philipp Zabel 

regards
Philipp

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

[Philipp Zabel]

Add bindings documentation for the video multiplexer device.

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

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

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

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

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

[Philipp Zabel]

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

Signed-off-by: Sascha Hauer 
Signed-off-by: Philipp Zabel 
Signed-off-by: Steve Longerbeam 
---
Changes since v2 [1]:
 - Extend vmux->lock to protect mbus format against simultaneous access
   from get/set_format calls.
 - Drop is_source_pad(), check pad->flags & MEDIA_PAD_FL_SOURCE directly.
 - Replace v4l2_of_parse_endpoint call with v4l2_fwnode_endpoint_parse,
   include media/v4l2-fwnode.h instead of media/v4l2-of.h.
 - Constify ops structures.

This was previously sent as part of Steve's i.MX media series [2].
Tested against
https://git.linuxtv.org/sailus/media_tree.git/log/?h=v4l2-acpi-merge

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

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

[PATCH] [media] imx: switch from V4L2 OF to V4L2 fwnode API

[Philipp Zabel]

Switch from the v4l2_of_ APIs to the v4l2_fwnode_ APIs so this driver
can work if the patch "v4l: Switch from V4L2 OF not V4L2 fwnode API"
is applied before it. Tested against
https://git.linuxtv.org/sailus/media_tree.git/log/?h=v4l2-acpi-merge

Signed-off-by: Philipp Zabel 
---
 drivers/staging/media/imx/imx-media-capture.c |  2 +-
 drivers/staging/media/imx/imx-media-csi.c | 10 +-
 drivers/staging/media/imx/imx-media-dev.c | 19 ++-
 drivers/staging/media/imx/imx-media-fim.c |  1 -
 drivers/staging/media/imx/imx-media-of.c  |  6 --
 drivers/staging/media/imx/imx-media.h |  4 ++--
 drivers/staging/media/imx/imx6-mipi-csi2.c|  9 +
 7 files changed, 27 insertions(+), 24 deletions(-)

diff --git a/drivers/staging/media/imx/imx-media-capture.c 
b/drivers/staging/media/imx/imx-media-capture.c
index 8b28dbc21566c..ddab4c249da25 100644
--- a/drivers/staging/media/imx/imx-media-capture.c
+++ b/drivers/staging/media/imx/imx-media-capture.c
@@ -21,8 +21,8 @@
 #include 
 #include 
 #include 
+#include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index 447c597111852..fdf90dc7d212e 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -17,8 +17,8 @@
 #include 
 #include 
 #include 
+#include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -307,7 +307,7 @@ static void csi_idmac_unsetup_vb2_buf(struct csi_priv *priv,
 static int csi_idmac_setup_channel(struct csi_priv *priv)
 {
struct imx_media_video_dev *vdev = priv->vdev;
-   struct v4l2_of_endpoint *sensor_ep;
+   struct v4l2_fwnode_endpoint *sensor_ep;
struct v4l2_mbus_framefmt *infmt;
struct ipu_image image;
u32 passthrough_bits;
@@ -557,7 +557,7 @@ static int csi_setup(struct csi_priv *priv)
 {
struct v4l2_mbus_framefmt *infmt, *outfmt;
struct v4l2_mbus_config sensor_mbus_cfg;
-   struct v4l2_of_endpoint *sensor_ep;
+   struct v4l2_fwnode_endpoint *sensor_ep;
struct v4l2_mbus_framefmt if_fmt;
const struct csi_skip_desc *skip;
 
@@ -957,7 +957,7 @@ static int csi_link_validate(struct v4l2_subdev *sd,
 {
struct csi_priv *priv = v4l2_get_subdevdata(sd);
const struct imx_media_pixfmt *incc;
-   struct v4l2_of_endpoint *sensor_ep;
+   struct v4l2_fwnode_endpoint *sensor_ep;
struct imx_media_subdev *sensor;
bool is_csi2;
int ret;
@@ -1066,7 +1066,7 @@ static void csi_try_crop(struct csi_priv *priv,
 struct v4l2_mbus_framefmt *infmt,
 struct imx_media_subdev *sensor)
 {
-   struct v4l2_of_endpoint *sensor_ep;
+   struct v4l2_fwnode_endpoint *sensor_ep;
 
sensor_ep = >sensor_ep;
 
diff --git a/drivers/staging/media/imx/imx-media-dev.c 
b/drivers/staging/media/imx/imx-media-dev.c
index d149d2f222f10..488c4d24783d9 100644
--- a/drivers/staging/media/imx/imx-media-dev.c
+++ b/drivers/staging/media/imx/imx-media-dev.c
@@ -40,14 +40,15 @@ imx_media_find_async_subdev(struct imx_media_dev *imxmd,
struct device_node *np,
const char *devname)
 {
+   struct fwnode_handle *fwnode = np ? of_fwnode_handle(np) : NULL;
struct imx_media_subdev *imxsd;
int i;
 
for (i = 0; i < imxmd->subdev_notifier.num_subdevs; i++) {
imxsd = >subdev[i];
switch (imxsd->asd.match_type) {
-   case V4L2_ASYNC_MATCH_OF:
-   if (np && imxsd->asd.match.of.node == np)
+   case V4L2_ASYNC_MATCH_FWNODE:
+   if (fwnode && imxsd->asd.match.fwnode.fwnode == fwnode)
return imxsd;
break;
case V4L2_ASYNC_MATCH_DEVNAME:
@@ -65,8 +66,8 @@ imx_media_find_async_subdev(struct imx_media_dev *imxmd,
 
 /*
  * Adds a subdev to the async subdev list. If np is non-NULL, adds
- * the async as a V4L2_ASYNC_MATCH_OF match type, otherwise as a
- * V4L2_ASYNC_MATCH_DEVNAME match type using the dev_name of the
+ * the async as a V4L2_ASYNC_MATCH_FWNODE match type, otherwise as
+ * a V4L2_ASYNC_MATCH_DEVNAME match type using the dev_name of the
  * given platform_device. This is called during driver load when
  * forming the async subdev list.
  */
@@ -101,8 +102,8 @@ imx_media_add_async_subdev(struct imx_media_dev *imxmd,
 
asd = >asd;
if (np) {
-   asd->match_type = V4L2_ASYNC_MATCH_OF;
-   asd->match.of.node = np;
+   asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
+   asd->match.fwnode.fwnode = of_fwnode_handle(np);
} else {
asd->match_type = V4L2_ASYNC_MATCH_DEVNAME;
strncpy(imxsd->devname, devname, sizeof(imxsd->devname));
@@ -114,7 +115,7 

Re: [PATCH v6 2/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

[Sakari Ailus]

Hi Niklas,

On Fri, Apr 28, 2017 at 12:36:58AM +0200, Niklas Söderlund wrote:
> A V4L2 driver for Renesas R-Car MIPI CSI-2 receiver. The driver
> supports the rcar-vin driver on R-Car Gen3 SoCs where separate CSI-2
> hardware blocks are connected between the video sources and the video
> grabbers (VIN).
> 
> Driver is based on a prototype by Koji Matsuoka in the Renesas BSP.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/Kconfig |  11 +
>  drivers/media/platform/rcar-vin/Makefile|   1 +
>  drivers/media/platform/rcar-vin/rcar-csi2.c | 872 
> 
>  3 files changed, 884 insertions(+)
>  create mode 100644 drivers/media/platform/rcar-vin/rcar-csi2.c
> 
> diff --git a/drivers/media/platform/rcar-vin/Kconfig 
> b/drivers/media/platform/rcar-vin/Kconfig
> index 111d2a151f6a4d44..f1df85d526e96a74 100644
> --- a/drivers/media/platform/rcar-vin/Kconfig
> +++ b/drivers/media/platform/rcar-vin/Kconfig
> @@ -1,3 +1,14 @@
> +config VIDEO_RCAR_CSI2
> + tristate "R-Car MIPI CSI-2 Receiver"
> + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF
> + depends on ARCH_RENESAS || COMPILE_TEST
> + ---help---
> +   Support for Renesas R-Car MIPI CSI-2 receiver.
> +   Supports R-Car Gen3 SoCs.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called rcar-csi2.
> +
>  config VIDEO_RCAR_VIN
>   tristate "R-Car Video Input (VIN) Driver"
>   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF && HAS_DMA && 
> MEDIA_CONTROLLER
> diff --git a/drivers/media/platform/rcar-vin/Makefile 
> b/drivers/media/platform/rcar-vin/Makefile
> index 48c5632c21dc060b..5ab803d3e7c1aa57 100644
> --- a/drivers/media/platform/rcar-vin/Makefile
> +++ b/drivers/media/platform/rcar-vin/Makefile
> @@ -1,3 +1,4 @@
>  rcar-vin-objs = rcar-core.o rcar-dma.o rcar-v4l2.o
>  
> +obj-$(CONFIG_VIDEO_RCAR_CSI2) += rcar-csi2.o
>  obj-$(CONFIG_VIDEO_RCAR_VIN) += rcar-vin.o
> diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c 
> b/drivers/media/platform/rcar-vin/rcar-csi2.c
> new file mode 100644
> index ..53601e171aa179b7
> --- /dev/null
> +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
> @@ -0,0 +1,872 @@
> +/*
> + * Driver for Renesas R-Car MIPI CSI-2 Receiver
> + *
> + * Copyright (C) 2017 Renesas Electronics Corp.
> + *
> + * This program is free software; you can redistribute  it and/or modify it
> + * under  the terms of  the GNU General  Public License as published by the
> + * Free Software Foundation;  either version 2 of the  License, or (at your
> + * option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 

Could you rebase also this on the V4L2 fwnode patchset?



> +#include 
> +
> +/* Register offsets and bits */
> +
> +/* Control Timing Select */
> +#define TREF_REG 0x00
> +#define TREF_TREF(1 << 0)
> +
> +/* Software Reset */
> +#define SRST_REG 0x04
> +#define SRST_SRST(1 << 0)
> +
> +/* PHY Operation Control */
> +#define PHYCNT_REG   0x08
> +#define PHYCNT_SHUTDOWNZ (1 << 17)
> +#define PHYCNT_RSTZ  (1 << 16)
> +#define PHYCNT_ENABLECLK (1 << 4)
> +#define PHYCNT_ENABLE_3  (1 << 3)
> +#define PHYCNT_ENABLE_2  (1 << 2)
> +#define PHYCNT_ENABLE_1  (1 << 1)
> +#define PHYCNT_ENABLE_0  (1 << 0)
> +
> +/* Checksum Control */
> +#define CHKSUM_REG   0x0c
> +#define CHKSUM_ECC_EN(1 << 1)
> +#define CHKSUM_CRC_EN(1 << 0)
> +
> +/*
> + * Channel Data Type Select
> + * VCDT[0-15]:  Channel 1 VCDT[16-31]:  Channel 2
> + * VCDT2[0-15]: Channel 3 VCDT2[16-31]: Channel 4
> + */
> +#define VCDT_REG 0x10
> +#define VCDT2_REG0x14
> +#define VCDT_VCDTN_EN(1 << 15)
> +#define VCDT_SEL_VC(n)   (((n) & 0x3) << 8)
> +#define VCDT_SEL_DTN_ON  (1 << 6)
> +#define VCDT_SEL_DT(n)   (((n) & 0x1f) << 0)
> +
> +/* Frame Data Type Select */
> +#define FRDT_REG 0x18
> +
> +/* Field Detection Control */
> +#define FLD_REG  0x1c
> +#define FLD_FLD_NUM(n)   (((n) & 0xff) << 16)
> +#define FLD_FLD_EN4  (1 << 3)
> +#define FLD_FLD_EN3  (1 << 2)
> +#define FLD_FLD_EN2  (1 << 1)
> +#define FLD_FLD_EN   (1 << 0)
> +
> +/* Automatic Standby Control */
> +#define ASTBY_REG0x20
> +
> +/* Long Data Type Setting 0 */
> +#define LNGDT0_REG 

RE: Donation Award

[Mayrhofer Family]

Good Day,

My wife and I have awarded you with a donation of $ 1,000,000.00 Dollars from 
part of our Jackpot Lottery of 50 Million Dollars, respond with your details 
for claims.

We await your earliest response and God Bless you.

Friedrich And Annand Mayrhofer.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: [PATCH 2/2] drm: rcar-du: Add support for colorkey alpha blending

[Laurent Pinchart]

Hi Alexandru,

On Thursday 04 May 2017 13:53:33 agheorghe wrote:
> Add two new plane properties colorkey and colorkey_alpha for rcar gen3.
> * colorkey:
>   - used for specifying the color on which the filtering is done.
>   - bits 0 to 23 are interpreted as RGB888 format, in case we are
> dealing with an YCbCr format, only the Y componenet is
> compared and it is represented by the G bits from RGB888
> format.
>   - bit 24 tells if it is enabled or not.
> * colorkey_alpha:
>   - the alpha to be set for matching pixels, in case it is
> missing the pixels will be made transparent

Colour keying is a feature found in most display engines, and would thus 
benefit from standardizing the properties. Instead of adding another colorkey 
property specific to rcar-du, could you make a proposal to standardize it ?

> Signed-off-by: agheorghe 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_drv.h   |  1 +
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c   |  8 
>  drivers/gpu/drm/rcar-du/rcar_du_plane.c |  3 ---
>  drivers/gpu/drm/rcar-du/rcar_du_plane.h |  6 ++
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c   | 22 ++
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.h   |  5 +
>  6 files changed, 42 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.h index 91e8fc5..1cb92e3 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> @@ -98,6 +98,7 @@ struct rcar_du_device {
>   struct {
>   struct drm_property *alpha;
>   struct drm_property *colorkey;
> + struct drm_property *colorkey_alpha;
>   } props;
> 
>   unsigned int dpad0_source;
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 1cc88ed..a733fa2 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -630,6 +630,14 @@ static int rcar_du_properties_init(struct
> rcar_du_device *rcdu) if (rcdu->props.colorkey == NULL)
>   return -ENOMEM;
> 
> + if (rcdu->info->gen == 3) {
> + rcdu->props.colorkey_alpha =
> + drm_property_create_range(rcdu->ddev, 0,
> +   "colorkey_alpha", 0, 255);
> + if (!rcdu->props.colorkey_alpha)
> + return -ENOMEM;
> + }
> +
>   return 0;
>  }
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> b/drivers/gpu/drm/rcar-du/rcar_du_plane.c index e408aa3..df689c4 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> @@ -307,9 +307,6 @@ int rcar_du_atomic_check_planes(struct drm_device *dev,
>   * Plane Setup
>   */
> 
> -#define RCAR_DU_COLORKEY_NONE(0 << 24)
> -#define RCAR_DU_COLORKEY_SOURCE  (1 << 24)
> -#define RCAR_DU_COLORKEY_MASK(1 << 24)
> 
>  static void rcar_du_plane_write(struct rcar_du_group *rgrp,
>   unsigned int index, u32 reg, u32 data)
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
> b/drivers/gpu/drm/rcar-du/rcar_du_plane.h index c1de338..9e7c3b6 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
> @@ -49,6 +49,12 @@ static inline struct rcar_du_plane *to_rcar_plane(struct
> drm_plane *plane) return container_of(plane, struct rcar_du_plane, plane);
>  }
> 
> +#define RCAR_DU_COLORKEY_NONE(0 << 24)
> +#define RCAR_DU_COLORKEY_MASKBIT(24)
> +#define RCAR_DU_COLORKEY_EN_MASK RCAR_DU_COLORKEY_MASK
> +#define RCAR_DU_COLORKEY_COLOR_MASK  0xFF
> +#define RCAR_DU_COLORKEY_ALPHA_MASK  0xFF
> +
>  /**
>   * struct rcar_du_plane_state - Driver-specific plane state
>   * @state: base DRM plane state
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index 4b460d4..b223be1 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> @@ -180,6 +180,11 @@ static void rcar_du_vsp_plane_setup(struct
> rcar_du_vsp_plane *plane) .pitch = fb->pitches[0],
>   .alpha = state->alpha,
>   .zpos = state->state.zpos,
> + .colorkey = state->colorkey & RCAR_DU_COLORKEY_COLOR_MASK,
> + .colorkey_en =
> + ((state->colorkey & RCAR_DU_COLORKEY_EN_MASK) != 0),
> + .colorkey_alpha =
> + (state->colorkey_alpha & RCAR_DU_COLORKEY_ALPHA_MASK),
>   };
>   unsigned int i;
> 
> @@ -379,6 +384,8 @@ static void rcar_du_vsp_plane_reset(struct drm_plane
> *plane) return;
> 
>   state->alpha = 255;
> + state->colorkey = RCAR_DU_COLORKEY_NONE;
> + state->colorkey_alpha = 0;
>   state->state.zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
> 
>   plane->state = 

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

[Mauro Carvalho Chehab]

Em Thu, 4 May 2017 09:55:04 +0200
Gregor Jasny  escreveu:

> Hello Mauro,
> 
> On 04.05.17 00:33, Mauro Carvalho Chehab wrote:
> > Em Wed, 3 May 2017 09:53:03 -0300
> > Mauro Carvalho Chehab  escreveu:  
> >> Em Tue, 2 May 2017 22:30:29 +0200
> >> Gregor Jasny  escreveu:  
> >>> I just used your patch and another to hopefully fix
> >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859008
> >>>
> >>> But I'm a little bit hesitant to merge it to v4l-utils git without
> >>> Mauros acknowledgement.  
> 
> >> Patches look correct, but the T2 parser has a more serious issue that
> >> will require breaking ABI/API compatibility.  
> 
> > I'll cherry-pick the corresponding patches to the stable branch.  
> 
> Reinhard, could you please test the latest patches on
> https://git.linuxtv.org/v4l-utils.git/log/?h=stable-1.12
> 
> If they work for you, I'd release a new stable version and upload it to 
> Debian Sid afterwards.

I found one additional bug there, at the code that handles subcells.

Fix applied. Reinhard/Clemens, if you find some channel that use
subcells on this descriptor and/or tfs_flag == 1, it would be really cool
if you could store ~60 seconds of the transponder and send it to me, as it
would allow me to have a testing stream. With that, I can input the stream
on my RF generator and test if this is parsed well with libdvbv5,
dvbv5-tools and Kaffeine.

In order to record 60 seconds for the full transponder, after generating
the channel scan, you can do (to record a channel named "RTL HD"):

$ dvbv5-zap -c dvb_channel.conf 'RTL HD' -r -P -t60 -o mychannel.ts

This will produce a big file, so you'll likely need to put it on
some place like dropbox/google drive and pass me the link via
a private e-mail.

-

At the master branch, I just added the logic to fully parse the
cell and subcell IDs. I also added (on both stable-1.2 and master)
a code that will translate guard_interval, SISO/MISO, bandwidth
and transmission mode to the corresponding strings for the bitfield
values.

With those changes, on "master" branch, it will now list the full
content of the descriptor at the NIT table:

NIT
| table_id 0x40
| section_length  135
| one 3
| zero1
| syntax  1
| transport_stream_id 12352
| current_next1
| version 9
| one23
| section_number  0
| last_section_number 0
| desc_length   45
|0x40: network_name_descriptor
|   network name: 'MEDIA BROADCAST'
|0x4a: linkage_descriptor
|   40 71 21 14 42 4c 09 12  60 74 8d 0e 00 f6 00 05   @q!.BL..`t..
|   00 00 01 68 00 00 00 07  07 00 ...h..
|- transport 4061 network 2114
|0x7f: extension_descriptor
|   descriptor T2_delivery_system_descriptor type 0x04
|   plp_id0
|   system_id 7766
|   tfs_flag  0
|   other_frequency_flag  0
|   transmission_mode 32K (5)
|   guard_interval1/16 (1)
|   reserved  3
|   bandwidth 800
|   SISO MISO SISO
|   Cell ID   0x6101
|  centre frequency[0]6420
|   Cell ID   0x0457
|  centre frequency[0]6500
|   frequency[0]  6420
|   frequency[1]  6500
|0x41: Unknown descriptor
|   03 01 1f 42 41 1f 42 42  1f 42 43 1f 42 44 1f 42   ...BA.BB.BC.BD.B
|   45 1f  E.
|- transport 4071 network 2114
|0x7f: extension_descriptor
|   descriptor T2_delivery_system_descriptor type 0x04
|   plp_id1
|   system_id 7766
|   tfs_flag  0
|   other_frequency_flag  0
|   transmission_mode 32K (5)
|   guard_interval1/16 (1)
|   reserved  3
|   bandwidth 800
|   SISO MISO SISO
|   Cell ID   0x0457
|  centre frequency[0]7220
|   frequency[0]  7220
|0x41: Unknown descriptor
|   42 4c 0c 42 80 01  BL.B..
|_  2 transports


Thanks,
Mauro

Re: [PATCH 1/2] v4l: vsp1: Add support for colorkey alpha blending

[Geert Uytterhoeven]

On Thu, May 4, 2017 at 12:53 PM, agheorghe
 wrote:
> --- a/include/media/vsp1.h
> +++ b/include/media/vsp1.h
> @@ -32,6 +32,9 @@ struct vsp1_du_atomic_config {
> struct v4l2_rect dst;
> unsigned int alpha;
> unsigned int zpos;
> +   u32 colorkey;
> +   bool colorkey_en;

Please move this bool down, together with the other bool, to reduce
object size due to alignment.

> +   u32 colorkey_alpha;
> bool interlaced;
>  };

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 1/2] v4l: vsp1: Add support for colorkey alpha blending

[Sergei Shtylyov]

On 05/04/2017 01:53 PM, agheorghe wrote:


The vsp2 hw supports changing of the alpha of pixels that match a color
key, this patch adds support for this feature in order to be used by
the rcar-du driver.
The colorkey is interpreted different depending of the pixel format:
* RGB   - all color components have to match.
* YCbCr - only the Y component has to match.

Signed-off-by: agheorghe 


  Your full name is absolutely necessary here.

MBR, Sergei

[PATCH 0/2] rcar-du, vsp1: rcar-gen3: Add support for colorkey alpha blending

[agheorghe]

Currently, rcar-du supports colorkeying  only for rcar-gen2 and it uses 
some hw capability of the display unit(DU) which is not available on gen3.
In order to implement colorkeying for gen3 we need to use the colorkey
capability of the VSPD, hence the need to change both drivers rcar-du and
vsp1.

This patchset had been developed and tested on top of v4.9/rcar-3.5.1 from
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git

agheorghe (2):
  v4l: vsp1: Add support for colorkey alpha blending
  drm: rcar-du: Add support for colorkey alpha blending

 drivers/gpu/drm/rcar-du/rcar_du_drv.h   |  1 +
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   |  8 
 drivers/gpu/drm/rcar-du/rcar_du_plane.c |  3 ---
 drivers/gpu/drm/rcar-du/rcar_du_plane.h |  6 ++
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   | 22 ++
 drivers/gpu/drm/rcar-du/rcar_du_vsp.h   |  5 +
 drivers/media/platform/vsp1/vsp1_drm.c  |  3 +++
 drivers/media/platform/vsp1/vsp1_rpf.c  | 10 --
 drivers/media/platform/vsp1/vsp1_rwpf.h |  3 +++
 include/media/vsp1.h|  3 +++
 10 files changed, 59 insertions(+), 5 deletions(-)

-- 
1.9.1

[PATCH 2/2] drm: rcar-du: Add support for colorkey alpha blending

[agheorghe]

Add two new plane properties colorkey and colorkey_alpha for rcar gen3.
* colorkey:
- used for specifying the color on which the filtering is done.
- bits 0 to 23 are interpreted as RGB888 format, in case we are
  dealing with an YCbCr format, only the Y componenet is
  compared and it is represented by the G bits from RGB888
  format.
- bit 24 tells if it is enabled or not.
* colorkey_alpha:
- the alpha to be set for matching pixels, in case it is
  missing the pixels will be made transparent

Signed-off-by: agheorghe 
---
 drivers/gpu/drm/rcar-du/rcar_du_drv.h   |  1 +
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   |  8 
 drivers/gpu/drm/rcar-du/rcar_du_plane.c |  3 ---
 drivers/gpu/drm/rcar-du/rcar_du_plane.h |  6 ++
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   | 22 ++
 drivers/gpu/drm/rcar-du/rcar_du_vsp.h   |  5 +
 6 files changed, 42 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index 91e8fc5..1cb92e3 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -98,6 +98,7 @@ struct rcar_du_device {
struct {
struct drm_property *alpha;
struct drm_property *colorkey;
+   struct drm_property *colorkey_alpha;
} props;
 
unsigned int dpad0_source;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 1cc88ed..a733fa2 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -630,6 +630,14 @@ static int rcar_du_properties_init(struct rcar_du_device 
*rcdu)
if (rcdu->props.colorkey == NULL)
return -ENOMEM;
 
+   if (rcdu->info->gen == 3) {
+   rcdu->props.colorkey_alpha =
+   drm_property_create_range(rcdu->ddev, 0,
+ "colorkey_alpha", 0, 255);
+   if (!rcdu->props.colorkey_alpha)
+   return -ENOMEM;
+   }
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index e408aa3..df689c4 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -307,9 +307,6 @@ int rcar_du_atomic_check_planes(struct drm_device *dev,
  * Plane Setup
  */
 
-#define RCAR_DU_COLORKEY_NONE  (0 << 24)
-#define RCAR_DU_COLORKEY_SOURCE(1 << 24)
-#define RCAR_DU_COLORKEY_MASK  (1 << 24)
 
 static void rcar_du_plane_write(struct rcar_du_group *rgrp,
unsigned int index, u32 reg, u32 data)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.h 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
index c1de338..9e7c3b6 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
@@ -49,6 +49,12 @@ static inline struct rcar_du_plane *to_rcar_plane(struct 
drm_plane *plane)
return container_of(plane, struct rcar_du_plane, plane);
 }
 
+#define RCAR_DU_COLORKEY_NONE  (0 << 24)
+#define RCAR_DU_COLORKEY_MASK  BIT(24)
+#define RCAR_DU_COLORKEY_EN_MASK   RCAR_DU_COLORKEY_MASK
+#define RCAR_DU_COLORKEY_COLOR_MASK0xFF
+#define RCAR_DU_COLORKEY_ALPHA_MASK0xFF
+
 /**
  * struct rcar_du_plane_state - Driver-specific plane state
  * @state: base DRM plane state
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index 4b460d4..b223be1 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -180,6 +180,11 @@ static void rcar_du_vsp_plane_setup(struct 
rcar_du_vsp_plane *plane)
.pitch = fb->pitches[0],
.alpha = state->alpha,
.zpos = state->state.zpos,
+   .colorkey = state->colorkey & RCAR_DU_COLORKEY_COLOR_MASK,
+   .colorkey_en =
+   ((state->colorkey & RCAR_DU_COLORKEY_EN_MASK) != 0),
+   .colorkey_alpha =
+   (state->colorkey_alpha & RCAR_DU_COLORKEY_ALPHA_MASK),
};
unsigned int i;
 
@@ -379,6 +384,8 @@ static void rcar_du_vsp_plane_reset(struct drm_plane *plane)
return;
 
state->alpha = 255;
+   state->colorkey = RCAR_DU_COLORKEY_NONE;
+   state->colorkey_alpha = 0;
state->state.zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
 
plane->state = >state;
@@ -394,6 +401,10 @@ static int rcar_du_vsp_plane_atomic_set_property(struct 
drm_plane *plane,
 
if (property == rcdu->props.alpha)
rstate->alpha = val;
+   else if (property == rcdu->props.colorkey)
+   rstate->colorkey = val;
+   else if (property == rcdu->props.colorkey_alpha)
+   rstate->colorkey_alpha = val;
  

[PATCH 1/2] v4l: vsp1: Add support for colorkey alpha blending

[agheorghe]

The vsp2 hw supports changing of the alpha of pixels that match a color
key, this patch adds support for this feature in order to be used by
the rcar-du driver.
The colorkey is interpreted different depending of the pixel format:
* RGB   - all color components have to match.
* YCbCr - only the Y component has to match.

Signed-off-by: agheorghe 
---
 drivers/media/platform/vsp1/vsp1_drm.c  |  3 +++
 drivers/media/platform/vsp1/vsp1_rpf.c  | 10 --
 drivers/media/platform/vsp1/vsp1_rwpf.h |  3 +++
 include/media/vsp1.h|  3 +++
 4 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 3627f08..a4d0aee 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -393,6 +393,9 @@ int vsp1_du_atomic_update(struct device *dev, unsigned int 
rpf_index,
else
rpf->format.plane_fmt[1].bytesperline = cfg->pitch;
rpf->alpha = cfg->alpha;
+   rpf->colorkey = cfg->colorkey;
+   rpf->colorkey_en = cfg->colorkey_en;
+   rpf->colorkey_alpha = cfg->colorkey_alpha;
rpf->interlaced = cfg->interlaced;
 
if (soc_device_match(r8a7795es1) && rpf->interlaced) {
diff --git a/drivers/media/platform/vsp1/vsp1_rpf.c 
b/drivers/media/platform/vsp1/vsp1_rpf.c
index a12d6f9..91f2a9f 100644
--- a/drivers/media/platform/vsp1/vsp1_rpf.c
+++ b/drivers/media/platform/vsp1/vsp1_rpf.c
@@ -356,8 +356,14 @@ static void rpf_configure(struct vsp1_entity *entity,
}
 
vsp1_rpf_write(rpf, dl, VI6_RPF_MSK_CTRL, 0);
-   vsp1_rpf_write(rpf, dl, VI6_RPF_CKEY_CTRL, 0);
-
+   if (rpf->colorkey_en) {
+   vsp1_rpf_write(rpf, dl, VI6_RPF_CKEY_SET0,
+  (rpf->colorkey_alpha << 24) | rpf->colorkey);
+   vsp1_rpf_write(rpf, dl, VI6_RPF_CKEY_CTRL,
+  VI6_RPF_CKEY_CTRL_SAPE0);
+   } else {
+   vsp1_rpf_write(rpf, dl, VI6_RPF_CKEY_CTRL, 0);
+   }
 }
 
 static const struct vsp1_entity_operations rpf_entity_ops = {
diff --git a/drivers/media/platform/vsp1/vsp1_rwpf.h 
b/drivers/media/platform/vsp1/vsp1_rwpf.h
index fbe6aa6..2d7f4b9 100644
--- a/drivers/media/platform/vsp1/vsp1_rwpf.h
+++ b/drivers/media/platform/vsp1/vsp1_rwpf.h
@@ -51,6 +51,9 @@ struct vsp1_rwpf {
unsigned int brs_input;
 
unsigned int alpha;
+   u32 colorkey;
+   bool colorkey_en;
+   u32 colorkey_alpha;
 
u32 mult_alpha;
u32 outfmt;
diff --git a/include/media/vsp1.h b/include/media/vsp1.h
index 97265f7..879f464 100644
--- a/include/media/vsp1.h
+++ b/include/media/vsp1.h
@@ -32,6 +32,9 @@ struct vsp1_du_atomic_config {
struct v4l2_rect dst;
unsigned int alpha;
unsigned int zpos;
+   u32 colorkey;
+   bool colorkey_en;
+   u32 colorkey_alpha;
bool interlaced;
 };
 
-- 
1.9.1

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

[Philipp Zabel]

On Thu, 2017-05-04 at 12:48 +0300, Sakari Ailus wrote:
> Hi Philipp,
> 
> On Thu, May 04, 2017 at 11:26:18AM +0200, Philipp Zabel wrote:
> > Hi Sakari,
> > 
> > On Thu, 2017-05-04 at 10:17 +0300, Sakari Ailus wrote:
> > > Hi Philipp,
> > > 
> > > On Thu, May 04, 2017 at 09:07:32AM +0200, Philipp Zabel wrote:
> > > > On Wed, 2017-05-03 at 22:28 +0300, Sakari Ailus wrote:
> > > > > Hi Philipp,
> > > > > 
> > > > > Thanks for continuing working on this!
> > > > > 
> > > > > I have some minor comments below...
> > > > 
> > > > Thank you for the comments.
> > > > 
> > > > [...]
> > > > > Could you rebase this on the V4L2 fwnode patchset here, please?
> > > > > 
> > > > > 
> > > > >
> > > > > The conversion is rather simple, as shown here:
> > > > > 
> > > > > 
> > > > 
> > > > What is the status of this patchset? Will this be merged soon?
> > > 
> > > I intend to send a pull request once the next rc1 tag is pulled on
> > > media-tree master. It depends on patches in linux-pm tree that aren't in
> > > media-tree yet.
> > 
> > I get conflicts trying to merge v4l2-acpi into v4.11 or media-tree
> > master. Could you provide an updated version?
> 
> What kind of conflicts? I wonder if something somewhere is out of sync. :-)
> My v4l2-acpi branch is on top of current media-tree master and appears to
> merge cleanly to v4.11 as well.
> 
> It still wouldn't compile though as it depends on the fwnode graph patches.
> 
> I've merged those here:
> 
> 

My bad, I accidentally used an old git remote that still pointed to
git://git.retiisi.org.uk/~sailus/linux.git. Fixed that now.

thanks
Philipp

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

[Sakari Ailus]

Hi Philipp,

On Thu, May 04, 2017 at 11:26:18AM +0200, Philipp Zabel wrote:
> Hi Sakari,
> 
> On Thu, 2017-05-04 at 10:17 +0300, Sakari Ailus wrote:
> > Hi Philipp,
> > 
> > On Thu, May 04, 2017 at 09:07:32AM +0200, Philipp Zabel wrote:
> > > On Wed, 2017-05-03 at 22:28 +0300, Sakari Ailus wrote:
> > > > Hi Philipp,
> > > > 
> > > > Thanks for continuing working on this!
> > > > 
> > > > I have some minor comments below...
> > > 
> > > Thank you for the comments.
> > > 
> > > [...]
> > > > Could you rebase this on the V4L2 fwnode patchset here, please?
> > > > 
> > > > 
> > > >
> > > > The conversion is rather simple, as shown here:
> > > > 
> > > > 
> > > 
> > > What is the status of this patchset? Will this be merged soon?
> > 
> > I intend to send a pull request once the next rc1 tag is pulled on
> > media-tree master. It depends on patches in linux-pm tree that aren't in
> > media-tree yet.
> 
> I get conflicts trying to merge v4l2-acpi into v4.11 or media-tree
> master. Could you provide an updated version?

What kind of conflicts? I wonder if something somewhere is out of sync. :-)
My v4l2-acpi branch is on top of current media-tree master and appears to
merge cleanly to v4.11 as well.

It still wouldn't compile though as it depends on the fwnode graph patches.

I've merged those here:



-- 
Kind regards,

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

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

[Philipp Zabel]

Hi Sakari,

On Thu, 2017-05-04 at 10:17 +0300, Sakari Ailus wrote:
> Hi Philipp,
> 
> On Thu, May 04, 2017 at 09:07:32AM +0200, Philipp Zabel wrote:
> > On Wed, 2017-05-03 at 22:28 +0300, Sakari Ailus wrote:
> > > Hi Philipp,
> > > 
> > > Thanks for continuing working on this!
> > > 
> > > I have some minor comments below...
> > 
> > Thank you for the comments.
> > 
> > [...]
> > > Could you rebase this on the V4L2 fwnode patchset here, please?
> > > 
> > > 
> > >
> > > The conversion is rather simple, as shown here:
> > > 
> > > 
> > 
> > What is the status of this patchset? Will this be merged soon?
> 
> I intend to send a pull request once the next rc1 tag is pulled on
> media-tree master. It depends on patches in linux-pm tree that aren't in
> media-tree yet.

I get conflicts trying to merge v4l2-acpi into v4.11 or media-tree
master. Could you provide an updated version?

regards
Philipp

Re: [PATCH] ov5670: Add Omnivision OV5670 5M sensor support

[Sakari Ailus]

On Thu, May 04, 2017 at 11:48:51AM +0300, Sakari Ailus wrote:
> On Wed, May 03, 2017 at 03:06:52PM -0700, Chiranjeevi Rapolu wrote:
> > Provides single source pad with up to 2576x1936 pixels at 10-bit raw
> > bayer format over MIPI CSI2 two lanes at 640Mbps/lane.
> > Supports up to 30fps at 5M pixels, up to 60fps at 1080p.
> > 
> > Signed-off-by: Chiranjeevi Rapolu 
> > ---
> >  drivers/media/i2c/Kconfig  |   11 +
> >  drivers/media/i2c/Makefile |1 +
> >  drivers/media/i2c/ov5670.c | 3890 
> > 
> >  3 files changed, 3902 insertions(+)
> >  create mode 100644 drivers/media/i2c/ov5670.c
> > 
> > diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> > index cee1dae..ded8485 100644
> > --- a/drivers/media/i2c/Kconfig
> > +++ b/drivers/media/i2c/Kconfig
> > @@ -531,6 +531,17 @@ config VIDEO_OV2659
> >   To compile this driver as a module, choose M here: the
> >   module will be called ov2659.
> >  
> > +config VIDEO_OV5670
> > +   tristate "OmniVision OV5670 sensor support"
> > +   depends on I2C && VIDEO_V4L2
> > +   depends on MEDIA_CAMERA_SUPPORT

select V4L2_FWNODE

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

Re: [PATCH] ov5670: Add Omnivision OV5670 5M sensor support

[Sakari Ailus]

Hi Chiranjeevi,

Thanks for the patch.

On Wed, May 03, 2017 at 03:06:52PM -0700, Chiranjeevi Rapolu wrote:
> Provides single source pad with up to 2576x1936 pixels at 10-bit raw
> bayer format over MIPI CSI2 two lanes at 640Mbps/lane.
> Supports up to 30fps at 5M pixels, up to 60fps at 1080p.
> 
> Signed-off-by: Chiranjeevi Rapolu 
> ---
>  drivers/media/i2c/Kconfig  |   11 +
>  drivers/media/i2c/Makefile |1 +
>  drivers/media/i2c/ov5670.c | 3890 
> 
>  3 files changed, 3902 insertions(+)
>  create mode 100644 drivers/media/i2c/ov5670.c
> 
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index cee1dae..ded8485 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -531,6 +531,17 @@ config VIDEO_OV2659
> To compile this driver as a module, choose M here: the
> module will be called ov2659.
>  
> +config VIDEO_OV5670
> + tristate "OmniVision OV5670 sensor support"
> + depends on I2C && VIDEO_V4L2
> + depends on MEDIA_CAMERA_SUPPORT
> + ---help---
> +   This is a Video4Linux2 sensor-level driver for the OmniVision
> +   OV5670 camera.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called ov5670.
> +
>  config VIDEO_OV7640
>   tristate "OmniVision OV7640 sensor support"
>   depends on I2C && VIDEO_V4L2
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index 5bc7bbe..3efc61f 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -57,6 +57,7 @@ obj-$(CONFIG_VIDEO_VP27SMPX) += vp27smpx.o
>  obj-$(CONFIG_VIDEO_SONY_BTF_MPX) += sony-btf-mpx.o
>  obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
>  obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
> +obj-$(CONFIG_VIDEO_OV5670) += ov5670.o

The patch no longer applies cleanly to current media-tree master. Could you
rebase it on top of that?

>  obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
>  obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
>  obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
> diff --git a/drivers/media/i2c/ov5670.c b/drivers/media/i2c/ov5670.c
> new file mode 100644
> index 000..394f8f2
> --- /dev/null
> +++ b/drivers/media/i2c/ov5670.c
> @@ -0,0 +1,3890 @@
> +/*
> + * Copyright (c) 2017 Intel Corporation.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version
> + * 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include 
> +#include 

Do you need delay.h?

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

Alphabetical order, please.

> +
> +#define OV5670_CHIP_ID   0x005670
> +
> +#define OV5670_REG_VALUE_08BIT   1
> +#define OV5670_REG_VALUE_16BIT   2
> +#define OV5670_REG_VALUE_24BIT   3
> +
> +#define OV5670_REG_MODE_SELECT   0x0100
> +#define OV5670_MODE_STANDBY  0x00
> +#define OV5670_MODE_STREAMING0x01
> +
> +#define OV5670_REG_SOFTWARE_RST  0x0103
> +#define OV5670_SOFTWARE_RST  0x01
> +
> +#define OV5670_REG_EXPOSURE  0x3500
> +#define OV5670_REG_ANALOG_GAIN   0x3508
> +
> +#define OV5670_REG_CHIPID0x300a
> +
> +/* Supported link frequencies */
> +#define OV5670_LINK_FREQ_840MBPS 84000
> +#define OV5670_LINK_FREQ_840MBPS_INDEX   0

It'd be better to define these there you have the related register lists.

> +
> +/* Analog gain controls from sensor */
> +#define  ANALOG_GAIN_MIN 0
> +#define  ANALOG_GAIN_MAX 8191
> +#define  ANALOG_GAIN_STEP1
> +#define  ANALOG_GAIN_DEFAULT 128
> +
> +/* Exposure controls from sensor */
> +#define  EXPOSURE_MIN0
> +#define  EXPOSURE_MAX1048575
> +#define  EXPOSURE_STEP   1
> +#define  EXPOSURE_DEFAULT47232

Are these values dependent on sensor configuration i.e. in the case of this
driver modes?

> +
> +struct ov5670_reg {
> + u16 address;
> + u8 val;
> +};
> +
> +struct ov5670_reg_list {
> + u32 num_of_regs;
> + const struct ov5670_reg *regs;
> +};
> +
> +struct ov5670_link_freq_config {
> + s64 link_freq;
> + u32 pixel_rate;
> +
> + const struct ov5670_reg_list reg_list;
> +};
> +
> +struct ov5670_mode {
> + /* Frame width in pixels */
> + u32 width;
> +
> + /* Frame height in pixels */
> + u32 height;
> +
> + /* Initial number of frames to skip to avoid garbage in the frames */
> + u32 skip_frames;
> +
> + /* Link frequency needed for this resolution */
> + u32 

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

[Gregor Jasny]

Hello Mauro,

On 04.05.17 00:33, Mauro Carvalho Chehab wrote:

Em Wed, 3 May 2017 09:53:03 -0300
Mauro Carvalho Chehab  escreveu:

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

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

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



Patches look correct, but the T2 parser has a more serious issue that
will require breaking ABI/API compatibility.



I'll cherry-pick the corresponding patches to the stable branch.


Reinhard, could you please test the latest patches on
https://git.linuxtv.org/v4l-utils.git/log/?h=stable-1.12

If they work for you, I'd release a new stable version and upload it to 
Debian Sid afterwards.


Thanks,
Gregor

Re: [PATCH v4 0/8] Add support for DCMI camera interface of STMicroelectronics STM32 SoC series

[Alexandre Torgue]

Hi Hugues,

On 04/20/2017 06:07 PM, Hugues Fruchet wrote:

This patchset introduces a basic support for Digital Camera Memory Interface
(DCMI) of STMicroelectronics STM32 SoC series.

This first basic support implements RGB565 & YUV frame grabbing.
Cropping and JPEG support will be added later on.

This has been tested on STM324x9I-EVAL evaluation board embedding
an OV2640 camera sensor.

This driver depends on:
  - [PATCHv6 00/14] atmel-isi/ov7670/ov2640: convert to standalone drivers 
http://www.spinics.net/lists/linux-media/msg113480.html


For stm32 machine part (DT+config):
Acked-by: Alexandre TORGUE 

I will add it in future pull request.

Regards
Alex



===
= history =
===
version 4:
  - "v4l2-compliance -s -f" report
  - fix behaviour in case of start_streaming failure (DMA memory shortage for 
ex.)
  - dt-bindings: Fix remarks from Rob Herring:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg111340.html
Add "Acked-by: Rob Herring "

version 3:
  - stm32-dcmi: Add "Reviewed-by: Hans Verkuil "
  - dt-bindings: Fix remarks from Rob Herring:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg110956.html

version 2:
  - Fix a Kbuild warning in probe:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg110678.html
  - Fix a warning in dcmi_queue_setup()
  - dt-bindings: warn on sensor signals level inversion in board example
  - Typos fixing

version 1:
  - Initial submission

===
= v4l2-compliance =
===
Below is the v4l2-compliance report for this current version of the DCMI camera 
interface.
v4l2-compliance has been built from v4l-utils-1.12.3.

~ # v4l2-compliance -s -f -d /dev/video0
v4l2-compliance SHA   : f5f45e17ee98a0ebad7836ade2b34ceec909d751

Driver Info:
Driver name   : stm32-dcmi
Card type : STM32 Digital Camera Memory Int
Bus info  : platform:dcmi
Driver version: 4.11.0
Capabilities  : 0x8521
Video Capture
Read/Write
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x0521
Video Capture
Read/Write
Streaming
Extended Pix Format

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

Required ioctls:
test VIDIOC_QUERYCAP: OK

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

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK

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

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

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

Test input 0:

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

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

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

Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test VIDIOC_EXPBUF: OK

Test input 0:

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

[Sakari Ailus]

Hi Philipp,

On Thu, May 04, 2017 at 09:07:32AM +0200, Philipp Zabel wrote:
> On Wed, 2017-05-03 at 22:28 +0300, Sakari Ailus wrote:
> > Hi Philipp,
> > 
> > Thanks for continuing working on this!
> > 
> > I have some minor comments below...
> 
> Thank you for the comments.
> 
> [...]
> > Could you rebase this on the V4L2 fwnode patchset here, please?
> > 
> > 
> >
> > The conversion is rather simple, as shown here:
> > 
> > 
> 
> What is the status of this patchset? Will this be merged soon?

I intend to send a pull request once the next rc1 tag is pulled on
media-tree master. It depends on patches in linux-pm tree that aren't in
media-tree yet.

-- 
Kind regards,

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

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

[Philipp Zabel]

On Wed, 2017-05-03 at 22:28 +0300, Sakari Ailus wrote:
> Hi Philipp,
> 
> Thanks for continuing working on this!
> 
> I have some minor comments below...

Thank you for the comments.

[...]
> Could you rebase this on the V4L2 fwnode patchset here, please?
> 
> 
>
> The conversion is rather simple, as shown here:
> 
> 

What is the status of this patchset? Will this be merged soon?

[...]
> > +static inline bool is_source_pad(struct video_mux *vmux, unsigned int pad)
> 
> It's a common practice to test pad flags rather than the pad number.
> Although the pad number here implicitly tells this, too, testing pad flags
> is cleaner.
> 
> The matter was discussed in the past and it was decided not to add helper
> functions to the framework for the purpose as testing the flags is trivial.

Ok, I'll drop is_source_pad and check (pad->flags & MEDIA_PAD_FL_SOURCE)
instead in the next version.

[...]
> > +static int video_mux_set_format(struct v4l2_subdev *sd,
> > +   struct v4l2_subdev_pad_config *cfg,
> > +   struct v4l2_subdev_format *sdformat)
> > +{
> > +   struct video_mux *vmux = v4l2_subdev_to_video_mux(sd);
> > +   struct v4l2_mbus_framefmt *mbusformat;
> > +
> > +   mbusformat = __video_mux_get_pad_format(sd, cfg, sdformat->pad,
> > +   sdformat->which);
> > +   if (!mbusformat)
> > +   return -EINVAL;
> > +
> > +   mutex_lock(>lock);
> > +
> > +   /* Source pad mirrors active sink pad, no limitations on sink pads */
> > +   if (is_source_pad(vmux, sdformat->pad) && vmux->active >= 0)
> > +   sdformat->format = vmux->format_mbus[vmux->active];
> > +
> > +   mutex_unlock(>lock);
> > +
> > +   *mbusformat = sdformat->format;
> 
> Shouldn't you do this before releasing the mutex? The assignment won't be
> an atomic operation. Same for get_format; you should take the mutex.

Yes, I'll extend the mutex to cover the mbus formats.

[...]
> > +static struct v4l2_subdev_pad_ops video_mux_pad_ops = {
> > +   .get_fmt = video_mux_get_format,
> > +   .set_fmt = video_mux_set_format,
> > +};
> > +
> > +static struct v4l2_subdev_ops video_mux_subdev_ops = {
> 
> Const for both of the structs?

Will do, thanks.

regards
Philipp