date:20160609

cron job: media_tree daily build: ERRORS

2016-06-09 Thread Hans Verkuil

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

Results of the daily build of media_tree:

date:   Fri Jun 10 04:00:31 CEST 2016
git branch: test
git hash:   cc650b65bea5613f04a0523c3ee2b91df371e175
gcc version:i686-linux-gcc (GCC) 5.3.0
sparse version: v0.5.0-56-g7647c77
smatch version: v0.5.0-3428-gdfe27cf
host hardware:  x86_64
host os:4.5.0-264

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-exynos: OK
linux-git-arm-mx: OK
linux-git-arm-omap: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: ERRORS
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: ERRORS
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.7.4-i686: ERRORS
linux-3.8-i686: ERRORS
linux-3.9.2-i686: ERRORS
linux-3.10.1-i686: ERRORS
linux-3.11.1-i686: ERRORS
linux-3.12.23-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: ERRORS
linux-3.15.2-i686: ERRORS
linux-3.16.7-i686: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.18.7-i686: ERRORS
linux-3.19-i686: ERRORS
linux-4.0-i686: ERRORS
linux-4.1.1-i686: ERRORS
linux-4.2-i686: ERRORS
linux-4.3-i686: ERRORS
linux-4.4-i686: ERRORS
linux-4.5-i686: ERRORS
linux-4.6-i686: ERRORS
linux-4.7-rc1-i686: OK
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-x86_64: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: ERRORS
linux-3.10.1-x86_64: ERRORS
linux-3.11.1-x86_64: ERRORS
linux-3.12.23-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: ERRORS
linux-3.15.2-x86_64: ERRORS
linux-3.16.7-x86_64: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.7-x86_64: ERRORS
linux-3.19-x86_64: ERRORS
linux-4.0-x86_64: ERRORS
linux-4.1.1-x86_64: ERRORS
linux-4.2-x86_64: ERRORS
linux-4.3-x86_64: ERRORS
linux-4.4-x86_64: ERRORS
linux-4.5-x86_64: ERRORS
linux-4.6-x86_64: ERRORS
linux-4.7-rc1-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] [media] media-device: dynamically allocate struct media_devnode

2016-06-09 Thread Sakari Ailus

Hi Mauro,

On Tue, Jun 07, 2016 at 10:11:33AM -0300, Mauro Carvalho Chehab wrote:
> Em Mon, 6 Jun 2016 17:13:12 -0600
> Shuah Khan  escreveu:
> 
> > > A few general comments on the patch --- I agree we've had the problem from
> > > the day one, but it's really started showing up recently. I agree with the
> > > taken approach of separating the lifetimes of both media device and the
> > > devnode. However, I don't think the patch as such is enough.
> 
> Do you or Laurent has an alternative patchset to fix those issues? From 
> where I sit, we have a serious bug that it is already known for a while,
> but nobody really tried to fix so far, except for Shuah and myself.

If I had, I would have posted it. :-I

> So, if you don't have any alternative patch ready to be merged, I'll
> apply what we have later today, together with the patch that fixes cdev
> livetime management:
>   https://patchwork.linuxtv.org/patch/34201/
> 
> This will allow it to be tested to a broader audience and check if
> the known issues will be fixed. I'll add a C/C stable, but my plan is
> to not send it as a fix for 4.7. Instead, to keep the fixes on our tree
> up to the next merge window, giving us ~5 weeks for testing.
> 
> As this is a Kernel only issue, it can be changed later if someone pops
> up with a better approach.

Ok. I haven't had time to review Shuah's patch but the direction taken sound
good.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [media]: Driver for Toshiba et8ek8 5MP sensor

2016-06-09 Thread Sakari Ailus

Hi Ivaylo,

On Sat, Jun 04, 2016 at 10:54:58PM +0300, Ivaylo Dimitrov wrote:
> Hi,
> 
> On 26.05.2016 00:45, Sakari Ailus wrote:
> >Hi Ivaylo,
> >
> >I've got some comments here but I haven't reviewed everything yet. What's
> >missing is
> >
> >- the user space interface for selecting the sensor configuration "mode",
> >
> >- passing information on the sensor configuration to the user space.
> >
> >I'll try to take a look at those some time in the near future.
> >
> 
> ok
> 
> >
> >I very much appreciate your work towards finally upstreaming this! :-)
> >
> >On Tue, May 03, 2016 at 05:50:04PM +0300, Ivaylo Dimitrov wrote:
> >>The sensor is found in Nokia N900 main camera
> >>
> >>Signed-off-by: Ivaylo Dimitrov 
> >>---
> >>  .../bindings/media/i2c/toshiba,et8ek8.txt  |   53 +
> >>  drivers/media/i2c/Kconfig  |1 +
> >>  drivers/media/i2c/Makefile |1 +
> >>  drivers/media/i2c/et8ek8/Kconfig   |6 +
> >>  drivers/media/i2c/et8ek8/Makefile  |2 +
> >>  drivers/media/i2c/et8ek8/et8ek8_driver.c   | 1711 
> >> 
> >>  drivers/media/i2c/et8ek8/et8ek8_mode.c |  591 +++
> >>  drivers/media/i2c/et8ek8/et8ek8_reg.h  |  100 ++
> >>  include/uapi/linux/v4l2-controls.h |5 +
> >>  9 files changed, 2470 insertions(+)
> >>  create mode 100644 
> >> Documentation/devicetree/bindings/media/i2c/toshiba,et8ek8.txt
> >>  create mode 100644 drivers/media/i2c/et8ek8/Kconfig
> >>  create mode 100644 drivers/media/i2c/et8ek8/Makefile
> >>  create mode 100644 drivers/media/i2c/et8ek8/et8ek8_driver.c
> >>  create mode 100644 drivers/media/i2c/et8ek8/et8ek8_mode.c
> >>  create mode 100644 drivers/media/i2c/et8ek8/et8ek8_reg.h
> >>
> >>diff --git a/Documentation/devicetree/bindings/media/i2c/toshiba,et8ek8.txt 
> >>b/Documentation/devicetree/bindings/media/i2c/toshiba,et8ek8.txt
> >>new file mode 100644
> >>index 000..55f712c
> >>--- /dev/null
> >>+++ b/Documentation/devicetree/bindings/media/i2c/toshiba,et8ek8.txt
> >>@@ -0,0 +1,53 @@
> >>+Toshiba et8ek8 5MP sensor
> >>+
> >>+Toshiba et8ek8 5MP sensor is an image sensor found in Nokia N900 device
> >>+
> >>+More detailed documentation can be found in
> >>+Documentation/devicetree/bindings/media/video-interfaces.txt .
> >>+
> >>+
> >>+Mandatory properties
> >>+
> >>+
> >>+- compatible: "toshiba,et8ek8"
> >>+- reg: I2C address (0x3e, or an alternative address)
> >>+- vana-supply: Analogue voltage supply (VANA), typically 2,8 volts (sensor
> >>+  dependent).
> >
> >As these are bindings for a particular sensor, 2,8 volts it is.
> >
> >The sensor has also a digital voltage supply but it might be controlled by
> >the same GPIO which controls the CCP2 switch. Ugly stuff. Perhaps we could
> >just omit that here.
> >
> 
> ok
> 
> >>+- clocks: External clock to the sensor
> >>+- clock-frequency: Frequency of the external clock to the sensor
> >>+
> >>+
> >>+Optional properties
> >>+---
> >>+
> >>+- reset-gpios: XSHUTDOWN GPIO
> >
> >I guess this should be mandatory.
> >
> 
> yeah. Also, I will change xxx-lanes to optional
> 
> >>+
> >>+
> >>+Endpoint node mandatory properties
> >>+--
> >>+
> >>+- clock-lanes: <0>
> >>+- data-lanes: <1..n>
> >>+- remote-endpoint: A phandle to the bus receiver's endpoint node.
> >>+
> >>+
> >>+Example
> >>+---
> >>+
> >>+ {
> >>+   clock-frequency = <40>;
> >>+
> >>+   cam1: camera@3e {
> >>+   compatible = "toshiba,et8ek8";
> >>+   reg = <0x3e>;
> >>+   vana-supply = <>;
> >>+   clocks = < 0>;
> >>+   clock-frequency = <960>;
> >>+   reset-gpio = < 6 GPIO_ACTIVE_HIGH>; /* 102 */
> >>+   port {
> >>+   csi_cam1: endpoint {
> >>+   remote-endpoint = <_out1>;
> >>+   };
> >>+   };
> >>+   };
> >>+};
> >
> >Please split the DT documentation from the driver.
> >
> 
> Split it how? Send as series [patch 1] - driver, [patch 2] - doc?

Yes, please. As the ad5820, for instance.

> 
> >I remember having discussed showing the module in DT with Sebastian but I
> >couldn't find the patches anywhere. We currently consider the lens and
> >sensor entirely separate, the module has not been shown in software as
> >there's been nothing to control it.
> >
> 
> Not sure what am I supposed to do with that comment :)

Not necessarily anything. But I'd like to continue the discussion on the
topic. :-)

> 
> >Sebastian: do you still have those patches around somewhere?
> >
> >>diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> >>index 993dc50..e964787 100644
> >>--- a/drivers/media/i2c/Kconfig
> >>+++ b/drivers/media/i2c/Kconfig
> >>@@ -629,6 +629,7 @@ config VIDEO_S5K5BAF
> >>  camera sensor with an embedded SoC image signal processor.
> >>
> >>  source

Re: [PATCHv2] device tree description for AD5820 camera auto-focus coil

2016-06-09 Thread Sakari Ailus

