date:20170531

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

Results of the daily build of media_tree:

date:   Thu Jun  1 05:00:16 CEST 2017
media-tree git hash:36bcba973ad478042d1ffc6e89afd92e8bd17030
media_build git hash:   0d8b3274e29b597780719e7ce1b3b460241a5395
v4l-utils git hash: ef074cf5500b7dd62e6eb3527ec47a914c7189ca
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: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: WARNINGS
linux-2.6.36.4-i686: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: OK
linux-3.0.60-i686: OK
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: OK
linux-3.12.67-i686: OK
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: OK
linux-4.9.26-i686: OK
linux-4.10.14-i686: OK
linux-4.11-i686: OK
linux-4.12-rc1-i686: OK
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.37-x86_64: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: WARNINGS
linux-3.12.67-x86_64: WARNINGS
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: WARNINGS
linux-4.9.26-x86_64: WARNINGS
linux-4.10.14-x86_64: WARNINGS
linux-4.11-x86_64: WARNINGS
linux-4.12-rc1-x86_64: WARNINGS
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

[PATCH] ivtv: Fix a sleep-in-atomic bug in snd_ivtv_pcm_hw_free

2017-05-31 Thread Jia-Ju Bai

The driver may sleep under a spin lock, and the function call path is:
snd_ivtv_pcm_hw_free (acquire the lock by spin_lock_irqsave)
  vfree --> may sleep

To fix it, the "substream->runtime->dma_area" is passed to a temporary
value, and mark it NULL when holding the lock. The memory is freed by
vfree through the temporary value outside the lock holding.

Signed-off-by: Jia-Ju Bai 
---
 drivers/media/pci/ivtv/ivtv-alsa-pcm.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/pci/ivtv/ivtv-alsa-pcm.c 
b/drivers/media/pci/ivtv/ivtv-alsa-pcm.c
index 807ead2..92d088c 100644
--- a/drivers/media/pci/ivtv/ivtv-alsa-pcm.c
+++ b/drivers/media/pci/ivtv/ivtv-alsa-pcm.c
@@ -262,14 +262,16 @@ static int snd_ivtv_pcm_hw_free(struct snd_pcm_substream 
*substream)
 {
struct snd_ivtv_card *itvsc = snd_pcm_substream_chip(substream);
unsigned long flags;
+   unsigned char *dma_area;
 
spin_lock_irqsave(>slock, flags);
if (substream->runtime->dma_area) {
dprintk("freeing pcm capture region\n");
-   vfree(substream->runtime->dma_area);
+   dma_area = substream->runtime->dma_area;
substream->runtime->dma_area = NULL;
}
spin_unlock_irqrestore(>slock, flags);
+   vfree(dma_area);
 
return 0;
 }
-- 
1.7.9.5

[PATCH] cx18: Fix a sleep-in-atomic bug in snd_cx18_pcm_hw_free

2017-05-31 Thread Jia-Ju Bai

The driver may sleep under a spin lock, and the function call path is:
snd_cx18_pcm_hw_free (acquire the lock by spin_lock_irqsave)
  vfree --> may sleep

To fix it, the "substream->runtime->dma_area" is passed to a temporary 
value, and mark it NULL when holding the lock. The memory is freed by 
vfree through the temporary value outside the lock holding.

Signed-off-by: Jia-Ju Bai 
---
 drivers/media/pci/cx18/cx18-alsa-pcm.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/pci/cx18/cx18-alsa-pcm.c 
b/drivers/media/pci/cx18/cx18-alsa-pcm.c
index 205a98d..ba83147 100644
--- a/drivers/media/pci/cx18/cx18-alsa-pcm.c
+++ b/drivers/media/pci/cx18/cx18-alsa-pcm.c
@@ -257,14 +257,16 @@ static int snd_cx18_pcm_hw_free(struct snd_pcm_substream 
*substream)
 {
struct snd_cx18_card *cxsc = snd_pcm_substream_chip(substream);
unsigned long flags;
+   unsigned char *dma_area;
 
spin_lock_irqsave(>slock, flags);
if (substream->runtime->dma_area) {
dprintk("freeing pcm capture region\n");
-   vfree(substream->runtime->dma_area);
+   dma_area = substream->runtime->dma_area;
substream->runtime->dma_area = NULL;
}
spin_unlock_irqrestore(>slock, flags);
+   vfree(dma_area);
 
return 0;
 }
-- 
1.7.9.5

Error trying to build the latest V4L on a BeagleBone Black

2017-05-31 Thread Ron Moreland

’m trying to build the latest V4L on a BeagleBone Black ( BBB ):
lsb_release -a ->
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 8.8 (jessie)
Release:8.8
Codename:   jessie

name -mrs ->  Linux 4.4.54-ti-r93 armv7l

error:

./scripts/make_kconfig.pl /lib/modules/4.4.54-ti-r93/build 
/lib/modules/4.4.54-ti-r93/build 1
Preparing to compile for kernel version 4.4.54
File not found: /lib/modules/4.4.54-ti-r93/build/.config at 
./scripts/make_kconfig.pl line 33,  line 4.
Makefile:383: recipe for target 'allyesconfig' failed
make[1]: *** [allyesconfig] Error 2
make[1]: Leaving directory '/home/ron/media_build/v4l'
Makefile:26: recipe for target 'allyesconfig' failed
make: *** [allyesconfig] Error 2
can't select all drivers at ./build line 501.

Re: [PATCH v2 0/15] [dt-bindings] [media] Add document file and driver for Sony CXD2880 DVB-T2/T tuner + demodulator

2017-05-31 Thread Takiguchi, Yasunari

Hi, all

I sent the patch series of Sony CXD2880 DVB-T2/T tuner + demodulator driver on 
Apr/14.
Are there any comments, advices and review results for them?

I'd like to get better understanding of current review status for our codes.

Regards,
Takiguchi

Re: [PATCH 00/19] cxd2841er/ddbridge: support Sony CXD28xx hardware

Hi Daniel,

ok, perfect !
Will check this flags later when I switch back to driver :) Current
situation with configurable flags is ok.


2017-05-31 16:32 GMT-04:00 Daniel Scheller :
> Am Wed, 31 May 2017 08:30:34 -0400
> schrieb Abylay Ospan :
>
> Hi Abylay,
>
>> I have ack'ed all patches related to cxd2841er. Please check am i
>> missing something ?
>
> Thank you very much for your review and your ACKs, and in general
> taking time to look into them! You didn't miss any of the patches :)
> Will add your ACKs to the cxd2841er patches in a very likely upcoming V2
> of the series.
>
>> I see some good flags (CXD2841ER_NO_WAIT_LOCK and
>> CXD2841ER_EARLY_TUNE). I should check it for our boards too :)
>
> Re EARLY_TUNE - I wasn't sure if the order of tuner/demod setup is of
> importance on your devices. When picking the IF freq from the tuner
> though, we first need to tune and then set up the demod since the demod
> queries the tuner about this. If your hardware also works with the
> "earlier tune", maybe we should drop this flag/condition and just move
> the tune call up.
>
> Re NO_WAIT_LOCK - works fine with or without this. However, when e.g.
> using TVH and looking at the stats, the Web UI will freeze if a retune
> occurs. Again, not sure if it's absolutely required on your
> hardware/software - if not, I suggest to remove the flag together with
> the wait lock entirely.
>
> Looking forward for your results and opinions! :-)
>
> Best regards,
> Daniel Scheller



-- 
Abylay Ospan,
NetUP Inc.
http://www.netup.tv

Re: [PATCH 00/19] cxd2841er/ddbridge: support Sony CXD28xx hardware

2017-05-31 Thread Daniel Scheller

Am Wed, 31 May 2017 08:30:34 -0400
schrieb Abylay Ospan :

Hi Abylay,

> I have ack'ed all patches related to cxd2841er. Please check am i
> missing something ?

Thank you very much for your review and your ACKs, and in general
taking time to look into them! You didn't miss any of the patches :)
Will add your ACKs to the cxd2841er patches in a very likely upcoming V2
of the series.

> I see some good flags (CXD2841ER_NO_WAIT_LOCK and
> CXD2841ER_EARLY_TUNE). I should check it for our boards too :)

Re EARLY_TUNE - I wasn't sure if the order of tuner/demod setup is of
importance on your devices. When picking the IF freq from the tuner
though, we first need to tune and then set up the demod since the demod
queries the tuner about this. If your hardware also works with the
"earlier tune", maybe we should drop this flag/condition and just move
the tune call up.

Re NO_WAIT_LOCK - works fine with or without this. However, when e.g.
using TVH and looking at the stats, the Web UI will freeze if a retune
occurs. Again, not sure if it's absolutely required on your
hardware/software - if not, I suggest to remove the flag together with
the wait lock entirely.

Looking forward for your results and opinions! :-)

Best regards,
Daniel Scheller

Re: [PATCH v7 00/34] i.MX Media Driver

2017-05-31 Thread Pavel Machek

Hi!

> >If there's a need for this (there should not be, as the controls are exposed
> >to the user space through the sub-device nodes as the other drivers do), the
> >framework APIs need to be extended.
> 
> Right, this gets back to the media framework usability arguments. At least
> myself, Philipp, and Russell feel that automatic inheritance of a configured
> pipeline's controls to a video device adds to the usability.

For the record, usability can be pretty much fixed in v4l-utils... I
have patches that try ioctls on a list of fd's. Now we need a way to
find out which /dev/video* files belong to single camera. I believe
kernel already has required APIs, we just need to apply v4l-utils
patch to use them...

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: Fwd: [PATCH] em28xx: add support for Hauppauge WinTV-dualHD DVB tuner

2017-05-31 Thread Brad Love

Christian et al,

I am an engineer at Hauppauge. This repo is the staging area for all the
patches I am testing, with the intention of getting them upstreamed. I
will be inaccessible for the next 18 days however, so I will not be able
to put any effort until I get back.

Cheers,

Brad



On 2017-05-27 10:38, Christian Steiner wrote:
> Hello,
>
> I have found patches that add support for the second tuner:
> https://github.com/b-rad-NDi/Ubuntu-media-tree-kernel-builder/tree/master/patches/ubuntu-zesty-4.10.0/extra
>
> I can confirm that they also work with the latest kernel (4.12.0-rc2).
> Would it be possible to integrate these patches into mainline?
> Applying 0006-Hauppauge-WinTV-DualHD-DVB-ATSC-second-tuner-support.patch
> is sufficient for the second tuner to appear, but I guess we should
> include all patches.
>
> Best regards,
> Christian
>
>
> On 11.04.2016 11:14, Olli Salonen wrote:
>> Hi Christian,
>>
>> Thanks for reporting back your experience. Certainly there's a chance
>> of supporting the second tuner too. There are still two issues that I
>> have not solved:
>>
>> 1. I haven't gotten the 2nd tuner working yet (alone, without the
>> first tuner), even if I think all the pieces of the puzzle are there.
>> 2. em28xx driver is built with one tuner in mind and needs significant
>> structural changes. If there's anyone very familiar with the em28xx
>> driver here, I'd be happy to hear your idea of what is entailed for
>> this.
>>
>> Cheers,
>> -olli
>>
>> On 10 April 2016 at 18:23, Christian Steiner
>>  wrote:
>>> On 04.04.2016 17:12, Olli Salonen wrote:
 Hauppauge WinTV-dualHD is a USB 2.0 dual DVB-T/T2/C tuner with
 following components:

 USB bridge: Empia EM28274 (chip id is the same as EM28174)
 Demodulator: 2x Silicon Labs Si2168-B40
 Tuner: 2x Silicon Labs Si2157-A30

 This patch adds support only for the first tuner.

 [...]
>>> Thank you very much!
>>> Works fine for me:
>>>
 [  419.413188] em28xx: New device HCW dualHD @ 480 Mbps (2040:0265, 
 interface 0, class 0)
 [  419.413195] em28xx: DVB interface 0 found: isoc
 [  419.413265] em28xx: chip ID is em28174
 [  420.529619] em28174 #0: EEPROM ID = 26 00 01 00, EEPROM hash = 
 0x7addc1c8
 [  420.529626] em28174 #0: EEPROM info:
 [  420.529630] em28174 #0:  microcode start address = 0x0004, boot 
 configuration = 0x01
 [  420.536077] em28174 #0:  AC97 audio (5 sample rates)
 [  420.536084] em28174 #0:  500mA max power
 [  420.536089] em28174 #0:  Table at offset 0x27, strings=0x0e6a, 
 0x1888, 0x087e
 [  420.536188] em28174 #0: Identified as Hauppauge WinTV-dualHD DVB 
 (card=98)
 [  420.537974] tveeprom 8-0050: Hauppauge model 204109, rev B2I6, serial# 
 11XX
 [  420.537981] tveeprom 8-0050: tuner model is SiLabs Si2157 (idx 186, 
 type 4)
 [  420.537986] tveeprom 8-0050: TV standards PAL(B/G) NTSC(M) PAL(I) 
 SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xfc)
 [  420.537989] tveeprom 8-0050: audio processor is None (idx 0)
 [  420.537993] tveeprom 8-0050: has no radio, has IR receiver, has no IR 
 transmitter
 [  420.537997] em28174 #0: dvb set to isoc mode.
 [  420.538056] usbcore: registered new interface driver em28xx
 [  420.541087] em28174 #0: Binding DVB extension
 [  420.544008] i2c i2c-8: Added multiplexed i2c bus 9
 [  420.544016] si2168 8-0064: Silicon Labs Si2168 successfully attached
 [  420.548372] si2157 9-0060: Silicon Labs Si2147/2148/2157/2158 
 successfully attached
 [  420.548389] DVB: registering new adapter (em28174 #0)
 [  420.548396] usb 2-2: DVB: registering adapter 0 frontend 0 (Silicon 
 Labs Si2168)...
 [  420.549737] em28174 #0: DVB extension successfully initialized
 [  420.549743] em28xx: Registered (Em28xx dvb Extension) extension
 [  435.418798] si2168 8-0064: found a 'Silicon Labs Si2168-B40'
 [  435.418823] si2168 8-0064: downloading firmware from file 
 'dvb-demod-si2168-b40-01.fw'
 [  435.617181] si2168 8-0064: firmware version: 4.0.11
 [  435.619791] si2157 9-0060: found a 'Silicon Labs Si2157-A30'
 [  435.642006] si2157 9-0060: firmware version: 3.0.5
>>> (I have replaced the last digits of the serial number with X)
>>>
>>> Is there any chance to add support for the second tuner, too?
>>> This would be awesome.
>>>
>>> Best,
>>> Christian
>>>

Re: [PATCH v7 16/34] [media] add Omnivision OV5640 sensor driver

2017-05-31 Thread Pavel Machek

Hi!

> +/* min/typical/max system clock (xclk) frequencies */
> +#define OV5640_XCLK_MIN  600
> +#define OV5640_XCLK_MAX 2400
> +
> +/*
> + * FIXME: there is no subdev API to set the MIPI CSI-2
> + * virtual channel yet, so this is hardcoded for now.
> + */
> +#define OV5640_MIPI_VC   1

Can the FIXME be fixed?

> +/*
> + * image size under 1280 * 960 are SUBSAMPLING

-> Image

> + * image size upper 1280 * 960 are SCALING

above?

> +/*
> + * FIXME: all of these register tables are likely filled with
> + * entries that set the register to their power-on default values,
> + * and which are otherwise not touched by this driver. Those entries
> + * should be identified and removed to speed register load time
> + * over i2c.
> + */

load->loading? Can the FIXME be fixed?

> + /* Auto/manual exposure */
> + ctrls->auto_exp = v4l2_ctrl_new_std_menu(hdl, ops,
> +  V4L2_CID_EXPOSURE_AUTO,
> +  V4L2_EXPOSURE_MANUAL, 0,
> +  V4L2_EXPOSURE_AUTO);
> + ctrls->exposure = v4l2_ctrl_new_std(hdl, ops,
> + V4L2_CID_EXPOSURE_ABSOLUTE,
> + 0, 65535, 1, 0);

Is exposure_absolute supposed to be in microseconds...?


> + /* Auto/manual gain */
> + ctrls->auto_gain = v4l2_ctrl_new_std(hdl, ops, V4L2_CID_AUTOGAIN,
> +  0, 1, 1, 1);
> + ctrls->gain = v4l2_ctrl_new_std(hdl, ops, V4L2_CID_GAIN,
> + 0, 1023, 1, 0);
> +
> + ctrls->saturation = v4l2_ctrl_new_std(hdl, ops, V4L2_CID_SATURATION,
> +   0, 255, 1, 64);
> + ctrls->hue = v4l2_ctrl_new_std(hdl, ops, V4L2_CID_HUE,
> +0, 359, 1, 0);
> + ctrls->contrast = v4l2_ctrl_new_std(hdl, ops, V4L2_CID_CONTRAST,
> + 0, 255, 1, 0);
> + ctrls->test_pattern =
> + v4l2_ctrl_new_std_menu_items(hdl, ops, V4L2_CID_TEST_PATTERN,
> +  ARRAY_SIZE(test_pattern_menu) - 1,
> +  0, 0, test_pattern_menu);
> +

It is good to see sensor that has autogain/etc. I'm emulating them in
v4l-utils, and hardware that supports it is a good argument. 

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


signature.asc
Description: Digital signature

Re: [PATCH] ARM: dts: exynos: Add HDMI CEC device to Exynos5 SoC family

2017-05-31 Thread Krzysztof Kozlowski

On Wed, May 31, 2017 at 01:00:17PM +0200, Marek Szyprowski wrote:
> Exynos5250 and Exynos542x SoCs have the same CEC hardware module as
> Exynos4 SoC series, so enable support for it using the same compatible
> string.
> 
> Tested on Odroid XU3 (Exynos5422) and Google Snow (Exynos5250) boards.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  arch/arm/boot/dts/exynos5250-pinctrl.dtsi  |  7 +++
>  arch/arm/boot/dts/exynos5250-snow-common.dtsi  |  4 
>  arch/arm/boot/dts/exynos5250.dtsi  | 13 +
>  arch/arm/boot/dts/exynos5420-pinctrl.dtsi  |  7 +++
>  arch/arm/boot/dts/exynos5420.dtsi  | 13 +
>  arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi |  4 
>  6 files changed, 48 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi 
> b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
> index 2f6ab32b5954..1fd122db18e6 100644
> --- a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
> @@ -589,6 +589,13 @@
>   samsung,pin-pud = ;
>   samsung,pin-drv = ;
>   };
> +
> + hdmi_cec: hdmi-cec {
> + samsung,pins = "gpx3-6";
> + samsung,pin-function = ;
> + samsung,pin-pud = ;
> + samsung,pin-drv = ;
> + };
>  };
>  
>  _1 {
> diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi 
> b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
> index 8f3a80430748..e1d293dbbe5d 100644
> --- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
> @@ -272,6 +272,10 @@
>   vdd_pll-supply = <_reg>;
>  };
>  
> + {
> + status = "okay";
> +};
> +
>  _0 {
>   status = "okay";
>   samsung,i2c-sda-delay = <100>;
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
> b/arch/arm/boot/dts/exynos5250.dtsi
> index 79c9c885613a..fbdc1d53a2ce 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -689,6 +689,19 @@
>   samsung,syscon-phandle = <_system_controller>;
>   };
>  
> + hdmicec: cec@101B {
> + compatible = "samsung,s5p-cec";
> + reg = <0x101B 0x200>;
> + interrupts = ;
> + clocks = < CLK_HDMI_CEC>;
> + clock-names = "hdmicec";
> + samsung,syscon-phandle = <_system_controller>;
> + hdmi-phandle = <>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_cec>;
> + status = "disabled";
> + };

What about Exynos5410? Is it applicable there as well? If yes, then this
could be added to exynos5.dtsi... although then clocks and pinctrl
should remain in SoC-specific DTSI. We're following such pattern in many
places but I am not sure if this more readable.

Beside that, looks fine to me.

Best regards,
Krzysztof

Re: [PATCH 6/7] [media] soc_camera: rcar_vin: use proper name for the R-Car SoC

2017-05-31 Thread Rob Herring

On Sun, May 28, 2017 at 11:30:49AM +0200, Wolfram Sang wrote:
> It is 'R-Car', not 'RCar'. No code or binding changes, only descriptive text.
> 
> Signed-off-by: Wolfram Sang 
> ---
> I suggest this trivial patch should be picked individually per susbsystem.
> 
>  Documentation/devicetree/bindings/media/rcar_vin.txt | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Acked-by: Rob Herring 

If you're going to change the subject, "dt-bindings: media: ..." is 
preferred.

Rob

hi

2017-05-31 Thread griestkrist

-- 
Please contact me in the my e-mail addres,(griestkrist1...@gmail.com)

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

2017-05-31 Thread Pavel Machek

Hi!

> > I agree, yes. I think the only way to solve this is to have a generic
> > EEPROM API that allows the camera sensor to read data from it. If
> 
> We have one already, and it's defined in Documentation/misc-devices/eeprom .
> 
> > another vendor uses a different type of EEPROM, the sensor driver would
> > remain the same, as it only reads data from the storage behind the
> > phandle, not caring about the details.
> > 
> > Same goes for the lens driver, and after thinking about it for awhile,
> > I'd say it makes most sense to allow referencing a v4l2_subdev device
> > through a phandle from another v4l2_subdev, and then offload certain
> > commands such as V4L2_CID_FOCUS_ABSOLUTE to the device that does the
> > actual work. Opinions?
> 
> There are different kinds of lens systems and I don't think the sensor
> drivers should be aware of them. The current approach is that the lens is a
> separate sub-device --- the intent of the patchset I posted was to document
> how the information on the related lens and eeprom components is conveyed to
> the software. There's one such driver in the mainline kernel, ad5820.
> 
> Unfortunately we don't right now have a good user space interface for
> telling which sensor a lens device is related to. The struct
> media_entity_desc does have a group_id field for grouping the sub-devices
> but that's hardly a good way to describe this.

Yeah, it would be good to get the corresponding patches to be merged
to v4l-utils...

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

[PATCH v6 1/1] [media] i2c: add support for OV13858 sensor

2017-05-31 Thread Hyungwoo Yang

This patch adds driver for Omnivision's ov13858
sensor, the driver supports following features:

