Re: Baytrail camera csi / isp support status ?

2015-01-05 Thread Laurent Pinchart 
Hi Bastien,

On Tuesday 06 January 2015 01:06:54 Bastien Nocera wrote:
 On Fri, 2014-12-12 at 12:07 +0100, Hans de Goede wrote:
  Hi All,
  
  A college of mine has a baytrail bases tablet:
  
  http://www.onda-tablet.com/onda-v975w-quad-core-win-8-tablet-9-7-inch-reti
  na-screen-ram-2gb-wifi-32gb.html
  
  And he is trying to get Linux to run on it, he has things mostly
  working, but he would also like to get the cameras to work.
  
  I've found this:
  
  http://sourceforge.net/projects/e3845mipi/files/
  
  Which is some not so pretty code, with the usual problems of using
  custom ioctls to pass info from the statistics block of the isp
  to userspace and then let some userspace thingie (blob?) handle it.
  
  So I was wondering if anyone is working on proper support
  (targeting upstream) for this ? It would be nice if we could at least
  get the csi bits going, using the sensors or software auto-whitebal, etc.
  for now.
 
 As I mentioned to Hans in private, I would be ready to provide the
 hardware for somebody with a track record to keep, to allow testing and
 hopefully maintaining that code longer term.
 
 I would expect that this sort of hardware is already quite common
 amongst Windows 8 tablets so it would be very helpful to have working
 out-of-the-box on a stock Linux.

$ cat BYT_LSP_3.11_ISP_2013-12-26.patch | diffstat -s
 302 files changed, 91662 insertions(+), 2 deletions(-)

There's no interest in upstreaming the code on Intel's side. As far as I 
understand their ISP is more like a programmable DSP than a fixed pipeline 
ISP. I expect the driver they have published to hardcode the pipeline 
programmed in a particular firmware and thus be specific to a limited number 
of devices. Given the amount of work required to get the code in shape, and 
given that reusability would be very limited if my assumptions are correct, I 
don't really see this happening unless you can find a motivated developer with 
way too much free time.

-- 
Regards,

Laurent Pinchart

--
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 1/2] V4L: remove clock name from v4l2_clk API

2015-01-05 Thread Guennadi Liakhovetski 
Hi Josh,

On Mon, 5 Jan 2015, Josh Wu wrote:

 Hi, Guennadi
 
 On 1/2/2015 7:48 PM, Guennadi Liakhovetski wrote:
  All uses of the v4l2_clk API so far only register one clock with a fixed
  name. This allows us to get rid of it, which also will make CCF and DT
  integration easier.
 This patch not register a v4l2_clk with name: mclk. So this will break all
 the i2c sensors that used the v4l2 clock mclk.
 To make those drivers work, we need change all lines from:
v4l2_clk_get(client-dev, mclk);
 to:
v4l2_clk_get(client-dev, NULL);
 
 Am I understanding correctly?

No, it's the opposite. Clock consumers should request clock names, 
according to their datasheets. In ov2640 case it's xvclk. For v4l2_clk the 
name will simply be ignored. But it will be used to try to get a CCF clock 
before falling back to V4L2 clocks.

Thanks
Guennadi

 if yes, I'd like to define a SOC_CAMERA_HOST_CLK_ID in soc_camera.h, and all
 code will use:
 v4l2_clk_get(client-dev, SOC_CAMERA_HOST_CLK_ID);
 
  
  Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
  ---
drivers/media/platform/soc_camera/soc_camera.c |  6 +++---
drivers/media/usb/em28xx/em28xx-camera.c   |  2 +-
drivers/media/v4l2-core/v4l2-clk.c | 24
  +++-
include/media/v4l2-clk.h   |  7 +++
4 files changed, 18 insertions(+), 21 deletions(-)
  
  diff --git a/drivers/media/platform/soc_camera/soc_camera.c
  b/drivers/media/platform/soc_camera/soc_camera.c
  index f4be2a1..ce192b6 100644
  --- a/drivers/media/platform/soc_camera/soc_camera.c
  +++ b/drivers/media/platform/soc_camera/soc_camera.c
  @@ -1380,7 +1380,7 @@ static int soc_camera_i2c_init(struct
  soc_camera_device *icd,
  snprintf(clk_name, sizeof(clk_name), %d-%04x,
   shd-i2c_adapter_id, shd-board_info-addr);
- icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name, mclk,
  icd);
  +   icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name, icd);
  if (IS_ERR(icd-clk)) {
  ret = PTR_ERR(icd-clk);
  goto eclkreg;
  @@ -1561,7 +1561,7 @@ static int scan_async_group(struct soc_camera_host
  *ici,
  snprintf(clk_name, sizeof(clk_name), %d-%04x,
   sasd-asd.match.i2c.adapter_id, sasd-asd.match.i2c.address);
- icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name, mclk,
  icd);
  +   icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name, icd);
  if (IS_ERR(icd-clk)) {
  ret = PTR_ERR(icd-clk);
  goto eclkreg;
  @@ -1666,7 +1666,7 @@ static int soc_of_bind(struct soc_camera_host *ici,
  snprintf(clk_name, sizeof(clk_name), of-%s,
   of_node_full_name(remote));
- icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name, mclk,
  icd);
  +   icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name, icd);
  if (IS_ERR(icd-clk)) {
  ret = PTR_ERR(icd-clk);
  goto eclkreg;
  diff --git a/drivers/media/usb/em28xx/em28xx-camera.c
  b/drivers/media/usb/em28xx/em28xx-camera.c
  index 7be661f..a4b22c2 100644
  --- a/drivers/media/usb/em28xx/em28xx-camera.c
  +++ b/drivers/media/usb/em28xx/em28xx-camera.c
  @@ -330,7 +330,7 @@ int em28xx_init_camera(struct em28xx *dev)
  v4l2_clk_name_i2c(clk_name, sizeof(clk_name),
i2c_adapter_id(adap), client-addr);
  -   v4l2-clk = v4l2_clk_register_fixed(clk_name, mclk, -EINVAL);
  +   v4l2-clk = v4l2_clk_register_fixed(clk_name, -EINVAL);
  if (IS_ERR(v4l2-clk))
  return PTR_ERR(v4l2-clk);
diff --git a/drivers/media/v4l2-core/v4l2-clk.c
  b/drivers/media/v4l2-core/v4l2-clk.c
  index e18cc04..c210906 100644
  --- a/drivers/media/v4l2-core/v4l2-clk.c
  +++ b/drivers/media/v4l2-core/v4l2-clk.c
  @@ -31,7 +31,8 @@ static struct v4l2_clk *v4l2_clk_find(const char *dev_id,
  const char *id)
  if (strcmp(dev_id, clk-dev_id))
  continue;
- if (!id || !clk-id || !strcmp(clk-id, id))
  +   if ((!id  !clk-id) ||
  +   (id  clk-id  !strcmp(clk-id, id)))
  return clk;
  }
@@ -127,8 +128,8 @@ void v4l2_clk_disable(struct v4l2_clk *clk)
  mutex_lock(clk-lock);
  enable = --clk-enable;
  -   if (WARN(enable  0, Unbalanced %s() on %s:%s!\n, __func__,
  -clk-dev_id, clk-id))
  +   if (WARN(enable  0, Unbalanced %s() on %s!\n, __func__,
  +clk-dev_id))
  clk-enable++;
  else if (!enable  clk-ops-disable)
  clk-ops-disable(clk);
  @@ -181,7 +182,7 @@ EXPORT_SYMBOL(v4l2_clk_set_rate);
  struct v4l2_clk *v4l2_clk_register(const struct v4l2_clk_ops *ops,
 const char *dev_id,
  -  const char *id, void *priv)
  +  void *priv)
{
  struct v4l2_clk *clk;
  int ret;
  @@ -193,9 +194,8 @@ struct v4l2_clk *v4l2_clk_register(const struct

Re: [PATCH v2 12/13] ARM: dts: sun6i: Add sun6i-a31s.dtsi

2015-01-05 Thread Hans de Goede 

Hi,

On 05-01-15 10:08, Maxime Ripard wrote:

Hi,

On Mon, Dec 22, 2014 at 02:46:12PM +0100, Hans de Goede wrote:

On 21-12-14 23:39, Maxime Ripard wrote:

On Sat, Dec 20, 2014 at 11:24:55AM +0100, Hans de Goede wrote:


snip


Given your previous changes, you should also update the enable-method.


I've not added a new compatible for the enable-method, given that
this is the exact same die, so the 2 are 100?% compatible, just like you
insisted that allwinner,sun4i-a10-mod0-clk should be used for the ir-clk
since it was 100% compatible to that I believe that the enable method
should use the existing compatible and not invent a new one for something
which is 100% compatible.


Yeah, you have a point and I agree, but your patch 3 does add a
CPU_METHOD_OF_DECLARE for the A31s.


Ah right, it does, my bad.


Since I was going to push the branch now that 3.19-rc1 is out, do you
want me to edit your patch before doing so?


Yes, please drop the addition of the extra CPU_METHOD_OF_DECLARE, or let
me know if you want a new version instead.


I just modified it, and pushed it, no need to resend it.


Thanks, while looking at your dt-for-3.20 branch I noticed that you've
merged v2 of ARM: dts: sun6i: Add ir node, I did a v3 adding an ir:
label to the node, which I noticed was missing because you asked me to
move the a31s dt stuff to moving label references, can you fix this up, or
do you want me to do a follow up patch ?

Note that having this fixed is a pre-req for the csq-cs908 dts patch.

Regards,

Hans
--
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 v2 2/2] V4L2: add CCF support to the v4l2_clk API

2015-01-05 Thread Guennadi Liakhovetski 
On Mon, 5 Jan 2015, Josh Wu wrote:

 Hi, Guennadi
 
 On 1/3/2015 4:18 AM, Guennadi Liakhovetski wrote:
   From aeaee56e04d023f3a019d2595ef5128015acdb06 Mon Sep 17 00:00:00 2001
  From: Guennadi Liakhovetski g.liakhovet...@gmx.de
  Date: Fri, 2 Jan 2015 12:26:41 +0100
  Subject: [PATCH 2/2] V4L2: add CCF support to the v4l2_clk API
  
  V4L2 clocks, e.g. used by camera sensors for their master clock, do not
  have to be supplied by a different V4L2 driver, they can also be
  supplied by an independent source. In this case the standart kernel
  clock API should be used to handle such clocks. This patch adds support
  for such cases.
  
  Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
  ---
  
  Hi Laurent,
  Thanks for the comment. The idea of allocating a new object for each get
  operation seems a bit weird to me, and completely trusting the user is a
  bit scary... :) But yes, it can work this way too, I think, and the user
  can screw either way too, anyway. So, here comes a v2. Something like
  this?
  
  v2: don't add CCF-related clocks on the global list, just allocate a new
  instance on each v4l2_clk_get()
  