On Tue, Jun 07, 2016 at 09:10:04AM +0200, Pavel Machek wrote:
> 
> Add documentation for ad5820 device tree binding.
> 
> Signed-off-by: Pavel Machek 
> Acked-by: Sakari Ailus 
> Acked-by: Rob Herring 

Thanks!

I've replaced the patch in my tree, will send a pull req later.

-- 
Cheers,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kernel 4.7.0-rc2 warnings with Facetime HD camera on Macbook Pro 8,1

2016-06-09 Thread Sakari Ailus

HI Augusto,

On Wed, Jun 08, 2016 at 02:00:46AM -0300, Augusto Mecking Caringi wrote:
> Hi,
> 
> I have a Macbook Pro 8,1 running Linux (Fedora) and until now I
> was running the kernel provided by the distro. Today I decided to
> compile a new kernel from Linus HEAD
> (3613a6245b9fb5091724961e502fd1228de40f32) with the attached .config.
> 
> During boot I see the following lines:
> 
> [   21.203874] media: Linux media interface: v0.10
> [   21.203888] usbcore: registered new interface driver bcm5974
> [   21.885849] Linux video capture interface: v2.00
> [   22.877744] uvcvideo: Found UVC 1.00 device FaceTime HD Camera
> (Built-in) (05ac:8509)
> [   22.884626] uvcvideo 1-2:1.0: Entity type for entity Processing 3
> was not initialized!
> [   22.887411] uvcvideo 1-2:1.0: Entity type for entity Camera 1 was
> not initialized!
> [   22.889287] input: FaceTime HD Camera (Built-in) as
> /devices/pci:00/:00:1a.7/usb1/1-2/1-2:1.0/input/input18
> [   22.891190] usbcore: registered new interface driver uvcvideo
> [   22.893180] USB Video Class driver (1.1.1)
> 
>  When I open cheese the camera works without problems, but a lot
> of messages like that appear in the kernel ring buffer:
> 
> [  414.181611] [ cut here ]
> [  414.181636] WARNING: CPU: 1 PID: 5763 at
> drivers/media/v4l2-core/v4l2-ioctl.c:2174 v4l_cropcap+0x13c/0x160
> [videodev]
> [  414.181641] Modules linked in: iptable_nat nf_nat_ipv4 nf_nat
> uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2
> videobuf2_core videodev media bcm5974 x86_pkg_temp_thermal coretemp
> snd_hda_codec_hdmi snd_hda_codec_cirrus snd_hda_codec_generic
> snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core
> [  414.181682] CPU: 1 PID: 5763 Comm: cheese Not tainted
> 4.7.0-rc2-4-g3613a62 #61
> [  414.181686] Hardware name: Apple Inc.
> MacBookPro8,1/Mac-94245B3640C91C81, BIOS
> MBP81.88Z.0047.B27.1201241646 01/24/12
> [  414.181690]   88008a907c18 8155791d
> 
> [  414.181698]   88008a907c58 810ace66
> 087ea01045b2
> [  414.181706]  c02c563a 88003fef7018 a00cc8c0
> 88008a907da8
> [  414.181714] Call Trace:
> [  414.181724]  [] dump_stack+0x4f/0x72
> [  414.181732]  [] __warn+0xc6/0xe0
> [  414.181739]  [] warn_slowpath_null+0x18/0x20
> [  414.181748]  [] v4l_cropcap+0x13c/0x160 [videodev]
> [  414.181758]  [] __video_do_ioctl+0x26a/0x2e0 [videodev]
> [  414.181766]  [] ? page_cache_async_readahead+0x89/0xc0
> [  414.181774]  [] ? __this_cpu_preempt_check+0x13/0x20
> [  414.181781]  [] ? __inc_zone_state+0x42/0xa0
> [  414.181791]  [] video_usercopy+0x30b/0x5a0 [videodev]
> [  414.181799]  [] ? video_ioctl2+0x20/0x20 [videodev]
> [  414.181807]  [] ? _raw_write_unlock+0x11/0x30
> [  414.181812]  [] ? _raw_spin_unlock+0x9/0x10
> [  414.181818]  [] ? handle_mm_fault+0x500/0x1400
> [  414.181827]  [] video_ioctl2+0x10/0x20 [videodev]
> [  414.181836]  [] v4l2_ioctl+0xd7/0xe0 [videodev]
> [  414.181842]  [] do_vfs_ioctl+0x8d/0x580
> [  414.181850]  [] ? __fget+0x72/0xa0
> [  414.181855]  [] SyS_ioctl+0x74/0x80
> [  414.181861]  [] entry_SYSCALL_64_fastpath+0x13/0x8f
> [  414.181866] ---[ end trace fc095e890e0ec9cf ]---
> 
>  This warning was introduced in commit "[media] v4l2-ioctl.c:
> improve cropcap compatibility code"
> (95dd7b7e30f385c1c2d5e41457c082c5f6c535b3) from 15/Apr/2016, file
> drivers/media/v4l2-core/v4l2-ioctl.c:2170:
> 
> /*
>  * The determine_valid_ioctls() call already should ensure
>  * that this can never happen, but just in case...
>  */
>  if (WARN_ON(!ops->vidioc_cropcap && !ops->vidioc_cropcap))
>  return -ENOTTY;
> 
> Just to emphasize: Despite the warnings, the camera is working ok.

It's a bug, which I believe is fixed by this patch:



-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [media] s5p-mfc: use vb2_is_streaming() to check vb2 queue status

2016-06-09 Thread Javier Martinez Canillas

The streaming field in struct vb2_queue is meant to be private and should
not be used by drivers directly, instead the vb2_is_streaming() function
should be used to check the videobuf2 queue streaming status.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 038215c198ac..d3b01e92ee80 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -423,7 +423,7 @@ static int vidioc_s_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
pix_mp = >fmt.pix_mp;
if (ret)
return ret;
-   if (ctx->vq_src.streaming || ctx->vq_dst.streaming) {
+   if (vb2_is_streaming(>vq_src) || vb2_is_streaming(>vq_dst)) {
v4l2_err(>v4l2_dev, "%s queue busy\n", __func__);
ret = -EBUSY;
goto out;
@@ -820,7 +820,7 @@ static int vidioc_decoder_cmd(struct file *file, void *priv,
if (cmd->flags != 0)
return -EINVAL;
 
-   if (!ctx->vq_src.streaming)
+   if (!vb2_is_streaming(>vq_src))
return -EINVAL;
 
spin_lock_irqsave(>irqlock, flags);
-- 
2.5.5

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dvb-core: how should i2c subdev drivers be attached?

2016-06-09 Thread Antti Palosaari


On 06/09/2016 10:35 PM, Mauro Carvalho Chehab wrote:

The above code is racy, as some other request to the frontend
may arrive between the if() statement and kfree(). A kref would
likely be safer.


Here is working proof-of-concept hack. It is for si2157 tuner module. It 
prevents module unbind and unload when module is active. Of course it is 
not safe. Some more work needed in order to allow runtime bind (I tested 
it earlier with a8293 and unbind + bind was possible for deactive module 
at that time).


https://git.linuxtv.org/anttip/media_tree.git/log/?h=unbind_poc

regards
Antti

--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dvb-core: how should i2c subdev drivers be attached?

2016-06-09 Thread Mauro Carvalho Chehab

Antti,

Em Thu, 09 Jun 2016 22:14:12 +0300
Antti Palosaari  escreveu:

> On 06/09/2016 09:30 PM, Mauro Carvalho Chehab wrote:
> > Em Thu, 9 Jun 2016 19:38:04 +0300
> > Antti Palosaari  escreveu:  
> 
> >>> The V4L2 core handles everything that it is needed for it to work, and
> >>> no extra code is needed to do module_put() or i2c_unregister_device().  
> >>
> >> That example attachs 2 I2C drivers, as your example only 1.  
> >
> > Well, on V4L2, 2 I2C drivers, two statements.
> >  
> >> Also it
> >> populates all the config to platform data on both I2C driver.  
> >
> > Yes, this is annoying, but lots of the converted entries are
> > doing the same crap, instead of using a const var outside
> > the code.
> >  
> >> Which
> >> annoys me is that try_module_get/module_put functionality.  
> >
> > That is scary, as any failure there would prevent removing/unbinding
> > a module. The core or some helper function should be handle it,
> > to avoid the risk of get twice, put twice, never call put, etc.
> >  
> >> You should be ideally able to unbind (and bind) modules like that:
> >> echo 6-0008 > /sys/bus/i2c/drivers/a8293/unbind  
> >
> > I guess unbinding a V4L2 module in real time won't cause any
> > crash (obviously, the device will stop work properly, if you
> > remove a component that it is being used).
> >
> > I actually tested remove/reinsert the I2C remote controller
> > drivers a long time ago, while looking at some bugs. Those are
> > usually harder to get it right, as most of them have a poll logic
> > internally to get IR events on every 10ms. I guess I tested
> > removing/reinserting the tuner too, but that was at the
> > "stone ages"... to old for me to remember what I did.
> >
> > Yet, I don't see any troubles preventing the I2C "slave" drivers to
> > be unbound before the master, by increasing their module refcounts
> > during their usage.
> >  
> >> and as it is not possible, that stuff is here to avoid problems. Some
> >> study is needed in order to find out how dynamic unbind/bind could be
> >> get working and after that I hope whole ref counting could be removed.
> >> Currently you cannot allow remove module as it leads to unbind, which
> >> does not work.  
> 
> I did tons of work in order to get things work properly with I2C 
> binding. And following things are now possible due to that:
> * Kernel logging. You could now use standard dev_ logging.
> * regmap. Could now use regmap in order to cover register access.
> * I2C-mux. No need for i2c_gate_control.
> 
> And everytime there is someone asking why just don't do things like 
> earlier :S
> 
> I really don't want add any new hacks but implement things as much as 
> possible the way driver core makes possible. For long ran I feel it is 
> better approach to follow driver core than make own hacks. Until someone 
> study things and says it is not possible to implement things like core 
> offers, then lets implement things. That's bind/unbind is one thing to 
> study, another thing is power-management.

Nobody is proposing to add hacks. I'm with you with that: hacks
should be removed (like that hybrid_instance ugly code used by most
hybrid tuners).

We should, however, put common code at the core or provide helper
functions, in order to:

1) Make life easier for developers to add support for new boards;

2) Prevent, as much as possible, the risk of developer's mistakes
   to cause harm to the drivers;

3) Simplify the logic at the drivers, and, if possible, remove that
   long per-card switch() at the dvb part of the hybrid drivers;