- manual exposure/analog gain
- two link frequencies
- VBLANK support
- test pattern support
- media controller support
- runtime pm support
- supported resolutions
  + 4224x3136 at 30FPS
  + 2112x1568 at 30FPS(default) and 60FPS
  + 2112x1188 at 30FPS(default) and 60FPS
  + 1056x784 at 30FPS(default) and 60FPS

Signed-off-by: Hyungwoo Yang 
---
 drivers/media/i2c/Kconfig   |8 +
 drivers/media/i2c/Makefile  |1 +
 drivers/media/i2c/ov13858.c | 1737 +++
 3 files changed, 1746 insertions(+)
 create mode 100644 drivers/media/i2c/ov13858.c

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index fd181c9..f8c5cca 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -589,6 +589,14 @@ config VIDEO_OV9650
  This is a V4L2 sensor-level driver for the Omnivision
  OV9650 and OV9652 camera sensors.
 
+config VIDEO_OV13858
+   tristate "OmniVision OV13858 sensor support"
+   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV13858 camera.
+
 config VIDEO_VS6624
tristate "ST VS6624 sensor support"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 62323ec..3f4dc02 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
 obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
 obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
 obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
+obj-$(CONFIG_VIDEO_OV13858) += ov13858.o
 obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
 obj-$(CONFIG_VIDEO_MT9M111) += mt9m111.o
 obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
diff --git a/drivers/media/i2c/ov13858.c b/drivers/media/i2c/ov13858.c
new file mode 100644
index 000..5c12e7a
--- /dev/null
+++ b/drivers/media/i2c/ov13858.c
@@ -0,0 +1,1737 @@
+/*
+ * 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 
+#include 
+#include 
+#include 
+#include 
+
+#define OV13858_REG_VALUE_08BIT1
+#define OV13858_REG_VALUE_16BIT2
+#define OV13858_REG_VALUE_24BIT3
+
+#define OV13858_REG_MODE_SELECT0x0100
+#define OV13858_MODE_STANDBY   0x00
+#define OV13858_MODE_STREAMING 0x01
+
+#define OV13858_REG_SOFTWARE_RST   0x0103
+#define OV13858_SOFTWARE_RST   0x01
+
+/* PLL1 generates PCLK and MIPI_PHY_CLK */
+#define OV13858_REG_PLL1_CTRL_00x0300
+#define OV13858_REG_PLL1_CTRL_10x0301
+#define OV13858_REG_PLL1_CTRL_20x0302
+#define OV13858_REG_PLL1_CTRL_30x0303
+#define OV13858_REG_PLL1_CTRL_40x0304
+#define OV13858_REG_PLL1_CTRL_50x0305
+
+/* PLL2 generates DAC_CLK, SCLK and SRAM_CLK */
+#define OV13858_REG_PLL2_CTRL_B0x030b
+#define OV13858_REG_PLL2_CTRL_C0x030c
+#define OV13858_REG_PLL2_CTRL_D0x030d
+#define OV13858_REG_PLL2_CTRL_E0x030e
+#define OV13858_REG_PLL2_CTRL_F0x030f
+#define OV13858_REG_PLL2_CTRL_12   0x0312
+#define OV13858_REG_MIPI_SC_CTRL0  0x3016
+#define OV13858_REG_MIPI_SC_CTRL1  0x3022
+
+/* Chip ID */
+#define OV13858_REG_CHIP_ID0x300a
+#define OV13858_CHIP_ID0x00d855
+
+/* V_TIMING internal */
+#define OV13858_REG_VTS0x380e
+#define OV13858_VTS_30FPS  0x0c8e /* 30 fps */
+#define OV13858_VTS_60FPS  0x0648 /* 60 fps */
+#define OV13858_VTS_MAX0x7fff
+#define OV13858_VBLANK_MIN 56
+
+/* Exposure control */
+#define OV13858_REG_EXPOSURE   0x3500
+#define OV13858_EXPOSURE_MIN   4
+#define OV13858_EXPOSURE_MAX   (OV13858_VTS_MAX - 8)
+#define OV13858_EXPOSURE_STEP  1
+#define OV13858_EXPOSURE_DEFAULT   0x640
+
+/* Analog gain control */
+#define OV13858_REG_ANALOG_GAIN0x3508
+#define OV13858_ANA_GAIN_MIN   0
+#define OV13858_ANA_GAIN_MAX   0x1fff
+#define OV13858_ANA_GAIN_STEP  1
+#define OV13858_ANA_GAIN_DEFAULT   0x80
+
+/* Test Pattern Control */
+#define OV13858_REG_TEST_PATTERN   0x4503
+#define OV13858_TEST_PATTERN_ENABLEBIT(7)
+#define

RE: [PATCH v5 1/1] [media] i2c: add support for OV13858 sensor

2017-05-31 Thread Yang, Hyungwoo


Hi,

Thank you so much. I'll submit v6. 
 
-Original Message-
> From: Sakari Ailus [mailto:sakari.ai...@iki.fi] 
> Sent: Wednesday, May 31, 2017 2:25 AM
> To: Yang, Hyungwoo 
> Cc: linux-media@vger.kernel.org; sakari.ai...@linux.intel.com; Zheng, Jian Xu 
> ; tf...@chromium.org; Hsu, Cedric 
> 
> Subject: Re: [PATCH v5 1/1] [media] i2c: add support for OV13858 sensor
> 
> Hi Hyungwoo,
> 
> A few minor comments more. Then I think we're done.
> 
> On Wed, May 31, 2017 at 01:09:28AM -0700, Hyungwoo Yang wrote:
> > This patch adds driver for Omnivision's ov13858 sensor, the driver 
> > supports following features:
> > 
> > - manual exposure/analog gain
> > - two link frequencies
> > - VBLANK support
> > - test pattern support
> > - media controller support
> > - runtime pm support
> 
> Could you list the resolutions and frame rates the driver supports here as 
> well?
> 

Ack.

> > 
> > Signed-off-by: Hyungwoo Yang 
> > ---
> >  drivers/media/i2c/Kconfig   |8 +
> >  drivers/media/i2c/Makefile  |1 +
> >  drivers/media/i2c/ov13858.c | 1739 
> > +++
> >  3 files changed, 1748 insertions(+)
> >  create mode 100644 drivers/media/i2c/ov13858.c
> > 
> > diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig 
> > index fd181c9..f8c5cca 100644
> > --- a/drivers/media/i2c/Kconfig
> > +++ b/drivers/media/i2c/Kconfig
> > @@ -589,6 +589,14 @@ config VIDEO_OV9650
> >   This is a V4L2 sensor-level driver for the Omnivision
> >   OV9650 and OV9652 camera sensors.
> >  
> > +config VIDEO_OV13858
> > +   tristate "OmniVision OV13858 sensor support"
> > +   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> > +   depends on MEDIA_CAMERA_SUPPORT
> > +   ---help---
> > + This is a Video4Linux2 sensor-level driver for the OmniVision
> > + OV13858 camera.
> > +
> >  config VIDEO_VS6624
> > tristate "ST VS6624 sensor support"
> > depends on VIDEO_V4L2 && I2C
> > diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile 
> > index 62323ec..3f4dc02 100644
> > --- a/drivers/media/i2c/Makefile
> > +++ b/drivers/media/i2c/Makefile
> > @@ -63,6 +63,7 @@ obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
> >  obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
> >  obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
> >  obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
> > +obj-$(CONFIG_VIDEO_OV13858) += ov13858.o
> >  obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
> >  obj-$(CONFIG_VIDEO_MT9M111) += mt9m111.o
> >  obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o diff --git 
> > a/drivers/media/i2c/ov13858.c b/drivers/media/i2c/ov13858.c new file 
> > mode 100644 index 000..bff865a
> > --- /dev/null
> > +++ b/drivers/media/i2c/ov13858.c
> > @@ -0,0 +1,1739 @@
> > +/*
> > + * 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 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define OV13858_REG_VALUE_08BIT1
> > +#define OV13858_REG_VALUE_16BIT2
> > +#define OV13858_REG_VALUE_24BIT3
> > +
> > +#define OV13858_REG_MODE_SELECT0x0100
> > +#define OV13858_MODE_STANDBY   0x00
> > +#define OV13858_MODE_STREAMING 0x01
> > +
> > +#define OV13858_REG_SOFTWARE_RST   0x0103
> > +#define OV13858_SOFTWARE_RST   0x01
> > +
> > +/* PLL1 generates PCLK and MIPI_PHY_CLK */
> > +#define OV13858_REG_PLL1_CTRL_00x0300
> > +#define OV13858_REG_PLL1_CTRL_10x0301
> > +#define OV13858_REG_PLL1_CTRL_20x0302
> > +#define OV13858_REG_PLL1_CTRL_30x0303
> > +#define OV13858_REG_PLL1_CTRL_40x0304
> > +#define OV13858_REG_PLL1_CTRL_50x0305
> > +
> > +/* PLL2 generates DAC_CLK, SCLK and SRAM_CLK */
> > +#define OV13858_REG_PLL2_CTRL_B0x030b
> > +#define OV13858_REG_PLL2_CTRL_C0x030c
> > +#define OV13858_REG_PLL2_CTRL_D0x030d
> > +#define OV13858_REG_PLL2_CTRL_E0x030e
> > +#define OV13858_REG_PLL2_CTRL_F0x030f
> > +#define OV13858_REG_PLL2_CTRL_12   0x0312
> > +#define OV13858_REG_MIPI_SC_CTRL0  0x3016
> > +#define OV13858_REG_MIPI_SC_CTRL1  0x3022
> > +
> > +/* Chip ID */
> > +#define OV13858_REG_CHIP_ID0x300a
> > +#define OV13858_CHIP_ID0x00d855
> > +
> > +/* V_TIMING internal */
> > +#define OV13858_REG_VTS0x380e
> >

[PATCH 2/3] vb2: Move buffer cache synchronisation to prepare from queue

The buffer cache should be synchronised in buffer preparation, not when
the buffer is queued to the device. Fix this.

Mmap buffers do not need cache synchronisation since they are always
coherent.

Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
 drivers/media/v4l2-core/videobuf2-core.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 9f3ce3b..3107e21 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1227,23 +1227,19 @@ static int __prepare_dmabuf(struct vb2_buffer *vb, 
const void *pb)
 static void __enqueue_in_driver(struct vb2_buffer *vb)
 {
struct vb2_queue *q = vb->vb2_queue;
-   unsigned int plane;
 
vb->state = VB2_BUF_STATE_ACTIVE;
atomic_inc(>owned_by_drv_count);
 
trace_vb2_buf_queue(q, vb);
 
-   /* sync buffers */
-   for (plane = 0; plane < vb->num_planes; ++plane)
-   call_void_memop(vb, prepare, vb->planes[plane].mem_priv);
-
call_void_vb_qop(vb, buf_queue, vb);
 }
 
 static int __buf_prepare(struct vb2_buffer *vb, const void *pb)
 {
struct vb2_queue *q = vb->vb2_queue;
+   unsigned int plane;
int ret;
 
if (q->error) {
@@ -1268,11 +1264,19 @@ static int __buf_prepare(struct vb2_buffer *vb, const 
void *pb)
ret = -EINVAL;
}
 
-   if (ret)
+   if (ret) {
dprintk(1, "buffer preparation failed: %d\n", ret);
-   vb->state = ret ? VB2_BUF_STATE_DEQUEUED : VB2_BUF_STATE_PREPARED;
+   vb->state = VB2_BUF_STATE_DEQUEUED;
+   return ret;
+   }
 
-   return ret;
+   /* sync buffers */
+   for (plane = 0; plane < vb->num_planes; ++plane)
+   call_void_memop(vb, prepare, vb->planes[plane].mem_priv);
+
+   vb->state = VB2_BUF_STATE_PREPARED;
+
+   return 0;
 }
 
 int vb2_core_prepare_buf(struct vb2_queue *q, unsigned int index, void *pb)
-- 
2.7.4

[PATCH 3/3] vb2: Move cache synchronisation from buffer done to dqbuf handler

The cache synchronisation may be a time consuming operation and thus not
best performed in an interrupt which is a typical context for
vb2_buffer_done() calls. This may consume up to tens of ms on some
machines, depending on the buffer size.

Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
 drivers/media/v4l2-core/videobuf2-core.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 3107e21..ce00f0b 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -889,7 +889,6 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum 
vb2_buffer_state state)
 {
struct vb2_queue *q = vb->vb2_queue;
unsigned long flags;
-   unsigned int plane;
 
if (WARN_ON(vb->state != VB2_BUF_STATE_ACTIVE))
return;
@@ -910,10 +909,6 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum 
vb2_buffer_state state)
dprintk(4, "done processing on buffer %d, state: %d\n",
vb->index, state);
 