drivers/media/v4l2-core/v4l2-clk.c | 45
  +++---
include/media/v4l2-clk.h   |  2 ++
2 files changed, 44 insertions(+), 3 deletions(-)
  
  diff --git a/drivers/media/v4l2-core/v4l2-clk.c
  b/drivers/media/v4l2-core/v4l2-clk.c
  index c210906..f5d1688 100644
  --- a/drivers/media/v4l2-core/v4l2-clk.c
  +++ b/drivers/media/v4l2-core/v4l2-clk.c
  @@ -9,6 +9,7 @@
 */
  #include linux/atomic.h
  +#include linux/clk.h
#include linux/device.h
#include linux/errno.h
#include linux/list.h
  @@ -42,6 +43,18 @@ static struct v4l2_clk *v4l2_clk_find(const char *dev_id,
  const char *id)
struct v4l2_clk *v4l2_clk_get(struct device *dev, const char *id)
{
  struct v4l2_clk *clk;
  +   struct clk *ccf_clk = clk_get(dev, id);
 We need to check whether the 'id' is NULL, otherwise there is no error
 reported if we use IS_ERR(ccf_clk).

? Sorry, don't understand. AFAIK, id = NULL is absolutely valid, no need 
to check for it explicitly. However, it just occurs to me, that we 
probably need to change the below test

 Best Regards,
 Josh Wu
 