4) Prevent, as much as possible, the risk of developer's mistakes
   to cause harm to the drivers;

5) Allow the code to be better reviewed by static code analyzers.

> 
> I suspect bind/unbind could be simple like just:
> i2c_driver_remove()
> {
>  if (frontend_is_running)
>  return -EBUSY;
> 
>  kfree(dev)
>  return 0;
> }

The above code is racy, as some other request to the frontend
may arrive between the if() statement and kfree(). A kref would
likely be safer.

Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dvb-core: how should i2c subdev drivers be attached?

2016-06-09 Thread Antti Palosaari


On 06/09/2016 09:30 PM, Mauro Carvalho Chehab wrote:

Em Thu, 9 Jun 2016 19:38:04 +0300
Antti Palosaari  escreveu:



The V4L2 core handles everything that it is needed for it to work, and
no extra code is needed to do module_put() or i2c_unregister_device().


That example attachs 2 I2C drivers, as your example only 1.


Well, on V4L2, 2 I2C drivers, two statements.


Also it
populates all the config to platform data on both I2C driver.


Yes, this is annoying, but lots of the converted entries are
doing the same crap, instead of using a const var outside
the code.


Which
annoys me is that try_module_get/module_put functionality.


That is scary, as any failure there would prevent removing/unbinding
a module. The core or some helper function should be handle it,
to avoid the risk of get twice, put twice, never call put, etc.


You should be ideally able to unbind (and bind) modules like that:
echo 6-0008 > /sys/bus/i2c/drivers/a8293/unbind


I guess unbinding a V4L2 module in real time won't cause any
crash (obviously, the device will stop work properly, if you
remove a component that it is being used).

I actually tested remove/reinsert the I2C remote controller
drivers a long time ago, while looking at some bugs. Those are
usually harder to get it right, as most of them have a poll logic
internally to get IR events on every 10ms. I guess I tested
removing/reinserting the tuner too, but that was at the
"stone ages"... to old for me to remember what I did.

Yet, I don't see any troubles preventing the I2C "slave" drivers to
be unbound before the master, by increasing their module refcounts
during their usage.


and as it is not possible, that stuff is here to avoid problems. Some
study is needed in order to find out how dynamic unbind/bind could be
get working and after that I hope whole ref counting could be removed.
Currently you cannot allow remove module as it leads to unbind, which
does not work.


I did tons of work in order to get things work properly with I2C 
binding. And following things are now possible due to that:

* Kernel logging. You could now use standard dev_ logging.
* regmap. Could now use regmap in order to cover register access.
* I2C-mux. No need for i2c_gate_control.

And everytime there is someone asking why just don't do things like 
earlier :S


I really don't want add any new hacks but implement things as much as 
possible the way driver core makes possible. For long ran I feel it is 
better approach to follow driver core than make own hacks. Until someone 
study things and says it is not possible to implement things like core 
offers, then lets implement things. That's bind/unbind is one thing to 
study, another thing is power-management.


I suspect bind/unbind could be simple like just:
i2c_driver_remove()
{
if (frontend_is_running)
return -EBUSY;

kfree(dev)
return 0;
}

regards
Antti

--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dvb-core: how should i2c subdev drivers be attached?

2016-06-09 Thread Mauro Carvalho Chehab

Em Thu, 9 Jun 2016 19:38:04 +0300
Antti Palosaari  escreveu:

> On 06/09/2016 07:18 PM, Mauro Carvalho Chehab wrote:
> > Em Thu, 09 Jun 2016 18:41:10 +0300
> > Antti Palosaari  escreveu:
> >  
> >> On 06/09/2016 06:24 PM, Mauro Carvalho Chehab wrote:  
> >>> Hi Akihiro,
> >>>
> >>> Em Thu, 09 Jun 2016 21:49:33 +0900
> >>> Akihiro TSUKADA  escreveu:
> >>>  
>  Hi,
>  excuse me for taking up a very old post again,
>  but I'd like to know the status of the patch:
>    https://patchwork.linuxtv.org/patch/27922/
>  , which provides helper code for defining/loading i2c DVB subdev drivers.
> 
>  Was it rejected and  
> >>>
> >>> It was not rejected. It is just that I didn't have time yet to think
> >>> about that, and Antti has a different view.
> >>>
> >>> The thing is that, whatever we do, it should work fine on drivers that
> >>> also exposes the tuner via V4L2. One of the reasons is that devices
> >>> that also allow the usage for SDR use the V4L2 core for the SDR part.
> >>>  
>  each i2c demod/tuner drivers should provide its own version of "attach" 
>  code?  
> >>>
> >>> Antti took this path, but I don't like it. Lots of duplicated and complex
> >>> stuff. Also, some static analyzers refuse to check it (like smatch),
> >>> due to its complexity.
> >>>  
>  Or is it acceptable (with some modifications) ?  
> >>>
> >>> I guess we should discuss a way of doing it that will be acceptable
> >>> on existing drivers. Perhaps you should try to do such change for
> >>> an hybrid driver like em28xx or cx231xx. There are a few ISDB-T
> >>> devices using them. Not sure how easy would be to find one of those
> >>> in Japan, though.
> >>>  
> 
>  Although not many drivers currently use i2c binding model (and use 
>  dvb_attach()),
>  but I expect that coming DVB subdev drivers will have a similar attach 
>  code,
>  including module request/ref-counting, device creation,
>  (re-)using i2c_board_info.platformdata to pass around both config 
>  parameters
>  and the resulting i2c_client* & dvb_frontend*.
> 
>  Since I have a plan to split out demod/tuner drivers from pci/pt1 
>  dvb-usb/friio
>  integrated drivers (because those share the tc90522 demod driver with 
>  pt3, and
>  friio also shares the bridge chip with gl861),
>  it would be nice if I can use the helper code,
>  instead of re-iterating similar "attach" code.  
> >>
> >> IMHO only thing which makes it looking complex is that module reference
> >> counting - otherwise it is just standard I2C binding. Ideally I2C
> >> modules should be possible to unbind and unload at runtime and also load
> >> and bind. There is "suppress_bind_attrs = true" set to prevent runtime
> >> unbinding and try_module_get() is to prevent module unloading. For me
> >> eyes all that is still some workaround - and now you want put this
> >> workaround to some generic code. Please find correct solutions for those
> >> two problems and then there we can get rid of things totally - no need
> >> to make generic functions at all.  
> >
> > It *is complex*. A single board binding on the way you're mapping is:
> >
> > case EM28174_BOARD_PCTV_460E: {
> > struct i2c_client *client;
> > struct i2c_board_info board_info;
> > struct tda10071_platform_data tda10071_pdata = {};
> > struct a8293_platform_data a8293_pdata = {};
> >
> > /* attach demod + tuner combo */
> > tda10071_pdata.clk = 40444000, /* 40.444 MHz */
> > tda10071_pdata.i2c_wr_max = 64,
> > tda10071_pdata.ts_mode = TDA10071_TS_SERIAL,
> > tda10071_pdata.pll_multiplier = 20,
> > tda10071_pdata.tuner_i2c_addr = 0x14,
> > memset(_info, 0, sizeof(board_info));
> > strlcpy(board_info.type, "tda10071_cx24118", I2C_NAME_SIZE);
> > board_info.addr = 0x55;
> > board_info.platform_data = _pdata;
> > request_module("tda10071");
> > client = i2c_new_device(>i2c_adap[dev->def_i2c_bus], 
> > _info);
> > if (client == NULL || client->dev.driver == NULL) {
> > result = -ENODEV;
> > goto out_free;
> > }
> > if (!try_module_get(client->dev.driver->owner)) {
> > i2c_unregister_device(client);
> > result = -ENODEV;
> > goto out_free;
> > }
> > dvb->fe[0] = tda10071_pdata.get_dvb_frontend(client);
> > dvb->i2c_client_demod = client;
> >
> > /* attach SEC */
> > a8293_pdata.dvb_frontend = dvb->fe[0];
> > memset(_info, 0, sizeof(board_info));
> > strlcpy(board_info.type, "a8293", I2C_NAME_SIZE);
> > board_info.addr = 0x08;
> > board_info.platform_data = _pdata;
> >

[PATCH] [media] v4l: vsp1: Fix format-info documentation

2016-06-09 Thread Kieran Bingham

Minor tweaks to document the swap register and make the documentation
match the struct ordering

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_pipe.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_pipe.h 
b/drivers/media/platform/vsp1/vsp1_pipe.h
index 7b56113511dd..6ee3db1fab55 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.h
+++ b/drivers/media/platform/vsp1/vsp1_pipe.h
@@ -25,11 +25,12 @@ struct vsp1_rwpf;
 
 /*
  * struct vsp1_format_info - VSP1 video format description
- * @mbus: media bus format code
  * @fourcc: V4L2 pixel format FCC identifier
+ * @mbus: media bus format code
+ * @hwfmt: VSP1 hardware format
+ * @swap: swap register control
  * @planes: number of planes
  * @bpp: bits per pixel
- * @hwfmt: VSP1 hardware format
  * @swap_yc: the Y and C components are swapped (Y comes before C)
  * @swap_uv: the U and V components are swapped (V comes before U)
  * @hsub: horizontal subsampling factor
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dvb-core: how should i2c subdev drivers be attached?

2016-06-09 Thread Akihiro TSUKADA

thanks for the replys.

so, the new i2c "attach" helper code should
1. be usable for V4L2-DVB multi-functional(hybrid) tuner devices
   (or at least co-exist well with them),
2. properly ref-count driver module
   to prevent (accidental) 'unload before use' by users.
3. a. block un-binding of the device while in use,
   b. support run-time {un-,}binding of the devices
  via sysfs by users (to switch drivers?).
Is this right?

> I guess we should discuss a way of doing it that will be acceptable
> on existing drivers. Perhaps you should try to do such change for
> an hybrid driver like em28xx or cx231xx. There are a few ISDB-T
> devices using them. Not sure how easy would be to find one of those
> in Japan, though.

I'll look into those drivers' code, to begin with.
(I'm pretty sure those devices are hardly found here in Japan).

> I'm now helping to to maintain Kaffeine upstream. I recently added
> support for both ISDB-T and DVB-T2. It would be nice if you could
> add support there for ISDB-S too.

All the channels in ISDB-S are scrambled,
unlike ISDB-T(jp) where non-scrambled '1-seg' channels are delivered.
In Japan, it will be considered illegal to desramble them with
a non-authorized software that lacks private copy-guard encryption.
So, unfortunately, there will be no legitimate OSS player for ISDB-S.

regards,
akihiro

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RFC 2/2] MAINTAINERS: Add support for FDP driver

2016-06-09 Thread Kieran Bingham

Signed-off-by: Kieran Bingham 
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 66de4da2d244..bc083b58e478 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7312,6 +7312,15 @@ S:   Supported
 F: Documentation/devicetree/bindings/media/renesas,vsp1.txt
 F: drivers/media/platform/vsp1/
 
+MEDIA DRIVERS FOR RENESAS - FDP1
+M: Kieran Bingham 
+L: linux-media@vger.kernel.org
+L: linux-renesas-...@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Supported
+F: Documentation/devicetree/bindings/media/renesas,fdp1.txt
+F: drivers/media/platform/rcar_fdp1.c
+
 MEDIA DRIVERS FOR ASCOT2E
 M: Sergey Kozlov 
 L: linux-media@vger.kernel.org
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RFC 1/2] v4l: platform: Add Renesas R-Car FDP1 Driver

2016-06-09 Thread Kieran Bingham

The FDP1 driver performs advanced de-interlacing on a memory 2 memory
based video stream, and supports conversion from YCbCr/YUV
to RGB pixel formats

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/Kconfig |   13 +
 drivers/media/platform/Makefile|1 +
 drivers/media/platform/rcar_fdp1.c | 2038 
 3 files changed, 2052 insertions(+)
 create mode 100644 drivers/media/platform/rcar_fdp1.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 84e041c0a70e..9c745e53909b 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -235,6 +235,19 @@ config VIDEO_SH_VEU
Support for the Video Engine Unit (VEU) on SuperH and
SH-Mobile SoCs.
 
+config VIDEO_RENESAS_FDP1
+   tristate "Renesas Fine Display Processor"
+   depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
+   #   depends on ARCH_SHMOBILE || COMPILE_TEST
+   select VIDEOBUF2_DMA_CONTIG
+   select V4L2_MEM2MEM_DEV
+   ---help---
+ This is a V4L2 driver for the Renesas Fine Display Processor
+ providing colour space conversion, and de-interlacing features.
+
+ To compile this driver as a module, choose M here: the module
+ will be called rcar_fdp1.
+
 config VIDEO_RENESAS_JPU
tristate "Renesas JPEG Processing Unit"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index bbb7bd1eb268..907ed6473718 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_VIDEO_SH_VOU)+= sh_vou.o
 
 obj-$(CONFIG_SOC_CAMERA)   += soc_camera/
 
+obj-$(CONFIG_VIDEO_RENESAS_FDP1)   += rcar_fdp1.o
 obj-$(CONFIG_VIDEO_RENESAS_JPU)+= rcar_jpu.o
 obj-$(CONFIG_VIDEO_RENESAS_VSP1)   += vsp1/
 
diff --git a/drivers/media/platform/rcar_fdp1.c 
b/drivers/media/platform/rcar_fdp1.c
new file mode 100644
index ..82078367fa14
--- /dev/null
+++ b/drivers/media/platform/rcar_fdp1.c
@@ -0,0 +1,2038 @@
+/*
+ * Renesas RCar Fine Display Processor
+ *
+ * Video format converter and frame deinterlacer device.
+ *
+ * Author: Kieran Bingham, 
+ * Copyright (c) 2016 Renesas Electronics Corporation.
+ *
+ * This code is developed and inspired from the vim2m, rcar_jpu,
+ * m2m-deinterlace, and vsp1 drivers.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static unsigned int debug;
+module_param(debug, uint, 0644);
+MODULE_PARM_DESC(debug, "activate debug info");
+
+/* Min Width/Height/Height-Field */
+#define MIN_W 80U
+#define MIN_H 80U
+
+#define MAX_W 3840U
+#define MAX_H 2160U
+
+/* Flags that indicate a format can be used for capture/output */
+#define FDP1_CAPTURE   (1 << 0)
+#define FDP1_OUTPUT(1 << 1)
+
+#define DRIVER_NAME"rcar_fdp1"
+
+#define dprintk(dev, fmt, arg...) \
+   v4l2_dbg(1, debug, >v4l2_dev, "%s: " fmt, __func__, ## arg)
+
+/*
+ * FDP1 registers and bits
+ */
+
+/* FDP1 start register - Imm */
+#define CTL_CMD0x
+#define CTL_CMD_STRCMD BIT(0)
+
+/* Sync generator register - Imm */
+#define CTL_SGCMD  0x0004
+#define CTL_SGCMD_SGEN BIT(0)
+
+/* Register set end register - Imm */
+#define CTL_REGEND 0x0008
+#define CTL_REGEND_REGEND  BIT(0)
+
+/* Channel activation register - Vupdt */
+#define CTL_CHACT  0x000C
+#define CTL_CHACT_SMW  BIT(9)
+#define CTL_CHACT_WR   BIT(8)
+#define CTL_CHACT_SMR  BIT(3)
+#define CTL_CHACT_RD2  BIT(2)
+#define CTL_CHACT_RD1  BIT(1)
+#define CTL_CHACT_RD0  BIT(0)
+
+/* Operation Mode Register - Vupdt */
+#define CTL_OPMODE 0x0010
+#define CTL_OPMODE_PRG BIT(4)
+#define CTL_OPMODE_VIMDGENMASK(1, 0)
+#define CTL_OPMODE_INTERRUPT   0
+#define CTL_OPMODE_BEST_EFFORT 1
+#define CTL_OPMODE_NO_INTERRUPT2
+
+#define CTL_VPERIOD0x0014
+#define CTL_CLKCTRL0x0018
+#define CTL_CLKCTRL_CSTP_N BIT(0)
+
+/* Software reset register */
+#define CTL_SRESET 0x001C
+#define CTL_SRESET_SRSTBIT(0)
+
+/* Control status register (V-update-status) */
+#define CTL_STATUS 0x0024
+#define CTL_STATUS_VINT_CNT(x) ((x & 0xff) >> 16)
+#define CTL_STATUS_SGREGSETBIT(10)
+#define CTL_STATUS_SGVERR  BIT(9)
+#define CTL_STATUS_SGFREND BIT(8)
+#define

[PATCH RFC 0/2] v4l: platform: Add Renesas R-Car FDP1 Driver

2016-06-09 Thread Kieran Bingham

This early version of the driver, is submitted for review, and functions only
as a pixel format converter.

The FDP1, (Fine Display Processor) is a de-interlacer device, with capability
to convert from various YCbCr/YUV formats to both YCbCr/YUV and RGB formats
at the same time as converting interlaced content to progressive.

It can also function with progressive frames on input, and still act as a
pixel converter which is the current state of the driver.

The next phase of work will be to implement the de-interlacing fucntionality
on top of this code base, however as it is now a functional driver this seemed
like an apt point to start the review process.

Kieran Bingham (2):
  v4l: platform: Add Renesas R-Car FDP1 Driver
  MAINTAINERS: Add support for FDP driver

 MAINTAINERS|9 +
 drivers/media/platform/Kconfig |   13 +
 drivers/media/platform/Makefile|1 +
 drivers/media/platform/rcar_fdp1.c | 2038 
 4 files changed, 2061 insertions(+)
 create mode 100644 drivers/media/platform/rcar_fdp1.c

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] v4l: Extend FCP compatible list to support the FDP

2016-06-09 Thread Kieran Bingham

The FCP must be powered up for the FDP1 to function, even when the FDP1
does not make use of the FCNL features. Extend the compatible list
to allow us to use the power domain and runtime-pm support.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/rcar-fcp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/platform/rcar-fcp.c 
b/drivers/media/platform/rcar-fcp.c
index 6a7bcc3028b1..0ff6b1edf1db 100644
--- a/drivers/media/platform/rcar-fcp.c
+++ b/drivers/media/platform/rcar-fcp.c
@@ -160,6 +160,7 @@ static int rcar_fcp_remove(struct platform_device *pdev)
 
 static const struct of_device_id rcar_fcp_of_match[] = {
{ .compatible = "renesas,fcpv" },
+   { .compatible = "renesas,fcpf" },
{ },
 };
 
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] v4l: Extend FCP compatible list to support the FDP