-   /* sync buffers */
-   for (plane = 0; plane < vb->num_planes; ++plane)
-   call_void_memop(vb, finish, vb->planes[plane].mem_priv);
-
spin_lock_irqsave(>done_lock, flags);
if (state == VB2_BUF_STATE_QUEUED ||
state == VB2_BUF_STATE_REQUEUEING) {
@@ -1573,6 +1568,10 @@ static void __vb2_dqbuf(struct vb2_buffer *vb)
 
vb->state = VB2_BUF_STATE_DEQUEUED;
 
+   /* sync buffers */
+   for (i = 0; i < vb->num_planes; ++i)
+   call_void_memop(vb, finish, vb->planes[i].mem_priv);
+
/* unmap DMABUF buffer */
if (q->memory == VB2_MEMORY_DMABUF)
for (i = 0; i < vb->num_planes; ++i) {
-- 
2.7.4

[PATCH 0/3] Prepare for cache coherency changes in videobuf2

Hello everyone,

I split off these three patches from another set ("vb2: Handle user cache
hints, allow drivers to choose cache coherency"):



The reason is that the rest of the set requires further work in order to
be mergeable. For now, just three patches. The functional change will be
moving the cache operations where they should have been all along.

-- 
Kind regards,
Sakari

[PATCH 1/3] vb2: Rename confusingly named internal buffer preparation functions

Rename __qbuf_*() functions which are specific to a buffer type as
__prepare_*() which matches with what they do. The naming was there for
historical reasons; the purpose of the functions was changed without
renaming them.

Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
Reviewed-by: Laurent Pinchart 
---
 drivers/media/v4l2-core/videobuf2-core.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index c0175ea..9f3ce3b 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -956,9 +956,9 @@ void vb2_discard_done(struct vb2_queue *q)
 EXPORT_SYMBOL_GPL(vb2_discard_done);
 
 /**
- * __qbuf_mmap() - handle qbuf of an MMAP buffer
+ * __prepare_mmap() - prepare an MMAP buffer
  */
-static int __qbuf_mmap(struct vb2_buffer *vb, const void *pb)
+static int __prepare_mmap(struct vb2_buffer *vb, const void *pb)
 {
int ret = 0;
 
@@ -969,9 +969,9 @@ static int __qbuf_mmap(struct vb2_buffer *vb, const void 
*pb)
 }
 
 /**
- * __qbuf_userptr() - handle qbuf of a USERPTR buffer
+ * __prepare_userptr() - prepare a USERPTR buffer
  */
-static int __qbuf_userptr(struct vb2_buffer *vb, const void *pb)
+static int __prepare_userptr(struct vb2_buffer *vb, const void *pb)
 {
struct vb2_plane planes[VB2_MAX_PLANES];
struct vb2_queue *q = vb->vb2_queue;
@@ -1087,9 +1087,9 @@ static int __qbuf_userptr(struct vb2_buffer *vb, const 
void *pb)
 }
 
 /**
- * __qbuf_dmabuf() - handle qbuf of a DMABUF buffer
+ * __prepare_dmabuf() - prepare a DMABUF buffer
  */
-static int __qbuf_dmabuf(struct vb2_buffer *vb, const void *pb)
+static int __prepare_dmabuf(struct vb2_buffer *vb, const void *pb)
 {
struct vb2_plane planes[VB2_MAX_PLANES];
struct vb2_queue *q = vb->vb2_queue;
@@ -1255,13 +1255,13 @@ static int __buf_prepare(struct vb2_buffer *vb, const 
void *pb)
 
switch (q->memory) {
case VB2_MEMORY_MMAP:
-   ret = __qbuf_mmap(vb, pb);
+   ret = __prepare_mmap(vb, pb);
break;
case VB2_MEMORY_USERPTR:
-   ret = __qbuf_userptr(vb, pb);
+   ret = __prepare_userptr(vb, pb);
break;
case VB2_MEMORY_DMABUF:
-   ret = __qbuf_dmabuf(vb, pb);
+   ret = __prepare_dmabuf(vb, pb);
break;
default:
WARN(1, "Invalid queue type\n");
-- 
2.7.4

[PATCH v7] cec: add STM32 cec driver

This patch add cec driver for STM32 platforms.
cec hardware block isn't not always used with hdmi so
cec notifier is not implemented. That will be done later
when STM32 DSI driver will be available.

Driver compliance has been tested with cec-ctl and cec-compliance
tools.

Signed-off-by: Benjamin Gaignard 
Signed-off-by: Yannick Fertre 
---
version 7:
- only set CEC_MODE_MONITOR_ALL and remove useless adap_monitor_all_enable 
callback
- caps is now the first item in stm32_cec_probe

 drivers/media/platform/Kconfig   |  12 +
 drivers/media/platform/Makefile  |   2 +
 drivers/media/platform/stm32/Makefile|   1 +
 drivers/media/platform/stm32/stm32-cec.c | 362 +++
 4 files changed, 377 insertions(+)
 create mode 100644 drivers/media/platform/stm32/Makefile
 create mode 100644 drivers/media/platform/stm32/stm32-cec.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 041cb80..52280bc 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -521,4 +521,16 @@ config VIDEO_STI_HDMI_CEC
  CEC bus is present in the HDMI connector and enables communication
  between compatible devices.
 
+config VIDEO_STM32_HDMI_CEC
+   tristate "STMicroelectronics STM32 HDMI CEC driver"
+   depends on ARCH_STM32 || COMPILE_TEST
+   select REGMAP
+   select REGMAP_MMIO
+   select CEC_CORE
+   ---help---
+ This is a driver for STM32 interface. It uses the
+ generic CEC framework interface.
+ CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
 endif #CEC_PLATFORM_DRIVERS
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 63303d6..7cd9965 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -44,6 +44,8 @@ obj-$(CONFIG_VIDEO_STI_HDMI_CEC)  += sti/cec/
 
 obj-$(CONFIG_VIDEO_STI_DELTA)  += sti/delta/
 
+obj-$(CONFIG_VIDEO_STM32_HDMI_CEC) += stm32/
+
 obj-$(CONFIG_BLACKFIN)  += blackfin/
 
 obj-$(CONFIG_ARCH_DAVINCI) += davinci/
diff --git a/drivers/media/platform/stm32/Makefile 
b/drivers/media/platform/stm32/Makefile
new file mode 100644
index 000..632b04c
--- /dev/null
+++ b/drivers/media/platform/stm32/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_STM32_HDMI_CEC) += stm32-cec.o
diff --git a/drivers/media/platform/stm32/stm32-cec.c 
b/drivers/media/platform/stm32/stm32-cec.c
new file mode 100644
index 000..9ab896b
--- /dev/null
+++ b/drivers/media/platform/stm32/stm32-cec.c
@@ -0,0 +1,362 @@
+/*
+ * STM32 CEC driver
+ * Copyright (C) STMicroelectronics SA 2017
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define CEC_NAME   "stm32-cec"
+
+/* CEC registers  */
+#define CEC_CR 0x /* Control Register */
+#define CEC_CFGR   0x0004 /* ConFiGuration Register */
+#define CEC_TXDR   0x0008 /* Rx data Register */
+#define CEC_RXDR   0x000C /* Rx data Register */
+#define CEC_ISR0x0010 /* Interrupt and status Register */
+#define CEC_IER0x0014 /* Interrupt enable Register */
+
+#define TXEOM  BIT(2)
+#define TXSOM  BIT(1)
+#define CECEN  BIT(0)
+
+#define LSTN   BIT(31)
+#define OARGENMASK(30, 16)
+#define SFTOP  BIT(8)
+#define BRDNOGEN   BIT(7)
+#define LBPEGENBIT(6)
+#define BREGEN BIT(5)
+#define BRESTP BIT(4)
+#define RXTOL  BIT(3)
+#define SFTGENMASK(2, 0)
+#define FULL_CFG   (LSTN | SFTOP | BRDNOGEN | LBPEGEN | BREGEN | BRESTP \
+| RXTOL)
+
+#define TXACKE BIT(12)
+#define TXERR  BIT(11)
+#define TXUDR  BIT(10)
+#define TXEND  BIT(9)
+#define TXBR   BIT(8)
+#define ARBLST BIT(7)
+#define RXACKE BIT(6)
+#define RXOVR  BIT(2)
+#define RXEND  BIT(1)
+#define RXBR   BIT(0)
+
+#define ALL_TX_IT  (TXEND | TXBR | TXACKE | TXERR | TXUDR | ARBLST)
+#define ALL_RX_IT  (RXEND | RXBR | RXACKE | RXOVR)
+
+struct stm32_cec {
+   struct cec_adapter  *adap;
+   struct device   *dev;
+   struct clk  *clk_cec;
+   struct clk  *clk_hdmi_cec;
+   struct reset_control*rstc;
+   struct regmap   *regmap;
+   int irq;
+   u32 irq_status;
+   struct cec_msg  rx_msg;
+   struct cec_msg  tx_msg;
+   int tx_cnt;

Re: [PATCH RFC] v4l2-core: Use kvmalloc() for potentially big allocations

Hi Tomasz,

On Wed, May 31, 2017 at 09:46:05PM +0900, Tomasz Figa wrote:
> On Wed, May 31, 2017 at 9:09 PM, Marek Szyprowski
>  wrote:
> > Hi Tomasz,
> >
> >
> > On 2017-05-31 08:58, Tomasz Figa wrote:
> >>
> >> There are multiple places where arrays or otherwise variable sized
> >> buffer are allocated through V4L2 core code, including things like
> >> controls, memory pages, staging buffers for ioctls and so on. Such
> >> allocations can potentially require an order > 0 allocation from the
> >> page allocator, which is not guaranteed to be fulfilled and is likely to
> >> fail on a system with severe memory fragmentation (e.g. a system with
> >> very long uptime).
> >>
> >> Since the memory being allocated is intended to be used by the CPU
> >> exclusively, we can consider using vmalloc() as a fallback and this is
> >> exactly what the recently merged kvmalloc() helpers do. A kmalloc() call
> >> is still attempted, even for order > 0 allocations, but it is done
> >> with __GFP_NORETRY and __GFP_NOWARN, with expectation of failing if
> >> requested memory is not available instantly. Only then the vmalloc()
> >> fallback is used. This should give us fast and more reliable allocations
> >> even on systems with higher memory pressure and/or more fragmentation,
> >> while still retaining the same performance level on systems not
> >> suffering from such conditions.
> >>
> >> While at it, replace explicit array size calculations on changed
> >> allocations with kvmalloc_array().
> >>
> >> Signed-off-by: Tomasz Figa 
> >> ---
> >>   drivers/media/v4l2-core/v4l2-async.c   |  4 ++--
> >>   drivers/media/v4l2-core/v4l2-ctrls.c   | 25
> >> +
> >>   drivers/media/v4l2-core/v4l2-event.c   |  8 +---
> >>   drivers/media/v4l2-core/v4l2-ioctl.c   |  6 +++---
> >>   drivers/media/v4l2-core/v4l2-subdev.c  |  7 ---
> >>   drivers/media/v4l2-core/videobuf2-dma-sg.c |  8 
> >
> >
> > For vb2:
> > Acked-by: Marek Szyprowski 
> 
> Thanks!
> 
> >
> > There are also a few vmalloc calls in old videobuf (v1) framework, which
> > might be converted to kvmalloc if you have a few spare minutes to take
> > a look.
> 
> I was intending to convert those as well, but on the other hand I
> concluded that it's some very old code, which might be difficult to
> test and likely to introduce some long undiscovered regressions. If
> it's desired to update those as well, I can include those changes in
> the non-RFC version.

I think it's better to leave videobuf1 as-is. I'd rather like to see it
removed instead.

Acked-by: Sakari Ailus 

-- 
Regards,

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

Re: [PATCH v6 2/2] cec: add STM32 cec driver

On 05/31/17 14:13, Benjamin Gaignard wrote:
> This patch add cec driver for STM32 platforms.
> cec hardware block isn't not always used with hdmi so
> cec notifier is not implemented. That will be done later
> when STM32 DSI driver will be available.
> 
> Driver compliance has been tested with cec-ctl and cec-compliance
> tools.
> 
> Signed-off-by: Benjamin Gaignard 
> Signed-off-by: Yannick Fertre 
> ---
> version 6:
> - fix duplicate constant in define 
> - add monitor mode
> 
>  drivers/media/platform/Kconfig   |  12 +
>  drivers/media/platform/Makefile  |   2 +
>  drivers/media/platform/stm32/Makefile|   1 +
>  drivers/media/platform/stm32/stm32-cec.c | 369 
> +++
>  4 files changed, 384 insertions(+)
>  create mode 100644 drivers/media/platform/stm32/Makefile
>  create mode 100644 drivers/media/platform/stm32/stm32-cec.c
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 041cb80..52280bc 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -521,4 +521,16 @@ config VIDEO_STI_HDMI_CEC
>   CEC bus is present in the HDMI connector and enables communication
>   between compatible devices.
>  
> +config VIDEO_STM32_HDMI_CEC
> +   tristate "STMicroelectronics STM32 HDMI CEC driver"
> +   depends on ARCH_STM32 || COMPILE_TEST
> +   select REGMAP
> +   select REGMAP_MMIO
> +   select CEC_CORE
> +   ---help---
> + This is a driver for STM32 interface. It uses the
> + generic CEC framework interface.
> + CEC bus is present in the HDMI connector and enables communication
> + between compatible devices.
> +
>  endif #CEC_PLATFORM_DRIVERS
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 63303d6..7cd9965 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -44,6 +44,8 @@ obj-$(CONFIG_VIDEO_STI_HDMI_CEC)+= sti/cec/
>  
>  obj-$(CONFIG_VIDEO_STI_DELTA)+= sti/delta/
>  
> +obj-$(CONFIG_VIDEO_STM32_HDMI_CEC)   += stm32/
> +
>  obj-$(CONFIG_BLACKFIN)  += blackfin/
>  
>  obj-$(CONFIG_ARCH_DAVINCI)   += davinci/
> diff --git a/drivers/media/platform/stm32/Makefile 
> b/drivers/media/platform/stm32/Makefile
> new file mode 100644
> index 000..632b04c
> --- /dev/null
> +++ b/drivers/media/platform/stm32/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_VIDEO_STM32_HDMI_CEC) += stm32-cec.o
> diff --git a/drivers/media/platform/stm32/stm32-cec.c 
> b/drivers/media/platform/stm32/stm32-cec.c
> new file mode 100644
> index 000..f7a8fd9
> --- /dev/null
> +++ b/drivers/media/platform/stm32/stm32-cec.c
> @@ -0,0 +1,369 @@
> +/*
> + * STM32 CEC driver
> + * Copyright (C) STMicroelectronics SA 2017
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#define CEC_NAME "stm32-cec"
> +
> +/* CEC registers  */
> +#define CEC_CR   0x /* Control Register */
> +#define CEC_CFGR 0x0004 /* ConFiGuration Register */
> +#define CEC_TXDR 0x0008 /* Rx data Register */
> +#define CEC_RXDR 0x000C /* Rx data Register */
> +#define CEC_ISR  0x0010 /* Interrupt and status Register */
> +#define CEC_IER  0x0014 /* Interrupt enable Register */
> +
> +#define TXEOMBIT(2)
> +#define TXSOMBIT(1)
> +#define CECENBIT(0)
> +
> +#define LSTN BIT(31)
> +#define OAR  GENMASK(30, 16)
> +#define SFTOPBIT(8)
> +#define BRDNOGEN BIT(7)
> +#define LBPEGEN  BIT(6)
> +#define BREGEN   BIT(5)
> +#define BRESTP   BIT(4)
> +#define RXTOLBIT(3)
> +#define SFT  GENMASK(2, 0)
> +#define FULL_CFG (LSTN | SFTOP | BRDNOGEN | LBPEGEN | BREGEN | BRESTP \
> +  | RXTOL)
> +
> +#define TXACKE   BIT(12)
> +#define TXERRBIT(11)
> +#define TXUDRBIT(10)
> +#define TXENDBIT(9)
> +#define TXBR BIT(8)
> +#define ARBLST   BIT(7)
> +#define RXACKE   BIT(6)
> +#define RXOVRBIT(2)
> +#define RXENDBIT(1)
> +#define RXBR BIT(0)
> +
> +#define ALL_TX_IT(TXEND | TXBR | TXACKE | TXERR | TXUDR | ARBLST)
> +#define ALL_RX_IT(RXEND | RXBR | RXACKE | RXOVR)
> +
> +struct stm32_cec {
> + struct cec_adapter  *adap;
> + struct device   *dev;
> + struct clk  *clk_cec;
> + struct clk

Re: [PATCH v9 3/4] arm: dts: mt2701: Add node for Mediatek JPEG Decoder

2017-05-31 Thread Matthias Brugger




On 10/05/17 13:02, Matthias Brugger wrote:



On 14/12/16 09:04, Rick Chang wrote:

Signed-off-by: Rick Chang 
Signed-off-by: Minghsiu Tsai 
---
This patch depends on:
   CCF "Add clock support for Mediatek MT2701"[1]
   iommu and smi "Add the dtsi node of iommu and smi for mt2701"[2]

[1] 
http://lists.infradead.org/pipermail/linux-mediatek/2016-October/007271.html 


[2] https://patchwork.kernel.org/patch/9164013/


Now queued for v4.12-next/dts32

Thanks and sorry for the delay.
Matthias



I realized that a long time ago I made a mistake when taking:
f3cba0f49c7c ("ARM: dts: mt2701: add iommu/smi dtsi node for mt2701")

as I forgot to include dt-bindings/memory/mt2701-larb-port.h

I fixed this now in v4.12-next/dts32

Sorry for that.

Regards,
Matthias


---
  arch/arm/boot/dts/mt2701.dtsi | 14 ++
  1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/mt2701.dtsi 
b/arch/arm/boot/dts/mt2701.dtsi

index 8f13c70..4dd5048 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -298,6 +298,20 @@
  power-domains = < MT2701_POWER_DOMAIN_ISP>;
  };
+jpegdec: jpegdec@15004000 {
+compatible = "mediatek,mt2701-jpgdec";
+reg = <0 0x15004000 0 0x1000>;
+interrupts = ;
+clocks =  < CLK_IMG_JPGDEC_SMI>,
+  < CLK_IMG_JPGDEC>;
+clock-names = "jpgdec-smi",
+  "jpgdec";
+power-domains = < MT2701_POWER_DOMAIN_ISP>;
+mediatek,larb = <>;
+iommus = < MT2701_M4U_PORT_JPGDEC_WDMA>,
+ < MT2701_M4U_PORT_JPGDEC_BSDMA>;
+};
+
  vdecsys: syscon@1600 {
  compatible = "mediatek,mt2701-vdecsys", "syscon";
  reg = <0 0x1600 0 0x1000>;

Re: [PATCH] ARM: dts: exynos: Add HDMI CEC device to Exynos5 SoC family

On 05/31/17 14:04, Marek Szyprowski wrote:
> Hi Hans,
> 
> On 2017-05-31 13:17, Hans Verkuil wrote:
>> On 05/31/17 13:00, Marek Szyprowski wrote:
>>> Exynos5250 and Exynos542x SoCs have the same CEC hardware module as
>>> Exynos4 SoC series, so enable support for it using the same compatible
>>> string.
>>>
>>> Tested on Odroid XU3 (Exynos5422) and Google Snow (Exynos5250) boards.
>> Thanks!
>>
>> Do you know if the CEC block is always on for these devices or only if there
>> is a hotplug signal? That was a problem with the exynos4 odroid.
> 
> Odroid XU3 has exactly same wiring between SoC & HDMI connector (via 
> IP4791CZ12
> chip) as Odroid U3, so I expect the same issues.
> 
> I don't have schematic for Google Snow board, so I have no idea how it works
> there.
> 
>> I have made a patch (not posted yet) to signal this in the device tree and
>> added a CEC capability to signal this to the user.
>>
>> This capability will be added to 4.13 (see my patch 'cec: add 
>> CEC_CAP_NEEDS_HPD'
>> from May 25th) since the DisplayPort CEC tunneling feature needs it as well.
>>
>> It's easy to test: don't connect an HDMI cable and run:
>>
>> cec-ctl --playback
>> cec-ctl -t0 --image-view-on
>>
>> If this returns with a NACK error, then it is OK. If you get a kernel message
>> that the transmit timed out, then you need this capability since CEC is 
>> disabled
>> without HPD.
> 
> I've checked those commands, but on all tested boards (Odroid U3+, 
> Odroid XU3 and
> Google Snow) I get the following message:
> 
> Transmit from Unregistered to TV (255 to 0):
> CEC_MSG_IMAGE_VIEW_ON (0x04)
>  Sequence: 19 Tx Timestamp: 175.935s
>  Tx, Error (1), Max Retries
> 
> I have never got a timeout message from the kernel. Do I need to enable 
> some kind
> of CEC debugs?

Ah, that's right. CEC works, but the level shifter drops the CEC signal
when there is no HPD. So this is actually quite hard to test.

The easiest is to get a Pulse-Eight USB CEC adapter since then you can
connect the odroid to the Pulse-Eight without connecting that to a TV
in turn. Sending a CEC command would show up with the Pulse-Eight if CEC
works without HPD.

Regards,

Hans

Re: [PATCH RFC] v4l2-core: Use kvmalloc() for potentially big allocations

2017-05-31 Thread Tomasz Figa

On Wed, May 31, 2017 at 9:09 PM, Marek Szyprowski
 wrote:
> Hi Tomasz,
>
>
> On 2017-05-31 08:58, Tomasz Figa wrote:
>>
>> There are multiple places where arrays or otherwise variable sized
>> buffer are allocated through V4L2 core code, including things like
>> controls, memory pages, staging buffers for ioctls and so on. Such
>> allocations can potentially require an order > 0 allocation from the
>> page allocator, which is not guaranteed to be fulfilled and is likely to
>> fail on a system with severe memory fragmentation (e.g. a system with
>> very long uptime).
>>
>> Since the memory being allocated is intended to be used by the CPU
>> exclusively, we can consider using vmalloc() as a fallback and this is
>> exactly what the recently merged kvmalloc() helpers do. A kmalloc() call
>> is still attempted, even for order > 0 allocations, but it is done
>> with __GFP_NORETRY and __GFP_NOWARN, with expectation of failing if
>> requested memory is not available instantly. Only then the vmalloc()
>> fallback is used. This should give us fast and more reliable allocations
>> even on systems with higher memory pressure and/or more fragmentation,
>> while still retaining the same performance level on systems not
>> suffering from such conditions.
>>
>> While at it, replace explicit array size calculations on changed
>> allocations with kvmalloc_array().
>>
>> Signed-off-by: Tomasz Figa 
>> ---
>>   drivers/media/v4l2-core/v4l2-async.c   |  4 ++--
>>   drivers/media/v4l2-core/v4l2-ctrls.c   | 25
>> +
>>   drivers/media/v4l2-core/v4l2-event.c   |  8 +---
>>   drivers/media/v4l2-core/v4l2-ioctl.c   |  6 +++---
>>   drivers/media/v4l2-core/v4l2-subdev.c  |  7 ---
>>   drivers/media/v4l2-core/videobuf2-dma-sg.c |  8 
>
>
> For vb2:
> Acked-by: Marek Szyprowski 

Thanks!

>
> There are also a few vmalloc calls in old videobuf (v1) framework, which
> might be converted to kvmalloc if you have a few spare minutes to take
> a look.

I was intending to convert those as well, but on the other hand I
concluded that it's some very old code, which might be difficult to
test and likely to introduce some long undiscovered regressions. If
it's desired to update those as well, I can include those changes in
the non-RFC version.

Also FYI, this is more about converting k[mzc]alloc(_array)? into
kvmalloc, so that we avoid costly high order allocations. Already
existing vmalloc calls should be fine IMHO.

>
>
>>   6 files changed, 31 insertions(+), 27 deletions(-)
>>
>> diff --git a/drivers/media/v4l2-core/v4l2-async.c
>> b/drivers/media/v4l2-core/v4l2-async.c
>> index 96cc733f35ef..2d2d9f1f8831 100644
>> --- a/drivers/media/v4l2-core/v4l2-async.c
>> +++ b/drivers/media/v4l2-core/v4l2-async.c
>> @@ -204,7 +204,7 @@ void v4l2_async_notifier_unregister(struct
>> v4l2_async_notifier *notifier)
>> if (!notifier->v4l2_dev)
>> return;
>>   - dev = kmalloc_array(n_subdev, sizeof(*dev), GFP_KERNEL);
>> +   dev = kvmalloc_array(n_subdev, sizeof(*dev), GFP_KERNEL);
>> if (!dev) {
>> dev_err(notifier->v4l2_dev->dev,
>> "Failed to allocate device cache!\n");
>> @@ -260,7 +260,7 @@ void v4l2_async_notifier_unregister(struct
>> v4l2_async_notifier *notifier)
>> }
>> put_device(d);
>> }
>> -   kfree(dev);
>> +   kvfree(dev);
>> notifier->v4l2_dev = NULL;
>>   diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
>> b/drivers/media/v4l2-core/v4l2-ctrls.c
>> index ec42872d11cf..88025527c67e 100644
>> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
>> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
>> @@ -1745,8 +1745,9 @@ int v4l2_ctrl_handler_init_class(struct
>> v4l2_ctrl_handler *hdl,
>> INIT_LIST_HEAD(>ctrls);
>> INIT_LIST_HEAD(>ctrl_refs);
>> hdl->nr_of_buckets = 1 + nr_of_controls_hint / 8;
>> -   hdl->buckets = kcalloc(hdl->nr_of_buckets,
>> sizeof(hdl->buckets[0]),
>> -  GFP_KERNEL);
>> +   hdl->buckets = kvmalloc_array(hdl->nr_of_buckets,
>> + sizeof(hdl->buckets[0]),
>> + GFP_KERNEL | __GFP_ZERO);
>> hdl->error = hdl->buckets ? 0 : -ENOMEM;
>> return hdl->error;
>>   }
>> @@ -1773,9 +1774,9 @@ void v4l2_ctrl_handler_free(struct v4l2_ctrl_handler
>> *hdl)
>> list_del(>node);
>> list_for_each_entry_safe(sev, next_sev, >ev_subs,
>> node)
>> list_del(>node);
>> -   kfree(ctrl);
>> +   kvfree(ctrl);
>> }
>> -   kfree(hdl->buckets);
>> +   kvfree(hdl->buckets);
>> hdl->buckets = NULL;
>> hdl->cached = NULL;
>> hdl->error = 0;
>> @@ -2022,7 +2023,7 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
>> v4l2_ctrl_handler *hdl,
>>

Re: [PATCH 00/19] cxd2841er/ddbridge: support Sony CXD28xx hardware

Hi Daniel,

I have ack'ed all patches related to cxd2841er. Please check am i
missing something ?

I see some good flags (CXD2841ER_NO_WAIT_LOCK and
CXD2841ER_EARLY_TUNE). I should check it for our boards too :)

2017-05-30 10:31 GMT-04:00 Abylay Ospan :
> Hi Daniel,
>
> I have checked your patches. Basically it looks good:
>  * compilation is clean (no warnings)
>  * Our card (NetUP Universal DVB Rev 1.4) works fine with this patches
>  * All patches looks reasonable and don't break other cards
>  * All patches has good comments
>
> I will send ack's to ML.
>
> Thanks for your work !
>
> 2017-05-28 17:47 GMT-04:00 Daniel Scheller :
>>
>> Am Sun,  9 Apr 2017 21:38:09 +0200
>> schrieb Daniel Scheller :
>>
>>
>> > Important note: This series depends on the stv0367/ddbridge series
>> > posted earlier (patches 12 [1] and 13 [2], depending on the I2C
>> > functions and the TDA18212 attach function).
>> >
>> > This series improves the cxd2841er demodulator driver and adds some
>> > bits to make it more versatile to be used in more scenarios. Also,
>> > the ddbridge code is updated to recognize all hardware (PCIe
>> > cards/bridges and DuoFlex modules) with Sony CXD28xx tuners,
>> > including the newly introduced MaxA8 eight-tuner C2T2 cards.
>> >
>> > The series has been tested (together with the STV0367 series) on a
>> > wide variety of cards, including CineCTv7, DuoFlex C(2)T2 modules and
>> > MaxA8 cards without any issues. Testing was done with TVHeadend, VDR
>> > and MythTV.
>> >
>> > Note that the i2c_gate_ctrl() flag is needed in this series aswell
>> > since the i2c_gate_ctrl function needs to be remapped and mutex_lock
>> > protected for the same reasons as in the STV0367 series.
>> >
>> > Besides printk() warnings, checkpatch.pl doesn't complain.
>>
>> Ping on this series aswell.
>>
>> Abylay, would you please mind taking a look at the cxd2841er changes
>> and check if you're fine with them?
>>
>> Regards,
>> Daniel
>
>
>
>
> --
> Abylay Ospan,
> NetUP Inc.
> http://www.netup.tv



-- 
Abylay Ospan,
NetUP Inc.
http://www.netup.tv

Re: [PATCH 17/19] [media] ddbridge: add I2C functions, add XO2 module support

not related to cxd2841er. I'm skipping this ...
same for rest of the patches (18/19, 19/19).

