[PATCH-Trivial 2/2] [media] s5p-fimc: Add missing braces around sizeof

2012-08-16 Thread Sachin Kamat 
Silences the following warning:
WARNING: sizeof *ctx should be sizeof(*ctx)

Signed-off-by: Sachin Kamat 
---
 drivers/media/platform/s5p-fimc/fimc-capture.c |2 +-
 drivers/media/platform/s5p-fimc/fimc-m2m.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/s5p-fimc/fimc-capture.c 
b/drivers/media/platform/s5p-fimc/fimc-capture.c
index 8e413dd..5283957 100644
--- a/drivers/media/platform/s5p-fimc/fimc-capture.c
+++ b/drivers/media/platform/s5p-fimc/fimc-capture.c
@@ -1593,7 +1593,7 @@ static int fimc_register_capture_device(struct fimc_dev 
*fimc,
struct vb2_queue *q;
int ret = -ENOMEM;

-   ctx = kzalloc(sizeof *ctx, GFP_KERNEL);
+   ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;

diff --git a/drivers/media/platform/s5p-fimc/fimc-m2m.c 
b/drivers/media/platform/s5p-fimc/fimc-m2m.c
index c587011..1b1e564 100644
--- a/drivers/media/platform/s5p-fimc/fimc-m2m.c
+++ b/drivers/media/platform/s5p-fimc/fimc-m2m.c
@@ -661,7 +661,7 @@ static int fimc_m2m_open(struct file *file)
if (fimc->vid_cap.refcnt > 0)
goto unlock;

-   ctx = kzalloc(sizeof *ctx, GFP_KERNEL);
+   ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
if (!ctx) {
ret = -ENOMEM;
goto unlock;
--
1.7.4.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-Trivial 1/2] [media] s5p-fimc: Replace asm/* headers with linux/*

2012-08-16 Thread Sachin Kamat 
Silences the following warning:
WARNING: Use #include  instead of 

Signed-off-by: Sachin Kamat 
---
 drivers/media/platform/s5p-fimc/fimc-core.h |2 +-
 drivers/media/platform/s5p-fimc/fimc-lite.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/s5p-fimc/fimc-core.h 
b/drivers/media/platform/s5p-fimc/fimc-core.h
index 808ccc6..e787f65 100644
--- a/drivers/media/platform/s5p-fimc/fimc-core.h
+++ b/drivers/media/platform/s5p-fimc/fimc-core.h
@@ -17,7 +17,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 

 #include 
 #include 
diff --git a/drivers/media/platform/s5p-fimc/fimc-lite.h 
b/drivers/media/platform/s5p-fimc/fimc-lite.h
index 44424ee..8dc3e9b 100644
--- a/drivers/media/platform/s5p-fimc/fimc-lite.h
+++ b/drivers/media/platform/s5p-fimc/fimc-lite.h
@@ -9,7 +9,7 @@
 #ifndef FIMC_LITE_H_
 #define FIMC_LITE_H_

-#include 
+#include 
 #include 
 #include 
 #include 
--
1.7.4.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-Trivial] [media] s5p-mfc: Add missing braces around sizeof

2012-08-16 Thread Sachin Kamat 
Silences the following warnings:
WARNING: sizeof *ctx should be sizeof(*ctx)
WARNING: sizeof *dev should be sizeof(*dev)

Signed-off-by: Sachin Kamat 
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index e3e616d..815affe 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -649,7 +649,7 @@ static int s5p_mfc_open(struct file *file)
return -ERESTARTSYS;
dev->num_inst++;/* It is guarded by mfc_mutex in vfd */
/* Allocate memory for context */
-   ctx = kzalloc(sizeof *ctx, GFP_KERNEL);
+   ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
if (!ctx) {
mfc_err("Not enough memory\n");
ret = -ENOMEM;
@@ -961,7 +961,7 @@ static int s5p_mfc_probe(struct platform_device *pdev)
int ret;

pr_debug("%s++\n", __func__);
-   dev = devm_kzalloc(&pdev->dev, sizeof *dev, GFP_KERNEL);
+   dev = devm_kzalloc(&pdev->dev, sizeof(*dev), GFP_KERNEL);
if (!dev) {
dev_err(&pdev->dev, "Not enough memory for MFC device\n");
return -ENOMEM;
--
1.7.4.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 1/1] driver-core: Shut up dev_dbg_reatelimited() without DEBUG

2012-08-16 Thread Hiroshi Doyu 
dev_dbg_reatelimited() without DEBUG printed "217078 callbacks
suppressed". This shouldn't print anything without DEBUG.

Signed-off-by: Hiroshi Doyu 
Reported-by: Antti Palosaari 
---
 include/linux/device.h |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/include/linux/device.h b/include/linux/device.h
index eb945e1..d4dc26e 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -962,9 +962,13 @@ do {   
\
dev_level_ratelimited(dev_notice, dev, fmt, ##__VA_ARGS__)
 #define dev_info_ratelimited(dev, fmt, ...)\
dev_level_ratelimited(dev_info, dev, fmt, ##__VA_ARGS__)
+#if defined(DEBUG)
 #define dev_dbg_ratelimited(dev, fmt, ...) \
dev_level_ratelimited(dev_dbg, dev, fmt, ##__VA_ARGS__)
-
+#else
+#define dev_dbg_ratelimited(dev, fmt, ...) \
+   no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
+#endif
 /*
  * Stupid hackaround for existing uses of non-printk uses dev_info
  *
-- 
1.7.5.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: noisy dev_dbg_ratelimited()

2012-08-16 Thread Hiroshi Doyu 
On Thu, 16 Aug 2012 22:29:43 +0200
Hin-Tak Leung  wrote:

> --- On Thu, 16/8/12, Antti Palosaari  wrote:
> 
> > Hello Hiroshi
> > 
> > On 08/16/2012 10:12 AM, Hiroshi Doyu wrote:
> > > Hi Antti,
> > >
> > > Antti Palosaari 
> > wrote @ Thu, 16 Aug 2012 03:11:56 +0200:
> > >
> > >> Hello Hiroshi,
> > >>
> > >> I see you have added dev_dbg_ratelimited()
> > recently, commit
> > >> 6ca045930338485a8cdef117e74372aa1678009d .
> > >>
> > >> However it seems to be noisy as expected similar
> > behavior than normal
> > >> dev_dbg() without a ratelimit.
> > >>
> > >> I looked ratelimit.c and there is:
> > >> printk(KERN_WARNING "%s: %d callbacks
> > suppressed\n", func, rs->missed);
> > >>
> > >> What it looks my eyes it will print those
> > "callbacks suppressed" always
> > >> because KERN_WARNING.
> > >
> > > Right. Can the following fix the problem?
> > 
> > No. That silences dev_dbg_reatelimited() totally.
> > dev_dbg() works as expected printing all the debugs. But
> > when I change 
> > it to dev_dbg_reatelimited() all printings are silenced.

I tested again locally. With DEBUG, it prints sometimes with inserting
"...28916 callbacks suppressed", without DEBUG, it doesn't print
anything. This looks the expected behavior. 

> That's probably correct - the patch looks a bit strange... I did not
> try the patch, but had a quick look at the file and noted that in
> include/linux/device.h, "info" (and possibly another level) are
> treated specially... just thought I should mention this.

I may not get your point correctly, but I think that the debug case is
different from the others(info, warn, err...etc) because, the others
always prints anything, but not debug depends on DEBUG. With DEBUG
it's expected to print at least something, and without DEBUG it's
expected to print nothing at all.
--
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: davinci: vpif: add check for NULL handler

2012-08-16 Thread Sekhar Nori 
On 8/17/2012 10:51 AM, Prabhakar Lad wrote:
> Hi Laurent,
> 
> Thanks for the review.
> 
> On Thursday 16 August 2012 08:43 PM, Laurent Pinchart wrote:
>> Hi Prabhakar,
>>
>> Thanks for the patch.
>>
>> On Thursday 16 August 2012 19:32:00 Prabhakar Lad wrote:
>>> From: Lad, Prabhakar 
>>>
>>> Signed-off-by: Lad, Prabhakar 
>>> Signed-off-by: Manjunath Hadli 
>>> Cc: Hans Verkuil 
>>> ---
>>>  drivers/media/video/davinci/vpif_capture.c |   12 +++-
>>>  drivers/media/video/davinci/vpif_display.c |   14 --
>>>  2 files changed, 15 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/media/video/davinci/vpif_capture.c
>>> b/drivers/media/video/davinci/vpif_capture.c index 266025e..a87b7a5 100644
>>> --- a/drivers/media/video/davinci/vpif_capture.c
>>> +++ b/drivers/media/video/davinci/vpif_capture.c
>>> @@ -311,12 +311,14 @@ static int vpif_start_streaming(struct vb2_queue *vq,
>>> unsigned int count) }
>>>
>>> /* configure 1 or 2 channel mode */
>>> -   ret = vpif_config_data->setup_input_channel_mode
>>> -   (vpif->std_info.ycmux_mode);
>>> +   if (vpif_config_data->setup_input_channel_mode) {
>>> +   ret = vpif_config_data->setup_input_channel_mode
>>> +   (vpif->std_info.ycmux_mode);
>>>
>>> -   if (ret < 0) {
>>> -   vpif_dbg(1, debug, "can't set vpif channel mode\n");
>>> -   return ret;
>>> +   if (ret < 0) {
>>> +   vpif_dbg(1, debug, "can't set vpif channel mode\n");
>>> +   return ret;
>>> +   }
>>
>> This change looks good to me. However, note that you will need to get rid of 
>> board code callbacks at some point to implement device tree support. It 
>> would 
>> be worth thinking about how to do so now.
>>
> Currently VPIF driver is only used by dm646x, and the handlers for this
> in the the board code are not null. This patch is intended for da850
> where this handlers will be null.
> 
>>> }
>>>
>>> /* Call vpif_set_params function to set the parameters and addresses */
>>> diff --git a/drivers/media/video/davinci/vpif_display.c
>>> b/drivers/media/video/davinci/vpif_display.c index e129c98..1e35f92 100644
>>> --- a/drivers/media/video/davinci/vpif_display.c
>>> +++ b/drivers/media/video/davinci/vpif_display.c
>>> @@ -280,12 +280,14 @@ static int vpif_start_streaming(struct vb2_queue *vq,
>>> unsigned int count) }
>>>
>>> /* clock settings */
>>> -   ret =
>>> -   vpif_config_data->set_clock(ch->vpifparams.std_info.ycmux_mode,
>>> -   ch->vpifparams.std_info.hd_sd);
>>> -   if (ret < 0) {
>>> -   vpif_err("can't set clock\n");
>>> -   return ret;
>>> +   if (vpif_config_data->set_clock) {
>>
>> Does the DaVinci platform use the common clock framework ? If so, a better 
>> fix 
>> for this would be to pass a clock name through platform data instead of 
>> using 
>> a callback function.
>>
> Currently DaVinci is not using the common clock framework.
> 
> Can you ACK this patch?

Yes, DaVinci has not migrated to common clock framework (yet). However,
even without that it should be possible to use clock API in driver code.
Using a callback to enable clocks or even passing the clock name from
platform data would be bypassing an existing framework. Clock name
should be IP specific, so it should be possible to use that in driver.

Thanks,
Sekhar
--
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: davinci: vpif: add check for NULL handler

2012-08-16 Thread Prabhakar Lad 
Hi Laurent,

Thanks for the review.

On Thursday 16 August 2012 08:43 PM, Laurent Pinchart wrote:
> Hi Prabhakar,
> 
> Thanks for the patch.
> 
> On Thursday 16 August 2012 19:32:00 Prabhakar Lad wrote:
>> From: Lad, Prabhakar 
>>
>> Signed-off-by: Lad, Prabhakar 
>> Signed-off-by: Manjunath Hadli 
>> Cc: Hans Verkuil 
>> ---
>>  drivers/media/video/davinci/vpif_capture.c |   12 +++-
>>  drivers/media/video/davinci/vpif_display.c |   14 --
>>  2 files changed, 15 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/media/video/davinci/vpif_capture.c
>> b/drivers/media/video/davinci/vpif_capture.c index 266025e..a87b7a5 100644
>> --- a/drivers/media/video/davinci/vpif_capture.c
>> +++ b/drivers/media/video/davinci/vpif_capture.c
>> @@ -311,12 +311,14 @@ static int vpif_start_streaming(struct vb2_queue *vq,
>> unsigned int count) }
>>
>>  /* configure 1 or 2 channel mode */
>> -ret = vpif_config_data->setup_input_channel_mode
>> -(vpif->std_info.ycmux_mode);
>> +if (vpif_config_data->setup_input_channel_mode) {
>> +ret = vpif_config_data->setup_input_channel_mode
>> +(vpif->std_info.ycmux_mode);
>>
>> -if (ret < 0) {
>> -vpif_dbg(1, debug, "can't set vpif channel mode\n");
>> -return ret;
>> +if (ret < 0) {
>> +vpif_dbg(1, debug, "can't set vpif channel mode\n");
>> +return ret;
>> +}
> 
> This change looks good to me. However, note that you will need to get rid of 
> board code callbacks at some point to implement device tree support. It would 
> be worth thinking about how to do so now.
> 
Currently VPIF driver is only used by dm646x, and the handlers for this
in the the board code are not null. This patch is intended for da850
where this handlers will be null.

>>  }
>>
>>  /* Call vpif_set_params function to set the parameters and addresses */
>> diff --git a/drivers/media/video/davinci/vpif_display.c
>> b/drivers/media/video/davinci/vpif_display.c index e129c98..1e35f92 100644
>> --- a/drivers/media/video/davinci/vpif_display.c
>> +++ b/drivers/media/video/davinci/vpif_display.c
>> @@ -280,12 +280,14 @@ static int vpif_start_streaming(struct vb2_queue *vq,
>> unsigned int count) }
>>
>>  /* clock settings */
>> -ret =
>> -vpif_config_data->set_clock(ch->vpifparams.std_info.ycmux_mode,
>> -ch->vpifparams.std_info.hd_sd);
>> -if (ret < 0) {
>> -vpif_err("can't set clock\n");
>> -return ret;
>> +if (vpif_config_data->set_clock) {
> 
> Does the DaVinci platform use the common clock framework ? If so, a better 
> fix 
> for this would be to pass a clock name through platform data instead of using 
> a callback function.
> 
Currently DaVinci is not using the common clock framework.

Can you ACK this patch?

Thanks and Regards,
--Prabhakar

>> +ret =
>> +vpif_config_data->set_clock(ch->vpifparams.std_info.ycmux_mode,
>> +ch->vpifparams.std_info.hd_sd);
>> +if (ret < 0) {
>> +vpif_err("can't set clock\n");
>> +return ret;
>> +}
>>  }
>>
>>  /* set the parameters and addresses */

--
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] smiapp: Remove unused function

2012-08-16 Thread Sachin Kamat 
smiapp_replace_limit_at() function is not called by the driver.
This was detected by sparse as:
drivers/media/i2c/smiapp/smiapp-quirk.c:64:5: warning:
symbol 'smiapp_replace_limit_at' was not declared. Should it be static?

Signed-off-by: Sachin Kamat 
---
 drivers/media/i2c/smiapp/smiapp-quirk.c |   20 
 1 files changed, 0 insertions(+), 20 deletions(-)

diff --git a/drivers/media/i2c/smiapp/smiapp-quirk.c 
b/drivers/media/i2c/smiapp/smiapp-quirk.c
index cf04812..725cf62 100644
--- a/drivers/media/i2c/smiapp/smiapp-quirk.c
+++ b/drivers/media/i2c/smiapp/smiapp-quirk.c
@@ -61,26 +61,6 @@ void smiapp_replace_limit(struct smiapp_sensor *sensor,
sensor->limits[limit] = val;
 }
 
-int smiapp_replace_limit_at(struct smiapp_sensor *sensor,
-   u32 reg, u32 val)
-{
-   struct i2c_client *client = v4l2_get_subdevdata(&sensor->src->sd);
-   int i;
-
-   for (i = 0; smiapp_reg_limits[i].addr; i++) {
-   if ((smiapp_reg_limits[i].addr & 0x) != reg)
-   continue;
-
-   smiapp_replace_limit(sensor, i, val);
-
-   return 0;
-   }
-
-   dev_dbg(&client->dev, "quirk: bad register 0x%4.4x\n", reg);
-
-   return -EINVAL;
-}
-
 bool smiapp_quirk_reg(struct smiapp_sensor *sensor,
  u32 reg, u32 *val)
 {
-- 
1.7.4.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 v2] smiapp: Use devm_* functions in smiapp-core.c file

2012-08-16 Thread Sachin Kamat 
devm_* functions are device managed functions and make code a bit
smaller and cleaner.

Signed-off-by: Sachin Kamat 
---
Changes since v1:
Used devm_kzalloc for sensor->nvm.
Used devm_clk_get and devm_regulator_get functions.

This patch is based on Mauro's re-organized tree
(media_tree staging/for_v3.7) and is compile tested.
---
 drivers/media/i2c/smiapp/smiapp-core.c |   47 +++
 1 files changed, 11 insertions(+), 36 deletions(-)

diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
b/drivers/media/i2c/smiapp/smiapp-core.c
index 1cf914d..4f1c8d6 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -2355,20 +2355,19 @@ static int smiapp_registered(struct v4l2_subdev *subdev)
unsigned int i;
int rval;
 
-   sensor->vana = regulator_get(&client->dev, "VANA");
+   sensor->vana = devm_regulator_get(&client->dev, "VANA");
if (IS_ERR(sensor->vana)) {
dev_err(&client->dev, "could not get regulator for vana\n");
return -ENODEV;
}
 
if (!sensor->platform_data->set_xclk) {
-   sensor->ext_clk = clk_get(&client->dev,
- sensor->platform_data->ext_clk_name);
+   sensor->ext_clk = devm_clk_get(&client->dev,
+   sensor->platform_data->ext_clk_name);
if (IS_ERR(sensor->ext_clk)) {
dev_err(&client->dev, "could not get clock %s\n",
sensor->platform_data->ext_clk_name);
-   rval = -ENODEV;
-   goto out_clk_get;
+   return -ENODEV;
}
 
rval = clk_set_rate(sensor->ext_clk,
@@ -2378,8 +2377,7 @@ static int smiapp_registered(struct v4l2_subdev *subdev)
"unable to set clock %s freq to %u\n",
sensor->platform_data->ext_clk_name,
sensor->platform_data->ext_clk);
-   rval = -ENODEV;
-   goto out_clk_set_rate;
+   return -ENODEV;
}
}
 
@@ -2389,8 +2387,7 @@ static int smiapp_registered(struct v4l2_subdev *subdev)
dev_err(&client->dev,
"unable to acquire reset gpio %d\n",
sensor->platform_data->xshutdown);
-   rval = -ENODEV;
-   goto out_clk_set_rate;
+   return -ENODEV;
}
}
 
@@ -2470,8 +2467,8 @@ static int smiapp_registered(struct v4l2_subdev *subdev)
 * when it is first requested by userspace.
 */
if (sensor->minfo.smiapp_version && sensor->platform_data->nvm_size) {
-   sensor->nvm = kzalloc(sensor->platform_data->nvm_size,
- GFP_KERNEL);
+   sensor->nvm = devm_kzalloc(&client->dev,
+   sensor->platform_data->nvm_size, GFP_KERNEL);
if (sensor->nvm == NULL) {
dev_err(&client->dev, "nvm buf allocation failed\n");
rval = -ENOMEM;
@@ -2637,21 +2634,12 @@ out_nvm_release:
device_remove_file(&client->dev, &dev_attr_nvm);
 
 out_power_off:
-   kfree(sensor->nvm);
-   sensor->nvm = NULL;
smiapp_power_off(sensor);
 
 out_smiapp_power_on:
if (sensor->platform_data->xshutdown != SMIAPP_NO_XSHUTDOWN)
gpio_free(sensor->platform_data->xshutdown);
 
-out_clk_set_rate:
-   clk_put(sensor->ext_clk);
-   sensor->ext_clk = NULL;
-
-out_clk_get:
-   regulator_put(sensor->vana);
-   sensor->vana = NULL;
return rval;
 }
 
@@ -2801,12 +2789,11 @@ static int smiapp_probe(struct i2c_client *client,
const struct i2c_device_id *devid)
 {
struct smiapp_sensor *sensor;
-   int rval;
 
if (client->dev.platform_data == NULL)
return -ENODEV;
 
-   sensor = kzalloc(sizeof(*sensor), GFP_KERNEL);
+   sensor = devm_kzalloc(&client->dev, sizeof(*sensor), GFP_KERNEL);
if (sensor == NULL)
return -ENOMEM;
 
@@ -2821,12 +2808,8 @@ static int smiapp_probe(struct i2c_client *client,
sensor->src->sensor = sensor;
 
sensor->src->pads[0].flags = MEDIA_PAD_FL_SOURCE;
-   rval = media_entity_init(&sensor->src->sd.entity, 2,
+   return media_entity_init(&sensor->src->sd.entity, 2,
 sensor->src->pads, 0);
-   if (rval < 0)
-   kfree(sensor);
-
-   return rval;
 }
 
 static int __exit smiapp_remove(struct i2c_client *client)
@@ -2845,10 +2828,8 @@ static int __exit smiapp_remove(struct i2c_client 
*client)
sensor->power_count = 0;
}
 
-   if (sensor->nvm) {
+   if (sensor->nvm)

Re: [PATCH] smiapp: Use devm_kzalloc() in smiapp-core.c file

2012-08-16 Thread Sachin Kamat 
Hi Sakari,

Thanks for reviewing the patch.

On 16 August 2012 22:26, Sakari Ailus  wrote:
> Hi Sachin,
>
> Thanks for the patch.
>
> On Thu, Aug 16, 2012 at 04:59:30PM +0530, Sachin Kamat wrote:
>> devm_kzalloc is a device managed function and makes code a bit
>> smaller and cleaner.
>>
>> Signed-off-by: Sachin Kamat 
>> ---
>> This patch is based on Mauro's re-organized tree
>> (media_tree staging/for_v3.7) and is compile tested.
>> ---
>>  drivers/media/i2c/smiapp/smiapp-core.c |   11 ++-
>>  1 files changed, 2 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
>> b/drivers/media/i2c/smiapp/smiapp-core.c
>> index 1cf914d..7d4280e 100644
>> --- a/drivers/media/i2c/smiapp/smiapp-core.c
>> +++ b/drivers/media/i2c/smiapp/smiapp-core.c
>> @@ -2801,12 +2801,11 @@ static int smiapp_probe(struct i2c_client *client,
>>   const struct i2c_device_id *devid)
>>  {
>>   struct smiapp_sensor *sensor;
>> - int rval;
>>
>>   if (client->dev.platform_data == NULL)
>>   return -ENODEV;
>>
>> - sensor = kzalloc(sizeof(*sensor), GFP_KERNEL);
>> + sensor = devm_kzalloc(&client->dev, sizeof(*sensor), GFP_KERNEL);
>>   if (sensor == NULL)
>>   return -ENOMEM;
>>
>
> I think the same should be done to sensor->nvm. Would you like to change the
> patch to incorporate the change? I'm fine doing that as well.

Sure. I will send the updated patch shortly. I have also expanded the
scope of the patch to
use other devm_* functions too.

>
> Cheers,
>
> --
> Sakari Ailus
> e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk



-- 
With warm regards,
Sachin
--
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

[samsung:v4l-exynos-gsc 77/299] drivers/media/video/em28xx/em28xx-video.c:2269:17-20: ERROR: reference preceded by free on line 2267

2012-08-16 Thread Fengguang Wu 
Hi Hans,

FYI, there are new coccinelle warnings show up in

tree:   git://git.infradead.org/users/kmpark/linux-samsung v4l-exynos-gsc
head:   8ac9447881f291e7b473d946bde20ec952621a23
commit: 876cb14db3bec19960751bb02f03f72ee024a46f [77/299] [media] em28xx: 
remove V4L2_FL_LOCK_ALL_FOPS

All coccinelle warnings:

+ drivers/media/video/em28xx/em28xx-video.c:2269:17-20: ERROR: reference 
preceded by free on line 2267

vim +2269 drivers/media/video/em28xx/em28xx-video.c
  2266  kfree(dev->alt_max_pkt_size);
  2267  kfree(dev);
  2268  kfree(fh);
> 2269  mutex_unlock(&dev->lock);
  2270  return 0;
  2271  }
  2272  

---
0-DAY kernel build testing backend Open Source Technology Centre
Fengguang Wu  Intel Corporation
--
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] dvb-usb: remove unused files

2012-08-16 Thread Antti Palosaari 
Those files were left from dvb-usb-v2 development as I have made
mistake during rebase operation.

Reported-by: Hans Verkuil 
Signed-off-by: Antti Palosaari 
---
 drivers/media/usb/dvb-usb/dvb_usb_dvb.c| 403 -
 drivers/media/usb/dvb-usb/dvb_usb_remote.c | 117 -
 2 files changed, 520 deletions(-)
 delete mode 100644 drivers/media/usb/dvb-usb/dvb_usb_dvb.c
 delete mode 100644 drivers/media/usb/dvb-usb/dvb_usb_remote.c

diff --git a/drivers/media/usb/dvb-usb/dvb_usb_dvb.c 
b/drivers/media/usb/dvb-usb/dvb_usb_dvb.c
deleted file mode 100644
index 384fe8e..000
--- a/drivers/media/usb/dvb-usb/dvb_usb_dvb.c
+++ /dev/null
@@ -1,403 +0,0 @@
-/* dvb-usb-dvb.c is part of the DVB USB library.
- *
- * Copyright (C) 2004-6 Patrick Boettcher (patrick.boettc...@desy.de)
- * see dvb-usb-init.c for copyright information.
- *
- * This file contains functions for initializing and handling the
- * linux-dvb API.
- */
-#include "dvb_usb_common.h"
-
-static void dvb_usb_data_complete(struct usb_data_stream *stream, u8 *buf,
-   size_t len)
-{
-   struct dvb_usb_adapter *adap = stream->user_priv;
-   dvb_dmx_swfilter(&adap->demux, buf, len);
-}
-
-static void dvb_usb_data_complete_204(struct usb_data_stream *stream, u8 *buf,
-   size_t len)
-{
-   struct dvb_usb_adapter *adap = stream->user_priv;
-   dvb_dmx_swfilter_204(&adap->demux, buf, len);
-}
-
-static void dvb_usb_data_complete_raw(struct usb_data_stream *stream, u8 *buf,
-   size_t len)
-{
-   struct dvb_usb_adapter *adap = stream->user_priv;
-   dvb_dmx_swfilter_raw(&adap->demux, buf, len);
-}
-
-int dvb_usbv2_adapter_stream_init(struct dvb_usb_adapter *adap)
-{
-   pr_debug("%s: adap=%d\n", __func__, adap->id);
-
-   adap->stream.udev = adap_to_d(adap)->udev;
-   adap->stream.user_priv = adap;
-   adap->stream.complete = dvb_usb_data_complete;
-
-   return usb_urb_initv2(&adap->stream, &adap->props->stream);
-}
-
-int dvb_usbv2_adapter_stream_exit(struct dvb_usb_adapter *adap)
-{
-   pr_debug("%s: adap=%d\n", __func__, adap->id);
-   usb_urb_exitv2(&adap->stream);
-
-   return 0;
-}
-
-/* does the complete input transfer handling */
-static inline int dvb_usb_ctrl_feed(struct dvb_demux_feed *dvbdmxfeed, int 
count)
-{
-   struct dvb_usb_adapter *adap = dvbdmxfeed->demux->priv;
-   struct dvb_usb_device *d = adap_to_d(adap);
-   int ret;
-   pr_debug("%s: adap=%d active_fe=%d feed_type=%d setting pid [%s]: " \
-   "%04x (%04d) at index %d '%s'\n", __func__, adap->id,
-   adap->active_fe, dvbdmxfeed->type,
-   adap->pid_filtering ? "yes" : "no", dvbdmxfeed->pid,
-   dvbdmxfeed->pid, dvbdmxfeed->index,
-   (count == 1) ? "on" : "off");
-
-   if (adap->active_fe == -1)
-   return -EINVAL;
-
-   adap->feed_count += count;
-
-   /* stop feeding if it is last pid */
-   if (adap->feed_count == 0) {
-   pr_debug("%s: stop feeding\n", __func__);
-   usb_urb_killv2(&adap->stream);
-
-   if (d->props->streaming_ctrl) {
-   ret = d->props->streaming_ctrl(adap, 0);
-   if (ret < 0) {
-   pr_err("%s: streaming_ctrl() failed=%d\n",
-   KBUILD_MODNAME, ret);
-   goto err_mutex_unlock;
-   }
-   }
-   mutex_unlock(&adap->sync_mutex);
-   }
-
-   /* activate the pid on the device pid filter */
-   if (adap->props->caps & DVB_USB_ADAP_HAS_PID_FILTER &&
-   adap->pid_filtering &&
-   adap->props->pid_filter)
-   ret = adap->props->pid_filter(adap, dvbdmxfeed->index,
-   dvbdmxfeed->pid, (count == 1) ? 1 : 0);
-   if (ret < 0)
-   pr_err("%s: pid_filter() failed=%d\n",
-   KBUILD_MODNAME, ret);
-
-   /* start feeding if it is first pid */
-   if (adap->feed_count == 1 && count == 1) {
-   struct usb_data_stream_properties stream_props;
-   mutex_lock(&adap->sync_mutex);
-   pr_debug("%s: start feeding\n", __func__);
-
-   /* resolve input and output streaming paramters */
-   if (d->props->get_stream_config) {
-   memcpy(&stream_props, &adap->props->stream,
-   sizeof(struct usb_data_stream_properties));
-   ret = d->props->get_stream_config(
-   adap->fe[adap->active_fe],
-   &adap->ts_type, &stream_props);
-   if (ret < 0)
-   goto err_mutex_unlock;
-   }

[PATCH] dvb_usb_v2: use ratelimited debugs where appropriate

2012-08-16 Thread Antti Palosaari 
Signed-off-by: Antti Palosaari 
---
 drivers/media/usb/dvb-usb-v2/usb_urb.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/media/usb/dvb-usb-v2/usb_urb.c 
b/drivers/media/usb/dvb-usb-v2/usb_urb.c
index eaf673a..5989b65 100644
--- a/drivers/media/usb/dvb-usb-v2/usb_urb.c
+++ b/drivers/media/usb/dvb-usb-v2/usb_urb.c
@@ -22,9 +22,9 @@ static void usb_urb_complete(struct urb *urb)
int i;
u8 *b;
 
-   dev_dbg(&stream->udev->dev, "%s: %s urb completed status=%d " \
-   "length=%d/%d pack_num=%d errors=%d\n", __func__,
-   ptype == PIPE_ISOCHRONOUS ? "isoc" : "bulk",
+   dev_dbg_ratelimited(&stream->udev->dev, "%s: %s urb completed " \
+   "status=%d length=%d/%d pack_num=%d errors=%d\n",
+   __func__, ptype == PIPE_ISOCHRONOUS ? "isoc" : "bulk",
urb->status, urb->actual_length,
urb->transfer_buffer_length,
urb->number_of_packets, urb->error_count);
@@ -38,7 +38,8 @@ static void usb_urb_complete(struct urb *urb)
case -ESHUTDOWN:
return;
default:/* error */
-   dev_dbg(&stream->udev->dev, "%s: urb completition failed=%d\n",
+   dev_dbg_ratelimited(&stream->udev->dev,
+   "%s: urb completition failed=%d\n",
__func__, urb->status);
break;
}
-- 
1.7.11.2

--
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 4/4] dvb_frontend: add routine for DTMB parameter validation

2012-08-16 Thread Antti Palosaari 
Common routine for use of dvb-core, demodulator and tuner for check
given DTMB parameters correctness.

Signed-off-by: Antti Palosaari 
---
 drivers/media/dvb-core/dvb_frontend.c | 97 +++
 drivers/media/dvb-core/dvb_frontend.h |  1 +
 2 files changed, 98 insertions(+)

diff --git a/drivers/media/dvb-core/dvb_frontend.c 
b/drivers/media/dvb-core/dvb_frontend.c
index 6a19c87..7c3ba26 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -2813,6 +2813,103 @@ int dvb_validate_params_dvbc_annex_a(struct 
dvb_frontend *fe)
 }
 EXPORT_SYMBOL(dvb_validate_params_dvbc_annex_a);
 
+int dvb_validate_params_dtmb(struct dvb_frontend *fe)
+{
+   struct dtv_frontend_properties *c = &fe->dtv_property_cache;
+
+   dev_dbg(fe->dvb->device, "%s:\n", __func__);
+
+   switch (c->delivery_system) {
+   case SYS_DTMB:
+   break;
+   default:
+   dev_dbg(fe->dvb->device, "%s: delivery_system=%d\n", __func__,
+   c->delivery_system);
+   return -EINVAL;
+   }
+
+   if (c->frequency >= 47000 && c->frequency <= 86200) {
+   ;
+   } else {
+   dev_dbg(fe->dvb->device, "%s: frequency=%d\n", __func__,
+   c->frequency);
+   return -EINVAL;
+   }
+
+   switch (c->bandwidth_hz) {
+   case 800:
+   break;
+   default:
+   dev_dbg(fe->dvb->device, "%s: bandwidth_hz=%d\n", __func__,
+   c->bandwidth_hz);
+   return -EINVAL;
+   }
+
+   switch (c->modulation) {
+   case QAM_AUTO:
+   case QPSK: /* QAM4 */
+   case QAM_16:
+   case QAM_32:
+   case QAM_64:
+   case QAM_4_NR:
+   break;
+   default:
+   dev_dbg(fe->dvb->device, "%s: modulation=%d\n", __func__,
+   c->modulation);
+   return -EINVAL;
+   }
+
+   switch (c->transmission_mode) {
+   case TRANSMISSION_MODE_AUTO:
+   case TRANSMISSION_MODE_C1:
+   case TRANSMISSION_MODE_C3780:
+   break;
+   default:
+   dev_dbg(fe->dvb->device, "%s: transmission_mode=%d\n", __func__,
+   c->transmission_mode);
+   return -EINVAL;
+   }
+
+   switch (c->guard_interval) {
+   case GUARD_INTERVAL_AUTO:
+   case GUARD_INTERVAL_PN420:
+   case GUARD_INTERVAL_PN595:
+   case GUARD_INTERVAL_PN945:
+   break;
+   default:
+   dev_dbg(fe->dvb->device, "%s: guard_interval=%d\n", __func__,
+   c->guard_interval);
+   return -EINVAL;
+   }
+
+   /* inner coding LDPC */
+   switch (c->fec_inner) {
+   case FEC_AUTO:
+   case FEC_2_5: /* 0.4 */
+   case FEC_3_5: /* 0.6 */
+   case FEC_4_5: /* 0.8 */
+   break;
+   default:
+   dev_dbg(fe->dvb->device, "%s: fec_inner=%d\n", __func__,
+   c->fec_inner);
+   return -EINVAL;
+   }
+
+   switch (c->interleaving) {
+   case INTERLEAVING_AUTO:
+   case INTERLEAVING_240:
+   case INTERLEAVING_720:
+   break;
+   default:
+   dev_dbg(fe->dvb->device, "%s: interleaving=%d\n", __func__,
+   c->interleaving);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(dvb_validate_params_dtmb);
+
 int dvb_register_frontend(struct dvb_adapter* dvb,
  struct dvb_frontend* fe)
 {
diff --git a/drivers/media/dvb-core/dvb_frontend.h 
b/drivers/media/dvb-core/dvb_frontend.h
index e6e6fe1..9499039 100644
--- a/drivers/media/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb-core/dvb_frontend.h
@@ -428,5 +428,6 @@ extern s32 timeval_usec_diff(struct timeval lasttime, 
struct timeval curtime);
 extern int dvb_validate_params_dvbt(struct dvb_frontend *fe);
 extern int dvb_validate_params_dvbt2(struct dvb_frontend *fe);
 extern int dvb_validate_params_dvbc_annex_a(struct dvb_frontend *fe);
+extern int dvb_validate_params_dtmb(struct dvb_frontend *fe);
 
 #endif
-- 
1.7.11.2

--
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/4] dvb_frontend: add routine for DVB-T parameter validation

2012-08-16 Thread Antti Palosaari 
Common routine for use of dvb-core, demodulator and tuner for check
given DVB-T parameters correctness.

Signed-off-by: Antti Palosaari 
---
 drivers/media/dvb-core/dvb_frontend.c | 136 ++
 drivers/media/dvb-core/dvb_frontend.h |   2 +
 2 files changed, 138 insertions(+)

diff --git a/drivers/media/dvb-core/dvb_frontend.c 
b/drivers/media/dvb-core/dvb_frontend.c
index d29d41a..4abb648 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -2505,6 +2505,142 @@ int dvb_frontend_resume(struct dvb_frontend *fe)
 }
 EXPORT_SYMBOL(dvb_frontend_resume);
 
+int dvb_validate_params_dvbt(struct dvb_frontend *fe)
+{
+   struct dtv_frontend_properties *c = &fe->dtv_property_cache;
+
+   dev_dbg(fe->dvb->device, "%s:\n", __func__);
+
+   switch (c->delivery_system) {
+   case SYS_DVBT:
+   break;
+   default:
+   dev_dbg(fe->dvb->device, "%s: delivery_system=%d\n", __func__,
+   c->delivery_system);
+   return -EINVAL;
+   }
+
+   if (c->frequency >= 17400 && c->frequency <= 23000) {
+   ;
+   } else if (c->frequency >= 47000 && c->frequency <= 86200) {
+   ;
+   } else {
+   dev_dbg(fe->dvb->device, "%s: frequency=%d\n", __func__,
+   c->frequency);
+   return -EINVAL;
+   }
+
+   switch (c->bandwidth_hz) {
+   case 600:
+   case 700:
+   case 800:
+   break;
+   default:
+   dev_dbg(fe->dvb->device, "%s: bandwidth_hz=%d\n", __func__,
+   c->bandwidth_hz);
+   return -EINVAL;
+   }
+
+   switch (c->transmission_mode) {
+   case TRANSMISSION_MODE_AUTO:
+   case TRANSMISSION_MODE_2K:
+   case TRANSMISSION_MODE_8K:
+   break;
+   default:
+   dev_dbg(fe->dvb->device, "%s: transmission_mode=%d\n", __func__,
+   c->transmission_mode);
+   return -EINVAL;
+   }
+
+   switch (c->modulation) {
+   case QAM_AUTO:
+   case QPSK:
+   case QAM_16:
+   case QAM_64:
+   break;
+   default:
+   dev_dbg(fe->dvb->device, "%s: modulation=%d\n", __func__,
+   c->modulation);
+   return -EINVAL;
+   }
+
+   switch (c->guard_interval) {
+   case GUARD_INTERVAL_AUTO:
+   case GUARD_INTERVAL_1_32:
+   case GUARD_INTERVAL_1_16:
+   case GUARD_INTERVAL_1_8:
+   case GUARD_INTERVAL_1_4:
+   break;
+   default:
+   dev_dbg(fe->dvb->device, "%s: guard_interval=%d\n", __func__,
+   c->guard_interval);
+   return -EINVAL;
+   }
+
+   switch (c->hierarchy) {
+   case HIERARCHY_NONE:
+   case HIERARCHY_AUTO:
+   case HIERARCHY_1:
+   case HIERARCHY_2:
+   case HIERARCHY_4:
+   break;
+   default:
+   dev_dbg(fe->dvb->device, "%s: hierarchy=%d\n", __func__,
+   c->hierarchy);
+   return -EINVAL;
+   }
+
+   switch (c->code_rate_HP) {
+   case FEC_AUTO:
+   case FEC_1_2:
+   case FEC_2_3:
+   case FEC_3_4:
+   case FEC_5_6:
+   case FEC_7_8:
+   break;
+   default:
+   dev_dbg(fe->dvb->device, "%s: code_rate_HP=%d\n", __func__,
+   c->code_rate_HP);
+   return -EINVAL;
+   }
+
+   /*
+* code_rate_LP is used only with hierarchical coding
+*/
+   if (c->hierarchy == HIERARCHY_NONE) {
+   switch (c->code_rate_LP) {
+   case FEC_NONE:
+   /*
+* TODO: FEC_AUTO here is wrong, but for some reason
+* dtv_set_frontend() forces it.
+*/
+   case FEC_AUTO:
+   break;
+   default:
+   dev_dbg(fe->dvb->device, "%s: code_rate_LP=%d\n",
+   __func__, c->code_rate_LP);
+   return -EINVAL;
+   }
+   } else {
+   switch (c->code_rate_LP) {
+   case FEC_AUTO:
+   case FEC_1_2:
+   case FEC_2_3:
+   case FEC_3_4:
+   case FEC_5_6:
+   case FEC_7_8:
+   break;
+   default:
+   dev_dbg(fe->dvb->device, "%s: code_rate_LP=%d\n",
+   __func__, c->code_rate_LP);
+   return -EINVAL;
+   }
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(dvb_validate_params_dvbt);
+
 int dvb_register_frontend(struct dvb_adapter* dvb,
  struct dvb_frontend* fe)
 {
diff --git a/drivers/media/dvb-core/dvb_front

[PATCH 0/4] dvb_frontend: few DTV validation routines

2012-08-16 Thread Antti Palosaari 
It could be nice to validate transmission parameters, coming from
the userspace, against standards before those are passed to the
individual chipset driver. As a starting point towards that
I implemented checks for few common standards. Those checks could
be better as I added almost none checks for comparing allowed
parameter combinations. I found it quite time consuming to search
all allowed parameters and combinations...

Those checks are now exported from the dvb-frontend, making for
example demodulator driver possible to call. Maybe someday those
could be used by frontend itself to validate data before pass call
for the driver.

I also noticed our documentation lacks quite totally possible values,
only possible parameters were listed. How do we expect application
makers could know those?

Antti Palosaari (4):
  dvb_frontend: add routine for DVB-T parameter validation
  dvb_frontend: add routine for DVB-T2 parameter validation
  dvb_frontend: add routine for DVB-C annex A parameter validation
  dvb_frontend: add routine for DTMB parameter validation

 drivers/media/dvb-core/dvb_frontend.c | 405 ++
 drivers/media/dvb-core/dvb_frontend.h |   5 +
 2 files changed, 410 insertions(+)

-- 
1.7.11.2

--
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/4] dvb_frontend: add routine for DVB-C annex A parameter validation

2012-08-16 Thread Antti Palosaari 
Common routine for use of dvb-core, demodulator and tuner for check
given DVB-C annex A parameters correctness.

Signed-off-by: Antti Palosaari 
---
 drivers/media/dvb-core/dvb_frontend.c | 54 +++
 drivers/media/dvb-core/dvb_frontend.h |  1 +
 2 files changed, 55 insertions(+)

diff --git a/drivers/media/dvb-core/dvb_frontend.c 
b/drivers/media/dvb-core/dvb_frontend.c
index 6413c74..6a19c87 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -2759,6 +2759,60 @@ int dvb_validate_params_dvbt2(struct dvb_frontend *fe)
 }
 EXPORT_SYMBOL(dvb_validate_params_dvbt2);
 
+int dvb_validate_params_dvbc_annex_a(struct dvb_frontend *fe)
+{
+   struct dtv_frontend_properties *c = &fe->dtv_property_cache;
+
+   dev_dbg(fe->dvb->device, "%s:\n", __func__);
+
+   switch (c->delivery_system) {
+   case SYS_DVBC_ANNEX_A:
+   break;
+   default:
+   dev_dbg(fe->dvb->device, "%s: delivery_system=%d\n", __func__,
+   c->delivery_system);
+   return -EINVAL;
+   }
+
+   /*
+* TODO: NorDig Unified 2.2 specifies input frequency range
+* 110 - 862 MHz. Do not limit it now as w_scan seems to start from
+* 73 MHz until reason is clear.
+*/
+   if (c->frequency >= 0 && c->frequency <= 86200) {
+   ;
+   } else {
+   dev_dbg(fe->dvb->device, "%s: frequency=%d\n", __func__,
+   c->frequency);
+   return -EINVAL;
+   }
+
+   if (c->symbol_rate >= 100 && c->symbol_rate <= 700) {
+   ;
+   } else {
+   dev_dbg(fe->dvb->device, "%s: symbol_rate=%d\n", __func__,
+   c->symbol_rate);
+   return -EINVAL;
+   }
+
+   switch (c->modulation) {
+   case QAM_AUTO:
+   case QAM_16:
+   case QAM_32:
+   case QAM_64:
+   case QAM_128:
+   case QAM_256:
+   break;
+   default:
+   dev_dbg(fe->dvb->device, "%s: modulation=%d\n", __func__,
+   c->modulation);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(dvb_validate_params_dvbc_annex_a);
+
 int dvb_register_frontend(struct dvb_adapter* dvb,
  struct dvb_frontend* fe)
 {
diff --git a/drivers/media/dvb-core/dvb_frontend.h 
b/drivers/media/dvb-core/dvb_frontend.h
index bcd572d..e6e6fe1 100644
--- a/drivers/media/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb-core/dvb_frontend.h
@@ -427,5 +427,6 @@ extern s32 timeval_usec_diff(struct timeval lasttime, 
struct timeval curtime);
 
 extern int dvb_validate_params_dvbt(struct dvb_frontend *fe);
 extern int dvb_validate_params_dvbt2(struct dvb_frontend *fe);
+extern int dvb_validate_params_dvbc_annex_a(struct dvb_frontend *fe);
 
 #endif
-- 
1.7.11.2

--
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/4] dvb_frontend: add routine for DVB-T2 parameter validation

2012-08-16 Thread Antti Palosaari 
Common routine for use of dvb-core, demodulator and tuner for check
given DVB-T2 parameters correctness.

Signed-off-by: Antti Palosaari 
---
 drivers/media/dvb-core/dvb_frontend.c | 118 ++
 drivers/media/dvb-core/dvb_frontend.h |   1 +
 2 files changed, 119 insertions(+)

diff --git a/drivers/media/dvb-core/dvb_frontend.c 
b/drivers/media/dvb-core/dvb_frontend.c
index 4abb648..6413c74 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -2641,6 +2641,124 @@ int dvb_validate_params_dvbt(struct dvb_frontend *fe)
 }
 EXPORT_SYMBOL(dvb_validate_params_dvbt);
 
+int dvb_validate_params_dvbt2(struct dvb_frontend *fe)
+{
+   struct dtv_frontend_properties *c = &fe->dtv_property_cache;
+
+   dev_dbg(fe->dvb->device, "%s:\n", __func__);
+
+   switch (c->delivery_system) {
+   case SYS_DVBT2:
+   break;
+   default:
+   dev_dbg(fe->dvb->device, "%s: delivery_system=%d\n", __func__,
+   c->delivery_system);
+   return -EINVAL;
+   }
+
+   /*
+* DVB-T2 specification as such does not specify any frequency bands.
+* Define real life limits still. L-Band 1452 - 1492 MHz may exits in
+* future too.
+*/
+   if (c->frequency >= 17400 && c->frequency <= 23000) {
+   ;
+   } else if (c->frequency >= 47000 && c->frequency <= 86200) {
+   ;
+   } else {
+   dev_dbg(fe->dvb->device, "%s: frequency=%d\n", __func__,
+   c->frequency);
+   return -EINVAL;
+   }
+
+   switch (c->bandwidth_hz) {
+   case  600:
+   case  700:
+   case  800:
+   case  170:
+   case  500:
+   case 1000:
+   break;
+   default:
+   dev_dbg(fe->dvb->device, "%s: bandwidth_hz=%d\n", __func__,
+   c->bandwidth_hz);
+   return -EINVAL;
+   }
+
+   /*
+* Valid Physical Layer Pipe (PLP) values are 0 - 255
+*/
+   if (c->dvbt2_plp_id <= 255) {
+   ;
+   } else {
+   dev_dbg(fe->dvb->device, "%s: dvbt2_plp_id=%d\n", __func__,
+   c->dvbt2_plp_id);
+   return -EINVAL;
+   }
+
+   switch (c->transmission_mode) {
+   case TRANSMISSION_MODE_AUTO:
+   case TRANSMISSION_MODE_2K:
+   case TRANSMISSION_MODE_8K:
+   case TRANSMISSION_MODE_1K:
+   case TRANSMISSION_MODE_4K:
+   case TRANSMISSION_MODE_16K:
+   case TRANSMISSION_MODE_32K:
+   break;
+   default:
+   dev_dbg(fe->dvb->device, "%s: transmission_mode=%d\n", __func__,
+   c->transmission_mode);
+   return -EINVAL;
+   }
+
+   switch (c->modulation) {
+   case QAM_AUTO:
+   case QPSK:
+   case QAM_16:
+   case QAM_64:
+   case QAM_256:
+   break;
+   default:
+   dev_dbg(fe->dvb->device, "%s: modulation=%d\n", __func__,
+   c->modulation);
+   return -EINVAL;
+   }
+
+   switch (c->guard_interval) {
+   case GUARD_INTERVAL_AUTO:
+   case GUARD_INTERVAL_1_32:
+   case GUARD_INTERVAL_1_16:
+   case GUARD_INTERVAL_1_8:
+   case GUARD_INTERVAL_1_4:
+   case GUARD_INTERVAL_1_128:
+   case GUARD_INTERVAL_19_128:
+   case GUARD_INTERVAL_19_256:
+   break;
+   default:
+   dev_dbg(fe->dvb->device, "%s: guard_interval=%d\n", __func__,
+   c->guard_interval);
+   return -EINVAL;
+   }
+
+   switch (c->fec_inner) {
+   case FEC_AUTO:
+   case FEC_1_2:
+   case FEC_3_5:
+   case FEC_2_3:
+   case FEC_3_4:
+   case FEC_4_5:
+   case FEC_5_6:
+   break;
+   default:
+   dev_dbg(fe->dvb->device, "%s: fec_inner=%d\n", __func__,
+   c->fec_inner);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(dvb_validate_params_dvbt2);
+
 int dvb_register_frontend(struct dvb_adapter* dvb,
  struct dvb_frontend* fe)
 {
diff --git a/drivers/media/dvb-core/dvb_frontend.h 
b/drivers/media/dvb-core/dvb_frontend.h
index 6df0c44..bcd572d 100644
--- a/drivers/media/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb-core/dvb_frontend.h
@@ -426,5 +426,6 @@ extern void dvb_frontend_sleep_until(struct timeval 
*waketime, u32 add_usec);
 extern s32 timeval_usec_diff(struct timeval lasttime, struct timeval curtime);
 
 extern int dvb_validate_params_dvbt(struct dvb_frontend *fe);
+extern int dvb_validate_params_dvbt2(struct dvb_frontend *fe);
 
 #endif
-- 
1.7.11.2

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

[PATCH 6/6] DVB API: LNA documentation

2012-08-16 Thread Antti Palosaari 
Signed-off-by: Antti Palosaari 
---
 Documentation/DocBook/media/dvb/dvbproperty.xml | 16 
 1 file changed, 16 insertions(+)

diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml 
b/Documentation/DocBook/media/dvb/dvbproperty.xml
index d188be9..2dfa6a0 100644
--- a/Documentation/DocBook/media/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
@@ -827,6 +827,17 @@ enum fe_interleaving {
 };


+   
+   DTV_LNA
+   Low-noise amplifier.
+   Hardware might offer controllable LNA which can be set manually
+   using that parameter. Usually LNA could be found only from
+   terrestrial devices if at all.
+   Possible values: 0, 1, INT_MIN
+   0, LNA off
+   1, LNA on
+   INT_MIN, LNA auto
+   
 

Properties used on terrestrial delivery systems
@@ -847,6 +858,7 @@ enum fe_interleaving {
DTV_GUARD_INTERVAL
DTV_TRANSMISSION_MODE
DTV_HIERARCHY
+   DTV_LNA



@@ -870,6 +882,7 @@ enum fe_interleaving {
DTV_TRANSMISSION_MODE
DTV_HIERARCHY
DTV_DVBT2_PLP_ID
+   DTV_LNA



@@ -981,6 +994,7 @@ enum fe_interleaving {
DTV_GUARD_INTERVAL
DTV_TRANSMISSION_MODE
DTV_INTERLEAVING
+   DTV_LNA



@@ -1001,6 +1015,7 @@ enum fe_interleaving {
DTV_INVERSION
DTV_SYMBOL_RATE
DTV_INNER_FEC
+   DTV_LNA



@@ -1015,6 +1030,7 @@ enum fe_interleaving {
DTV_FREQUENCY
DTV_MODULATION
DTV_INVERSION
+   DTV_LNA



-- 
1.7.11.2

--
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/6] cxd2820r: use Kernel GPIO for GPIO access

2012-08-16 Thread Antti Palosaari 
Currently there is LNA behind cxd2820r demodulator GPIO. Use
Kernel GPIO interface to access those GPIOs.

Signed-off-by: Antti Palosaari 
---
 drivers/media/dvb-frontends/cxd2820r.h  |  14 ++--
 drivers/media/dvb-frontends/cxd2820r_c.c|   5 --
 drivers/media/dvb-frontends/cxd2820r_core.c | 108 ++--
 drivers/media/dvb-frontends/cxd2820r_priv.h |   9 ++-
 drivers/media/dvb-frontends/cxd2820r_t.c|   5 --
 drivers/media/dvb-frontends/cxd2820r_t2.c   |   5 --
 drivers/media/usb/dvb-usb-v2/anysee.c   |   2 +-
 drivers/media/usb/em28xx/em28xx-dvb.c   |  21 --
 8 files changed, 114 insertions(+), 55 deletions(-)

diff --git a/drivers/media/dvb-frontends/cxd2820r.h 
b/drivers/media/dvb-frontends/cxd2820r.h
index 5aa306e..6acc21c 100644
--- a/drivers/media/dvb-frontends/cxd2820r.h
+++ b/drivers/media/dvb-frontends/cxd2820r.h
@@ -62,14 +62,6 @@ struct cxd2820r_config {
 * Values: 0, 1
 */
bool spec_inv;
-
-   /* GPIOs for all used modes.
-* Default: none, disabled
-* Values: 
-*/
-   u8 gpio_dvbt[3];
-   u8 gpio_dvbt2[3];
-   u8 gpio_dvbc[3];
 };
 
 
@@ -77,12 +69,14 @@ struct cxd2820r_config {
(defined(CONFIG_DVB_CXD2820R_MODULE) && defined(MODULE))
 extern struct dvb_frontend *cxd2820r_attach(
const struct cxd2820r_config *config,
-   struct i2c_adapter *i2c
+   struct i2c_adapter *i2c,
+   int *gpio_chip_base
 );
 #else
 static inline struct dvb_frontend *cxd2820r_attach(
const struct cxd2820r_config *config,
-   struct i2c_adapter *i2c
+   struct i2c_adapter *i2c,
+   int *gpio_chip_base
 )
 {
printk(KERN_WARNING "%s: driver disabled by Kconfig\n", __func__);
diff --git a/drivers/media/dvb-frontends/cxd2820r_c.c 
b/drivers/media/dvb-frontends/cxd2820r_c.c
index d2a0c28..125a440 100644
--- a/drivers/media/dvb-frontends/cxd2820r_c.c
+++ b/drivers/media/dvb-frontends/cxd2820r_c.c
@@ -50,11 +50,6 @@ int cxd2820r_set_frontend_c(struct dvb_frontend *fe)
dev_dbg(&priv->i2c->dev, "%s: frequency=%d symbol_rate=%d\n", __func__,
c->frequency, c->symbol_rate);
 
-   /* update GPIOs */
-   ret = cxd2820r_gpio(fe);
-   if (ret)
-   goto error;
-
/* program tuner */
if (fe->ops.tuner_ops.set_params)
fe->ops.tuner_ops.set_params(fe);
diff --git a/drivers/media/dvb-frontends/cxd2820r_core.c 
b/drivers/media/dvb-frontends/cxd2820r_core.c
index a3656ba..4bd42f2 100644
--- a/drivers/media/dvb-frontends/cxd2820r_core.c
+++ b/drivers/media/dvb-frontends/cxd2820r_core.c
@@ -168,30 +168,15 @@ int cxd2820r_wr_reg_mask(struct cxd2820r_priv *priv, u32 
reg, u8 val,
return cxd2820r_wr_reg(priv, reg, val);
 }
 
-int cxd2820r_gpio(struct dvb_frontend *fe)
+int cxd2820r_gpio(struct dvb_frontend *fe, u8 *gpio)
 {
struct cxd2820r_priv *priv = fe->demodulator_priv;
int ret, i;
-   u8 *gpio, tmp0, tmp1;
+   u8 tmp0, tmp1;
 
dev_dbg(&priv->i2c->dev, "%s: delsys=%d\n", __func__,
fe->dtv_property_cache.delivery_system);
 
-   switch (fe->dtv_property_cache.delivery_system) {
-   case SYS_DVBT:
-   gpio = priv->cfg.gpio_dvbt;
-   break;
-   case SYS_DVBT2:
-   gpio = priv->cfg.gpio_dvbt2;
-   break;
-   case SYS_DVBC_ANNEX_AC:
-   gpio = priv->cfg.gpio_dvbc;
-   break;
-   default:
-   ret = -EINVAL;
-   goto error;
-   }
-
/* update GPIOs only when needed */
if (!memcmp(gpio, priv->gpio, sizeof(priv->gpio)))
return 0;
@@ -582,9 +567,19 @@ static int cxd2820r_get_frontend_algo(struct dvb_frontend 
*fe)
 static void cxd2820r_release(struct dvb_frontend *fe)
 {
struct cxd2820r_priv *priv = fe->demodulator_priv;
+   int ret;
 
dev_dbg(&priv->i2c->dev, "%s\n", __func__);
 
+#ifdef CONFIG_GPIOLIB
+   /* remove GPIOs */
+   if (priv->gpio_chip.label) {
+   ret = gpiochip_remove(&priv->gpio_chip);
+   if (ret)
+   dev_err(&priv->i2c->dev, "%s: gpiochip_remove() " \
+   "failed=%d\n", KBUILD_MODNAME, ret);
+   }
+#endif
kfree(priv);
return;
 }
@@ -599,6 +594,49 @@ static int cxd2820r_i2c_gate_ctrl(struct dvb_frontend *fe, 
int enable)
return cxd2820r_wr_reg_mask(priv, 0xdb, enable ? 1 : 0, 0x1);
 }
 
+#ifdef CONFIG_GPIOLIB
+static int cxd2820r_gpio_direction_output(struct gpio_chip *chip, unsigned nr,
+   int val)
+{
+   struct cxd2820r_priv *priv =
+   container_of(chip, struct cxd2820r_priv, gpio_chip);
+   u8 gpio[GPIO_COUNT];
+
+   dev_dbg(&priv->i2c->dev, "%s: nr=%d val=%d\n", __func__, nr, val);
+
+   memcpy(gpio, priv->gpio, sizeof(gpio));
+   gpio[nr] = CXD2820R_GPIO_E | CXD2820R_GPIO_O | (val << 2);
+

[PATCH 5/6] cxd2820r: GPIO when GPIOLIB is undefined

2012-08-16 Thread Antti Palosaari 
Use static GPIO config when GPIOLIB is undefined.
It is fallback condition as GPIOLIB seems to be disabled by default.
Better solution is needed, maybe GPIOLIB could be enabled by default?

Signed-off-by: Antti Palosaari 
---
 drivers/media/dvb-frontends/cxd2820r_core.c | 29 -
 drivers/media/usb/em28xx/em28xx-dvb.c   |  2 ++
 2 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/drivers/media/dvb-frontends/cxd2820r_core.c 
b/drivers/media/dvb-frontends/cxd2820r_core.c
index 4bd42f2..4264864 100644
--- a/drivers/media/dvb-frontends/cxd2820r_core.c
+++ b/drivers/media/dvb-frontends/cxd2820r_core.c
@@ -567,7 +567,7 @@ static int cxd2820r_get_frontend_algo(struct dvb_frontend 
*fe)
 static void cxd2820r_release(struct dvb_frontend *fe)
 {
struct cxd2820r_priv *priv = fe->demodulator_priv;
-   int ret;
+   int uninitialized_var(ret); /* silence compiler warning */
 
dev_dbg(&priv->i2c->dev, "%s\n", __func__);
 
@@ -688,9 +688,9 @@ struct dvb_frontend *cxd2820r_attach(const struct 
cxd2820r_config *cfg,
 {
struct cxd2820r_priv *priv;
int ret;
-   u8 tmp;
+   u8 tmp, gpio[GPIO_COUNT];
 
-   priv = kzalloc(sizeof (struct cxd2820r_priv), GFP_KERNEL);
+   priv = kzalloc(sizeof(struct cxd2820r_priv), GFP_KERNEL);
if (!priv) {
ret = -ENOMEM;
dev_err(&i2c->dev, "%s: kzalloc() failed\n",
@@ -699,7 +699,9 @@ struct dvb_frontend *cxd2820r_attach(const struct 
cxd2820r_config *cfg,
}
 
priv->i2c = i2c;
-   memcpy(&priv->cfg, cfg, sizeof (struct cxd2820r_config));
+   memcpy(&priv->cfg, cfg, sizeof(struct cxd2820r_config));
+   memcpy(&priv->fe.ops, &cxd2820r_ops, sizeof(struct dvb_frontend_ops));
+   priv->fe.demodulator_priv = priv;
 
priv->bank[0] = priv->bank[1] = 0xff;
ret = cxd2820r_rd_reg(priv, 0x000fd, &tmp);
@@ -707,9 +709,9 @@ struct dvb_frontend *cxd2820r_attach(const struct 
cxd2820r_config *cfg,
if (ret || tmp != 0xe1)
goto error;
 
-#ifdef CONFIG_GPIOLIB
-   /* add GPIOs */
if (gpio_chip_base) {
+#ifdef CONFIG_GPIOLIB
+   /* add GPIOs */
priv->gpio_chip.label = KBUILD_MODNAME;
priv->gpio_chip.dev = &priv->i2c->dev;
priv->gpio_chip.owner = THIS_MODULE;
@@ -728,11 +730,20 @@ struct dvb_frontend *cxd2820r_attach(const struct 
cxd2820r_config *cfg,
priv->gpio_chip.base);
 
*gpio_chip_base = priv->gpio_chip.base;
-   }
+#else
+   /*
+* Use static GPIO configuration if GPIOLIB is undefined.
+* This is fallback condition.
+*/
+   gpio[0] = (*gpio_chip_base >> 0) & 0x07;
+   gpio[1] = (*gpio_chip_base >> 3) & 0x07;
+   gpio[2] = 0;
+   ret = cxd2820r_gpio(&priv->fe, gpio);
+   if (ret)
+   goto error;
 #endif
+   }
 
-   memcpy(&priv->fe.ops, &cxd2820r_ops, sizeof (struct dvb_frontend_ops));
-   priv->fe.demodulator_priv = priv;
return &priv->fe;
 error:
dev_dbg(&i2c->dev, "%s: failed=%d\n", __func__, ret);
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c 
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 75f907a..e0128b3 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -983,6 +983,8 @@ static int em28xx_dvb_init(struct em28xx *dev)
   &dev->i2c_adap, &kworld_a340_config);
break;
case EM28174_BOARD_PCTV_290E:
+   /* set default GPIO0 for LNA, used if GPIOLIB is undefined */
+   dvb->gpio = CXD2820R_GPIO_E | CXD2820R_GPIO_O | CXD2820R_GPIO_L;
dvb->fe[0] = dvb_attach(cxd2820r_attach,
&em28xx_cxd2820r_config,
&dev->i2c_adap,
-- 
1.7.11.2

--
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 4/6] em28xx: implement FE set_lna() callback

2012-08-16 Thread Antti Palosaari 
Make LNA run-time switching possible for PCTV nanoStick T2 290e!

Signed-off-by: Antti Palosaari 
---
 drivers/media/usb/em28xx/em28xx-dvb.c | 40 ++-
 1 file changed, 35 insertions(+), 5 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c 
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 34c5ea9..75f907a 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -81,6 +81,7 @@ struct em28xx_dvb {
int (*gate_ctrl)(struct dvb_frontend *, int);
struct semaphore  pll_mutex;
booldont_attach_fe1;
+   int gpio;
 };
 
 
@@ -568,6 +569,33 @@ static void pctv_520e_init(struct em28xx *dev)
i2c_master_send(&dev->i2c_client, regs[i].r, regs[i].len);
 };
 
+static int em28xx_pctv_290e_set_lna(struct dvb_frontend *fe, int val)
+{
+   struct em28xx *dev = fe->dvb->priv;
+#ifdef CONFIG_GPIOLIB
+   struct em28xx_dvb *dvb = dev->dvb;
+   int ret;
+   unsigned long flags;
+
+   if (val)
+   flags = GPIOF_OUT_INIT_LOW;
+   else
+   flags = GPIOF_OUT_INIT_HIGH;
+
+   ret = gpio_request_one(dvb->gpio, flags, NULL);
+   if (ret)
+   em28xx_errdev("gpio request failed %d\n", ret);
+   else
+   gpio_free(dvb->gpio);
+
+   return ret;
+#else
+   dev_warn(&dev->udev->dev, "%s: LNA control is disabled\n",
+   KBUILD_MODNAME);
+   return 0;
+#endif
+}
+
 static int em28xx_mt352_terratec_xs_init(struct dvb_frontend *fe)
 {
/* Values extracted from a USB trace of the Terratec Windows driver */
@@ -809,7 +837,7 @@ static void em28xx_unregister_dvb(struct em28xx_dvb *dvb)
 
 static int em28xx_dvb_init(struct em28xx *dev)
 {
-   int result = 0, mfe_shared = 0, gpio_chip_base;
+   int result = 0, mfe_shared = 0;
struct em28xx_dvb *dvb;
 
if (!dev->board.has_dvb) {
@@ -958,7 +986,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
dvb->fe[0] = dvb_attach(cxd2820r_attach,
&em28xx_cxd2820r_config,
&dev->i2c_adap,
-   &gpio_chip_base);
+   &dvb->gpio);
if (dvb->fe[0]) {
/* FE 0 attach tuner */
if (!dvb_attach(tda18271_attach,
@@ -973,15 +1001,17 @@ static int em28xx_dvb_init(struct em28xx *dev)
}
}
 
+#ifdef CONFIG_GPIOLIB
/* enable LNA for DVB-T, DVB-T2 and DVB-C */
-   result = gpio_request_one(gpio_chip_base, GPIOF_INIT_LOW,
-   "LNA");
+   result = gpio_request_one(dvb->gpio, GPIOF_OUT_INIT_LOW, NULL);
if (result)
em28xx_errdev("gpio request failed %d\n", result);
else
-   gpio_free(gpio_chip_base);
+   gpio_free(dvb->gpio);
 
result = 0; /* continue even set LNA fails */
+#endif
+   dvb->fe[0]->ops.set_lna = em28xx_pctv_290e_set_lna;
break;
case EM2884_BOARD_HAUPPAUGE_WINTV_HVR_930C:
{
-- 
1.7.11.2

--
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/6] cxd2820r: switch to Kernel dev_* logging

2012-08-16 Thread Antti Palosaari 
Signed-off-by: Antti Palosaari 
---
 drivers/media/dvb-frontends/cxd2820r_c.c| 26 -
 drivers/media/dvb-frontends/cxd2820r_core.c | 84 -
 drivers/media/dvb-frontends/cxd2820r_priv.h | 13 -
 drivers/media/dvb-frontends/cxd2820r_t.c| 28 +-
 drivers/media/dvb-frontends/cxd2820r_t2.c   | 26 -
 5 files changed, 101 insertions(+), 76 deletions(-)

diff --git a/drivers/media/dvb-frontends/cxd2820r_c.c 
b/drivers/media/dvb-frontends/cxd2820r_c.c
index ed3b0ba6..d2a0c28 100644
--- a/drivers/media/dvb-frontends/cxd2820r_c.c
+++ b/drivers/media/dvb-frontends/cxd2820r_c.c
@@ -47,7 +47,8 @@ int cxd2820r_set_frontend_c(struct dvb_frontend *fe)
{ 0x10070, priv->cfg.ts_mode, 0xff },
};
 
-   dbg("%s: RF=%d SR=%d", __func__, c->frequency, c->symbol_rate);
+   dev_dbg(&priv->i2c->dev, "%s: frequency=%d symbol_rate=%d\n", __func__,
+   c->frequency, c->symbol_rate);
 
/* update GPIOs */
ret = cxd2820r_gpio(fe);
@@ -78,7 +79,7 @@ int cxd2820r_set_frontend_c(struct dvb_frontend *fe)
} else
if_freq = 0;
 
-   dbg("%s: if_freq=%d", __func__, if_freq);
+   dev_dbg(&priv->i2c->dev, "%s: if_freq=%d\n", __func__, if_freq);
 
num = if_freq / 1000; /* Hz => kHz */
num *= 0x4000;
@@ -100,7 +101,7 @@ int cxd2820r_set_frontend_c(struct dvb_frontend *fe)
 
return ret;
 error:
-   dbg("%s: failed:%d", __func__, ret);
+   dev_dbg(&priv->i2c->dev, "%s: failed=%d\n", __func__, ret);
return ret;
 }
 
@@ -150,7 +151,7 @@ int cxd2820r_get_frontend_c(struct dvb_frontend *fe)
 
return ret;
 error:
-   dbg("%s: failed:%d", __func__, ret);
+   dev_dbg(&priv->i2c->dev, "%s: failed=%d\n", __func__, ret);
return ret;
 }
 
@@ -184,7 +185,7 @@ int cxd2820r_read_ber_c(struct dvb_frontend *fe, u32 *ber)
 
return ret;
 error:
-   dbg("%s: failed:%d", __func__, ret);
+   dev_dbg(&priv->i2c->dev, "%s: failed=%d\n", __func__, ret);
return ret;
 }
 
@@ -214,7 +215,7 @@ int cxd2820r_read_signal_strength_c(struct dvb_frontend *fe,
 
return ret;
 error:
-   dbg("%s: failed:%d", __func__, ret);
+   dev_dbg(&priv->i2c->dev, "%s: failed=%d\n", __func__, ret);
return ret;
 }
 
@@ -251,7 +252,7 @@ int cxd2820r_read_snr_c(struct dvb_frontend *fe, u16 *snr)
 
return ret;
 error:
-   dbg("%s: failed:%d", __func__, ret);
+   dev_dbg(&priv->i2c->dev, "%s: failed=%d\n", __func__, ret);
return ret;
 }
 
@@ -283,11 +284,12 @@ int cxd2820r_read_status_c(struct dvb_frontend *fe, 
fe_status_t *status)
}
}
 
-   dbg("%s: lock=%02x %02x", __func__, buf[0], buf[1]);
+   dev_dbg(&priv->i2c->dev, "%s: lock=%02x %02x\n", __func__, buf[0],
+   buf[1]);
 
return ret;
 error:
-   dbg("%s: failed:%d", __func__, ret);
+   dev_dbg(&priv->i2c->dev, "%s: failed=%d\n", __func__, ret);
return ret;
 }
 
@@ -302,7 +304,7 @@ int cxd2820r_init_c(struct dvb_frontend *fe)
 
return ret;
 error:
-   dbg("%s: failed:%d", __func__, ret);
+   dev_dbg(&priv->i2c->dev, "%s: failed=%d\n", __func__, ret);
return ret;
 }
 
@@ -318,7 +320,7 @@ int cxd2820r_sleep_c(struct dvb_frontend *fe)
{ 0x00080, 0x00, 0xff },
};
 
-   dbg("%s", __func__);
+   dev_dbg(&priv->i2c->dev, "%s\n", __func__);
 
priv->delivery_system = SYS_UNDEFINED;
 
@@ -331,7 +333,7 @@ int cxd2820r_sleep_c(struct dvb_frontend *fe)
 
return ret;
 error:
-   dbg("%s: failed:%d", __func__, ret);
+   dev_dbg(&priv->i2c->dev, "%s: failed=%d\n", __func__, ret);
return ret;
 }
 
diff --git a/drivers/media/dvb-frontends/cxd2820r_core.c 
b/drivers/media/dvb-frontends/cxd2820r_core.c
index 3bba37d..a3656ba 100644
--- a/drivers/media/dvb-frontends/cxd2820r_core.c
+++ b/drivers/media/dvb-frontends/cxd2820r_core.c
@@ -21,10 +21,6 @@
 
 #include "cxd2820r_priv.h"
 
-int cxd2820r_debug;
-module_param_named(debug, cxd2820r_debug, int, 0644);
-MODULE_PARM_DESC(debug, "Turn on/off frontend debugging (default:off).");
-
 /* write multiple registers */
 static int cxd2820r_wr_regs_i2c(struct cxd2820r_priv *priv, u8 i2c, u8 reg,
u8 *val, int len)
@@ -47,7 +43,8 @@ static int cxd2820r_wr_regs_i2c(struct cxd2820r_priv *priv, 
u8 i2c, u8 reg,
if (ret == 1) {
ret = 0;
} else {
-   warn("i2c wr failed ret:%d reg:%02x len:%d", ret, reg, len);
+   dev_warn(&priv->i2c->dev, "%s: i2c wr failed=%d reg=%02x " \
+   "len=%d\n", KBUILD_MODNAME, ret, reg, len);
ret = -EREMOTEIO;
}
return ret;
@@ -78,7 +75,8 @@ static int cxd2820r_rd_regs_i2c(struct cxd2820r_priv *priv, 
u8 i2c, u8 reg,
memcpy(val, buf, len);
ret = 0;
} else {
-   warn("i2c rd failed ret:

[PATCH 1/6] add LNA support for DVB API

2012-08-16 Thread Antti Palosaari 
Signed-off-by: Antti Palosaari 
---
 drivers/media/dvb-core/dvb_frontend.c | 5 +
 drivers/media/dvb-core/dvb_frontend.h | 1 +
 include/linux/dvb/frontend.h  | 4 +++-
 include/linux/dvb/version.h   | 2 +-
 4 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb-core/dvb_frontend.c 
b/drivers/media/dvb-core/dvb_frontend.c
index 7d079fb..d29d41a 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -1023,6 +1023,7 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND + 1] = {
 
_DTV_CMD(DTV_ISDBS_TS_ID, 1, 0),
_DTV_CMD(DTV_DVBT2_PLP_ID, 1, 0),
+   _DTV_CMD(DTV_LNA, 1, 0),
 
/* Get */
_DTV_CMD(DTV_DISEQC_SLAVE_REPLY, 0, 1),
@@ -1731,6 +1732,10 @@ static int dtv_property_process_set(struct dvb_frontend 
*fe,
case DTV_INTERLEAVING:
c->interleaving = tvp->u.data;
break;
+   case DTV_LNA:
+   if (fe->ops.set_lna)
+   r = fe->ops.set_lna(fe, tvp->u.data);
+   break;
 
/* ISDB-T Support here */
case DTV_ISDBT_PARTIAL_RECEPTION:
diff --git a/drivers/media/dvb-core/dvb_frontend.h 
b/drivers/media/dvb-core/dvb_frontend.h
index db309db..74ba563 100644
--- a/drivers/media/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb-core/dvb_frontend.h
@@ -303,6 +303,7 @@ struct dvb_frontend_ops {
int (*dishnetwork_send_legacy_command)(struct dvb_frontend* fe, 
unsigned long cmd);
int (*i2c_gate_ctrl)(struct dvb_frontend* fe, int enable);
int (*ts_bus_ctrl)(struct dvb_frontend* fe, int acquire);
+   int (*set_lna)(struct dvb_frontend *, int);
 
/* These callbacks are for devices that implement their own
 * tuning algorithms, rather than a simple swzigzag
diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
index bb51edf..4098021 100644
--- a/include/linux/dvb/frontend.h
+++ b/include/linux/dvb/frontend.h
@@ -362,8 +362,9 @@ struct dvb_frontend_event {
 #define DTV_ATSCMH_SCCC_CODE_MODE_D59
 
 #define DTV_INTERLEAVING   60
+#define DTV_LNA61
 
-#define DTV_MAX_COMMANDDTV_INTERLEAVING
+#define DTV_MAX_COMMANDDTV_LNA
 
 typedef enum fe_pilot {
PILOT_ON,
@@ -436,6 +437,7 @@ enum atscmh_rs_code_mode {
ATSCMH_RSCODE_RES= 3,
 };
 
+#define LNA_AUTO INT_MIN
 
 struct dtv_cmds_h {
char*name;  /* A display name for debugging purposes */
diff --git a/include/linux/dvb/version.h b/include/linux/dvb/version.h
index 70c2c7e..20e5eac 100644
--- a/include/linux/dvb/version.h
+++ b/include/linux/dvb/version.h
@@ -24,6 +24,6 @@
 #define _DVBVERSION_H_
 
 #define DVB_API_VERSION 5
-#define DVB_API_VERSION_MINOR 7
+#define DVB_API_VERSION_MINOR 8
 
 #endif /*_DVBVERSION_H_*/
-- 
1.7.11.2

--
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 0/6] DVB API LNA

2012-08-16 Thread Antti Palosaari 
LNA API and one implementation as for example. 

Implementation relies Kernel GPIOLIB as LNAs are typically controlled
by GPIO. Anyhow, GPIOLIB seems to be disabled by default thus I was
forced to add some glue macros to handle situation where GPIOLIB is
not available. But lets try to found out solution / reason later for
that GPIOLIB part.

Antti Palosaari (6):
  add LNA support for DVB API
  cxd2820r: switch to Kernel dev_* logging
  cxd2820r: use Kernel GPIO for GPIO access
  em28xx: implement FE set_lna() callback
  cxd2820r: use static GPIO config when GPIOLIB is undefined
  DVB API: LNA documentation

 Documentation/DocBook/media/dvb/dvbproperty.xml |  16 ++
 drivers/media/dvb-core/dvb_frontend.c   |   5 +
 drivers/media/dvb-core/dvb_frontend.h   |   1 +
 drivers/media/dvb-frontends/cxd2820r.h  |  14 +-
 drivers/media/dvb-frontends/cxd2820r_c.c|  31 ++--
 drivers/media/dvb-frontends/cxd2820r_core.c | 211 ++--
 drivers/media/dvb-frontends/cxd2820r_priv.h |  22 +--
 drivers/media/dvb-frontends/cxd2820r_t.c|  33 ++--
 drivers/media/dvb-frontends/cxd2820r_t2.c   |  31 ++--
 drivers/media/usb/dvb-usb-v2/anysee.c   |   2 +-
 drivers/media/usb/em28xx/em28xx-dvb.c   |  51 +-
 include/linux/dvb/frontend.h|   4 +-
 include/linux/dvb/version.h |   2 +-
 13 files changed, 287 insertions(+), 136 deletions(-)

-- 
1.7.11.2

--
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 0/5] Generic panel framework

2012-08-16 Thread Jingoo Han 
On Friday, August 17, 2012 9:50 AM Laurent Pinchart wrote:
> 
> Hi everybody,
> 
> While working on DT bindings for the Renesas Mobile SoC display controller
> (a.k.a. LCDC) I quickly realized that display panel implementation based on
> board code callbacks would need to be replaced by a driver-based panel
> framework.
> 
> Several driver-based panel support solution already exist in the kernel.
> 
> - The LCD device class is implemented in drivers/video/backlight/lcd.c and
>   exposes a kernel API in include/linux/lcd.h. That API is tied to the FBDEV
>   API for historical reason, uses board code callback for reset and power
>   management, and doesn't include support for standard features available in
>   today's "smart panels".
> 
> - OMAP2+ based systems use custom panel drivers available in
>   drivers/video/omap2/displays. Those drivers are based on OMAP DSS (display
>   controller) specific APIs.
> 
> - Similarly, Exynos based systems use custom panel drivers available in
>   drivers/video/exynos. Only a single driver (s6e8ax0) is currently available.
>   That driver is based on Exynos display controller specific APIs and on the
>   LCD device class API.
> 

Hi Laurent,

I am a Exynos DP maintainer and Samsung FB maintainer.

Actually, eDP (embedded display port) will be faced with this kind of problem.
According to the eDP standard, eDP panel can have their own specific registers
that handle extra operations. In this case, custom panel driver for this eDP 
panel
will be necessary.

In my opinion, the panel framework would be helpful to solve this problem.


Best regards,
Jingoo Han


> I've brought up the issue with Tomi Valkeinen (OMAP DSS maintainer) and Marcus
> Lorentzon (working on panel support for ST/Linaro), and we agreed that a
> generic panel framework for display devices is needed. These patches implement
> a first proof of concept.
> 
> One of the main reasons for creating a new panel framework instead of adding
> missing features to the LCD framework is to avoid being tied to the FBDEV
> framework. Panels will be used by DRM drivers as well, and their API should
> thus be subsystem-agnostic. Note that the panel framework used the
> fb_videomode structure in its API, this will be replaced by a common video
> mode structure shared across subsystems (there's only so many hours per day).
> 
> Panels, as used in these patches, are defined as physical devices combining a
> matrix of pixels and a controller capable of driving that matrix.
> 
> Panel physical devices are registered as children of the control bus the panel
> controller is connected to (depending on the panel type, we can find platform
> devices for dummy panels with no control bus, or I2C, SPI, DBI, DSI, ...
> devices). The generic panel framework matches registered panel devices with
> panel drivers and call the panel drivers probe method, as done by other device
> classes in the kernel. The driver probe() method is responsible for
> instantiating a struct panel instance and registering it with the generic
> panel framework.
> 
> Display drivers are panel consumers. They register a panel notifier with the
> framework, which then calls the notifier when a matching panel is registered.
> The reason for this asynchronous mode of operation, compared to how drivers
> acquire regulator or clock resources, is that the panel can use resources
> provided by the display driver. For instance a panel can be a child of the DBI
> or DSI bus controlled by the display device, or use a clock provided by that
> device. We can't defer the display device probe until the panel is registered
> and also defer the panel device probe until the display is registered. As
> most display drivers need to handle output devices hotplug (HDMI monitors for
> instance), handling panel through a notification system seemed to be the
> easiest solution.
> 
> Note that this brings a different issue after registration, as display and
> panel drivers would take a reference to each other. Those circular references
> would make driver unloading impossible. I haven't found a good solution for
> that problem yet (hence the RFC state of those patches), and I would
> appreciate your input here. This might also be a hint that the framework
> design is wrong to start with. I guess I can't get everything right on the
> first try ;-)
> 
> Getting hold of the panel is the most complex part. Once done, display drivers
> can call abstract operations provided by panel drivers to control the panel
> operation. These patches implement three of those operations (enable, start
> transfer and get modes). More operations will be needed, and those three
> operations will likely get modified during review. Most of the panels on
> devices I own are dumb panels with no control bus, and are thus not the best
> candidates to design a framework that needs to take complex panels' needs into
> account.
> 
> In addition to the generic panel core, I've implemented MIPI DBI (Display Bus
> Interfac

Re: [PATCH] dvb_frontend: Multistream support

2012-08-16 Thread Akihiro TSUKADA 
Hi,

> diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.h 
> b/drivers/media/dvb/dvb-core/dvb_frontend.h
> index 7c64c09..bec0cda 100644
> --- a/drivers/media/dvb/dvb-core/dvb_frontend.h
> +++ b/drivers/media/dvb/dvb-core/dvb_frontend.h
> @@ -368,11 +368,8 @@ struct dtv_frontend_properties {
>  u8 interleaving;
>  } layer[3];
> 
> - /* ISDB-T specifics */
> - u32 isdbs_ts_id;
> -
> - /* DVB-T2 specifics */
> - u32 dvbt2_plp_id;
> + /* Multistream specifics */
> + u32 stream_id;
> 
>  /* ATSC-MH specifics */
>  u8 atscmh_fic_ver;

It would be nice if you would include a patch to replace isdbs_ts_id
in dvb/pt1/va1j5jf8007s.c, which is the only file to use the variable.
--
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

[RFC 3/5] video: panel: Add MIPI DBI bus support

2012-08-16 Thread Laurent Pinchart 
Signed-off-by: Laurent Pinchart 
---
 drivers/video/panel/Kconfig |4 +
 drivers/video/panel/Makefile|1 +
 drivers/video/panel/panel-dbi.c |  217 +++
 include/video/panel-dbi.h   |   92 +
 4 files changed, 314 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/panel/panel-dbi.c
 create mode 100644 include/video/panel-dbi.h

diff --git a/drivers/video/panel/Kconfig b/drivers/video/panel/Kconfig
index 36fb9ca..fd0b3cf 100644
--- a/drivers/video/panel/Kconfig
+++ b/drivers/video/panel/Kconfig
@@ -12,4 +12,8 @@ config DISPLAY_PANEL_DUMMY
 
  If you are in doubt, say N.
 
+config DISPLAY_PANEL_DBI
+   tristate
+   default n
+
 endif # DISPLAY_PANEL
diff --git a/drivers/video/panel/Makefile b/drivers/video/panel/Makefile
index 9fc05c2..2ab0520 100644
--- a/drivers/video/panel/Makefile
+++ b/drivers/video/panel/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_DISPLAY_PANEL) += panel.o
 obj-$(CONFIG_DISPLAY_PANEL_DUMMY) += panel-dummy.o
+obj-$(CONFIG_DISPLAY_PANEL_DBI) += panel-dbi.o
diff --git a/drivers/video/panel/panel-dbi.c b/drivers/video/panel/panel-dbi.c
new file mode 100644
index 000..0511997
--- /dev/null
+++ b/drivers/video/panel/panel-dbi.c
@@ -0,0 +1,217 @@
+/*
+ * MIPI DBI Bus
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* 
-
+ * Bus operations
+ */
+
+void panel_dbi_write_command(struct panel_dbi_device *dev, unsigned long cmd)
+{
+   dev->bus->ops->write_command(dev->bus, cmd);
+}
+EXPORT_SYMBOL_GPL(panel_dbi_write_command);
+
+void panel_dbi_write_data(struct panel_dbi_device *dev, unsigned long data)
+{
+   dev->bus->ops->write_data(dev->bus, data);
+}
+EXPORT_SYMBOL_GPL(panel_dbi_write_data);
+
+unsigned long panel_dbi_read_data(struct panel_dbi_device *dev)
+{
+   return dev->bus->ops->read_data(dev->bus);
+}
+EXPORT_SYMBOL_GPL(panel_dbi_read_data);
+
+/* 
-
+ * Bus type
+ */
+
+static const struct panel_dbi_device_id *
+panel_dbi_match_id(const struct panel_dbi_device_id *id,
+  struct panel_dbi_device *dev)
+{
+   while (id->name[0]) {
+   if (strcmp(dev->name, id->name) == 0) {
+   dev->id_entry = id;
+   return id;
+   }
+   id++;
+   }
+   return NULL;
+}
+
+static int panel_dbi_match(struct device *_dev, struct device_driver *_drv)
+{
+   struct panel_dbi_device *dev = to_panel_dbi_device(_dev);
+   struct panel_dbi_driver *drv = to_panel_dbi_driver(_drv);
+
+   if (drv->id_table)
+   return panel_dbi_match_id(drv->id_table, dev) != NULL;
+
+   return (strcmp(dev->name, _drv->name) == 0);
+}
+
+static ssize_t modalias_show(struct device *_dev, struct device_attribute *a,
+char *buf)
+{
+   struct panel_dbi_device *dev = to_panel_dbi_device(_dev);
+   int len = snprintf(buf, PAGE_SIZE, PANEL_DBI_MODULE_PREFIX "%s\n",
+  dev->name);
+
+   return (len >= PAGE_SIZE) ? (PAGE_SIZE - 1) : len;
+}
+
+static struct device_attribute panel_dbi_dev_attrs[] = {
+   __ATTR_RO(modalias),
+   __ATTR_NULL,
+};
+
+static int panel_dbi_uevent(struct device *_dev, struct kobj_uevent_env *env)
+{
+   struct panel_dbi_device *dev = to_panel_dbi_device(_dev);
+
+   add_uevent_var(env, "MODALIAS=%s%s", PANEL_DBI_MODULE_PREFIX,
+  dev->name);
+   return 0;
+}
+
+static const struct dev_pm_ops panel_dbi_dev_pm_ops = {
+   .runtime_suspend = pm_generic_runtime_suspend,
+   .runtime_resume = pm_generic_runtime_resume,
+   .runtime_idle = pm_generic_runtime_idle,
+   .suspend = pm_generic_suspend,
+   .resume = pm_generic_resume,
+   .freeze = pm_generic_freeze,
+   .thaw = pm_generic_thaw,
+   .poweroff = pm_generic_poweroff,
+   .restore = pm_generic_restore,
+};
+
+static struct bus_type panel_dbi_bus_type = {
+   .name   = "mipi-dbi",
+   .dev_attrs  = panel_dbi_dev_attrs,
+   .match  = panel_dbi_match,
+   .uevent = panel_dbi_uevent,
+   .pm = &panel_dbi_dev_pm_ops,
+};
+
+/* 
-
+ * Device and driver (un)registration
+ */
+
+/**
+ * panel_dbi_device_register - register a DBI device
+ * @dev: DBI device we're registering
+ */
+int panel_dbi_device_register(struct panel_dbi_device *dev,
+ stru

[RFC 5/5] video: panel: Add R61517 panel support

2012-08-16 Thread Laurent Pinchart 
The R61517 is a MIPI DBI panel controller from Renesas.

Signed-off-by: Laurent Pinchart 
---
 drivers/video/panel/Kconfig|9 +
 drivers/video/panel/Makefile   |1 +
 drivers/video/panel/panel-r61517.c |  408 
 include/video/panel-r61517.h   |   28 +++
 4 files changed, 446 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/panel/panel-r61517.c
 create mode 100644 include/video/panel-r61517.h

diff --git a/drivers/video/panel/Kconfig b/drivers/video/panel/Kconfig
index 12d7712..bd643be 100644
--- a/drivers/video/panel/Kconfig
+++ b/drivers/video/panel/Kconfig
@@ -25,4 +25,13 @@ config DISPLAY_PANEL_R61505
 
  If you are in doubt, say N.
 
+config DISPLAY_PANEL_R61517
+   tristate "Renesas R61517-based Display Panel"
+   select DISPLAY_PANEL_DBI
+   ---help---
+ Support panels based on the Renesas R61517 panel controller.
+ Those panels are controlled through a MIPI DBI interface.
+
+ If you are in doubt, say N.
+
 endif # DISPLAY_PANEL
diff --git a/drivers/video/panel/Makefile b/drivers/video/panel/Makefile
index e4fb9fe..3c11d26 100644
--- a/drivers/video/panel/Makefile
+++ b/drivers/video/panel/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_DISPLAY_PANEL) += panel.o
 obj-$(CONFIG_DISPLAY_PANEL_DUMMY) += panel-dummy.o
 obj-$(CONFIG_DISPLAY_PANEL_DBI) += panel-dbi.o
 obj-$(CONFIG_DISPLAY_PANEL_R61505) += panel-r61505.o
+obj-$(CONFIG_DISPLAY_PANEL_R61517) += panel-r61517.o
diff --git a/drivers/video/panel/panel-r61517.c 
b/drivers/video/panel/panel-r61517.c
new file mode 100644
index 000..6e8d933
--- /dev/null
+++ b/drivers/video/panel/panel-r61517.c
@@ -0,0 +1,408 @@
+/*
+ * Renesas R61517-based Display Panels
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ * Based on KFR2R09 LCD panel support
+ * Copyright (C) 2009 Magnus Damm
+ * Register settings based on the out-of-tree t33fb.c driver
+ * Copyright (C) 2008 Lineo Solutions, Inc.
+ *
+ * Contacts: Laurent Pinchart 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+struct r61517 {
+   struct panel panel;
+   struct panel_dbi_device *dbi;
+   const struct panel_r61517_platform_data *pdata;
+};
+
+#define to_panel(p)container_of(p, struct r61517, panel)
+
+/* 
-
+ * Read, write and reset
+ */
+
+static void r61517_write_command(struct r61517 *panel, u16 reg)
+{
+   panel_dbi_write_command(panel->dbi, reg);
+}
+
+static void r61517_write_data(struct r61517 *panel, u16 data)
+{
+   panel_dbi_write_data(panel->dbi, data);
+}
+
+static void r61517_write(struct r61517 *panel, u16 reg, u16 data)
+{
+   panel_dbi_write_command(panel->dbi, reg);
+   panel_dbi_write_data(panel->dbi, data);
+}
+
+static u16 r61517_read_data(struct r61517 *panel)
+{
+   return panel_dbi_read_data(panel->dbi);
+}
+
+static void __r61517_write_array(struct r61517 *panel, const u8 *data,
+unsigned int len)
+{
+   unsigned int i;
+
+   for (i = 0; i < len; ++i)
+   r61517_write_data(panel, data[i]);
+}
+
+#define r61517_write_array(p, a) \
+   __r61517_write_array(p, a, ARRAY_SIZE(a))
+
+static void r61517_reset(struct r61517 *panel)
+{
+   gpio_set_value(panel->pdata->protect, 0);   /* PROTECT/ -> L */
+   gpio_set_value(panel->pdata->reset, 0); /* LCD_RST/ -> L */
+   gpio_set_value(panel->pdata->protect, 1);   /* PROTECT/ -> H */
+   usleep_range(1100, 1200);
+   gpio_set_value(panel->pdata->reset, 1); /* LCD_RST/ -> H */
+   usleep_range(10, 100);
+   gpio_set_value(panel->pdata->protect, 0);   /* PROTECT/ -> L */
+   msleep(20);
+}
+
+/* 
-
+ * Configuration
+ */
+
+static const u8 data_frame_if[] = {
+   0x02, /* WEMODE: 1=cont, 0=one-shot */
+   0x00, 0x00,
+   0x00, /* EPF, DFM */
+   0x02, /* RIM[1] : 1 (18bpp) */
+};
+
+static const u8 data_panel[] = {
+   0x0b,
+   0x63, /* 400 lines */
+   0x04, 0x00, 0x00, 0x04, 0x11, 0x00, 0x00,
+};
+
+static const u8 data_timing[] = {
+   0x00, 0x00, 0x13, 0x08, 0x08,
+};
+
+static const u8 data_timing_src[] = {
+   0x11, 0x01, 0x00, 0x01,
+};
+
+static const u8 data_gamma[] = {
+   0x01, 0x02, 0x08, 0x23, 0x03, 0x0c, 0x00, 0x06, 0x00, 0x00,
+   0x01, 0x00, 0x0c, 0x23, 0x03, 0x08, 0x02, 0x06, 0x00, 0x00,
+};
+
+static const u8 data_power[] = {
+   0x07, 0xc5, 0xdc, 0x02, 0x33, 0x0a,
+};
+
+static unsigned long r61517_read_device_code(struct r61517 *panel)
+{
+   /* access protect OFF */
+   r61517_write(panel, 0xb0, 0x00);

[RFC 4/5] video: panel: Add R61505 panel support

2012-08-16 Thread Laurent Pinchart 
The R61505 is a SYS-80 bus panel controller from Renesas.

Signed-off-by: Laurent Pinchart 
---
 drivers/video/panel/Kconfig|9 +
 drivers/video/panel/Makefile   |1 +
 drivers/video/panel/panel-r61505.c |  520 
 include/video/panel-r61505.h   |   27 ++
 4 files changed, 557 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/panel/panel-r61505.c
 create mode 100644 include/video/panel-r61505.h

diff --git a/drivers/video/panel/Kconfig b/drivers/video/panel/Kconfig
index fd0b3cf..12d7712 100644
--- a/drivers/video/panel/Kconfig
+++ b/drivers/video/panel/Kconfig
@@ -16,4 +16,13 @@ config DISPLAY_PANEL_DBI
tristate
default n
 
+config DISPLAY_PANEL_R61505
+   tristate "Renesas R61505-based Display Panel"
+   select DISPLAY_PANEL_DBI
+   ---help---
+ Support panels based on the Renesas R61505 panel controller.
+ Those panels are controlled through a MIPI DBI interface.
+
+ If you are in doubt, say N.
+
 endif # DISPLAY_PANEL
diff --git a/drivers/video/panel/Makefile b/drivers/video/panel/Makefile
index 2ab0520..e4fb9fe 100644
--- a/drivers/video/panel/Makefile
+++ b/drivers/video/panel/Makefile
@@ -1,3 +1,4 @@
 obj-$(CONFIG_DISPLAY_PANEL) += panel.o
 obj-$(CONFIG_DISPLAY_PANEL_DUMMY) += panel-dummy.o
 obj-$(CONFIG_DISPLAY_PANEL_DBI) += panel-dbi.o
+obj-$(CONFIG_DISPLAY_PANEL_R61505) += panel-r61505.o
diff --git a/drivers/video/panel/panel-r61505.c 
b/drivers/video/panel/panel-r61505.c
new file mode 100644
index 000..e09455e
--- /dev/null
+++ b/drivers/video/panel/panel-r61505.c
@@ -0,0 +1,520 @@
+/*
+ * Renesas R61505-based Display Panels
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ * Based on SuperH MigoR Quarter VGA LCD Panel
+ * Copyright (C) 2008 Magnus Damm
+ * Based on lcd_powertip.c from Kenati Technologies Pvt Ltd.
+ * Copyright (c) 2007 Ujjwal Pande
+ *
+ * Contacts: Laurent Pinchart 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define R61505_DEVICE_CODE 0x
+#define R61505_DEVICE_CODE_VALUE   0x1505
+#define R61505_DRIVER_OUTPUT_CONTROL   0x0001
+#define R61505_DRIVER_OUTPUT_CONTROL_SM(1 << 10)
+#define R61505_DRIVER_OUTPUT_CONTROL_SS(1 << 8)
+#define R61505_LCD_WAVEFORM0x0002
+#define R61505_LCD_WAVEFORM_BC0(1 << 9)
+#define R61505_LCD_WAVEFORM_EOR(1 << 8)
+#define R61505_ENTRY_MODE  0x0003
+#define R61505_ENTRY_MODE_TRIREG   (1 << 15)
+#define R61505_ENTRY_MODE_DFM  (1 << 14)
+#define R61505_ENTRY_MODE_BGR  (1 << 12)
+#define R61505_ENTRY_MODE_HWM  (1 << 9)
+#define R61505_ENTRY_MODE_ORG  (1 << 7)
+#define R61505_ENTRY_MODE_ID1  (1 << 5)
+#define R61505_ENTRY_MODE_ID0  (1 << 4)
+#define R61505_ENTRY_MODE_AM   (1 << 3)
+#define R61505_RESIZE_CONTROL  0x0004
+#define R61505_RESIZE_CONTROL_RCV(n)   (((n) & 3) << 8)
+#define R61505_RESIZE_CONTROL_RCH(n)   (((n) & 3) << 4)
+#define R61505_RESIZE_CONTROL_RSZ_4(3 << 0)
+#define R61505_RESIZE_CONTROL_RSZ_2(1 << 0)
+#define R61505_RESIZE_CONTROL_RSZ_1(0 << 0)
+#define R61505_DISPLAY_CONTROL10x0007
+#define R61505_DISPLAY_CONTROL1_PTDE1  (1 << 13)
+#define R61505_DISPLAY_CONTROL1_PTDE0  (1 << 12)
+#define R61505_DISPLAY_CONTROL1_BASEE  (1 << 8)
+#define R61505_DISPLAY_CONTROL1_VON(1 << 6)
+#define R61505_DISPLAY_CONTROL1_GON(1 << 5)
+#define R61505_DISPLAY_CONTROL1_DTE(1 << 4)
+#define R61505_DISPLAY_CONTROL1_COL(1 << 3)
+#define R61505_DISPLAY_CONTROL1_D1 (1 << 1)
+#define R61505_DISPLAY_CONTROL1_D0 (1 << 0)
+#define R61505_DISPLAY_CONTROL20x0008
+#define R61505_DISPLAY_CONTROL2_FP(n)  (((n) & 0xf) << 8)
+#define R61505_DISPLAY_CONTROL2_BP(n)  (((n) & 0xf) << 0)
+#define R61505_DISPLAY_CONTROL30x0009
+#define R61505_DISPLAY_CONTROL3_PTS(n) (((n) & 7) << 8)
+#define R61505_DISPLAY_CONTROL3_PTG(n) (((n) & 3) << 3)
+#define R61505_DISPLAY_CONTROL3_ICS(n) (((n) & 0xf) << 0)
+#define R61505_DISPLAY_CONTROL40x000a
+#define R61505_DISPLAY_CONTROL4_FMARKOE(1 << 3)
+#define R61505_DISPLAY_CONTROL4_FMI_6  (5 << 0)
+#define R61505_DISPLAY_CONTROL4_FMI_4  (3 << 0)
+#define R61505_DISPLAY_CONTROL4_FMI_2  (1 << 0)
+#define R61505_DISPLAY_CONTROL4_FMI_1  (0 << 0)
+#define

[RFC 1/5] video: Add generic display panel core

2012-08-16 Thread Laurent Pinchart 
Signed-off-by: Laurent Pinchart 
---
 drivers/video/Kconfig|1 +
 drivers/video/Makefile   |1 +
 drivers/video/panel/Kconfig  |4 +
 drivers/video/panel/Makefile |1 +
 drivers/video/panel/panel.c  |  269 ++
 include/video/panel.h|  111 +
 6 files changed, 387 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/panel/Kconfig
 create mode 100644 drivers/video/panel/Makefile
 create mode 100644 drivers/video/panel/panel.c
 create mode 100644 include/video/panel.h

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 0217f74..2cc394e 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2448,6 +2448,7 @@ source "drivers/video/omap/Kconfig"
 source "drivers/video/omap2/Kconfig"
 source "drivers/video/exynos/Kconfig"
 source "drivers/video/backlight/Kconfig"
+source "drivers/video/panel/Kconfig"
 
 if VT
source "drivers/video/console/Kconfig"
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index ee8dafb..577240c 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -14,6 +14,7 @@ fb-objs   := $(fb-y)
 obj-$(CONFIG_VT) += console/
 obj-$(CONFIG_LOGO)   += logo/
 obj-y+= backlight/
+obj-y+= panel/
 
 obj-$(CONFIG_EXYNOS_VIDEO) += exynos/
 
diff --git a/drivers/video/panel/Kconfig b/drivers/video/panel/Kconfig
new file mode 100644
index 000..26b1787
--- /dev/null
+++ b/drivers/video/panel/Kconfig
@@ -0,0 +1,4 @@
+menuconfig DISPLAY_PANEL
+   tristate "Display Panel"
+   ---help---
+ Support for display panels for graphics devices.
diff --git a/drivers/video/panel/Makefile b/drivers/video/panel/Makefile
new file mode 100644
index 000..cf5c5e2
--- /dev/null
+++ b/drivers/video/panel/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_DISPLAY_PANEL) += panel.o
diff --git a/drivers/video/panel/panel.c b/drivers/video/panel/panel.c
new file mode 100644
index 000..cfca804
--- /dev/null
+++ b/drivers/video/panel/panel.c
@@ -0,0 +1,269 @@
+/*
+ * Display Panel
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static LIST_HEAD(panel_list);
+static LIST_HEAD(panel_notifiers);
+static DEFINE_MUTEX(panel_mutex);
+
+/**
+ * panel_enable - Set the panel operation mode
+ * @panel: The panel
+ * @enable: Panel operation mode
+ *
+ * - PANEL_ENABLE_OFF turns the panel off completely, possibly including its
+ *   power supplies. Communication with a panel in that mode is not possible.
+ * - PANEL_ENABLE_BLANK turns the panel on but keep the output blanked. Full
+ *   communication with the panel is supported, including pixel data transfer.
+ * - PANEL_ENABLE_ON turns the whole panel on, including the output.
+ *
+ * Return 0 on success or a negative error code otherwise.
+ */
+int panel_enable(struct panel *panel, enum panel_enable_mode enable)
+{
+   int ret;
+
+   if (panel->enable == enable)
+   return 0;
+
+   if (!panel->ops || !panel->ops->enable)
+   return 0;
+
+   ret = panel->ops->enable(panel, enable);
+   if (ret < 0)
+   return ret;
+
+   panel->enable = enable;
+   return 0;
+}
+EXPORT_SYMBOL_GPL(panel_enable);
+
+/**
+ * panel_start_transfer - Start frame transfer
+ * @panel: The panel
+ *
+ * Make the panel ready to receive pixel data and start frame transfer. This
+ * operation can only be called if the panel is in BLANK or ON mode.
+ *
+ * Return 0 on success or a negative error code otherwise.
+ */
+int panel_start_transfer(struct panel *panel)
+{
+   if (!panel->ops || !panel->ops->start_transfer)
+   return 0;
+
+   return panel->ops->start_transfer(panel);
+}
+
+/**
+ * panel_get_modes - Get video modes supported by the panel
+ * @panel: The panel
+ * @modes: Pointer to an array of modes
+ *
+ * Fill the modes argument with a pointer to an array of video modes. The array
+ * is owned by the panel.
+ *
+ * Return the number of supported modes on success (including 0 if no mode is
+ * supported) or a negative error code otherwise.
+ */
+int panel_get_modes(struct panel *panel, const struct fb_videomode **modes)
+{
+   if (!panel->ops || !panel->ops->get_modes)
+   return 0;
+
+   return panel->ops->get_modes(panel, modes);
+}
+EXPORT_SYMBOL_GPL(panel_get_modes);
+
+static void panel_release(struct kref *ref)
+{
+   struct panel *panel = container_of(ref, struct panel, ref);
+
+   if (panel->release)
+   panel->release(panel);
+}
+
+/**
+ * panel_get - get a reference to a panel
+ * @panel: the panel
+ *
+ *

[RFC 2/5] video: panel: Add dummy panel support

2012-08-16 Thread Laurent Pinchart 
Signed-off-by: Laurent Pinchart 
---
 drivers/video/panel/Kconfig   |   11 
 drivers/video/panel/Makefile  |1 +
 drivers/video/panel/panel-dummy.c |  103 +
 include/video/panel-dummy.h   |   25 +
 4 files changed, 140 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/panel/panel-dummy.c
 create mode 100644 include/video/panel-dummy.h

diff --git a/drivers/video/panel/Kconfig b/drivers/video/panel/Kconfig
index 26b1787..36fb9ca 100644
--- a/drivers/video/panel/Kconfig
+++ b/drivers/video/panel/Kconfig
@@ -2,3 +2,14 @@ menuconfig DISPLAY_PANEL
tristate "Display Panel"
---help---
  Support for display panels for graphics devices.
+
+if DISPLAY_PANEL
+
+config DISPLAY_PANEL_DUMMY
+   tristate "Dummy Display Panel"
+   ---help---
+ Support dummy panels with no control bus.
+
+ If you are in doubt, say N.
+
+endif # DISPLAY_PANEL
diff --git a/drivers/video/panel/Makefile b/drivers/video/panel/Makefile
index cf5c5e2..9fc05c2 100644
--- a/drivers/video/panel/Makefile
+++ b/drivers/video/panel/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_DISPLAY_PANEL) += panel.o
+obj-$(CONFIG_DISPLAY_PANEL_DUMMY) += panel-dummy.o
diff --git a/drivers/video/panel/panel-dummy.c 
b/drivers/video/panel/panel-dummy.c
new file mode 100644
index 000..9ba1447
--- /dev/null
+++ b/drivers/video/panel/panel-dummy.c
@@ -0,0 +1,103 @@
+/*
+ * Dummy Display Panel
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+
+#include 
+
+struct panel_dummy {
+   struct panel panel;
+   const struct panel_dummy_platform_data *pdata;
+};
+
+#define to_panel_dummy(p)  container_of(p, struct panel_dummy, panel)
+
+static int panel_dummy_get_modes(struct panel *p,
+const struct fb_videomode **modes)
+{
+   struct panel_dummy *panel = to_panel_dummy(p);
+
+   *modes = panel->pdata->mode;
+   return 1;
+}
+
+static const struct panel_ops panel_dummy_ops = {
+   .get_modes = panel_dummy_get_modes,
+};
+
+static void panel_dummy_release(struct panel *p)
+{
+   struct panel_dummy *panel = to_panel_dummy(p);
+
+   kfree(panel);
+}
+
+static int panel_dummy_remove(struct platform_device *pdev)
+{
+   struct panel_dummy *panel = platform_get_drvdata(pdev);
+
+   platform_set_drvdata(pdev, NULL);
+   panel_unregister(&panel->panel);
+
+   return 0;
+}
+
+static int __devinit panel_dummy_probe(struct platform_device *pdev)
+{
+   const struct panel_dummy_platform_data *pdata = pdev->dev.platform_data;
+   struct panel_dummy *panel;
+   int ret;
+
+   if (pdata == NULL)
+   return -ENODEV;
+
+   panel = kzalloc(sizeof(*panel), GFP_KERNEL);
+   if (panel == NULL)
+   return -ENOMEM;
+
+   panel->pdata = pdata;
+   panel->panel.dev = &pdev->dev;
+   panel->panel.release = panel_dummy_release;
+   panel->panel.ops = &panel_dummy_ops;
+   panel->panel.width = pdata->width;
+   panel->panel.height = pdata->height;
+
+   ret = panel_register(&panel->panel);
+   if (ret < 0) {
+   kfree(panel);
+   return ret;
+   }
+
+   platform_set_drvdata(pdev, panel);
+
+   return 0;
+}
+
+static const struct dev_pm_ops panel_dummy_dev_pm_ops = {
+};
+
+static struct platform_driver panel_dummy_driver = {
+   .probe = panel_dummy_probe,
+   .remove = panel_dummy_remove,
+   .driver = {
+   .name = "panel_dummy",
+   .owner = THIS_MODULE,
+   .pm = &panel_dummy_dev_pm_ops,
+   },
+};
+
+module_platform_driver(panel_dummy_driver);
+
+MODULE_AUTHOR("Laurent Pinchart ");
+MODULE_DESCRIPTION("Dummy Display Panel");
+MODULE_LICENSE("GPL");
diff --git a/include/video/panel-dummy.h b/include/video/panel-dummy.h
new file mode 100644
index 000..558a297
--- /dev/null
+++ b/include/video/panel-dummy.h
@@ -0,0 +1,25 @@
+/*
+ * Dummy Display Panel
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __PANEL_DUMMY_H__
+#define __PANEL_DUMMY_H__
+
+#include 
+#include 
+
+struct panel_dummy_platform_data {
+   unsigned long width;/* Panel width in mm */
+   unsigned long height;   /* Panel height in mm */
+   const struct fb_videomode *mode;
+};
+
+#endif /* __PANEL_DUMMY_H__ */
-- 
1.7.8.6

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.k

[RFC 0/5] Generic panel framework

2012-08-16 Thread Laurent Pinchart 
Hi everybody,

While working on DT bindings for the Renesas Mobile SoC display controller
(a.k.a. LCDC) I quickly realized that display panel implementation based on
board code callbacks would need to be replaced by a driver-based panel
framework.

Several driver-based panel support solution already exist in the kernel.

- The LCD device class is implemented in drivers/video/backlight/lcd.c and
  exposes a kernel API in include/linux/lcd.h. That API is tied to the FBDEV
  API for historical reason, uses board code callback for reset and power
  management, and doesn't include support for standard features available in
  today's "smart panels".

- OMAP2+ based systems use custom panel drivers available in
  drivers/video/omap2/displays. Those drivers are based on OMAP DSS (display
  controller) specific APIs.

- Similarly, Exynos based systems use custom panel drivers available in
  drivers/video/exynos. Only a single driver (s6e8ax0) is currently available.
  That driver is based on Exynos display controller specific APIs and on the
  LCD device class API.

I've brought up the issue with Tomi Valkeinen (OMAP DSS maintainer) and Marcus
Lorentzon (working on panel support for ST/Linaro), and we agreed that a
generic panel framework for display devices is needed. These patches implement
a first proof of concept.

One of the main reasons for creating a new panel framework instead of adding
missing features to the LCD framework is to avoid being tied to the FBDEV
framework. Panels will be used by DRM drivers as well, and their API should
thus be subsystem-agnostic. Note that the panel framework used the
fb_videomode structure in its API, this will be replaced by a common video
mode structure shared across subsystems (there's only so many hours per day).

Panels, as used in these patches, are defined as physical devices combining a
matrix of pixels and a controller capable of driving that matrix.

Panel physical devices are registered as children of the control bus the panel
controller is connected to (depending on the panel type, we can find platform
devices for dummy panels with no control bus, or I2C, SPI, DBI, DSI, ...
devices). The generic panel framework matches registered panel devices with
panel drivers and call the panel drivers probe method, as done by other device
classes in the kernel. The driver probe() method is responsible for
instantiating a struct panel instance and registering it with the generic
panel framework.

Display drivers are panel consumers. They register a panel notifier with the
framework, which then calls the notifier when a matching panel is registered.
The reason for this asynchronous mode of operation, compared to how drivers
acquire regulator or clock resources, is that the panel can use resources
provided by the display driver. For instance a panel can be a child of the DBI
or DSI bus controlled by the display device, or use a clock provided by that
device. We can't defer the display device probe until the panel is registered
and also defer the panel device probe until the display is registered. As
most display drivers need to handle output devices hotplug (HDMI monitors for
instance), handling panel through a notification system seemed to be the
easiest solution.

Note that this brings a different issue after registration, as display and
panel drivers would take a reference to each other. Those circular references
would make driver unloading impossible. I haven't found a good solution for
that problem yet (hence the RFC state of those patches), and I would
appreciate your input here. This might also be a hint that the framework
design is wrong to start with. I guess I can't get everything right on the
first try ;-)

Getting hold of the panel is the most complex part. Once done, display drivers
can call abstract operations provided by panel drivers to control the panel
operation. These patches implement three of those operations (enable, start
transfer and get modes). More operations will be needed, and those three
operations will likely get modified during review. Most of the panels on
devices I own are dumb panels with no control bus, and are thus not the best
candidates to design a framework that needs to take complex panels' needs into
account.

In addition to the generic panel core, I've implemented MIPI DBI (Display Bus
Interface, a parallel bus for panels that supports read/write transfers of
commands and data) bus support, as well as three panel drivers (dummy panels
with no control bus, and Renesas R61505- and R61517-based panels, both using
DBI as their control bus). Only the dummy panel driver has been tested as I
lack hardware for the two other drivers.

I will appreciate all reviews, comments, criticisms, ideas, remarks, ... If
you can find a clever way to solve the cyclic references issue described above
I'll buy you a beer at the next conference we will both attend. If you think
the proposed solution is too complex, or too simple, I'm all ears. I
personally alrea

Re: [PATCH] dvb_frontend: Multistream support

2012-08-16 Thread Mauro Carvalho Chehab 
Em 16-08-2012 15:11, Antti Palosaari escreveu:
> On 08/16/2012 08:46 PM, CrazyCat wrote:
>> DTV_ISDBS_TS_ID replaced with DTV_STREAM_ID.
>> Aliases DTV_ISDBS_TS_ID, DTV_DVBS2_MIS_ID for DTV_STREAM_ID.
>> DTV_DVBT2_PLP_ID marked as legacy.
>>
>> Signed-off-by: Evgeny Plehov 
>> diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
>> index f50d405..3444dda 100644
>> --- a/include/linux/dvb/frontend.h
>> +++ b/include/linux/dvb/frontend.h
>> @@ -62,6 +62,7 @@ typedef enum fe_caps {
>>   FE_CAN_8VSB = 0x20,
>>   FE_CAN_16VSB = 0x40,
>>   FE_HAS_EXTENDED_CAPS = 0x80,   /* We need more bitspace for 
>> newer APIs, indicate this. */
>> + FE_CAN_MULTISTREAM = 0x400,  /* frontend supports DVB-S2 multistream 
>> filtering */

It is better to change this comment to cover the other standards.

>>   FE_CAN_TURBO_FEC = 0x800,  /* frontend supports "turbo fec 
>> modulation" */
>>   FE_CAN_2G_MODULATION = 0x1000, /* frontend supports "2nd 
>> generation modulation" (DVB-S2) */
>>   FE_NEEDS_BENDING = 0x2000, /* not supported anymore, don't use 
>> (frontend requires frequency bending) */
>> @@ -314,9 +315,11 @@ struct dvb_frontend_event {
>>
>>   #define DTV_ISDBT_LAYER_ENABLED 41
>>
>> -#define DTV_ISDBS_TS_ID 42
>> +#define DTV_STREAM_ID 42
>> +#define DTV_ISDBS_TS_ID DTV_STREAM_ID
>> +#define DTV_DVBS2_MIS_ID DTV_STREAM_ID
> 
> @Mauro, should we rename also DTV_ISDBS_TS_ID to DTV_ISDBS_TS_ID_LEGACY to 
> remind users ?

I think so.
> 
>> -#define DTV_DVBT2_PLP_ID 43
>> +#define DTV_DVBT2_PLP_ID_LEGACY 43
>>
>>   #define DTV_ENUM_DELSYS 44
>>
>> diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.h 
>> b/drivers/media/dvb/dvb-core/dvb_frontend.h
>> index 7c64c09..bec0cda 100644
>> --- a/drivers/media/dvb/dvb-core/dvb_frontend.h
>> +++ b/drivers/media/dvb/dvb-core/dvb_frontend.h
>> @@ -368,11 +368,8 @@ struct dtv_frontend_properties {
>>   u8 interleaving;
>>   } layer[3];
>>
>> - /* ISDB-T specifics */
>> - u32 isdbs_ts_id;
>> -
>> - /* DVB-T2 specifics */
>> - u32 dvbt2_plp_id;
>> + /* Multistream specifics */
>> + u32 stream_id;
> 
> u32 == 32 bit long unsigned number. See next comment.
> 
>>
>>   /* ATSC-MH specifics */
>>   u8 atscmh_fic_ver;
>> diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
>> b/drivers/media/dvb/dvb-core/dvb_frontend.c
>> index aebcdf2..bccd245 100644
>> --- a/drivers/media/dvb/dvb-core/dvb_frontend.c
>> +++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
>> @@ -946,8 +946,7 @@ static int dvb_frontend_clear_cache(struct dvb_frontend 
>> *fe)
>>   c->layer[i].segment_count = 0;
>>   }
>>
>> - c->isdbs_ts_id = 0;
>> - c->dvbt2_plp_id = 0;
>> + c->stream_id = -1;
> 
> unsigned number cannot be -1. It can be only 0 or bigger. Due to that this is 
> wrong.
> 
>>
>>   switch (c->delivery_system) {
>>   case SYS_DVBS:
>> @@ -1017,8 +1016,8 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND + 1] 
>> = {
>>   _DTV_CMD(DTV_ISDBT_LAYERC_SEGMENT_COUNT, 1, 0),
>>   _DTV_CMD(DTV_ISDBT_LAYERC_TIME_INTERLEAVING, 1, 0),
>>
>> - _DTV_CMD(DTV_ISDBS_TS_ID, 1, 0),
>> - _DTV_CMD(DTV_DVBT2_PLP_ID, 1, 0),
>> + _DTV_CMD(DTV_STREAM_ID, 1, 0),
>> + _DTV_CMD(DTV_DVBT2_PLP_ID_LEGACY, 1, 0),
>>
>>   /* Get */
>>   _DTV_CMD(DTV_DISEQC_SLAVE_REPLY, 0, 1),
>> @@ -1382,11 +1381,10 @@ static int dtv_property_process_get(struct 
>> dvb_frontend *fe,
>>   case DTV_ISDBT_LAYERC_TIME_INTERLEAVING:
>>   tvp->u.data = c->layer[2].interleaving;
>>   break;
>> - case DTV_ISDBS_TS_ID:
>> - tvp->u.data = c->isdbs_ts_id;
>> - break;
>> - case DTV_DVBT2_PLP_ID:
>> - tvp->u.data = c->dvbt2_plp_id;
>> +
>> + case DTV_STREAM_ID:
>> + case DTV_DVBT2_PLP_ID_LEGACY:
>> + tvp->u.data = c->stream_id;
>>   break;
>>
>>   /* ATSC-MH */
>> @@ -1771,11 +1769,10 @@ static int dtv_property_process_set(struct 
>> dvb_frontend *fe,
>>   case DTV_ISDBT_LAYERC_TIME_INTERLEAVING:
>>   c->layer[2].interleaving = tvp->u.data;
>>   break;
>> - case DTV_ISDBS_TS_ID:
>> - c->isdbs_ts_id = tvp->u.data;
>> - break;
>> - case DTV_DVBT2_PLP_ID:
>> - c->dvbt2_plp_id = tvp->u.data;
>> +
>> + case DTV_STREAM_ID:
>> + case DTV_DVBT2_PLP_ID_LEGACY:
>> + c->stream_id = tvp->u.data;
>>   break;
>>
>>   /* ATSC-MH */

The rest looks fine for me. Still missing the DocBook additions for multistream
(Documentation/DocBook/media/dvb/dvbproperty.xml).

> 
> regards
> Antti
> 
> 

--
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: [media] rc-core: move timeout and checks to lirc

2012-08-16 Thread Mauro Carvalho Chehab 
Em 16-08-2012 19:15, Sean Young escreveu:
>  
>> The lirc TX functionality expects the process which writes (TX) data to
>> the lirc dev to sleep until the actual data has been transmitted by the
>> hardware.
>>
>> Since the same timeout calculation is duplicated in more than one driver
>> (and would have to be duplicated in even more drivers as they gain TX
>> support), it makes sense to move this timeout calculation to the lirc
>> layer instead.
>>
>> At the same time, centralize some of the sanity checks.
>>
>> Signed-off-by: David Härdeman 
>> Cc: Jarod Wilson 
>> Signed-off-by: Mauro Carvalho Chehab 
>> ---
>>  drivers/media/rc/ir-lirc-codec.c | 33 +
>>  drivers/media/rc/mceusb.c| 18 --
>>  drivers/media/rc/rc-loopback.c   | 12 
>>  3 files changed, 29 insertions(+), 34 deletions(-)
>>
>> diff --git a/drivers/media/rc/ir-lirc-codec.c 
>> b/drivers/media/rc/ir-lirc-codec.c
>> index d2fd064..6ad4a07 100644
>> --- a/drivers/media/rc/ir-lirc-codec.c
>> +++ b/drivers/media/rc/ir-lirc-codec.c
>> @@ -107,6 +107,12 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, 
>> const char __user *buf,
>>  unsigned int *txbuf; /* buffer with values to transmit */
>>  ssize_t ret = -EINVAL;
>>  size_t count;
>> +ktime_t start;
>> +s64 towait;
>> +unsigned int duration = 0; /* signal duration in us */
>> +int i;
>> +
>> +start = ktime_get();
>>  
>>  lirc = lirc_get_pdata(file);
>>  if (!lirc)
>> @@ -129,11 +135,30 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, 
>> const char __user *buf,
>>  goto out;
>>  }
>>  
>> -if (dev->tx_ir)
>> -ret = dev->tx_ir(dev, txbuf, count);
>> +if (!dev->tx_ir) {
>> +ret = -ENOSYS;
>> +goto out;
>> +}
>> +
>> +ret = dev->tx_ir(dev, txbuf, (u32)n);
>> +if (ret < 0)
>> +goto out;
>> +
>> +for (i = 0; i < ret; i++)
>> +duration += txbuf[i];
>>  
>> -if (ret > 0)
>> -ret *= sizeof(unsigned);
>> +ret *= sizeof(unsigned int);
>> +
>> +/*
>> + * The lircd gap calculation expects the write function to
>> + * wait for the actual IR signal to be transmitted before
>> + * returning.
>> + */
>> +towait = ktime_us_delta(ktime_add_us(start, duration), ktime_get());
>> +if (towait > 0) {
>> +set_current_state(TASK_INTERRUPTIBLE);
>> +schedule_timeout(usecs_to_jiffies(towait));
>> +}
>>  
>>  out:
> 
> You've moved the sleeping out of the drivers to ir-lirc-codec, which makes
> sense for some devices. However you haven't updated winbond-cir.c which
> does two things:
> 
> 1) Modifies the txbuf (which is now used after transmit)
> 2) Does the sleeping already since it blocks on the device to complete.
> 
> Surely if the driver can block on the device to complete then that is 
> better than sleeping; there might some difference due to rounding and 
> clock skew.
> 
> In addition to winbond-cir, iguanair suffer from the same problem. There
> might be others.

That's likely my fault: I was waiting for Jarod's review on this patch,
with didn't happen, likely because he is too busy with some other stuff.
Both winbond and iguanair drivers went after David's patch.

Feel free to send me a patch fixing it there.

> Could we have a flag in rc_dev to signify whether a driver blocks on
> completion of a transmit and only sleep here if it is not set?
> 
> e.g. rc_dev.tx_blocks_until_complete
> 
> The wording could be improved.
> 
> Another alternative would be if the drivers provided a 
> "wait_for_tx_to_complete()" function. If they can provided that; using 
> that it would be possible to implement O_NONBLOCK and sync.

Seems fine on my eyes. It may avoid code duplication if you pass the fd 
flags to the lirc call, and add a code there that will wait for complete, 
if the device was not opened in block mode.

Regards,
mauro

> 
>>  kfree(txbuf);
>> diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
>> index d289fd4..a5c6c1c 100644
>> --- a/drivers/media/rc/mceusb.c
>> +++ b/drivers/media/rc/mceusb.c
>> @@ -791,10 +791,6 @@ static int mceusb_tx_ir(struct rc_dev *dev, unsigned 
>> *txbuf, unsigned count)
>>  int i, ret = 0;
>>  int cmdcount = 0;
>>  unsigned char *cmdbuf; /* MCE command buffer */
>> -long signal_duration = 0; /* Singnal length in us */
>> -struct timeval start_time, end_time;
>> -
>> -do_gettimeofday(&start_time);
>>  
>>  cmdbuf = kzalloc(sizeof(unsigned) * MCE_CMDBUF_SIZE, GFP_KERNEL);
>>  if (!cmdbuf)
>> @@ -807,7 +803,6 @@ static int mceusb_tx_ir(struct rc_dev *dev, unsigned 
>> *txbuf, unsigned count)
>>  
>>  /* Generate mce packet data */
>>  for (i = 0; (i < count) && (cmdcount < MCE_CMDBUF_SIZE); i++) {
>> -signal_duration += txbuf[i];
>>  txbuf[i] = txbuf[i] / MCE_TIME_UNIT;
>>  
>>  do { /* loop to sup

Re: [media] rc-core: move timeout and checks to lirc

2012-08-16 Thread Sean Young 
 
> The lirc TX functionality expects the process which writes (TX) data to
> the lirc dev to sleep until the actual data has been transmitted by the
> hardware.
> 
> Since the same timeout calculation is duplicated in more than one driver
> (and would have to be duplicated in even more drivers as they gain TX
> support), it makes sense to move this timeout calculation to the lirc
> layer instead.
> 
> At the same time, centralize some of the sanity checks.
> 
> Signed-off-by: David Härdeman 
> Cc: Jarod Wilson 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/rc/ir-lirc-codec.c | 33 +
>  drivers/media/rc/mceusb.c| 18 --
>  drivers/media/rc/rc-loopback.c   | 12 
>  3 files changed, 29 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/media/rc/ir-lirc-codec.c 
> b/drivers/media/rc/ir-lirc-codec.c
> index d2fd064..6ad4a07 100644
> --- a/drivers/media/rc/ir-lirc-codec.c
> +++ b/drivers/media/rc/ir-lirc-codec.c
> @@ -107,6 +107,12 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, 
> const char __user *buf,
>   unsigned int *txbuf; /* buffer with values to transmit */
>   ssize_t ret = -EINVAL;
>   size_t count;
> + ktime_t start;
> + s64 towait;
> + unsigned int duration = 0; /* signal duration in us */
> + int i;
> +
> + start = ktime_get();
>  
>   lirc = lirc_get_pdata(file);
>   if (!lirc)
> @@ -129,11 +135,30 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, 
> const char __user *buf,
>   goto out;
>   }
>  
> - if (dev->tx_ir)
> - ret = dev->tx_ir(dev, txbuf, count);
> + if (!dev->tx_ir) {
> + ret = -ENOSYS;
> + goto out;
> + }
> +
> + ret = dev->tx_ir(dev, txbuf, (u32)n);
> + if (ret < 0)
> + goto out;
> +
> + for (i = 0; i < ret; i++)
> + duration += txbuf[i];
>  
> - if (ret > 0)
> - ret *= sizeof(unsigned);
> + ret *= sizeof(unsigned int);
> +
> + /*
> +  * The lircd gap calculation expects the write function to
> +  * wait for the actual IR signal to be transmitted before
> +  * returning.
> +  */
> + towait = ktime_us_delta(ktime_add_us(start, duration), ktime_get());
> + if (towait > 0) {
> + set_current_state(TASK_INTERRUPTIBLE);
> + schedule_timeout(usecs_to_jiffies(towait));
> + }
>  
>  out:

You've moved the sleeping out of the drivers to ir-lirc-codec, which makes
sense for some devices. However you haven't updated winbond-cir.c which
does two things:

1) Modifies the txbuf (which is now used after transmit)
2) Does the sleeping already since it blocks on the device to complete.

Surely if the driver can block on the device to complete then that is 
better than sleeping; there might some difference due to rounding and 
clock skew.

In addition to winbond-cir, iguanair suffer from the same problem. There
might be others.

Could we have a flag in rc_dev to signify whether a driver blocks on
completion of a transmit and only sleep here if it is not set?

e.g. rc_dev.tx_blocks_until_complete

The wording could be improved.

Another alternative would be if the drivers provided a 
"wait_for_tx_to_complete()" function. If they can provided that; using 
that it would be possible to implement O_NONBLOCK and sync.

>   kfree(txbuf);
> diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
> index d289fd4..a5c6c1c 100644
> --- a/drivers/media/rc/mceusb.c
> +++ b/drivers/media/rc/mceusb.c
> @@ -791,10 +791,6 @@ static int mceusb_tx_ir(struct rc_dev *dev, unsigned 
> *txbuf, unsigned count)
>   int i, ret = 0;
>   int cmdcount = 0;
>   unsigned char *cmdbuf; /* MCE command buffer */
> - long signal_duration = 0; /* Singnal length in us */
> - struct timeval start_time, end_time;
> -
> - do_gettimeofday(&start_time);
>  
>   cmdbuf = kzalloc(sizeof(unsigned) * MCE_CMDBUF_SIZE, GFP_KERNEL);
>   if (!cmdbuf)
> @@ -807,7 +803,6 @@ static int mceusb_tx_ir(struct rc_dev *dev, unsigned 
> *txbuf, unsigned count)
>  
>   /* Generate mce packet data */
>   for (i = 0; (i < count) && (cmdcount < MCE_CMDBUF_SIZE); i++) {
> - signal_duration += txbuf[i];
>   txbuf[i] = txbuf[i] / MCE_TIME_UNIT;
>  
>   do { /* loop to support long pulses/spaces > 127*50us=6.35ms */
> @@ -850,19 +845,6 @@ static int mceusb_tx_ir(struct rc_dev *dev, unsigned 
> *txbuf, unsigned count)
>   /* Transmit the command to the mce device */
>   mce_async_out(ir, cmdbuf, cmdcount);
>  
> - /*
> -  * The lircd gap calculation expects the write function to
> -  * wait the time it takes for the ircommand to be sent before
> -  * it returns.
> -  */
> - do_gettimeofday(&end_time);
> - signal_duration -= (end_time.tv_usec - start_time.tv_usec) +
> -(end_time.tv_sec - start_time.tv_sec)

Re: [PATCH] [media] winbond-cir: Fix initialization

2012-08-16 Thread Sean Young 
On Thu, Aug 16, 2012 at 09:19:09AM -0700, Greg KH wrote:
> On Tue, Jul 31, 2012 at 11:37:03AM +0100, Sean Young wrote:
> > The serial driver will detect the winbond cir device as a serial port,
> > since it looks exactly like a serial port unless you know what it is
> > from the PNP ID.
> > 
> > Winbond CIR 00:04: Region 0x2f8-0x2ff already in use!
> > Winbond CIR 00:04: disabled
> > Winbond CIR: probe of 00:04 failed with error -16
> > 
> > Signed-off-by: Sean Young 
> > ---
> >  drivers/media/rc/winbond-cir.c | 21 -
> >  drivers/tty/serial/8250/8250.c |  1 +
> >  2 files changed, 21 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/media/rc/winbond-cir.c b/drivers/media/rc/winbond-cir.c
> > index 54ee348..20a0bbb 100644
> > --- a/drivers/media/rc/winbond-cir.c
> > +++ b/drivers/media/rc/winbond-cir.c
> > @@ -55,6 +55,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  
> >  #define DRVNAME "winbond-cir"
> > @@ -957,6 +958,7 @@ wbcir_probe(struct pnp_dev *device, const struct 
> > pnp_device_id *dev_id)
> > struct device *dev = &device->dev;
> > struct wbcir_data *data;
> > int err;
> > +   struct resource *io;
> >  
> > if (!(pnp_port_len(device, 0) == EHFUNC_IOMEM_LEN &&
> >   pnp_port_len(device, 1) == WAKEUP_IOMEM_LEN &&
> > @@ -1049,7 +1051,24 @@ wbcir_probe(struct pnp_dev *device, const struct 
> > pnp_device_id *dev_id)
> > goto exit_release_wbase;
> > }
> >  
> > -   if (!request_region(data->sbase, SP_IOMEM_LEN, DRVNAME)) {
> > +   io = request_region(data->sbase, SP_IOMEM_LEN, DRVNAME);
> > +
> > +   /*
> > +* The winbond cir device looks exactly like an NS16550A serial port
> > +* unless you know what it is. We've got here via the PNP ID.
> > +*/
> > +#ifdef CONFIG_SERIAL_8250
> > +   if (!io) {
> > +   struct uart_port port = { .iobase = data->sbase };
> > +   int line = serial8250_find_port(&port);
> > +   if (line >= 0) {
> > +   serial8250_unregister_port(line);
> > +
> > +   io = request_region(data->sbase, SP_IOMEM_LEN, DRVNAME);
> > +   }
> > +   }
> > +#endif
> > +   if (!io) {
> > dev_err(dev, "Region 0x%lx-0x%lx already in use!\n",
> > data->sbase, data->sbase + SP_IOMEM_LEN - 1);
> > err = -EBUSY;
> > diff --git a/drivers/tty/serial/8250/8250.c b/drivers/tty/serial/8250/8250.c
> > index 5c27f7e..d38615f 100644
> > --- a/drivers/tty/serial/8250/8250.c
> > +++ b/drivers/tty/serial/8250/8250.c
> > @@ -2914,6 +2914,7 @@ int serial8250_find_port(struct uart_port *p)
> > }
> > return -ENODEV;
> >  }
> > +EXPORT_SYMBOL(serial8250_find_port);
> 
> EXPORT_SYMBOL_GPL please.

Ah yes.

> But can't this be done as a quirk to the 8250 driver so that it just
> does not bind to this device in the first place?  Wouldn't that make
> more sense?

Absolutely. However for such a quirk to work, it'll need to detect the
IR port. The problem is, based just the I/O ports for the serial port, 
it seems impossible. I've been banging my head against a brick wall 
trying to find a way to do this. As soon as you start looking at
the other I/O ports for the IR then it becomes clear, but you'll need
to glean from PNP what the port numbers are. Either that or some sort
of Super I/O detection.


Sean
--
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] ddbridge: fix error handling in module_init_ddbridge()

2012-08-16 Thread Alexey Khoroshilov 
If pci_register_driver() failed, resources allocated in
ddb_class_create() are leaked. The patch fixes it
as well as it replaces -1 with correct error code
in ddb_class_create().

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
---
 drivers/media/dvb/ddbridge/ddbridge-core.c |   15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/media/dvb/ddbridge/ddbridge-core.c 
b/drivers/media/dvb/ddbridge/ddbridge-core.c
index ebf3f05..feff57e 100644
--- a/drivers/media/dvb/ddbridge/ddbridge-core.c
+++ b/drivers/media/dvb/ddbridge/ddbridge-core.c
@@ -1497,7 +1497,7 @@ static int ddb_class_create(void)
ddb_class = class_create(THIS_MODULE, DDB_NAME);
if (IS_ERR(ddb_class)) {
unregister_chrdev(ddb_major, DDB_NAME);
-   return -1;
+   return PTR_ERR(ddb_class);
}
ddb_class->devnode = ddb_devnode;
return 0;
@@ -1701,11 +1701,18 @@ static struct pci_driver ddb_pci_driver = {
 
 static __init int module_init_ddbridge(void)
 {
+   int ret;
+
printk(KERN_INFO "Digital Devices PCIE bridge driver, "
   "Copyright (C) 2010-11 Digital Devices GmbH\n");
-   if (ddb_class_create())
-   return -1;
-   return pci_register_driver(&ddb_pci_driver);
+
+   ret = ddb_class_create();
+   if (ret < 0)
+   return ret;
+   ret = pci_register_driver(&ddb_pci_driver);
+   if (ret < 0)
+   ddb_class_destroy();
+   return ret;
 }
 
 static __exit void module_exit_ddbridge(void)
-- 
1.7.9.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-usb-v2 change broke s2250-loader compilation

2012-08-16 Thread Antti Palosaari 

On 08/16/2012 11:06 PM, Mauro Carvalho Chehab wrote:

Em 16-08-2012 15:48, Antti Palosaari escreveu:

On 08/16/2012 09:34 PM, Mauro Carvalho Chehab wrote:

Em 16-08-2012 15:31, Antti Palosaari escreveu:

On 08/16/2012 07:50 PM, Mauro Carvalho Chehab wrote:

Em 16-08-2012 11:29, Antti Palosaari escreveu:

On 08/16/2012 05:07 PM, Hans Verkuil wrote:

On Thu August 16 2012 15:45:47 Antti Palosaari wrote:

On 08/16/2012 03:18 PM, Antti Palosaari wrote:

On 08/16/2012 01:33 PM, Hans Verkuil wrote:

Building the kernel with the Sensoray 2250/2251 staging go7007 driver
enabled
fails with this link error:

ERROR: "usb_cypress_load_firmware"
[drivers/staging/media/go7007/s2250-loader.ko] undefined!

As far as I can tell this is related to the dvb-usb-v2 changes.

Can someone take a look at this?

Thanks!

Hans


Yes it is dvb usb v2 related. I wasn't even aware that someone took that
module use in few days after it was added for the dvb-usb-v2.

Maybe it is worth to make it even more common and move out of dvb-usb-v2...

regards
Antti


And after looking it twice I cannot see the reason. I split that Cypress
firmware download to own module called dvb_usb_cypress_firmware which
offer routine usbv2_cypress_load_firmware(). Old DVB USB is left
untouched. I can confirm it fails to compile for s2250, but there is
still old dvb_usb_cxusb that is compiling without a error.

Makefile paths seems to be correct also, no idea whats wrong


drivers/media/usb/Makefile uses := instead of += for the dvb-usb(-v2) 
directories,
and that prevents dvb-usb from being build. I think that's the cause of the link
error.


For that I cannot say as I don't understand situation enough.


In addition I noticed that in usb/dvb-usb there is a dvb_usb_dvb.c and a
dvb-usb-dvb.c file: there's a mixup with _ and -.


These files seems to be my fault. Original patch series removes those,
but I was forced to rebase whole set and in that rebased set those are left 
unremoved.
Likely due to some rebase conflict. I will send new patch to remove those.


If you remove the _, they'll conflict with dvb-usb at media-build.git.

The better is to add a _v2 (or -v2) on all dvb-usb-v2 files
(or to convert the remaining dvb-usb drivers to dvb-usb-v2).


hmm, now I am quite out what you mean.

This is from my first PULL-request:
http://git.linuxtv.org/anttip/media_tree.git/commit/c60c6d44111be2b2fd9ef9b716ea50bd87493893

And this is same patch after large rebase:
http://git.linuxtv.org/anttip/media_tree.git/commit/ac97c6f722aafb5b562ef04062b543147399dff8

Why removing those wrong files will cause conflict in media_build.git ?


Because, at the media-build, all files are linked into the "/v4l" dir. If there 
are two different
modules with the same name, one will override the other.


But there should not be same names what I know.
Here is the list of DVB USB related files:

DVB USB v1:
***
dvb-usb/dvb-usb-firmware.c
dvb-usb/dvb-usb.h
dvb-usb/dvb-usb-common.h
dvb-usb/dvb_usb_dvb.c *** not needed
dvb-usb/dvb-usb-dvb.c
dvb-usb/dvb-usb-i2c.c
dvb-usb/dvb-usb-init.c
dvb-usb/dvb_usb_remote.c *** not needed
dvb-usb/dvb-usb-remote.c
dvb-usb/dvb-usb-urb.c
dvb-usb/usb-urb.c
dvb-usb/dvb-usb.ko

DVB USB v2:
***
dvb-usb-v2/cypress_firmware.c
dvb-usb-v2/cypress_firmware.h
dvb-usb-v2/dvb_usb.h
dvb-usb-v2/dvb_usb_common.h
dvb-usb-v2/dvb_usb_core.c
dvb-usb-v2/dvb_usb_urb.c
dvb-usb-v2/usb_urb.c
dvb-usb-v2/dvb_usb_cypress_firmware.ko
dvb-usb-v2/dvb_usbv2.ko


Yes, but Hans got confused with dvb_usb/dvb-usb stuff.
I said that renaming from one to the other would cause conflicts.

-

As discussed on IRC, this patch should likely fix it (untested, at media-build).


I can confirm after that patch at least dvb-usb and dvb-usb-v2 are build 
again.


Tested-by: Antti Palosaari 





[media] Fix some Makefile rules

From: Mauro Carvalho Chehab 

On a few places, := were using instead of +=, causing drivers to
not compile.

While here, standardize the usage of += on all cases where multiple
lines are needed, and for obj-y/obj-m targets, and := when just one
line is needed, on -obj rules.

Reported-by: Hans Verkuil 
Identified-by: Antti Polosaari 
Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/common/b2c2/Makefile 
b/drivers/media/common/b2c2/Makefile
index 48a4c90..24993a5 100644
--- a/drivers/media/common/b2c2/Makefile
+++ b/drivers/media/common/b2c2/Makefile
@@ -1,5 +1,6 @@
-b2c2-flexcop-objs = flexcop.o flexcop-fe-tuner.o flexcop-i2c.o \
-   flexcop-sram.o flexcop-eeprom.o flexcop-misc.o flexcop-hw-filter.o
+b2c2-flexcop-objs += flexcop.o flexcop-fe-tuner.o flexcop-i2c.o
+b2c2-flexcop-objs += flexcop-sram.o flexcop-eeprom.o flexcop-misc.o
+b2c2-flexcop-objs += flexcop-hw-filter.o
  obj-$(CONFIG_DVB_B2C2_FLEXCOP) += b2c2-flexcop.o

  ccflags-y += -Idrivers/media/dvb-core/
diff --git a/drivers/media/dvb-frontends/Makefile 
b/drivers/media/dvb-frontends/Makefile
index 208bc49..7eb73bb 100644
--- a/drivers/media/dvb-frontends/Makefile
+++ b

Re: noisy dev_dbg_ratelimited()

2012-08-16 Thread Hin-Tak Leung 
--- On Thu, 16/8/12, Antti Palosaari  wrote:

> Hello Hiroshi
> 
> On 08/16/2012 10:12 AM, Hiroshi Doyu wrote:
> > Hi Antti,
> >
> > Antti Palosaari 
> wrote @ Thu, 16 Aug 2012 03:11:56 +0200:
> >
> >> Hello Hiroshi,
> >>
> >> I see you have added dev_dbg_ratelimited()
> recently, commit
> >> 6ca045930338485a8cdef117e74372aa1678009d .
> >>
> >> However it seems to be noisy as expected similar
> behavior than normal
> >> dev_dbg() without a ratelimit.
> >>
> >> I looked ratelimit.c and there is:
> >> printk(KERN_WARNING "%s: %d callbacks
> suppressed\n", func, rs->missed);
> >>
> >> What it looks my eyes it will print those
> "callbacks suppressed" always
> >> because KERN_WARNING.
> >
> > Right. Can the following fix the problem?
> 
> No. That silences dev_dbg_reatelimited() totally.
> dev_dbg() works as expected printing all the debugs. But
> when I change 
> it to dev_dbg_reatelimited() all printings are silenced.

That's probably correct - the patch looks a bit strange... I did not try the 
patch, but had a quick look at the file and noted that in 
include/linux/device.h, "info" (and possibly another level) are treated 
specially... just thought I should mention this.

> >>From 905b1dedb6c64bc46a70f6d203ef98c23fccb107 Mon
> Sep 17 00:00:00 2001
> > From: Hiroshi Doyu 
> > Date: Thu, 16 Aug 2012 10:02:11 +0300
> > Subject: [PATCH 1/1] driver-core: Shut up
> dev_dbg_reatelimited() without
> >   DEBUG
> >
> > dev_dbg_reatelimited() without DEBUG printed "217078
> callbacks
> > suppressed". This shouldn't print anything without
> DEBUG.
> >
> > Signed-off-by: Hiroshi Doyu 
> > Reported-by: Antti Palosaari 
> > ---
> >   include/linux/device.h |   
> 6 +-
> >   1 files changed, 5 insertions(+), 1
> deletions(-)
> >
> > diff --git a/include/linux/device.h
> b/include/linux/device.h
> > index eb945e1..d4dc26e 100644
> > --- a/include/linux/device.h
> > +++ b/include/linux/device.h
> > @@ -962,9 +962,13 @@ do {   
>            
>            
>         \
> >  
> dev_level_ratelimited(dev_notice, dev, fmt, ##__VA_ARGS__)
> >   #define dev_info_ratelimited(dev, fmt,
> ...)           
>     \
> >  
> dev_level_ratelimited(dev_info, dev, fmt, ##__VA_ARGS__)
> > +#if defined(DEBUG)
> >   #define dev_dbg_ratelimited(dev, fmt,
> ...)           
>     \
> >  
> dev_level_ratelimited(dev_dbg, dev, fmt, ##__VA_ARGS__)
> > -
> > +#else
> > +#define dev_dbg_ratelimited(dev, fmt,
> ...)           
> \
> > +    no_printk(KERN_DEBUG pr_fmt(fmt),
> ##__VA_ARGS__)
> > +#endif
> >   /*
> >    * Stupid hackaround for existing uses of
> non-printk uses dev_info
> >    *
> >
> 
> 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-usb-v2 change broke s2250-loader compilation

2012-08-16 Thread Mauro Carvalho Chehab 
Em 16-08-2012 15:48, Antti Palosaari escreveu:
> On 08/16/2012 09:34 PM, Mauro Carvalho Chehab wrote:
>> Em 16-08-2012 15:31, Antti Palosaari escreveu:
>>> On 08/16/2012 07:50 PM, Mauro Carvalho Chehab wrote:
 Em 16-08-2012 11:29, Antti Palosaari escreveu:
> On 08/16/2012 05:07 PM, Hans Verkuil wrote:
>> On Thu August 16 2012 15:45:47 Antti Palosaari wrote:
>>> On 08/16/2012 03:18 PM, Antti Palosaari wrote:
 On 08/16/2012 01:33 PM, Hans Verkuil wrote:
> Building the kernel with the Sensoray 2250/2251 staging go7007 driver
> enabled
> fails with this link error:
>
> ERROR: "usb_cypress_load_firmware"
> [drivers/staging/media/go7007/s2250-loader.ko] undefined!
>
> As far as I can tell this is related to the dvb-usb-v2 changes.
>
> Can someone take a look at this?
>
> Thanks!
>
>Hans

 Yes it is dvb usb v2 related. I wasn't even aware that someone took 
 that
 module use in few days after it was added for the dvb-usb-v2.

 Maybe it is worth to make it even more common and move out of 
 dvb-usb-v2...

 regards
 Antti
>>>
>>> And after looking it twice I cannot see the reason. I split that Cypress
>>> firmware download to own module called dvb_usb_cypress_firmware which
>>> offer routine usbv2_cypress_load_firmware(). Old DVB USB is left
>>> untouched. I can confirm it fails to compile for s2250, but there is
>>> still old dvb_usb_cxusb that is compiling without a error.
>>>
>>> Makefile paths seems to be correct also, no idea whats wrong
>>
>> drivers/media/usb/Makefile uses := instead of += for the dvb-usb(-v2) 
>> directories,
>> and that prevents dvb-usb from being build. I think that's the cause of 
>> the link
>> error.
>
> For that I cannot say as I don't understand situation enough.
>
>> In addition I noticed that in usb/dvb-usb there is a dvb_usb_dvb.c and a
>> dvb-usb-dvb.c file: there's a mixup with _ and -.
>
> These files seems to be my fault. Original patch series removes those,
> but I was forced to rebase whole set and in that rebased set those are 
> left unremoved.
> Likely due to some rebase conflict. I will send new patch to remove those.

 If you remove the _, they'll conflict with dvb-usb at media-build.git.

 The better is to add a _v2 (or -v2) on all dvb-usb-v2 files
 (or to convert the remaining dvb-usb drivers to dvb-usb-v2).
>>>
>>> hmm, now I am quite out what you mean.
>>>
>>> This is from my first PULL-request:
>>> http://git.linuxtv.org/anttip/media_tree.git/commit/c60c6d44111be2b2fd9ef9b716ea50bd87493893
>>>
>>> And this is same patch after large rebase:
>>> http://git.linuxtv.org/anttip/media_tree.git/commit/ac97c6f722aafb5b562ef04062b543147399dff8
>>>
>>> Why removing those wrong files will cause conflict in media_build.git ?
>>
>> Because, at the media-build, all files are linked into the "/v4l" dir. If 
>> there are two different
>> modules with the same name, one will override the other.
> 
> But there should not be same names what I know.
> Here is the list of DVB USB related files:
> 
> DVB USB v1:
> ***
> dvb-usb/dvb-usb-firmware.c
> dvb-usb/dvb-usb.h
> dvb-usb/dvb-usb-common.h
> dvb-usb/dvb_usb_dvb.c *** not needed
> dvb-usb/dvb-usb-dvb.c
> dvb-usb/dvb-usb-i2c.c
> dvb-usb/dvb-usb-init.c
> dvb-usb/dvb_usb_remote.c *** not needed
> dvb-usb/dvb-usb-remote.c
> dvb-usb/dvb-usb-urb.c
> dvb-usb/usb-urb.c
> dvb-usb/dvb-usb.ko
> 
> DVB USB v2:
> ***
> dvb-usb-v2/cypress_firmware.c
> dvb-usb-v2/cypress_firmware.h
> dvb-usb-v2/dvb_usb.h
> dvb-usb-v2/dvb_usb_common.h
> dvb-usb-v2/dvb_usb_core.c
> dvb-usb-v2/dvb_usb_urb.c
> dvb-usb-v2/usb_urb.c
> dvb-usb-v2/dvb_usb_cypress_firmware.ko
> dvb-usb-v2/dvb_usbv2.ko

Yes, but Hans got confused with dvb_usb/dvb-usb stuff.
I said that renaming from one to the other would cause conflicts.

-

As discussed on IRC, this patch should likely fix it (untested, at media-build).



[media] Fix some Makefile rules

From: Mauro Carvalho Chehab 

On a few places, := were using instead of +=, causing drivers to
not compile.

While here, standardize the usage of += on all cases where multiple
lines are needed, and for obj-y/obj-m targets, and := when just one
line is needed, on -obj rules.

Reported-by: Hans Verkuil 
Identified-by: Antti Polosaari 
Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/common/b2c2/Makefile 
b/drivers/media/common/b2c2/Makefile
index 48a4c90..24993a5 100644
--- a/drivers/media/common/b2c2/Makefile
+++ b/drivers/media/common/b2c2/Makefile
@@ -1,5 +1,6 @@
-b2c2-flexcop-objs = flexcop.o flexcop-fe-tuner.o flexcop-i2c.o \
-   flexcop-sram.o flexcop-eeprom.o flexcop-misc.o flexcop-hw-filter.o
+b2c2-flexcop-objs += flexcop.o flexcop-fe-tuner.o flexcop-i2c.o
+b

Re: noisy dev_dbg_ratelimited()

2012-08-16 Thread Antti Palosaari 

Hello Hiroshi

On 08/16/2012 10:12 AM, Hiroshi Doyu wrote:

Hi Antti,

Antti Palosaari  wrote @ Thu, 16 Aug 2012 03:11:56 +0200:


Hello Hiroshi,

I see you have added dev_dbg_ratelimited() recently, commit
6ca045930338485a8cdef117e74372aa1678009d .

However it seems to be noisy as expected similar behavior than normal
dev_dbg() without a ratelimit.

I looked ratelimit.c and there is:
printk(KERN_WARNING "%s: %d callbacks suppressed\n", func, rs->missed);

What it looks my eyes it will print those "callbacks suppressed" always
because KERN_WARNING.


Right. Can the following fix the problem?


No. That silences dev_dbg_reatelimited() totally.
dev_dbg() works as expected printing all the debugs. But when I change 
it to dev_dbg_reatelimited() all printings are silenced.




From 905b1dedb6c64bc46a70f6d203ef98c23fccb107 Mon Sep 17 00:00:00 2001

From: Hiroshi Doyu 
Date: Thu, 16 Aug 2012 10:02:11 +0300
Subject: [PATCH 1/1] driver-core: Shut up dev_dbg_reatelimited() without
  DEBUG

dev_dbg_reatelimited() without DEBUG printed "217078 callbacks
suppressed". This shouldn't print anything without DEBUG.

Signed-off-by: Hiroshi Doyu 
Reported-by: Antti Palosaari 
---
  include/linux/device.h |6 +-
  1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/include/linux/device.h b/include/linux/device.h
index eb945e1..d4dc26e 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -962,9 +962,13 @@ do {   
\
dev_level_ratelimited(dev_notice, dev, fmt, ##__VA_ARGS__)
  #define dev_info_ratelimited(dev, fmt, ...)   \
dev_level_ratelimited(dev_info, dev, fmt, ##__VA_ARGS__)
+#if defined(DEBUG)
  #define dev_dbg_ratelimited(dev, fmt, ...)\
dev_level_ratelimited(dev_dbg, dev, fmt, ##__VA_ARGS__)
-
+#else
+#define dev_dbg_ratelimited(dev, fmt, ...) \
+   no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
+#endif
  /*
   * Stupid hackaround for existing uses of non-printk uses dev_info
   *



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: [GIT PULL] ViewCast O820E capture support added

2012-08-16 Thread Hans Verkuil 
On Thu August 16 2012 19:39:51 Steven Toth wrote:
> >> So, I've ran v4l2-compliance and it pointed out a few things that I've
> >> fixed, but it also does a few things that (for some reason) I can't
> >> seem to catch. One particular test is on (iirc) s_fmt. It attempts to
> >> set ATSC but by ioctl callback never receives ATSC in the norm/id arg,
> >> it actually receives 0x0. This feels more like a bug in the test.
> >> Either way, I have some if (std & ATSC) return -EINVAL, but it still
> >> appears to fail the test.
> 
> Oddly enough. If I set tvnorms to something valid, then compliance
> passes but gstreamer
> fails to run, looks like some kind of confusion about either the
> current established
> norm, or a failure to establish a norm.
> 
> For the time being I've set tvnorms to 0 (with a comment) and removed
> current_norm.

Well, this needs to be sorted, because something is clearly amiss.

> >
> > I think it might be because vdev->tvnorms isn't set for the video node.
> > It's set for the VBI node, though. If tvnorms is 0, then ENUMSTD will
> > probably return an empty list, and that might be the cause of the ATSC
> > test. I also see that current_norm is used: don't do that. Instead store
> > the current standard yourself and return it in g_std. I'm slowly phasing
> > out current_norm because 1) it's ugly and 2) it doesn't work if you have
> > both a vbi and a video node.
> 
> Done.
> 
> >
> >> I see some tests which report failure (testing videobuf) but given
> >> that I essentially pass the ioctl directly into the videbug core, very
> >> much like every oher driver I've ever done, it's probably either a
> >> quirk of the tool, or something inside videobuf core itself that needs
> >> some adjustment. (userptr/mmap for capture or output buffers related
> >> test).
> >
> > videobuf does not follow the spec in several areas (most notably and 
> > extremely
> > annoyingly it does not support calling REQBUFS with a count of 0). So any
> > driver that uses videobuf will fail a number of tests in v4l2-compliance.
> 
> Compliance as of today (with changes), now gives:
> 
> "Buffer ioctls:
>   fail: v4l2-test-buffers.cpp(76): can_stream && !mmap_valid && 
> !userptr_valid
>   test VIDIOC_REQBUFS/CREATE_BUFS: FAIL
>   test read/write: OK"

Yeah, that's because videobuf is used instead of vb2.



> In the meantime, here's the compliance report for the current driver:
> 
> http://git.kernellabs.com/?p=stoth/media_tree.git;a=shortlog;h=refs/heads/o820e
> 
> I have a couple of questions...
> 
> -bash-4.1$ ./v4l2-compliance -d /dev/video0
> Driver Info:
>   Driver name   : vc8x0
>   Card type : ViewCast 820e
>   Bus info  : PCIe::02:00.0
>   Driver version: 3.0.1
>   Capabilities  : 0x84020001
>   Video Capture
>   Audio
>   Streaming
>   Device Capabilities
>   Device Caps   : 0x04020001
>   Video Capture
>   Audio
>   Streaming
> 
> Compliance test for device /dev/video0 (not using libv4l2):
> 
> Required ioctls:
>   test VIDIOC_QUERYCAP: OK
> 
> Allow for multiple opens:
>   test second video open: OK
>   test VIDIOC_QUERYCAP: OK
>   fail: v4l2-compliance.cpp(323): doioctl(node, 
> VIDIOC_G_PRIORITY, &prio)
>   test VIDIOC_G/S_PRIORITY: FAIL
> 
> ^^^ If I read the compliance test correctly then I think this may be a
> bug in the tool. The driver doesn't support g_priority so why mark a
> failure?

The tool is more strict in some places than the spec is. One of those cases
is that is requires that priority handling is implemented. The reason for that
is 1) if you use the latest framework support (struct v4l2_fh in particular),
then you get priority handling for free by just setting a single bit, so there
is no excuse not to implement it, and 2) the reason few if any applications use
it is that too few drivers implemented it, so apps couldn't rely on it. It's
again a chicken and egg problem and the only way to improve matters is to have
a check that clearly tells you to add support for this.

> 
> 
> Debug ioctls:
>   test VIDIOC_DBG_G_CHIP_IDENT: Not Supported
>   test VIDIOC_DBG_G/S_REGISTER: Not Supported
>   test VIDIOC_LOG_STATUS: Not Supported
> 
> 
> Debuggung was removed as part of removing the /proc support, but
> likely this will return in the form of the above
> calls when the next major rev of this 820 card ships (and the driver
> is subsequently asked to support a variation of the 820 hardware).

OK.

> Input ioctls:
>   test VIDIOC_G/S_TUNER: Not Supported
>   test VIDIOC_G/S_FREQUENCY: Not Supported
>   test VIDIOC_S_HW_FREQ_SEEK: OK
>   test VIDIOC_ENUMAUDIO: OK
>   test VIDIOC_G/S/ENUMINPUT: OK
>   test VIDIOC_G/S_AUDIO: OK
>   Inputs: 7 Audio Inputs: 1 Tuners: 0
> 
> Output ioctls:
>   test VIDIOC_G/S_MODULATOR: Not Supported
>   test VIDIOC_G/S_FREQUENCY: Not Supported
>   t

Re: dvb-usb-v2 change broke s2250-loader compilation

2012-08-16 Thread Antti Palosaari 

On 08/16/2012 09:34 PM, Mauro Carvalho Chehab wrote:

Em 16-08-2012 15:31, Antti Palosaari escreveu:

On 08/16/2012 07:50 PM, Mauro Carvalho Chehab wrote:

Em 16-08-2012 11:29, Antti Palosaari escreveu:

On 08/16/2012 05:07 PM, Hans Verkuil wrote:

On Thu August 16 2012 15:45:47 Antti Palosaari wrote:

On 08/16/2012 03:18 PM, Antti Palosaari wrote:

On 08/16/2012 01:33 PM, Hans Verkuil wrote:

Building the kernel with the Sensoray 2250/2251 staging go7007 driver
enabled
fails with this link error:

ERROR: "usb_cypress_load_firmware"
[drivers/staging/media/go7007/s2250-loader.ko] undefined!

As far as I can tell this is related to the dvb-usb-v2 changes.

Can someone take a look at this?

Thanks!

   Hans


Yes it is dvb usb v2 related. I wasn't even aware that someone took that
module use in few days after it was added for the dvb-usb-v2.

Maybe it is worth to make it even more common and move out of dvb-usb-v2...

regards
Antti


And after looking it twice I cannot see the reason. I split that Cypress
firmware download to own module called dvb_usb_cypress_firmware which
offer routine usbv2_cypress_load_firmware(). Old DVB USB is left
untouched. I can confirm it fails to compile for s2250, but there is
still old dvb_usb_cxusb that is compiling without a error.

Makefile paths seems to be correct also, no idea whats wrong


drivers/media/usb/Makefile uses := instead of += for the dvb-usb(-v2) 
directories,
and that prevents dvb-usb from being build. I think that's the cause of the link
error.


For that I cannot say as I don't understand situation enough.


In addition I noticed that in usb/dvb-usb there is a dvb_usb_dvb.c and a
dvb-usb-dvb.c file: there's a mixup with _ and -.


These files seems to be my fault. Original patch series removes those,
but I was forced to rebase whole set and in that rebased set those are left 
unremoved.
Likely due to some rebase conflict. I will send new patch to remove those.


If you remove the _, they'll conflict with dvb-usb at media-build.git.

The better is to add a _v2 (or -v2) on all dvb-usb-v2 files
(or to convert the remaining dvb-usb drivers to dvb-usb-v2).


hmm, now I am quite out what you mean.

This is from my first PULL-request:
http://git.linuxtv.org/anttip/media_tree.git/commit/c60c6d44111be2b2fd9ef9b716ea50bd87493893

And this is same patch after large rebase:
http://git.linuxtv.org/anttip/media_tree.git/commit/ac97c6f722aafb5b562ef04062b543147399dff8

Why removing those wrong files will cause conflict in media_build.git ?


Because, at the media-build, all files are linked into the "/v4l" dir. If there 
are two different
modules with the same name, one will override the other.


But there should not be same names what I know.
Here is the list of DVB USB related files:

DVB USB v1:
***
dvb-usb/dvb-usb-firmware.c
dvb-usb/dvb-usb.h
dvb-usb/dvb-usb-common.h
dvb-usb/dvb_usb_dvb.c *** not needed
dvb-usb/dvb-usb-dvb.c
dvb-usb/dvb-usb-i2c.c
dvb-usb/dvb-usb-init.c
dvb-usb/dvb_usb_remote.c *** not needed
dvb-usb/dvb-usb-remote.c
dvb-usb/dvb-usb-urb.c
dvb-usb/usb-urb.c
dvb-usb/dvb-usb.ko

DVB USB v2:
***
dvb-usb-v2/cypress_firmware.c
dvb-usb-v2/cypress_firmware.h
dvb-usb-v2/dvb_usb.h
dvb-usb-v2/dvb_usb_common.h
dvb-usb-v2/dvb_usb_core.c
dvb-usb-v2/dvb_usb_urb.c
dvb-usb-v2/usb_urb.c
dvb-usb-v2/dvb_usb_cypress_firmware.ko
dvb-usb-v2/dvb_usbv2.ko


regards
Antti






OK, those are just wasting space nothing more. But there was that original 
problem too which breaks s2250-loader compilation.

regards
Antti



Regards,
Mauro




Mauro, did that happen during the reorganization?

Regards,

  Hans



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

cron job: media_tree daily build: ERRORS

2012-08-16 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:Thu Aug 16 19:00:26 CEST 2012
git hash:893430558e5bf116179915de2d3d119ad25c01cf
gcc version:  i686-linux-gcc (GCC) 4.7.1
host hardware:x86_64
host os:  3.4.07-marune

linux-git-arm-eabi-davinci: ERRORS
linux-git-arm-eabi-exynos: ERRORS
linux-git-arm-eabi-omap: ERRORS
linux-git-i686: WARNINGS
linux-git-m32r: WARNINGS
linux-git-mips: ERRORS
linux-git-powerpc64: OK
linux-git-x86_64: OK
linux-2.6.31.12-x86_64: ERRORS
linux-2.6.32.6-x86_64: ERRORS
linux-2.6.33-x86_64: ERRORS
linux-2.6.34-x86_64: ERRORS
linux-2.6.35.3-x86_64: ERRORS
linux-2.6.36-x86_64: ERRORS
linux-2.6.37-x86_64: ERRORS
linux-2.6.38.2-x86_64: ERRORS
linux-2.6.39.1-x86_64: ERRORS
linux-3.0-x86_64: ERRORS
linux-3.1-x86_64: ERRORS
linux-3.2.1-x86_64: WARNINGS
linux-3.3-x86_64: WARNINGS
linux-3.4-x86_64: WARNINGS
linux-3.5-x86_64: WARNINGS
linux-2.6.31.12-i686: ERRORS
linux-2.6.32.6-i686: ERRORS
linux-2.6.33-i686: ERRORS
linux-2.6.34-i686: ERRORS
linux-2.6.35.3-i686: ERRORS
linux-2.6.36-i686: ERRORS
linux-2.6.37-i686: ERRORS
linux-2.6.38.2-i686: ERRORS
linux-2.6.39.1-i686: ERRORS
linux-3.0-i686: ERRORS
linux-3.1-i686: ERRORS
linux-3.2.1-i686: WARNINGS
linux-3.3-i686: WARNINGS
linux-3.4-i686: WARNINGS
linux-3.5-i686: WARNINGS
apps: WARNINGS
spec-git: OK
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

The V4L-DVB specification 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: dvb-usb-v2 change broke s2250-loader compilation

2012-08-16 Thread Mauro Carvalho Chehab 
Em 16-08-2012 15:31, Antti Palosaari escreveu:
> On 08/16/2012 07:50 PM, Mauro Carvalho Chehab wrote:
>> Em 16-08-2012 11:29, Antti Palosaari escreveu:
>>> On 08/16/2012 05:07 PM, Hans Verkuil wrote:
 On Thu August 16 2012 15:45:47 Antti Palosaari wrote:
> On 08/16/2012 03:18 PM, Antti Palosaari wrote:
>> On 08/16/2012 01:33 PM, Hans Verkuil wrote:
>>> Building the kernel with the Sensoray 2250/2251 staging go7007 driver
>>> enabled
>>> fails with this link error:
>>>
>>> ERROR: "usb_cypress_load_firmware"
>>> [drivers/staging/media/go7007/s2250-loader.ko] undefined!
>>>
>>> As far as I can tell this is related to the dvb-usb-v2 changes.
>>>
>>> Can someone take a look at this?
>>>
>>> Thanks!
>>>
>>>   Hans
>>
>> Yes it is dvb usb v2 related. I wasn't even aware that someone took that
>> module use in few days after it was added for the dvb-usb-v2.
>>
>> Maybe it is worth to make it even more common and move out of 
>> dvb-usb-v2...
>>
>> regards
>> Antti
>
> And after looking it twice I cannot see the reason. I split that Cypress
> firmware download to own module called dvb_usb_cypress_firmware which
> offer routine usbv2_cypress_load_firmware(). Old DVB USB is left
> untouched. I can confirm it fails to compile for s2250, but there is
> still old dvb_usb_cxusb that is compiling without a error.
>
> Makefile paths seems to be correct also, no idea whats wrong

 drivers/media/usb/Makefile uses := instead of += for the dvb-usb(-v2) 
 directories,
 and that prevents dvb-usb from being build. I think that's the cause of 
 the link
 error.
>>>
>>> For that I cannot say as I don't understand situation enough.
>>>
 In addition I noticed that in usb/dvb-usb there is a dvb_usb_dvb.c and a
 dvb-usb-dvb.c file: there's a mixup with _ and -.
>>>
>>> These files seems to be my fault. Original patch series removes those,
>>> but I was forced to rebase whole set and in that rebased set those are left 
>>> unremoved.
>>> Likely due to some rebase conflict. I will send new patch to remove those.
>>
>> If you remove the _, they'll conflict with dvb-usb at media-build.git.
>>
>> The better is to add a _v2 (or -v2) on all dvb-usb-v2 files
>> (or to convert the remaining dvb-usb drivers to dvb-usb-v2).
> 
> hmm, now I am quite out what you mean.
> 
> This is from my first PULL-request:
> http://git.linuxtv.org/anttip/media_tree.git/commit/c60c6d44111be2b2fd9ef9b716ea50bd87493893
> 
> And this is same patch after large rebase:
> http://git.linuxtv.org/anttip/media_tree.git/commit/ac97c6f722aafb5b562ef04062b543147399dff8
> 
> Why removing those wrong files will cause conflict in media_build.git ?

Because, at the media-build, all files are linked into the "/v4l" dir. If there 
are two different
modules with the same name, one will override the other.
> 
> 
> 
> OK, those are just wasting space nothing more. But there was that original 
> problem too which breaks s2250-loader compilation.
> 
> regards
> Antti
> 
>>
>> Regards,
>> Mauro
>>
>>>
 Mauro, did that happen during the reorganization?

 Regards,

  Hans

>>>
>>> regards
>>> Antti
>>>
>>
> 
> 

--
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-usb-v2 change broke s2250-loader compilation

2012-08-16 Thread Antti Palosaari 

On 08/16/2012 07:50 PM, Mauro Carvalho Chehab wrote:

Em 16-08-2012 11:29, Antti Palosaari escreveu:

On 08/16/2012 05:07 PM, Hans Verkuil wrote:

On Thu August 16 2012 15:45:47 Antti Palosaari wrote:

On 08/16/2012 03:18 PM, Antti Palosaari wrote:

On 08/16/2012 01:33 PM, Hans Verkuil wrote:

Building the kernel with the Sensoray 2250/2251 staging go7007 driver
enabled
fails with this link error:

ERROR: "usb_cypress_load_firmware"
[drivers/staging/media/go7007/s2250-loader.ko] undefined!

As far as I can tell this is related to the dvb-usb-v2 changes.

Can someone take a look at this?

Thanks!

  Hans


Yes it is dvb usb v2 related. I wasn't even aware that someone took that
module use in few days after it was added for the dvb-usb-v2.

Maybe it is worth to make it even more common and move out of dvb-usb-v2...

regards
Antti


And after looking it twice I cannot see the reason. I split that Cypress
firmware download to own module called dvb_usb_cypress_firmware which
offer routine usbv2_cypress_load_firmware(). Old DVB USB is left
untouched. I can confirm it fails to compile for s2250, but there is
still old dvb_usb_cxusb that is compiling without a error.

Makefile paths seems to be correct also, no idea whats wrong


drivers/media/usb/Makefile uses := instead of += for the dvb-usb(-v2) 
directories,
and that prevents dvb-usb from being build. I think that's the cause of the link
error.


For that I cannot say as I don't understand situation enough.


In addition I noticed that in usb/dvb-usb there is a dvb_usb_dvb.c and a
dvb-usb-dvb.c file: there's a mixup with _ and -.


These files seems to be my fault. Original patch series removes those,
but I was forced to rebase whole set and in that rebased set those are left 
unremoved.
Likely due to some rebase conflict. I will send new patch to remove those.


If you remove the _, they'll conflict with dvb-usb at media-build.git.

The better is to add a _v2 (or -v2) on all dvb-usb-v2 files
(or to convert the remaining dvb-usb drivers to dvb-usb-v2).


hmm, now I am quite out what you mean.

This is from my first PULL-request:
http://git.linuxtv.org/anttip/media_tree.git/commit/c60c6d44111be2b2fd9ef9b716ea50bd87493893

And this is same patch after large rebase:
http://git.linuxtv.org/anttip/media_tree.git/commit/ac97c6f722aafb5b562ef04062b543147399dff8

Why removing those wrong files will cause conflict in media_build.git ?



OK, those are just wasting space nothing more. But there was that 
original problem too which breaks s2250-loader compilation.


regards
Antti



Regards,
Mauro




Mauro, did that happen during the reorganization?

Regards,

 Hans



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-usb-v2 change broke s2250-loader compilation

2012-08-16 Thread Mauro Carvalho Chehab 
Em 16-08-2012 11:29, Antti Palosaari escreveu:
> On 08/16/2012 05:07 PM, Hans Verkuil wrote:
>> On Thu August 16 2012 15:45:47 Antti Palosaari wrote:
>>> On 08/16/2012 03:18 PM, Antti Palosaari wrote:
 On 08/16/2012 01:33 PM, Hans Verkuil wrote:
> Building the kernel with the Sensoray 2250/2251 staging go7007 driver
> enabled
> fails with this link error:
>
> ERROR: "usb_cypress_load_firmware"
> [drivers/staging/media/go7007/s2250-loader.ko] undefined!
>
> As far as I can tell this is related to the dvb-usb-v2 changes.
>
> Can someone take a look at this?
>
> Thanks!
>
>  Hans

 Yes it is dvb usb v2 related. I wasn't even aware that someone took that
 module use in few days after it was added for the dvb-usb-v2.

 Maybe it is worth to make it even more common and move out of dvb-usb-v2...

 regards
 Antti
>>>
>>> And after looking it twice I cannot see the reason. I split that Cypress
>>> firmware download to own module called dvb_usb_cypress_firmware which
>>> offer routine usbv2_cypress_load_firmware(). Old DVB USB is left
>>> untouched. I can confirm it fails to compile for s2250, but there is
>>> still old dvb_usb_cxusb that is compiling without a error.
>>>
>>> Makefile paths seems to be correct also, no idea whats wrong
>>
>> drivers/media/usb/Makefile uses := instead of += for the dvb-usb(-v2) 
>> directories,
>> and that prevents dvb-usb from being build. I think that's the cause of the 
>> link
>> error.
> 
> For that I cannot say as I don't understand situation enough.
> 
>> In addition I noticed that in usb/dvb-usb there is a dvb_usb_dvb.c and a
>> dvb-usb-dvb.c file: there's a mixup with _ and -.
> 
> These files seems to be my fault. Original patch series removes those, 
> but I was forced to rebase whole set and in that rebased set those are left 
> unremoved. 
> Likely due to some rebase conflict. I will send new patch to remove those.

If you remove the _, they'll conflict with dvb-usb at media-build.git.

The better is to add a _v2 (or -v2) on all dvb-usb-v2 files
(or to convert the remaining dvb-usb drivers to dvb-usb-v2).

Regards,
Mauro

> 
>> Mauro, did that happen during the reorganization?
>>
>> Regards,
>>
>> Hans
>>
> 
> regards
> Antti
> 

--
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: [git:v4l-dvb/for_v3.7] [media] media: rc: Introduce RX51 IR transmitter driver

2012-08-16 Thread Timo Kokkonen 
On 08/16/12 19:34, Sakari Ailus wrote:
> Hi Sebastian,
> 
> On Thu, Aug 16, 2012 at 01:21:04PM +0200, Sebastian Reichel wrote:
>> Hi,
>>
 It was an requirement back then that this driver needs to be a module as
 99% of the N900 owners still don't even know they have this kind of
 capability on their devices, so it doesn't make sense to keep the module
 loaded unless the user actually needs it.
>>>
>>> I don't think that's so important --- currently the vast majority of the
>>> N900 users using the mainline kernel compile it themselves. It's more
>>> important to have a clean implementation at this point.
>>
>> I would like to enable this feature for the Debian OMAP kernel,
>> which is not only used for N900, but also for Pandaboard, etc.
> 
> Fair enough. Thanks for the info!
> 
> Timo: thinking this a little more, do you think the call is really needed?
> AFAIU it doesn't really achieve what it's supposed to, keeping the CPU from
> going to sleep. I noticed exactly the same problem you did, it was bad to
> the extent irsend failed due to a timeout unless I kept the CPU busy.

Yes, that's right. It's not really useful as is.

> So I think we can remove the call, which results in two things: the driver
> can be built as a module and the platform data does not contain a function
> pointer any longer.

Yeah, I agree. Although with the original N900 kernel the call did make
it work. But the power management implementation was different there
too. Maybe the proper fix for the problem is today something different
it was back then.

If I have time I'll see if I can figure out something..

-Timo

--
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] dvb_frontend: Multistream support

2012-08-16 Thread Antti Palosaari 

On 08/16/2012 08:46 PM, CrazyCat wrote:

DTV_ISDBS_TS_ID replaced with DTV_STREAM_ID.
Aliases DTV_ISDBS_TS_ID, DTV_DVBS2_MIS_ID for DTV_STREAM_ID.
DTV_DVBT2_PLP_ID marked as legacy.

Signed-off-by: Evgeny Plehov 
diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
index f50d405..3444dda 100644
--- a/include/linux/dvb/frontend.h
+++ b/include/linux/dvb/frontend.h
@@ -62,6 +62,7 @@ typedef enum fe_caps {
  FE_CAN_8VSB = 0x20,
  FE_CAN_16VSB = 0x40,
  FE_HAS_EXTENDED_CAPS = 0x80,   /* We need more bitspace for newer 
APIs, indicate this. */
+ FE_CAN_MULTISTREAM = 0x400,  /* frontend supports DVB-S2 multistream 
filtering */
  FE_CAN_TURBO_FEC = 0x800,  /* frontend supports "turbo fec 
modulation" */
  FE_CAN_2G_MODULATION = 0x1000, /* frontend supports "2nd generation 
modulation" (DVB-S2) */
  FE_NEEDS_BENDING = 0x2000, /* not supported anymore, don't use 
(frontend requires frequency bending) */
@@ -314,9 +315,11 @@ struct dvb_frontend_event {

  #define DTV_ISDBT_LAYER_ENABLED 41

-#define DTV_ISDBS_TS_ID 42
+#define DTV_STREAM_ID 42
+#define DTV_ISDBS_TS_ID DTV_STREAM_ID
+#define DTV_DVBS2_MIS_ID DTV_STREAM_ID


@Mauro, should we rename also DTV_ISDBS_TS_ID to DTV_ISDBS_TS_ID_LEGACY 
to remind users ?



-#define DTV_DVBT2_PLP_ID 43
+#define DTV_DVBT2_PLP_ID_LEGACY 43

  #define DTV_ENUM_DELSYS 44

diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.h 
b/drivers/media/dvb/dvb-core/dvb_frontend.h
index 7c64c09..bec0cda 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.h
@@ -368,11 +368,8 @@ struct dtv_frontend_properties {
  u8 interleaving;
  } layer[3];

- /* ISDB-T specifics */
- u32 isdbs_ts_id;
-
- /* DVB-T2 specifics */
- u32 dvbt2_plp_id;
+ /* Multistream specifics */
+ u32 stream_id;


u32 == 32 bit long unsigned number. See next comment.



  /* ATSC-MH specifics */
  u8 atscmh_fic_ver;
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index aebcdf2..bccd245 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -946,8 +946,7 @@ static int dvb_frontend_clear_cache(struct dvb_frontend *fe)
  c->layer[i].segment_count = 0;
  }

- c->isdbs_ts_id = 0;
- c->dvbt2_plp_id = 0;
+ c->stream_id = -1;


unsigned number cannot be -1. It can be only 0 or bigger. Due to that 
this is wrong.




  switch (c->delivery_system) {
  case SYS_DVBS:
@@ -1017,8 +1016,8 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND + 1] = {
  _DTV_CMD(DTV_ISDBT_LAYERC_SEGMENT_COUNT, 1, 0),
  _DTV_CMD(DTV_ISDBT_LAYERC_TIME_INTERLEAVING, 1, 0),

- _DTV_CMD(DTV_ISDBS_TS_ID, 1, 0),
- _DTV_CMD(DTV_DVBT2_PLP_ID, 1, 0),
+ _DTV_CMD(DTV_STREAM_ID, 1, 0),
+ _DTV_CMD(DTV_DVBT2_PLP_ID_LEGACY, 1, 0),

  /* Get */
  _DTV_CMD(DTV_DISEQC_SLAVE_REPLY, 0, 1),
@@ -1382,11 +1381,10 @@ static int dtv_property_process_get(struct dvb_frontend 
*fe,
  case DTV_ISDBT_LAYERC_TIME_INTERLEAVING:
  tvp->u.data = c->layer[2].interleaving;
  break;
- case DTV_ISDBS_TS_ID:
- tvp->u.data = c->isdbs_ts_id;
- break;
- case DTV_DVBT2_PLP_ID:
- tvp->u.data = c->dvbt2_plp_id;
+
+ case DTV_STREAM_ID:
+ case DTV_DVBT2_PLP_ID_LEGACY:
+ tvp->u.data = c->stream_id;
  break;

  /* ATSC-MH */
@@ -1771,11 +1769,10 @@ static int dtv_property_process_set(struct dvb_frontend 
*fe,
  case DTV_ISDBT_LAYERC_TIME_INTERLEAVING:
  c->layer[2].interleaving = tvp->u.data;
  break;
- case DTV_ISDBS_TS_ID:
- c->isdbs_ts_id = tvp->u.data;
- break;
- case DTV_DVBT2_PLP_ID:
- c->dvbt2_plp_id = tvp->u.data;
+
+ case DTV_STREAM_ID:
+ case DTV_DVBT2_PLP_ID_LEGACY:
+ c->stream_id = tvp->u.data;
  break;

  /* ATSC-MH */


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: [RFCv3 PATCH 3/8] v4l2-subdev: add support for the new edid ioctls.

2012-08-16 Thread Soby Mathew 
Hi Hans,
   For EDID update, it is recommended that the HPD line be toggled
after the EDID update is completed. So for the driver to detect the
EDID write is complete, probably a field mentioning the EDID write
completed would be good, so that the HPD toggling can be done by the
driver.

Best Regards
Soby Mathew

On 8/10/12, Hans Verkuil  wrote:
> Signed-off-by: Hans Verkuil 
> ---
>  drivers/media/video/v4l2-compat-ioctl32.c |   57
> +
>  drivers/media/video/v4l2-ioctl.c  |   13 +++
>  drivers/media/video/v4l2-subdev.c |6 +++
>  include/media/v4l2-subdev.h   |2 +
>  4 files changed, 78 insertions(+)
>
> diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
> b/drivers/media/video/v4l2-compat-ioctl32.c
> index 9ebd5c5..e843705 100644
> --- a/drivers/media/video/v4l2-compat-ioctl32.c
> +++ b/drivers/media/video/v4l2-compat-ioctl32.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>
> @@ -729,6 +730,44 @@ static int put_v4l2_event32(struct v4l2_event *kp,
> struct v4l2_event32 __user *u
>   return 0;
>  }
>
> +struct v4l2_subdev_edid32 {
> + __u32 pad;
> + __u32 start_block;
> + __u32 blocks;
> + __u32 reserved[5];
> + compat_caddr_t edid;
> +};
> +
> +static int get_v4l2_subdev_edid32(struct v4l2_subdev_edid *kp, struct
> v4l2_subdev_edid32 __user *up)
> +{
> + u32 tmp;
> +
> + if (!access_ok(VERIFY_READ, up, sizeof(struct v4l2_subdev_edid32)) ||
> + get_user(kp->pad, &up->pad) ||
> + get_user(kp->start_block, &up->start_block) ||
> + get_user(kp->blocks, &up->blocks) ||
> + get_user(tmp, &up->edid) ||
> + copy_from_user(kp->reserved, up->reserved, 
> sizeof(kp->reserved)))
> + return -EFAULT;
> + kp->edid = compat_ptr(tmp);
> + return 0;
> +}
> +
> +static int put_v4l2_subdev_edid32(struct v4l2_subdev_edid *kp, struct
> v4l2_subdev_edid32 __user *up)
> +{
> + u32 tmp = (u32)((unsigned long)kp->edid);
> +
> + if (!access_ok(VERIFY_WRITE, up, sizeof(struct v4l2_subdev_edid32)) ||
> + put_user(kp->pad, &up->pad) ||
> + put_user(kp->start_block, &up->start_block) ||
> + put_user(kp->blocks, &up->blocks) ||
> + put_user(tmp, &up->edid) ||
> + copy_to_user(kp->reserved, up->reserved, sizeof(kp->reserved)))
> + return -EFAULT;
> + return 0;
> +}
> +
> +
>  #define VIDIOC_G_FMT32   _IOWR('V',  4, struct v4l2_format32)
>  #define VIDIOC_S_FMT32   _IOWR('V',  5, struct v4l2_format32)
>  #define VIDIOC_QUERYBUF32_IOWR('V',  9, struct v4l2_buffer32)
> @@ -738,6 +777,8 @@ static int put_v4l2_event32(struct v4l2_event *kp,
> struct v4l2_event32 __user *u
>  #define VIDIOC_DQBUF32   _IOWR('V', 17, struct v4l2_buffer32)
>  #define VIDIOC_ENUMSTD32 _IOWR('V', 25, struct v4l2_standard32)
>  #define VIDIOC_ENUMINPUT32   _IOWR('V', 26, struct v4l2_input32)
> +#define VIDIOC_SUBDEV_G_EDID32   _IOWR('V', 63, struct 
> v4l2_subdev_edid32)
> +#define VIDIOC_SUBDEV_S_EDID32   _IOWR('V', 64, struct 
> v4l2_subdev_edid32)
>  #define VIDIOC_TRY_FMT32 _IOWR('V', 64, struct v4l2_format32)
>  #define VIDIOC_G_EXT_CTRLS32_IOWR('V', 71, struct v4l2_ext_controls32)
>  #define VIDIOC_S_EXT_CTRLS32_IOWR('V', 72, struct v4l2_ext_controls32)
> @@ -765,6 +806,7 @@ static long do_video_ioctl(struct file *file, unsigned
> int cmd, unsigned long ar
>   struct v4l2_ext_controls v2ecs;
>   struct v4l2_event v2ev;
>   struct v4l2_create_buffers v2crt;
> + struct v4l2_subdev_edid v2edid;
>   unsigned long vx;
>   int vi;
>   } karg;
> @@ -797,6 +839,8 @@ static long do_video_ioctl(struct file *file, unsigned
> int cmd, unsigned long ar
>   case VIDIOC_S_OUTPUT32: cmd = VIDIOC_S_OUTPUT; break;
>   case VIDIOC_CREATE_BUFS32: cmd = VIDIOC_CREATE_BUFS; break;
>   case VIDIOC_PREPARE_BUF32: cmd = VIDIOC_PREPARE_BUF; break;
> + case VIDIOC_SUBDEV_G_EDID32: cmd = VIDIOC_SUBDEV_G_EDID; break;
> + case VIDIOC_SUBDEV_S_EDID32: cmd = VIDIOC_SUBDEV_S_EDID; break;
>   }
>
>   switch (cmd) {
> @@ -814,6 +858,12 @@ static long do_video_ioctl(struct file *file, unsigned
> int cmd, unsigned long ar
>   compatible_arg = 0;
>   break;
>
> + case VIDIOC_SUBDEV_G_EDID:
> + case VIDIOC_SUBDEV_S_EDID:
> + err = get_v4l2_subdev_edid32(&karg.v2edid, up);
> + compatible_arg = 0;
> + break;
> +
>   case VIDIOC_G_FMT:
>   case VIDIOC_S_FMT:
>   case VIDIOC_TRY_FMT:
> @@ -906,6 +956,11 @@ static long do_video_ioctl(struct file *file, unsigned
> int cmd, unsigned long ar
>   err = put_v4l2_event32(&karg.v2ev, up);
>   break;
>
> + case VIDIOC_SUBDEV_G_EDID:
> + case VIDIOC_

[PATCH] stv090x: Multistream support

2012-08-16 Thread CrazyCat 
DVB-S2 Multistream support for stv090x

Signed-off-by: Evgeny Plehov 
diff --git a/drivers/media/dvb/frontends/stv090x.c 
b/drivers/media/dvb/frontends/stv090x.c
index ea86a56..13caec0 100644
--- a/drivers/media/dvb/frontends/stv090x.c
+++ b/drivers/media/dvb/frontends/stv090x.c
@@ -3425,6 +3425,33 @@ err:
return -1;
 }
 
+static int stv090x_set_mis(struct stv090x_state *state, int mis)
+{
+   u32 reg;
+
+   if (mis < 0 || mis > 255) {
+   dprintk(FE_DEBUG, 1, "Disable MIS filtering");
+   reg = STV090x_READ_DEMOD(state, PDELCTRL1);
+   STV090x_SETFIELD_Px(reg, FILTER_EN_FIELD, 0x00);
+   if (STV090x_WRITE_DEMOD(state, PDELCTRL1, reg) < 0)
+   goto err;
+   } else {
+   dprintk(FE_DEBUG, 1, "Enable MIS filtering - %d", mis);
+   reg = STV090x_READ_DEMOD(state, PDELCTRL1);
+   STV090x_SETFIELD_Px(reg, FILTER_EN_FIELD, 0x01);
+   if (STV090x_WRITE_DEMOD(state, PDELCTRL1, reg) < 0)
+   goto err;
+   if (STV090x_WRITE_DEMOD(state, ISIENTRY, mis) < 0)
+   goto err;
+   if (STV090x_WRITE_DEMOD(state, ISIBITENA, 0xff) < 0)
+   goto err;
+   }
+   return 0;
+err:
+   dprintk(FE_ERROR, 1, "I/O error");
+   return -1;
+}
+
 static enum dvbfe_search stv090x_search(struct dvb_frontend *fe)
 {
struct stv090x_state *state = fe->demodulator_priv;
@@ -3447,6 +3474,8 @@ static enum dvbfe_search stv090x_search(struct 
dvb_frontend *fe)
state->search_range = 500;
}
 
+   stv090x_set_mis(state, props->stream_id);
+
if (stv090x_algo(state) == STV090x_RANGEOK) {
dprintk(FE_DEBUG, 1, "Search success!");
return DVBFE_ALGO_SEARCH_SUCCESS;
@@ -4798,6 +4827,9 @@ struct dvb_frontend *stv090x_attach(const struct 
stv090x_config *config,
}
}
 
+   if (state->internal->dev_ver >= 0x30)
+   state->frontend.ops.info.caps |= FE_CAN_MULTISTREAM;
+
/* workaround for stuck DiSEqC output */
if (config->diseqc_envelope_mode)
stv090x_send_diseqc_burst(&state->frontend, SEC_MINI_A);
--
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] dvb_frontend: Multistream support

2012-08-16 Thread CrazyCat 
DTV_ISDBS_TS_ID replaced with DTV_STREAM_ID.
Aliases DTV_ISDBS_TS_ID, DTV_DVBS2_MIS_ID for DTV_STREAM_ID.
DTV_DVBT2_PLP_ID marked as legacy.

Signed-off-by: Evgeny Plehov 
diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
index f50d405..3444dda 100644
--- a/include/linux/dvb/frontend.h
+++ b/include/linux/dvb/frontend.h
@@ -62,6 +62,7 @@ typedef enum fe_caps {
 FE_CAN_8VSB = 0x20,
 FE_CAN_16VSB = 0x40,
 FE_HAS_EXTENDED_CAPS = 0x80,   /* We need more bitspace for newer 
APIs, indicate this. */
+ FE_CAN_MULTISTREAM = 0x400,  /* frontend supports DVB-S2 multistream 
filtering */
 FE_CAN_TURBO_FEC = 0x800,  /* frontend supports "turbo fec 
modulation" */
 FE_CAN_2G_MODULATION = 0x1000, /* frontend supports "2nd 
generation modulation" (DVB-S2) */
 FE_NEEDS_BENDING = 0x2000, /* not supported anymore, don't use 
(frontend requires frequency bending) */
@@ -314,9 +315,11 @@ struct dvb_frontend_event {

 #define DTV_ISDBT_LAYER_ENABLED 41

-#define DTV_ISDBS_TS_ID 42
+#define DTV_STREAM_ID 42
+#define DTV_ISDBS_TS_ID DTV_STREAM_ID
+#define DTV_DVBS2_MIS_ID DTV_STREAM_ID

-#define DTV_DVBT2_PLP_ID 43
+#define DTV_DVBT2_PLP_ID_LEGACY 43

 #define DTV_ENUM_DELSYS 44

diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.h 
b/drivers/media/dvb/dvb-core/dvb_frontend.h
index 7c64c09..bec0cda 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.h
@@ -368,11 +368,8 @@ struct dtv_frontend_properties {
 u8 interleaving;
 } layer[3];

- /* ISDB-T specifics */
- u32 isdbs_ts_id;
-
- /* DVB-T2 specifics */
- u32 dvbt2_plp_id;
+ /* Multistream specifics */
+ u32 stream_id;

 /* ATSC-MH specifics */
 u8 atscmh_fic_ver;
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index aebcdf2..bccd245 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -946,8 +946,7 @@ static int dvb_frontend_clear_cache(struct dvb_frontend *fe)
 c->layer[i].segment_count = 0;
 }

- c->isdbs_ts_id = 0;
- c->dvbt2_plp_id = 0;
+ c->stream_id = -1;

 switch (c->delivery_system) {
 case SYS_DVBS:
@@ -1017,8 +1016,8 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND + 1] = {
 _DTV_CMD(DTV_ISDBT_LAYERC_SEGMENT_COUNT, 1, 0),
 _DTV_CMD(DTV_ISDBT_LAYERC_TIME_INTERLEAVING, 1, 0),

- _DTV_CMD(DTV_ISDBS_TS_ID, 1, 0),
- _DTV_CMD(DTV_DVBT2_PLP_ID, 1, 0),
+ _DTV_CMD(DTV_STREAM_ID, 1, 0),
+ _DTV_CMD(DTV_DVBT2_PLP_ID_LEGACY, 1, 0),

 /* Get */
 _DTV_CMD(DTV_DISEQC_SLAVE_REPLY, 0, 1),
@@ -1382,11 +1381,10 @@ static int dtv_property_process_get(struct dvb_frontend 
*fe,
 case DTV_ISDBT_LAYERC_TIME_INTERLEAVING:
 tvp->u.data = c->layer[2].interleaving;
 break;
- case DTV_ISDBS_TS_ID:
- tvp->u.data = c->isdbs_ts_id;
- break;
- case DTV_DVBT2_PLP_ID:
- tvp->u.data = c->dvbt2_plp_id;
+
+ case DTV_STREAM_ID:
+ case DTV_DVBT2_PLP_ID_LEGACY:
+ tvp->u.data = c->stream_id;
 break;

 /* ATSC-MH */
@@ -1771,11 +1769,10 @@ static int dtv_property_process_set(struct dvb_frontend 
*fe,
 case DTV_ISDBT_LAYERC_TIME_INTERLEAVING:
 c->layer[2].interleaving = tvp->u.data;
 break;
- case DTV_ISDBS_TS_ID:
- c->isdbs_ts_id = tvp->u.data;
- break;
- case DTV_DVBT2_PLP_ID:
- c->dvbt2_plp_id = tvp->u.data;
+
+ case DTV_STREAM_ID:
+ case DTV_DVBT2_PLP_ID_LEGACY:
+ c->stream_id = tvp->u.data;
 break;

 /* ATSC-MH */
--
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: [GIT PULL] ViewCast O820E capture support added

2012-08-16 Thread Steven Toth 
>> So, I've ran v4l2-compliance and it pointed out a few things that I've
>> fixed, but it also does a few things that (for some reason) I can't
>> seem to catch. One particular test is on (iirc) s_fmt. It attempts to
>> set ATSC but by ioctl callback never receives ATSC in the norm/id arg,
>> it actually receives 0x0. This feels more like a bug in the test.
>> Either way, I have some if (std & ATSC) return -EINVAL, but it still
>> appears to fail the test.

Oddly enough. If I set tvnorms to something valid, then compliance
passes but gstreamer
fails to run, looks like some kind of confusion about either the
current established
norm, or a failure to establish a norm.

For the time being I've set tvnorms to 0 (with a comment) and removed
current_norm.

>
> I think it might be because vdev->tvnorms isn't set for the video node.
> It's set for the VBI node, though. If tvnorms is 0, then ENUMSTD will
> probably return an empty list, and that might be the cause of the ATSC
> test. I also see that current_norm is used: don't do that. Instead store
> the current standard yourself and return it in g_std. I'm slowly phasing
> out current_norm because 1) it's ugly and 2) it doesn't work if you have
> both a vbi and a video node.

Done.

>
>> I see some tests which report failure (testing videobuf) but given
>> that I essentially pass the ioctl directly into the videbug core, very
>> much like every oher driver I've ever done, it's probably either a
>> quirk of the tool, or something inside videobuf core itself that needs
>> some adjustment. (userptr/mmap for capture or output buffers related
>> test).
>
> videobuf does not follow the spec in several areas (most notably and extremely
> annoyingly it does not support calling REQBUFS with a count of 0). So any
> driver that uses videobuf will fail a number of tests in v4l2-compliance.

Compliance as of today (with changes), now gives:

"Buffer ioctls:
fail: v4l2-test-buffers.cpp(76): can_stream && !mmap_valid && 
!userptr_valid
test VIDIOC_REQBUFS/CREATE_BUFS: FAIL
test read/write: OK"


>
> These problems are fixed in vb2, which is why I strongly recommend its use in
> new drivers. In addition, work on the new DMABUF mechanism for sharing buffers
> between v4l2 and drm will only be implemented in vb2.
>
>> In summary, the v4l2-compliance tool has pointed out a few things that
>> were worth fixing for sure, and thus I've fixed. It it also feels like
>> the tool itself is still evolving. When I get a moment I'll run the
>> compliance tool and paste the results here for comment.
>
> It is steadily being improved, that's correct.
>
> BTW, don't forget to also run it for the vbi node (option '-V /dev/vbiX').

It's got a couple more failures I need to take care of, nothing huge.

>
> Feedback on the tool is very much appreciated! E.g. how to improve it, whether
> there are missing, confusing or incorrect tests, etc.
>
>> I'd welcome your feedback on the compliance feedback.
>
> No problem. One set of errors that v4l2-compliance produces is that it fails
> if you can change VBI formats using a video node or vice versa. I want to
> address that in the V4L2 core rather than having to fix all drivers. It's one
> of the topics in the V4L2 ambiguities list for the upcoming workshop.
>
>> > Take a look at vivi.c: it implements all the latest infrastructure and it
>> > is now actually a pretty good example of how things should work.
>>
>> Noted, that's a useful reference point.
>>
>> >
>> > It's also one of the few drivers that passes all v4l2-compliance tests.
>> >
>> > The only ioctls that aren't covered yet by v4l2-compliance are:
>> >
>> >VIDIOC_CROPCAP, VIDIOC_G/S_CROP, VIDIOC_G/S_SELECTION
>> >VIDIOC_S_FBUF/OVERLAY
>> >VIDIOC_(TRY_)ENCODER_CMD
>> >VIDIOC_(TRY_)DECODER_CMD
>> >VIDIOC_G_ENC_INDEX
>> >VIDIOC_QBUF/DQBUF/QUERYBUF/PREPARE_BUFS
>> >VIDIOC_STREAMON/OFF
>> >
>> > So basically cropping, compression encoder/decoder control and actual
>> > streaming. And the subdev and media API is also not tested, although
>> > those might be beyond the scope of this utility anyway.
>> >
>> > Everything else is now tested fairly exhaustively.
>> >
>> >> 2) ... and some larger discussion items have been raised, Eg.
>> >> Absorbing more of the V4L2 kernel infrastructure into the vc8x0 driver
>> >> vs a fairly self-contained driver with very limited opportunities for
>> >> future breakage.
>> >>
>> >> Are you really willing to say that all drivers, with unique and new
>> >> pieces of silicon, need to be split out into independent modules,
>> >> adopting a subdev type interfaces or mainline merge is refused? It's
>> >> not that I'm asking you to merge duplicate functionality, duplicate
>> >> driver code, replicating functionality for new hardware or for an
>> >> existing modules (tuner/demod/whatever). (Like has already happened in
>> >> the past - 18271 for example).
>> >
>>

Re: [PATCH 2/2] marvell-cam: Build fix: missing "select VIDEOBUF2_VMALLOC"

2012-08-16 Thread Jonathan Corbet 
On Mon, 13 Aug 2012 19:40:08 -0300
Mauro Carvalho Chehab  wrote:

> Ping?
> 
> Is this patch needed or not?

Sorry, I have dropped vast numbers of balls over the last six months and
am far from having picked them all up.

Reviewing the conversation, I still must confess that I don't understand
the problem.  Why is having the VB2 vmalloc support built as a module a
problem?  

> Another alternative would be to change the Kconfig stuff to explicitly select
> the type of videobuf2 that would be used by those drivers, something like the
> enclosed (untested) patch.

The current Kconfig already has specific select lines for the supported
modes.  

When I get a chance, I'll go in and try to reproduce the problem, but it
may be a little bit, sorry...

jon
--
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] smiapp: Use devm_kzalloc() in smiapp-core.c file

2012-08-16 Thread Sakari Ailus 
Hi Sachin,

Thanks for the patch.

On Thu, Aug 16, 2012 at 04:59:30PM +0530, Sachin Kamat wrote:
> devm_kzalloc is a device managed function and makes code a bit
> smaller and cleaner.
> 
> Signed-off-by: Sachin Kamat 
> ---
> This patch is based on Mauro's re-organized tree
> (media_tree staging/for_v3.7) and is compile tested.
> ---
>  drivers/media/i2c/smiapp/smiapp-core.c |   11 ++-
>  1 files changed, 2 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
> b/drivers/media/i2c/smiapp/smiapp-core.c
> index 1cf914d..7d4280e 100644
> --- a/drivers/media/i2c/smiapp/smiapp-core.c
> +++ b/drivers/media/i2c/smiapp/smiapp-core.c
> @@ -2801,12 +2801,11 @@ static int smiapp_probe(struct i2c_client *client,
>   const struct i2c_device_id *devid)
>  {
>   struct smiapp_sensor *sensor;
> - int rval;
>  
>   if (client->dev.platform_data == NULL)
>   return -ENODEV;
>  
> - sensor = kzalloc(sizeof(*sensor), GFP_KERNEL);
> + sensor = devm_kzalloc(&client->dev, sizeof(*sensor), GFP_KERNEL);
>   if (sensor == NULL)
>   return -ENOMEM;
>  

I think the same should be done to sensor->nvm. Would you like to change the
patch to incorporate the change? I'm fine doing that as well.

Cheers,

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: 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: [git:v4l-dvb/for_v3.7] [media] media: rc: Introduce RX51 IR transmitter driver

2012-08-16 Thread Sakari Ailus 
Hi Sebastian,

On Thu, Aug 16, 2012 at 01:21:04PM +0200, Sebastian Reichel wrote:
> Hi,
> 
> > > It was an requirement back then that this driver needs to be a module as
> > > 99% of the N900 owners still don't even know they have this kind of
> > > capability on their devices, so it doesn't make sense to keep the module
> > > loaded unless the user actually needs it.
> > 
> > I don't think that's so important --- currently the vast majority of the
> > N900 users using the mainline kernel compile it themselves. It's more
> > important to have a clean implementation at this point.
> 
> I would like to enable this feature for the Debian OMAP kernel,
> which is not only used for N900, but also for Pandaboard, etc.

Fair enough. Thanks for the info!

Timo: thinking this a little more, do you think the call is really needed?
AFAIU it doesn't really achieve what it's supposed to, keeping the CPU from
going to sleep. I noticed exactly the same problem you did, it was bad to
the extent irsend failed due to a timeout unless I kept the CPU busy.

So I think we can remove the call, which results in two things: the driver
can be built as a module and the platform data does not contain a function
pointer any longer.

Cheers,

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: 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] davinci: vpfe: Add documentation

2012-08-16 Thread Sakari Ailus 
Hi Manju,

On Thu, Aug 09, 2012 at 09:13:52AM +0530, Manjunath Hadli wrote:
> Hi Sakari,
>  
>  Thank you for the comments.

Thanks for the graphs!

> On Thursday 02 August 2012 05:37 AM, Sakari Ailus wrote:
> > Hi Manju,
> >
> > Thanks for the patch.
> >
> > Please make sure these patches reach linux-media next time. If they do
> > not,
> > it severely limits the number of potential reviewers. I don't know
> > why, but
> > the original patch isn't on linux-media even if the list was cc'd.
> >
> > Dropping linux-kernel from cc.
> >
> > Manjunath Hadli wrote:
> >> Add documentation on the Davinci VPFE driver. Document the subdevs,
> >> and private IOTCLs the driver implements
> >>
> >> Signed-off-by: Manjunath Hadli 
> >> Signed-off-by: Lad, Prabhakar 
> >> ---
> >>   Documentation/video4linux/davinci-vpfe-mc.txt |  263
> >> +
> >>   1 files changed, 263 insertions(+), 0 deletions(-)
> >>   create mode 100644 Documentation/video4linux/davinci-vpfe-mc.txt
> >>
> >> diff --git a/Documentation/video4linux/davinci-vpfe-mc.txt
> >> b/Documentation/video4linux/davinci-vpfe-mc.txt
> >> new file mode 100644
> >> index 000..968194f
> >> --- /dev/null
> >> +++ b/Documentation/video4linux/davinci-vpfe-mc.txt
> >> @@ -0,0 +1,263 @@
> >> +Davinci Video processing Front End (VPFE) driver
> >> +
> >> +Copyright (C) 2012 Texas Instruments Inc
> >> +
> >> +Contacts: Manjunath Hadli 
> >> +
> >> +Introduction
> >> +
> >> +
> >> +This file documents the Texas Instruments Davinci Video processing
> >> Front End
> >> +(VPFE) driver located under drivers/media/video/davinci. The
> >> original driver
> >> +exists for Davinci VPFE, which is now being changed to Media Controller
> >> +Framework.
> >> +
> >> +Currently the driver has been successfully used on the following
> >> version of Davinci:
> >> +
> >> +DM365/DM368
> >> +
> >> +The driver implements V4L2, Media controller and v4l2_subdev
> >> interfaces.
> >> +Sensor, lens and flash drivers using the v4l2_subdev interface in
> >> the kernel
> >> +are supported.
> >> +
> >> +
> >> +Split to subdevs
> >> +
> >> +
> >> +The Davinic VPFE is split into V4L2 subdevs, each of the blocks
> >> inside the VPFE
> >> +having one subdev to represent it. Each of the subdevs provide a
> >> V4L2 subdev
> >> +interface to userspace.
> >> +
> >> +DAVINCI CCDC
> >> +DAVINCI PREVIEWER
> >> +DAVINCI RESIZER
> >> +DAVINCI AEW
> >> +DAVINCI AF
> >> +
> >> +Each possible link in the VPFE is modeled by a link in the Media
> >> controller
> >> +interface. For an example program see [1].
> >> +
> >> +
> >> +Private IOCTLs
> >> +==
> >> +
> >> +The Davinci Video processing Front End (VPFE) driver supports
> >> standard V4L2
> >> +IOCTLs and controls where possible and practical. Much of the
> >> functions provided
> >> +by the VPFE, however, does not fall under the standard IOCTLs.
> >> +
> >> +In general, there is a private ioctl for configuring each of the blocks
> >> +containing hardware-dependent functions.
> >> +
> >> +The following private IOCTLs are supported:
> >> +
> >> +1: IOCTL: PREV_S_PARAM/PREV_G_PARAM
> >> +Description:
> >> +Sets/Gets the parameters required by the previewer module
> >> +Parameter:
> >> +/**
> >> + * struct prev_module_param- structure to configure preview modules
> >> + * @version: Version of the preview module
> >> + * @len: Length of the module config structure
> >> + * @module_id: Module id
> >> + * @param: pointer to module config parameter.
> >> + */
> >> +struct prev_module_param {
> >> +char version[IMP_MAX_NAME_SIZE];
> >> +unsigned short len;
> >> +unsigned short module_id;
> >> +void *param;
> >> +};
> >
> > In addition to what Laurent commented on this, could the version
> > information be passed in struct media_entity_desc instead?
> I plan to leave out the version.
> >
> > As a general comment, it's a bad idea to design an API that allows
> > passing
> > blobs, especially when the expected size of the blobs isn't known. That
> > really equals to asking for trouble.
> >
> > That said, I know this is an area where complete documentation is acarce,
> > but I think that at least the memory layout of the current blob pointers
> > should be visible in the struct definitions whenever possible. See
> > e.g. the
> > OMAP 3 ISP driver.
> I have proposed using a union of structures instead of the void  blob. 
> I also saw the OMAP implementation, and they are pointers (but not void). 
> To me the union approach looks better as it keeps the architecture
> intact and does not necessitate an
> explicit copy_from_user. Which of these ways do you suggest?

I would suggest to use the approach taken in the OMAP 3 ISP driver as it has
one obvious advantage over the union of pointers: it makes it possible to
perform atomic changes to the configuration.

However, changes to configuration done through controls and the

Re: [PATCH] [media] winbond-cir: Fix initialization

2012-08-16 Thread Greg KH 
On Tue, Jul 31, 2012 at 11:37:03AM +0100, Sean Young wrote:
> The serial driver will detect the winbond cir device as a serial port,
> since it looks exactly like a serial port unless you know what it is
> from the PNP ID.
> 
> Winbond CIR 00:04: Region 0x2f8-0x2ff already in use!
> Winbond CIR 00:04: disabled
> Winbond CIR: probe of 00:04 failed with error -16
> 
> Signed-off-by: Sean Young 
> ---
>  drivers/media/rc/winbond-cir.c | 21 -
>  drivers/tty/serial/8250/8250.c |  1 +
>  2 files changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/rc/winbond-cir.c b/drivers/media/rc/winbond-cir.c
> index 54ee348..20a0bbb 100644
> --- a/drivers/media/rc/winbond-cir.c
> +++ b/drivers/media/rc/winbond-cir.c
> @@ -55,6 +55,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #define DRVNAME "winbond-cir"
> @@ -957,6 +958,7 @@ wbcir_probe(struct pnp_dev *device, const struct 
> pnp_device_id *dev_id)
>   struct device *dev = &device->dev;
>   struct wbcir_data *data;
>   int err;
> + struct resource *io;
>  
>   if (!(pnp_port_len(device, 0) == EHFUNC_IOMEM_LEN &&
> pnp_port_len(device, 1) == WAKEUP_IOMEM_LEN &&
> @@ -1049,7 +1051,24 @@ wbcir_probe(struct pnp_dev *device, const struct 
> pnp_device_id *dev_id)
>   goto exit_release_wbase;
>   }
>  
> - if (!request_region(data->sbase, SP_IOMEM_LEN, DRVNAME)) {
> + io = request_region(data->sbase, SP_IOMEM_LEN, DRVNAME);
> +
> + /*
> +  * The winbond cir device looks exactly like an NS16550A serial port
> +  * unless you know what it is. We've got here via the PNP ID.
> +  */
> +#ifdef CONFIG_SERIAL_8250
> + if (!io) {
> + struct uart_port port = { .iobase = data->sbase };
> + int line = serial8250_find_port(&port);
> + if (line >= 0) {
> + serial8250_unregister_port(line);
> +
> + io = request_region(data->sbase, SP_IOMEM_LEN, DRVNAME);
> + }
> + }
> +#endif
> + if (!io) {
>   dev_err(dev, "Region 0x%lx-0x%lx already in use!\n",
>   data->sbase, data->sbase + SP_IOMEM_LEN - 1);
>   err = -EBUSY;
> diff --git a/drivers/tty/serial/8250/8250.c b/drivers/tty/serial/8250/8250.c
> index 5c27f7e..d38615f 100644
> --- a/drivers/tty/serial/8250/8250.c
> +++ b/drivers/tty/serial/8250/8250.c
> @@ -2914,6 +2914,7 @@ int serial8250_find_port(struct uart_port *p)
>   }
>   return -ENODEV;
>  }
> +EXPORT_SYMBOL(serial8250_find_port);

EXPORT_SYMBOL_GPL please.

But can't this be done as a quirk to the 8250 driver so that it just
does not bind to this device in the first place?  Wouldn't that make
more sense?

thanks,

greg k-h
--
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: davinci: vpif: add check for NULL handler

2012-08-16 Thread Laurent Pinchart 
Hi Prabhakar,

Thanks for the patch.

On Thursday 16 August 2012 19:32:00 Prabhakar Lad wrote:
> From: Lad, Prabhakar 
> 
> Signed-off-by: Lad, Prabhakar 
> Signed-off-by: Manjunath Hadli 
> Cc: Hans Verkuil 
> ---
>  drivers/media/video/davinci/vpif_capture.c |   12 +++-
>  drivers/media/video/davinci/vpif_display.c |   14 --
>  2 files changed, 15 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/media/video/davinci/vpif_capture.c
> b/drivers/media/video/davinci/vpif_capture.c index 266025e..a87b7a5 100644
> --- a/drivers/media/video/davinci/vpif_capture.c
> +++ b/drivers/media/video/davinci/vpif_capture.c
> @@ -311,12 +311,14 @@ static int vpif_start_streaming(struct vb2_queue *vq,
> unsigned int count) }
> 
>   /* configure 1 or 2 channel mode */
> - ret = vpif_config_data->setup_input_channel_mode
> - (vpif->std_info.ycmux_mode);
> + if (vpif_config_data->setup_input_channel_mode) {
> + ret = vpif_config_data->setup_input_channel_mode
> + (vpif->std_info.ycmux_mode);
> 
> - if (ret < 0) {
> - vpif_dbg(1, debug, "can't set vpif channel mode\n");
> - return ret;
> + if (ret < 0) {
> + vpif_dbg(1, debug, "can't set vpif channel mode\n");
> + return ret;
> + }

This change looks good to me. However, note that you will need to get rid of 
board code callbacks at some point to implement device tree support. It would 
be worth thinking about how to do so now.

>   }
> 
>   /* Call vpif_set_params function to set the parameters and addresses */
> diff --git a/drivers/media/video/davinci/vpif_display.c
> b/drivers/media/video/davinci/vpif_display.c index e129c98..1e35f92 100644
> --- a/drivers/media/video/davinci/vpif_display.c
> +++ b/drivers/media/video/davinci/vpif_display.c
> @@ -280,12 +280,14 @@ static int vpif_start_streaming(struct vb2_queue *vq,
> unsigned int count) }
> 
>   /* clock settings */
> - ret =
> - vpif_config_data->set_clock(ch->vpifparams.std_info.ycmux_mode,
> - ch->vpifparams.std_info.hd_sd);
> - if (ret < 0) {
> - vpif_err("can't set clock\n");
> - return ret;
> + if (vpif_config_data->set_clock) {

Does the DaVinci platform use the common clock framework ? If so, a better fix 
for this would be to pass a clock name through platform data instead of using 
a callback function.

> + ret =
> + vpif_config_data->set_clock(ch->vpifparams.std_info.ycmux_mode,
> + ch->vpifparams.std_info.hd_sd);
> + if (ret < 0) {
> + vpif_err("can't set clock\n");
> + return ret;
> + }
>   }
> 
>   /* set the parameters and addresses */
-- 
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

[PATCH] cx23885: fix pointer to structure for CAM

2012-08-16 Thread ptqa 
Hello, Mauro. Please, check our patch. Fixes problem with CAM, when 
after re-iinitialization CAM used old pointer to structure.


Signed-off-by: Anton Nurkin 

---

 drivers/media/pci/cx23885/altera-ci.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/media/pci/cx23885/altera-ci.c 
b/drivers/media/pci/cx23885/altera-ci.c

index 1fa8927..1e73764 100644
--- a/drivers/media/pci/cx23885/altera-ci.c
+++ b/drivers/media/pci/cx23885/altera-ci.c
@@ -724,6 +724,7 @@ int altera_ci_init(struct altera_ci_config *config, 
int ci_nr)

if (temp_int != NULL) {
inter = temp_int->internal;
(inter->cis_used)++;
+inter->fpga_rw = config->fpga_rw;
ci_dbg_print("%s: Find Internal Structure!\n", __func__);
} else {
inter = kzalloc(sizeof(struct fpga_internal), GFP_KERNEL);
@@ -743,7 +744,6 @@ int altera_ci_init(struct altera_ci_config *config, 
int ci_nr)


ci_dbg_print("%s: setting state = %p for ci = %d\n", __func__,
state, ci_nr - 1);
-   inter->state[ci_nr - 1] = state;
state->internal = inter;
state->nr = ci_nr - 1;

@@ -765,6 +765,8 @@ int altera_ci_init(struct altera_ci_config *config, 
int ci_nr)

if (0 != ret)
goto err;

+   inter->state[ci_nr - 1] = state;
+
altera_hw_filt_init(config, ci_nr);

if (inter->strt_wrk) {

--
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: [GIT PULL] ViewCast O820E capture support added

2012-08-16 Thread Hans Verkuil 
On Thu August 16 2012 15:27:51 Steven Toth wrote:
> >> While I don't necessarily agree with Mauro that adoption of subdev is
> >> "MANDATORY" (in the larger sense of the kernel driver development -
> >> and common practices throughout the entire source base), I do hear and
> >> value your comments and concerns from a peer review perspective.
> >
> > You're awfully polite for someone whose code has been shot down :-)
> > Don't worry, I'll buy you a beer in San Diego to soften the pain (or to
> > drown your sorrows!).
> 
> :)
> 
> It benefits everyone when rationale discussion can be had, even when
> points of view differ. The alternative is we shout at each other over
> email. Shouting gets old very quickly and never accomplishes anything.
> 
> >
> >> 1) A handful of simple improvements have been suggested, Eg.
> >> ioctl_unlocked, double-checking v4l2-compliance, try_fmt, /proc
> >> removal, firmware loading etc
> >>
> >> Ack. I have no objections. Items like this are fairly trivial, easy to
> >> address, I can absorb this and provide new patches quickly and easily.
> >> I'll go back over the detailed comments this weekend and prepare
> >> additional patches (and retest).
> >
> > Note that the v4l2-compliance tests are generally more strict than the
> > spec itself. For example, it assumes that the control framework is used,
> > that control events are implemented, and that vb2 is used.
> 
> I made some patches to the current tree to fixup some of the earlier
> comments, firmware loading via nowait, unlocked_ioctl2, /proc removal.
> I also ran the compliance testing tool. After realizing my version of
> v4l2-compliance was a little out of date - and building fresh from
> v4l2-utils, it turned out some highly useful information about the
> driver.
> 
> So, I've ran v4l2-compliance and it pointed out a few things that I've
> fixed, but it also does a few things that (for some reason) I can't
> seem to catch. One particular test is on (iirc) s_fmt. It attempts to
> set ATSC but by ioctl callback never receives ATSC in the norm/id arg,
> it actually receives 0x0. This feels more like a bug in the test.
> Either way, I have some if (std & ATSC) return -EINVAL, but it still
> appears to fail the test.

I think it might be because vdev->tvnorms isn't set for the video node.
It's set for the VBI node, though. If tvnorms is 0, then ENUMSTD will
probably return an empty list, and that might be the cause of the ATSC
test. I also see that current_norm is used: don't do that. Instead store
the current standard yourself and return it in g_std. I'm slowly phasing
out current_norm because 1) it's ugly and 2) it doesn't work if you have
both a vbi and a video node.

> I see some tests which report failure (testing videobuf) but given
> that I essentially pass the ioctl directly into the videbug core, very
> much like every oher driver I've ever done, it's probably either a
> quirk of the tool, or something inside videobuf core itself that needs
> some adjustment. (userptr/mmap for capture or output buffers related
> test).

videobuf does not follow the spec in several areas (most notably and extremely
annoyingly it does not support calling REQBUFS with a count of 0). So any
driver that uses videobuf will fail a number of tests in v4l2-compliance.

These problems are fixed in vb2, which is why I strongly recommend its use in
new drivers. In addition, work on the new DMABUF mechanism for sharing buffers
between v4l2 and drm will only be implemented in vb2.

> In summary, the v4l2-compliance tool has pointed out a few things that
> were worth fixing for sure, and thus I've fixed. It it also feels like
> the tool itself is still evolving. When I get a moment I'll run the
> compliance tool and paste the results here for comment.

It is steadily being improved, that's correct.

BTW, don't forget to also run it for the vbi node (option '-V /dev/vbiX').

Feedback on the tool is very much appreciated! E.g. how to improve it, whether
there are missing, confusing or incorrect tests, etc.

> I'd welcome your feedback on the compliance feedback.

No problem. One set of errors that v4l2-compliance produces is that it fails
if you can change VBI formats using a video node or vice versa. I want to
address that in the V4L2 core rather than having to fix all drivers. It's one
of the topics in the V4L2 ambiguities list for the upcoming workshop.

> > Take a look at vivi.c: it implements all the latest infrastructure and it
> > is now actually a pretty good example of how things should work.
> 
> Noted, that's a useful reference point.
> 
> >
> > It's also one of the few drivers that passes all v4l2-compliance tests.
> >
> > The only ioctls that aren't covered yet by v4l2-compliance are:
> >
> >VIDIOC_CROPCAP, VIDIOC_G/S_CROP, VIDIOC_G/S_SELECTION
> >VIDIOC_S_FBUF/OVERLAY
> >VIDIOC_(TRY_)ENCODER_CMD
> >VIDIOC_(TRY_)DECODER_CMD
> >VIDIOC_G_ENC_INDEX
> >VIDIOC_QBUF/DQBUF/QU

Re: dvb-usb-v2 change broke s2250-loader compilation

2012-08-16 Thread Antti Palosaari 

On 08/16/2012 05:07 PM, Hans Verkuil wrote:

On Thu August 16 2012 15:45:47 Antti Palosaari wrote:

On 08/16/2012 03:18 PM, Antti Palosaari wrote:

On 08/16/2012 01:33 PM, Hans Verkuil wrote:

Building the kernel with the Sensoray 2250/2251 staging go7007 driver
enabled
fails with this link error:

ERROR: "usb_cypress_load_firmware"
[drivers/staging/media/go7007/s2250-loader.ko] undefined!

As far as I can tell this is related to the dvb-usb-v2 changes.

Can someone take a look at this?

Thanks!

 Hans


Yes it is dvb usb v2 related. I wasn't even aware that someone took that
module use in few days after it was added for the dvb-usb-v2.

Maybe it is worth to make it even more common and move out of dvb-usb-v2...

regards
Antti


And after looking it twice I cannot see the reason. I split that Cypress
firmware download to own module called dvb_usb_cypress_firmware which
offer routine usbv2_cypress_load_firmware(). Old DVB USB is left
untouched. I can confirm it fails to compile for s2250, but there is
still old dvb_usb_cxusb that is compiling without a error.

Makefile paths seems to be correct also, no idea whats wrong


drivers/media/usb/Makefile uses := instead of += for the dvb-usb(-v2) 
directories,
and that prevents dvb-usb from being build. I think that's the cause of the link
error.


For that I cannot say as I don't understand situation enough.


In addition I noticed that in usb/dvb-usb there is a dvb_usb_dvb.c and a
dvb-usb-dvb.c file: there's a mixup with _ and -.


These files seems to be my fault. Original patch series removes those, 
but I was forced to rebase whole set and in that rebased set those are 
left unremoved. Likely due to some rebase conflict. I will send new 
patch to remove those.



Mauro, did that happen during the reorganization?

Regards,

Hans



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

[PATCH] m5mols: Add missing free_irq() on error path

2012-08-16 Thread Sylwester Nawrocki 
Make sure the interrupt is freed when the driver probing fails.

Reported-by: Marek Szyprowski 
Cc: HeungJun Kim 
Signed-off-by: Sylwester Nawrocki 
---
 drivers/media/video/m5mols/m5mols_core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/video/m5mols/m5mols_core.c 
b/drivers/media/video/m5mols/m5mols_core.c
index ac7d28b..8bf6599 100644
--- a/drivers/media/video/m5mols/m5mols_core.c
+++ b/drivers/media/video/m5mols/m5mols_core.c
@@ -931,7 +931,7 @@ static int __devinit m5mols_probe(struct i2c_client *client,

ret = m5mols_sensor_power(info, true);
if (ret)
-   goto out_me;
+   goto out_irq;

ret = m5mols_fw_start(sd);
if (!ret)
@@ -940,6 +940,8 @@ static int __devinit m5mols_probe(struct i2c_client *client,
m5mols_sensor_power(info, false);
if (!ret)
return 0;
+out_irq:
+   free_irq(client->irq, sd);
 out_me:
media_entity_cleanup(&sd->entity);
 out_reg:
--
1.7.11.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

Re: dvb-usb-v2 change broke s2250-loader compilation

2012-08-16 Thread Hans Verkuil 
On Thu August 16 2012 15:45:47 Antti Palosaari wrote:
> On 08/16/2012 03:18 PM, Antti Palosaari wrote:
> > On 08/16/2012 01:33 PM, Hans Verkuil wrote:
> >> Building the kernel with the Sensoray 2250/2251 staging go7007 driver
> >> enabled
> >> fails with this link error:
> >>
> >> ERROR: "usb_cypress_load_firmware"
> >> [drivers/staging/media/go7007/s2250-loader.ko] undefined!
> >>
> >> As far as I can tell this is related to the dvb-usb-v2 changes.
> >>
> >> Can someone take a look at this?
> >>
> >> Thanks!
> >>
> >> Hans
> >
> > Yes it is dvb usb v2 related. I wasn't even aware that someone took that
> > module use in few days after it was added for the dvb-usb-v2.
> >
> > Maybe it is worth to make it even more common and move out of dvb-usb-v2...
> >
> > regards
> > Antti
> 
> And after looking it twice I cannot see the reason. I split that Cypress 
> firmware download to own module called dvb_usb_cypress_firmware which 
> offer routine usbv2_cypress_load_firmware(). Old DVB USB is left 
> untouched. I can confirm it fails to compile for s2250, but there is 
> still old dvb_usb_cxusb that is compiling without a error.
> 
> Makefile paths seems to be correct also, no idea whats wrong

drivers/media/usb/Makefile uses := instead of += for the dvb-usb(-v2) 
directories,
and that prevents dvb-usb from being build. I think that's the cause of the link
error.

In addition I noticed that in usb/dvb-usb there is a dvb_usb_dvb.c and a
dvb-usb-dvb.c file: there's a mixup with _ and -.

Mauro, did that happen during the reorganization?

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

[PATCH] media: davinci: vpif: add check for NULL handler

2012-08-16 Thread Prabhakar Lad 
From: Lad, Prabhakar 

Signed-off-by: Lad, Prabhakar 
Signed-off-by: Manjunath Hadli 
Cc: Hans Verkuil 
---
 drivers/media/video/davinci/vpif_capture.c |   12 +++-
 drivers/media/video/davinci/vpif_display.c |   14 --
 2 files changed, 15 insertions(+), 11 deletions(-)

diff --git a/drivers/media/video/davinci/vpif_capture.c 
b/drivers/media/video/davinci/vpif_capture.c
index 266025e..a87b7a5 100644
--- a/drivers/media/video/davinci/vpif_capture.c
+++ b/drivers/media/video/davinci/vpif_capture.c
@@ -311,12 +311,14 @@ static int vpif_start_streaming(struct vb2_queue *vq, 
unsigned int count)
}
 
/* configure 1 or 2 channel mode */
-   ret = vpif_config_data->setup_input_channel_mode
-   (vpif->std_info.ycmux_mode);
+   if (vpif_config_data->setup_input_channel_mode) {
+   ret = vpif_config_data->setup_input_channel_mode
+   (vpif->std_info.ycmux_mode);
 
-   if (ret < 0) {
-   vpif_dbg(1, debug, "can't set vpif channel mode\n");
-   return ret;
+   if (ret < 0) {
+   vpif_dbg(1, debug, "can't set vpif channel mode\n");
+   return ret;
+   }
}
 
/* Call vpif_set_params function to set the parameters and addresses */
diff --git a/drivers/media/video/davinci/vpif_display.c 
b/drivers/media/video/davinci/vpif_display.c
index e129c98..1e35f92 100644
--- a/drivers/media/video/davinci/vpif_display.c
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -280,12 +280,14 @@ static int vpif_start_streaming(struct vb2_queue *vq, 
unsigned int count)
}
 
/* clock settings */
-   ret =
-   vpif_config_data->set_clock(ch->vpifparams.std_info.ycmux_mode,
-   ch->vpifparams.std_info.hd_sd);
-   if (ret < 0) {
-   vpif_err("can't set clock\n");
-   return ret;
+   if (vpif_config_data->set_clock) {
+   ret =
+   vpif_config_data->set_clock(ch->vpifparams.std_info.ycmux_mode,
+   ch->vpifparams.std_info.hd_sd);
+   if (ret < 0) {
+   vpif_err("can't set clock\n");
+   return ret;
+   }
}
 
/* set the parameters and addresses */
-- 
1.7.0.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: [git:v4l-dvb/for_v3.7] [media] mantis: Terratec Cinergy C PCI HD (CI)

2012-08-16 Thread Bjørn Mork 
Manu Abraham  writes:

> Terratec Cinregy C is VP-2033 and not VP-2040.

Can you please enlighten me on how to tell this difference?  I have two
of these cards:

bjorn@canardo:~$ lspci -vvnns 05:00
05:00.0 Multimedia controller [0480]: Twinhan Technology Co. Ltd Mantis DTV PCI 
Bridge Controller [Ver 1.0] [1822:4e35] (rev 01)
Subsystem: TERRATEC Electronic GmbH Device [153b:1178]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR-  GSI 16 (level, low) -> IRQ 16
[   35.847869] DVB: registering new adapter (Mantis DVB adapter)
[   37.358998] DVB: registering adapter 0 frontend 0 (Philips TDA10023 DVB-C)...
[   37.359079] Mantis :05:01.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[   37.607414] DVB: registering new adapter (Mantis DVB adapter)
[   38.486159] DVB: registering adapter 1 frontend 0 (Philips TDA10023 DVB-C)...


But as both the VP-2033 and VP-2040 code support both TDA10021 and
TDA10023 there is obviously some other difference between these.  Bridge
version maybe?   Or something else?



Bjørn
--
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-usb-v2 change broke s2250-loader compilation

2012-08-16 Thread Antti Palosaari 

On 08/16/2012 03:18 PM, Antti Palosaari wrote:

On 08/16/2012 01:33 PM, Hans Verkuil wrote:

Building the kernel with the Sensoray 2250/2251 staging go7007 driver
enabled
fails with this link error:

ERROR: "usb_cypress_load_firmware"
[drivers/staging/media/go7007/s2250-loader.ko] undefined!

As far as I can tell this is related to the dvb-usb-v2 changes.

Can someone take a look at this?

Thanks!

Hans


Yes it is dvb usb v2 related. I wasn't even aware that someone took that
module use in few days after it was added for the dvb-usb-v2.

Maybe it is worth to make it even more common and move out of dvb-usb-v2...

regards
Antti


And after looking it twice I cannot see the reason. I split that Cypress 
firmware download to own module called dvb_usb_cypress_firmware which 
offer routine usbv2_cypress_load_firmware(). Old DVB USB is left 
untouched. I can confirm it fails to compile for s2250, but there is 
still old dvb_usb_cxusb that is compiling without a error.


Makefile paths seems to be correct also, no idea whats wrong


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: [git:v4l-dvb/for_v3.7] [media] mantis: Terratec Cinergy C PCI HD (CI)

2012-08-16 Thread Bjørn Mork 
Mauro Carvalho Chehab  writes:

> Hmm... there's something wrong: this would be the revert patch, as produced
> by git revert:
>
> diff --git a/drivers/media/pci/mantis/mantis_cards.c 
> b/drivers/media/pci/mantis/mantis_cards.c
> index 0207d1f..095cf3a 100644
> --- a/drivers/media/pci/mantis/mantis_cards.c
> +++ b/drivers/media/pci/mantis/mantis_cards.c
> @@ -275,7 +275,7 @@ static struct pci_device_id mantis_pci_table[] = {
>   MAKE_ENTRY(TWINHAN_TECHNOLOGIES, MANTIS_VP_2033_DVB_C, &vp2033_config),
>   MAKE_ENTRY(TWINHAN_TECHNOLOGIES, MANTIS_VP_2040_DVB_C, &vp2040_config),
>   MAKE_ENTRY(TECHNISAT, CABLESTAR_HD2, &vp2040_config),
> - MAKE_ENTRY(TERRATEC, CINERGY_C, &vp2040_config),
> + MAKE_ENTRY(TERRATEC, CINERGY_C, &vp2033_config),
>   MAKE_ENTRY(TWINHAN_TECHNOLOGIES, MANTIS_VP_3030_DVB_T, &vp3030_config),
>   { }
>  };
> diff --git a/drivers/media/pci/mantis/mantis_core.c 
> b/drivers/media/pci/mantis/mantis_core.c
> index 684d906..22524a8 100644
> --- a/drivers/media/pci/mantis/mantis_core.c
> +++ b/drivers/media/pci/mantis/mantis_core.c
> @@ -121,7 +121,7 @@ static void mantis_load_config(struct mantis_pci *mantis)
>   mantis->hwconfig = &vp2033_mantis_config;
>   break;
>   case MANTIS_VP_2040_DVB_C:  /* VP-2040 */
> - case CINERGY_C: /* VP-2040 clone */
> + case TERRATEC_CINERGY_C_PCI:/* VP-2040 clone */
>   case TECHNISAT_CABLESTAR_HD2:
>   mantis->hwconfig = &vp2040_mantis_config;
>   break;
>
> There's something wrong there: the comments at "mantis_core", before this
> patch, is saying that TERRATEC_CINERGY_C_PCI is a VP-2040 clone.
>
> That doesn't look right: this card is either a VP-2033 clone (as stated on
> mantis_cards), or a VP-2040 (as stated on mantis_core).


Just delete the whole mantis_core.c file.  It has never been built in
the in-kernel driver.  See, no reference to it at all:


bjorn@nemi:/usr/local/src/git/linux$ cat drivers/media/dvb/mantis/Makefile 
mantis_core-objs := mantis_ioc.o\
mantis_uart.o   \
mantis_dma.o\
mantis_pci.o\
mantis_i2c.o\
mantis_dvb.o\
mantis_evm.o\
mantis_hif.o\
mantis_ca.o \
mantis_pcmcia.o \
mantis_input.o

mantis-objs :=  mantis_cards.o  \
mantis_vp1033.o \
mantis_vp1034.o \
mantis_vp1041.o \
mantis_vp2033.o \
mantis_vp2040.o \
mantis_vp3030.o

hopper-objs :=  hopper_cards.o  \
hopper_vp3028.o

obj-$(CONFIG_MANTIS_CORE)   += mantis_core.o
obj-$(CONFIG_DVB_MANTIS)+= mantis.o
obj-$(CONFIG_DVB_HOPPER)+= hopper.o

ccflags-y += -Idrivers/media/dvb/dvb-core/ -Idrivers/media/dvb/frontends/




Bjørn
--
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: [GIT PULL] ViewCast O820E capture support added

2012-08-16 Thread Steven Toth 
>> While I don't necessarily agree with Mauro that adoption of subdev is
>> "MANDATORY" (in the larger sense of the kernel driver development -
>> and common practices throughout the entire source base), I do hear and
>> value your comments and concerns from a peer review perspective.
>
> You're awfully polite for someone whose code has been shot down :-)
> Don't worry, I'll buy you a beer in San Diego to soften the pain (or to
> drown your sorrows!).

:)

It benefits everyone when rationale discussion can be had, even when
points of view differ. The alternative is we shout at each other over
email. Shouting gets old very quickly and never accomplishes anything.

>
>> 1) A handful of simple improvements have been suggested, Eg.
>> ioctl_unlocked, double-checking v4l2-compliance, try_fmt, /proc
>> removal, firmware loading etc
>>
>> Ack. I have no objections. Items like this are fairly trivial, easy to
>> address, I can absorb this and provide new patches quickly and easily.
>> I'll go back over the detailed comments this weekend and prepare
>> additional patches (and retest).
>
> Note that the v4l2-compliance tests are generally more strict than the
> spec itself. For example, it assumes that the control framework is used,
> that control events are implemented, and that vb2 is used.

I made some patches to the current tree to fixup some of the earlier
comments, firmware loading via nowait, unlocked_ioctl2, /proc removal.
I also ran the compliance testing tool. After realizing my version of
v4l2-compliance was a little out of date - and building fresh from
v4l2-utils, it turned out some highly useful information about the
driver.

So, I've ran v4l2-compliance and it pointed out a few things that I've
fixed, but it also does a few things that (for some reason) I can't
seem to catch. One particular test is on (iirc) s_fmt. It attempts to
set ATSC but by ioctl callback never receives ATSC in the norm/id arg,
it actually receives 0x0. This feels more like a bug in the test.
Either way, I have some if (std & ATSC) return -EINVAL, but it still
appears to fail the test.

I see some tests which report failure (testing videobuf) but given
that I essentially pass the ioctl directly into the videbug core, very
much like every oher driver I've ever done, it's probably either a
quirk of the tool, or something inside videobuf core itself that needs
some adjustment. (userptr/mmap for capture or output buffers related
test).

In summary, the v4l2-compliance tool has pointed out a few things that
were worth fixing for sure, and thus I've fixed. It it also feels like
the tool itself is still evolving. When I get a moment I'll run the
compliance tool and paste the results here for comment.

I'd welcome your feedback on the compliance feedback.

>
> Take a look at vivi.c: it implements all the latest infrastructure and it
> is now actually a pretty good example of how things should work.

Noted, that's a useful reference point.

>
> It's also one of the few drivers that passes all v4l2-compliance tests.
>
> The only ioctls that aren't covered yet by v4l2-compliance are:
>
>VIDIOC_CROPCAP, VIDIOC_G/S_CROP, VIDIOC_G/S_SELECTION
>VIDIOC_S_FBUF/OVERLAY
>VIDIOC_(TRY_)ENCODER_CMD
>VIDIOC_(TRY_)DECODER_CMD
>VIDIOC_G_ENC_INDEX
>VIDIOC_QBUF/DQBUF/QUERYBUF/PREPARE_BUFS
>VIDIOC_STREAMON/OFF
>
> So basically cropping, compression encoder/decoder control and actual
> streaming. And the subdev and media API is also not tested, although
> those might be beyond the scope of this utility anyway.
>
> Everything else is now tested fairly exhaustively.
>
>> 2) ... and some larger discussion items have been raised, Eg.
>> Absorbing more of the V4L2 kernel infrastructure into the vc8x0 driver
>> vs a fairly self-contained driver with very limited opportunities for
>> future breakage.
>>
>> Are you really willing to say that all drivers, with unique and new
>> pieces of silicon, need to be split out into independent modules,
>> adopting a subdev type interfaces or mainline merge is refused? It's
>> not that I'm asking you to merge duplicate functionality, duplicate
>> driver code, replicating functionality for new hardware or for an
>> existing modules (tuner/demod/whatever). (Like has already happened in
>> the past - 18271 for example).
>
> Speaking for myself, I would probably NACK it, yes. I would hate to do it,
> but there are IMHO good technical reasons why the ad7441 code should be
> implemented as a subdev driver.

I hear you. In the spirit of co-operation I'll take a shot at turning
ad7441 into a subdev and see what odd problems shake out of the
process. I should be clear that the resulting subdevice will likely be
very 820 specific in terms of configuration, but it's a reasonable
cut-point.

>
>> If the answer is Yes, then my second questions is:
>>
>> Assuming the comments / issues mentioned in #1 are addressed, are you
>> really willing to stand up in fro

Re: [PATCH] [media] davinci: vpfe: Add documentation

2012-08-16 Thread Prabhakar Lad 
Hi Rob,

On Thursday 16 August 2012 06:40 PM, Rob Landley wrote:
> On 07/11/2012 10:39 AM, Manjunath Hadli wrote:
>> Add documentation on the Davinci VPFE driver. Document the subdevs,
>> and private IOTCLs the driver implements
>>
>> Signed-off-by: Manjunath Hadli 
>> Signed-off-by: Lad, Prabhakar 
> 
> I saw the comment on the 8th, is there another version of this
> documentation coming...?
> 
 I was waiting for comments from Sakari/Laurent, If they are happy
 from what Manju has proposed, depending on the outcome of the
discussion I'll soon post another version soon.

Thanks and Regards,
--Prabhakar

> Rob
> 

--
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] mantis: merge both vp2033 and vp2040 drivers

2012-08-16 Thread Bjørn Mork 
Manu Abraham  writes:

> That's just peanuts you are talking about. The memory usage appears only
> if you are using the module. 200 lines of .text is nothing.

OK.  Deleting 200 completely useless lines of code is nothing?  I don't
think we live in the same world.

> That exists to
> differentiate between the 2 devices, not to make both hardware look the same.

Right.  And every single USB hard drive out there should have it's own
duplicated usb-storage driver?  I don't think so...

I am sure you are right that the cards are different.  It just doesn't
matter as long as the drivers are identical.

Thank you Mauro for doing this long awaited cleanup.  Getting rid of all
the duplicated and unused code in this driver will make it easier for
others to get involved in fixing the real bugs.


Bjørn
--
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] davinci: vpfe: Add documentation

2012-08-16 Thread Rob Landley 
On 07/11/2012 10:39 AM, Manjunath Hadli wrote:
> Add documentation on the Davinci VPFE driver. Document the subdevs,
> and private IOTCLs the driver implements
> 
> Signed-off-by: Manjunath Hadli 
> Signed-off-by: Lad, Prabhakar 

I saw the comment on the 8th, is there another version of this
documentation coming...?

Rob
-- 
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation.  Pick one.
--
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 Trivial] [media] s5p-jpeg: Add missing braces around sizeof

2012-08-16 Thread Sylwester Nawrocki 
On 08/16/2012 01:52 PM, Sachin Kamat wrote:
> Silences the following warning:
> WARNING: sizeof *ctx should be sizeof(*ctx)
> 
> Signed-off-by: Sachin Kamat 

Thanks Sachin, I've added this to my tree for v3.7.

> ---
>  drivers/media/platform/s5p-jpeg/jpeg-core.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c 
> b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> index 72c3e52..ae916cd 100644
> --- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
> +++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> @@ -288,7 +288,7 @@ static int s5p_jpeg_open(struct file *file)
>   struct s5p_jpeg_fmt *out_fmt;
>   int ret = 0;
>  
> - ctx = kzalloc(sizeof *ctx, GFP_KERNEL);
> + ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
>   if (!ctx)
>   return -ENOMEM;

Regards,
Sylwester
--
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-usb-v2 change broke s2250-loader compilation

2012-08-16 Thread Antti Palosaari 

On 08/16/2012 01:33 PM, Hans Verkuil wrote:

Building the kernel with the Sensoray 2250/2251 staging go7007 driver enabled
fails with this link error:

ERROR: "usb_cypress_load_firmware" 
[drivers/staging/media/go7007/s2250-loader.ko] undefined!

As far as I can tell this is related to the dvb-usb-v2 changes.

Can someone take a look at this?

Thanks!

Hans


Yes it is dvb usb v2 related. I wasn't even aware that someone took that 
module use in few days after it was added for the dvb-usb-v2.


Maybe it is worth to make it even more common and move out of dvb-usb-v2...

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

[PATCH] [media] s5p-mfc: Add device tree support

2012-08-16 Thread Arun Kumar K 
This patch will add the device tree support for MFC driver.

Signed-off-by: Arun Kumar K 
---
 drivers/media/video/s5p-mfc/s5p_mfc.c |  106 -
 1 files changed, 90 insertions(+), 16 deletions(-)

diff --git a/drivers/media/video/s5p-mfc/s5p_mfc.c 
b/drivers/media/video/s5p-mfc/s5p_mfc.c
index 75b9026..83a4494 100644
--- a/drivers/media/video/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/video/s5p-mfc/s5p_mfc.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "s5p_mfc_common.h"
 #include "s5p_mfc_ctrl.h"
@@ -921,6 +922,8 @@ static int match_child(struct device *dev, void *data)
return !strcmp(dev_name(dev), (char *)data);
 }
 
+static void *mfc_get_drv_data(struct platform_device *pdev);
+
 /* MFC probe function */
 static int s5p_mfc_probe(struct platform_device *pdev)
 {
@@ -928,6 +931,8 @@ static int s5p_mfc_probe(struct platform_device *pdev)
struct video_device *vfd;
struct resource *res;
int ret;
+   unsigned int base_addr;
+   unsigned int bank_size;
 
pr_debug("%s++\n", __func__);
dev = devm_kzalloc(&pdev->dev, sizeof *dev, GFP_KERNEL);
@@ -944,8 +949,7 @@ static int s5p_mfc_probe(struct platform_device *pdev)
return -ENODEV;
}
 
-   dev->variant = (struct s5p_mfc_variant *)
-   platform_get_device_id(pdev)->driver_data;
+   dev->variant = mfc_get_drv_data(pdev);
 
ret = s5p_mfc_init_pm(dev);
if (ret < 0) {
@@ -975,19 +979,59 @@ static int s5p_mfc_probe(struct platform_device *pdev)
goto err_res;
}
 
-   dev->mem_dev_l = device_find_child(&dev->plat_dev->dev, "s5p-mfc-l",
-  match_child);
-   if (!dev->mem_dev_l) {
-   mfc_err("Mem child (L) device get failed\n");
-   ret = -ENODEV;
-   goto err_res;
-   }
-   dev->mem_dev_r = device_find_child(&dev->plat_dev->dev, "s5p-mfc-r",
-  match_child);
-   if (!dev->mem_dev_r) {
-   mfc_err("Mem child (R) device get failed\n");
-   ret = -ENODEV;
-   goto err_res;
+   if (pdev->dev.of_node) {
+   dev->mem_dev_l = kzalloc(sizeof(struct device), GFP_KERNEL);
+   if (!dev->mem_dev_l) {
+   mfc_err("Not enough memory\n");
+   ret = -ENOMEM;
+   goto err_res;
+   }
+   of_property_read_u32(pdev->dev.of_node, "samsung,mfc-l",
+   &base_addr);
+   of_property_read_u32(pdev->dev.of_node, "samsung,mfc-l-size",
+   &bank_size);
+   if (dma_declare_coherent_memory(dev->mem_dev_l, base_addr,
+   base_addr, bank_size,
+   DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE) == 0) {
+   mfc_err("Failed to declare coherent memory for\n"
+   "MFC device\n");
+   ret = -ENOMEM;
+   goto err_res;
+   }
+
+   dev->mem_dev_r = kzalloc(sizeof(struct device), GFP_KERNEL);
+   if (!dev->mem_dev_r) {
+   mfc_err("Not enough memory\n");
+   ret = -ENOMEM;
+   goto err_res;
+   }
+   of_property_read_u32(pdev->dev.of_node, "samsung,mfc-r",
+   &base_addr);
+   of_property_read_u32(pdev->dev.of_node, "samsung,mfc-r-size",
+   &bank_size);
+   if (dma_declare_coherent_memory(dev->mem_dev_r, base_addr,
+   base_addr, bank_size,
+   DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE) == 0) {
+   pr_err("Failed to declare coherent memory for\n"
+   "MFC device\n");
+   ret = -ENOMEM;
+   goto err_res;
+   }
+   } else {
+   dev->mem_dev_l = device_find_child(&dev->plat_dev->dev,
+   "s5p-mfc-l", match_child);
+   if (!dev->mem_dev_l) {
+   mfc_err("Mem child (L) device get failed\n");
+   ret = -ENODEV;
+   goto err_res;
+   }
+   dev->mem_dev_r = device_find_child(&dev->plat_dev->dev,
+   "s5p-mfc-r", match_child);
+   if (!dev->mem_dev_r) {
+   mfc_err("Mem child (R) device get failed\n");
+   ret = -ENODEV;
+   goto err_res;
+   }
}
 
dev->alloc_ctx[0] = vb2_dma_contig_init_ctx(dev->mem_dev_l);
@@ -1262,6 +1306,35 @@ static struct platform_device_id mfc_driver_ids[] = {
 };
 MODULE_DEVICE_TAB

[PATCH Trivial] [media] s5p-jpeg: Add missing braces around sizeof

2012-08-16 Thread Sachin Kamat 
Silences the following warning:
WARNING: sizeof *ctx should be sizeof(*ctx)

Signed-off-by: Sachin Kamat 
---
 drivers/media/platform/s5p-jpeg/jpeg-core.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c 
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 72c3e52..ae916cd 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -288,7 +288,7 @@ static int s5p_jpeg_open(struct file *file)
struct s5p_jpeg_fmt *out_fmt;
int ret = 0;
 
-   ctx = kzalloc(sizeof *ctx, GFP_KERNEL);
+   ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
 
-- 
1.7.4.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] Add MFC device tree support

2012-08-16 Thread Arun Kumar K 
The patch adds device tree support for the MFC driver. 
The ARCH side patch for the device tree support for Exynos4 and 5
SoCs are posted in linux-samsung mailing list [1].
This patch has to be applied over the patchset for MFC v6 support [2].

[1] http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg11872.html
[2] http://www.mail-archive.com/linux-media@vger.kernel.org/msg50204.html

Arun Kumar K (1):
  [media] s5p-mfc: Add device tree support

 drivers/media/video/s5p-mfc/s5p_mfc.c |  106 -
 1 files changed, 90 insertions(+), 16 deletions(-)

--
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] s5p-fimc: Add pipeline ops to separate FIMC-LITE module (was From: Sylwester Nawrocki )

2012-08-16 Thread Sylwester Nawrocki 
On 08/16/2012 12:34 PM, Sylwester Nawrocki wrote:

The patch's subject got wrong due to stray characters that snicked
in, the subject should read:

[PATCH] s5p-fimc: Add pipeline ops to separate FIMC-LITE module

My apologies for spamming.

Thanks,
Sylwester
> In order to reuse the FIMC-LITE module on Exynos4 and Exynos5
> SoC introduce a set of callbacks for the media pipeline control
> from within FIMC/FIMC-LITE video node. It lets us avoid symbol
> dependencies between FIMC-LITE and the whole media device driver,
> which simplifies the initialization sequences and doesn't
> introduce issues preventing common kernel image for exynos4 and
> exynos5 SoCs.
> 
> Signed-off-by: Sylwester Nawrocki 
> Signed-off-by: Kyungmin Park 



--
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: [git:v4l-dvb/for_v3.7] [media] media: rc: Introduce RX51 IR transmitter driver

2012-08-16 Thread Sebastian Reichel 
Hi,

> > It was an requirement back then that this driver needs to be a module as
> > 99% of the N900 owners still don't even know they have this kind of
> > capability on their devices, so it doesn't make sense to keep the module
> > loaded unless the user actually needs it.
> 
> I don't think that's so important --- currently the vast majority of the
> N900 users using the mainline kernel compile it themselves. It's more
> important to have a clean implementation at this point.

I would like to enable this feature for the Debian OMAP kernel,
which is not only used for N900, but also for Pandaboard, etc.

-- Sebastian


signature.asc
Description: Digital signature

[PATCH] smiapp: Use devm_kzalloc() in smiapp-core.c file

2012-08-16 Thread Sachin Kamat 
devm_kzalloc is a device managed function and makes code a bit
smaller and cleaner.

Signed-off-by: Sachin Kamat 
---
This patch is based on Mauro's re-organized tree
(media_tree staging/for_v3.7) and is compile tested.
---
 drivers/media/i2c/smiapp/smiapp-core.c |   11 ++-
 1 files changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
b/drivers/media/i2c/smiapp/smiapp-core.c
index 1cf914d..7d4280e 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -2801,12 +2801,11 @@ static int smiapp_probe(struct i2c_client *client,
const struct i2c_device_id *devid)
 {
struct smiapp_sensor *sensor;
-   int rval;
 
if (client->dev.platform_data == NULL)
return -ENODEV;
 
-   sensor = kzalloc(sizeof(*sensor), GFP_KERNEL);
+   sensor = devm_kzalloc(&client->dev, sizeof(*sensor), GFP_KERNEL);
if (sensor == NULL)
return -ENOMEM;
 
@@ -2821,12 +2820,8 @@ static int smiapp_probe(struct i2c_client *client,
sensor->src->sensor = sensor;
 
sensor->src->pads[0].flags = MEDIA_PAD_FL_SOURCE;
-   rval = media_entity_init(&sensor->src->sd.entity, 2,
+   return media_entity_init(&sensor->src->sd.entity, 2,
 sensor->src->pads, 0);
-   if (rval < 0)
-   kfree(sensor);
-
-   return rval;
 }
 
 static int __exit smiapp_remove(struct i2c_client *client)
@@ -2862,8 +2857,6 @@ static int __exit smiapp_remove(struct i2c_client *client)
if (sensor->vana)
regulator_put(sensor->vana);
 
-   kfree(sensor);
-
return 0;
 }
 
-- 
1.7.4.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: Update VIP to videobuf2 and control framework

2012-08-16 Thread Federico Vaga 
In data mercoledì 1 agosto 2012 07:04:18, Jonathan Corbet ha scritto:
> On Wed, 1 Aug 2012 08:41:56 +0200
> 
> Hans Verkuil  wrote:
> > > The second patch adds a new memory allocator for the videobuf2. I
> > > name it videobuf2-dma-streaming but I think "streaming" is not
> > > the best choice, so suggestions are welcome. My inspiration for
> > > this buffer come from videobuf-dma-contig (cached) version. After
> > > I made this buffer I found the videobuf2-dma-nc made by Jonathan
> > > Corbet and I improve the allocator with some suggestions
> > > (http://patchwork.linuxtv.org/patch/7441/). The VIP doesn't work
> > > with videobu2-dma-contig and I think this solution is easier the
> > > sg.> 
> > I leave this to the vb2 experts. It's not obvious to me why we would
> > need a fourth memory allocator.
> 
> I first wrote my version after observing that performance dropped by a
> factor of three on the OLPC XO 1.75 when using contiguous, coherent
> memory.  If the architecture needs to turn off caching, things really
> slow down, to the point that it's unusable.  There's no real reason
> why a V4L2 device shouldn't be able to use streaming mappings in this
> situation; it performs better and doesn't eat into the limited
> amounts of coherent DMA space available on some systems.
> 
> I never got my version into a mergeable state only because I finally
> figured out how to bludgeon the hardware into doing s/g DMA and didn't
> need it anymore.  But I think it's a worthwhile functionality to
> have, and, with CMA, it could be the preferred mode for a number of
> devices.
> 
> jon

I think that the memory allocator is the most questionable patch, but if 
there are not any other comments I will send my three patches for the 
inclusion. It is summer, time for vacation, so I'll wait for another 
week or two for critical comments and then I will send patches.


-- 
Federico Vaga
--
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 v3 3/4] media: videobuf2-dma-contig: use dma_mmap_coherent if available

2012-08-16 Thread Marek Szyprowski 
Hello,

On Thursday, August 16, 2012 12:14 PM Hideki EIRAKU wrote:

> From: Marek Szyprowski 
> Subject: RE: [PATCH v3 3/4] media: videobuf2-dma-contig: use 
> dma_mmap_coherent if available
> Date: Tue, 07 Aug 2012 16:53:25 +0200
> 
> > I'm sorry for bringing this issue now, once you have already created v3 of 
> > your
> > patches, but similar patch has been already proposed some time ago. It is 
> > already
> > processed together with general videobuf2-dma-contig redesign and dma-buf 
> > extensions
> > by Tomasz Stanislawski.
> >
> > See post 
> > http://thread.gmane.org/gmane.comp.video.dri.devel/70402/focus=49461 and
> > http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/49438
> >
> > It doesn't use conditional code inside videobuf2 allocator and rely 
> > entirely on
> > dma-mapping subsystem to provide a working 
> > dma_mmap_coherent/writecombine/attrs()
> > function. When it was posted, it relied on the dma-mapping extensions, 
> > which now
> > have been finally merged to v3.6-rc1. Now I wonder if there are any 
> > architectures,
> > which don't use dma_map_ops based dma-mapping framework, which might use
> > videobuf2-dma-conting module.
> 
> Thank you for telling me about videobuf2-dma-contig and v3.6-rc1.  The
> videobuf2-dma-contig patch I sent is now unnecessary.  So I will
> remove the patch.  I will remove the patch defining
> ARCH_HAS_DMA_MMAP_COHERENT too because the v3.6-rc1 kernel has generic
> dma_mmap_coherent() API for every architecture.

Just to let you know - Tomasz has posted an updated version of the 
dma-buf/vb2-dma-contig
patches:

http://www.spinics.net/lists/linux-media/msg51768.html

Best regards
-- 
Marek Szyprowski
Samsung Poland R&D Center


--
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: Patches submitted via linux-media ML that are at patchwork.linuxtv.org

2012-08-16 Thread Prabhakar Lad 
Hi Mauro,

On Thursday 16 August 2012 05:16 AM, Mauro Carvalho Chehab wrote:
> Em 14-08-2012 10:04, Mauro Carvalho Chehab escreveu:
>> In order to help people to know about the status of the pending patches,
>> I'm summing-up the patches pending for merge on this email.
> 
> Thank you all maintainers that helped me updating it!
> 
> If I didn't miss anything, the patches below are what's under review.
> 
> I applied today the reorg patches part 2. Please test. There are still some
> mess at drivers/media/platform. I may try to address it next week, if I have
> some time. Of course, people are welcome to do that, instead ;) Basically,
> vivi, platform and mem2mem drivers are there, maybe together with some other
> stuff. I think soc_camera deserves its own directory, just like other
> platform drivers.
> 
> The Kconfig stuff on V4L can likely be simplified: there are too many hidden
> options there that probably can be removed, in order to make it simpler.
> 
> Anyway, at least in my humble opinion, things are now better organized.
> 
> With regards to media-build.git tree, I updated it to properly apply the
> fixup patches against the new tree. I didn't updated the driver removal
> logic there, used during "make install".
> 
> For the driver removal logic to work at media-build, the file "obsolete.txt" 
> needs to have the name and patches for all drivers before the reorganization.
> As the maximum backport is 2.6.31, I suspect that all other stuff at 
> "obsolete.txt" just got outdated and can be removed.
> 
> Thanks,
> Mauro
> 
>   == Needing more discussions/review by the LinuxTV community == 
> 
> Jun,21 2012: [media] dvb frontend core: tuning in ISDB-T using DVB API v3 
>   http://patchwork.linuxtv.org/patch/12988  Olivier Grenie 
> 
> Jun,21 2012: dvb: push down ioctl lock in dvb_usercopy
>   http://patchwork.linuxtv.org/patch/12989  Nikolaus Schulz 
> 
> Jul,26 2012: media: rc: Add support to decode Remotes using NECx IR protocol  
>   http://patchwork.linuxtv.org/patch/13480  Ravi Kumar V 
> 
> Jul,31 2012: [RFC] Fix DVB ioctls failing if frontend open/closed too fast
>   http://patchwork.linuxtv.org/patch/13563  Juergen Lock 
> 
> Jan,20 2012: [RFC] dvb: Add DVBv5 properties for quality parameters   
>   http://patchwork.linuxtv.org/patch/9578   Mauro Carvalho Chehab 
> 
> Aug,13 2012: [media] dvb: frontend API: Add a flag to indicate that 
> get_frontend()  http://patchwork.linuxtv.org/patch/13783  Mauro Carvalho 
> Chehab 
> 
>   == Guennadi Liakhovetski  == 
> 
> Jul,12 2012: media: mx2_camera: Remove MX2_CAMERA_SWAP16 and 
> MX2_CAMERA_PACK_DIR_MS http://patchwork.linuxtv.org/patch/13331  Javier 
> Martin 
> May,25 2012: [08/15] video: mx2_emmaprp: Use 
> clk_prepare_enable/clk_disable_unprepa 
> http://patchwork.linuxtv.org/patch/11507  Fabio Estevam 
> 
> 
>   == Prabhakar Lad  == 
> 
> Aug, 9 2012: [1/1, v2] media/video: vpif: fixing function name start to 
> vpif_config http://patchwork.linuxtv.org/patch/13689  Dror Cohen 
> 
> 
 This patch can be marked as 'Accepted'.

Thanks and Regards,
--Prabhakar

>   == Jonathan Corbet  == 
> 
> Apr,26 2012: [2/2] marvell-cam: Build fix: missing "select VIDEOBUF2_VMALLOC" 
>   http://patchwork.linuxtv.org/patch/10848  Chris Ball 
> Aug,13 2012: [2/2] marvell-cam: Build fix: missing "select VIDEOBUF2_VMALLOC" 
>   http://patchwork.linuxtv.org/patch/13784  Mauro Carvalho Chehab 
> 
> 
>   == Manu Abraham  == 
> 
> May,25 2011: Add remote control support for mantis
> Christoph Pinkl 
> 
> Jun, 8 2011: Add remote control support for mantis
>   http://patchwork.linuxtv.org/patch/7217   Christoph Pinkl 
> 
> Nov,29 2011: stv090x: implement function for reading uncorrected blocks count 
>   http://patchwork.linuxtv.org/patch/8656   Mariusz Bia?o?czyk 
> 
> Mar,11 2012: [2/3] stv090x: use error counter 1 for BER estimation
>   http://patchwork.linuxtv.org/patch/10301  Andreas Regel 
> 
> Mar,11 2012: [3/3] stv090x: On STV0903 do not set registers of the second 
> path. http://patchwork.linuxtv.org/patch/10302  Andreas Regel 
> 
> Apr, 1 2012: [05/11] Slightly more friendly debugging output. 
>   http://patchwork.linuxtv.org/patch/10520  "Steinar H. Gunderson" 
> 
> Apr, 1 2012: [06/11] Replace ca_lock by a slightly more general 
> int_stat_lock.  http://patchwork.linuxtv.org/patch/10521  "Steinar H. 
> Gunderson" 
> Apr, 1 2012: [07/11] Fix a ton of SMP-unsafe accesses.
>   http://patchwork.linuxtv.org/patch/10523  "Steinar H. Gunderson" 
> 
> Apr, 1 2012: [11/11] Enable Mantis CA support.
>   http://patchwork.linuxtv.org/patch/10524  "Steinar H. Gunderson" 
> 
> Apr, 1 2012: [08/11] Remove some unused structure memb

From: Sylwester Nawrocki

2012-08-16 Thread Sylwester Nawrocki 
In order to reuse the FIMC-LITE module on Exynos4 and Exynos5
SoC introduce a set of callbacks for the media pipeline control
from within FIMC/FIMC-LITE video node. It lets us avoid symbol
dependencies between FIMC-LITE and the whole media device driver,
which simplifies the initialization sequences and doesn't
introduce issues preventing common kernel image for exynos4 and
exynos5 SoCs.

Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
---
 drivers/media/platform/s5p-fimc/fimc-capture.c | 21 -
 drivers/media/platform/s5p-fimc/fimc-core.h|  1 +
 drivers/media/platform/s5p-fimc/fimc-lite.c| 22 ++
 drivers/media/platform/s5p-fimc/fimc-lite.h|  2 ++
 drivers/media/platform/s5p-fimc/fimc-mdevice.c | 26 ++
 drivers/media/platform/s5p-fimc/fimc-mdevice.h |  6 --
 include/media/s5p_fimc.h   | 18 ++
 7 files changed, 65 insertions(+), 31 deletions(-)

diff --git a/drivers/media/platform/s5p-fimc/fimc-capture.c 
b/drivers/media/platform/s5p-fimc/fimc-capture.c
index 4092388..ab1fa9d 100644
--- a/drivers/media/platform/s5p-fimc/fimc-capture.c
+++ b/drivers/media/platform/s5p-fimc/fimc-capture.c
@@ -118,7 +118,8 @@ static int fimc_capture_state_cleanup(struct fimc_dev 
*fimc, bool suspend)
spin_unlock_irqrestore(&fimc->slock, flags);

if (streaming)
-   return fimc_pipeline_s_stream(&fimc->pipeline, 0);
+   return fimc_pipeline_call(fimc, set_stream,
+ &fimc->pipeline, 0);
else
return 0;
 }
@@ -264,7 +265,8 @@ static int start_streaming(struct vb2_queue *q, unsigned 
int count)
fimc_activate_capture(ctx);

if (!test_and_set_bit(ST_CAPT_ISP_STREAM, &fimc->state))
-   fimc_pipeline_s_stream(&fimc->pipeline, 1);
+   fimc_pipeline_call(fimc, set_stream,
+  &fimc->pipeline, 1);
}

return 0;
@@ -288,7 +290,7 @@ int fimc_capture_suspend(struct fimc_dev *fimc)
int ret = fimc_stop_capture(fimc, suspend);
if (ret)
return ret;
-   return fimc_pipeline_shutdown(&fimc->pipeline);
+   return fimc_pipeline_call(fimc, shutdown, &fimc->pipeline);
 }

 static void buffer_queue(struct vb2_buffer *vb);
@@ -304,8 +306,8 @@ int fimc_capture_resume(struct fimc_dev *fimc)

INIT_LIST_HEAD(&fimc->vid_cap.active_buf_q);
vid_cap->buf_index = 0;
-   fimc_pipeline_initialize(&fimc->pipeline, &vid_cap->vfd.entity,
-false);
+   fimc_pipeline_call(fimc, initialize, &fimc->pipeline,
+  &vid_cap->vfd.entity, false);
fimc_capture_hw_init(fimc);

clear_bit(ST_CAPT_SUSPENDED, &fimc->state);
@@ -422,7 +424,8 @@ static void buffer_queue(struct vb2_buffer *vb)
spin_unlock_irqrestore(&fimc->slock, flags);

if (!test_and_set_bit(ST_CAPT_ISP_STREAM, &fimc->state))
-   fimc_pipeline_s_stream(&fimc->pipeline, 1);
+   fimc_pipeline_call(fimc, set_stream,
+  &fimc->pipeline, 1);
return;
}
spin_unlock_irqrestore(&fimc->slock, flags);
@@ -502,8 +505,8 @@ static int fimc_capture_open(struct file *file)
}

if (++fimc->vid_cap.refcnt == 1) {
-   ret = fimc_pipeline_initialize(&fimc->pipeline,
-  &fimc->vid_cap.vfd.entity, true);
+   ret = fimc_pipeline_call(fimc, initialize, &fimc->pipeline,
+&fimc->vid_cap.vfd.entity, true);

if (!ret && !fimc->vid_cap.user_subdev_api)
ret = fimc_capture_set_default_format(fimc);
@@ -536,7 +539,7 @@ static int fimc_capture_close(struct file *file)
if (--fimc->vid_cap.refcnt == 0) {
clear_bit(ST_CAPT_BUSY, &fimc->state);
fimc_stop_capture(fimc, false);
-   fimc_pipeline_shutdown(&fimc->pipeline);
+   fimc_pipeline_call(fimc, shutdown, &fimc->pipeline);
clear_bit(ST_CAPT_SUSPENDED, &fimc->state);
}

diff --git a/drivers/media/platform/s5p-fimc/fimc-core.h 
b/drivers/media/platform/s5p-fimc/fimc-core.h
index d3a3a00..6180546 100644
--- a/drivers/media/platform/s5p-fimc/fimc-core.h
+++ b/drivers/media/platform/s5p-fimc/fimc-core.h
@@ -440,6 +440,7 @@ struct fimc_dev {
unsigned long   state;
struct vb2_alloc_ctx*alloc_ctx;
struct fimc_pipelinepipeline;
+   const struct fimc_pipeline_ops  *pipeline_ops;
 };

 /**
diff --git a/drivers/media/platform/s5p-fimc/fimc-lite.c 
b/drivers/media/platform/s5p-fimc/fimc-lite.c
index 9289008..5e99713 100644
--- a/drivers/media/platform/s5p-fimc/fimc-lite.c
+++ b/dri

dvb-usb-v2 change broke s2250-loader compilation

2012-08-16 Thread Hans Verkuil 
Building the kernel with the Sensoray 2250/2251 staging go7007 driver enabled
fails with this link error:

ERROR: "usb_cypress_load_firmware" 
[drivers/staging/media/go7007/s2250-loader.ko] undefined!

As far as I can tell this is related to the dvb-usb-v2 changes.

Can someone take a look at this?

Thanks!

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: [ANNOUNCE] tree renaming patches part 1 applied

2012-08-16 Thread Mauro Carvalho Chehab 
Em 16-08-2012 06:24, Sylwester Nawrocki escreveu:
> Hi Mauro,
> 
> On 08/14/2012 01:59 PM, Mauro Carvalho Chehab wrote:
>> Anyway, in order to help people that might still have patches against
>> the old structure, I created a small script and added them at the
>> media_build tree:
>>  
>> http://git.linuxtv.org/media_build.git/blob/HEAD:/devel_scripts/rename_patch.sh
>>
>> (in fact, I created an script that auto-generated it ;) )
>>
>> To use it, all you need to do is:
>>
>>  $ ./rename_patch.sh your_patch
>>
>> As usual, if you want to change several patches, you could do:
>>  $ git format_patch some_reference_cs
>>
>> and apply the rename_patch.sh to the generated 0*.patch files, like
>>  $ for i in 0*.patch; do ./rename_patch.sh $i; done
>>
>> More details about that are at the readme file:
>>  http://git.linuxtv.org/media_build.git/blob/HEAD:/devel_scripts/README
> 
> Thanks for preparing this little helper script! It's helpful since I have
> quite a few pending patches, and it also saves time when porting patches
> from older kernel trees.

Anytime!

Anyway, I'm running this script here, when a patch doesn't apply, so, you
don't urge to port patches to the new structure.

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

Re: [git:v4l-dvb/for_v3.7] [media] media: rc: Introduce RX51 IR transmitter driver

2012-08-16 Thread Sakari Ailus 
Moi,

On Wed, Aug 15, 2012 at 10:46:43PM +0300, Timo Kokkonen wrote:
> Long time no see.

Indeed! Better late than never I guess. :)

> On 08/15/12 19:06, Sakari Ailus wrote:
> > Heippa,
> > 
> > Thanks for the patch! I know Mauro has already applied this so any changes
> > would make a separate patch.
> > 
> 
> Patches are cheap :) I'll have also couple of changes from Sean's comments.
> 
> > I have tested this up to the point I can see that the IR LED blinks  ---
> > using my phone's camera. :-) But I have no receivers so the testing ends to
> > this.
> 
> Thanks for your thorough review and testing.

You're welcome. It's nice to see people working on the N900 support. ;)

> > On Mon, Aug 13, 2012 at 09:53:45PM +0200, Mauro Carvalho Chehab wrote:
> >> This is an automatic generated email to let you know that the following 
> >> patch were queued at the 
> >> http://git.linuxtv.org/media_tree.git tree:
> >>
> >> Subject: [media] media: rc: Introduce RX51 IR transmitter driver
> >> Author:  Timo Kokkonen 
> >> Date:Fri Aug 10 06:16:36 2012 -0300
> >>
> >> This is the driver for the IR transmitter diode found on the Nokia
> >> N900 (also known as RX51) device. The driver is mostly the same as
> >> found in the original 2.6.28 based kernel that comes with the device.
> >>
> >> The following modifications have been made compared to the original
> >> driver version:
> >>
> >> - Adopt to the changes that has happen in the kernel during the past
> >>   five years, such as the change in the include paths
> >>
> >> - The OMAP DM-timers require much more care nowadays. The timers need
> >>   to be enabled and disabled or otherwise many actions fail. Timers
> >>   must not be freed without first stopping them or otherwise the timer
> >>   cannot be requested again.
> >>
> >> The code has been tested with sending IR codes with N900 device
> >> running Debian userland. The device receiving the codes was Anysee
> >> DVB-C USB receiver.
> > 
> > Just a general question: how much this driver actually depends on the N900?
> > I can see there's a dependency to OMAP DM timers, but couldn't you use the
> > same driver if you just wired the IR LED there? Even the timer configuration
> > is there, so it looks a lot more generic than N900-specific.
> > 
> 
> Yeah, I was thinking that there are no other boards that have an IR
> diode connected to the PWM timer pin. But that doesn't stop anyone from
> soldering a diode one to his/her board.
> 
> >> Signed-off-by: Timo Kokkonen 
> >> Cc: Tony Lindgren 
> >> Cc: linux-o...@vger.kernel.org
> >> Cc: Sakari Ailus 
> >> Signed-off-by: Mauro Carvalho Chehab 
> >>
> >>  drivers/media/rc/Kconfig   |   10 +
> >>  drivers/media/rc/Makefile  |1 +
> >>  drivers/media/rc/ir-rx51.c |  496 
> >> 
> >>  include/media/ir-rx51.h|   10 +
> >>  4 files changed, 517 insertions(+), 0 deletions(-)
> >>
> >> ---
> >>
> >> http://git.linuxtv.org/media_tree.git?a=commitdiff;h=c332e8472d7db67766bcad33390c607fdd9ac5bc
> >>
> >> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> >> index 64be610..016f9ab 100644
> >> --- a/drivers/media/rc/Kconfig
> >> +++ b/drivers/media/rc/Kconfig
> >> @@ -287,6 +287,16 @@ config IR_TTUSBIR
> >>   To compile this driver as a module, choose M here: the module will
> >>   be called ttusbir.
> >>  
> >> +config IR_RX51
> >> +  tristate "Nokia N900 IR transmitter diode
> >> +  depends on MACH_NOKIA_RX51 && OMAP_DM_TIMER
> > 
> > You also should depend on LIRC.
> 
> Yes. And if one had the diode in some other board than RX51, maybe this
> wouldn't need to depend on MACH_NOKIA_RX51 either.
> 
> ...
> 
> 
> Which gave me an idea. We have this new PWM subsystem that I know
> nothing about. If the omap timer PWM routines were exposed through this
> API, we could modify this driver to a generic PWM lirc driver. I don't
> know how well the PWM api suits for that purpose, but it could be an
> interesting idea.. :)

Sounds like an excellent idea. If the PWM subsystem couldn't be used for
this it'd be very valuable input for the design of that API.

That's something for future though, as I guess the OMAP DM timers aren't yet
supported by the PWM framework. This pull req has support for many sub-archs
but not for OMAPs. :I

http://www.spinics.net/lists/arm-kernel/msg180746.html>

It might not make sense to rename the driver before moving to PWM API but a
note saying it can be used on any OMAP ? for the same would be nice.

> >> +  ---help---
> >> + Say Y or M here if you want to enable support for the IR
> >> + transmitter diode built in the Nokia N900 (RX51) device.
> >> +
> >> + The driver uses omap DM timers for gereating the carrier
> > 
> > s/gereating/renerating/
> > 
> 
> Uh oh, will fix..
> 
> >> + wave and pulses.
> >> +
> >>  config RC_LOOPBACK
> >>tristate "Remote Control Loopback Driver"
> >>depends on RC_CORE
> >> diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Mak

Re: [PATCH v3 3/4] media: videobuf2-dma-contig: use dma_mmap_coherent if available

2012-08-16 Thread Hideki EIRAKU 
Hello,

From: Marek Szyprowski 
Subject: RE: [PATCH v3 3/4] media: videobuf2-dma-contig: use dma_mmap_coherent 
if available
Date: Tue, 07 Aug 2012 16:53:25 +0200

> I'm sorry for bringing this issue now, once you have already created v3 of 
> your
> patches, but similar patch has been already proposed some time ago. It is 
> already
> processed together with general videobuf2-dma-contig redesign and dma-buf 
> extensions
> by Tomasz Stanislawski.
> 
> See post http://thread.gmane.org/gmane.comp.video.dri.devel/70402/focus=49461 
> and
> http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/49438 
> 
> It doesn't use conditional code inside videobuf2 allocator and rely entirely 
> on 
> dma-mapping subsystem to provide a working 
> dma_mmap_coherent/writecombine/attrs() 
> function. When it was posted, it relied on the dma-mapping extensions, which 
> now
> have been finally merged to v3.6-rc1. Now I wonder if there are any 
> architectures, 
> which don't use dma_map_ops based dma-mapping framework, which might use 
> videobuf2-dma-conting module. 

Thank you for telling me about videobuf2-dma-contig and v3.6-rc1.  The
videobuf2-dma-contig patch I sent is now unnecessary.  So I will
remove the patch.  I will remove the patch defining
ARCH_HAS_DMA_MMAP_COHERENT too because the v3.6-rc1 kernel has generic
dma_mmap_coherent() API for every architecture.

I will also remove the Laurent's patch I sent because it was related
to ARCH_HAS_DMA_MMAP_COHERENT.

The remaining patch is sh_mobile_lcdc.  I will remove ifdefs from the
patch and re-post it as a patch v4.

-- 
Hideki EIRAKU 
--
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 4/4] s5p-fimc: Don't allocate fimc-m2m video device dynamically

2012-08-16 Thread Sylwester Nawrocki 
There is no need to to dynamically allocate struct video_device
for the M2M devices, so embed it instead in driver's private
data structure as it is done in case of fimc-capture and fimc-lite,
where it solves some bugs on cleanup paths.

Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
---
 drivers/media/platform/s5p-fimc/fimc-capture.c |3 ++
 drivers/media/platform/s5p-fimc/fimc-core.h|2 +-
 drivers/media/platform/s5p-fimc/fimc-m2m.c |   40 
 3 files changed, 17 insertions(+), 28 deletions(-)

diff --git a/drivers/media/platform/s5p-fimc/fimc-capture.c 
b/drivers/media/platform/s5p-fimc/fimc-capture.c
index 5d3a70f..4092388 100644
--- a/drivers/media/platform/s5p-fimc/fimc-capture.c
+++ b/drivers/media/platform/s5p-fimc/fimc-capture.c
@@ -1663,6 +1663,9 @@ static int fimc_capture_subdev_registered(struct 
v4l2_subdev *sd)
struct fimc_dev *fimc = v4l2_get_subdevdata(sd);
int ret;
 
+   if (fimc == NULL)
+   return -ENXIO;
+
ret = fimc_register_m2m_device(fimc, sd->v4l2_dev);
if (ret)
return ret;
diff --git a/drivers/media/platform/s5p-fimc/fimc-core.h 
b/drivers/media/platform/s5p-fimc/fimc-core.h
index 30f93f2..d3a3a00 100644
--- a/drivers/media/platform/s5p-fimc/fimc-core.h
+++ b/drivers/media/platform/s5p-fimc/fimc-core.h
@@ -287,7 +287,7 @@ struct fimc_frame {
  * @refcnt: the reference counter
  */
 struct fimc_m2m_device {
-   struct video_device *vfd;
+   struct video_device vfd;
struct v4l2_m2m_dev *m2m_dev;
struct fimc_ctx *ctx;
int refcnt;
diff --git a/drivers/media/platform/s5p-fimc/fimc-m2m.c 
b/drivers/media/platform/s5p-fimc/fimc-m2m.c
index c587011..293e602 100644
--- a/drivers/media/platform/s5p-fimc/fimc-m2m.c
+++ b/drivers/media/platform/s5p-fimc/fimc-m2m.c
@@ -370,7 +370,7 @@ static int fimc_m2m_s_fmt_mplane(struct file *file, void 
*fh,
vq = v4l2_m2m_get_vq(ctx->m2m_ctx, f->type);
 
if (vb2_is_busy(vq)) {
-   v4l2_err(fimc->m2m.vfd, "queue (%d) busy\n", f->type);
+   v4l2_err(&fimc->m2m.vfd, "queue (%d) busy\n", f->type);
return -EBUSY;
}
 
@@ -507,7 +507,7 @@ static int fimc_m2m_try_crop(struct fimc_ctx *ctx, struct 
v4l2_crop *cr)
int i;
 
if (cr->c.top < 0 || cr->c.left < 0) {
-   v4l2_err(fimc->m2m.vfd,
+   v4l2_err(&fimc->m2m.vfd,
"doesn't support negative values for top & left\n");
return -EINVAL;
}
@@ -577,7 +577,7 @@ static int fimc_m2m_s_crop(struct file *file, void *fh, 
struct v4l2_crop *cr)
cr->c.height, ctx->rotation);
}
if (ret) {
-   v4l2_err(fimc->m2m.vfd, "Out of scaler range\n");
+   v4l2_err(&fimc->m2m.vfd, "Out of scaler range\n");
return -EINVAL;
}
}
@@ -666,7 +666,7 @@ static int fimc_m2m_open(struct file *file)
ret = -ENOMEM;
goto unlock;
}
-   v4l2_fh_init(&ctx->fh, fimc->m2m.vfd);
+   v4l2_fh_init(&ctx->fh, &fimc->m2m.vfd);
ctx->fimc_dev = fimc;
 
/* Default color format */
@@ -784,38 +784,26 @@ static struct v4l2_m2m_ops m2m_ops = {
 int fimc_register_m2m_device(struct fimc_dev *fimc,
 struct v4l2_device *v4l2_dev)
 {
-   struct video_device *vfd;
-   struct platform_device *pdev;
-   int ret = 0;
-
-   if (!fimc)
-   return -ENODEV;
+   struct video_device *vfd = &fimc->m2m.vfd;
+   int ret;
 
-   pdev = fimc->pdev;
fimc->v4l2_dev = v4l2_dev;
 
-   vfd = video_device_alloc();
-   if (!vfd) {
-   v4l2_err(v4l2_dev, "Failed to allocate video device\n");
-   return -ENOMEM;
-   }
-
+   memset(vfd, 0, sizeof(*vfd));
vfd->fops = &fimc_m2m_fops;
vfd->ioctl_ops = &fimc_m2m_ioctl_ops;
vfd->v4l2_dev = v4l2_dev;
vfd->minor = -1;
-   vfd->release = video_device_release;
+   vfd->release = video_device_release_empty;
vfd->lock = &fimc->lock;
 
snprintf(vfd->name, sizeof(vfd->name), "fimc.%d.m2m", fimc->id);
video_set_drvdata(vfd, fimc);
 
-   fimc->m2m.vfd = vfd;
fimc->m2m.m2m_dev = v4l2_m2m_init(&m2m_ops);
if (IS_ERR(fimc->m2m.m2m_dev)) {
v4l2_err(v4l2_dev, "failed to initialize v4l2-m2m device\n");
-   ret = PTR_ERR(fimc->m2m.m2m_dev);
-   goto err_init;
+   return PTR_ERR(fimc->m2m.m2m_dev);
}
 
ret = media_entity_init(&vfd->entity, 0, NULL, 0);
@@ -834,8 +822,6 @@ err_vd:
media_entity_cleanup(&vfd->entity);
 err_me:
v4l2_m2m_release(fimc->m2m.m2m_dev);
-err_init:
-   video_device_release(fimc->m2m.vfd);
return ret;
 }

[PATCH 3/4] s5p-fimc: Don't allocate fimc-capture video device dynamically

2012-08-16 Thread Sylwester Nawrocki 
This fixes potential invalid pointer de-reference, when
media_entity_cleanup() is called before video device
is unregistered.

Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
---
 drivers/media/platform/s5p-fimc/fimc-capture.c |   28 
 drivers/media/platform/s5p-fimc/fimc-core.h|2 +-
 drivers/media/platform/s5p-fimc/fimc-mdevice.c |2 +-
 drivers/media/platform/s5p-fimc/fimc-mdevice.h |6 ++---
 drivers/media/platform/s5p-fimc/fimc-reg.c |6 ++---
 5 files changed, 16 insertions(+), 28 deletions(-)

diff --git a/drivers/media/platform/s5p-fimc/fimc-capture.c 
b/drivers/media/platform/s5p-fimc/fimc-capture.c
index 8e413dd..5d3a70f 100644
--- a/drivers/media/platform/s5p-fimc/fimc-capture.c
+++ b/drivers/media/platform/s5p-fimc/fimc-capture.c
@@ -304,7 +304,7 @@ int fimc_capture_resume(struct fimc_dev *fimc)
 
INIT_LIST_HEAD(&fimc->vid_cap.active_buf_q);
vid_cap->buf_index = 0;
-   fimc_pipeline_initialize(&fimc->pipeline, &vid_cap->vfd->entity,
+   fimc_pipeline_initialize(&fimc->pipeline, &vid_cap->vfd.entity,
 false);
fimc_capture_hw_init(fimc);
 
@@ -371,7 +371,7 @@ static int buffer_prepare(struct vb2_buffer *vb)
unsigned long size = ctx->d_frame.payload[i];
 
if (vb2_plane_size(vb, i) < size) {
-   v4l2_err(ctx->fimc_dev->vid_cap.vfd,
+   v4l2_err(&ctx->fimc_dev->vid_cap.vfd,
 "User buffer too small (%ld < %ld)\n",
 vb2_plane_size(vb, i), size);
return -EINVAL;
@@ -503,7 +503,7 @@ static int fimc_capture_open(struct file *file)
 
if (++fimc->vid_cap.refcnt == 1) {
ret = fimc_pipeline_initialize(&fimc->pipeline,
-  &fimc->vid_cap.vfd->entity, true);
+  &fimc->vid_cap.vfd.entity, true);
 
if (!ret && !fimc->vid_cap.user_subdev_api)
ret = fimc_capture_set_default_format(fimc);
@@ -1587,7 +1587,7 @@ static int fimc_capture_set_default_format(struct 
fimc_dev *fimc)
 static int fimc_register_capture_device(struct fimc_dev *fimc,
 struct v4l2_device *v4l2_dev)
 {
-   struct video_device *vfd;
+   struct video_device *vfd = &fimc->vid_cap.vfd;
struct fimc_vid_cap *vid_cap;
struct fimc_ctx *ctx;
struct vb2_queue *q;
@@ -1604,25 +1604,19 @@ static int fimc_register_capture_device(struct fimc_dev 
*fimc,
ctx->s_frame.fmt = fimc_find_format(NULL, NULL, FMT_FLAGS_CAM, 0);
ctx->d_frame.fmt = ctx->s_frame.fmt;
 
-   vfd = video_device_alloc();
-   if (!vfd) {
-   v4l2_err(v4l2_dev, "Failed to allocate video device\n");
-   goto err_vd_alloc;
-   }
-
+   memset(vfd, 0, sizeof(*vfd));
snprintf(vfd->name, sizeof(vfd->name), "fimc.%d.capture", fimc->id);
 
vfd->fops   = &fimc_capture_fops;
vfd->ioctl_ops  = &fimc_capture_ioctl_ops;
vfd->v4l2_dev   = v4l2_dev;
vfd->minor  = -1;
-   vfd->release= video_device_release;
+   vfd->release= video_device_release_empty;
vfd->lock   = &fimc->lock;
 
video_set_drvdata(vfd, fimc);
 
vid_cap = &fimc->vid_cap;
-   vid_cap->vfd = vfd;
vid_cap->active_buf_cnt = 0;
vid_cap->reqbufs_count  = 0;
vid_cap->refcnt = 0;
@@ -1660,8 +1654,6 @@ static int fimc_register_capture_device(struct fimc_dev 
*fimc,
 err_vd:
media_entity_cleanup(&vfd->entity);
 err_ent:
-   video_device_release(vfd);
-err_vd_alloc:
kfree(ctx);
return ret;
 }
@@ -1691,12 +1683,10 @@ static void fimc_capture_subdev_unregistered(struct 
v4l2_subdev *sd)
 
fimc_unregister_m2m_device(fimc);
 
-   if (fimc->vid_cap.vfd) {
-   media_entity_cleanup(&fimc->vid_cap.vfd->entity);
-   video_unregister_device(fimc->vid_cap.vfd);
-   fimc->vid_cap.vfd = NULL;
+   if (video_is_registered(&fimc->vid_cap.vfd)) {
+   video_unregister_device(&fimc->vid_cap.vfd);
+   media_entity_cleanup(&fimc->vid_cap.vfd.entity);
}
-
kfree(fimc->vid_cap.ctx);
fimc->vid_cap.ctx = NULL;
 }
diff --git a/drivers/media/platform/s5p-fimc/fimc-core.h 
b/drivers/media/platform/s5p-fimc/fimc-core.h
index 808ccc6..30f93f2 100644
--- a/drivers/media/platform/s5p-fimc/fimc-core.h
+++ b/drivers/media/platform/s5p-fimc/fimc-core.h
@@ -320,7 +320,7 @@ struct fimc_m2m_device {
 struct fimc_vid_cap {
struct fimc_ctx *ctx;
struct vb2_alloc_ctx*alloc_ctx;
-   struct video_device *vfd;
+   struct video_device vfd;
struct v4l2_subdev  subdev;
struct media_padvd_pad;
struct v4

[PATCH 2/4] s5p-fimc: Don't allocate fimc-lite video device structure dynamically

2012-08-16 Thread Sylwester Nawrocki 
This fixes potential invalid pointer de-reference, when
media_entity_cleanup() is called after video_unregister_device,
and video device structure memory is already freed.

Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
---
 drivers/media/platform/s5p-fimc/fimc-lite-reg.c |2 +-
 drivers/media/platform/s5p-fimc/fimc-lite.c |   42 +--
 drivers/media/platform/s5p-fimc/fimc-lite.h |2 +-
 drivers/media/platform/s5p-fimc/fimc-mdevice.c  |2 +-
 4 files changed, 19 insertions(+), 29 deletions(-)

diff --git a/drivers/media/platform/s5p-fimc/fimc-lite-reg.c 
b/drivers/media/platform/s5p-fimc/fimc-lite-reg.c
index f996e94..09dc71e 100644
--- a/drivers/media/platform/s5p-fimc/fimc-lite-reg.c
+++ b/drivers/media/platform/s5p-fimc/fimc-lite-reg.c
@@ -137,7 +137,7 @@ void flite_hw_set_source_format(struct fimc_lite *dev, 
struct flite_frame *f)
}
 
if (i == 0 && src_pixfmt_map[i][0] != pixelcode) {
-   v4l2_err(dev->vfd,
+   v4l2_err(&dev->vfd,
 "Unsupported pixel code, falling back to %#08x\n",
 src_pixfmt_map[i][0]);
}
diff --git a/drivers/media/platform/s5p-fimc/fimc-lite.c 
b/drivers/media/platform/s5p-fimc/fimc-lite.c
index c5b57e8..9289008 100644
--- a/drivers/media/platform/s5p-fimc/fimc-lite.c
+++ b/drivers/media/platform/s5p-fimc/fimc-lite.c
@@ -374,7 +374,7 @@ static int buffer_prepare(struct vb2_buffer *vb)
unsigned long size = fimc->payload[i];
 
if (vb2_plane_size(vb, i) < size) {
-   v4l2_err(fimc->vfd,
+   v4l2_err(&fimc->vfd,
 "User buffer too small (%ld < %ld)\n",
 vb2_plane_size(vb, i), size);
return -EINVAL;
@@ -467,7 +467,7 @@ static int fimc_lite_open(struct file *file)
 
if (++fimc->ref_count == 1 && fimc->out_path == FIMC_IO_DMA) {
ret = fimc_pipeline_initialize(&fimc->pipeline,
-  &fimc->vfd->entity, true);
+  &fimc->vfd.entity, true);
if (ret < 0) {
pm_runtime_put_sync(&fimc->pdev->dev);
fimc->ref_count--;
@@ -1215,18 +1215,14 @@ static int fimc_lite_subdev_registered(struct 
v4l2_subdev *sd)
 {
struct fimc_lite *fimc = v4l2_get_subdevdata(sd);
struct vb2_queue *q = &fimc->vb_queue;
-   struct video_device *vfd;
+   struct video_device *vfd = &fimc->vfd;
int ret;
 
+   memset(vfd, 0, sizeof(*vfd));
+
fimc->fmt = &fimc_lite_formats[0];
fimc->out_path = FIMC_IO_DMA;
 
-   vfd = video_device_alloc();
-   if (!vfd) {
-   v4l2_err(sd->v4l2_dev, "Failed to allocate video device\n");
-   return -ENOMEM;
-   }
-
snprintf(vfd->name, sizeof(vfd->name), "fimc-lite.%d.capture",
 fimc->index);
 
@@ -1234,9 +1230,8 @@ static int fimc_lite_subdev_registered(struct v4l2_subdev 
*sd)
vfd->ioctl_ops = &fimc_lite_ioctl_ops;
vfd->v4l2_dev = sd->v4l2_dev;
vfd->minor = -1;
-   vfd->release = video_device_release;
+   vfd->release = video_device_release_empty;
vfd->lock = &fimc->lock;
-   fimc->vfd = vfd;
fimc->ref_count = 0;
fimc->reqbufs_count = 0;
 
@@ -1255,24 +1250,20 @@ static int fimc_lite_subdev_registered(struct 
v4l2_subdev *sd)
 
fimc->vd_pad.flags = MEDIA_PAD_FL_SINK;
ret = media_entity_init(&vfd->entity, 1, &fimc->vd_pad, 0);
-   if (ret)
-   goto err;
+   if (ret < 0)
+   return ret;
 
video_set_drvdata(vfd, fimc);
 
ret = video_register_device(vfd, VFL_TYPE_GRABBER, -1);
-   if (ret)
-   goto err_vd;
+   if (ret < 0) {
+   media_entity_cleanup(&vfd->entity);
+   return ret;
+   }
 
v4l2_info(sd->v4l2_dev, "Registered %s as /dev/%s\n",
  vfd->name, video_device_node_name(vfd));
return 0;
-
- err_vd:
-   media_entity_cleanup(&vfd->entity);
- err:
-   video_device_release(vfd);
-   return ret;
 }
 
 static void fimc_lite_subdev_unregistered(struct v4l2_subdev *sd)
@@ -1282,10 +1273,9 @@ static void fimc_lite_subdev_unregistered(struct 
v4l2_subdev *sd)
if (fimc == NULL)
return;
 
-   if (fimc->vfd) {
-   video_unregister_device(fimc->vfd);
-   media_entity_cleanup(&fimc->vfd->entity);
-   fimc->vfd = NULL;
+   if (video_is_registered(&fimc->vfd)) {
+   video_unregister_device(&fimc->vfd);
+   media_entity_cleanup(&fimc->vfd.entity);
}
 }
 
@@ -1515,7 +1505,7 @@ static int fimc_lite_resume(struct device *dev)
return 0;
 
INIT_LIST_HEAD(&fimc->active_buf_q);
-   fimc_pipeline_init

[PATCH 1/4] s5p-fimc: Enable FIMC-LITE driver only for SOC_EXYNOS4x12

2012-08-16 Thread Sylwester Nawrocki 
Allow to compile-in the FIMC-LITE driver only on Exynos4212,
Exynos4412 and Exynos5250 SoC where the device is available.

Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
---
 drivers/media/platform/s5p-fimc/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/s5p-fimc/Kconfig 
b/drivers/media/platform/s5p-fimc/Kconfig
index a564f7e..8f090a8 100644
--- a/drivers/media/platform/s5p-fimc/Kconfig
+++ b/drivers/media/platform/s5p-fimc/Kconfig
@@ -31,7 +31,7 @@ config VIDEO_S5P_MIPI_CSIS
  To compile this driver as a module, choose M here: the
  module will be called s5p-csis.
 
-if ARCH_EXYNOS
+if SOC_EXYNOS4212 || SOC_EXYNOS4412 || SOC_EXYNOS5250
 
 config VIDEO_EXYNOS_FIMC_LITE
tristate "EXYNOS FIMC-LITE camera interface driver"
-- 
1.7.10

--
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] ddbridge: fix error handling in module_init_ddbridge()

2012-08-16 Thread Mauro Carvalho Chehab 
Em 16-08-2012 06:26, Mauro Carvalho Chehab escreveu:
> Em 15-08-2012 17:42, Alexey Khoroshilov escreveu:
>> If pci_register_driver() failed, resources allocated in
>> ddb_class_create() are leaked. The patch fixes it.
>>
>> Found by Linux Driver Verification project (linuxtesting.org).
>>
>> Signed-off-by: Alexey Khoroshilov 
>> ---
>>  drivers/media/dvb/ddbridge/ddbridge-core.c |6 +-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/media/dvb/ddbridge/ddbridge-core.c 
>> b/drivers/media/dvb/ddbridge/ddbridge-core.c
>> index ebf3f05..36aa4e4 100644
>> --- a/drivers/media/dvb/ddbridge/ddbridge-core.c
>> +++ b/drivers/media/dvb/ddbridge/ddbridge-core.c
>> @@ -1705,7 +1705,11 @@ static __init int module_init_ddbridge(void)
>> "Copyright (C) 2010-11 Digital Devices GmbH\n");
>>  if (ddb_class_create())
>>  return -1;
> 
> This is not right. It should be returning a proper error code.

Please discard this email. I already commented this on a previous email.
This one was a previous draft.

Thanks,
Mauro

> 
> Could you please patch ddb_class_create() in order to make it to
> return the retuned value from IS_ERR() as the error code, and return
> it back to the init code?
> 
> Ok, I noticed that other parts of the driver are also returning wrong
> error codes, but let's fix at least module_init_ddbridge() while you're
> looking into this.
> 
>> -return pci_register_driver(&ddb_pci_driver);
>> +if (pci_register_driver(&ddb_pci_driver) < 0) {
>> +ddb_class_destroy();
>> +return -1;
> 
> The correct here would be to store the error on a temp register
> and return it, instead of returning -1.
> 
>> +}
>> +return 0;
>>  }
>>  
>>  static __exit void module_exit_ddbridge(void)
>>
> 
> Thank you!
> 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
> 

--
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] ddbridge: fix error handling in module_init_ddbridge()

2012-08-16 Thread Mauro Carvalho Chehab 
Em 15-08-2012 17:42, Alexey Khoroshilov escreveu:
> If pci_register_driver() failed, resources allocated in
> ddb_class_create() are leaked. The patch fixes it.
> 
> Found by Linux Driver Verification project (linuxtesting.org).
> 
> Signed-off-by: Alexey Khoroshilov 
> ---
>  drivers/media/dvb/ddbridge/ddbridge-core.c |6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/dvb/ddbridge/ddbridge-core.c 
> b/drivers/media/dvb/ddbridge/ddbridge-core.c
> index ebf3f05..36aa4e4 100644
> --- a/drivers/media/dvb/ddbridge/ddbridge-core.c
> +++ b/drivers/media/dvb/ddbridge/ddbridge-core.c
> @@ -1705,7 +1705,11 @@ static __init int module_init_ddbridge(void)
>  "Copyright (C) 2010-11 Digital Devices GmbH\n");
>   if (ddb_class_create())
>   return -1;

This is not right. It should be returning a proper error code.

Could you please patch ddb_class_create() in order to make it to
return the retuned value from IS_ERR() as the error code, and return
it back to the init code?

Ok, I noticed that other parts of the driver are also returning wrong
error codes, but let's fix at least module_init_ddbridge() while you're
looking into this.

> - return pci_register_driver(&ddb_pci_driver);
> + if (pci_register_driver(&ddb_pci_driver) < 0) {
> + ddb_class_destroy();
> + return -1;

The correct here would be to store the error on a temp register
and return it, instead of returning -1.

> + }
> + return 0;
>  }
>  
>  static __exit void module_exit_ddbridge(void)
> 

Thank you!
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: [ANNOUNCE] tree renaming patches part 1 applied

2012-08-16 Thread Sylwester Nawrocki 
Hi Mauro,

On 08/14/2012 01:59 PM, Mauro Carvalho Chehab wrote:
> Anyway, in order to help people that might still have patches against
> the old structure, I created a small script and added them at the
> media_build tree:
>   
> http://git.linuxtv.org/media_build.git/blob/HEAD:/devel_scripts/rename_patch.sh
> 
> (in fact, I created an script that auto-generated it ;) )
> 
> To use it, all you need to do is:
> 
>   $ ./rename_patch.sh your_patch
> 
> As usual, if you want to change several patches, you could do:
>   $ git format_patch some_reference_cs
> 
> and apply the rename_patch.sh to the generated 0*.patch files, like
>   $ for i in 0*.patch; do ./rename_patch.sh $i; done
> 
> More details about that are at the readme file:
>   http://git.linuxtv.org/media_build.git/blob/HEAD:/devel_scripts/README

Thanks for preparing this little helper script! It's helpful since I have
quite a few pending patches, and it also saves time when porting patches
from older kernel trees.

--
Regards,
Sylwester
--
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 PATCHv2 0/1] Adding core TMC decoding support to RDS library

2012-08-16 Thread Hans Verkuil 
On Wed August 15 2012 16:30:57 Konke Radlow wrote:
> this patch is an updated version of the last RDS-TMC core support patch. 
> 
> The changes proposed by Hans Verkuil were implemented. In addition
> the handling and decoding of multi-group TMC messages was heavily modified,
> in order to improve read- and maintainability

If there are no further comments, then I plan on merging this tomorrow.

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: (still) NULL pointer crashes with nuvoton_cir driver

2012-08-16 Thread Matthijs Kooijman 
Hi folks,

> I'm currently compiling a 3.5 kernel with just the rdev initialization
> moved up to see if this will fix my problem at all, but I'd like your
> view on this in the meantime as well.
Ok, this seems to fix my problem:

--- a/drivers/media/rc/nuvoton-cir.c
+++ b/drivers/media/rc/nuvoton-cir.c
@@ -1066,6 +1066,7 @@
/* tx bits */
rdev->tx_resolution = XYZ;
 #endif
+   nvt->rdev = rdev;
 
ret = -EBUSY;
/* now claim resources */
@@ -1090,7 +1091,6 @@
goto failure5;
 
device_init_wakeup(&pdev->dev, true);
-   nvt->rdev = rdev;
nvt_pr(KERN_NOTICE, "driver has been successfully loaded\n");
if (debug) {
cir_dump_regs(nvt);


I'm still not sure if the rc_register_device shouldn't also be moved up. It
seems this doesn't trigger a problem right now, but if there is a problem, I
suspect its trigger window is a lot smaller than with the rdev initialization
problem...

Gr.

Matthijs


signature.asc
Description: Digital signature

Re: noisy dev_dbg_ratelimited()

2012-08-16 Thread Hiroshi Doyu 
Hi Antti,

Antti Palosaari  wrote @ Thu, 16 Aug 2012 03:11:56 +0200:

> Hello Hiroshi,
> 
> I see you have added dev_dbg_ratelimited() recently, commit 
> 6ca045930338485a8cdef117e74372aa1678009d .
> 
> However it seems to be noisy as expected similar behavior than normal 
> dev_dbg() without a ratelimit.
> 
> I looked ratelimit.c and there is:
> printk(KERN_WARNING "%s: %d callbacks suppressed\n", func, rs->missed);
> 
> What it looks my eyes it will print those "callbacks suppressed" always 
> because KERN_WARNING.

Right. Can the following fix the problem?

>From 905b1dedb6c64bc46a70f6d203ef98c23fccb107 Mon Sep 17 00:00:00 2001
From: Hiroshi Doyu 
Date: Thu, 16 Aug 2012 10:02:11 +0300
Subject: [PATCH 1/1] driver-core: Shut up dev_dbg_reatelimited() without
 DEBUG

dev_dbg_reatelimited() without DEBUG printed "217078 callbacks
suppressed". This shouldn't print anything without DEBUG.

Signed-off-by: Hiroshi Doyu 
Reported-by: Antti Palosaari 
---
 include/linux/device.h |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/include/linux/device.h b/include/linux/device.h
index eb945e1..d4dc26e 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -962,9 +962,13 @@ do {   
\
dev_level_ratelimited(dev_notice, dev, fmt, ##__VA_ARGS__)
 #define dev_info_ratelimited(dev, fmt, ...)\
dev_level_ratelimited(dev_info, dev, fmt, ##__VA_ARGS__)
+#if defined(DEBUG)
 #define dev_dbg_ratelimited(dev, fmt, ...) \
dev_level_ratelimited(dev_dbg, dev, fmt, ##__VA_ARGS__)
-
+#else
+#define dev_dbg_ratelimited(dev, fmt, ...) \
+   no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
+#endif
 /*
  * Stupid hackaround for existing uses of non-printk uses dev_info
  *
-- 
1.7.5.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