2016-06-09 Thread Kieran Bingham

The following patch extends Laurents FCP driver to support the FCP for
FDP (FCPF) which is used by the FDP driver currently in development

This patch is of course dependant upon Laurents FCP driver series [0]
which has not yet hit mainline

[0] http://www.spinics.net/lists/linux-media/msg97302.html

Kieran Bingham (1):
  v4l: Extend FCP compatible list to support the FDP

 drivers/media/platform/rcar-fcp.c | 1 +
 1 file changed, 1 insertion(+)

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dvb-core: how should i2c subdev drivers be attached?

2016-06-09 Thread Antti Palosaari




On 06/09/2016 07:18 PM, Mauro Carvalho Chehab wrote:

Em Thu, 09 Jun 2016 18:41:10 +0300
Antti Palosaari  escreveu:


On 06/09/2016 06:24 PM, Mauro Carvalho Chehab wrote:

Hi Akihiro,

Em Thu, 09 Jun 2016 21:49:33 +0900
Akihiro TSUKADA  escreveu:


Hi,
excuse me for taking up a very old post again,
but I'd like to know the status of the patch:
  https://patchwork.linuxtv.org/patch/27922/
, which provides helper code for defining/loading i2c DVB subdev drivers.

Was it rejected and


It was not rejected. It is just that I didn't have time yet to think
about that, and Antti has a different view.

The thing is that, whatever we do, it should work fine on drivers that
also exposes the tuner via V4L2. One of the reasons is that devices
that also allow the usage for SDR use the V4L2 core for the SDR part.


each i2c demod/tuner drivers should provide its own version of "attach" code?


Antti took this path, but I don't like it. Lots of duplicated and complex
stuff. Also, some static analyzers refuse to check it (like smatch),
due to its complexity.


Or is it acceptable (with some modifications) ?


I guess we should discuss a way of doing it that will be acceptable
on existing drivers. Perhaps you should try to do such change for
an hybrid driver like em28xx or cx231xx. There are a few ISDB-T
devices using them. Not sure how easy would be to find one of those
in Japan, though.



Although not many drivers currently use i2c binding model (and use 
dvb_attach()),
but I expect that coming DVB subdev drivers will have a similar attach code,
including module request/ref-counting, device creation,
(re-)using i2c_board_info.platformdata to pass around both config parameters
and the resulting i2c_client* & dvb_frontend*.

Since I have a plan to split out demod/tuner drivers from pci/pt1 dvb-usb/friio
integrated drivers (because those share the tc90522 demod driver with pt3, and
friio also shares the bridge chip with gl861),
it would be nice if I can use the helper code,
instead of re-iterating similar "attach" code.


IMHO only thing which makes it looking complex is that module reference
counting - otherwise it is just standard I2C binding. Ideally I2C
modules should be possible to unbind and unload at runtime and also load
and bind. There is "suppress_bind_attrs = true" set to prevent runtime
unbinding and try_module_get() is to prevent module unloading. For me
eyes all that is still some workaround - and now you want put this
workaround to some generic code. Please find correct solutions for those
two problems and then there we can get rid of things totally - no need
to make generic functions at all.


It *is complex*. A single board binding on the way you're mapping is:

case EM28174_BOARD_PCTV_460E: {
struct i2c_client *client;
struct i2c_board_info board_info;
struct tda10071_platform_data tda10071_pdata = {};
struct a8293_platform_data a8293_pdata = {};

/* attach demod + tuner combo */
tda10071_pdata.clk = 40444000, /* 40.444 MHz */
tda10071_pdata.i2c_wr_max = 64,
tda10071_pdata.ts_mode = TDA10071_TS_SERIAL,
tda10071_pdata.pll_multiplier = 20,
tda10071_pdata.tuner_i2c_addr = 0x14,
memset(_info, 0, sizeof(board_info));
strlcpy(board_info.type, "tda10071_cx24118", I2C_NAME_SIZE);
board_info.addr = 0x55;
board_info.platform_data = _pdata;
request_module("tda10071");
client = i2c_new_device(>i2c_adap[dev->def_i2c_bus], 
_info);
if (client == NULL || client->dev.driver == NULL) {
result = -ENODEV;
goto out_free;
}
if (!try_module_get(client->dev.driver->owner)) {
i2c_unregister_device(client);
result = -ENODEV;
goto out_free;
}
dvb->fe[0] = tda10071_pdata.get_dvb_frontend(client);
dvb->i2c_client_demod = client;

/* attach SEC */
a8293_pdata.dvb_frontend = dvb->fe[0];
memset(_info, 0, sizeof(board_info));
strlcpy(board_info.type, "a8293", I2C_NAME_SIZE);
board_info.addr = 0x08;
board_info.platform_data = _pdata;
request_module("a8293");
client = i2c_new_device(>i2c_adap[dev->def_i2c_bus], 
_info);
if (client == NULL || client->dev.driver == NULL) {
module_put(dvb->i2c_client_demod->dev.driver->owner);
i2c_unregister_device(dvb->i2c_client_demod);
result = -ENODEV;
goto out_free;
}
if (!try_module_get(client->dev.driver->owner)) {

Re: dvb-core: how should i2c subdev drivers be attached?

2016-06-09 Thread Mauro Carvalho Chehab

Em Thu, 09 Jun 2016 18:41:10 +0300
Antti Palosaari  escreveu:

> On 06/09/2016 06:24 PM, Mauro Carvalho Chehab wrote:
> > Hi Akihiro,
> >
> > Em Thu, 09 Jun 2016 21:49:33 +0900
> > Akihiro TSUKADA  escreveu:
> >  
> >> Hi,
> >> excuse me for taking up a very old post again,
> >> but I'd like to know the status of the patch:
> >>   https://patchwork.linuxtv.org/patch/27922/
> >> , which provides helper code for defining/loading i2c DVB subdev drivers.
> >>
> >> Was it rejected and  
> >
> > It was not rejected. It is just that I didn't have time yet to think
> > about that, and Antti has a different view.
> >
> > The thing is that, whatever we do, it should work fine on drivers that
> > also exposes the tuner via V4L2. One of the reasons is that devices
> > that also allow the usage for SDR use the V4L2 core for the SDR part.
> >  
> >> each i2c demod/tuner drivers should provide its own version of "attach" 
> >> code?  
> >
> > Antti took this path, but I don't like it. Lots of duplicated and complex
> > stuff. Also, some static analyzers refuse to check it (like smatch),
> > due to its complexity.
> >  
> >> Or is it acceptable (with some modifications) ?  
> >
> > I guess we should discuss a way of doing it that will be acceptable
> > on existing drivers. Perhaps you should try to do such change for
> > an hybrid driver like em28xx or cx231xx. There are a few ISDB-T
> > devices using them. Not sure how easy would be to find one of those
> > in Japan, though.
> >  
> >>
> >> Although not many drivers currently use i2c binding model (and use 
> >> dvb_attach()),
> >> but I expect that coming DVB subdev drivers will have a similar attach 
> >> code,
> >> including module request/ref-counting, device creation,
> >> (re-)using i2c_board_info.platformdata to pass around both config 
> >> parameters
> >> and the resulting i2c_client* & dvb_frontend*.
> >>
> >> Since I have a plan to split out demod/tuner drivers from pci/pt1 
> >> dvb-usb/friio
> >> integrated drivers (because those share the tc90522 demod driver with pt3, 
> >> and
> >> friio also shares the bridge chip with gl861),
> >> it would be nice if I can use the helper code,
> >> instead of re-iterating similar "attach" code.  
> 
> IMHO only thing which makes it looking complex is that module reference 
> counting - otherwise it is just standard I2C binding. Ideally I2C 
> modules should be possible to unbind and unload at runtime and also load 
> and bind. There is "suppress_bind_attrs = true" set to prevent runtime 
> unbinding and try_module_get() is to prevent module unloading. For me 
> eyes all that is still some workaround - and now you want put this 
> workaround to some generic code. Please find correct solutions for those 
> two problems and then there we can get rid of things totally - no need 
> to make generic functions at all.

It *is complex*. A single board binding on the way you're mapping is:

case EM28174_BOARD_PCTV_460E: {
struct i2c_client *client;
struct i2c_board_info board_info;
struct tda10071_platform_data tda10071_pdata = {};
struct a8293_platform_data a8293_pdata = {};

/* attach demod + tuner combo */
tda10071_pdata.clk = 40444000, /* 40.444 MHz */
tda10071_pdata.i2c_wr_max = 64,
tda10071_pdata.ts_mode = TDA10071_TS_SERIAL,
tda10071_pdata.pll_multiplier = 20,
tda10071_pdata.tuner_i2c_addr = 0x14,
memset(_info, 0, sizeof(board_info));
strlcpy(board_info.type, "tda10071_cx24118", I2C_NAME_SIZE);
board_info.addr = 0x55;
board_info.platform_data = _pdata;
request_module("tda10071");
client = i2c_new_device(>i2c_adap[dev->def_i2c_bus], 
_info);
if (client == NULL || client->dev.driver == NULL) {
result = -ENODEV;
goto out_free;
}
if (!try_module_get(client->dev.driver->owner)) {
i2c_unregister_device(client);
result = -ENODEV;
goto out_free;
}
dvb->fe[0] = tda10071_pdata.get_dvb_frontend(client);
dvb->i2c_client_demod = client;

/* attach SEC */
a8293_pdata.dvb_frontend = dvb->fe[0];
memset(_info, 0, sizeof(board_info));
strlcpy(board_info.type, "a8293", I2C_NAME_SIZE);
board_info.addr = 0x08;
board_info.platform_data = _pdata;
request_module("a8293");
client = i2c_new_device(>i2c_adap[dev->def_i2c_bus], 
_info);
if (client == NULL || client->dev.driver == NULL) {
module_put(dvb->i2c_client_demod->dev.driver->owner);

Re: dvb-core: how should i2c subdev drivers be attached?

2016-06-09 Thread Antti Palosaari


On 06/09/2016 06:24 PM, Mauro Carvalho Chehab wrote:

Hi Akihiro,

Em Thu, 09 Jun 2016 21:49:33 +0900
Akihiro TSUKADA  escreveu:


Hi,
excuse me for taking up a very old post again,
but I'd like to know the status of the patch:
  https://patchwork.linuxtv.org/patch/27922/
, which provides helper code for defining/loading i2c DVB subdev drivers.

Was it rejected and


It was not rejected. It is just that I didn't have time yet to think
about that, and Antti has a different view.

The thing is that, whatever we do, it should work fine on drivers that
also exposes the tuner via V4L2. One of the reasons is that devices
that also allow the usage for SDR use the V4L2 core for the SDR part.


each i2c demod/tuner drivers should provide its own version of "attach" code?


Antti took this path, but I don't like it. Lots of duplicated and complex
stuff. Also, some static analyzers refuse to check it (like smatch),
due to its complexity.


Or is it acceptable (with some modifications) ?


I guess we should discuss a way of doing it that will be acceptable
on existing drivers. Perhaps you should try to do such change for
an hybrid driver like em28xx or cx231xx. There are a few ISDB-T
devices using them. Not sure how easy would be to find one of those
in Japan, though.



Although not many drivers currently use i2c binding model (and use 
dvb_attach()),
but I expect that coming DVB subdev drivers will have a similar attach code,
including module request/ref-counting, device creation,
(re-)using i2c_board_info.platformdata to pass around both config parameters
and the resulting i2c_client* & dvb_frontend*.

Since I have a plan to split out demod/tuner drivers from pci/pt1 dvb-usb/friio
integrated drivers (because those share the tc90522 demod driver with pt3, and
friio also shares the bridge chip with gl861),
it would be nice if I can use the helper code,
instead of re-iterating similar "attach" code.


IMHO only thing which makes it looking complex is that module reference 
counting - otherwise it is just standard I2C binding. Ideally I2C 
modules should be possible to unbind and unload at runtime and also load 
and bind. There is "suppress_bind_attrs = true" set to prevent runtime 
unbinding and try_module_get() is to prevent module unloading. For me 
eyes all that is still some workaround - and now you want put this 
workaround to some generic code. Please find correct solutions for those 
two problems and then there we can get rid of things totally - no need 
to make generic functions at all.


regards
Antti

--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dvb-core: how should i2c subdev drivers be attached?

2016-06-09 Thread Mauro Carvalho Chehab

Hi Akihiro,

Em Thu, 09 Jun 2016 21:49:33 +0900
Akihiro TSUKADA  escreveu:

> Hi,
> excuse me for taking up a very old post again,
> but I'd like to know the status of the patch:
>   https://patchwork.linuxtv.org/patch/27922/
> , which provides helper code for defining/loading i2c DVB subdev drivers.
> 
> Was it rejected and 

It was not rejected. It is just that I didn't have time yet to think
about that, and Antti has a different view. 

The thing is that, whatever we do, it should work fine on drivers that
also exposes the tuner via V4L2. One of the reasons is that devices
that also allow the usage for SDR use the V4L2 core for the SDR part.

> each i2c demod/tuner drivers should provide its own version of "attach" code?

Antti took this path, but I don't like it. Lots of duplicated and complex
stuff. Also, some static analyzers refuse to check it (like smatch),
due to its complexity.

> Or is it acceptable (with some modifications) ?

I guess we should discuss a way of doing it that will be acceptable
on existing drivers. Perhaps you should try to do such change for
an hybrid driver like em28xx or cx231xx. There are a few ISDB-T
devices using them. Not sure how easy would be to find one of those
in Japan, though.

> 
> Although not many drivers currently use i2c binding model (and use 
> dvb_attach()),
> but I expect that coming DVB subdev drivers will have a similar attach code,
> including module request/ref-counting, device creation,
> (re-)using i2c_board_info.platformdata to pass around both config parameters
> and the resulting i2c_client* & dvb_frontend*.
> 
> Since I have a plan to split out demod/tuner drivers from pci/pt1 
> dvb-usb/friio
> integrated drivers (because those share the tc90522 demod driver with pt3, and
> friio also shares the bridge chip with gl861),
> it would be nice if I can use the helper code,
> instead of re-iterating similar "attach" code.

Yeah, sure.

---

An unrelated thing:

I'm now helping to to maintain Kaffeine upstream. I recently added
support for both ISDB-T and DVB-T2. It would be nice if you could
add support there for ISDB-S too.

You can find the kaffeine repository at kde.org. I'm also keeping
an updated copy at linuxtv.org:
git://anongit.kde.org/kaffeine  (official repo)
https://git.linuxtv.org/mchehab/kaffeine.git/


-- 
Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] dt-bindings: Add Renesas R-Car FDP1 bindings

2016-06-09 Thread Kieran Bingham

The FDP1 is a de-interlacing module which converts interlaced video to
progressive video. It is also capable of performing pixel format conversion
between YCbCr/YUV formats and RGB formats.

Signed-off-by: Kieran Bingham 
---
 .../devicetree/bindings/media/renesas,fdp1.txt | 34 ++
 1 file changed, 34 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/renesas,fdp1.txt

diff --git a/Documentation/devicetree/bindings/media/renesas,fdp1.txt 
b/Documentation/devicetree/bindings/media/renesas,fdp1.txt
new file mode 100644
index ..e2da2aec5e9f
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/renesas,fdp1.txt
@@ -0,0 +1,34 @@
+Renesas R-Car Fine Display Processor (FDP1)
+---
+
+The FDP1 is a de-interlacing module which converts interlaced video to
+progressive video. It is capable of performing pixel format conversion between
+YCbCr/YUV formats and RGB formats. Only YCbCr/YUV formats are supported as
+an input to the module.
+
+ - compatible: Must be one or more of the following
+
+   - "renesas,r8a7795-fdp1" for R8A7795 (R-Car H3)
+   - "renesas,r8a7796-fdp1" for R8A7796 (R-Car M3-W)
+   - "renesas,fdp1" for generic compatible
+
+   When compatible with the generic version, nodes must list the
+   SoC-specific version corresponding to the platform first, followed by the
+   family-specific and/or generic versions.
+
+ - reg: the register base and size for the device registers
+ - clocks: Reference to the functional clock
+ - renesas,fcp: Reference to the FCPF connected to the FDP1
+
+
+Device node example
+---
+
+   fdp1ch1: fdp1@fe94 {
+   compatible = "renesas,r8a7795-fdp1", "renesas,fdp1";
+   reg = <0 0xfe94 0 0x2400>;
+   interrupts = ;
+   clocks = < CPG_MOD 119>;
+   power-domains = < R8A7795_PD_A3VP>;
+   renesas,fcp = <>;
+   };
\ No newline at end of file
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] dt-bindings: Update Renesas R-Car FCP DT binding

2016-06-09 Thread Kieran Bingham

The FCP driver, can also support the FCPF variant for FDP1 compatible
processing.

Signed-off-by: Kieran Bingham 
---
 Documentation/devicetree/bindings/media/renesas,fcp.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/media/renesas,fcp.txt 
b/Documentation/devicetree/bindings/media/renesas,fcp.txt
index 6a12960609d8..271dcfdb5a76 100644
--- a/Documentation/devicetree/bindings/media/renesas,fcp.txt
+++ b/Documentation/devicetree/bindings/media/renesas,fcp.txt
@@ -7,12 +7,14 @@ conversion of AXI transactions in order to reduce the memory 
bandwidth.
 
 There are three types of FCP: FCP for Codec (FCPC), FCP for VSP (FCPV) and FCP
 for FDP (FCPF). Their configuration and behaviour depend on the module they
-are paired with. These DT bindings currently support the FCPV only.
+are paired with. These DT bindings currently support the FCPV and FCPF.
 
  - compatible: Must be one or more of the following
 
- "renesas,r8a7795-fcpv" for R8A7795 (R-Car H3) compatible 'FCP for VSP'
+   - "renesas,r8a7795-fcpf" for R8A7795 (R-Car H3) compatible 'FCP for FDP'
- "renesas,fcpv" for generic compatible 'FCP for VSP'
+   - "renesas,fcpf" for generic compatible 'FCP for FDP'
 
When compatible with the generic version, nodes must list the
SoC-specific version corresponding to the platform first, followed by the
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] dt-bindings: Document Renesas R-Car FCP power-domains usage

2016-06-09 Thread Kieran Bingham

The power domain must be specified to bring the device out of module
standby. Document this in the example provided, so that new additions
are not missed.

Signed-off-by: Kieran Bingham 
---
 Documentation/devicetree/bindings/media/renesas,fcp.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/media/renesas,fcp.txt 
b/Documentation/devicetree/bindings/media/renesas,fcp.txt
index 271dcfdb5a76..6a55f5215221 100644
--- a/Documentation/devicetree/bindings/media/renesas,fcp.txt
+++ b/Documentation/devicetree/bindings/media/renesas,fcp.txt
@@ -31,4 +31,5 @@ Device node example
compatible = "renesas,r8a7795-fcpv", "renesas,fcpv";
reg = <0 0xfea2f000 0 0x200>;
clocks = < CPG_MOD 602>;
+   power-domains = < R8A7795_PD_A3VP>;
};
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