2017-04-09 15:38 GMT-04:00 Daniel Scheller :
> From: Daniel Scheller 
>
> Some Flex modules (mostly with anyof C/C2/T/T2 demods based on the Sony
> CXD28xxER series) are equipped with an interface named XO2 (which
> appears to be the Lattice MachXO2). Add functionality to detect such
> links and initialise them, so any tuner module with such an interface can
> be used.
>
> This also adds dummy detection for any possible connected module, telling
> the user it isn't supported at this very moment.
>
> Also adds i2c_io(), i2c_write() and i2c_write_reg(), all required for the
> XO2 handling functionality.
>
> Signed-off-by: Daniel Scheller 
> ---
>  drivers/media/pci/ddbridge/ddbridge-core.c | 147 
> +
>  drivers/media/pci/ddbridge/ddbridge.h  |  11 +++
>  2 files changed, 158 insertions(+)
>
> diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c 
> b/drivers/media/pci/ddbridge/ddbridge-core.c
> index 6b49fa9..ab88fcf 100644
> --- a/drivers/media/pci/ddbridge/ddbridge-core.c
> +++ b/drivers/media/pci/ddbridge/ddbridge-core.c
> @@ -43,6 +43,10 @@
>  #include "stv0367_priv.h"
>  #include "tda18212.h"
>
> +static int xo2_speed = 2;
> +module_param(xo2_speed, int, 0444);
> +MODULE_PARM_DESC(xo2_speed, "default transfer speed for xo2 based duoflex, 
> 0=55,1=75,2=90,3=104 MBit/s, default=2, use attribute to change for 
> individual cards");
> +
>  DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
>
>  /* MSI had problems with lost interrupts, fixed but needs testing */
> @@ -50,6 +54,24 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
>
>  
> /**/
>
> +static int i2c_io(struct i2c_adapter *adapter, u8 adr,
> + u8 *wbuf, u32 wlen, u8 *rbuf, u32 rlen)
> +{
> +   struct i2c_msg msgs[2] = {{.addr = adr,  .flags = 0,
> +  .buf  = wbuf, .len   = wlen },
> + {.addr = adr,  .flags = I2C_M_RD,
> +  .buf  = rbuf,  .len   = rlen } };
> +   return (i2c_transfer(adapter, msgs, 2) == 2) ? 0 : -1;
> +}
> +
> +static int i2c_write(struct i2c_adapter *adap, u8 adr, u8 *data, int len)
> +{
> +   struct i2c_msg msg = {.addr = adr, .flags = 0,
> + .buf = data, .len = len};
> +
> +   return (i2c_transfer(adap, , 1) == 1) ? 0 : -1;
> +}
> +
>  static int i2c_read(struct i2c_adapter *adapter, u8 adr, u8 *val)
>  {
> struct i2c_msg msgs[1] = {{.addr = adr,  .flags = I2C_M_RD,
> @@ -83,6 +105,14 @@ static int i2c_read_reg16(struct i2c_adapter *adapter, u8 
> adr,
> return (i2c_transfer(adapter, msgs, 2) == 2) ? 0 : -1;
>  }
>
> +static int i2c_write_reg(struct i2c_adapter *adap, u8 adr,
> +u8 reg, u8 val)
> +{
> +   u8 msg[2] = {reg, val};
> +
> +   return i2c_write(adap, adr, msg, 2);
> +}
> +
>  static int ddb_i2c_cmd(struct ddb_i2c *i2c, u32 adr, u32 cmd)
>  {
> struct ddb *dev = i2c->dev;
> @@ -1272,6 +1302,70 @@ static void ddb_ports_detach(struct ddb *dev)
>  
> //
>  
> //
>
> +static int init_xo2(struct ddb_port *port)
> +{
> +   struct i2c_adapter *i2c = >i2c->adap;
> +   u8 val, data[2];
> +   int res;
> +
> +   res = i2c_read_regs(i2c, 0x10, 0x04, data, 2);
> +   if (res < 0)
> +   return res;
> +
> +   if (data[0] != 0x01)  {
> +   pr_info("Port %d: invalid XO2\n", port->nr);
> +   return -1;
> +   }
> +
> +   i2c_read_reg(i2c, 0x10, 0x08, );
> +   if (val != 0) {
> +   i2c_write_reg(i2c, 0x10, 0x08, 0x00);
> +   msleep(100);
> +   }
> +   /* Enable tuner power, disable pll, reset demods */
> +   i2c_write_reg(i2c, 0x10, 0x08, 0x04);
> +   usleep_range(2000, 3000);
> +   /* Release demod resets */
> +   i2c_write_reg(i2c, 0x10, 0x08, 0x07);
> +
> +   /* speed: 0=55,1=75,2=90,3=104 MBit/s */
> +   i2c_write_reg(i2c, 0x10, 0x09,
> +   ((xo2_speed >= 0 && xo2_speed <= 3) ? xo2_speed : 2));
> +
> +   i2c_write_reg(i2c, 0x10, 0x0a, 0x01);
> +   i2c_write_reg(i2c, 0x10, 0x0b, 0x01);
> +
> +   usleep_range(2000, 3000);
> +   /* Start XO2 PLL */
> +   i2c_write_reg(i2c, 0x10, 0x08, 0x87);
> +
> +   return 0;
> +}
> +
> +static int port_has_xo2(struct ddb_port *port, u8 *type, u8 *id)
> +{
> +   u8 probe[1] = { 0x00 }, data[4];
> +
> +   *type = DDB_XO2_TYPE_NONE;
> +
> +   if (i2c_io(>i2c->adap, 0x10, probe, 1, data, 4))
> +   return 0;
> +   if (data[0] == 'D' && data[1] == 'F') {
> +   *id = data[2];
> +

Re: [PATCH 16/19] [media] ddbridge: board control setup, ts quirk flags

not related to cxd2841er. I'm skipping this ...

2017-04-09 15:38 GMT-04:00 Daniel Scheller :
> From: Daniel Scheller 
>
> This is a backport of the board control setup from the vendor provided
> dddvb driver package, which does additional device initialisation based
> on the board_control device info values. Also backports the TS quirk
> flags which is used to control setup and usage of the tuner modules
> soldered on the bridge cards (e.g. CineCTv7, CineS2 V7, MaxA8 and the
> likes).
>
> Functionality originates from ddbridge vendor driver. Permission for
> reuse and kernel inclusion was formally granted by Ralph Metzler
> .
>
> Cc: Ralph Metzler 
> Signed-off-by: Daniel Scheller 
> ---
>  drivers/media/pci/ddbridge/ddbridge-core.c | 13 +
>  drivers/media/pci/ddbridge/ddbridge-regs.h |  4 
>  drivers/media/pci/ddbridge/ddbridge.h  | 10 ++
>  3 files changed, 27 insertions(+)
>
> diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c 
> b/drivers/media/pci/ddbridge/ddbridge-core.c
> index 12f5aa3..6b49fa9 100644
> --- a/drivers/media/pci/ddbridge/ddbridge-core.c
> +++ b/drivers/media/pci/ddbridge/ddbridge-core.c
> @@ -1763,6 +1763,19 @@ static int ddb_probe(struct pci_dev *pdev, const 
> struct pci_device_id *id)
> ddbwritel(0xfff0f, INTERRUPT_ENABLE);
> ddbwritel(0, MSI1_ENABLE);
>
> +   /* board control */
> +   if (dev->info->board_control) {
> +   ddbwritel(0, DDB_LINK_TAG(0) | BOARD_CONTROL);
> +   msleep(100);
> +   ddbwritel(dev->info->board_control_2,
> +   DDB_LINK_TAG(0) | BOARD_CONTROL);
> +   usleep_range(2000, 3000);
> +   ddbwritel(dev->info->board_control_2
> +   | dev->info->board_control,
> +   DDB_LINK_TAG(0) | BOARD_CONTROL);
> +   usleep_range(2000, 3000);
> +   }
> +
> if (ddb_i2c_init(dev) < 0)
> goto fail1;
> ddb_ports_init(dev);
> diff --git a/drivers/media/pci/ddbridge/ddbridge-regs.h 
> b/drivers/media/pci/ddbridge/ddbridge-regs.h
> index 6ae8103..98cebb9 100644
> --- a/drivers/media/pci/ddbridge/ddbridge-regs.h
> +++ b/drivers/media/pci/ddbridge/ddbridge-regs.h
> @@ -34,6 +34,10 @@
>
>  /* - 
> */
>
> +#define BOARD_CONTROL0x30
> +
> +/* - 
> */
> +
>  /* Interrupt controller */
>  /* How many MSI's are available depends on HW (Min 2 max 8) */
>  /* How many are usable also depends on Host platform*/
> diff --git a/drivers/media/pci/ddbridge/ddbridge.h 
> b/drivers/media/pci/ddbridge/ddbridge.h
> index 0898f60..734e18e 100644
> --- a/drivers/media/pci/ddbridge/ddbridge.h
> +++ b/drivers/media/pci/ddbridge/ddbridge.h
> @@ -43,6 +43,10 @@
>  #define DDB_MAX_PORT4
>  #define DDB_MAX_INPUT   8
>  #define DDB_MAX_OUTPUT  4
> +#define DDB_MAX_LINK4
> +#define DDB_LINK_SHIFT 28
> +
> +#define DDB_LINK_TAG(_x) (_x << DDB_LINK_SHIFT)
>
>  struct ddb_info {
> int   type;
> @@ -51,6 +55,12 @@ struct ddb_info {
> char *name;
> int   port_num;
> u32   port_type[DDB_MAX_PORT];
> +   u32   board_control;
> +   u32   board_control_2;
> +   u8ts_quirks;
> +#define TS_QUIRK_SERIAL   1
> +#define TS_QUIRK_REVERSED 2
> +#define TS_QUIRK_ALT_OSC  8
>  };
>
>  /* DMA_SIZE MUST be divisible by 188 and 128 !!! */
> --
> 2.10.2
>



-- 
Abylay Ospan,
NetUP Inc.
http://www.netup.tv

Re: [PATCH 15/19] [media] dvb-frontends/cxd2841er: improved snr reporting

Acked-by: Abylay Ospan 

2017-04-09 15:38 GMT-04:00 Daniel Scheller :
> From: Daniel Scheller 
>
> On DVB-T/T2 at least, SNR might be reported as >2500dB, which not only is
> just wrong but also ridiculous, so fix this by improving the conversion
> of the register value.
>
> The INTLOG10X100 function/macro and the way the values are converted were
> both taken from DD's cxd2843 driver.
>
> Signed-off-by: Daniel Scheller 
> ---
>  drivers/media/dvb-frontends/cxd2841er.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
> b/drivers/media/dvb-frontends/cxd2841er.c
> index efb2795..a01ac58 100644
> --- a/drivers/media/dvb-frontends/cxd2841er.c
> +++ b/drivers/media/dvb-frontends/cxd2841er.c
> @@ -38,6 +38,8 @@
>  #define MAX_WRITE_REGSIZE  16
>  #define LOG2_E_100X 144
>
> +#define INTLOG10X100(x) ((u32) (((u64) intlog10(x) * 100) >> 24))
> +
>  /* DVB-C constellation */
>  enum sony_dvbc_constellation_t {
> SONY_DVBC_CONSTELLATION_16QAM,
> @@ -1817,7 +1819,7 @@ static int cxd2841er_read_snr_t(struct cxd2841er_priv 
> *priv, u32 *snr)
> }
> if (reg > 4996)
> reg = 4996;
> -   *snr = 1 * ((intlog10(reg) - intlog10(5350 - reg)) >> 24) + 28500;
> +   *snr = 100 * ((INTLOG10X100(reg) - INTLOG10X100(5350 - reg)) + 285);
> return 0;
>  }
>
> @@ -1846,8 +1848,7 @@ static int cxd2841er_read_snr_t2(struct cxd2841er_priv 
> *priv, u32 *snr)
> }
> if (reg > 10876)
> reg = 10876;
> -   *snr = 1 * ((intlog10(reg) -
> -   intlog10(12600 - reg)) >> 24) + 32000;
> +   *snr = 100 * ((INTLOG10X100(reg) - INTLOG10X100(12600 - reg)) + 320);
> return 0;
>  }
>
> --
> 2.10.2
>



-- 
Abylay Ospan,
NetUP Inc.
http://www.netup.tv

Re: [PATCH 14/19] [media] dvb-frontends/cxd2841er: more configurable TSBITS

Acked-by: Abylay Ospan 

2017-04-09 15:38 GMT-04:00 Daniel Scheller :
> From: Daniel Scheller 
>
> Bits 3 and 4 of the TSCONFIG register are important for certain hardware
> constellations, in that they need to be zeroed. Add a configuration flag
> to toggle this.
>
> Signed-off-by: Daniel Scheller 
> ---
>  drivers/media/dvb-frontends/cxd2841er.c | 4 
>  drivers/media/dvb-frontends/cxd2841er.h | 1 +
>  2 files changed, 5 insertions(+)
>
> diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
> b/drivers/media/dvb-frontends/cxd2841er.c
> index 67bd13c..efb2795 100644
> --- a/drivers/media/dvb-frontends/cxd2841er.c
> +++ b/drivers/media/dvb-frontends/cxd2841er.c
> @@ -3794,6 +3794,10 @@ static int cxd2841er_init_tc(struct dvb_frontend *fe)
> cxd2841er_set_reg_bits(priv, I2C_SLVT, 0xc4,
> ((priv->flags & CXD2841ER_TS_SERIAL) ? 0x80 : 0x00), 0x80);
>
> +   /* clear TSCFG bits 3+4 */
> +   if (priv->flags & CXD2841ER_TSBITS)
> +   cxd2841er_set_reg_bits(priv, I2C_SLVT, 0xc4, 0x00, 0x18);
> +
> cxd2841er_init_stats(fe);
>
> return 0;
> diff --git a/drivers/media/dvb-frontends/cxd2841er.h 
> b/drivers/media/dvb-frontends/cxd2841er.h
> index 4f94422..dc32f5fb 100644
> --- a/drivers/media/dvb-frontends/cxd2841er.h
> +++ b/drivers/media/dvb-frontends/cxd2841er.h
> @@ -31,6 +31,7 @@
>  #define CXD2841ER_EARLY_TUNE   16  /* bit 4 */
>  #define CXD2841ER_NO_WAIT_LOCK 32  /* bit 5 */
>  #define CXD2841ER_NO_AGCNEG64  /* bit 6 */
> +#define CXD2841ER_TSBITS   128 /* bit 7 */
>
>  enum cxd2841er_xtal {
> SONY_XTAL_20500, /* 20.5 MHz */
> --
> 2.10.2
>



-- 
Abylay Ospan,
NetUP Inc.
http://www.netup.tv

Re: [PATCH 13/19] [media] dvb-frontends/cxd2841er: configurable IFAGCNEG

Acked-by: Abylay Ospan 

2017-04-09 15:38 GMT-04:00 Daniel Scheller :
> From: Daniel Scheller 
>
> Adds a flag to enable or disable the IFAGCNEG bit in cxd2841er_init_tc().
>
> Signed-off-by: Daniel Scheller 
> ---
>  drivers/media/dvb-frontends/cxd2841er.c | 5 +++--
>  drivers/media/dvb-frontends/cxd2841er.h | 1 +
>  2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
> b/drivers/media/dvb-frontends/cxd2841er.c
> index 67d4399..67bd13c 100644
> --- a/drivers/media/dvb-frontends/cxd2841er.c
> +++ b/drivers/media/dvb-frontends/cxd2841er.c
> @@ -3783,9 +3783,10 @@ static int cxd2841er_init_tc(struct dvb_frontend *fe)
> dev_dbg(>i2c->dev, "%s() bandwidth_hz=%d\n",
> __func__, p->bandwidth_hz);
> cxd2841er_shutdown_to_sleep_tc(priv);
> -   /* SONY_DEMOD_CONFIG_IFAGCNEG = 1 */
> +   /* SONY_DEMOD_CONFIG_IFAGCNEG = 1 (0 for NO_AGCNEG */
> cxd2841er_write_reg(priv, I2C_SLVT, 0x00, 0x10);
> -   cxd2841er_set_reg_bits(priv, I2C_SLVT, 0xcb, 0x40, 0x40);
> +   cxd2841er_set_reg_bits(priv, I2C_SLVT, 0xcb,
> +   ((priv->flags & CXD2841ER_NO_AGCNEG) ? 0x00 : 0x40), 0x40);
> /* SONY_DEMOD_CONFIG_IFAGC_ADC_FS = 0 */
> cxd2841er_write_reg(priv, I2C_SLVT, 0xcd, 0x50);
> /* SONY_DEMOD_CONFIG_PARALLEL_SEL = 1 */
> diff --git a/drivers/media/dvb-frontends/cxd2841er.h 
> b/drivers/media/dvb-frontends/cxd2841er.h
> index d77b59f..4f94422 100644
> --- a/drivers/media/dvb-frontends/cxd2841er.h
> +++ b/drivers/media/dvb-frontends/cxd2841er.h
> @@ -30,6 +30,7 @@
>  #define CXD2841ER_ASCOT8   /* bit 3 */
>  #define CXD2841ER_EARLY_TUNE   16  /* bit 4 */
>  #define CXD2841ER_NO_WAIT_LOCK 32  /* bit 5 */
> +#define CXD2841ER_NO_AGCNEG64  /* bit 6 */
>
>  enum cxd2841er_xtal {
> SONY_XTAL_20500, /* 20.5 MHz */
> --
> 2.10.2
>



-- 
Abylay Ospan,
NetUP Inc.
http://www.netup.tv

Re: [PATCH 12/19] [media] dvb-frontends/cxd2841er: make lock wait in set_fe_tc() optional

Acked-by: Abylay Ospan 

2017-04-09 15:38 GMT-04:00 Daniel Scheller :
> From: Daniel Scheller 
>
> Don't wait for FE_HAS_LOCK in set_frontend_tc() and thus don't hammer the
> lock status register with inquiries when CXD2841ER_NO_WAIT_LOCK is set
> in the configuration, which also unneccessarily blocks applications until
> a TS LOCK has been acquired. Rather, API and applications will check for
> a TS LOCK by utilising the tune fe_op, read_status and get_frontend ops,
> which is sufficient.
>
> Signed-off-by: Daniel Scheller 
> ---
>  drivers/media/dvb-frontends/cxd2841er.c | 4 
>  drivers/media/dvb-frontends/cxd2841er.h | 1 +
>  2 files changed, 5 insertions(+)
>
> diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
> b/drivers/media/dvb-frontends/cxd2841er.c
> index 894cb5a..67d4399 100644
> --- a/drivers/media/dvb-frontends/cxd2841er.c
> +++ b/drivers/media/dvb-frontends/cxd2841er.c
> @@ -3460,6 +3460,10 @@ static int cxd2841er_set_frontend_tc(struct 
> dvb_frontend *fe)
> cxd2841er_tuner_set(fe);
>
> cxd2841er_tune_done(priv);
> +
> +   if (priv->flags & CXD2841ER_NO_WAIT_LOCK)
> +   goto done;
> +
> timeout = 2500;
> while (timeout > 0) {
> ret = cxd2841er_read_status_tc(fe, );
> diff --git a/drivers/media/dvb-frontends/cxd2841er.h 
> b/drivers/media/dvb-frontends/cxd2841er.h
> index 061e551..d77b59f 100644
> --- a/drivers/media/dvb-frontends/cxd2841er.h
> +++ b/drivers/media/dvb-frontends/cxd2841er.h
> @@ -29,6 +29,7 @@
>  #define CXD2841ER_TS_SERIAL4   /* bit 2 */
>  #define CXD2841ER_ASCOT8   /* bit 3 */
>  #define CXD2841ER_EARLY_TUNE   16  /* bit 4 */
> +#define CXD2841ER_NO_WAIT_LOCK 32  /* bit 5 */
>
>  enum cxd2841er_xtal {
> SONY_XTAL_20500, /* 20.5 MHz */
> --
> 2.10.2
>



-- 
Abylay Ospan,
NetUP Inc.
http://www.netup.tv

Re: [PATCH 11/19] [media] dvb-frontends/cxd2841er: optionally tune earlier in set_frontend()

Acked-by: Abylay Ospan 

2017-04-09 15:38 GMT-04:00 Daniel Scheller :
> From: Daniel Scheller 
>
> When AUTO_IFHZ is set and the tuner is supposed to provide proper IF speed
> values, it should be possible to have the tuner setup take place before
> the demod is configured, else the demod might be configured with either
> wrong (old), or even no values at all, which obviously will cause issues.
> To set this behaviour in the most flexible way, this is done with a
> separate flag instead of making this depend on AUTO_IFHZ.
>
> It should be evaluated if tuning shouldn't take place earlier in all cases
> and hardware constellations.
>
> Signed-off-by: Daniel Scheller 
> ---
>  drivers/media/dvb-frontends/cxd2841er.c | 14 --
>  drivers/media/dvb-frontends/cxd2841er.h |  1 +
>  2 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
> b/drivers/media/dvb-frontends/cxd2841er.c
> index 7ca589a..894cb5a 100644
> --- a/drivers/media/dvb-frontends/cxd2841er.c
> +++ b/drivers/media/dvb-frontends/cxd2841er.c
> @@ -3306,6 +3306,10 @@ static int cxd2841er_set_frontend_s(struct 
> dvb_frontend *fe)
> __func__,
> (p->delivery_system == SYS_DVBS ? "DVB-S" : "DVB-S2"),
>  p->frequency, symbol_rate, priv->xtal);
> +
> +   if (priv->flags & CXD2841ER_EARLY_TUNE)
> +   cxd2841er_tuner_set(fe);
> +
> switch (priv->state) {
> case STATE_SLEEP_S:
> ret = cxd2841er_sleep_s_to_active_s(
> @@ -3325,7 +3329,8 @@ static int cxd2841er_set_frontend_s(struct dvb_frontend 
> *fe)
> goto done;
> }
>
> -   cxd2841er_tuner_set(fe);
> +   if (!(priv->flags & CXD2841ER_EARLY_TUNE))
> +   cxd2841er_tuner_set(fe);
>
> cxd2841er_tune_done(priv);
> timeout = ((300 + (symbol_rate - 1)) / symbol_rate) + 150;
> @@ -3365,6 +3370,10 @@ static int cxd2841er_set_frontend_tc(struct 
> dvb_frontend *fe)
>
> dev_dbg(>i2c->dev, "%s() delivery_system=%d bandwidth_hz=%d\n",
>  __func__, p->delivery_system, p->bandwidth_hz);
> +
> +   if (priv->flags & CXD2841ER_EARLY_TUNE)
> +   cxd2841er_tuner_set(fe);
> +
> if (p->delivery_system == SYS_DVBT) {
> priv->system = SYS_DVBT;
> switch (priv->state) {
> @@ -3447,7 +3456,8 @@ static int cxd2841er_set_frontend_tc(struct 
> dvb_frontend *fe)
> if (ret)
> goto done;
>
> -   cxd2841er_tuner_set(fe);
> +   if (!(priv->flags & CXD2841ER_EARLY_TUNE))
> +   cxd2841er_tuner_set(fe);
>
> cxd2841er_tune_done(priv);
> timeout = 2500;
> diff --git a/drivers/media/dvb-frontends/cxd2841er.h 
> b/drivers/media/dvb-frontends/cxd2841er.h
> index 90ced97..061e551 100644
> --- a/drivers/media/dvb-frontends/cxd2841er.h
> +++ b/drivers/media/dvb-frontends/cxd2841er.h
> @@ -28,6 +28,7 @@
>  #define CXD2841ER_AUTO_IFHZ2   /* bit 1 */
>  #define CXD2841ER_TS_SERIAL4   /* bit 2 */
>  #define CXD2841ER_ASCOT8   /* bit 3 */
> +#define CXD2841ER_EARLY_TUNE   16  /* bit 4 */
>
>  enum cxd2841er_xtal {
> SONY_XTAL_20500, /* 20.5 MHz */
> --
> 2.10.2
>



-- 
Abylay Ospan,
NetUP Inc.
http://www.netup.tv

Re: [PATCH 10/19] [media] dvb-frontends/cxd2841er: make ASCOT use optional

Acked-by: Abylay Ospan 

2017-04-09 15:38 GMT-04:00 Daniel Scheller :
> From: Daniel Scheller 
>
> The Sony CXD28xx demods may have other tuner types attached to them (e.g.
> NXP TDA18212), so don't mandatorily configure and enable the ASCOT
> functionality, but make this conditional by a config flag.
>
> Signed-off-by: Daniel Scheller 
> ---
>  drivers/media/dvb-frontends/cxd2841er.c| 70 
> ++
>  drivers/media/dvb-frontends/cxd2841er.h|  1 +
>  drivers/media/pci/netup_unidvb/netup_unidvb_core.c |  2 +-
>  3 files changed, 46 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
> b/drivers/media/dvb-frontends/cxd2841er.c
> index 1df95c4..7ca589a 100644
> --- a/drivers/media/dvb-frontends/cxd2841er.c
> +++ b/drivers/media/dvb-frontends/cxd2841er.c
> @@ -2277,7 +2277,8 @@ static int cxd2841er_sleep_tc_to_active_t2_band(struct 
> cxd2841er_priv *priv,
> /* Group delay equaliser settings for
>  * ASCOT2D, ASCOT2E and ASCOT3 tuners
>  */
> -   cxd2841er_write_regs(priv, I2C_SLVT,
> +   if (priv->flags & CXD2841ER_ASCOT)
> +   cxd2841er_write_regs(priv, I2C_SLVT,
> 0xA6, itbCoef8bw[priv->xtal], 14);
> /*  */
> ifhz = cxd2841er_get_if_hz(priv, 480);
> @@ -2306,7 +2307,8 @@ static int cxd2841er_sleep_tc_to_active_t2_band(struct 
> cxd2841er_priv *priv,
> /* Group delay equaliser settings for
>  * ASCOT2D, ASCOT2E and ASCOT3 tuners
>  */
> -   cxd2841er_write_regs(priv, I2C_SLVT,
> +   if (priv->flags & CXD2841ER_ASCOT)
> +   cxd2841er_write_regs(priv, I2C_SLVT,
> 0xA6, itbCoef7bw[priv->xtal], 14);
> /*  */
> ifhz = cxd2841er_get_if_hz(priv, 420);
> @@ -2335,7 +2337,8 @@ static int cxd2841er_sleep_tc_to_active_t2_band(struct 
> cxd2841er_priv *priv,
> /* Group delay equaliser settings for
>  * ASCOT2D, ASCOT2E and ASCOT3 tuners
>  */
> -   cxd2841er_write_regs(priv, I2C_SLVT,
> +   if (priv->flags & CXD2841ER_ASCOT)
> +   cxd2841er_write_regs(priv, I2C_SLVT,
> 0xA6, itbCoef6bw[priv->xtal], 14);
> /*  */
> ifhz = cxd2841er_get_if_hz(priv, 360);
> @@ -2364,7 +2367,8 @@ static int cxd2841er_sleep_tc_to_active_t2_band(struct 
> cxd2841er_priv *priv,
> /* Group delay equaliser settings for
>  * ASCOT2D, ASCOT2E and ASCOT3 tuners
>  */
> -   cxd2841er_write_regs(priv, I2C_SLVT,
> +   if (priv->flags & CXD2841ER_ASCOT)
> +   cxd2841er_write_regs(priv, I2C_SLVT,
> 0xA6, itbCoef5bw[priv->xtal], 14);
> /*  */
> ifhz = cxd2841er_get_if_hz(priv, 360);
> @@ -2393,7 +2397,8 @@ static int cxd2841er_sleep_tc_to_active_t2_band(struct 
> cxd2841er_priv *priv,
> /* Group delay equaliser settings for
>  * ASCOT2D, ASCOT2E and ASCOT3 tuners
>  */
> -   cxd2841er_write_regs(priv, I2C_SLVT,
> +   if (priv->flags & CXD2841ER_ASCOT)
> +   cxd2841er_write_regs(priv, I2C_SLVT,
> 0xA6, itbCoef17bw[priv->xtal], 14);
> /*  */
> ifhz = cxd2841er_get_if_hz(priv, 350);
> @@ -2493,7 +2498,8 @@ static int cxd2841er_sleep_tc_to_active_t_band(
> /* Group delay equaliser settings for
>  * ASCOT2D, ASCOT2E and ASCOT3 tuners
> */
> -   cxd2841er_write_regs(priv, I2C_SLVT,
> +   if (priv->flags & CXD2841ER_ASCOT)
> +   cxd2841er_write_regs(priv, I2C_SLVT,
> 0xA6, itbCoef8bw[priv->xtal], 14);
> /*  */
> ifhz = cxd2841er_get_if_hz(priv, 480);
> @@ -2529,7 +2535,8 @@ static int cxd2841er_sleep_tc_to_active_t_band(
> /* Group delay equaliser settings for
>  * ASCOT2D, ASCOT2E and ASCOT3 tuners
> */
> -   cxd2841er_write_regs(priv, I2C_SLVT,
> +   if (priv->flags & CXD2841ER_ASCOT)
> +   cxd2841er_write_regs(priv, I2C_SLVT,
> 0xA6, itbCoef7bw[priv->xtal], 14);
> /*  */
> ifhz = cxd2841er_get_if_hz(priv, 420);
> @@ -2565,7 +2572,8 @@ static int cxd2841er_sleep_tc_to_active_t_band(
> /* Group delay equaliser settings for
>  * ASCOT2D, ASCOT2E and ASCOT3 tuners
>

[PATCH v6 1/2] dt-bindings: media: stm32 cec driver

Add bindings documentation for stm32 CEC driver.

Signed-off-by: Benjamin Gaignard 
---
 .../devicetree/bindings/media/st,stm32-cec.txt| 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/st,stm32-cec.txt

diff --git a/Documentation/devicetree/bindings/media/st,stm32-cec.txt 
b/Documentation/devicetree/bindings/media/st,stm32-cec.txt
new file mode 100644
index 000..6be2381
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/st,stm32-cec.txt
@@ -0,0 +1,19 @@
+STMicroelectronics STM32 CEC driver
+
+Required properties:
+ - compatible : value should be "st,stm32-cec"
+ - reg : Physical base address of the IP registers and length of memory
+mapped region.
+ - clocks : from common clock binding: handle to CEC clocks
+ - clock-names : from common clock binding: must be "cec" and "hdmi-cec".
+ - interrupts : CEC interrupt number to the CPU.
+
+Example for stm32f746:
+
+cec: cec@40006c00 {
+   compatible = "st,stm32-cec";
+   reg = <0x40006C00 0x400>;
+   interrupts = <94>;
+   clocks = < 0 STM32F7_APB1_CLOCK(CEC)>, < 1 CLK_HDMI_CEC>;
+   clock-names = "cec", "hdmi-cec";
+};
-- 
1.9.1

[PATCH v6 2/2] cec: add STM32 cec driver

This patch add cec driver for STM32 platforms.
cec hardware block isn't not always used with hdmi so
cec notifier is not implemented. That will be done later
when STM32 DSI driver will be available.

Driver compliance has been tested with cec-ctl and cec-compliance
tools.

Signed-off-by: Benjamin Gaignard 
Signed-off-by: Yannick Fertre 
---
version 6:
- fix duplicate constant in define 
- add monitor mode

 drivers/media/platform/Kconfig   |  12 +
 drivers/media/platform/Makefile  |   2 +
 drivers/media/platform/stm32/Makefile|   1 +
 drivers/media/platform/stm32/stm32-cec.c | 369 +++
 4 files changed, 384 insertions(+)
 create mode 100644 drivers/media/platform/stm32/Makefile
 create mode 100644 drivers/media/platform/stm32/stm32-cec.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 041cb80..52280bc 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -521,4 +521,16 @@ config VIDEO_STI_HDMI_CEC
  CEC bus is present in the HDMI connector and enables communication
  between compatible devices.
 
+config VIDEO_STM32_HDMI_CEC
+   tristate "STMicroelectronics STM32 HDMI CEC driver"
+   depends on ARCH_STM32 || COMPILE_TEST
+   select REGMAP
+   select REGMAP_MMIO
+   select CEC_CORE
+   ---help---
+ This is a driver for STM32 interface. It uses the
+ generic CEC framework interface.
+ CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
 endif #CEC_PLATFORM_DRIVERS
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 63303d6..7cd9965 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -44,6 +44,8 @@ obj-$(CONFIG_VIDEO_STI_HDMI_CEC)  += sti/cec/
 
 obj-$(CONFIG_VIDEO_STI_DELTA)  += sti/delta/
 
+obj-$(CONFIG_VIDEO_STM32_HDMI_CEC) += stm32/
+
 obj-$(CONFIG_BLACKFIN)  += blackfin/
 
 obj-$(CONFIG_ARCH_DAVINCI) += davinci/
diff --git a/drivers/media/platform/stm32/Makefile 
b/drivers/media/platform/stm32/Makefile
new file mode 100644
index 000..632b04c
--- /dev/null
+++ b/drivers/media/platform/stm32/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_STM32_HDMI_CEC) += stm32-cec.o
diff --git a/drivers/media/platform/stm32/stm32-cec.c 
b/drivers/media/platform/stm32/stm32-cec.c
new file mode 100644
index 000..f7a8fd9
--- /dev/null
+++ b/drivers/media/platform/stm32/stm32-cec.c
@@ -0,0 +1,369 @@
+/*
+ * STM32 CEC driver
+ * Copyright (C) STMicroelectronics SA 2017
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define CEC_NAME   "stm32-cec"
+
+/* CEC registers  */
+#define CEC_CR 0x /* Control Register */
+#define CEC_CFGR   0x0004 /* ConFiGuration Register */
+#define CEC_TXDR   0x0008 /* Rx data Register */
+#define CEC_RXDR   0x000C /* Rx data Register */
+#define CEC_ISR0x0010 /* Interrupt and status Register */
+#define CEC_IER0x0014 /* Interrupt enable Register */
+
+#define TXEOM  BIT(2)
+#define TXSOM  BIT(1)
+#define CECEN  BIT(0)
+
+#define LSTN   BIT(31)
+#define OARGENMASK(30, 16)
+#define SFTOP  BIT(8)
+#define BRDNOGEN   BIT(7)
+#define LBPEGENBIT(6)
+#define BREGEN BIT(5)
+#define BRESTP BIT(4)
+#define RXTOL  BIT(3)
+#define SFTGENMASK(2, 0)
+#define FULL_CFG   (LSTN | SFTOP | BRDNOGEN | LBPEGEN | BREGEN | BRESTP \
+| RXTOL)
+
+#define TXACKE BIT(12)
+#define TXERR  BIT(11)
+#define TXUDR  BIT(10)
+#define TXEND  BIT(9)
+#define TXBR   BIT(8)
+#define ARBLST BIT(7)
+#define RXACKE BIT(6)
+#define RXOVR  BIT(2)
+#define RXEND  BIT(1)
+#define RXBR   BIT(0)
+
+#define ALL_TX_IT  (TXEND | TXBR | TXACKE | TXERR | TXUDR | ARBLST)
+#define ALL_RX_IT  (RXEND | RXBR | RXACKE | RXOVR)
+
+struct stm32_cec {
+   struct cec_adapter  *adap;
+   struct device   *dev;
+   struct clk  *clk_cec;
+   struct clk  *clk_hdmi_cec;
+   struct reset_control*rstc;
+   struct regmap   *regmap;
+   int irq;
+   u32 irq_status;
+   struct cec_msg  rx_msg;
+   struct cec_msg  tx_msg;
+   int tx_cnt;
+};
+
+static void cec_hw_init(struct stm32_cec *cec)
+{
+

[PATCH v6 0/2] cec: STM32 driver

version 6:
- fix duplicate constant in define 
- add monitor mode

version 5:
- remove cec notifier (to be added after drm driver release)

version 4:
- rebased on Hans cec-config branch
- rework bindings commit message
- add notifier support
- update KConfig

version 2:
- fix typo in compagnie name
- add yannick sign-off
- use cec_message instead of custom struct in cec device
- add monitor mode

I don't change the split between irq handler and irq thread because
it would had mean to handle all errors cases irq handler to keep
a correct sequence. I don't think it is critical as it is since cec is a very
slow protocol.

This serie of patches add cec driver for STM32 platforms.

This code doesn't implement cec notifier because STM32 doesn't
provide HDMI yet but it will be added later.

Those patches have been developped on top of media_tree master branch
where STM32 DCMI code has not been merged so conflict in Kconfig and Makefile
could occur depending of merge ordering.

Compliance has been tested on STM32F769.

~ # cec-ctl -p 1.0.0.0 --playback 
Driver Info:
Driver Name: stm32-cec
Adapter Name   : stm32-cec
Capabilities   : 0x000f
Physical Address
Logical Addresses
Transmit
Passthrough
Driver version : 4.11.0
Available Logical Addresses: 1
Physical Address   : 1.0.0.0
Logical Address Mask   : 0x0010
CEC Version: 2.0
Vendor ID  : 0x000c03 (HDMI)
OSD Name   : 'Playback'
Logical Addresses  : 1 (Allow RC Passthrough)

  Logical Address  : 4 (Playback Device 1)
Primary Device Type: Playback
Logical Address Type   : Playback
All Device Types   : Playback
RC TV Profile  : None
Device Features:
None

~ # cec-compliance -A 
cec-compliance SHA : 6acac5cec698de39b9398b66c4f5f4db6b2730d8

Driver Info:
Driver Name: stm32-cec
Adapter Name   : stm32-cec
Capabilities   : 0x000f
Physical Address
Logical Addresses
Transmit
Passthrough
Driver version : 4.11.0
Available Logical Addresses: 1
Physical Address   : 1.0.0.0
Logical Address Mask   : 0x0010
CEC Version: 2.0
Vendor ID  : 0x000c03
Logical Addresses  : 1 (Allow RC Passthrough)

  Logical Address  : 4
Primary Device Type: Playback
Logical Address Type   : Playback
All Device Types   : Playback
RC TV Profile  : None
Device Features:
None

Compliance test for device /dev/cec0:

The test results mean the following:
OK  Supported correctly by the device.
OK (Not Supported)  Not supported and not mandatory for the device.
OK (Presumed)   Presumably supported.  Manually check to confirm.
OK (Unexpected) Supported correctly but is not expected to be 
supported for this device.
OK (Refused)Supported by the device, but was refused.
FAILFailed and was expected to be supported by this 
device.

Find remote devices:
Polling: OK

CEC API:
CEC_ADAP_G_CAPS: OK
CEC_DQEVENT: OK
CEC_ADAP_G/S_PHYS_ADDR: OK
CEC_ADAP_G/S_LOG_ADDRS: OK
CEC_TRANSMIT: OK
CEC_RECEIVE: OK
CEC_TRANSMIT/RECEIVE (non-blocking): OK (Presumed)
CEC_G/S_MODE: OK
CEC_EVENT_LOST_MSGS: OK

Network topology:
System Information for device 0 (TV) from device 4 (Playback Device 1):
CEC Version: 1.4
Physical Address   : 0.0.0.0
Primary Device Type: TV
Vendor ID  : 0x00903e
OSD Name   : 'TV'
Menu Language  : fre
Power Status   : On

Total: 10, Succeeded: 10, Failed: 0, Warnings: 0


Benjamin Gaignard (2):
  dt-bindings: media: stm32 cec driver
  cec: add STM32 cec driver

 .../devicetree/bindings/media/st,stm32-cec.txt |  19 ++
 drivers/media/platform/Kconfig |  12 +
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/stm32/Makefile  |   1 +
 drivers/media/platform/stm32/stm32-cec.c   | 369 +
 5 files changed, 403 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/st,stm32-cec.txt
 create mode 100644 drivers/media/platform/stm32/Makefile
 create mode 100644

Re: [PATCH RFC] v4l2-core: Use kvmalloc() for potentially big allocations


Hi Tomasz,

On 2017-05-31 08:58, Tomasz Figa wrote:

There are multiple places where arrays or otherwise variable sized
buffer are allocated through V4L2 core code, including things like
controls, memory pages, staging buffers for ioctls and so on. Such
allocations can potentially require an order > 0 allocation from the
page allocator, which is not guaranteed to be fulfilled and is likely to
fail on a system with severe memory fragmentation (e.g. a system with
very long uptime).

Since the memory being allocated is intended to be used by the CPU
exclusively, we can consider using vmalloc() as a fallback and this is
exactly what the recently merged kvmalloc() helpers do. A kmalloc() call
is still attempted, even for order > 0 allocations, but it is done
with __GFP_NORETRY and __GFP_NOWARN, with expectation of failing if
requested memory is not available instantly. Only then the vmalloc()
fallback is used. This should give us fast and more reliable allocations
even on systems with higher memory pressure and/or more fragmentation,
while still retaining the same performance level on systems not
suffering from such conditions.

While at it, replace explicit array size calculations on changed
allocations with kvmalloc_array().

Signed-off-by: Tomasz Figa 
---
  drivers/media/v4l2-core/v4l2-async.c   |  4 ++--
  drivers/media/v4l2-core/v4l2-ctrls.c   | 25 +
  drivers/media/v4l2-core/v4l2-event.c   |  8 +---
  drivers/media/v4l2-core/v4l2-ioctl.c   |  6 +++---
  drivers/media/v4l2-core/v4l2-subdev.c  |  7 ---
  drivers/media/v4l2-core/videobuf2-dma-sg.c |  8 


For vb2:
Acked-by: Marek Szyprowski 

There are also a few vmalloc calls in old videobuf (v1) framework, which
might be converted to kvmalloc if you have a few spare minutes to take
a look.


  6 files changed, 31 insertions(+), 27 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-async.c 
b/drivers/media/v4l2-core/v4l2-async.c
index 96cc733f35ef..2d2d9f1f8831 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -204,7 +204,7 @@ void v4l2_async_notifier_unregister(struct 
v4l2_async_notifier *notifier)
if (!notifier->v4l2_dev)
return;
  
-	dev = kmalloc_array(n_subdev, sizeof(*dev), GFP_KERNEL);

+   dev = kvmalloc_array(n_subdev, sizeof(*dev), GFP_KERNEL);
if (!dev) {
dev_err(notifier->v4l2_dev->dev,
"Failed to allocate device cache!\n");
@@ -260,7 +260,7 @@ void v4l2_async_notifier_unregister(struct 
v4l2_async_notifier *notifier)
}
put_device(d);
}
-   kfree(dev);
+   kvfree(dev);
  
  	notifier->v4l2_dev = NULL;
  
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c

index ec42872d11cf..88025527c67e 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -1745,8 +1745,9 @@ int v4l2_ctrl_handler_init_class(struct v4l2_ctrl_handler 
*hdl,
INIT_LIST_HEAD(>ctrls);
INIT_LIST_HEAD(>ctrl_refs);
hdl->nr_of_buckets = 1 + nr_of_controls_hint / 8;
-   hdl->buckets = kcalloc(hdl->nr_of_buckets, sizeof(hdl->buckets[0]),
-  GFP_KERNEL);
+   hdl->buckets = kvmalloc_array(hdl->nr_of_buckets,
+ sizeof(hdl->buckets[0]),
+ GFP_KERNEL | __GFP_ZERO);
hdl->error = hdl->buckets ? 0 : -ENOMEM;
return hdl->error;
  }
@@ -1773,9 +1774,9 @@ void v4l2_ctrl_handler_free(struct v4l2_ctrl_handler *hdl)
list_del(>node);
list_for_each_entry_safe(sev, next_sev, >ev_subs, node)
list_del(>node);
-   kfree(ctrl);
+   kvfree(ctrl);
}
-   kfree(hdl->buckets);
+   kvfree(hdl->buckets);
hdl->buckets = NULL;
hdl->cached = NULL;
hdl->error = 0;
@@ -2022,7 +2023,7 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct 
v4l2_ctrl_handler *hdl,
 is_array)
sz_extra += 2 * tot_ctrl_size;
  
-	ctrl = kzalloc(sizeof(*ctrl) + sz_extra, GFP_KERNEL);

+   ctrl = kvzalloc(sizeof(*ctrl) + sz_extra, GFP_KERNEL);
if (ctrl == NULL) {
handler_set_err(hdl, -ENOMEM);
return NULL;
@@ -2071,7 +2072,7 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct 
v4l2_ctrl_handler *hdl,
}
  
  	if (handler_new_ref(hdl, ctrl)) {

-   kfree(ctrl);
+   kvfree(ctrl);
return NULL;
}
mutex_lock(hdl->lock);
@@ -2824,8 +2825,8 @@ int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl, 
struct v4l2_ext_controls *cs
return class_check(hdl, cs->which);
  
  	if (cs->count > ARRAY_SIZE(helper)) {

-   helpers = kmalloc_array(cs->count, sizeof(helper[0]),
-

Re: [PATCH 09/19] [media] dvb-frontends/cxd2841er: TS_SERIAL config flag

Acked-by: Abylay Ospan 

2017-04-09 15:38 GMT-04:00 Daniel Scheller :
> From: Daniel Scheller 
>
> Some constellations work/need a serial TS transport mode. This adds a flag
> that will toggle set up of such mode.
>
> Signed-off-by: Daniel Scheller 
> ---
>  drivers/media/dvb-frontends/cxd2841er.c | 18 --
>  drivers/media/dvb-frontends/cxd2841er.h |  5 +++--
>  2 files changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
> b/drivers/media/dvb-frontends/cxd2841er.c
> index fa6a963..1df95c4 100644
> --- a/drivers/media/dvb-frontends/cxd2841er.c
> +++ b/drivers/media/dvb-frontends/cxd2841er.c
> @@ -912,6 +912,18 @@ static void cxd2841er_set_ts_clock_mode(struct 
> cxd2841er_priv *priv,
>
> /*
>  * slaveBankAddrBitdefaultName
> +*   00h C4h [1:0]  2'b??  OSERCKMODE
> +*/
> +   cxd2841er_set_reg_bits(priv, I2C_SLVT, 0xc4,
> +   ((priv->flags & CXD2841ER_TS_SERIAL) ? 0x01 : 0x00), 0x03);
> +   /*
> +* slaveBankAddrBitdefaultName
> +*   00h D1h [1:0]  2'b??  OSERDUTYMODE
> +*/
> +   cxd2841er_set_reg_bits(priv, I2C_SLVT, 0xd1,
> +   ((priv->flags & CXD2841ER_TS_SERIAL) ? 0x01 : 0x00), 0x03);
> +   /*
> +* slaveBankAddrBitdefaultName
>  *   00h D9h [7:0]  8'h08  OTSCKPERIOD
>  */
> cxd2841er_write_reg(priv, I2C_SLVT, 0xd9, 0x08);
> @@ -925,7 +937,8 @@ static void cxd2841er_set_ts_clock_mode(struct 
> cxd2841er_priv *priv,
>  * slaveBankAddrBitdefaultName
>  *   00h 33h [1:0]  2'b01  OREG_CKSEL_TSIF
>  */
> -   cxd2841er_set_reg_bits(priv, I2C_SLVT, 0x33, 0x00, 0x03);
> +   cxd2841er_set_reg_bits(priv, I2C_SLVT, 0x33,
> +   ((priv->flags & CXD2841ER_TS_SERIAL) ? 0x01 : 0x00), 0x03);
> /*
>  * Enable TS IF Clock
>  * slaveBankAddrBitdefaultName
> @@ -3745,7 +3758,8 @@ static int cxd2841er_init_tc(struct dvb_frontend *fe)
> cxd2841er_write_reg(priv, I2C_SLVT, 0xcd, 0x50);
> /* SONY_DEMOD_CONFIG_PARALLEL_SEL = 1 */
> cxd2841er_write_reg(priv, I2C_SLVT, 0x00, 0x00);
> -   cxd2841er_set_reg_bits(priv, I2C_SLVT, 0xc4, 0x00, 0x80);
> +   cxd2841er_set_reg_bits(priv, I2C_SLVT, 0xc4,
> +   ((priv->flags & CXD2841ER_TS_SERIAL) ? 0x80 : 0x00), 0x80);
>
> cxd2841er_init_stats(fe);
>
> diff --git a/drivers/media/dvb-frontends/cxd2841er.h 
> b/drivers/media/dvb-frontends/cxd2841er.h
> index 38d7f9f..58fbd98 100644
> --- a/drivers/media/dvb-frontends/cxd2841er.h
> +++ b/drivers/media/dvb-frontends/cxd2841er.h
> @@ -24,8 +24,9 @@
>
>  #include 
>
> -#define CXD2841ER_USE_GATECTRL 1
> -#define CXD2841ER_AUTO_IFHZ2
> +#define CXD2841ER_USE_GATECTRL 1   /* bit 0 */
> +#define CXD2841ER_AUTO_IFHZ2   /* bit 1 */
> +#define CXD2841ER_TS_SERIAL4   /* bit 2 */
>
>  enum cxd2841er_xtal {
> SONY_XTAL_20500, /* 20.5 MHz */
> --
> 2.10.2
>



-- 
Abylay Ospan,
NetUP Inc.
http://www.netup.tv

Re: [PATCH 08/19] [media] dvb-frontends/cxd2841er: support IF speed calc from tuner values

Acked-by: Abylay Ospan 

2017-04-09 15:38 GMT-04:00 Daniel Scheller :
> From: Daniel Scheller 
>
> Add a AUTO_IFHZ flag and a function that will read IF speed values from any
> attached tuner if the tuner supports this and if AUTO_IFHZ is enabled, and
> else the passed default value (which probably matches Sony ASCOT tuners)
> will be passed back. The returned value is then used to calculate the iffeq
> which the demod will be programmed with.
>
> Signed-off-by: Daniel Scheller 
> ---
>  drivers/media/dvb-frontends/cxd2841er.c | 64 
> +++--
>  drivers/media/dvb-frontends/cxd2841er.h |  1 +
>  2 files changed, 47 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
> b/drivers/media/dvb-frontends/cxd2841er.c
> index 162a0f5..fa6a963 100644
> --- a/drivers/media/dvb-frontends/cxd2841er.c
> +++ b/drivers/media/dvb-frontends/cxd2841er.c
> @@ -327,6 +327,20 @@ static u32 cxd2841er_calc_iffreq(u32 ifhz)
> return cxd2841er_calc_iffreq_xtal(SONY_XTAL_20500, ifhz);
>  }
>
> +static int cxd2841er_get_if_hz(struct cxd2841er_priv *priv, u32 def_hz)
> +{
> +   u32 hz;
> +
> +   if (priv->frontend.ops.tuner_ops.get_if_frequency
> +   && (priv->flags & CXD2841ER_AUTO_IFHZ))
> +   priv->frontend.ops.tuner_ops.get_if_frequency(
> +   >frontend, );
> +   else
> +   hz = def_hz;
> +
> +   return hz;
> +}
> +
>  static int cxd2841er_tuner_set(struct dvb_frontend *fe)
>  {
> struct cxd2841er_priv *priv = fe->demodulator_priv;
> @@ -2147,7 +2161,7 @@ static int cxd2841er_dvbt2_set_plp_config(struct 
> cxd2841er_priv *priv,
>  static int cxd2841er_sleep_tc_to_active_t2_band(struct cxd2841er_priv *priv,
> u32 bandwidth)
>  {
> -   u32 iffreq;
> +   u32 iffreq, ifhz;
> u8 data[MAX_WRITE_REGSIZE];
>
> const uint8_t nominalRate8bw[3][5] = {
> @@ -2253,7 +2267,8 @@ static int cxd2841er_sleep_tc_to_active_t2_band(struct 
> cxd2841er_priv *priv,
> cxd2841er_write_regs(priv, I2C_SLVT,
> 0xA6, itbCoef8bw[priv->xtal], 14);
> /*  */
> -   iffreq = cxd2841er_calc_iffreq_xtal(priv->xtal, 480);
> +   ifhz = cxd2841er_get_if_hz(priv, 480);
> +   iffreq = cxd2841er_calc_iffreq_xtal(priv->xtal, ifhz);
> data[0] = (u8) ((iffreq >> 16) & 0xff);
> data[1] = (u8)((iffreq >> 8) & 0xff);
> data[2] = (u8)(iffreq & 0xff);
> @@ -2281,7 +2296,8 @@ static int cxd2841er_sleep_tc_to_active_t2_band(struct 
> cxd2841er_priv *priv,
> cxd2841er_write_regs(priv, I2C_SLVT,
> 0xA6, itbCoef7bw[priv->xtal], 14);
> /*  */
> -   iffreq = cxd2841er_calc_iffreq_xtal(priv->xtal, 420);
> +   ifhz = cxd2841er_get_if_hz(priv, 420);
> +   iffreq = cxd2841er_calc_iffreq_xtal(priv->xtal, ifhz);
> data[0] = (u8) ((iffreq >> 16) & 0xff);
> data[1] = (u8)((iffreq >> 8) & 0xff);
> data[2] = (u8)(iffreq & 0xff);
> @@ -2309,7 +2325,8 @@ static int cxd2841er_sleep_tc_to_active_t2_band(struct 
> cxd2841er_priv *priv,
> cxd2841er_write_regs(priv, I2C_SLVT,
> 0xA6, itbCoef6bw[priv->xtal], 14);
> /*  */
> -   iffreq = cxd2841er_calc_iffreq_xtal(priv->xtal, 360);
> +   ifhz = cxd2841er_get_if_hz(priv, 360);
> +   iffreq = cxd2841er_calc_iffreq_xtal(priv->xtal, ifhz);
> data[0] = (u8) ((iffreq >> 16) & 0xff);
> data[1] = (u8)((iffreq >> 8) & 0xff);
> data[2] = (u8)(iffreq & 0xff);
> @@ -2337,7 +2354,8 @@ static int cxd2841er_sleep_tc_to_active_t2_band(struct 
> cxd2841er_priv *priv,
> cxd2841er_write_regs(priv, I2C_SLVT,
> 0xA6, itbCoef5bw[priv->xtal], 14);
> /*  */
> -   iffreq = cxd2841er_calc_iffreq_xtal(priv->xtal, 360);
> +   ifhz = cxd2841er_get_if_hz(priv, 360);
> +   iffreq = cxd2841er_calc_iffreq_xtal(priv->xtal, ifhz);
> data[0] = (u8) ((iffreq >> 16) & 0xff);
> data[1] = (u8)((iffreq >> 8) & 0xff);
> data[2] = (u8)(iffreq & 0xff);
> @@ -2365,7 +2383,8 @@ static int cxd2841er_sleep_tc_to_active_t2_band(struct 
> cxd2841er_priv *priv,
> cxd2841er_write_regs(priv, I2C_SLVT,
> 0xA6, itbCoef17bw[priv->xtal], 14);
> /*  */
> -   iffreq = cxd2841er_calc_iffreq_xtal(priv->xtal, 350);
> +   ifhz = cxd2841er_get_if_hz(priv, 350);
> +   iffreq =

Re: [PATCH] ARM: dts: exynos: Add HDMI CEC device to Exynos5 SoC family


Hi Hans,

On 2017-05-31 13:17, Hans Verkuil wrote:

On 05/31/17 13:00, Marek Szyprowski wrote:

Exynos5250 and Exynos542x SoCs have the same CEC hardware module as
Exynos4 SoC series, so enable support for it using the same compatible
string.

Tested on Odroid XU3 (Exynos5422) and Google Snow (Exynos5250) boards.

Thanks!

Do you know if the CEC block is always on for these devices or only if there
is a hotplug signal? That was a problem with the exynos4 odroid.


Odroid XU3 has exactly same wiring between SoC & HDMI connector (via 
IP4791CZ12

chip) as Odroid U3, so I expect the same issues.

I don't have schematic for Google Snow board, so I have no idea how it works
there.


I have made a patch (not posted yet) to signal this in the device tree and
added a CEC capability to signal this to the user.

This capability will be added to 4.13 (see my patch 'cec: add CEC_CAP_NEEDS_HPD'
from May 25th) since the DisplayPort CEC tunneling feature needs it as well.

It's easy to test: don't connect an HDMI cable and run:

cec-ctl --playback
cec-ctl -t0 --image-view-on

If this returns with a NACK error, then it is OK. If you get a kernel message
that the transmit timed out, then you need this capability since CEC is disabled
without HPD.


I've checked those commands, but on all tested boards (Odroid U3+, 
Odroid XU3 and

Google Snow) I get the following message:

Transmit from Unregistered to TV (255 to 0):
CEC_MSG_IMAGE_VIEW_ON (0x04)
Sequence: 19 Tx Timestamp: 175.935s
Tx, Error (1), Max Retries

I have never got a timeout message from the kernel. Do I need to enable 
some kind

of CEC debugs?

> [...]

Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [PATCH 07/19] [media] dvb-frontends/cxd2841er: make call to i2c_gate_ctrl optional

Acked-by: Abylay Ospan 

2017-04-09 15:38 GMT-04:00 Daniel Scheller :
> From: Daniel Scheller 
>
> Some cards/bridges wrap i2c_gate_ctrl handling with a mutex_lock(). This is
> e.g. done in ddbridge to protect against concurrent tuner access with
> regards to the dual tuner HW, where concurrent tuner reconfiguration can
> result in tuning fails or bad reception quality. When the tuner driver
> additionally tries to open the I2C gate (which e.g. the tda18212 driver
> does) when the demod already did this, this will lead to a deadlock. This
> makes the calls to i2c_gatectrl from the demod driver optional when the
> flag is set, leaving this to the tuner driver. For readability reasons and
> to not have the check duplicated multiple times, the setup is factored
> into cxd2841er_tuner_set().
>
> This commit also updates the netup card driver (which seems to be the only
> consumer of the cxd2841er as of now).
>
> Signed-off-by: Daniel Scheller 
> ---
>  drivers/media/dvb-frontends/cxd2841er.c| 32 
> ++
>  drivers/media/dvb-frontends/cxd2841er.h|  2 ++
>  drivers/media/pci/netup_unidvb/netup_unidvb_core.c |  3 +-
>  3 files changed, 24 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
> b/drivers/media/dvb-frontends/cxd2841er.c
> index f49a09b..162a0f5 100644
> --- a/drivers/media/dvb-frontends/cxd2841er.c
> +++ b/drivers/media/dvb-frontends/cxd2841er.c
> @@ -327,6 +327,20 @@ static u32 cxd2841er_calc_iffreq(u32 ifhz)
> return cxd2841er_calc_iffreq_xtal(SONY_XTAL_20500, ifhz);
>  }
>
> +static int cxd2841er_tuner_set(struct dvb_frontend *fe)
> +{
> +   struct cxd2841er_priv *priv = fe->demodulator_priv;
> +
> +   if ((priv->flags & CXD2841ER_USE_GATECTRL) && fe->ops.i2c_gate_ctrl)
> +   fe->ops.i2c_gate_ctrl(fe, 1);
> +   if (fe->ops.tuner_ops.set_params)
> +   fe->ops.tuner_ops.set_params(fe);
> +   if ((priv->flags & CXD2841ER_USE_GATECTRL) && fe->ops.i2c_gate_ctrl)
> +   fe->ops.i2c_gate_ctrl(fe, 0);
> +
> +   return 0;
> +}
> +
>  static int cxd2841er_dvbs2_set_symbol_rate(struct cxd2841er_priv *priv,
>u32 symbol_rate)
>  {
> @@ -3251,12 +3265,9 @@ static int cxd2841er_set_frontend_s(struct 
> dvb_frontend *fe)
> dev_dbg(>i2c->dev, "%s(): tune failed\n", __func__);
> goto done;
> }
> -   if (fe->ops.i2c_gate_ctrl)
> -   fe->ops.i2c_gate_ctrl(fe, 1);
> -   if (fe->ops.tuner_ops.set_params)
> -   fe->ops.tuner_ops.set_params(fe);
> -   if (fe->ops.i2c_gate_ctrl)
> -   fe->ops.i2c_gate_ctrl(fe, 0);
> +
> +   cxd2841er_tuner_set(fe);
> +
> cxd2841er_tune_done(priv);
> timeout = ((300 + (symbol_rate - 1)) / symbol_rate) + 150;
> for (i = 0; i < timeout / CXD2841ER_DVBS_POLLING_INVL; i++) {
> @@ -3376,12 +3387,9 @@ static int cxd2841er_set_frontend_tc(struct 
> dvb_frontend *fe)
> }
> if (ret)
> goto done;
> -   if (fe->ops.i2c_gate_ctrl)
> -   fe->ops.i2c_gate_ctrl(fe, 1);
> -   if (fe->ops.tuner_ops.set_params)
> -   fe->ops.tuner_ops.set_params(fe);
> -   if (fe->ops.i2c_gate_ctrl)
> -   fe->ops.i2c_gate_ctrl(fe, 0);
> +
> +   cxd2841er_tuner_set(fe);
> +
> cxd2841er_tune_done(priv);
> timeout = 2500;
> while (timeout > 0) {
> diff --git a/drivers/media/dvb-frontends/cxd2841er.h 
> b/drivers/media/dvb-frontends/cxd2841er.h
> index 2fb8b38..15564af 100644
> --- a/drivers/media/dvb-frontends/cxd2841er.h
> +++ b/drivers/media/dvb-frontends/cxd2841er.h
> @@ -24,6 +24,8 @@
>
>  #include 
>
> +#define CXD2841ER_USE_GATECTRL 1
> +
>  enum cxd2841er_xtal {
> SONY_XTAL_20500, /* 20.5 MHz */
> SONY_XTAL_24000, /* 24 MHz */
> diff --git a/drivers/media/pci/netup_unidvb/netup_unidvb_core.c 
> b/drivers/media/pci/netup_unidvb/netup_unidvb_core.c
> index 191bd82..5e6553f 100644
> --- a/drivers/media/pci/netup_unidvb/netup_unidvb_core.c
> +++ b/drivers/media/pci/netup_unidvb/netup_unidvb_core.c
> @@ -122,7 +122,8 @@ static void netup_unidvb_queue_cleanup(struct netup_dma 
> *dma);
>
>  static struct cxd2841er_config demod_config = {
> .i2c_addr = 0xc8,
> -   .xtal = SONY_XTAL_24000
> +   .xtal = SONY_XTAL_24000,
> +   .flags = CXD2841ER_USE_GATECTRL
>  };
>
>  static struct horus3a_config horus3a_conf = {
> --
> 2.10.2
>



-- 
Abylay Ospan,
NetUP Inc.
http://www.netup.tv

Re: [PATCH 06/19] [media] dvb-frontends/cxd2841er: add variable for configuration flags

Acked-by: Abylay Ospan 

2017-04-09 15:38 GMT-04:00 Daniel Scheller :
> From: Daniel Scheller 
>
> Throughout the patch series some configuration flags will be added to the
> demod driver. This patch prepares this by adding the flags var to
> struct cxd2841er_config, which will serve as a bitmask to toggle various
> options and behaviour in the driver.
>
> Signed-off-by: Daniel Scheller 
> ---
>  drivers/media/dvb-frontends/cxd2841er.c | 2 ++
>  drivers/media/dvb-frontends/cxd2841er.h | 1 +
>  2 files changed, 3 insertions(+)
>
> diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
> b/drivers/media/dvb-frontends/cxd2841er.c
> index 6648bd1..f49a09b 100644
> --- a/drivers/media/dvb-frontends/cxd2841er.c
> +++ b/drivers/media/dvb-frontends/cxd2841er.c
> @@ -65,6 +65,7 @@ struct cxd2841er_priv {
> u8  system;
> enum cxd2841er_xtal xtal;
> enum fe_caps caps;
> +   u32 flags;
>  };
>
>  static const struct cxd2841er_cnr_data s_cn_data[] = {
> @@ -3736,6 +3737,7 @@ static struct dvb_frontend *cxd2841er_attach(struct 
> cxd2841er_config *cfg,
> priv->i2c_addr_slvx = (cfg->i2c_addr + 4) >> 1;
> priv->i2c_addr_slvt = (cfg->i2c_addr) >> 1;
> priv->xtal = cfg->xtal;
> +   priv->flags = cfg->flags;
> priv->frontend.demodulator_priv = priv;
> dev_info(>i2c->dev,
> "%s(): I2C adapter %p SLVX addr %x SLVT addr %x\n",
> diff --git a/drivers/media/dvb-frontends/cxd2841er.h 
> b/drivers/media/dvb-frontends/cxd2841er.h
> index 7f1acfb..2fb8b38 100644
> --- a/drivers/media/dvb-frontends/cxd2841er.h
> +++ b/drivers/media/dvb-frontends/cxd2841er.h
> @@ -33,6 +33,7 @@ enum cxd2841er_xtal {
>  struct cxd2841er_config {
> u8  i2c_addr;
> enum cxd2841er_xtal xtal;
> +   u32 flags;
>  };
>
>  #if IS_REACHABLE(CONFIG_DVB_CXD2841ER)
> --
> 2.10.2
>



-- 
Abylay Ospan,
NetUP Inc.
http://www.netup.tv

Re: [PATCH 05/19] [media] dvb-frontends/cxd2841er: replace IFFREQ calc macros into functions

Acked-by: Abylay Ospan 

2017-04-09 15:38 GMT-04:00 Daniel Scheller :
> From: Daniel Scheller 
>
> The way the MAKE_IFFREQ_CONFIG macros are written make it impossible to
> pass regular integers for iffreq calculation, since this will cause "SSE
> register return with SSE disabled" compile errors. This changes the
> calculation into C functions which also might help when debugging. Also,
> expand all passed frequencies from MHz to Hz scale.
>
> Signed-off-by: Daniel Scheller 
> ---
>  drivers/media/dvb-frontends/cxd2841er.c | 48 
> -
>  1 file changed, 29 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
> b/drivers/media/dvb-frontends/cxd2841er.c
> index 72a27cc..6648bd1 100644
> --- a/drivers/media/dvb-frontends/cxd2841er.c
> +++ b/drivers/media/dvb-frontends/cxd2841er.c
> @@ -201,11 +201,6 @@ static const struct cxd2841er_cnr_data s2_cn_data[] = {
> { 0x0016, 19700 }, { 0x0015, 19900 }, { 0x0014, 2 },
>  };
>
> -#define MAKE_IFFREQ_CONFIG(iffreq) ((u32)(((iffreq)/41.0)*16777216.0 + 0.5))
> -#define MAKE_IFFREQ_CONFIG_XTAL(xtal, iffreq) ((xtal == SONY_XTAL_24000) ? \
> -   (u32)(((iffreq)/48.0)*16777216.0 + 0.5) : \
> -   (u32)(((iffreq)/41.0)*16777216.0 + 0.5))
> -
>  static int cxd2841er_freeze_regs(struct cxd2841er_priv *priv);
>  static int cxd2841er_unfreeze_regs(struct cxd2841er_priv *priv);
>
> @@ -316,6 +311,21 @@ static int cxd2841er_set_reg_bits(struct cxd2841er_priv 
> *priv,
> return cxd2841er_write_reg(priv, addr, reg, data);
>  }
>
> +static u32 cxd2841er_calc_iffreq_xtal(enum cxd2841er_xtal xtal, u32 ifhz)
> +{
> +   u64 tmp;
> +
> +   tmp = (u64) ifhz * 16777216;
> +   do_div(tmp, ((xtal == SONY_XTAL_24000) ? 4800 : 4100));
> +
> +   return (u32) tmp;
> +}
> +
> +static u32 cxd2841er_calc_iffreq(u32 ifhz)
> +{
> +   return cxd2841er_calc_iffreq_xtal(SONY_XTAL_20500, ifhz);
> +}
> +
>  static int cxd2841er_dvbs2_set_symbol_rate(struct cxd2841er_priv *priv,
>u32 symbol_rate)
>  {
> @@ -2228,7 +2238,7 @@ static int cxd2841er_sleep_tc_to_active_t2_band(struct 
> cxd2841er_priv *priv,
> cxd2841er_write_regs(priv, I2C_SLVT,
> 0xA6, itbCoef8bw[priv->xtal], 14);
> /*  */
> -   iffreq = MAKE_IFFREQ_CONFIG_XTAL(priv->xtal, 4.80);
> +   iffreq = cxd2841er_calc_iffreq_xtal(priv->xtal, 480);
> data[0] = (u8) ((iffreq >> 16) & 0xff);
> data[1] = (u8)((iffreq >> 8) & 0xff);
> data[2] = (u8)(iffreq & 0xff);
> @@ -2256,7 +2266,7 @@ static int cxd2841er_sleep_tc_to_active_t2_band(struct 
> cxd2841er_priv *priv,
> cxd2841er_write_regs(priv, I2C_SLVT,
> 0xA6, itbCoef7bw[priv->xtal], 14);
> /*  */
> -   iffreq = MAKE_IFFREQ_CONFIG_XTAL(priv->xtal, 4.20);
> +   iffreq = cxd2841er_calc_iffreq_xtal(priv->xtal, 420);
> data[0] = (u8) ((iffreq >> 16) & 0xff);
> data[1] = (u8)((iffreq >> 8) & 0xff);
> data[2] = (u8)(iffreq & 0xff);
> @@ -2284,7 +2294,7 @@ static int cxd2841er_sleep_tc_to_active_t2_band(struct 
> cxd2841er_priv *priv,
> cxd2841er_write_regs(priv, I2C_SLVT,
> 0xA6, itbCoef6bw[priv->xtal], 14);
> /*  */
> -   iffreq = MAKE_IFFREQ_CONFIG_XTAL(priv->xtal, 3.60);
> +   iffreq = cxd2841er_calc_iffreq_xtal(priv->xtal, 360);
> data[0] = (u8) ((iffreq >> 16) & 0xff);
> data[1] = (u8)((iffreq >> 8) & 0xff);
> data[2] = (u8)(iffreq & 0xff);
> @@ -2312,7 +2322,7 @@ static int cxd2841er_sleep_tc_to_active_t2_band(struct 
> cxd2841er_priv *priv,
> cxd2841er_write_regs(priv, I2C_SLVT,
> 0xA6, itbCoef5bw[priv->xtal], 14);
> /*  */
> -   iffreq = MAKE_IFFREQ_CONFIG_XTAL(priv->xtal, 3.60);
> +   iffreq = cxd2841er_calc_iffreq_xtal(priv->xtal, 360);
> data[0] = (u8) ((iffreq >> 16) & 0xff);
> data[1] = (u8)((iffreq >> 8) & 0xff);
> data[2] = (u8)(iffreq & 0xff);
> @@ -2340,7 +2350,7 @@ static int cxd2841er_sleep_tc_to_active_t2_band(struct 
> cxd2841er_priv *priv,
> cxd2841er_write_regs(priv, I2C_SLVT,
> 0xA6, itbCoef17bw[priv->xtal], 14);
> /*  */
> -   iffreq = MAKE_IFFREQ_CONFIG_XTAL(priv->xtal, 3.50);
> +   iffreq = cxd2841er_calc_iffreq_xtal(priv->xtal, 350);
> data[0] = (u8) ((iffreq >> 16) & 0xff);
> data[1] = (u8)((iffreq >> 8) & 0xff);
> data[2] =

Re: [PATCH] ARM: dts: exynos: Add HDMI CEC device to Exynos5 SoC family

On 05/31/17 13:00, Marek Szyprowski wrote:
> Exynos5250 and Exynos542x SoCs have the same CEC hardware module as
> Exynos4 SoC series, so enable support for it using the same compatible
> string.
> 
> Tested on Odroid XU3 (Exynos5422) and Google Snow (Exynos5250) boards.

Thanks!

Do you know if the CEC block is always on for these devices or only if there
is a hotplug signal? That was a problem with the exynos4 odroid.

I have made a patch (not posted yet) to signal this in the device tree and
added a CEC capability to signal this to the user.

This capability will be added to 4.13 (see my patch 'cec: add CEC_CAP_NEEDS_HPD'
from May 25th) since the DisplayPort CEC tunneling feature needs it as well.

It's easy to test: don't connect an HDMI cable and run:

cec-ctl --playback
cec-ctl -t0 --image-view-on

If this returns with a NACK error, then it is OK. If you get a kernel message
that the transmit timed out, then you need this capability since CEC is disabled
without HPD.

Regards,

Hans

> 
> Signed-off-by: Marek Szyprowski 
> ---
>  arch/arm/boot/dts/exynos5250-pinctrl.dtsi  |  7 +++
>  arch/arm/boot/dts/exynos5250-snow-common.dtsi  |  4 
>  arch/arm/boot/dts/exynos5250.dtsi  | 13 +
>  arch/arm/boot/dts/exynos5420-pinctrl.dtsi  |  7 +++
>  arch/arm/boot/dts/exynos5420.dtsi  | 13 +
>  arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi |  4 
>  6 files changed, 48 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi 
> b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
> index 2f6ab32b5954..1fd122db18e6 100644
> --- a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
> @@ -589,6 +589,13 @@
>   samsung,pin-pud = ;
>   samsung,pin-drv = ;
>   };
> +
> + hdmi_cec: hdmi-cec {
> + samsung,pins = "gpx3-6";
> + samsung,pin-function = ;
> + samsung,pin-pud = ;
> + samsung,pin-drv = ;
> + };
>  };
>  
>  _1 {
> diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi 
> b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
> index 8f3a80430748..e1d293dbbe5d 100644
> --- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
> @@ -272,6 +272,10 @@
>   vdd_pll-supply = <_reg>;
>  };
>  
> + {
> + status = "okay";
> +};
> +
>  _0 {
>   status = "okay";
>   samsung,i2c-sda-delay = <100>;
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
> b/arch/arm/boot/dts/exynos5250.dtsi
> index 79c9c885613a..fbdc1d53a2ce 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -689,6 +689,19 @@
>   samsung,syscon-phandle = <_system_controller>;
>   };
>  
> + hdmicec: cec@101B {
> + compatible = "samsung,s5p-cec";
> + reg = <0x101B 0x200>;
> + interrupts = ;
> + clocks = < CLK_HDMI_CEC>;
> + clock-names = "hdmicec";
> + samsung,syscon-phandle = <_system_controller>;
> + hdmi-phandle = <>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_cec>;
> + status = "disabled";
> + };
> +
>   mixer@1445 {
>   compatible = "samsung,exynos5250-mixer";
>   reg = <0x1445 0x1>;
> diff --git a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi 
> b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
> index 3924b4fafe72..65aa0e300c23 100644
> --- a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
> @@ -67,6 +67,13 @@
>   samsung,pin-pud = ;
>   samsung,pin-drv = ;
>   };
> +
> + hdmi_cec: hdmi-cec {
> + samsung,pins = "gpx3-6";
> + samsung,pin-function = ;
> + samsung,pin-pud = ;
> + samsung,pin-drv = ;
> + };
>  };
>  
>  _1 {
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
> b/arch/arm/boot/dts/exynos5420.dtsi
> index 0db0bcf8da36..acd77b10b3df 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -624,6 +624,19 @@
>   reg = <0x145D 0x20>;
>   };
>  
> + hdmicec: cec@101B {
> + compatible = "samsung,s5p-cec";
> + reg = <0x101B 0x200>;
> + interrupts = ;
> + clocks = < CLK_HDMI_CEC>;
> + clock-names = "hdmicec";
> + samsung,syscon-phandle = <_system_controller>;
> + hdmi-phandle = <>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_cec>;
> + status = "disabled";
> +

Re: [ANN] HDMI CEC Status Update


Hi Andrzej and Hans,

On 2017-05-31 10:12, Andrzej Hajda wrote:

On 30.05.2017 08:53, Hans Verkuil wrote:

For those who are interested in HDMI CEC support I made a little status
document that I intend to keep up to date:

https://hverkuil.home.xs4all.nl/cec-status.txt

My goal is to get CEC supported for any mainlined HDMI driver where the hardware
supports CEC.

If anyone is working on a CEC driver that I don't know already about, just drop
me an email so I can update the status.

Sii8620 HDMI->MHL bridge is on my TODO list.
Regarding Exynos5 it is apparently the same IP as in Exynos4.


I've just posted a patch enabling CEC module on Exynos5250 (Google Snow)
and Exynos5422 (Odroid XU3).

Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

[PATCH] ARM: dts: exynos: Add HDMI CEC device to Exynos5 SoC family

Exynos5250 and Exynos542x SoCs have the same CEC hardware module as
Exynos4 SoC series, so enable support for it using the same compatible
string.

Tested on Odroid XU3 (Exynos5422) and Google Snow (Exynos5250) boards.

Signed-off-by: Marek Szyprowski 
---
 arch/arm/boot/dts/exynos5250-pinctrl.dtsi  |  7 +++
 arch/arm/boot/dts/exynos5250-snow-common.dtsi  |  4 
 arch/arm/boot/dts/exynos5250.dtsi  | 13 +
 arch/arm/boot/dts/exynos5420-pinctrl.dtsi  |  7 +++
 arch/arm/boot/dts/exynos5420.dtsi  | 13 +
 arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi |  4 
 6 files changed, 48 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi 
b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
index 2f6ab32b5954..1fd122db18e6 100644
--- a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
@@ -589,6 +589,13 @@
samsung,pin-pud = ;
samsung,pin-drv = ;
};
+
+   hdmi_cec: hdmi-cec {
+   samsung,pins = "gpx3-6";
+   samsung,pin-function = ;
+   samsung,pin-pud = ;
+   samsung,pin-drv = ;
+   };
 };
 
 _1 {
diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi 
b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
index 8f3a80430748..e1d293dbbe5d 100644
--- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
@@ -272,6 +272,10 @@
vdd_pll-supply = <_reg>;
 };
 
+ {
+   status = "okay";
+};
+
 _0 {
status = "okay";
samsung,i2c-sda-delay = <100>;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 79c9c885613a..fbdc1d53a2ce 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -689,6 +689,19 @@
samsung,syscon-phandle = <_system_controller>;
};
 
+   hdmicec: cec@101B {
+   compatible = "samsung,s5p-cec";
+   reg = <0x101B 0x200>;
+   interrupts = ;
+   clocks = < CLK_HDMI_CEC>;
+   clock-names = "hdmicec";
+   samsung,syscon-phandle = <_system_controller>;
+   hdmi-phandle = <>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_cec>;
+   status = "disabled";
+   };
+
mixer@1445 {
compatible = "samsung,exynos5250-mixer";
reg = <0x1445 0x1>;
diff --git a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi 
b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
index 3924b4fafe72..65aa0e300c23 100644
--- a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
@@ -67,6 +67,13 @@
samsung,pin-pud = ;
samsung,pin-drv = ;
};
+
+   hdmi_cec: hdmi-cec {
+   samsung,pins = "gpx3-6";
+   samsung,pin-function = ;
+   samsung,pin-pud = ;
+   samsung,pin-drv = ;
+   };
 };
 
 _1 {
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 0db0bcf8da36..acd77b10b3df 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -624,6 +624,19 @@
reg = <0x145D 0x20>;
};
 
+   hdmicec: cec@101B {
+   compatible = "samsung,s5p-cec";
+   reg = <0x101B 0x200>;
+   interrupts = ;
+   clocks = < CLK_HDMI_CEC>;
+   clock-names = "hdmicec";
+   samsung,syscon-phandle = <_system_controller>;
+   hdmi-phandle = <>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_cec>;
+   status = "disabled";
+   };
+
mixer: mixer@1445 {
compatible = "samsung,exynos5420-mixer";
reg = <0x1445 0x1>;
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 05b9afdd6757..01d6ac99e974 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -265,6 +265,10 @@
vdd-supply = <_reg>;
 };
 
+ {
+   status = "okay";
+};
+
 _4 {
status = "okay";
 
-- 
1.9.1

[PATCH] cec: improve debug messages

- use __func__ instead of writing the full function name
- drop debug message in cec_config_log_addr since the same information
  will be reported later
- use debug level 1 for errors and infrequent events, use level 2 for
  debugging CEC message traffic
- log when a transmit is retried, very useful to know when debugging
- debug messages now all start with lower case

Signed-off-by: Hans Verkuil 
---
 drivers/media/cec/cec-adap.c | 28 
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index f5fe01c9da8a..f85eae710043 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -392,7 +392,7 @@ int cec_thread_func(void *_adap)
 * happen and is an indication of a faulty CEC adapter
 * driver, or the CEC bus is in some weird state.
 */
-   dprintk(0, "message %*ph timed out!\n",
+   dprintk(0, "%s: message %*ph timed out!\n", __func__,
adap->transmitting->msg.len,
adap->transmitting->msg.msg);
/* Just give up on this. */
@@ -468,7 +468,7 @@ void cec_transmit_done(struct cec_adapter *adap, u8 status, 
u8 arb_lost_cnt,
struct cec_msg *msg;
u64 ts = ktime_get_ns();

-   dprintk(2, "cec_transmit_done %02x\n", status);
+   dprintk(2, "%s: status %02x\n", __func__, status);
mutex_lock(>lock);
data = adap->transmitting;
if (!data) {
@@ -477,7 +477,8 @@ void cec_transmit_done(struct cec_adapter *adap, u8 status, 
u8 arb_lost_cnt,
 * unplugged while the transmit is ongoing. Ignore this
 * transmit in that case.
 */
-   dprintk(1, "cec_transmit_done without an ongoing transmit!\n");
+   dprintk(1, "%s was called without an ongoing transmit!\n",
+   __func__);
goto unlock;
}

@@ -504,6 +505,12 @@ void cec_transmit_done(struct cec_adapter *adap, u8 
status, u8 arb_lost_cnt,
!(status & (CEC_TX_STATUS_MAX_RETRIES | CEC_TX_STATUS_OK))) {
/* Retry this message */
data->attempts--;
+   if (msg->timeout)
+   dprintk(2, "retransmit: %*ph (attempts: %d, wait for 
0x%02x)\n",
+   msg->len, msg->msg, data->attempts, msg->reply);
+   else
+   dprintk(2, "retransmit: %*ph (attempts: %d)\n",
+   msg->len, msg->msg, data->attempts);
/* Add the message in front of the transmit queue */
list_add(>list, >transmit_queue);
adap->transmit_queue_sz++;
@@ -911,7 +918,7 @@ void cec_received_msg(struct cec_adapter *adap, struct 
cec_msg *msg)
memset(msg->msg + msg->len, 0, sizeof(msg->msg) - msg->len);

mutex_lock(>lock);
-   dprintk(2, "cec_received_msg: %*ph\n", msg->len, msg->msg);
+   dprintk(2, "%s: %*ph\n", __func__, msg->len, msg->msg);

/* Check if this message was for us (directed or broadcast). */
if (!cec_msg_is_broadcast(msg))
@@ -1112,9 +1119,6 @@ static int cec_config_log_addr(struct cec_adapter *adap,
las->log_addr[idx] = log_addr;
las->log_addr_mask |= 1 << log_addr;
adap->phys_addrs[log_addr] = adap->phys_addr;
-
-   dprintk(2, "claimed addr %d (%d)\n", log_addr,
-   las->primary_device_type[idx]);
return 1;
 }

@@ -1300,7 +1304,7 @@ static int cec_config_thread_func(void *arg)
/* Report Physical Address */
cec_msg_report_physical_addr(, adap->phys_addr,
 las->primary_device_type[i]);
-   dprintk(2, "config: la %d pa %x.%x.%x.%x\n",
+   dprintk(1, "config: la %d pa %x.%x.%x.%x\n",
las->log_addr[i],
cec_phys_addr_exp(adap->phys_addr));
cec_transmit_msg_fh(adap, , NULL, false);
@@ -1534,12 +1538,12 @@ int __cec_s_log_addrs(struct cec_adapter *adap,
if (log_addrs->num_log_addrs == 2) {
if (!(type_mask & ((1 << CEC_LOG_ADDR_TYPE_AUDIOSYSTEM) 
|
   (1 << CEC_LOG_ADDR_TYPE_TV {
-   dprintk(1, "Two LAs is only allowed for 
audiosystem and TV\n");
+   dprintk(1, "two LAs is only allowed for 
audiosystem and TV\n");
return -EINVAL;
}
if (!(type_mask & ((1 << CEC_LOG_ADDR_TYPE_PLAYBACK) |
   (1 << CEC_LOG_ADDR_TYPE_RECORD {
-   dprintk(1, "An audiosystem/TV can only be 
combined with record or

[PATCH] [media] tc358743: Handle return value of clk_prepare_enable

2017-05-31 Thread Arvind Yadav

clk_prepare_enable() can fail here and we must check its return value.

Signed-off-by: Arvind Yadav 
---
 drivers/media/i2c/tc358743.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c
index acef4ec..0b30f7b 100644
--- a/drivers/media/i2c/tc358743.c
+++ b/drivers/media/i2c/tc358743.c
@@ -1730,7 +1730,11 @@ static int tc358743_probe_of(struct tc358743_state 
*state)
 
state->bus = endpoint->bus.mipi_csi2;
 
-   clk_prepare_enable(refclk);
+   ret = clk_prepare_enable(refclk);
+   if (ret) {
+   dev_err(dev, "Failed! to enable clock\n");
+   goto free_endpoint;
+   }
 
state->pdata.refclk_hz = clk_get_rate(refclk);
state->pdata.ddc5v_delay = DDC5V_DELAY_100_MS;
-- 
1.9.1

Re: [PATCH v5 1/1] [media] i2c: add support for OV13858 sensor

Hi Hyungwoo,

A few minor comments more. Then I think we're done.

On Wed, May 31, 2017 at 01:09:28AM -0700, Hyungwoo Yang wrote:
> This patch adds driver for Omnivision's ov13858
> sensor, the driver supports following features:
> 
> - manual exposure/analog gain
> - two link frequencies
> - VBLANK support
> - test pattern support
> - media controller support
> - runtime pm support

Could you list the resolutions and frame rates the driver supports here as
well?

> 
> Signed-off-by: Hyungwoo Yang 
> ---
>  drivers/media/i2c/Kconfig   |8 +
>  drivers/media/i2c/Makefile  |1 +
>  drivers/media/i2c/ov13858.c | 1739 
> +++
>  3 files changed, 1748 insertions(+)
>  create mode 100644 drivers/media/i2c/ov13858.c
> 
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index fd181c9..f8c5cca 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -589,6 +589,14 @@ config VIDEO_OV9650
> This is a V4L2 sensor-level driver for the Omnivision
> OV9650 and OV9652 camera sensors.
>  
> +config VIDEO_OV13858
> + tristate "OmniVision OV13858 sensor support"
> + depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> + depends on MEDIA_CAMERA_SUPPORT
> + ---help---
> +   This is a Video4Linux2 sensor-level driver for the OmniVision
> +   OV13858 camera.
> +
>  config VIDEO_VS6624
>   tristate "ST VS6624 sensor support"
>   depends on VIDEO_V4L2 && I2C
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index 62323ec..3f4dc02 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -63,6 +63,7 @@ obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
>  obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
>  obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
>  obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
> +obj-$(CONFIG_VIDEO_OV13858) += ov13858.o
>  obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
>  obj-$(CONFIG_VIDEO_MT9M111) += mt9m111.o
>  obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
> diff --git a/drivers/media/i2c/ov13858.c b/drivers/media/i2c/ov13858.c
> new file mode 100644
> index 000..bff865a
> --- /dev/null
> +++ b/drivers/media/i2c/ov13858.c
> @@ -0,0 +1,1739 @@
> +/*
> + * 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 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define OV13858_REG_VALUE_08BIT  1
> +#define OV13858_REG_VALUE_16BIT  2
> +#define OV13858_REG_VALUE_24BIT  3
> +
> +#define OV13858_REG_MODE_SELECT  0x0100
> +#define OV13858_MODE_STANDBY 0x00
> +#define OV13858_MODE_STREAMING   0x01
> +
> +#define OV13858_REG_SOFTWARE_RST 0x0103
> +#define OV13858_SOFTWARE_RST 0x01
> +
> +/* PLL1 generates PCLK and MIPI_PHY_CLK */
> +#define OV13858_REG_PLL1_CTRL_0  0x0300
> +#define OV13858_REG_PLL1_CTRL_1  0x0301
> +#define OV13858_REG_PLL1_CTRL_2  0x0302
> +#define OV13858_REG_PLL1_CTRL_3  0x0303
> +#define OV13858_REG_PLL1_CTRL_4  0x0304
> +#define OV13858_REG_PLL1_CTRL_5  0x0305
> +
> +/* PLL2 generates DAC_CLK, SCLK and SRAM_CLK */
> +#define OV13858_REG_PLL2_CTRL_B  0x030b
> +#define OV13858_REG_PLL2_CTRL_C  0x030c
> +#define OV13858_REG_PLL2_CTRL_D  0x030d
> +#define OV13858_REG_PLL2_CTRL_E  0x030e
> +#define OV13858_REG_PLL2_CTRL_F  0x030f
> +#define OV13858_REG_PLL2_CTRL_12 0x0312
> +#define OV13858_REG_MIPI_SC_CTRL00x3016
> +#define OV13858_REG_MIPI_SC_CTRL10x3022
> +
> +/* Chip ID */
> +#define OV13858_REG_CHIP_ID  0x300a
> +#define OV13858_CHIP_ID  0x00d855
> +
> +/* V_TIMING internal */
> +#define OV13858_REG_VTS  0x380e
> +#define OV13858_VTS_30FPS0x0c8e /* 30 fps */
> +#define OV13858_VTS_60FPS0x0648 /* 60 fps */
> +#define OV13858_VTS_MAX  0x7fff
> +#define OV13858_VBLANK_MIN   56
> +
> +/* Exposure control */
> +#define OV13858_REG_EXPOSURE 0x3500
> +#define OV13858_EXPOSURE_MIN 4
> +#define OV13858_EXPOSURE_MAX (OV13858_VTS_MAX - 8)
> +#define OV13858_EXPOSURE_STEP1
> +#define OV13858_EXPOSURE_DEFAULT 0x640
> +
> +/* Analog gain control */
> +#define OV13858_REG_ANALOG_GAIN  0x3508
> +#define OV13858_ANA_GAIN_MIN 0
> +#define OV13858_ANA_GAIN_MAX 0x1fff

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

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

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

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

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

Signed-off-by: Ramesh Shanmugasundaram 
---
v6:
 - Used fwnode_ apis wherever applicable.
 - Cleaned up debug prints.

---
 drivers/media/platform/Kconfig |   25 +
 drivers/media/platform/Makefile|1 +
 drivers/media/platform/rcar_drif.c | 1500 
 3 files changed, 1526 insertions(+)
 create mode 100644 drivers/media/platform/rcar_drif.c

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

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

Hi Media, DT maintainers, All,

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

These patches were based on top of Sakari's v4l2-acpi tag as requested.
repo: git://git.linuxtv.org/sailus/media_tree.git
branch: v4l2-acpi
commit: 575cafad3859ae42e83538b1c60d2beb51bd845f

https://www.spinics.net/lists/linux-media/msg116129.html

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

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

Change history:

v5 -> v6:
 - Addressed Sakari's comments & rebased to his branch.
 - Used fwnode_ instead of of_ apis whereever applicable.

v4 -> v5:
 - Minor documentation changes. Refer individual patches.

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

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

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

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

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

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

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

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

Required ioctls:
test VIDIOC_QUERYCAP: OK

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

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

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

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

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

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

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

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

Buffer ioctls:

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

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

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

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

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

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

Signed-off-by: Ramesh Shanmugasundaram 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/media/renesas,drif.txt | 176 +
 1 file changed, 176 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/renesas,drif.txt

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

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

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

Signed-off-by: Ramesh Shanmugasundaram 
Acked-by: Rob Herring 
---
v6:
 - clocks property updated.
 - pico-farads renamed to picofarads (Sakari).

v5:
 - pF in property-units.txt is renamed to pico-farads (Geert)
 - "maxim,refout-load-pF" is renamed to "maxim,refout-load".
---
 .../devicetree/bindings/media/i2c/max2175.txt  | 59 ++
 .../devicetree/bindings/property-units.txt |  1 +
 2 files changed, 60 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/max2175.txt

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

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

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

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

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

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

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

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

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

This patch adds documentation for the three new SDR formats

V4L2_SDR_FMT_PCU16BE
V4L2_SDR_FMT_PCU18BE
V4L2_SDR_FMT_PCU20BE

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

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

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

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

Signed-off-by: Ramesh Shanmugasundaram 
---
v6:
 - Addressed Sakari's comments. They are:
- Added uapi header file.
- Added newline at the end of the function before return.
- Cleaned up header file inclusion.
- Used fwnode_ apis whereever applicable.
- Cleaned up debug statements.
- Removed separate dir for max2175.
 
v5:
 - sck -> Sample clock is clarified in driver documentation (Hans)
 - "refout-load-pF" is renamed to "refout-load" as per updated bindings.
---
 Documentation/media/v4l-drivers/index.rst   |1 +
 Documentation/media/v4l-drivers/max2175.rst |   60 ++
 drivers/media/i2c/Kconfig   |   12 +
 drivers/media/i2c/Makefile  |2 +
 drivers/media/i2c/max2175.c | 1448 +++
 drivers/media/i2c/max2175.h |  107 ++
 include/uapi/linux/max2175.h|   28 +
 7 files changed, 1658 insertions(+)
 create mode 100644 Documentation/media/v4l-drivers/max2175.rst
 create mode 100644 drivers/media/i2c/max2175.c
 create mode 100644 drivers/media/i2c/max2175.h
 create mode 100644 include/uapi/linux/max2175.h

diff --git a/Documentation/media/v4l-drivers/index.rst 
b/Documentation/media/v4l-drivers/index.rst
index 90fe22a6414a..2e24d6806052 100644
--- a/Documentation/media/v4l-drivers/index.rst
+++ b/Documentation/media/v4l-drivers/index.rst
@@ -42,6 +42,7 @@ For more details see the file COPYING in the source 
distribution of Linux.
davinci-vpbe
fimc
ivtv
+   max2175
meye
omap3isp
omap4_camera
diff --git a/Documentation/media/v4l-drivers/max2175.rst 
b/Documentation/media/v4l-drivers/max2175.rst
new file mode 100644
index ..94fb815f043b
--- /dev/null
+++ b/Documentation/media/v4l-drivers/max2175.rst
@@ -0,0 +1,60 @@
+Maxim Integrated MAX2175 RF to bits tuner driver
+
+
+The MAX2175 driver implements the following driver-specific controls:
+
+``V4L2_CID_MAX2175_I2S_ENABLE``
+---
+Enable/Disable I2S output of the tuner.
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 4
+
+* - ``(0)``
+  - I2S output is disabled.
+* - ``(1)``
+  - I2S output is enabled.
+
+``V4L2_CID_MAX2175_HSLS``
+-
+The high-side/low-side (HSLS) control of the tuner for a given band.
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 4
+
+* - ``(0)``
+  - The LO frequency position is below the desired frequency.
+* - ``(1)``
+  - The LO frequency position is above the desired frequency.
+
+``V4L2_CID_MAX2175_RX_MODE (menu)``
+---
+The Rx mode controls a number of preset parameters of the tuner like
+sample clock (sck), sampling rate etc. These multiple settings are
+provided under one single label called Rx mode in the datasheet. The
+list below shows the supported modes with a brief description.
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 4
+
+* - ``"Europe modes"``
+* - ``"FM 1.2" (0)``
+  - This configures FM band with a sample rate of 0.512 million
+samples/sec with a 10.24 MHz sck.
+* - ``"DAB 1.2" (1)``
+  - This configures VHF band with a sample rate of 2.048 million
+samples/sec with a 32.768 MHz sck.
+
+* - ``"North America modes"``
+* - ``"FM 1.0" (0)``
+  - This configures FM band with a sample rate of 0.7441875 million
+samples/sec with a 14.88375 MHz sck.
+* - ``"DAB 1.2" (1)``
+  - This configures FM band with a sample rate of 0.372 million
+samples/sec with a 7.441875 MHz sck.
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 7c23b7a1fd05..5e94935c0822 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -793,6 +793,18 @@ config VIDEO_SAA6752HS
  To compile this driver as a module, choose M here: the
  module will be called saa6752hs.
 
+comment "SDR tuner chips"
+
+config SDR_MAX2175
+   tristate "Maxim 2175 RF to Bits tuner"
+   depends on VIDEO_V4L2 && MEDIA_SDR_SUPPORT && I2C
+   ---help---
+ Support for Maxim 2175 tuner. It is an advanced analog/digital
+ radio receiver with RF-to-Bits front-end designed for SDR solutions.
+
+ To compile this driver as a module, choose M here; the
+ module will be called max2175.
+
 comment "Miscellaneous helper chips"
 
 config VIDEO_THS7303
diff --git a/drivers/media/i2c/Makefile

Re: [ANN] HDMI CEC Status Update

2017-05-31 Thread Andrzej Hajda

On 30.05.2017 08:53, Hans Verkuil wrote:
> For those who are interested in HDMI CEC support I made a little status
> document that I intend to keep up to date:
>
> https://hverkuil.home.xs4all.nl/cec-status.txt
>
> My goal is to get CEC supported for any mainlined HDMI driver where the 
> hardware
> supports CEC.
>
> If anyone is working on a CEC driver that I don't know already about, just 
> drop
> me an email so I can update the status.

Sii8620 HDMI->MHL bridge is on my TODO list.
Regarding Exynos5 it is apparently the same IP as in Exynos4.

Regards
Andrzej

[PATCH v5 1/1] [media] i2c: add support for OV13858 sensor

2017-05-31 Thread Hyungwoo Yang

This patch adds driver for Omnivision's ov13858
sensor, the driver supports following features:

- manual exposure/analog gain
- two link frequencies
- VBLANK support
- test pattern support
- media controller support
- runtime pm support

Signed-off-by: Hyungwoo Yang 
---
 drivers/media/i2c/Kconfig   |8 +
 drivers/media/i2c/Makefile  |1 +
 drivers/media/i2c/ov13858.c | 1739 +++
 3 files changed, 1748 insertions(+)
 create mode 100644 drivers/media/i2c/ov13858.c

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index fd181c9..f8c5cca 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -589,6 +589,14 @@ config VIDEO_OV9650
  This is a V4L2 sensor-level driver for the Omnivision
  OV9650 and OV9652 camera sensors.
 
+config VIDEO_OV13858
+   tristate "OmniVision OV13858 sensor support"
+   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV13858 camera.
+
 config VIDEO_VS6624
tristate "ST VS6624 sensor support"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 62323ec..3f4dc02 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
 obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
 obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
 obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
+obj-$(CONFIG_VIDEO_OV13858) += ov13858.o
 obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
 obj-$(CONFIG_VIDEO_MT9M111) += mt9m111.o
 obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
diff --git a/drivers/media/i2c/ov13858.c b/drivers/media/i2c/ov13858.c
new file mode 100644
index 000..bff865a
--- /dev/null
+++ b/drivers/media/i2c/ov13858.c
@@ -0,0 +1,1739 @@
+/*
+ * 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 
+#include 
+#include 
+#include 
+#include 
+
+#define OV13858_REG_VALUE_08BIT1
+#define OV13858_REG_VALUE_16BIT2
+#define OV13858_REG_VALUE_24BIT3
+
+#define OV13858_REG_MODE_SELECT0x0100
+#define OV13858_MODE_STANDBY   0x00
+#define OV13858_MODE_STREAMING 0x01
+
+#define OV13858_REG_SOFTWARE_RST   0x0103
+#define OV13858_SOFTWARE_RST   0x01
+
+/* PLL1 generates PCLK and MIPI_PHY_CLK */
+#define OV13858_REG_PLL1_CTRL_00x0300
+#define OV13858_REG_PLL1_CTRL_10x0301
+#define OV13858_REG_PLL1_CTRL_20x0302
+#define OV13858_REG_PLL1_CTRL_30x0303
+#define OV13858_REG_PLL1_CTRL_40x0304
+#define OV13858_REG_PLL1_CTRL_50x0305
+
+/* PLL2 generates DAC_CLK, SCLK and SRAM_CLK */
+#define OV13858_REG_PLL2_CTRL_B0x030b
+#define OV13858_REG_PLL2_CTRL_C0x030c
+#define OV13858_REG_PLL2_CTRL_D0x030d
+#define OV13858_REG_PLL2_CTRL_E0x030e
+#define OV13858_REG_PLL2_CTRL_F0x030f
+#define OV13858_REG_PLL2_CTRL_12   0x0312
+#define OV13858_REG_MIPI_SC_CTRL0  0x3016
+#define OV13858_REG_MIPI_SC_CTRL1  0x3022
+
+/* Chip ID */
+#define OV13858_REG_CHIP_ID0x300a
+#define OV13858_CHIP_ID0x00d855
+
+/* V_TIMING internal */
+#define OV13858_REG_VTS0x380e
+#define OV13858_VTS_30FPS  0x0c8e /* 30 fps */
+#define OV13858_VTS_60FPS  0x0648 /* 60 fps */
+#define OV13858_VTS_MAX0x7fff
+#define OV13858_VBLANK_MIN 56
+
+/* Exposure control */
+#define OV13858_REG_EXPOSURE   0x3500
+#define OV13858_EXPOSURE_MIN   4
+#define OV13858_EXPOSURE_MAX   (OV13858_VTS_MAX - 8)
+#define OV13858_EXPOSURE_STEP  1
+#define OV13858_EXPOSURE_DEFAULT   0x640
+
+/* Analog gain control */
+#define OV13858_REG_ANALOG_GAIN0x3508
+#define OV13858_ANA_GAIN_MIN   0
+#define OV13858_ANA_GAIN_MAX   0x1fff
+#define OV13858_ANA_GAIN_STEP  1
+#define OV13858_ANA_GAIN_DEFAULT   0x80
+
+/* Test Pattern Control */
+#define OV13858_REG_TEST_PATTERN   0x4503
+#define OV13858_TEST_PATTERN_ENABLEBIT(7)
+#define OV13858_TEST_PATTERN_MASK  0xfc
+
+/* Number of frames to skip */
+#define OV13858_NUM_OF_SKIP_FRAMES 2
+
+struct ov13858_reg {
+   u16 address;
+   u8

[PATCH RFC] v4l2-core: Use kvmalloc() for potentially big allocations

2017-05-31 Thread Tomasz Figa

There are multiple places where arrays or otherwise variable sized
buffer are allocated through V4L2 core code, including things like
controls, memory pages, staging buffers for ioctls and so on. Such
allocations can potentially require an order > 0 allocation from the
page allocator, which is not guaranteed to be fulfilled and is likely to
fail on a system with severe memory fragmentation (e.g. a system with
very long uptime).

Since the memory being allocated is intended to be used by the CPU
exclusively, we can consider using vmalloc() as a fallback and this is
exactly what the recently merged kvmalloc() helpers do. A kmalloc() call
is still attempted, even for order > 0 allocations, but it is done
with __GFP_NORETRY and __GFP_NOWARN, with expectation of failing if
requested memory is not available instantly. Only then the vmalloc()
fallback is used. This should give us fast and more reliable allocations
even on systems with higher memory pressure and/or more fragmentation,
while still retaining the same performance level on systems not
suffering from such conditions.

While at it, replace explicit array size calculations on changed
allocations with kvmalloc_array().

Signed-off-by: Tomasz Figa 
---
 drivers/media/v4l2-core/v4l2-async.c   |  4 ++--
 drivers/media/v4l2-core/v4l2-ctrls.c   | 25 +
 drivers/media/v4l2-core/v4l2-event.c   |  8 +---
 drivers/media/v4l2-core/v4l2-ioctl.c   |  6 +++---
 drivers/media/v4l2-core/v4l2-subdev.c  |  7 ---
 drivers/media/v4l2-core/videobuf2-dma-sg.c |  8 
 6 files changed, 31 insertions(+), 27 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-async.c 
b/drivers/media/v4l2-core/v4l2-async.c
index 96cc733f35ef..2d2d9f1f8831 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -204,7 +204,7 @@ void v4l2_async_notifier_unregister(struct 
v4l2_async_notifier *notifier)
if (!notifier->v4l2_dev)
return;
 
-   dev = kmalloc_array(n_subdev, sizeof(*dev), GFP_KERNEL);
+   dev = kvmalloc_array(n_subdev, sizeof(*dev), GFP_KERNEL);
if (!dev) {
dev_err(notifier->v4l2_dev->dev,
"Failed to allocate device cache!\n");
@@ -260,7 +260,7 @@ void v4l2_async_notifier_unregister(struct 
v4l2_async_notifier *notifier)
}
put_device(d);
}
-   kfree(dev);
+   kvfree(dev);
 
notifier->v4l2_dev = NULL;
 
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
b/drivers/media/v4l2-core/v4l2-ctrls.c
index ec42872d11cf..88025527c67e 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -1745,8 +1745,9 @@ int v4l2_ctrl_handler_init_class(struct v4l2_ctrl_handler 
*hdl,
INIT_LIST_HEAD(>ctrls);
INIT_LIST_HEAD(>ctrl_refs);
hdl->nr_of_buckets = 1 + nr_of_controls_hint / 8;
-   hdl->buckets = kcalloc(hdl->nr_of_buckets, sizeof(hdl->buckets[0]),
-  GFP_KERNEL);
+   hdl->buckets = kvmalloc_array(hdl->nr_of_buckets,
+ sizeof(hdl->buckets[0]),
+ GFP_KERNEL | __GFP_ZERO);
hdl->error = hdl->buckets ? 0 : -ENOMEM;
return hdl->error;
 }
@@ -1773,9 +1774,9 @@ void v4l2_ctrl_handler_free(struct v4l2_ctrl_handler *hdl)
list_del(>node);
list_for_each_entry_safe(sev, next_sev, >ev_subs, node)
list_del(>node);
-   kfree(ctrl);
+   kvfree(ctrl);
}
-   kfree(hdl->buckets);
+   kvfree(hdl->buckets);
hdl->buckets = NULL;
hdl->cached = NULL;
hdl->error = 0;
@@ -2022,7 +2023,7 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct 
v4l2_ctrl_handler *hdl,
 is_array)
sz_extra += 2 * tot_ctrl_size;
 
-   ctrl = kzalloc(sizeof(*ctrl) + sz_extra, GFP_KERNEL);
+   ctrl = kvzalloc(sizeof(*ctrl) + sz_extra, GFP_KERNEL);
if (ctrl == NULL) {
handler_set_err(hdl, -ENOMEM);
return NULL;
@@ -2071,7 +2072,7 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct 
v4l2_ctrl_handler *hdl,
}
 
if (handler_new_ref(hdl, ctrl)) {
-   kfree(ctrl);
+   kvfree(ctrl);
return NULL;
}
mutex_lock(hdl->lock);
@@ -2824,8 +2825,8 @@ int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl, 
struct v4l2_ext_controls *cs
return class_check(hdl, cs->which);
 
if (cs->count > ARRAY_SIZE(helper)) {
-   helpers = kmalloc_array(cs->count, sizeof(helper[0]),
-   GFP_KERNEL);
+   helpers = kvmalloc_array(cs->count, sizeof(helper[0]),
+GFP_KERNEL);
if (helpers == NULL)
return -ENOMEM;
}
@@ -2877,7

Re: [RFC PATCH 6/7] drm: add support for DisplayPort CEC-Tunneling-over-AUX


On 05/31/2017 01:57 AM, Clint Taylor wrote:



On 05/26/2017 12:18 AM, Daniel Vetter wrote:

On Thu, May 25, 2017 at 05:06:25PM +0200, Hans Verkuil wrote:

From: Hans Verkuil 

This adds support for the DisplayPort CEC-Tunneling-over-AUX
feature that is part of the DisplayPort 1.3 standard.

Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a
chip that has this capability actually hook up the CEC pin, so
even though a CEC device is created, it may not actually work.

Signed-off-by: Hans Verkuil 
---
   drivers/gpu/drm/Kconfig  |   3 +
   drivers/gpu/drm/Makefile |   1 +
   drivers/gpu/drm/drm_dp_cec.c | 196 
+++
   include/drm/drm_dp_helper.h  |  24 ++
   4 files changed, 224 insertions(+)
   create mode 100644 drivers/gpu/drm/drm_dp_cec.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 78d7fc0ebb57..dd771ce8a3d0 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -120,6 +120,9 @@ config DRM_LOAD_EDID_FIRMWARE
  default case is N. Details and instructions how to build your own
  EDID data are given in Documentation/EDID/HOWTO.txt.
   
+config DRM_DP_CEC

+   bool

We generally don't bother with a Kconfig for every little bit in drm, not
worth the trouble (yes I know there's some exceptions, but somehow they're
all from soc people). Just smash this into the KMS_HELPER one and live is
much easier for drivers. Also allows you to drop the dummy inline
functions.

All of the functions like cec_register_adapter() require
CONFIG_MEDIA_CEC_SUPPORT.
This will add a new dependency to the DRM drivers. All instances of
CONFIG_DRM_DP_CEC should be changed to CONFIG_MEDIA_CEC_SUPPORT so drm
can still be used without the media CEC drivers.


This has changed in the next version. I realized the same thing and there
are CEC core patches pending for 4.12 to solve this.

I plan on posting a new patch series for this later this week, and that
will include those patches for 4.12 so it is easier to test this.

Regards,

Hans

Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

On 05/31/2017 01:25 AM, Clint Taylor wrote:

On 05/30/2017 02:29 PM, Hans Verkuil wrote:

On 05/30/2017 10:32 PM, Clint Taylor wrote:

On 05/30/2017 09:54 AM, Hans Verkuil wrote:

On 05/30/2017 06:49 PM, Hans Verkuil wrote:

On 05/30/2017 04:19 PM, Clint Taylor wrote:

On 05/30/2017 12:11 AM, Jani Nikula wrote:

On Tue, 30 May 2017, Hans Verkuil wrote:

On 05/29/2017 09:00 PM, Daniel Vetter wrote:

On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:

On 05/26/2017 09:15 AM, Daniel Vetter wrote:

Did you look into also wiring this up for dp mst chains?

Isn't this sufficient? I have no way of testing mst chains.

I think I need some pointers from you, since I am a complete
newbie when it
comes to mst.

I don't really have more clue, but yeah if you don't have an mst
thing (a
simple dp port multiplexer is what I use for testing here, then
plug in a
converter dongle or cable into that) then probably better to not
wire up
the code for it.

I think my NUC already uses mst internally. But I was planning on
buying a
dp multiplexer to make sure there is nothing special I need to do
for mst.

The CEC Tunneling is all in the branch device, so if I understand
things
correctly it is not affected by mst.

BTW, I did a bit more testing on my NUC7i5BNK: for the HDMI output
they
use a MegaChip MCDP2800 DP-to-HDMI converter which according to
their
datasheet is supposed to implement CEC Tunneling, but if they do
it is not
exposed as a capability. I'm not sure if it is a MegaChip firmware
issue
or something else. The BIOS is able to do some CEC, but whether
they hook
into the MegaChip or have the CEC pin connected to a GPIO or
something and
have their own controller is something I do not know.

If anyone can clarify what Intel did on the NUC, then that would
be very
helpful.

It's called LSPCON, see i915/intel_lspcon.c, basically to support
HDMI
2.0. Currently we only use it in PCON mode, shows up as DP for
us. It
could be used in LS mode, showing up as HDMI 1.4, but we don't
support
that in i915.

I don't know about the CEC on that.

My NUC6i7KYK has the MCDP2850 LSPCON and it does support CEC over
Aux.
The release notes for the NUC state that there is a BIOS
configuration
option for enabling support. My doesn't have the option but the
LSPCON
fully supports CEC.

What is the output of:

dd if=/dev/drm_dp_aux0 of=aux0 skip=12288 ibs=1 count=48
od -t x1 aux0

Assuming drm_dp_aux0 is the aux channel for the HDMI output on your
NUC.

If the first byte is != 0x00, then it advertises CEC over Aux.

For me it says 0x00.

When you say "it does support CEC over Aux", does that mean you have
actually
tested it somehow? The only working solution I have seen mentioned
for the
NUC6i7KYK is a Pulse-Eight adapter.

With the NUC7i Intel made BIOS support for CEC, but it is not at all
clear to me if they used CEC tunneling or just hooked up the CEC
pin to
some microcontroller.

The only working chipset I have seen is the Parade PS176.

If it really is working on your NUC, then can you add the output of
/sys/kernel/debug/dri/0/i915_display_info?

[root@localhost cec-ctl]# cat /sys/kernel/debug/dri/0/i915_display_info

Connector info
--
connector 48: type DP-1, status: connected
name:
physical dimensions: 700x400mm
subpixel order: Unknown
CEA rev: 3
DPCD rev: 12
audio support: yes
DP branch device present: yes
Type: HDMI
ID: 175IB0
HW: 1.0
SW: 7.32
Max TMDS clock: 60 kHz
Max bpc: 12

Huh. Based on this document:

https://downloadmirror.intel.com/26061/eng/NUC6i7KYK%20HDMI%202.0%20Firmware%20update%20Instructions.pdf

this is the internal DP-to-HDMI adapter and it has the PS175. So it is a
Parade chipset, and I have seen that work before (at least the PS176).

This is the PS175 LSPCON on the NUC6.

connector 55: type DP-2, status: connected
name:
physical dimensions: 620x340mm
subpixel order: Unknown
CEA rev: 3
DPCD rev: 12
audio support: yes
DP branch device present: yes
Type: HDMI
ID: BCTRC0
HW: 2.0
SW: 0.26

And is this from a USB-C to HDMI adapter? Which one? I don't recognize
the ID.

This is a LSPCON inside the Google USB-C->HDMI dongle. This is actually
a MC2850 with what appears to be a custom ID. Datasheet claims CEC over
Aux and the pin is wired, but FW has it currently disabled.

OK, in other words the Parade chipsets work and the Megachip chipsets
don't. And Intel in their wisdom decided to go with Megachip for the new
NUCs.

I have no idea if you have any ins with the NUC team, but it would be so
nice if there would be a Megachip firmware update enabling this feature.

Regards,

Hans

Re: [RFC PATCH] [media] v4l2-subdev: check colorimetry in link validate