  +
  +   if (!IS_ERR(ccf_clk)) {

to

  +   if (!IS_ERR_OR_NULL(ccf_clk)) {

to cover the case when CCF isn't built at all and a stub is used. In that 
case it's probably better to fall back to the V4L2 clock emulation.

Thanks
Guennadi

  +   clk = kzalloc(sizeof(struct v4l2_clk), GFP_KERNEL);
  +   if (!clk) {
  +   clk_put(ccf_clk);
  +   return ERR_PTR(-ENOMEM);
  +   }
  +   clk-clk = ccf_clk;
  +
  +   return clk;
  +   }
  mutex_lock(clk_lock);
  clk = v4l2_clk_find(dev_name(dev), id);
  @@ -61,6 +74,12 @@ void v4l2_clk_put(struct v4l2_clk *clk)
  if (IS_ERR(clk))
  return;
+ if (clk-clk) {
  +   clk_put(clk-clk);
  +   kfree(clk);
  +   return;
  +   }
  +
  mutex_lock(clk_lock);
  list_for_each_entry(tmp, clk_list, list)
  @@ -98,8 +117,12 @@ static void v4l2_clk_unlock_driver(struct v4l2_clk *clk)
  int v4l2_clk_enable(struct v4l2_clk *clk)
{
  -   int ret = v4l2_clk_lock_driver(clk);
  +   int ret;
+ if (clk-clk)
  +   return clk_enable(clk-clk);
  +
  +   ret = v4l2_clk_lock_driver(clk);
  if (ret  0)
  return ret;
@@ -125,6 +148,9 @@ void v4l2_clk_disable(struct v4l2_clk *clk)
{
  int enable;
+ if (clk-clk)
  +   return clk_disable(clk-clk);
  +
  mutex_lock(clk-lock);
  enable = --clk-enable;
  @@ -142,8 +168,12 @@ EXPORT_SYMBOL(v4l2_clk_disable);
  unsigned long v4l2_clk_get_rate(struct v4l2_clk *clk)
{
  -   int ret = v4l2_clk_lock_driver(clk);
  +   int ret;
  +
  +   if (clk-clk)
  +   return clk_get_rate(clk-clk);
+ ret = v4l2_clk_lock_driver(clk);
  if (ret  0)
  return ret;
@@ -162,7 +192,16 @@ EXPORT_SYMBOL(v4l2_clk_get_rate);
  int v4l2_clk_set_rate(struct v4l2_clk *clk, unsigned long rate)
{
  -   int ret = v4l2_clk_lock_driver(clk);
  +   int ret;
  +
  +   if (clk-clk) {
  +   long r = clk_round_rate(clk-clk, rate);
  +   if (r  0)
  +   return r;
  +   return clk_set_rate(clk-clk, r);
  +   }
  +
  +   ret = v4l2_clk_lock_driver(clk);
  if (ret  0)
  return ret;
  diff --git a/include/media/v4l2-clk.h b/include/media/v4l2-clk.h
  index 8f06967..4402b2d 100644
  --- a/include/media/v4l2-clk.h
  +++ b/include/media/v4l2-clk.h
  @@ -22,6 +22,7 @@
struct module;
struct device;
+struct clk;
struct v4l2_clk {
  struct list_head list;
  const struct v4l2_clk_ops *ops;
  @@ -30,6 +31,7 @@ struct v4l2_clk {
  int enable;
  struct mutex lock; /* Protect the enable count */
  atomic_t use_count;
  +

Re: [PATCH v2 2/2] V4L2: add CCF support to the v4l2_clk API

2015-01-05 Thread Josh Wu 

On 1/5/2015 5:36 PM, Guennadi Liakhovetski wrote:

On Mon, 5 Jan 2015, Josh Wu wrote:


Hi, Guennadi

On 1/3/2015 4:18 AM, Guennadi Liakhovetski wrote:

  From aeaee56e04d023f3a019d2595ef5128015acdb06 Mon Sep 17 00:00:00 2001
From: Guennadi Liakhovetski g.liakhovet...@gmx.de
Date: Fri, 2 Jan 2015 12:26:41 +0100
Subject: [PATCH 2/2] V4L2: add CCF support to the v4l2_clk API

V4L2 clocks, e.g. used by camera sensors for their master clock, do not
have to be supplied by a different V4L2 driver, they can also be
supplied by an independent source. In this case the standart kernel
clock API should be used to handle such clocks. This patch adds support
for such cases.

Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---

Hi Laurent,
Thanks for the comment. The idea of allocating a new object for each get
operation seems a bit weird to me, and completely trusting the user is a
bit scary... :) But yes, it can work this way too, I think, and the user
can screw either way too, anyway. So, here comes a v2. Something like
this?

v2: don't add CCF-related clocks on the global list, just allocate a new
instance on each v4l2_clk_get()

   drivers/media/v4l2-core/v4l2-clk.c | 45
+++---
   include/media/v4l2-clk.h   |  2 ++
   2 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-clk.c
b/drivers/media/v4l2-core/v4l2-clk.c
index c210906..f5d1688 100644
--- a/drivers/media/v4l2-core/v4l2-clk.c
+++ b/drivers/media/v4l2-core/v4l2-clk.c
@@ -9,6 +9,7 @@
*/
 #include linux/atomic.h
+#include linux/clk.h
   #include linux/device.h
   #include linux/errno.h
   #include linux/list.h
@@ -42,6 +43,18 @@ static struct v4l2_clk *v4l2_clk_find(const char *dev_id,
const char *id)
   struct v4l2_clk *v4l2_clk_get(struct device *dev, const char *id)
   {
struct v4l2_clk *clk;
+   struct clk *ccf_clk = clk_get(dev, id);

We need to check whether the 'id' is NULL, otherwise there is no error
reported if we use IS_ERR(ccf_clk).

? Sorry, don't understand. AFAIK, id = NULL is absolutely valid, no need
to check for it explicitly. However, it just occurs to me, that we
probably need to change the below test


Best Regards,
Josh Wu


+
+   if (!IS_ERR(ccf_clk)) {

to


+   if (!IS_ERR_OR_NULL(ccf_clk)) {

to cover the case when CCF isn't built at all and a stub is used. In that
case it's probably better to fall back to the V4L2 clock emulation.
yes, this's what I mean. but I don't know the function 
IS_ERR_OR_NULL().  ;-)


Best Regards,
Josh Wu



Thanks
Guennadi


+   clk = kzalloc(sizeof(struct v4l2_clk), GFP_KERNEL);
+   if (!clk) {
+   clk_put(ccf_clk);
+   return ERR_PTR(-ENOMEM);
+   }
+   clk-clk = ccf_clk;
+
+   return clk;
+   }
mutex_lock(clk_lock);
clk = v4l2_clk_find(dev_name(dev), id);
@@ -61,6 +74,12 @@ void v4l2_clk_put(struct v4l2_clk *clk)
if (IS_ERR(clk))
return;
   +if (clk-clk) {
+   clk_put(clk-clk);
+   kfree(clk);
+   return;
+   }
+
mutex_lock(clk_lock);
list_for_each_entry(tmp, clk_list, list)
@@ -98,8 +117,12 @@ static void v4l2_clk_unlock_driver(struct v4l2_clk *clk)
 int v4l2_clk_enable(struct v4l2_clk *clk)
   {
-   int ret = v4l2_clk_lock_driver(clk);
+   int ret;
   +if (clk-clk)
+   return clk_enable(clk-clk);
+
+   ret = v4l2_clk_lock_driver(clk);
if (ret  0)
return ret;
   @@ -125,6 +148,9 @@ void v4l2_clk_disable(struct v4l2_clk *clk)
   {
int enable;
   +if (clk-clk)
+   return clk_disable(clk-clk);
+
mutex_lock(clk-lock);
enable = --clk-enable;
@@ -142,8 +168,12 @@ EXPORT_SYMBOL(v4l2_clk_disable);
 unsigned long v4l2_clk_get_rate(struct v4l2_clk *clk)
   {
-   int ret = v4l2_clk_lock_driver(clk);
+   int ret;
+
+   if (clk-clk)
+   return clk_get_rate(clk-clk);
   +ret = v4l2_clk_lock_driver(clk);
if (ret  0)
return ret;
   @@ -162,7 +192,16 @@ EXPORT_SYMBOL(v4l2_clk_get_rate);
 int v4l2_clk_set_rate(struct v4l2_clk *clk, unsigned long rate)
   {
-   int ret = v4l2_clk_lock_driver(clk);
+   int ret;
+
+   if (clk-clk) {
+   long r = clk_round_rate(clk-clk, rate);
+   if (r  0)
+   return r;
+   return clk_set_rate(clk-clk, r);
+   }
+
+   ret = v4l2_clk_lock_driver(clk);
if (ret  0)
return ret;
diff --git a/include/media/v4l2-clk.h b/include/media/v4l2-clk.h
index 8f06967..4402b2d 100644
--- a/include/media/v4l2-clk.h
+++ b/include/media/v4l2-clk.h
@@ -22,6 +22,7 @@
   struct module;
   struct device;
   +struct clk;
   struct v4l2_clk {
struct list_head list;
const struct v4l2_clk_ops *ops;
@@ -30,6 +31,7 @@ struct v4l2_clk {

Re: [PATCH 1/2] V4L: remove clock name from v4l2_clk API

2015-01-05 Thread Josh Wu 

Hi, Guennadi

On 1/5/2015 5:28 PM, Guennadi Liakhovetski wrote:

Hi Josh,

On Mon, 5 Jan 2015, Josh Wu wrote:


Hi, Guennadi

On 1/2/2015 7:48 PM, Guennadi Liakhovetski wrote:

All uses of the v4l2_clk API so far only register one clock with a fixed
name. This allows us to get rid of it, which also will make CCF and DT
integration easier.

This patch not register a v4l2_clk with name: mclk. So this will break all
the i2c sensors that used the v4l2 clock mclk.
To make those drivers work, we need change all lines from:
v4l2_clk_get(client-dev, mclk);
to:
v4l2_clk_get(client-dev, NULL);

Am I understanding correctly?

No, it's the opposite. Clock consumers should request clock names,
according to their datasheets. In ov2640 case it's xvclk. For v4l2_clk the
name will simply be ignored. But it will be used to try to get a CCF clock
before falling back to V4L2 clocks.
Okay, you mean I only need request xvclk clock via call v4l2_clk_get() 
in ov2640 driver. right?
So the question is how do we operation the camera host's 
.clock_start/stop()? Which is by v4l2_clk_get() old mclk.


hmm, wait. Since this part is not belong to ov2640, I think we should 
move this part code to soc_camera.c 's function: soc_camera_power_on().

or do I miss anything?



Thanks
Guennadi


Best Regards,
Josh Wu

if yes, I'd like to define a SOC_CAMERA_HOST_CLK_ID in soc_camera.h, and all
code will use:
 v4l2_clk_get(client-dev, SOC_CAMERA_HOST_CLK_ID);


Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
   drivers/media/platform/soc_camera/soc_camera.c |  6 +++---
   drivers/media/usb/em28xx/em28xx-camera.c   |  2 +-
   drivers/media/v4l2-core/v4l2-clk.c | 24
+++-
   include/media/v4l2-clk.h   |  7 +++
   4 files changed, 18 insertions(+), 21 deletions(-)

diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index f4be2a1..ce192b6 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -1380,7 +1380,7 @@ static int soc_camera_i2c_init(struct
soc_camera_device *icd,
snprintf(clk_name, sizeof(clk_name), %d-%04x,
 shd-i2c_adapter_id, shd-board_info-addr);
   -icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name, mclk,
icd);
+   icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name, icd);
if (IS_ERR(icd-clk)) {
ret = PTR_ERR(icd-clk);
goto eclkreg;
@@ -1561,7 +1561,7 @@ static int scan_async_group(struct soc_camera_host
*ici,
snprintf(clk_name, sizeof(clk_name), %d-%04x,
 sasd-asd.match.i2c.adapter_id, sasd-asd.match.i2c.address);
   -icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name, mclk,
icd);
+   icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name, icd);
if (IS_ERR(icd-clk)) {
ret = PTR_ERR(icd-clk);
goto eclkreg;
@@ -1666,7 +1666,7 @@ static int soc_of_bind(struct soc_camera_host *ici,
snprintf(clk_name, sizeof(clk_name), of-%s,
 of_node_full_name(remote));
   -icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name, mclk,
icd);
+   icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name, icd);
if (IS_ERR(icd-clk)) {
ret = PTR_ERR(icd-clk);
goto eclkreg;
diff --git a/drivers/media/usb/em28xx/em28xx-camera.c
b/drivers/media/usb/em28xx/em28xx-camera.c
index 7be661f..a4b22c2 100644
--- a/drivers/media/usb/em28xx/em28xx-camera.c
+++ b/drivers/media/usb/em28xx/em28xx-camera.c
@@ -330,7 +330,7 @@ int em28xx_init_camera(struct em28xx *dev)
v4l2_clk_name_i2c(clk_name, sizeof(clk_name),
  i2c_adapter_id(adap), client-addr);
-   v4l2-clk = v4l2_clk_register_fixed(clk_name, mclk, -EINVAL);
+   v4l2-clk = v4l2_clk_register_fixed(clk_name, -EINVAL);
if (IS_ERR(v4l2-clk))
return PTR_ERR(v4l2-clk);
   diff --git a/drivers/media/v4l2-core/v4l2-clk.c
b/drivers/media/v4l2-core/v4l2-clk.c
index e18cc04..c210906 100644
--- a/drivers/media/v4l2-core/v4l2-clk.c
+++ b/drivers/media/v4l2-core/v4l2-clk.c
@@ -31,7 +31,8 @@ static struct v4l2_clk *v4l2_clk_find(const char *dev_id,
const char *id)
if (strcmp(dev_id, clk-dev_id))
continue;
   -if (!id || !clk-id || !strcmp(clk-id, id))
+   if ((!id  !clk-id) ||
+   (id  clk-id  !strcmp(clk-id, id)))
return clk;
}
   @@ -127,8 +128,8 @@ void v4l2_clk_disable(struct v4l2_clk *clk)
mutex_lock(clk-lock);
enable = --clk-enable;
-   if (WARN(enable  0, Unbalanced %s() on %s:%s!\n, __func__,
-clk-dev_id, clk-id))
+   if (WARN(enable  0, Unbalanced %s() on %s!\n, __func__,
+clk-dev_id))
clk-enable++;
else if (!enable

Re: [PATCH v2 12/13] ARM: dts: sun6i: Add sun6i-a31s.dtsi

2015-01-05 Thread Maxime Ripard 
Hi,

On Mon, Dec 22, 2014 at 02:46:12PM +0100, Hans de Goede wrote:
 On 21-12-14 23:39, Maxime Ripard wrote:
 On Sat, Dec 20, 2014 at 11:24:55AM +0100, Hans de Goede wrote:
 Hi,
 
 On 19-12-14 19:34, Maxime Ripard wrote:
 On Wed, Dec 17, 2014 at 06:18:23PM +0100, Hans de Goede wrote:
 Add a dtsi file for A31s based boards.
 
 Since the  A31s is the same die as the A31 in a different package, this 
 dtsi
 simply includes sun6i-a31.dtsi and then overrides the pinctrl compatible 
 to
 reflect the different package, everything else is identical.
 
 Signed-off-by: Hans de Goede hdego...@redhat.com
 ---
 Changes in v2:
 -include sun6i-a31.dtsi and override the pinctrl compatible, rather then
   copying everything
 ---
   arch/arm/boot/dts/sun6i-a31s.dtsi | 62 
  +++
   1 file changed, 62 insertions(+)
   create mode 100644 arch/arm/boot/dts/sun6i-a31s.dtsi
 
 diff --git a/arch/arm/boot/dts/sun6i-a31s.dtsi 
 b/arch/arm/boot/dts/sun6i-a31s.dtsi
 new file mode 100644
 index 000..d0bd2b9
 --- /dev/null
 +++ b/arch/arm/boot/dts/sun6i-a31s.dtsi
 @@ -0,0 +1,62 @@
 +/*
 + * Copyright 2014 Hans de Goede hdego...@redhat.com
 + *
 + * This file is dual-licensed: you can use it either under the terms
 + * of the GPL or the X11 license, at your option. Note that this dual
 + * licensing only applies to this file, and not this project as a
 + * whole.
 + *
 + *  a) This library 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 library 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.
 + *
 + * You should have received a copy of the GNU General Public
 + * License along with this library; if not, write to the Free
 + * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
 + * MA 02110-1301 USA
 + *
 + * Or, alternatively,
 + *
 + *  b) Permission is hereby granted, free of charge, to any person
 + * obtaining a copy of this software and associated documentation
 + * files (the Software), to deal in the Software without
 + * restriction, including without limitation the rights to use,
 + * copy, modify, merge, publish, distribute, sublicense, and/or
 + * sell copies of the Software, and to permit persons to whom the
 + * Software is furnished to do so, subject to the following
 + * conditions:
 + *
 + * The above copyright notice and this permission notice shall be
 + * included in all copies or substantial portions of the Software.
 + *
 + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
 + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
 + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
 + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
 + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
 + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
 + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
 + * OTHER DEALINGS IN THE SOFTWARE.
 + */
 +
 +/*
 + * The A31s is the same die as the A31 in a different package, this is
 + * reflected by it having different pinctrl compatible everything else is
 + * identical.
 + */
 +
 +/include/ sun6i-a31.dtsi
 +
 +/ {
 + soc@01c0 {
 + pio: pinctrl@01c20800 {
 + compatible = allwinner,sun6i-a31s-pinctrl;
 + };
 + };
 +};
 
 Given your previous changes, you should also update the enable-method.
 
 I've not added a new compatible for the enable-method, given that
 this is the exact same die, so the 2 are 100?% compatible, just like you
 insisted that allwinner,sun4i-a10-mod0-clk should be used for the ir-clk
 since it was 100% compatible to that I believe that the enable method
 should use the existing compatible and not invent a new one for something
 which is 100% compatible.
 
 Yeah, you have a point and I agree, but your patch 3 does add a
 CPU_METHOD_OF_DECLARE for the A31s.
 
 Ah right, it does, my bad.
 
 Since I was going to push the branch now that 3.19-rc1 is out, do you
 want me to edit your patch before doing so?
 
 Yes, please drop the addition of the extra CPU_METHOD_OF_DECLARE, or let
 me know if you want a new version instead.

I just modified it, and pushed it, no need to resend it.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [PATCH 1/2] V4L: remove clock name from v4l2_clk API

2015-01-05 Thread Josh Wu 

Hi, Guennadi

On 1/2/2015 7:48 PM, Guennadi Liakhovetski wrote:

All uses of the v4l2_clk API so far only register one clock with a fixed
name. This allows us to get rid of it, which also will make CCF and DT
integration easier.
This patch not register a v4l2_clk with name: mclk. So this will break 
all the i2c sensors that used the v4l2 clock mclk.

To make those drivers work, we need change all lines from:
   v4l2_clk_get(client-dev, mclk);
to:
   v4l2_clk_get(client-dev, NULL);

Am I understanding correctly?

if yes, I'd like to define a SOC_CAMERA_HOST_CLK_ID in soc_camera.h, and 
all code will use:

v4l2_clk_get(client-dev, SOC_CAMERA_HOST_CLK_ID);



Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
  drivers/media/platform/soc_camera/soc_camera.c |  6 +++---
  drivers/media/usb/em28xx/em28xx-camera.c   |  2 +-
  drivers/media/v4l2-core/v4l2-clk.c | 24 +++-
  include/media/v4l2-clk.h   |  7 +++
  4 files changed, 18 insertions(+), 21 deletions(-)

diff --git a/drivers/media/platform/soc_camera/soc_camera.c 
b/drivers/media/platform/soc_camera/soc_camera.c
index f4be2a1..ce192b6 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -1380,7 +1380,7 @@ static int soc_camera_i2c_init(struct soc_camera_device 
*icd,
snprintf(clk_name, sizeof(clk_name), %d-%04x,
 shd-i2c_adapter_id, shd-board_info-addr);
  
-	icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name, mclk, icd);

+   icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name, icd);
if (IS_ERR(icd-clk)) {
ret = PTR_ERR(icd-clk);
goto eclkreg;
@@ -1561,7 +1561,7 @@ static int scan_async_group(struct soc_camera_host *ici,
snprintf(clk_name, sizeof(clk_name), %d-%04x,
 sasd-asd.match.i2c.adapter_id, sasd-asd.match.i2c.address);
  
-	icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name, mclk, icd);

+   icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name, icd);
if (IS_ERR(icd-clk)) {
ret = PTR_ERR(icd-clk);
goto eclkreg;
@@ -1666,7 +1666,7 @@ static int soc_of_bind(struct soc_camera_host *ici,
snprintf(clk_name, sizeof(clk_name), of-%s,
 of_node_full_name(remote));
  
-	icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name, mclk, icd);

+   icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name, icd);
if (IS_ERR(icd-clk)) {
ret = PTR_ERR(icd-clk);
goto eclkreg;
diff --git a/drivers/media/usb/em28xx/em28xx-camera.c 
b/drivers/media/usb/em28xx/em28xx-camera.c
index 7be661f..a4b22c2 100644
--- a/drivers/media/usb/em28xx/em28xx-camera.c
+++ b/drivers/media/usb/em28xx/em28xx-camera.c
@@ -330,7 +330,7 @@ int em28xx_init_camera(struct em28xx *dev)
  
  	v4l2_clk_name_i2c(clk_name, sizeof(clk_name),

  i2c_adapter_id(adap), client-addr);
-   v4l2-clk = v4l2_clk_register_fixed(clk_name, mclk, -EINVAL);
+   v4l2-clk = v4l2_clk_register_fixed(clk_name, -EINVAL);
if (IS_ERR(v4l2-clk))
return PTR_ERR(v4l2-clk);
  
diff --git a/drivers/media/v4l2-core/v4l2-clk.c b/drivers/media/v4l2-core/v4l2-clk.c

index e18cc04..c210906 100644
--- a/drivers/media/v4l2-core/v4l2-clk.c
+++ b/drivers/media/v4l2-core/v4l2-clk.c
@@ -31,7 +31,8 @@ static struct v4l2_clk *v4l2_clk_find(const char *dev_id, 
const char *id)
if (strcmp(dev_id, clk-dev_id))
continue;
  
-		if (!id || !clk-id || !strcmp(clk-id, id))

+   if ((!id  !clk-id) ||
+   (id  clk-id  !strcmp(clk-id, id)))
return clk;
}
  
@@ -127,8 +128,8 @@ void v4l2_clk_disable(struct v4l2_clk *clk)

mutex_lock(clk-lock);
  
  	enable = --clk-enable;

-   if (WARN(enable  0, Unbalanced %s() on %s:%s!\n, __func__,
-clk-dev_id, clk-id))
+   if (WARN(enable  0, Unbalanced %s() on %s!\n, __func__,
+clk-dev_id))
clk-enable++;
else if (!enable  clk-ops-disable)
clk-ops-disable(clk);
@@ -181,7 +182,7 @@ EXPORT_SYMBOL(v4l2_clk_set_rate);
  
  struct v4l2_clk *v4l2_clk_register(const struct v4l2_clk_ops *ops,

   const char *dev_id,
-  const char *id, void *priv)
+  void *priv)
  {
struct v4l2_clk *clk;
int ret;
@@ -193,9 +194,8 @@ struct v4l2_clk *v4l2_clk_register(const struct 
v4l2_clk_ops *ops,
if (!clk)
return ERR_PTR(-ENOMEM);
  
-	clk-id = kstrdup(id, GFP_KERNEL);

clk-dev_id = kstrdup(dev_id, GFP_KERNEL);
-   if ((id  !clk-id) || !clk-dev_id) {
+   if (!clk-dev_id) {
ret = -ENOMEM;
goto ealloc;
}
@@ -205,7 +205,7 @@ struct v4l2_clk

Re: [PATCH v2 2/2] V4L2: add CCF support to the v4l2_clk API

2015-01-05 Thread Josh Wu 

Hi, Guennadi

On 1/3/2015 4:18 AM, Guennadi Liakhovetski wrote:

 From aeaee56e04d023f3a019d2595ef5128015acdb06 Mon Sep 17 00:00:00 2001
From: Guennadi Liakhovetski g.liakhovet...@gmx.de
Date: Fri, 2 Jan 2015 12:26:41 +0100
Subject: [PATCH 2/2] V4L2: add CCF support to the v4l2_clk API

V4L2 clocks, e.g. used by camera sensors for their master clock, do not
have to be supplied by a different V4L2 driver, they can also be
supplied by an independent source. In this case the standart kernel
clock API should be used to handle such clocks. This patch adds support
for such cases.

Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---

Hi Laurent,
Thanks for the comment. The idea of allocating a new object for each get
operation seems a bit weird to me, and completely trusting the user is a
bit scary... :) But yes, it can work this way too, I think, and the user
can screw either way too, anyway. So, here comes a v2. Something like
this?

v2: don't add CCF-related clocks on the global list, just allocate a new
instance on each v4l2_clk_get()

  drivers/media/v4l2-core/v4l2-clk.c | 45 +++---
  include/media/v4l2-clk.h   |  2 ++
  2 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-clk.c 
b/drivers/media/v4l2-core/v4l2-clk.c
index c210906..f5d1688 100644
--- a/drivers/media/v4l2-core/v4l2-clk.c
+++ b/drivers/media/v4l2-core/v4l2-clk.c
@@ -9,6 +9,7 @@
   */
  
  #include linux/atomic.h

+#include linux/clk.h
  #include linux/device.h
  #include linux/errno.h
  #include linux/list.h
@@ -42,6 +43,18 @@ static struct v4l2_clk *v4l2_clk_find(const char *dev_id, 
const char *id)
  struct v4l2_clk *v4l2_clk_get(struct device *dev, const char *id)
  {
struct v4l2_clk *clk;
+   struct clk *ccf_clk = clk_get(dev, id);
We need to check whether the 'id' is NULL, otherwise there is no error 
reported if we use IS_ERR(ccf_clk).


Best Regards,
Josh Wu


+
+   if (!IS_ERR(ccf_clk)) {
+   clk = kzalloc(sizeof(struct v4l2_clk), GFP_KERNEL);
+   if (!clk) {
+   clk_put(ccf_clk);
+   return ERR_PTR(-ENOMEM);
+   }
+   clk-clk = ccf_clk;
+
+   return clk;
+   }
  
  	mutex_lock(clk_lock);

clk = v4l2_clk_find(dev_name(dev), id);
@@ -61,6 +74,12 @@ void v4l2_clk_put(struct v4l2_clk *clk)
if (IS_ERR(clk))
return;
  
+	if (clk-clk) {

+   clk_put(clk-clk);
+   kfree(clk);
+   return;
+   }
+
mutex_lock(clk_lock);
  
  	list_for_each_entry(tmp, clk_list, list)

@@ -98,8 +117,12 @@ static void v4l2_clk_unlock_driver(struct v4l2_clk *clk)
  
  int v4l2_clk_enable(struct v4l2_clk *clk)

  {
-   int ret = v4l2_clk_lock_driver(clk);
+   int ret;
  
+	if (clk-clk)

+   return clk_enable(clk-clk);
+
+   ret = v4l2_clk_lock_driver(clk);
if (ret  0)
return ret;
  
@@ -125,6 +148,9 @@ void v4l2_clk_disable(struct v4l2_clk *clk)

  {
int enable;
  
+	if (clk-clk)

+   return clk_disable(clk-clk);
+
mutex_lock(clk-lock);
  
  	enable = --clk-enable;

@@ -142,8 +168,12 @@ EXPORT_SYMBOL(v4l2_clk_disable);
  
  unsigned long v4l2_clk_get_rate(struct v4l2_clk *clk)

  {
-   int ret = v4l2_clk_lock_driver(clk);
+   int ret;
+
+   if (clk-clk)
+   return clk_get_rate(clk-clk);
  
+	ret = v4l2_clk_lock_driver(clk);

if (ret  0)
return ret;
  
@@ -162,7 +192,16 @@ EXPORT_SYMBOL(v4l2_clk_get_rate);
  
  int v4l2_clk_set_rate(struct v4l2_clk *clk, unsigned long rate)

  {
-   int ret = v4l2_clk_lock_driver(clk);
+   int ret;
+
+   if (clk-clk) {
+   long r = clk_round_rate(clk-clk, rate);
+   if (r  0)
+   return r;
+   return clk_set_rate(clk-clk, r);
+   }
+
+   ret = v4l2_clk_lock_driver(clk);
  
  	if (ret  0)

return ret;
diff --git a/include/media/v4l2-clk.h b/include/media/v4l2-clk.h
index 8f06967..4402b2d 100644
--- a/include/media/v4l2-clk.h
+++ b/include/media/v4l2-clk.h
@@ -22,6 +22,7 @@
  struct module;
  struct device;
  
+struct clk;

  struct v4l2_clk {
struct list_head list;
const struct v4l2_clk_ops *ops;
@@ -30,6 +31,7 @@ struct v4l2_clk {
int enable;
struct mutex lock; /* Protect the enable count */
atomic_t use_count;
+   struct clk *clk;
void *priv;
  };
  


--
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: [RFC/PATCH] dvb-core: add template code for i2c binding model

2015-01-05 Thread Akihiro TSUKADA 
Hi, thank you for the comment.
I understood the naming conventions you mentioned,
and I'll update them in the next version.

 diff --git a/drivers/media/dvb-core/dvb_i2c.c 
 b/drivers/media/dvb-core/dvb_i2c.c
 new file mode 100644
 index 000..4ea4e5e
 --- /dev/null
 +++ b/drivers/media/dvb-core/dvb_i2c.c

 +static struct i2c_client *
 +dvb_i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info *info,
 +   const unsigned short *probe_addrs)
 +{
 +struct i2c_client *cl;
 +
 +request_module(I2C_MODULE_PREFIX %s, info-type);
 +/* Create the i2c client */
 +if (info-addr == 0  probe_addrs)
 +cl = i2c_new_probed_device(adap, info, probe_addrs, NULL);
 +else
 +cl = i2c_new_device(adap, info);
 +if (!cl || !cl-dev.driver)
 +return NULL;
 +return cl;
 
 The best would be to also register the device with the media controller,
 if CONFIG_MEDIA_CONTROLLER is defined, just like v4l2_i2c_subdev_init()
 does.

I'll comment to your patch on this.

 I would also try to use similar names for the function calls to the ones
 that the v4l subsystem uses for subdevices.

So the name should be dvb_i2c_new_subdev()?
I am a bit worried that it would be rather confusing because
this func is different from v4l2_i2c_new_subdev() in that
it does not return struct dvb_frontend *, requires info.platform_data 
parameter,
and is a static/internal function.

One more thing that I'm wondering about is whether we should add 
fe-demod_i2c_bus
to support tuner devices on a (dedicated) i2c bus hosted on a demod device.
I guess that this structure is pretty common (to reduce noise),
and this removes i2c_adapter from out structure and
confines the usage of out structure to just device-specific ones.

--
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: [RFC/PATCH] dvb-core: add template code for i2c binding model

2015-01-05 Thread Akihiro TSUKADA 
 The only thing I noticed is that it is causing some warnings at
 dmesg about trying to create already created sysfs nodes, when the
 driver is removed/reinserted.
 
 Probably, the remove callback is called too soon or too late.

I don't have any warnings in syslog when reinserting earth-pt3 + tc90522,
but I'll look into it.

 -struct dvb_frontend *mb86a20s_attach(const struct mb86a20s_config *config,
 - struct i2c_adapter *i2c)
 +static int mb86a20s_probe(struct i2c_client *i2c,
 +   const struct i2c_device_id *id)
  {
 + struct dvb_frontend *fe;
   struct mb86a20s_state *state;
   u8  rev;
  
   dev_dbg(i2c-dev, %s called.\n, __func__);
  
 - /* allocate memory for the internal state */
 - state = kzalloc(sizeof(struct mb86a20s_state), GFP_KERNEL);
 - if (state == NULL) {
 - dev_err(i2c-dev,
 - %s: unable to allocate memory for state\n, __func__);
 - goto error;
 - }
 + fe = i2c_get_clientdata(i2c);
 + state = fe-demodulator_priv;
  
   /* setup the state */
 - state-config = config;
 + memcpy(state-config, i2c-dev.platform_data, sizeof(state-config));
   state-i2c = i2c;
  
   /* create dvb_frontend */
 - memcpy(state-frontend.ops, mb86a20s_ops,
 + memcpy(fe-ops, mb86a20s_ops,
   sizeof(struct dvb_frontend_ops));

btw,
we can go with mb86a20s_param = { .ops.fe_ops = mb86a20s_ops,} insead.

--
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

Re: [RFC/PATCH] dvb-core: add template code for i2c binding model

2015-01-05 Thread Mauro Carvalho Chehab 
Em Mon, 05 Jan 2015 21:14:42 +0900
Akihiro TSUKADA tsk...@gmail.com escreveu:

  The only thing I noticed is that it is causing some warnings at
  dmesg about trying to create already created sysfs nodes, when the
  driver is removed/reinserted.
  
  Probably, the remove callback is called too soon or too late.
 
 I don't have any warnings in syslog when reinserting earth-pt3 + tc90522,
 but I'll look into it.

This seems to be an already existing bug at cx231xx, as I'm also getting
those without those patches.

 
  -struct dvb_frontend *mb86a20s_attach(const struct mb86a20s_config *config,
  -   struct i2c_adapter *i2c)
  +static int mb86a20s_probe(struct i2c_client *i2c,
  + const struct i2c_device_id *id)
   {
  +   struct dvb_frontend *fe;
  struct mb86a20s_state *state;
  u8  rev;
   
  dev_dbg(i2c-dev, %s called.\n, __func__);
   
  -   /* allocate memory for the internal state */
  -   state = kzalloc(sizeof(struct mb86a20s_state), GFP_KERNEL);
  -   if (state == NULL) {
  -   dev_err(i2c-dev,
  -   %s: unable to allocate memory for state\n, __func__);
  -   goto error;
  -   }
  +   fe = i2c_get_clientdata(i2c);
  +   state = fe-demodulator_priv;
   
  /* setup the state */
  -   state-config = config;
  +   memcpy(state-config, i2c-dev.platform_data, sizeof(state-config));
  state-i2c = i2c;
   
  /* create dvb_frontend */
  -   memcpy(state-frontend.ops, mb86a20s_ops,
  +   memcpy(fe-ops, mb86a20s_ops,
  sizeof(struct dvb_frontend_ops));
 
 btw,
 we can go with mb86a20s_param = { .ops.fe_ops = mb86a20s_ops,} insead.
 
 --
 regards,
 akihiro


-- 

Cheers,
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

[PULL patches for 3.20]: New gspca touptek driver and sunxi-cir driver improvments

2015-01-05 Thread Hans de Goede 

Hi Mauro,

Please pull from my tree for a new gspca touptek driver and some
sunxi-cir driver improvments.

The following changes since commit 99f3cd52aee21091ce62442285a68873e3be833f:

  [media] vb2-vmalloc: Protect DMA-specific code by #ifdef CONFIG_HAS_DMA 
(2014-12-23 16:28:09 -0200)

are available in the git repository at:

  git://linuxtv.org/hgoede/gspca.git media-for_v3.20

for you to fetch changes up to bb729335790614dab96fab6dbed979a711955bdd:

  rc: sunxi-cir: Add support for the larger fifo found on sun5i and sun6i 
(2015-01-05 13:43:33 +0100)


Hans de Goede (2):
  rc: sunxi-cir: Add support for an optional reset controller
  rc: sunxi-cir: Add support for the larger fifo found on sun5i and sun6i

John McMaster (1):
  gspca_touptek: Add support for ToupTek UCMOS series USB cameras

 .../devicetree/bindings/media/sunxi-ir.txt |   4 +-
 drivers/media/rc/sunxi-cir.c   |  46 +-
 drivers/media/usb/gspca/Kconfig|  10 +
 drivers/media/usb/gspca/Makefile   |   2 +
 drivers/media/usb/gspca/touptek.c  | 732 +
 5 files changed, 782 insertions(+), 12 deletions(-)
 create mode 100644 drivers/media/usb/gspca/touptek.c

Thanks  Regards,

Hans
--
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/5] mb86a20s: convert it to I2C binding model

2015-01-05 Thread Akihiro TSUKADA 
moikka,

On 2015年01月02日 06:30, Antti Palosaari wrote:
 I am on holiday trip now. But generally speaking I would like to separate all 
 drivers from the interfaces. That means for example I2C tuner driver is just 
 a I2C driver and nothing more - no relations to DVB nor V4L API. That is 
 something I said many times earlier too, but for my taste drivers should be 
 agnostics to APIs.

I can't yet fully understand what API agnostic driver means,
but if it is like the implementation of the current i2c tuner/demod drivers,
each adapter drivers must (re-)implement common codes like module 
loading/ref-counting
and demod/tuner drivers must implement dvb-core related initializations on 
their own.
In addition, they may take different ways in how the data like fe, config 
data and
other device specific output parameters are passed around
between adapters and demod/tuners.

I thought it would be better to intergrate those common codes into dvb_core
to ease maintainance and let each driver concentrate on driver-specific things.

And don't the current i2c tuner drivers already depend on dvb_core practically
by implementing dvb_tuner_ops functions and
filling in their pointers into fe-ops.tuner_ops?

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

Re: [PATCH] [media] gspca_touptek: Add support for ToupTek UCMOS series USB cameras

2015-01-05 Thread Hans de Goede 

Hi John,

On 01-12-14 03:27, John McMaster wrote:

Adds support for AmScope MU800 / ToupTek UCMOS08000KPB USB microscope camera.

Signed-off-by: John McMaster johndmcmas...@gmail.com


Thanks, I've added this driver to my gspca tree, and asked Mauro to
queue it up for 3.20.

Regards,

Hans


---
  drivers/media/usb/gspca/Kconfig   |   10 +
  drivers/media/usb/gspca/Makefile  |2 +
  drivers/media/usb/gspca/touptek.c |  729 +
  3 files changed, 741 insertions(+)
  create mode 100644 drivers/media/usb/gspca/touptek.c

diff --git a/drivers/media/usb/gspca/Kconfig b/drivers/media/usb/gspca/Kconfig
index eed10d7..60af3b1 100644
--- a/drivers/media/usb/gspca/Kconfig
+++ b/drivers/media/usb/gspca/Kconfig
@@ -395,6 +395,16 @@ config USB_GSPCA_TOPRO
  To compile this driver as a module, choose M here: the
  module will be called gspca_topro.

+config USB_GSPCA_TOUPTEK
+   tristate Touptek USB Camera Driver
+   depends on VIDEO_V4L2  USB_GSPCA
+   help
+ Say Y here if you want support for cameras based on the ToupTek UCMOS
+ / AmScope MU series camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called gspca_touptek.
+
  config USB_GSPCA_TV8532
tristate TV8532 USB Camera Driver
depends on VIDEO_V4L2  USB_GSPCA
diff --git a/drivers/media/usb/gspca/Makefile b/drivers/media/usb/gspca/Makefile
index f46975e..9f5ccec 100644
--- a/drivers/media/usb/gspca/Makefile
+++ b/drivers/media/usb/gspca/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_USB_GSPCA_STK1135)  += gspca_stk1135.o
  obj-$(CONFIG_USB_GSPCA_STV0680)  += gspca_stv0680.o
  obj-$(CONFIG_USB_GSPCA_T613) += gspca_t613.o
  obj-$(CONFIG_USB_GSPCA_TOPRO)+= gspca_topro.o
+obj-$(CONFIG_USB_GSPCA_TOUPTEK)  += gspca_touptek.o
  obj-$(CONFIG_USB_GSPCA_TV8532)   += gspca_tv8532.o
  obj-$(CONFIG_USB_GSPCA_VC032X)   += gspca_vc032x.o
  obj-$(CONFIG_USB_GSPCA_VICAM)+= gspca_vicam.o
@@ -86,6 +87,7 @@ gspca_stv0680-objs  := stv0680.o
  gspca_sunplus-objs  := sunplus.o
  gspca_t613-objs := t613.o
  gspca_topro-objs:= topro.o
+gspca_touptek-objs  := touptek.o
  gspca_tv8532-objs   := tv8532.o
  gspca_vc032x-objs   := vc032x.o
  gspca_vicam-objs:= vicam.o
diff --git a/drivers/media/usb/gspca/touptek.c 
b/drivers/media/usb/gspca/touptek.c
new file mode 100644
index 000..2fd876c
--- /dev/null
+++ b/drivers/media/usb/gspca/touptek.c
@@ -0,0 +1,729 @@
+/*
+ * ToupTek UCMOS / AmScope MU series camera driver
+ * TODO: contrast with ScopeTek / AmScope MDC cameras
+ *
+ * Copyright (C) 2012-2014 John McMaster johndmcmas...@gmail.com
+ *
+ * Special thanks to Bushing for helping with the decrypt algorithm and
+ * Sean O'Sullivan / the Rensselaer Center for Open Source
+ * Software (RCOS) for helping me learn kernel development
+ *
+ * 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
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include gspca.h
+
+#define MODULE_NAME touptek
+
+MODULE_AUTHOR(John McMaster);
+MODULE_DESCRIPTION(ToupTek UCMOS / Amscope MU microscope camera driver);
+MODULE_LICENSE(GPL);
+
+/*
+Exposure reg is linear with exposure time
+Exposure (sec), E (reg)
+0.000400, 0x0002
+0.001000, 0x0005
+0.005000, 0x0019
+0.02, 0x0064
+0.08, 0x0190
+0.40, 0x07D0
+1.00, 0x1388
+2.00, 0x2710
+
+Three gain stages
+0x1000: master channel enable bit
+0x007F: low gain bits
+0x0080: medium gain bit
+0x0100: high gain bit
+gain = enable * (1 + regH) * (1 + regM) * z * regL
+
+Gain implementation
+Want to do something similar to mt9v011.c's set_balance
+
+Gain does not vary with resolution (checked 640x480 vs 1600x1200)
+
+Constant derivation:
+
+Raw data:
+Gain,   GTOP,   B,   R,  GBOT
+1.00,   0x105C, 0x1068, 0x10C8, 0x105C
+1.20,   0x106E, 0x107E, 0x10D6, 0x106E
+1.40,   0x10C0, 0x10CA, 0x10E5, 0x10C0
+1.60,   0x10C9, 0x10D4, 0x10F3, 0x10C9
+1.80,   0x10D2, 0x10DE, 0x11C1, 0x10D2
+2.00,   0x10DC, 0x10E9, 0x11C8, 0x10DC
+2.20,   0x10E5, 0x10F3, 0x11CF, 0x10E5
+2.40,   0x10EE, 0x10FE, 0x11D7, 0x10EE
+2.60,   0x10F7, 0x11C4, 0x11DE, 0x10F7
+2.80,   0x11C0, 0x11CA, 0x11E5, 0x11C0
+3.00,   0x11C5, 0x11CF, 0x11ED, 0x11C5
+
+zR = 0.0069605943152454778
+   about 3/431 = 0.0069605568445475635
+zB = 0.0095695970695970703
+   about 6/627 = 0.0095693779904306216
+zG = 0.010889328063241107
+

Re: [PATCH 4/5] dvb core: add media controller support for the demod

2015-01-05 Thread Akihiro TSUKADA 
On 2015年01月02日 00:51, Mauro Carvalho Chehab wrote:
  /*
 @@ -416,6 +418,11 @@ struct dvb_frontend {
   struct dvb_frontend_ops ops;
   struct dvb_adapter *dvb;
   struct i2c_client *fe_cl;
 +#if defined(CONFIG_MEDIA_CONTROLLER)
 + struct media_device *mdev;
 + struct media_entity demod_entity;
 +#endif
 +

I understood that this patch was invalidated by the updated patch series:
dvb core: add basic suuport for the media controller,
and now the demod_entity is registered in dvbdev.c::dvb_register_device()
via dvb_frontend_register(). Is that right?
And if so,
Shouldn't only the (tuner) subdevices be registered separately
in dvb_i2c_attach_tuner(), instead of dvb_i2c_attach_fe()?
(and it would be simpler if mdev can be accessed
like dvb_fe_get_mdev() {return fepriv-dvbdev-mdev;},
instead of having a cached value in dvb_frontend.)

sorry if I'm totally wrong,
I don't have an experience with media controller API.

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] [media] [pvrusb2]: remove dead retry cmd code

2015-01-05 Thread Haim Daniel 
In case a command is timed out, current flow sets the retry_flag
and does nothing.

Signed-off-by: Haim Daniel haim.dan...@gmail.com
---
 drivers/media/usb/pvrusb2/pvrusb2-encoder.c | 15 +--
 1 file changed, 1 insertion(+), 14 deletions(-)

diff --git a/drivers/media/usb/pvrusb2/pvrusb2-encoder.c 
b/drivers/media/usb/pvrusb2/pvrusb2-encoder.c
index f7702ae..02028aa 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-encoder.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-encoder.c
@@ -145,8 +145,6 @@ static int pvr2_encoder_cmd(void *ctxt,
u32 *argp)
 {
unsigned int poll_count;
-   unsigned int try_count = 0;
-   int retry_flag;
int ret = 0;
unsigned int idx;
/* These sizes look to be limited by the FX2 firmware implementation */
@@ -213,8 +211,6 @@ static int pvr2_encoder_cmd(void *ctxt,
break;
}
 
-   retry_flag = 0;
-   try_count++;
ret = 0;
wrData[0] = 0;
wrData[1] = cmd;
@@ -245,11 +241,9 @@ static int pvr2_encoder_cmd(void *ctxt,
}
if (rdData[0]  (poll_count  1000)) continue;
if (!rdData[0]) {
-   retry_flag = !0;
pvr2_trace(
PVR2_TRACE_ERROR_LEGS,
-   Encoder timed out waiting for us
-   ; arranging to retry);
+   Encoder timed out waiting for us);
} else {
pvr2_trace(
PVR2_TRACE_ERROR_LEGS,
@@ -269,13 +263,6 @@ static int pvr2_encoder_cmd(void *ctxt,
ret = -EBUSY;
break;
}
-   if (retry_flag) {
-   if (try_count  20) continue;
-   pvr2_trace(
-   PVR2_TRACE_ERROR_LEGS,
-   Too many retries...);
-   ret = -EBUSY;
-   }
if (ret) {
del_timer_sync(hdw-encoder_run_timer);
hdw-state_encoder_ok = 0;
-- 
1.9.3

--
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

[yavta PATCH 2/2] Fix data offset config option parsing

2015-01-05 Thread Sakari Ailus 
The option itself was considered correctly, but a small but crucial break
statement was missing. --data-offset option does not take an argument
either.

Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com
---
 yavta.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/yavta.c b/yavta.c
index 3bec0be..7c21db2 100644
--- a/yavta.c
+++ b/yavta.c
@@ -1770,7 +1770,7 @@ static struct option opts[] = {
{buffer-type, 1, 0, 'B'},
{capture, 2, 0, 'c'},
{check-overrun, 0, 0, 'C'},
-   {data-prefix, 1, 0, OPT_DATA_PREFIX},
+   {data-prefix, 0, 0, OPT_DATA_PREFIX},
{delay, 1, 0, 'd'},
{enum-formats, 0, 0, OPT_ENUM_FORMATS},
{enum-inputs, 0, 0, OPT_ENUM_INPUTS},
@@ -2034,6 +2034,7 @@ int main(int argc, char *argv[])
break;
case OPT_DATA_PREFIX:
dev.write_data_prefix = true;
+   break;
default:
printf(Invalid option -%c\n, c);
printf(Run %s -h for help.\n, argv[0]);
-- 
2.1.0.231.g7484e3b

--
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

[yavta PATCH 1/2] Rename buffer prefix as data prefix

2015-01-05 Thread Sakari Ailus 
Data prefix is a much better name for this (think of data_offset, for
instance).

Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com
---
 yavta.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/yavta.c b/yavta.c
index 0055c7d..3bec0be 100644
--- a/yavta.c
+++ b/yavta.c
@@ -81,7 +81,7 @@ struct device
void *pattern[VIDEO_MAX_PLANES];
unsigned int patternsize[VIDEO_MAX_PLANES];
 
-   bool write_buffer_prefix;
+   bool write_data_prefix;
 };
 
 static bool video_is_mplane(struct device *dev)
@@ -1556,7 +1556,7 @@ static void video_save_image(struct device *dev, struct 
v4l2_buffer *buf,
if (video_is_mplane(dev)) {
length = buf-m.planes[i].bytesused;
 
-   if (!dev-write_buffer_prefix) {
+   if (!dev-write_data_prefix) {
data += buf-m.planes[i].data_offset;
length -= buf-m.planes[i].data_offset;
}
@@ -1763,14 +1763,14 @@ static void usage(const char *argv0)
 #define OPT_BUFFER_SIZE268
 #define OPT_PREMULTIPLIED  269
 #define OPT_QUEUE_LATE 270
-#define OPT_BUFFER_PREFIX  271
+#define OPT_DATA_PREFIX271
 
 static struct option opts[] = {
{buffer-size, 1, 0, OPT_BUFFER_SIZE},
{buffer-type, 1, 0, 'B'},
-   {buffer-prefix, 1, 0, OPT_BUFFER_PREFIX},
{capture, 2, 0, 'c'},
{check-overrun, 0, 0, 'C'},
+   {data-prefix, 1, 0, OPT_DATA_PREFIX},
{delay, 1, 0, 'd'},
{enum-formats, 0, 0, OPT_ENUM_FORMATS},
{enum-inputs, 0, 0, OPT_ENUM_INPUTS},
@@ -2032,8 +2032,8 @@ int main(int argc, char *argv[])
case OPT_USERPTR_OFFSET:
userptr_offset = atoi(optarg);
break;
-   case OPT_BUFFER_PREFIX:
-   dev.write_buffer_prefix = true;
+   case OPT_DATA_PREFIX:
+   dev.write_data_prefix = true;
default:
printf(Invalid option -%c\n, c);
printf(Run %s -h for help.\n, argv[0]);
-- 
2.1.0.231.g7484e3b

--
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

[yavta PATCH 0/2] Data prefix writing fixes

2015-01-05 Thread Sakari Ailus 
Hi Laurent,

Just a small fix (and a better name) for the --buffer-prefix option
implementation. The original patch didn't quite work as intended.

-- 
Kind regards,
Sakari

--
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: Baytrail camera csi / isp support status ?

2015-01-05 Thread Bastien Nocera 
Hey,

On Fri, 2014-12-12 at 12:07 +0100, Hans de Goede wrote:
 Hi All,
 
 A college of mine has a baytrail bases tablet:
 
 http://www.onda-tablet.com/onda-v975w-quad-core-win-8-tablet-9-7-inch-retina-screen-ram-2gb-wifi-32gb.html
 
 And he is trying to get Linux to run on it, he has things mostly
 working, but he would also like to get the cameras to work.
 
 I've found this:
 
 http://sourceforge.net/projects/e3845mipi/files/
 
 Which is some not so pretty code, with the usual problems of using
 custom ioctls to pass info from the statistics block of the isp
 to userspace and then let some userspace thingie (blob?) handle it.
 
 So I was wondering if anyone is working on proper support
 (targeting upstream) for this ? It would be nice if we could at least
 get the csi bits going, using the sensors or software auto-whitebal, etc.
 for now.

As I mentioned to Hans in private, I would be ready to provide the
hardware for somebody with a track record to keep, to allow testing and
hopefully maintaining that code longer term.

I would expect that this sort of hardware is already quite common
amongst Windows 8 tablets so it would be very helpful to have working
out-of-the-box on a stock Linux.

Cheers

--
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

2015-01-05 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:   Tue Jan  6 04:00:11 CET 2015
git branch: test
git hash:   99f3cd52aee21091ce62442285a68873e3be833f
gcc version:i686-linux-gcc (GCC) 4.9.1
sparse version: v0.5.0-41-g6c2d743
smatch version: 0.4.1-3153-g7d56ab3
host hardware:  x86_64
host os:3.18.0-1.slh.1-amd64

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-omap1: OK
linux-git-arm-pxa: OK
linux-git-blackfin: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.32.27-i686: ERRORS
linux-2.6.33.7-i686: ERRORS
linux-2.6.34.7-i686: ERRORS
linux-2.6.35.9-i686: ERRORS
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-i686: ERRORS
linux-3.17-i686: ERRORS
linux-3.18-i686: ERRORS
linux-2.6.32.27-x86_64: ERRORS
linux-2.6.33.7-x86_64: ERRORS
linux-2.6.34.7-x86_64: ERRORS
linux-2.6.35.9-x86_64: ERRORS
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-x86_64: ERRORS
linux-3.17-x86_64: ERRORS
linux-3.18-x86_64: ERRORS
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: ERRORS

Detailed results are available here:

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

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.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 4/5] dvb core: add media controller support for the demod

2015-01-05 Thread Mauro Carvalho Chehab 
Em Mon, 05 Jan 2015 23:36:00 +0900
Akihiro TSUKADA tsk...@gmail.com escreveu:

 On 2015年01月02日 00:51, Mauro Carvalho Chehab wrote:
   /*
  @@ -416,6 +418,11 @@ struct dvb_frontend {
  struct dvb_frontend_ops ops;
  struct dvb_adapter *dvb;
  struct i2c_client *fe_cl;
  +#if defined(CONFIG_MEDIA_CONTROLLER)
  +   struct media_device *mdev;
  +   struct media_entity demod_entity;
  +#endif
  +
 
 I understood that this patch was invalidated by the updated patch series:
 dvb core: add basic suuport for the media controller,
 and now the demod_entity is registered in dvbdev.c::dvb_register_device()
 via dvb_frontend_register(). Is that right?

Yes. 

 And if so,
 Shouldn't only the (tuner) subdevices be registered separately
 in dvb_i2c_attach_tuner(), instead of dvb_i2c_attach_fe()?

No, it seems better to let dmxdev to register. That means that even
the non-converted I2C drivers, plus the non-I2C drivers may benefit
from the Media controller as well.

 (and it would be simpler if mdev can be accessed
 like dvb_fe_get_mdev() {return fepriv-dvbdev-mdev;},
 instead of having a cached value in dvb_frontend.)

Yeah, we could map this way, but that would require to add an extra
parameter to the fe register function, with has already too much
parameters. So, as it already uses an struct to pass parameters into
it, I decided to just re-use it.

 sorry if I'm totally wrong,
 I don't have an experience with media controller API.
 
 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


-- 

Cheers,
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/5] mb86a20s: convert it to I2C binding model

2015-01-05 Thread Mauro Carvalho Chehab 
Em Thu, 01 Jan 2015 21:30:36 +
Antti Palosaari cr...@iki.fi escreveu:

 I am on holiday trip now. But generally speaking I would like to separate all 
 drivers from the interfaces. That means for example I2C tuner driver is just 
 a I2C driver and nothing more - no relations to DVB nor V4L API.

That would never work, as the tuner driver needs to include the DVB
and v4l headers, in order to implement the proper ops and to recognize
the cache struct, etc.

 That is something I said many times earlier too, but for my taste
 drivers should be agnostics to APIs.

The big issue right now is that each patch converting to the new I2C
model adds extra complexity to the drivers, as it doesn't use any
helper function to do the binding, but just replicate several lines
of code everywhere, as I already pointed.

I agree with the concept that whatever solution done should be agnostic
if the caller module is V4L, DVB or some other driver, but we need some
helper functions somewhere to do the bindings, in a way that we can easily
convert all drivers to it, via some scripts.

It is a nightmare right now, as each driver does something that can be
different than the others.

Regards,
Mauro

 Antti
 On 1 Jan 2015 15:51, Mauro Carvalho Chehab mche...@osg.samsung.com wrote:
 
  Instead of using I2C raw API, use the standard I2C binding API, 
  with the DVB core support for it. 
 
  Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com 
 
  diff --git a/drivers/media/dvb-frontends/mb86a20s.c 
  b/drivers/media/dvb-frontends/mb86a20s.c 
  index 8f54c39ca63f..8dd608be1edd 100644 
  --- a/drivers/media/dvb-frontends/mb86a20s.c 
  +++ b/drivers/media/dvb-frontends/mb86a20s.c 
  @@ -18,6 +18,7 @@ 
  #include asm/div64.h 
 
  #include dvb_frontend.h 
  +#include dvb_i2c.h 
  #include mb86a20s.h 
 
  #define NUM_LAYERS 3 
  @@ -35,12 +36,10 @@ static u8 mb86a20s_subchannel[] = { 
  }; 
 
  struct mb86a20s_state { 
  - struct i2c_adapter *i2c; 
  + struct i2c_client *i2c; 
  const struct mb86a20s_config *config; 
  u32 last_frequency; 
 
  - struct dvb_frontend frontend; 
  - 
  u32 if_freq; 
  enum mb86a20s_bandwidth bw; 
  bool inversion; 
  @@ -234,7 +233,7 @@ static int mb86a20s_i2c_writereg(struct mb86a20s_state 
  *state, 
  }; 
  int rc; 
 
  - rc = i2c_transfer(state-i2c, msg, 1); 
  + rc = i2c_transfer(state-i2c-adapter, msg, 1); 
  if (rc != 1) { 
  dev_err(state-i2c-dev, 
  %s: writereg error (rc == %i, reg == 0x%02x, data == 0x%02x)\n, 
  @@ -269,7 +268,7 @@ static int mb86a20s_i2c_readreg(struct mb86a20s_state 
  *state, 
  { .addr = i2c_addr, .flags = I2C_M_RD, .buf = val, .len = 1 } 
  }; 
 
  - rc = i2c_transfer(state-i2c, msg, 2); 
  + rc = i2c_transfer(state-i2c-adapter, msg, 2); 
 
  if (rc != 2) { 
  dev_err(state-i2c-dev, %s: reg=0x%x (error=%d)\n, 
  @@ -281,11 +280,11 @@ static int mb86a20s_i2c_readreg(struct mb86a20s_state 
  *state, 
  } 
 
  #define mb86a20s_readreg(state, reg) \ 
  - mb86a20s_i2c_readreg(state, state-config-demod_address, reg) 
  + mb86a20s_i2c_readreg(state, state-i2c-addr, reg) 
  #define mb86a20s_writereg(state, reg, val) \ 
  - mb86a20s_i2c_writereg(state, state-config-demod_address, reg, val) 
  + mb86a20s_i2c_writereg(state, state-i2c-addr, reg, val) 
  #define mb86a20s_writeregdata(state, regdata) \ 
  - mb86a20s_i2c_writeregdata(state, state-config-demod_address, \ 
  + mb86a20s_i2c_writeregdata(state, state-i2c-addr, \ 
  regdata, ARRAY_SIZE(regdata)) 
 
  /* 
  @@ -2058,41 +2057,34 @@ static int mb86a20s_tune(struct dvb_frontend *fe, 
  return rc; 
  } 
 
  -static void mb86a20s_release(struct dvb_frontend *fe) 
  +static int mb86a20s_remove(struct i2c_client *i2c) 
  { 
  - struct mb86a20s_state *state = fe-demodulator_priv; 
  + dev_dbg(i2c-dev, %s called.\n, __func__); 
 
  - dev_dbg(state-i2c-dev, %s called.\n, __func__); 
  - 
  - kfree(state); 
  + return 0; 
  } 
 
  static struct dvb_frontend_ops mb86a20s_ops; 
 
  -struct dvb_frontend *mb86a20s_attach(const struct mb86a20s_config *config, 
  -     struct i2c_adapter *i2c) 
  +static int mb86a20s_probe(struct i2c_client *i2c, 
  +   const struct i2c_device_id *id) 
  { 
  + struct dvb_frontend *fe; 
  struct mb86a20s_state *state; 
  u8 rev; 
 
  dev_dbg(i2c-dev, %s called.\n, __func__); 
 
  - /* allocate memory for the internal state */ 
  - state = kzalloc(sizeof(struct mb86a20s_state), GFP_KERNEL); 
  - if (state == NULL) { 
  - dev_err(i2c-dev, 
  - %s: unable to allocate memory for state\n, __func__); 
  - goto error; 
  - } 
  + fe = i2c_get_clientdata(i2c); 
  + state = fe-demodulator_priv; 
 
  /* setup the state */ 
  - state-config = config; 
  + memcpy(state-config, i2c-dev.platform_data, sizeof(state-config)); 
  state-i2c = i2c; 
 
  /* create dvb_frontend */ 
  - memcpy(state-frontend.ops, mb86a20s_ops, 
  + memcpy(fe-ops, mb86a20s_ops, 
  sizeof(struct dvb_frontend_ops)); 
  - state-frontend.demodulator_priv = state; 
 
  /* Check if it is a mb86a20s frontend */ 
  rev = mb86a20s_readreg(state,

Using CSI1 on i.MX6

2015-01-05 Thread Jean-Michel Hautbois 
Hi all,

First of all, happy new year :).
Next, I am trying to use the second CSI on i.MX6 (still based on media
tree and Steve's work, slightly modified ;-)).
I am using the following lines in order to configure my adv7604
correctly, and running it in free run mode in order to get something
reliable :
DEVICE=4
INPUT=0
SUBDEV=3
v4l2-ctl -d$DEVICE --set-edid=pad=0,edid=hdmi -i$INPUT
v4l2-ctl -d$DEVICE
--set-fmt-video=width=1280,height=720,pixelformat=YUYV,field=none,bytesperline=2560
v4l2-ctl -d$DEVICE --set-dv-bt-timings index=4
v4l2-dbg -d$DEVICE -c subdev$SUBDEV -s 0x03 0x80
v4l2-dbg -d$DEVICE -c subdev$SUBDEV -s 0x02 0x35


And then, I launch this simple line, which gets stuck :
v4l2-ctl -d$DEVICE --stream-mmap --stream-to /data/x.raw --stream-count=1

The exact same sequence on CSI0 is working fine.
I added the dynamic debug messages and here is the configuration (from
my point of view, it seems to be ok, but I may have miss a bit here or
there) :
[  131.963122] mx6-camera-encoder: Direct CSI - SMFC - MEM
[  131.968568] mx6-camera-encoder: CSI channel 1 on IPU 2
[  131.973856] imx-ipuv3 280.ipu: ipu_idmac_get 3
[  131.973880] mx6-camera-encoder: Preview is off
[  131.978380] imx-ipuv3 280.ipu: CSI_SENS_CONF = 0x0950
[  131.978410] imx-ipuv3 280.ipu: CSI_ACT_FRM_SIZE = 0x02CF04FF
[  131.987448] ipu_cpmem_set_image: resolution: 1280x720 stride: 2560
[  131.987467] ipu_ch_param_write_field 0 125 13
[  131.987482] ipu_ch_param_write_field 0 138 12
[  131.987495] ipu_ch_param_write_field 1 102 14
[  131.987507] ipu_ch_param_write_field 0 107 3
[  131.987520] ipu_ch_param_write_field 1 85 4
[  131.987531] ipu_ch_param_write_field 1 78 7
[  131.987544] ipu_ch_param_write_field 1 0 29
[  131.987554] ipu_ch_param_write_field 1 29 29
[  131.987568] ipu_ch_param_write_field 1 78 7
[  131.987591] ipu_ch_param_write_field 1 93 2
[  131.987997] mx6-camera-encoder: Enable CSI
[  131.992125] imx-ipuv3 280.ipu: ch 3 word 0 -  
 E0001800 000B3C9F
[  131.992146] imx-ipuv3 280.ipu: ch 3 word 1 - 0906 01214000
0103C000 00027FC0 
[  131.992159] ipu_ch_param_read_field 1 85 4
[  131.992173] imx-ipuv3 280.ipu: PFS 0x8,
[  131.992185] ipu_ch_param_read_field 0 107 3
[  131.992199] imx-ipuv3 280.ipu: BPP 0x3,
[  131.992209] ipu_ch_param_read_field 1 78 7
[  131.99] imx-ipuv3 280.ipu: NPB 0xf
[  131.992234] ipu_ch_param_read_field 0 125 13
[  131.992248] imx-ipuv3 280.ipu: FW 1279,
[  131.992259] ipu_ch_param_read_field 0 138 12
[  131.992271] imx-ipuv3 280.ipu: FH 719,
[  131.992283] ipu_ch_param_read_field 1 0 29
[  131.992296] imx-ipuv3 280.ipu: EBA0 0x4830
[  131.992307] ipu_ch_param_read_field 1 29 29
[  131.992320] imx-ipuv3 280.ipu: EBA1 0x4850
[  131.992331] ipu_ch_param_read_field 1 102 14
[  131.992344] imx-ipuv3 280.ipu: Stride 2559
[  131.992355] ipu_ch_param_read_field 0 113 1
[  131.992367] imx-ipuv3 280.ipu: scan_order 0
[  131.992378] ipu_ch_param_read_field 1 128 14
[  131.992390] imx-ipuv3 280.ipu: uv_stride 0
[  131.992401] ipu_ch_param_read_field 0 46 22
[  131.992413] imx-ipuv3 280.ipu: u_offset 0x0
[  131.992425] ipu_ch_param_read_field 0 68 22
[  131.992438] imx-ipuv3 280.ipu: v_offset 0x0
[  131.992448] ipu_ch_param_read_field 1 116 3
[  131.992460] imx-ipuv3 280.ipu: Width0 0+1,
[  131.992472] ipu_ch_param_read_field 1 119 3
[  131.992485] imx-ipuv3 280.ipu: Width1 0+1,
[  131.992496] ipu_ch_param_read_field 1 122 3
[  131.992509] imx-ipuv3 280.ipu: Width2 0+1,
[  131.992519] ipu_ch_param_read_field 1 125 3
[  131.992531] imx-ipuv3 280.ipu: Width3 0+1,
[  131.992543] ipu_ch_param_read_field 1 128 5
[  131.992556] imx-ipuv3 280.ipu: Offset0 0,
[  131.992566] ipu_ch_param_read_field 1 133 5
[  131.992579] imx-ipuv3 280.ipu: Offset1 0,
[  131.992589] ipu_ch_param_read_field 1 138 5
[  131.992602] imx-ipuv3 280.ipu: Offset2 0,
[  131.992613] ipu_ch_param_read_field 1 143 5
[  131.992626] imx-ipuv3 280.ipu: Offset3 0
[  131.992641] imx-ipuv3 280.ipu: IPU_CONF =0x0102
[  131.992654] imx-ipuv3 280.ipu: IDMAC_CONF =  0x002F
[  131.992667] imx-ipuv3 280.ipu: IDMAC_CHA_EN1 =   0x0008
[  131.992679] imx-ipuv3 280.ipu: IDMAC_CHA_EN2 =   0x
[  131.992691] imx-ipuv3 280.ipu: IDMAC_CHA_PRI1 =  0x0008
[  131.992704] imx-ipuv3 280.ipu: IDMAC_CHA_PRI2 =  0x
[  131.992718] imx-ipuv3 280.ipu: IDMAC_BAND_EN1 =  0x
[  131.992731] imx-ipuv3 280.ipu: IDMAC_BAND_EN2 =  0x
[  131.992743] imx-ipuv3 280.ipu: IPU_CHA_DB_MODE_SEL0 =0x0008
[  131.992756] imx-ipuv3 280.ipu: IPU_CHA_DB_MODE_SEL1 =0x
[  131.992769] imx-ipuv3 280.ipu: IPU_FS_PROC_FLOW1 =   0x
[  131.992782] imx-ipuv3 280.ipu: IPU_FS_PROC_FLOW2 =   0x
[  131.992794] imx-ipuv3 280.ipu: IPU_FS_PROC_FLOW3 =   0x
[  131.992806] imx-ipuv3 280.ipu:

Re: [linux-media] Patch notification: 2 patches updated

2015-01-05 Thread Fabio Estevam 
Hi Mauro,

On Tue, Dec 23, 2014 at 2:38 PM, Patchwork patchw...@linuxtv.org wrote:
 Hello,

 The following patches (submitted by you) have been updated in patchwork:

  * linux-media: [1/2] of: Add new compatibles for CODA bindings
  - http://patchwork.linuxtv.org/patch/27149/
  - for: Linux Media kernel patches
 was: New
 now: Not Applicable

  * linux-media: [2/2] of: Add named interrupts to CODA bindings
  - http://patchwork.linuxtv.org/patch/27150/
  - for: Linux Media kernel patches
 was: New
 now: Not Applicable

I thought the bindings documentation for the coda driver should go via
your tree.

If this is not correct, please advise as to which tree this should go in.

Thanks,

Fabio Estevam
--
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