dvb-core: how should i2c subdev drivers be attached?

2016-06-09 Thread Akihiro TSUKADA

Hi,
excuse me for taking up a very old post again,
but I'd like to know the status of the patch:
  https://patchwork.linuxtv.org/patch/27922/
, which provides helper code for defining/loading i2c DVB subdev drivers.

Was it rejected and 
each i2c demod/tuner drivers should provide its own version of "attach" code?
Or is it acceptable (with some modifications) ?

Although not many drivers currently use i2c binding model (and use 
dvb_attach()),
but I expect that coming DVB subdev drivers will have a similar attach code,
including module request/ref-counting, device creation,
(re-)using i2c_board_info.platformdata to pass around both config parameters
and the resulting i2c_client* & dvb_frontend*.

Since I have a plan to split out demod/tuner drivers from pci/pt1 dvb-usb/friio
integrated drivers (because those share the tc90522 demod driver with pt3, and
friio also shares the bridge chip with gl861),
it would be nice if I can use the helper code,
instead of re-iterating similar "attach" code.

--
akihiro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [media] rc: Remove init_ir_raw_event and DEFINE_IR_RAW_EVENT

2016-06-09 Thread Mauro Carvalho Chehab

Em Wed, 13 Apr 2016 10:36:51 +0100
Sean Young  escreveu:

> On Wed, Apr 13, 2016 at 02:07:49PM +0800, kbuild test robot wrote:
> > Hi Sean,
> > 
> > [auto build test ERROR on linuxtv-media/master]
> > [also build test ERROR on v4.6-rc3 next-20160412]
> > [if your patch is applied to the wrong git tree, please drop us a note to 
> > help improving the system]
> > 
> > url:
> > https://github.com/0day-ci/linux/commits/Sean-Young/rc-Remove-init_ir_raw_event-and-DEFINE_IR_RAW_EVENT/20160412-203118
> > base:   git://linuxtv.org/media_tree.git master
> > config: openrisc-allmodconfig (attached as .config)
> > reproduce:
> > wget 
> > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
> >  -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > # save the attached .config to linux build tree
> > make.cross ARCH=openrisc 
> > 
> > All errors (new ones prefixed by >>):
> > 
> >drivers/media/i2c/cx25840/cx25840-ir.c: In function 
> > 'cx25840_ir_rx_read':  
> > >> drivers/media/i2c/cx25840/cx25840-ir.c:710:4: error: unknown field 
> > >> 'duration' specified in initializer  
> > --
> >drivers/media/rc/streamzap.c: In function 'streamzap_callback':  
> > >> drivers/media/rc/streamzap.c:258:6: error: unknown field 'duration' 
> > >> specified in initializer  
> > 
> > vim +/duration +710 drivers/media/i2c/cx25840/cx25840-ir.c
> > 
> >704  v = (unsigned) pulse_width_count_to_ns(
> >705(u16) (p->hw_fifo_data & 
> > FIFO_RXTX), divider);
> >706  if (v > IR_MAX_DURATION)
> >707  v = IR_MAX_DURATION;
> >708  
> >709  p->ir_core_data = (struct ir_raw_event)  
> >  > 710  { .pulse = u, .duration = v, .timeout = 
> > w };  
> 
> Looks like gcc 4.5.1 does not handle anonymous union initializers properly.
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676
> 
> I don't think this patch can be reworked without it.

So, let's not apply it. According with Documentation/Changes, the
minimal gcc version we should support is 3.2.

Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 2/2] media: Add a driver for the ov5645 camera sensor.

2016-06-09 Thread Todor Tomov

The ov5645 sensor from Omnivision supports up to 2592x1944
and CSI2 interface.

The driver adds support for the following modes:
- 1280x960
- 1920x1080
- 2592x1944

Output format is packed 8bit UYVY.

Signed-off-by: Todor Tomov 
---
 drivers/media/i2c/Kconfig  |   12 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/ov5645.c | 1369 
 3 files changed, 1382 insertions(+)
 create mode 100644 drivers/media/i2c/ov5645.c

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 993dc50..0cee05b 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -500,6 +500,18 @@ config VIDEO_OV2659
  To compile this driver as a module, choose M here: the
  module will be called ov2659.
 
+config VIDEO_OV5645
+   tristate "OmniVision OV5645 sensor support"
+   depends on OF
+   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
+ OV5645 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov5645.
+
 config VIDEO_OV7640
tristate "OmniVision OV7640 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 94f2c99..2485aed 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_VIDEO_VP27SMPX) += vp27smpx.o
 obj-$(CONFIG_VIDEO_SONY_BTF_MPX) += sony-btf-mpx.o
 obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
 obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
+obj-$(CONFIG_VIDEO_OV5645) += ov5645.o
 obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
 obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
 obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
diff --git a/drivers/media/i2c/ov5645.c b/drivers/media/i2c/ov5645.c
new file mode 100644
index 000..cc695c0
--- /dev/null
+++ b/drivers/media/i2c/ov5645.c
@@ -0,0 +1,1369 @@
+/*
+ * Driver for the OV5645 camera sensor.
+ *
+ * Copyright (c) 2011-2015, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2015 By Tech Design S.L. All Rights Reserved.
+ * Copyright (C) 2012-2013 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * Based on:
+ * - the OV5645 driver from QC msm-3.10 kernel on codeaurora.org:
+ *   https://us.codeaurora.org/cgit/quic/la/kernel/msm-3.10/tree/drivers/
+ *   media/platform/msm/camera_v2/sensor/ov5645.c?h=LA.BR.1.2.4_rb1.41
+ * - the OV5640 driver posted on linux-media:
+ *   https://www.mail-archive.com/linux-media%40vger.kernel.org/msg92671.html
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define OV5645_VOLTAGE_ANALOG   280
+#define OV5645_VOLTAGE_DIGITAL_CORE 150
+#define OV5645_VOLTAGE_DIGITAL_IO   180
+
+#define OV5645_XCLK2388
+
+#define OV5645_SYSTEM_CTRL00x3008
+#defineOV5645_SYSTEM_CTRL0_START   0x02
+#defineOV5645_SYSTEM_CTRL0_STOP0x42
+#define OV5645_CHIP_ID_HIGH_REG0x300A
+#defineOV5645_CHIP_ID_HIGH 0x56
+#define OV5645_CHIP_ID_LOW_REG 0x300B
+#defineOV5645_CHIP_ID_LOW  0x45
+#define OV5645_AWB_MANUAL_CONTROL  0x3406
+#defineOV5645_AWB_MANUAL_ENABLEBIT(0)
+#define OV5645_AEC_PK_MANUAL   0x3503
+#defineOV5645_AEC_MANUAL_ENABLEBIT(0)
+#defineOV5645_AGC_MANUAL_ENABLEBIT(1)
+#define OV5645_TIMING_TC_REG20 0x3820
+#defineOV5645_SENSOR_VFLIP BIT(1)
+#defineOV5645_ISP_VFLIPBIT(2)
+#define OV5645_TIMING_TC_REG21 0x3821
+#defineOV5645_SENSOR_MIRRORBIT(1)
+#define OV5645_PRE_ISP_TEST_SETTING_1  0x503d
+#defineOV5645_TEST_PATTERN_MASK0x3
+#defineOV5645_SET_TEST_PATTERN(x)  ((x) & 
OV5645_TEST_PATTERN_MASK)
+#defineOV5645_TEST_PATTERN_ENABLE  BIT(7)
+#define OV5645_SDE_SAT_U   0x5583
+#define OV5645_SDE_SAT_V   0x5584
+
+enum ov5645_mode {
+   OV5645_MODE_MIN = 0,
+   OV5645_MODE_SXGA = 0,
+   OV5645_MODE_1080P = 1,
+

[PATCH v4 1/2] media: i2c/ov5645: add the device tree binding document

2016-06-09 Thread Todor Tomov

Add the document for ov5645 device tree binding.

Signed-off-by: Todor Tomov 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/media/i2c/ov5645.txt   | 50 ++
 1 file changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5645.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/ov5645.txt 
b/Documentation/devicetree/bindings/media/i2c/ov5645.txt
new file mode 100644
index 000..468cf83
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov5645.txt
@@ -0,0 +1,50 @@
+* Omnivision 1/4-Inch 5Mp CMOS Digital Image Sensor
+
+The Omnivision OV5645 is a 1/4-Inch CMOS active pixel digital image sensor with
+an active array size of 2592H x 1944V. It is programmable through a serial I2C
+interface.
+
+Required Properties:
+- compatible: Value should be "ovti,ov5645".
+- clocks: Reference to the xclk clock.
+- clock-names: Should be "xclk".
+- enable-gpios: Chip enable GPIO. Polarity is GPIO_ACTIVE_HIGH.
+- reset-gpios: Chip reset GPIO. Polarity is GPIO_ACTIVE_LOW.
+- vdddo-supply: Chip digital IO regulator.
+- vdda-supply: Chip analog regulator.
+- vddd-supply: Chip digital core regulator.
+
+The device node must contain one 'port' child node for its digital output
+video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+{
+   ...
+
+   ov5645: ov5645@78 {
+   compatible = "ovti,ov5645";
+   reg = <0x78>;
+
+   enable-gpios = < 6 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 20 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_rear_default>;
+
+   clocks = < 200>;
+   clock-names = "xclk";
+
+   vdddo-supply = <_dovdd_1v8>;
+   vdda-supply = <_avdd_2v8>;
+   vddd-supply = <_dvdd_1v2>;
+
+   port {
+   ov5645_ep: endpoint {
+   clock-lanes = <1>;
+   data-lanes = <0 2>;
+   remote-endpoint = <_ep>;
+   };
+   };
+   };
+   };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 0/2] OV5645 camera sensor driver

2016-06-09 Thread Todor Tomov

This is the fourth version of the OV5645 camera sensor driver patchset.

Only one change since version 3:
- build failure on kernel v4.7-rc1 fixed:
  s/media_entity_init/media_entity_pads_init/

Changes from version 2 include:
- external camera clock configuration is moved from DT to driver;
- pwdn-gpios renamed to enable-gpios;
- switched polarity of reset-gpios to the more intuitive active low;
- added Kconfig dependency to OF;
- return values checks;
- regulators and gpios are now required (not optional);
- regulators names renamed;
- power counter variable changed to a bool power state;
- ov5645_registered() is removed and sensor id reading moved to probe().

Changes from version 1 include:
- patch split to dt binding doc patch and driver patch;
- changes in power on/off logic - s_power is now not called on
  open/close;
- using assigned-clock-rates in dt for setting camera external
  clock rate;
- correct api for gpio handling;
- return values checks;
- style fixes.

Todor Tomov (2):
  media: i2c/ov5645: add the device tree binding document
  media: Add a driver for the ov5645 camera sensor.

 .../devicetree/bindings/media/i2c/ov5645.txt   |   50 +
 drivers/media/i2c/Kconfig  |   12 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/ov5645.c | 1369 
 4 files changed, 1432 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5645.txt
 create mode 100644 drivers/media/i2c/ov5645.c

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/6] drivers/media/media-device: add "release" callback

2016-06-09 Thread Mauro Carvalho Chehab

Em Mon, 21 Mar 2016 14:30:38 +0100
Max Kellermann  escreveu:

> Allow the client to free its data structures only after all files have
> been closed (fixing use-after-free bugs).

Hmm... Shuah is also working on fixing such issues at the media controller
stuff, and I made a few fix patches myself.

Our work is at:
https://git.linuxtv.org/mchehab/experimental.git/log/?h=media_cdev_fix

Please base your changes on it, to avoid conflicting work or rework.

I just rebased it on the top of media_tree (plus the patches for it
that I didn't push yet).


Thanks!
Mauro


> 
> Signed-off-by: Max Kellermann 
> ---
>  drivers/media/media-device.c |9 +++--
>  include/media/media-device.h |2 ++
>  2 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index 5c4669c..a3901f9 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -551,9 +551,14 @@ static DEVICE_ATTR(model, S_IRUGO, show_model, NULL);
>   * Registration/unregistration
>   */
>  
> -static void media_device_release(struct media_devnode *mdev)
> +static void media_device_release(struct media_devnode *devnode)
>  {
> - dev_dbg(mdev->parent, "Media device released\n");
> + struct media_device *mdev = to_media_device(devnode);
> +
> + dev_dbg(devnode->parent, "Media device released\n");
> +
> + if (mdev->release)
> + mdev->release(mdev);
>  }
>  
>  /**
> diff --git a/include/media/media-device.h b/include/media/media-device.h
> index d385589..d184d0c 100644
> --- a/include/media/media-device.h
> +++ b/include/media/media-device.h
> @@ -326,6 +326,8 @@ struct media_device {
>  
>   int (*link_notify)(struct media_link *link, u32 flags,
>  unsigned int notification);
> +
> + void (*release)(struct media_device *mdev);
>  };
>  
>  #ifdef CONFIG_MEDIA_CONTROLLER
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/6] drivers/media/dvb-core/en50221: postpone release until file is closed

2016-06-09 Thread Mauro Carvalho Chehab

Em Mon, 21 Mar 2016 14:30:22 +0100
Max Kellermann  escreveu:

> Fixes use-after-free bug which occurs when I disconnect my DVB-S
> received while VDR is running.

I guess that the best way to fix it is to use a kref() that would be also
incremented at open() and decremented at release(). 

This works better than adding other non-standard ways to manage data livetime
cycle.

Regards,
Mauro

> 
> Signed-off-by: Max Kellermann 
> ---
>  drivers/media/dvb-core/dvb_ca_en50221.c |   23 ++-
>  1 file changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/dvb-core/dvb_ca_en50221.c 
> b/drivers/media/dvb-core/dvb_ca_en50221.c
> index e33364c..dfc686a 100644
> --- a/drivers/media/dvb-core/dvb_ca_en50221.c
> +++ b/drivers/media/dvb-core/dvb_ca_en50221.c
> @@ -148,6 +148,9 @@ struct dvb_ca_private {
>   /* Flag indicating if the CA device is open */
>   unsigned int open:1;
>  
> + /* Flag indicating if the CA device is released */
> + unsigned int released:1;
> +
>   /* Flag indicating the thread should wake up now */
>   unsigned int wakeup:1;
>  
> @@ -1392,6 +1395,11 @@ static int dvb_ca_en50221_io_read_condition(struct 
> dvb_ca_private *ca,
>   int found = 0;
>   u8 hdr[2];
>  
> + if (ca->released) {
> + *result = -ENODEV;
> + return 1;
> + }
> +
>   slot = ca->next_read_slot;
>   while ((slot_count < ca->slot_count) && (!found)) {
>   if (ca->slot_info[slot].slot_state != DVB_CA_SLOTSTATE_RUNNING)
> @@ -1595,6 +1603,9 @@ static int dvb_ca_en50221_io_release(struct inode 
> *inode, struct file *file)
>  
>   err = dvb_generic_release(inode, file);
>  
> + if (ca->released)
> + dvb_ca_private_free(ca);
> +
>   module_put(ca->pub->owner);
>  
>   return err;
> @@ -1701,6 +1712,7 @@ int dvb_ca_en50221_init(struct dvb_adapter *dvb_adapter,
>   }
>   init_waitqueue_head(>wait_queue);
>   ca->open = 0;
> + ca->released = 0;
>   ca->wakeup = 0;
>   ca->next_read_slot = 0;
>   pubca->private = ca;
> @@ -1765,12 +1777,21 @@ void dvb_ca_en50221_release(struct dvb_ca_en50221 
> *pubca)
>  
>   dprintk("%s\n", __func__);
>  
> + BUG_ON(ca->released);
> +
>   /* shutdown the thread if there was one */
>   kthread_stop(ca->thread);
>  
>   for (i = 0; i < ca->slot_count; i++) {
>   dvb_ca_en50221_slot_shutdown(ca, i);
>   }
> - dvb_ca_private_free(ca);
> +
> + if (ca->open) {
> + ca->released = 1;
> + mb();
> + wake_up_interruptible(>wait_queue);
> + } else
> + dvb_ca_private_free(ca);
> +
>   pubca->private = NULL;
>  }
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

cron job: media_tree daily build: ERRORS

Re: [PATCH 2/2] [media] media-device: dynamically allocate struct media_devnode

Re: [PATCH] [media]: Driver for Toshiba et8ek8 5MP sensor

Re: [PATCHv2] device tree description for AD5820 camera auto-focus coil

Re: Kernel 4.7.0-rc2 warnings with Facetime HD camera on Macbook Pro 8,1

[PATCH] [media] s5p-mfc: use vb2_is_streaming() to check vb2 queue status

Re: dvb-core: how should i2c subdev drivers be attached?

Re: dvb-core: how should i2c subdev drivers be attached?

Re: dvb-core: how should i2c subdev drivers be attached?

Re: dvb-core: how should i2c subdev drivers be attached?

[PATCH] [media] v4l: vsp1: Fix format-info documentation

Re: dvb-core: how should i2c subdev drivers be attached?

[PATCH RFC 2/2] MAINTAINERS: Add support for FDP driver

[PATCH RFC 1/2] v4l: platform: Add Renesas R-Car FDP1 Driver

[PATCH RFC 0/2] v4l: platform: Add Renesas R-Car FDP1 Driver

[PATCH] v4l: Extend FCP compatible list to support the FDP

[PATCH] v4l: Extend FCP compatible list to support the FDP

Re: dvb-core: how should i2c subdev drivers be attached?

Re: dvb-core: how should i2c subdev drivers be attached?

Re: dvb-core: how should i2c subdev drivers be attached?

Re: dvb-core: how should i2c subdev drivers be attached?

[PATCH 3/3] dt-bindings: Add Renesas R-Car FDP1 bindings

[PATCH 1/3] dt-bindings: Update Renesas R-Car FCP DT binding

[PATCH 2/3] dt-bindings: Document Renesas R-Car FCP power-domains usage

dvb-core: how should i2c subdev drivers be attached?

Re: [PATCH] [media] rc: Remove init_ir_raw_event and DEFINE_IR_RAW_EVENT

[PATCH v4 2/2] media: Add a driver for the ov5645 camera sensor.

[PATCH v4 1/2] media: i2c/ov5645: add the device tree binding document

[PATCH v4 0/2] OV5645 camera sensor driver

Re: [PATCH 5/6] drivers/media/media-device: add "release" callback

Re: [PATCH 2/6] drivers/media/dvb-core/en50221: postpone release until file is closed

31 matches

Site Navigation

Mail list logo

Footer information