Re: Re: [PATCH 3/3] DVBSky V3 PCIe card: add some changes to M88DS3103for supporting the demod of M88RS6000

[Nibble Max]

>
>
>On 10/13/2014 09:44 AM, Nibble Max wrote:
>> M88RS6000 is the integrated chip, which includes tuner and demod.
>> Its internal demod is similar with M88DS3103 except some registers 
>> definition.
>> The main different part of this internal demod from others is its clock/pll 
>> generation IP block sitting inside the tuner die.
>> So clock/pll functions should be configed through its tuner i2c bus, NOT its 
>> demod i2c bus.
>> The demod of M88RS6000 need the firmware: dvb-demod-m88rs6000.fw
>> firmware download link: 
>> http://www.dvbsky.net/download/linux/dvbsky-firmware.tar.gz
>
>> @@ -250,6 +251,7 @@ static int m88ds3103_set_frontend(struct dvb_frontend 
>> *fe)
>>  u16 u16tmp, divide_ratio;
>>  u32 tuner_frequency, target_mclk;
>>  s32 s32tmp;
>> +struct m88rs6000_mclk_config mclk_cfg;
>>
>>  dev_dbg(&priv->i2c->dev,
>>  "%s: delivery_system=%d modulation=%d frequency=%d 
>> symbol_rate=%d inversion=%d pilot=%d rolloff=%d\n",
>> @@ -291,6 +293,26 @@ static int m88ds3103_set_frontend(struct dvb_frontend 
>> *fe)
>>  if (ret)
>>  goto err;
>>
>> +if (priv->chip_id == M88RS6000_CHIP_ID) {
>> +ret = m88ds3103_wr_reg(priv, 0x06, 0xe0);
>> +if (ret)
>> +goto err;
>> +if (fe->ops.tuner_ops.set_config) {
>> +/* select main mclk */
>> +mclk_cfg.config_op = 0;
>> +mclk_cfg.TunerfreqMHz = c->frequency / 1000;
>> +mclk_cfg.SymRateKSs = c->symbol_rate / 1000;
>> +ret = fe->ops.tuner_ops.set_config(fe, &mclk_cfg);
>> +if (ret)
>> +goto err;
>> +priv->mclk_khz = mclk_cfg.MclkKHz;
>> +}
>> +ret = m88ds3103_wr_reg(priv, 0x06, 0x00);
>> +if (ret)
>> +goto err;
>> +usleep_range(1, 2);
>> +}
>
>That looks odd and also ugly. You pass some values from demod to tuner 
>using set_config callback. Tuner driver can get symbol_rate and 
>frequency just similarly from property cache than demod. Why you do it 
>like that?
>
>Clock is provided by tuner as you mention. I see you use that to pass 
>used clock frequency from tuner to demod. This does not look nice and I 
>would like to see clock framework instead. Or calculate clock on both 
>drivers. Does the demod clock even needs to be changed? I think it is 
>only TS stream size which defines used clock frequency - smaller the TS 
>bitstream, the smaller the clock frequency needed => optimizes power 
>consumption a little. But TS clock is calculated on tuner driver in any 
>case?
>
Yes, M88RS6000 looks odd. This integrated chip has two part die, tuner die and 
demod die.
Its demod's clock(PLL) block is sitting insided the tuner die. The demod has no 
PLL ip block that makes demod die smaller.
The demod's clock can be adjusted according to the transponder's frequency and 
symbol rate.
So that the demod's clock and its harmonic frequency will not overlap with the 
transponder's frequency range.
It will improve its tuner's sensitivity.

However the tuner driver can get the values from property cache.
Tuner driver does not know when need adjust this demod pll
and return the current demod pll value to the demod driver.
in "struct dvb_tuner_ops", there is no call back to do this directly.
So I select the general "set_config" call back.
TS main clock of demdod also need to be controlled in the tuner die.

These demod's PLL registers have no relationship with tuner at all.
Logically, These demod's PLL registers should go with demod die as usual.
But in this case they goes with the tuner die physically and controlled through 
tuner i2c bus.

The current dvb-frontend driver requires the tuner and demod to split into the 
seperate drivers.
The demod driver will not access tuner i2c bus directly.
But this integrate chip has more tighter relationship of its tuner and demod 
die.
That is reason why these odd call backs happen.

>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 v2] media: soc_camera: rcar_vin: Enable VSYNC field toggle mode

[Yoshihiro Kaneko]

From: Koji Matsuoka 

By applying this patch, it sets to VSYNC field toggle mode not only
at the time of progressive mode but at the time of an interlace mode.

Signed-off-by: Koji Matsuoka 
Signed-off-by: Yoshihiro Kaneko 
---

This patch is against master branch of linuxtv.org/media_tree.git.

v2 [Yoshihiro Kaneko]
* improve the macro definition for the VLV field

 drivers/media/platform/soc_camera/rcar_vin.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/soc_camera/rcar_vin.c 
b/drivers/media/platform/soc_camera/rcar_vin.c
index 9300076..beaf8e5 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -107,6 +107,7 @@
 #define VNDMR2_VPS (1 << 30)
 #define VNDMR2_HPS (1 << 29)
 #define VNDMR2_FTEV(1 << 17)
+#define VNDMR2_VLV(n)  ((n & 0xf) << 12)
 
 #define VIN_MAX_WIDTH  2048
 #define VIN_MAX_HEIGHT 2048
@@ -827,7 +828,7 @@ static int rcar_vin_set_bus_param(struct soc_camera_device 
*icd)
if (ret < 0 && ret != -ENOIOCTLCMD)
return ret;
 
-   val = priv->field == V4L2_FIELD_NONE ? VNDMR2_FTEV : 0;
+   val = VNDMR2_FTEV | VNDMR2_VLV(1);
if (!(common_flags & V4L2_MBUS_VSYNC_ACTIVE_LOW))
val |= VNDMR2_VPS;
if (!(common_flags & V4L2_MBUS_HSYNC_ACTIVE_LOW))
-- 
1.9.1

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

Re: [PATCH] media: soc_camera: rcar_vin: Enable VSYNC field toggle mode

[Yoshihiro Kaneko]

Hi Geert-san,

2014-10-21 16:09 GMT+09:00 Geert Uytterhoeven :
> Hi Kaneko-san,
>
> On Tue, Oct 21, 2014 at 5:30 AM, Yoshihiro Kaneko  
> wrote:
 --- a/drivers/media/platform/soc_camera/rcar_vin.c
 +++ b/drivers/media/platform/soc_camera/rcar_vin.c
 @@ -108,6 +108,7 @@
   #define VNDMR2_VPS(1 << 30)
   #define VNDMR2_HPS(1 << 29)
   #define VNDMR2_FTEV   (1 << 17)
 +#define VNDMR2_VLV_1   (1 << 12)
>>>
>>>Please instead do:
>>>
>>> #define VNDMR2_VLV(n)   ((n & 0xf) << 12)
>>
>> It's unclear to me why the style of the new #define should differ
>> from those of the existing ones.
>
> I think Sergey wants to say that unlike for the other fields, there are
> multiple possible values for the VLV field.
>
> By providing the single macro definition
>
> #define VNDMR2_VLV(n)   ((n & 0xf) << 12)
>
> you can easily provide a way to set any of VNDMR2_VLV_n.
>
> I hope this explanation makes it clearer.

Thank you for the clarification!
I'll update this patch sooner.

Thanks,
Kaneko

>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
--
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

[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:   Wed Oct 22 04:00:29 CEST 2014
git branch: test
git hash:   1ef24960ab78554fe7e8e77d8fc86524fbd60d3c
gcc version:i686-linux-gcc (GCC) 4.9.1
sparse version: v0.5.0-20-g7abd8a7
host hardware:  x86_64
host os:3.17-0.slh.1-amd64

linux-git-arm-at91: ERRORS
linux-git-arm-davinci: ERRORS
linux-git-arm-exynos: ERRORS
linux-git-arm-mx: ERRORS
linux-git-arm-omap: ERRORS
linux-git-arm-omap1: ERRORS
linux-git-arm-pxa: ERRORS
linux-git-blackfin: ERRORS
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: ERRORS
linux-git-powerpc64: OK
linux-git-sh: ERRORS
linux-git-x86_64: OK
linux-2.6.32.27-i686: WARNINGS
linux-2.6.33.7-i686: WARNINGS
linux-2.6.34.7-i686: WARNINGS
linux-2.6.35.9-i686: WARNINGS
linux-2.6.36.4-i686: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.2.37-i686: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.4.27-i686: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: WARNINGS
linux-3.12.23-i686: WARNINGS
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16-i686: WARNINGS
linux-3.17-i686: OK
linux-2.6.32.27-x86_64: WARNINGS
linux-2.6.33.7-x86_64: WARNINGS
linux-2.6.34.7-x86_64: WARNINGS
linux-2.6.35.9-x86_64: WARNINGS
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.37-x86_64: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: WARNINGS
linux-3.12.23-x86_64: WARNINGS
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16-x86_64: WARNINGS
linux-3.17-x86_64: WARNINGS
apps: OK
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: [PATCH 3/3] DVBSky V3 PCIe card: add some changes to M88DS3103 for supporting the demod of M88RS6000

[Antti Palosaari]

On 10/13/2014 09:44 AM, Nibble Max wrote:

M88RS6000 is the integrated chip, which includes tuner and demod.
Its internal demod is similar with M88DS3103 except some registers definition.
The main different part of this internal demod from others is its clock/pll 
generation IP block sitting inside the tuner die.
So clock/pll functions should be configed through its tuner i2c bus, NOT its 
demod i2c bus.
The demod of M88RS6000 need the firmware: dvb-demod-m88rs6000.fw
firmware download link: 
http://www.dvbsky.net/download/linux/dvbsky-firmware.tar.gz



@@ -250,6 +251,7 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
u16 u16tmp, divide_ratio;
u32 tuner_frequency, target_mclk;
s32 s32tmp;
+   struct m88rs6000_mclk_config mclk_cfg;

dev_dbg(&priv->i2c->dev,
"%s: delivery_system=%d modulation=%d frequency=%d 
symbol_rate=%d inversion=%d pilot=%d rolloff=%d\n",
@@ -291,6 +293,26 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
if (ret)
goto err;

+   if (priv->chip_id == M88RS6000_CHIP_ID) {
+   ret = m88ds3103_wr_reg(priv, 0x06, 0xe0);
+   if (ret)
+   goto err;
+   if (fe->ops.tuner_ops.set_config) {
+   /* select main mclk */
+   mclk_cfg.config_op = 0;
+   mclk_cfg.TunerfreqMHz = c->frequency / 1000;
+   mclk_cfg.SymRateKSs = c->symbol_rate / 1000;
+   ret = fe->ops.tuner_ops.set_config(fe, &mclk_cfg);
+   if (ret)
+   goto err;
+   priv->mclk_khz = mclk_cfg.MclkKHz;
+   }
+   ret = m88ds3103_wr_reg(priv, 0x06, 0x00);
+   if (ret)
+   goto err;
+   usleep_range(1, 2);
+   }


That looks odd and also ugly. You pass some values from demod to tuner 
using set_config callback. Tuner driver can get symbol_rate and 
frequency just similarly from property cache than demod. Why you do it 
like that?


Clock is provided by tuner as you mention. I see you use that to pass 
used clock frequency from tuner to demod. This does not look nice and I 
would like to see clock framework instead. Or calculate clock on both 
drivers. Does the demod clock even needs to be changed? I think it is 
only TS stream size which defines used clock frequency - smaller the TS 
bitstream, the smaller the clock frequency needed => optimizes power 
consumption a little. But TS clock is calculated on tuner driver in any 
case?


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

Chrity Code: MP389

[Antalya İl Halk Ktp .]

$1 Million USD. Has been donated to you kindly contact the donator Mr. Harry 
Black via personal email ( 
harryblac...@rogers.com )
--
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 1/2] [media] rc-core: fix protocol_change regression in ir_raw_event_register

[Tomas Melin]

IR reciever using nuvoton-cir and lirc required additional configuration
steps after upgrade from kernel 3.16 to 3.17-rcX.
Bisected regression to commit da6e162d6a4607362f8478c715c797d84d449f8b
("[media] rc-core: simplify sysfs code").

The regression comes from adding empty function change_protocol in
ir-raw.c. It changes behaviour so that only the protocol enabled by driver's
map_name will be active after registration. This breaks user space behaviour,
lirc does not get key press signals anymore.

Changed back to original behaviour by removing empty function
change_protocol in ir-raw.c. Instead only calling change_protocol for
drivers that actually have the function set up.

Signed-off-by: Tomas Melin 
---
 drivers/media/rc/rc-ir-raw.c |7 ---
 drivers/media/rc/rc-main.c   |   19 ---
 2 files changed, 8 insertions(+), 18 deletions(-)

diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
index e8fff2a..a118539 100644
--- a/drivers/media/rc/rc-ir-raw.c
+++ b/drivers/media/rc/rc-ir-raw.c
@@ -240,12 +240,6 @@ ir_raw_get_allowed_protocols(void)
return protocols;
 }
 
-static int change_protocol(struct rc_dev *dev, u64 *rc_type)
-{
-   /* the caller will update dev->enabled_protocols */
-   return 0;
-}
-
 /*
  * Used to (un)register raw event clients
  */
@@ -263,7 +257,6 @@ int ir_raw_event_register(struct rc_dev *dev)
 
dev->raw->dev = dev;
dev->enabled_protocols = ~0;
-   dev->change_protocol = change_protocol;
rc = kfifo_alloc(&dev->raw->kfifo,
 sizeof(struct ir_raw_event) * MAX_IR_EVENT_SIZE,
 GFP_KERNEL);
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index a7991c7..633c682 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1001,11 +1001,6 @@ static ssize_t store_protocols(struct device *device,
set_filter = dev->s_wakeup_filter;
}
 
-   if (!change_protocol) {
-   IR_dprintk(1, "Protocol switching not supported\n");
-   return -EINVAL;
-   }
-
mutex_lock(&dev->lock);
 
old_protocols = *current_protocols;
@@ -1013,12 +1008,14 @@ static ssize_t store_protocols(struct device *device,
rc = parse_protocol_change(&new_protocols, buf);
if (rc < 0)
goto out;
-
-   rc = change_protocol(dev, &new_protocols);
-   if (rc < 0) {
-   IR_dprintk(1, "Error setting protocols to 0x%llx\n",
-  (long long)new_protocols);
-   goto out;
+   /* Only if protocol change set up in driver */
+   if (change_protocol) {
+   rc = change_protocol(dev, &new_protocols);
+   if (rc < 0) {
+   IR_dprintk(1, "Error setting protocols to 0x%llx\n",
+  (long long)new_protocols);
+   goto out;
+   }
}
 
if (new_protocols == old_protocols) {
-- 
1.7.10.4

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

[PATCH v2 2/2] [media] rc-core: change enabled_protocol default setting

[Tomas Melin]

Change default setting for enabled protocols.
Instead of enabling all protocols during registration,
disable all except default keymap and lirc.
Reduces overhead since all protocols not handled by default.
Protocol to use will be enabled when keycode table is written by userspace.

Signed-off-by: Tomas Melin 
---
 drivers/media/rc/rc-ir-raw.c |1 -
 drivers/media/rc/rc-main.c   |6 --
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
index a118539..d3b1e76 100644
--- a/drivers/media/rc/rc-ir-raw.c
+++ b/drivers/media/rc/rc-ir-raw.c
@@ -256,7 +256,6 @@ int ir_raw_event_register(struct rc_dev *dev)
return -ENOMEM;
 
dev->raw->dev = dev;
-   dev->enabled_protocols = ~0;
rc = kfifo_alloc(&dev->raw->kfifo,
 sizeof(struct ir_raw_event) * MAX_IR_EVENT_SIZE,
 GFP_KERNEL);
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 633c682..dcdf4cd 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1320,6 +1320,8 @@ int rc_register_device(struct rc_dev *dev)
rc_map = rc_map_get(RC_MAP_EMPTY);
if (!rc_map || !rc_map->scan || rc_map->size == 0)
return -EINVAL;
+   /* get default keymap type */
+   u64 rc_type = (1 << rc_map->rc_type);
 
set_bit(EV_KEY, dev->input_dev->evbit);
set_bit(EV_REP, dev->input_dev->evbit);
@@ -1412,16 +1414,16 @@ int rc_register_device(struct rc_dev *dev)
raw_init = true;
}
rc = ir_raw_event_register(dev);
+   dev->enabled_protocols = (rc_type | RC_BIT_LIRC);
if (rc < 0)
goto out_input;
}
 
if (dev->change_protocol) {
-   u64 rc_type = (1 << rc_map->rc_type);
rc = dev->change_protocol(dev, &rc_type);
if (rc < 0)
goto out_raw;
-   dev->enabled_protocols = rc_type;
+   dev->enabled_protocols = (rc_type | RC_BIT_LIRC);
}
 
mutex_unlock(&dev->lock);
-- 
1.7.10.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: [PATCH 2/2] [media] rc-core: change enabled_protocol default setting

[Tomas Melin]

On Mon, Oct 20, 2014 at 5:12 PM, David Härdeman  wrote:
> On 2014-10-19 12:21, Tomas Melin wrote:
>>
>> Change default setting for enabled protocols.
>> Instead of enabling all protocols, disable all except lirc during
>> registration.
>> Reduces overhead since all protocols not handled by default.
>> Protocol to use will be enabled when keycode table is written by
>> userspace.
>
>
> I can see the appeal in this, but now you've disabled automatic decoding for
> the protocol specified by the keymap for raw drivers? So this would also be
> a change, right?

Yes, you are right. Atleast it potentially still could change expected
behaviour.

>
> I agree with Mauro that the "proper" long-term fix would be to teach the
> LIRC userspace daemon to enable the lirc protocol as/when necessary, but
> something similar to the patch below (but lirc + keymap protocol...if that's
> possible to implement in a non-intrusive manner, I haven't checked TBH)
> might be a good idea as an interim measure?
>
I think it looks feasible to implement that way. I'll look in to it
and send a new patch series.

Tomas

>
>
>>
>> Signed-off-by: Tomas Melin 
>> ---
>>  drivers/media/rc/rc-ir-raw.c |3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
>> index a118539..63d23d0 100644
>> --- a/drivers/media/rc/rc-ir-raw.c
>> +++ b/drivers/media/rc/rc-ir-raw.c
>> @@ -256,7 +256,8 @@ int ir_raw_event_register(struct rc_dev *dev)
>> return -ENOMEM;
>>
>> dev->raw->dev = dev;
>> -   dev->enabled_protocols = ~0;
>> +   /* by default, disable all but lirc*/
>> +   dev->enabled_protocols = RC_BIT_LIRC;
>> rc = kfifo_alloc(&dev->raw->kfifo,
>>  sizeof(struct ir_raw_event) * MAX_IR_EVENT_SIZE,
>>  GFP_KERNEL);
--
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: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api

[Shuah Khan]

On 10/21/2014 10:05 AM, Takashi Iwai wrote:
> At Tue, 21 Oct 2014 17:42:51 +0200,
> Hans Verkuil wrote:

>>
>> Quite often media apps open the alsa device at the start and then switch
>> between TV, radio or DVB mode. If the alsa device would claim the tuner
>> just by being opened (as opposed to actually using the tuner, which happens
>> when you start streaming),
> 
> What about parameter changes?  The sound devices have to be configured
> before using.  Don't they influence on others at all, i.e. you can
> change the PCM sample rate etc during TV, radio or DVB is running?

Yes. kaffeine uses  snd_usb_capture_ops ioctl -> snd_pcm_lib_ioctl

Other v4l and vlc (dvb) uses open/close as well as trigger start and
stop. trigger start/stop is done by a special audio thread in some
cases. open/close happens from the main thread.

> 
>> then that would make it impossible for the
>> application to switch tuner mode. In general you want to avoid that open()
>> will start configuring hardware since that can quite often be slow. Tuner
>> configuration in particular can be slow since several common tuners need
>> to load firmware over i2c. You only want to do that when it is really needed,
>> and not when some application (udev!) opens the device just to examine what
>> sort of device it is.
> 
> But most apps close the device soon after that, no?
> Which programs keep the PCM device (not the control) opened without
> actually using?
> 
>> So claiming the tuner in the trigger seems to be the right place. If
>> returning EBUSY is a poor error code for alsa, then we can use something else
>> for that. EACCES perhaps?
> 
> Sorry, I'm not convinced by that.  If the device has to be controlled
> exclusively, the right position is the open/close.  Otherwise, the
> program cannot know when it becomes inaccessible out of sudden during
> its operation.
> 
> 

Let me share my test matrix for this patch series. Hans pointed out
one test case I didn't know about as a result missed testing. Please
see if any of the tests miss use-cases or break them: you can scroll
down to the proposal at the end, if this is too much detail :)

Digital active and analog starting testing:
kaffeine running
- v4l2-ctl --all - works
- Changing channels works with the same token hold, even when
  frequency changes. Tested changing channels that force freq
  change.
- vlc resource is busy with no disruption to kaffeine
- xawtv - tuner busy when it tries to do ioctls that change
  tuner settings - snd_usb_pcm_open detects device is busy
  ( pcm open called from the same thread, trigger gets called
from another thread )
- tvtime - tuner busy when it tries to do ioctls that change
  tuner settings with no disruption to kaffeine
  ( pcm open called from the same thread, trigger gets called
from another thread )
- vlc - audio capture on WinTV HVR-950 - device is busy
  start vlc with no channels for this test
- arecord to capture on WinTV HVR-950 - device busy

vlc running
vlc -v channels.xspf
- v4l2-ctl --all - works
- Changing channels works with the same token hold, even when
  frequency changes. Tested changing channels that force freq
  change.
- kaffeine resource is busy with no disruption to vlc
- xawtv - tuner busy when it tries to do ioctls that change
  tuner settings - snd_usb_pcm_open detects device is busy
  ( pcm open called from the same thread, trigger gets called
from another thread )
- tvtime - tuner busy when it tries to do ioctls that change
  tuner settings with no disruption to kaffeine
  ( pcm open called from the same thread, trigger gets called
from another thread )
- vlc - audio capture on WinTV HVR-950 - device is busy
- arecord to capture on WinTV HVR-950 - device busy

Analog active and start digital testing:
xawtv -noalsa -c /dev/video1
- v4l2-ctl --all - works
- start kaffeine - fails with device busy and no disruption
- start vlc - fails with device busy and no disruption
- tvtime - tuner busy when it tries to do ioctls that change
  tuner settings with no disruption to kaffeine
- vlc - audio capture on WinTV HVR-950 - device is busy
- arecord to capture on WinTV HVR-950 - device busy

tvtime
- v4l2-ctl --all - works
- start kaffeine - fails with device busy and no disruption
- start vlc - fails with device busy and no disruption
- xawtv - tuner busy when it tries to do ioctls that change
  tuner settings with no disruption to kaffeine
- vlc - audio capture on WinTV HVR-950 - device is busy
- arecord to capture on WinTV HVR-950 - device busy

The following audio/video start/stop combination tests:
( used arecord as well to test these cases, arecord )

- tvtime start/vlc start/vlc stop/tvtime stop
  no disruption to tvtime
- tvtime start/vlc start/tvtie stop/vlc stop
  One tvtime stops, could trigger capture manually
- vlc start/tvtime start/tvtime stop/vlc stop
  vlc audio capture continues, tvtime detect tuner busy
- vlc start/tvtime start/vlc stop/tvtime start
  when vlc stops, tvtime could open the tuner dev

Re: [PATCH] DocBook: Reduce noise from make cleandocs

[Mauro Carvalho Chehab]

Em Tue, 21 Oct 2014 18:18:12 +0200
Takashi Iwai  escreveu:

> I've got a harmless warning when running make cleandocs on an already
> cleaned tree:
>   Documentation/DocBook/media/Makefile:28: recipe for target 'cleanmediadocs' 
> failed
>   make[1]: [cleanmediadocs] Error 1 (ignored)
> 
> Suppress this by passing -f to rm.
> 
> Signed-off-by: Takashi Iwai 

Assuming that this one would go via linux-doc tree:

Acked-by: Mauro Carvalho Chehab 

> ---
>  Documentation/DocBook/media/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/DocBook/media/Makefile 
> b/Documentation/DocBook/media/Makefile
> index df2962d9e11e..8bf7c6191296 100644
> --- a/Documentation/DocBook/media/Makefile
> +++ b/Documentation/DocBook/media/Makefile
> @@ -25,7 +25,7 @@ GENFILES := $(addprefix $(MEDIA_OBJ_DIR)/, $(MEDIA_TEMP))
>  PHONY += cleanmediadocs
>  
>  cleanmediadocs:
> - -@rm `find $(MEDIA_OBJ_DIR) -type l` $(GENFILES) $(OBJIMGFILES) 
> 2>/dev/null
> + -@rm -f `find $(MEDIA_OBJ_DIR) -type l` $(GENFILES) $(OBJIMGFILES) 
> 2>/dev/null
>  
>  $(obj)/media_api.xml: $(GENFILES) FORCE
>  
--
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] CODA960: Fails to allocate memory

[Jean-Michel Hautbois]

Hi Philipp,

2014-10-21 18:21 GMT+02:00 Philipp Zabel :
> Hi Jean-Michel,
>
> Am Dienstag, den 21.10.2014, 17:39 +0200 schrieb Jean-Michel Hautbois:
> [...]
>> And the output is now :
>> v4l2-ctl -d1 --stream-out-mmap --stream-mmap --stream-to x.raw
>> [ 6208.240919] coda 204.vpu: Not output type
>> [ 6208.245316] coda 204.vpu: streamon_out (N), streamon_cap (Y)
>> [ 6208.251353] coda 204.vpu: fill bitstream
>> [ 6208.255653] coda 204.vpu: fill bitstream payload : 0
>> VIDIOC_STREAMON: failed: Invalid argument
>>
>> Any idea ?
>> JM
>
> $ trace-cmd record -e v4l2* v4l2-ctl -d13 --stream-out-mmap --stream-mmap 
> --stream-to x.raw
> [...]
> $ trace-cmd report -R | grep bytesused
> [...]
> v4l2-ctl-308   [003]  1030.861067: v4l2_qbuf: minor=44 
> index=0 type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 
> timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 
> timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 
> timecode_userbits2=0 timecode_userbits3=0 sequence=0
> v4l2-ctl-308   [003]  1030.861292: v4l2_qbuf: minor=44 
> index=1 type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 
> timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 
> timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 
> timecode_userbits2=0 timecode_userbits3=0 sequence=0
> v4l2-ctl-308   [003]  1030.861471: v4l2_qbuf: minor=44 
> index=2 type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 
> timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 
> timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 
> timecode_userbits2=0 timecode_userbits3=0 sequence=0
> v4l2-ctl-308   [003]  1030.861638: v4l2_qbuf: minor=44 
> index=3 type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 
> timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 
> timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 
> timecode_userbits2=0 timecode_userbits3=0 sequence=0
> v4l2-ctl-308   [003]  1030.862301: v4l2_qbuf: minor=44 
> index=0 type=2 bytesused=3133440 flags=16387 field=1 timestamp=1030852944000 
> timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 
> timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 
> timecode_userbits2=0 timecode_userbits3=0 sequence=0
> v4l2-ctl-308   [003]  1030.862490: v4l2_qbuf: minor=44 
> index=1 type=2 bytesused=3133440 flags=16387 field=1 timestamp=1030853139000 
> timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 
> timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 
> timecode_userbits2=0 timecode_userbits3=0 sequence=0
> v4l2-ctl-308   [003]  1030.862672: v4l2_qbuf: minor=44 
> index=2 type=2 bytesused=3133440 flags=16387 field=1 timestamp=1030853322000 
> timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 
> timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 
> timecode_userbits2=0 timecode_userbits3=0 sequence=0
> v4l2-ctl-308   [003]  1030.862841: v4l2_qbuf: minor=44 
> index=3 type=2 bytesused=3133440 flags=16387 field=1 timestamp=1030853491000 
> timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 
> timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 
> timecode_userbits2=0 timecode_userbits3=0 sequence=0
>
> The decoder is fed ~ 3 MiB input buffers, which it tries (and fails) to
> copy into the 1 MiB bitstream ringbuffer (currently hard-coded via the
> badly named CODA_MAX_FRAME_SIZE constant), so the bitstream payload in
> the ringbuffer is 0 during start_streaming.

Mmmh, nice, didn't thought to get perf out of there :).
Well, I understand it can't feed the ringbuffer, but is there a way to
make the encoder work ?
I could of course modify CODA_MAX_FRAME_SIZE but this is clearly not
the good thing to do...

Thanks,
JM
--
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] coda: re-queue buffers if start_streaming fails

[Philipp Zabel]

Patch b906352c2338 ([media] coda: dequeue buffers if start_streaming fails)
incorrectly marked buffers as DEQUEUED in case of start_streaming failure, when
in fact they should be set to QUEUED. The videobuf2 core warns about this.

Reported-by: Jean-Michel Hautbois 
Signed-off-by: Philipp Zabel 
---
 drivers/media/platform/coda/coda-common.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/coda/coda-common.c 
b/drivers/media/platform/coda/coda-common.c
index ced4760..23ace447 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -1093,10 +1093,10 @@ static int coda_start_streaming(struct vb2_queue *q, 
unsigned int count)
 err:
if (q->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
while ((buf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx)))
-   v4l2_m2m_buf_done(buf, VB2_BUF_STATE_DEQUEUED);
+   v4l2_m2m_buf_done(buf, VB2_BUF_STATE_QUEUED);
} else {
while ((buf = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx)))
-   v4l2_m2m_buf_done(buf, VB2_BUF_STATE_DEQUEUED);
+   v4l2_m2m_buf_done(buf, VB2_BUF_STATE_QUEUED);
}
return ret;
 }
-- 
2.1.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: [media] CODA960: Fails to allocate memory

[Philipp Zabel]

Hi Jean-Michel,

Am Dienstag, den 21.10.2014, 17:39 +0200 schrieb Jean-Michel Hautbois:
[...]
> And the output is now :
> v4l2-ctl -d1 --stream-out-mmap --stream-mmap --stream-to x.raw
> [ 6208.240919] coda 204.vpu: Not output type
> [ 6208.245316] coda 204.vpu: streamon_out (N), streamon_cap (Y)
> [ 6208.251353] coda 204.vpu: fill bitstream
> [ 6208.255653] coda 204.vpu: fill bitstream payload : 0
> VIDIOC_STREAMON: failed: Invalid argument
> 
> Any idea ?
> JM

$ trace-cmd record -e v4l2* v4l2-ctl -d13 --stream-out-mmap --stream-mmap 
--stream-to x.raw
[...]
$ trace-cmd report -R | grep bytesused
[...]
v4l2-ctl-308   [003]  1030.861067: v4l2_qbuf: minor=44 index=0 
type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 
timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 
timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 
timecode_userbits3=0 sequence=0
v4l2-ctl-308   [003]  1030.861292: v4l2_qbuf: minor=44 index=1 
type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 
timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 
timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 
timecode_userbits3=0 sequence=0
v4l2-ctl-308   [003]  1030.861471: v4l2_qbuf: minor=44 index=2 
type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 
timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 
timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 
timecode_userbits3=0 sequence=0
v4l2-ctl-308   [003]  1030.861638: v4l2_qbuf: minor=44 index=3 
type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 
timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 
timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 
timecode_userbits3=0 sequence=0
v4l2-ctl-308   [003]  1030.862301: v4l2_qbuf: minor=44 index=0 
type=2 bytesused=3133440 flags=16387 field=1 timestamp=1030852944000 
timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 
timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 
timecode_userbits2=0 timecode_userbits3=0 sequence=0
v4l2-ctl-308   [003]  1030.862490: v4l2_qbuf: minor=44 index=1 
type=2 bytesused=3133440 flags=16387 field=1 timestamp=1030853139000 
timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 
timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 
timecode_userbits2=0 timecode_userbits3=0 sequence=0
v4l2-ctl-308   [003]  1030.862672: v4l2_qbuf: minor=44 index=2 
type=2 bytesused=3133440 flags=16387 field=1 timestamp=1030853322000 
timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 
timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 
timecode_userbits2=0 timecode_userbits3=0 sequence=0
v4l2-ctl-308   [003]  1030.862841: v4l2_qbuf: minor=44 index=3 
type=2 bytesused=3133440 flags=16387 field=1 timestamp=1030853491000 
timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 
timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 
timecode_userbits2=0 timecode_userbits3=0 sequence=0

The decoder is fed ~ 3 MiB input buffers, which it tries (and fails) to
copy into the 1 MiB bitstream ringbuffer (currently hard-coded via the
badly named CODA_MAX_FRAME_SIZE constant), so the bitstream payload in
the ringbuffer is 0 during start_streaming.

regards
Philipp

--
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] DocBook: Reduce noise from make cleandocs

[Takashi Iwai]

I've got a harmless warning when running make cleandocs on an already
cleaned tree:
  Documentation/DocBook/media/Makefile:28: recipe for target 'cleanmediadocs' 
failed
  make[1]: [cleanmediadocs] Error 1 (ignored)

Suppress this by passing -f to rm.

Signed-off-by: Takashi Iwai 
---
 Documentation/DocBook/media/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/DocBook/media/Makefile 
b/Documentation/DocBook/media/Makefile
index df2962d9e11e..8bf7c6191296 100644
--- a/Documentation/DocBook/media/Makefile
+++ b/Documentation/DocBook/media/Makefile
@@ -25,7 +25,7 @@ GENFILES := $(addprefix $(MEDIA_OBJ_DIR)/, $(MEDIA_TEMP))
 PHONY += cleanmediadocs
 
 cleanmediadocs:
-   -@rm `find $(MEDIA_OBJ_DIR) -type l` $(GENFILES) $(OBJIMGFILES) 
2>/dev/null
+   -@rm -f `find $(MEDIA_OBJ_DIR) -type l` $(GENFILES) $(OBJIMGFILES) 
2>/dev/null
 
 $(obj)/media_api.xml: $(GENFILES) FORCE
 
-- 
2.1.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: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api

[Takashi Iwai]

At Tue, 21 Oct 2014 12:08:59 -0400,
Devin Heitmueller wrote:
> 
> > Sorry, I'm not convinced by that.  If the device has to be controlled
> > exclusively, the right position is the open/close.  Otherwise, the
> > program cannot know when it becomes inaccessible out of sudden during
> > its operation.
> 
> I can say that I've definitely seen cases where if you configure a
> device as the "default" capture device in PulseAudio, then pulse will
> continue to capture from it even if you're not actively capturing the
> audio from pulse.  I only spotted this because I had a USB analyzer on
> the device and was dumbfounded when the ISOC packets kept arriving
> even after I had closed VLC.

You might have had an input monitor active in some PA apps?
PA shouldn't do it as default.  If it does unintentionally, you should
report it to PA guys.


Takashi
--
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: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api

[Devin Heitmueller]

> Sorry, I'm not convinced by that.  If the device has to be controlled
> exclusively, the right position is the open/close.  Otherwise, the
> program cannot know when it becomes inaccessible out of sudden during
> its operation.

I can say that I've definitely seen cases where if you configure a
device as the "default" capture device in PulseAudio, then pulse will
continue to capture from it even if you're not actively capturing the
audio from pulse.  I only spotted this because I had a USB analyzer on
the device and was dumbfounded when the ISOC packets kept arriving
even after I had closed VLC.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
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: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api

[Takashi Iwai]

At Tue, 21 Oct 2014 17:42:51 +0200,
Hans Verkuil wrote:
> 
> 
> 
> On 10/16/2014 04:48 PM, Takashi Iwai wrote:
> > At Thu, 16 Oct 2014 08:39:14 -0600,
> > Shuah Khan wrote:
> >>
> >> On 10/16/2014 08:16 AM, Takashi Iwai wrote:
> >>> At Thu, 16 Oct 2014 08:10:52 -0600,
> >>> Shuah Khan wrote:
> 
>  On 10/16/2014 08:01 AM, Takashi Iwai wrote:
> > At Thu, 16 Oct 2014 07:10:37 -0600,
> > Shuah Khan wrote:
> >>
> >> On 10/16/2014 06:00 AM, Lars-Peter Clausen wrote:
> >>> On 10/14/2014 04:58 PM, Shuah Khan wrote:
> >>> [...]
> switch (cmd) {
> case SNDRV_PCM_TRIGGER_START:
>  +err = media_get_audio_tkn(&subs->dev->dev);
>  +if (err == -EBUSY) {
>  +dev_info(&subs->dev->dev, "%s device is busy\n",
>  +__func__);
> >>>
> >>> In my opinion this should not dev_info() as this is out of band error
> >>> signaling and also as the potential to spam the log. The userspace
> >>> application is already properly notified by the return code.
> >>>
> >>
> >> Yes it has the potential to flood the dmesg especially with alsa,
> >> I will remove the dev_info().
> >
> > Yes.  And, I think doing this in the trigger isn't the best.
> > Why not in open & close?
> 
>  My first cut of this change was in open and close. I saw pulseaudio
>  application go into this loop trying to open the device. To avoid
>  such problems, I went with trigger stat and stop. That made all the
>  pulseaudio continues attempts to open problems go away.
> >>>
> >>> But now starting the stream gives the error, and PA would loop it
> >>> again, no?
> >>>
> >>>
> > Also, is this token restriction needed only for PCM?  No mixer or
> > other controls?
> 
>  snd_pcm_ops are the only ones media drivers implement and use. So
>  I don't think mixer is needed. If it is needed, it is not to hard
>  to add for that case.
> >>>
> >>> Well, then I wonder what resource does actually conflict with
> >>> usb-audio and media drivers at all...?
> >>>
> >>
> >> audio for dvb/v4l apps gets disrupted when audio app starts. For
> >> example, dvb or v4l app tuned to a channel, and when an audio app
> >> starts. audio path needs protected to avoid conflicts between
> >> digital and analog applications as well.
> >
> > OK, then concentrating on only PCM is fine.
> >
> > But, I'm still not convinced about doing the token management in the
> > trigger.  The reason -EBUSY doesn't work is that it's the very same
> > error code when a PCM device is blocked by other processes.  And
> > -EAGAIN is interpreted by PCM core to -EBUSY for historical reasons.
> >
> > How applications (e.g. PA) should behave if the token get fails?
> > Shouldn't it retry or totally give up?
> 
> Quite often media apps open the alsa device at the start and then switch
> between TV, radio or DVB mode. If the alsa device would claim the tuner
> just by being opened (as opposed to actually using the tuner, which happens
> when you start streaming),

What about parameter changes?  The sound devices have to be configured
before using.  Don't they influence on others at all, i.e. you can
change the PCM sample rate etc during TV, radio or DVB is running?

> then that would make it impossible for the
> application to switch tuner mode. In general you want to avoid that open()
> will start configuring hardware since that can quite often be slow. Tuner
> configuration in particular can be slow since several common tuners need
> to load firmware over i2c. You only want to do that when it is really needed,
> and not when some application (udev!) opens the device just to examine what
> sort of device it is.

But most apps close the device soon after that, no?
Which programs keep the PCM device (not the control) opened without
actually using?

> So claiming the tuner in the trigger seems to be the right place. If
> returning EBUSY is a poor error code for alsa, then we can use something else
> for that. EACCES perhaps?

Sorry, I'm not convinced by that.  If the device has to be controlled
exclusively, the right position is the open/close.  Otherwise, the
program cannot know when it becomes inaccessible out of sudden during
its operation.


Takashi
--
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: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api

[Hans Verkuil]

On 10/16/2014 04:48 PM, Takashi Iwai wrote:

At Thu, 16 Oct 2014 08:39:14 -0600,
Shuah Khan wrote:


On 10/16/2014 08:16 AM, Takashi Iwai wrote:

At Thu, 16 Oct 2014 08:10:52 -0600,
Shuah Khan wrote:


On 10/16/2014 08:01 AM, Takashi Iwai wrote:

At Thu, 16 Oct 2014 07:10:37 -0600,
Shuah Khan wrote:


On 10/16/2014 06:00 AM, Lars-Peter Clausen wrote:

On 10/14/2014 04:58 PM, Shuah Khan wrote:
[...]

   switch (cmd) {
   case SNDRV_PCM_TRIGGER_START:
+err = media_get_audio_tkn(&subs->dev->dev);
+if (err == -EBUSY) {
+dev_info(&subs->dev->dev, "%s device is busy\n",
+__func__);


In my opinion this should not dev_info() as this is out of band error
signaling and also as the potential to spam the log. The userspace
application is already properly notified by the return code.



Yes it has the potential to flood the dmesg especially with alsa,
I will remove the dev_info().


Yes.  And, I think doing this in the trigger isn't the best.
Why not in open & close?


My first cut of this change was in open and close. I saw pulseaudio
application go into this loop trying to open the device. To avoid
such problems, I went with trigger stat and stop. That made all the
pulseaudio continues attempts to open problems go away.


But now starting the stream gives the error, and PA would loop it
again, no?



Also, is this token restriction needed only for PCM?  No mixer or
other controls?


snd_pcm_ops are the only ones media drivers implement and use. So
I don't think mixer is needed. If it is needed, it is not to hard
to add for that case.


Well, then I wonder what resource does actually conflict with
usb-audio and media drivers at all...?



audio for dvb/v4l apps gets disrupted when audio app starts. For
example, dvb or v4l app tuned to a channel, and when an audio app
starts. audio path needs protected to avoid conflicts between
digital and analog applications as well.


OK, then concentrating on only PCM is fine.

But, I'm still not convinced about doing the token management in the
trigger.  The reason -EBUSY doesn't work is that it's the very same
error code when a PCM device is blocked by other processes.  And
-EAGAIN is interpreted by PCM core to -EBUSY for historical reasons.

How applications (e.g. PA) should behave if the token get fails?
Shouldn't it retry or totally give up?


Quite often media apps open the alsa device at the start and then switch
between TV, radio or DVB mode. If the alsa device would claim the tuner
just by being opened (as opposed to actually using the tuner, which happens
when you start streaming), then that would make it impossible for the
application to switch tuner mode. In general you want to avoid that open()
will start configuring hardware since that can quite often be slow. Tuner
configuration in particular can be slow since several common tuners need
to load firmware over i2c. You only want to do that when it is really needed,
and not when some application (udev!) opens the device just to examine what
sort of device it is.

So claiming the tuner in the trigger seems to be the right place. If
returning EBUSY is a poor error code for alsa, then we can use something else
for that. EACCES perhaps?

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: [media] CODA960: Fails to allocate memory

[Jean-Michel Hautbois]

2014-10-21 15:49 GMT+02:00 Hans Verkuil :
>
>
> On 10/21/2014 03:42 PM, Jean-Michel Hautbois wrote:
>>
>> Hi Hans,
>>
>> 2014-10-21 15:27 GMT+02:00 Hans Verkuil :
>>>
>>>
>>>
>>> On 10/21/2014 03:16 PM, Jean-Michel Hautbois wrote:


 Hi,

 I am trying to use the CODA960 driver on a 3.18 kernel.
 It seems pretty good when the module is probed (appart from the
 unsupported firmware version) but when I try using the encoder, it
 fails allocating dma buffers.

 Here is the DT part I added :
 &vpu {
   compatible = "fsl,imx6q-vpu";
   clocks = <&clks 168>, <&clks 140>, <&clks 142>;
   clock-names = "per", "ahb", "ocram";
   iramsize = <0x21000>;
   iram = <&ocram>;
   resets = <&src 1>;
   status = "okay";
 };

 When booting, I see :
 [4.410645] coda 204.vpu: Firmware code revision: 46056
 [4.416312] coda 204.vpu: Initialized CODA960.
 [4.421123] coda 204.vpu: Unsupported firmware version: 3.1.1
 [4.483577] coda 204.vpu: codec registered as /dev/video[0-1]

 I can start v4l2-ctl and it shows that the device seems to be ok :
v4l2-ctl --all -d /dev/video1
 Driver Info (not using libv4l2):
   Driver name   : coda
   Card type : CODA960
   Bus info  : platform:coda
   Driver version: 3.18.0
   Capabilities  : 0x84208000
   Video Memory-to-Memory
   Streaming
   Extended Pix Format
   Device Capabilities
   Device Caps   : 0x04208000
   Video Memory-to-Memory
   Streaming
   Extended Pix Format
 Priority: 2
 Format Video Capture:
   Width/Height  : 1920/1088
   Pixel Format  : 'YU12'
   Field : None
   Bytes per Line: 1920
   Size Image: 3133440
   Colorspace: HDTV and modern devices (ITU709)
   Flags :
 Format Video Output:
   Width/Height  : 1920/1088
   Pixel Format  : 'H264'
   Field : None
   Bytes per Line: 0
   Size Image: 1048576
   Colorspace: HDTV and modern devices (ITU709)
   Flags :
 Selection: compose, Left 0, Top 0, Width 1920, Height 1088
 Selection: compose_default, Left 0, Top 0, Width 1920, Height 1088
 Selection: compose_bounds, Left 0, Top 0, Width 1920, Height 1088
 Selection: compose_padded, Left 0, Top 0, Width 1920, Height 1088
 Selection: crop, Left 0, Top 0, Width 1920, Height 1088
 Selection: crop_default, Left 0, Top 0, Width 1920, Height 1088
 Selection: crop_bounds, Left 0, Top 0, Width 1920, Height 1088

 User Controls

   horizontal_flip (bool)   : default=0 value=0
 vertical_flip (bool)   : default=0 value=0

 Codec Controls

video_gop_size (int): min=1 max=60 step=1
 default=16 value=16
 video_bitrate (int): min=0 max=32767000 step=1
 default=0 value=0
   number_of_intra_refresh_mbs (int): min=0 max=8160 step=1
 default=0 value=0
  sequence_header_mode (menu)   : min=0 max=1 default=1
 value=1
  maximum_bytes_in_a_slice (int): min=1 max=1073741823 step=1
 default=500 value=500
  number_of_mbs_in_a_slice (int): min=1 max=1073741823 step=1
 default=1 value=1
 slice_partitioning_method (menu)   : min=0 max=2 default=0
 value=0
 h264_i_frame_qp_value (int): min=0 max=51 step=1
 default=25 value=25
 h264_p_frame_qp_value (int): min=0 max=51 step=1
 default=25 value=25
 h264_maximum_qp_value (int): min=0 max=51 step=1
 default=51 value=51
 h264_loop_filter_alpha_offset (int): min=0 max=15 step=1
 default=0
 value=0
  h264_loop_filter_beta_offset (int): min=0 max=15 step=1
 default=0
 value=0
 h264_loop_filter_mode (menu)   : min=0 max=1 default=0
 value=0
mpeg4_i_frame_qp_value (int): min=1 max=31 step=1
 default=2
 value=2
mpeg4_p_frame_qp_value (int): min=1 max=31 step=1
 default=2
 value=2
   horizontal_flip (bool)   : default=0 value=0
 vertical_flip (bool)   : default=0 value=0




 But when I try to get a file outputed, it fails :

 v4l2-ctl -d1 --stream-out-mmap --stream-mmap --stream-to x.raw
 [ 1197.292256] coda 204.vpu: dma_alloc_coherent of size 1048576
 failed
 VIDIOC_REQBUFS: failed: Cannot allocate memory

 Did I forget to do someth

Re: [media-workshop] [ANNOUNCE] Media summit Report - October, 17-18 2014 - Düsseldorf

[Hans Verkuil]

On 10/21/2014 05:26 PM, Mauro Carvalho Chehab wrote:

Em Tue, 21 Oct 2014 12:53:16 -0200
Mauro Carvalho Chehab  escreveu:


This report is also available in html at:
http://linuxtv.org/news.php?entry=2014-10-21.mchehab

In the name of the organizing committee, I'd like to thank you all for
being there with us during those two days.

There were several good discussions that happened during the meeting,
aimed to improve even more the Linux media subsystem.

Also, it was agreed during the meeting that we'll try to reach an even
broader audience on the next events. So we're counting with all you
on our next year's event(s).

Thanks!
Mauro

-

Attendees, in alphabetical order:

NAME- EMAIL - ORGANIZATION
Brad Love   - bl...@hauppauge.com   - Hauppauge
Chris Kohn  - christian.k...@xilinx.com - Xilinx
Friedrich Schwittay - fschwit...@pctvsystems.com- PCTV
Guennaddi Liakhovetski  - g.liakhovet...@gmx.de - Intel
Hans de Goede   - hdego...@redhat.com   - Red hat
Hans Verkuil- hverk...@xs4all.nl- Cisco
Henning Garbers - hgarb...@pctvsystems.com  - PCTV
Johannes Stezenbach - j...@linuxtv.org  - LinuxTV
Julien Beraud   - julien.ber...@parrot.com  - Parrot 
(www.parrot.com)
Kamil Debski- k.deb...@samsung.com  - Samsung
Laurent Pinchart- laurent.pinch...@ideasonboard.com - Ideas on board
Lucas Stach - l.st...@pengutronix.de- Pengutronix
Mauro Carvalho Chehab   - mche...@osg.samsung.com   - Samsung
Mike Krufky - mkru...@linuxtv.org   - Samsung
Nicolas Dufresne- nicolas.dufre...@collabora.com- Collabora
Pawel Osciak- pa...@osciak.com  - Google
Peter Griffin   - peter.grif...@linaro.org  - Linaro/ST
Philipp Zabel   - p.za...@pengutronix.de- Pengutronix
Ralph Metzler   - r...@metzlerbros.de   - Meltzler 
Brothers
Ricardo Ribalda Delgado - rica...@qtec.com  - Qtechnolgy A/S
Sakari Ailus- sakari.ai...@linux.intel.com  - Intel

Thursday:


1) Configuration stores - Hans Verkuil
===

- Need to report which settings/controls were applied

- Drivers needs to be able to report full/limited Android CameraHAL v3 support
(full means full synchronization support)

- We probably need a mechanism to be able to remove (free) config stores

- Can we use APPLY(0) instead of CLOSE?

- Per buffer or per frame configuration? Note: there is no notion of frame IDs
yet in V4L2.

- Would be nice to be able to disable APPLY, perhaps a flag for the core similar
to HAS STORE

2) Android camera HAL v3 - Sakari Ailus


http://www.retiisi.org.uk/v4l2/foil/android-camera-hal-v3-v4l2.pdf
- Capture requests queued lead to returned buffers in order, best effort to make
per-buffer configuration apply correctly needed

- Capture requests/returned buffers do not map directly to QBUF/DQBUF because
multiple buffers in different formats may be produced from a single request.
Some outputs could be implemented in software, e.g. multiple YUV outputs when
hardware simply does not contain as many.

- Should statistical data be returned in a separate video buffer queue? Might be
associated via sequence number, probably separate frame ID better

- 3A library input: frame metadata, depends on sensor, might be in-frame or
out-of band. If possible, separate buffer queue prepared to get to it early.

- HAL v3 needs Start Of Frame and End Of Frame events

- If there is no hardware mechanism for synchronization, apply sensor settings
as soon as possible after SOF and hope for the best. It is possible to verify
the timing has been successful in the user space.

- Sensor settings and ISP settings applied at different points in time, as
sensor settings usally take effect on the following frame

- Sensors may implement all or parts of the ISP themselves. It may not be
feasible to implement hal v3 full profile for such sensors.

- Start of Exposure events not to be implemented in the kernel. HAL must
calculate the event time based on other available information, such as end of
frame (or start of frame event) and other frame timing parameters.

- Some metadata tags could be mapped to V4L2 (compound) controls, they are
associated with a single capture request. Some metadata tags (statistics) are
produced from video buffer queues. Other metadata tags originate from HAL.

- Needs a guarantee that a single capture request will produce all buffers
requested by it with the request's parameters, needs per-buffer configuration,
associating buffers with a certain frame.

- A working halv

Re: [media-workshop] [ANNOUNCE] Media summit Report - October, 17-18 2014 - Düsseldorf

[Mauro Carvalho Chehab]

Em Tue, 21 Oct 2014 12:53:16 -0200
Mauro Carvalho Chehab  escreveu:

> This report is also available in html at: 
>   http://linuxtv.org/news.php?entry=2014-10-21.mchehab
> 
> In the name of the organizing committee, I'd like to thank you all for
> being there with us during those two days.
> 
> There were several good discussions that happened during the meeting,
> aimed to improve even more the Linux media subsystem.
> 
> Also, it was agreed during the meeting that we'll try to reach an even
> broader audience on the next events. So we're counting with all you
> on our next year's event(s).
> 
> Thanks!
> Mauro
> 
> -
> 
> Attendees, in alphabetical order:
> 
> NAME  - EMAIL - ORGANIZATION
> Brad Love - bl...@hauppauge.com   - Hauppauge
> Chris Kohn- christian.k...@xilinx.com - Xilinx
> Friedrich Schwittay   - fschwit...@pctvsystems.com- PCTV
> Guennaddi Liakhovetski- g.liakhovet...@gmx.de - Intel
> Hans de Goede - hdego...@redhat.com   - Red hat
> Hans Verkuil  - hverk...@xs4all.nl- Cisco
> Henning Garbers   - hgarb...@pctvsystems.com  - PCTV
> Johannes Stezenbach   - j...@linuxtv.org  - LinuxTV
> Julien Beraud - julien.ber...@parrot.com  - Parrot 
> (www.parrot.com)
> Kamil Debski  - k.deb...@samsung.com  - Samsung
> Laurent Pinchart  - laurent.pinch...@ideasonboard.com - Ideas on board
> Lucas Stach   - l.st...@pengutronix.de- Pengutronix
> Mauro Carvalho Chehab - mche...@osg.samsung.com   - Samsung
> Mike Krufky   - mkru...@linuxtv.org   - Samsung
> Nicolas Dufresne  - nicolas.dufre...@collabora.com- Collabora
> Pawel Osciak  - pa...@osciak.com  - Google
> Peter Griffin - peter.grif...@linaro.org  - Linaro/ST
> Philipp Zabel - p.za...@pengutronix.de- Pengutronix
> Ralph Metzler - r...@metzlerbros.de   - Meltzler 
> Brothers
> Ricardo Ribalda Delgado   - rica...@qtec.com  - 
> Qtechnolgy A/S
> Sakari Ailus  - sakari.ai...@linux.intel.com  - Intel
> 
> Thursday:
> 
> 
> 1) Configuration stores - Hans Verkuil
>===
> 
> - Need to report which settings/controls were applied
> 
> - Drivers needs to be able to report full/limited Android CameraHAL v3 support
> (full means full synchronization support)
> 
> - We probably need a mechanism to be able to remove (free) config stores
> 
> - Can we use APPLY(0) instead of CLOSE?
> 
> - Per buffer or per frame configuration? Note: there is no notion of frame IDs
> yet in V4L2.
> 
> - Would be nice to be able to disable APPLY, perhaps a flag for the core 
> similar
> to HAS STORE
> 
> 2) Android camera HAL v3 - Sakari Ailus
>
> 
> http://www.retiisi.org.uk/v4l2/foil/android-camera-hal-v3-v4l2.pdf
> - Capture requests queued lead to returned buffers in order, best effort to 
> make
> per-buffer configuration apply correctly needed
> 
> - Capture requests/returned buffers do not map directly to QBUF/DQBUF because
> multiple buffers in different formats may be produced from a single request.
> Some outputs could be implemented in software, e.g. multiple YUV outputs when
> hardware simply does not contain as many.
> 
> - Should statistical data be returned in a separate video buffer queue? Might 
> be
> associated via sequence number, probably separate frame ID better
> 
> - 3A library input: frame metadata, depends on sensor, might be in-frame or
> out-of band. If possible, separate buffer queue prepared to get to it early.
> 
> - HAL v3 needs Start Of Frame and End Of Frame events
> 
> - If there is no hardware mechanism for synchronization, apply sensor settings
> as soon as possible after SOF and hope for the best. It is possible to verify
> the timing has been successful in the user space.
> 
> - Sensor settings and ISP settings applied at different points in time, as
> sensor settings usally take effect on the following frame
> 
> - Sensors may implement all or parts of the ISP themselves. It may not be
> feasible to implement hal v3 full profile for such sensors.
> 
> - Start of Exposure events not to be implemented in the kernel. HAL must
> calculate the event time based on other available information, such as end of
> frame (or start of frame event) and other frame timing parameters.
> 
> - Some metadata tags could be mapped to V4L2 (compound) controls, they are
> associated with a single capture request. Some metadata tags (statistics) are
> produced from video buffer queues. Other metadata tags originate from HAL.
> 
> - Needs a guarantee that a single capture request will produce all buffe

[RFCv2 1/8] [media] si4713: switch to devm regulator API

[Sebastian Reichel]

This switches back to the normal regulator API (but use
managed variant) in preparation for device tree support.

Signed-off-by: Sebastian Reichel 
---
 drivers/media/radio/si4713/si4713.c | 80 ++---
 drivers/media/radio/si4713/si4713.h |  6 +--
 2 files changed, 58 insertions(+), 28 deletions(-)

diff --git a/drivers/media/radio/si4713/si4713.c 
b/drivers/media/radio/si4713/si4713.c
index b576555..b335093 100644
--- a/drivers/media/radio/si4713/si4713.c
+++ b/drivers/media/radio/si4713/si4713.c
@@ -23,6 +23,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -366,13 +367,22 @@ static int si4713_powerup(struct si4713_device *sdev)
if (sdev->power_state)
return 0;
 
-   if (sdev->supplies) {
-   err = regulator_bulk_enable(sdev->supplies, sdev->supply_data);
+   if (sdev->vdd) {
+   err = regulator_enable(sdev->vdd);
if (err) {
-   v4l2_err(&sdev->sd, "Failed to enable supplies: %d\n", 
err);
+   v4l2_err(&sdev->sd, "Failed to enable vdd: %d\n", err);
return err;
}
}
+
+   if (sdev->vio) {
+   err = regulator_enable(sdev->vio);
+   if (err) {
+   v4l2_err(&sdev->sd, "Failed to enable vio: %d\n", err);
+   return err;
+   }
+   }
+
if (gpio_is_valid(sdev->gpio_reset)) {
udelay(50);
gpio_set_value(sdev->gpio_reset, 1);
@@ -399,11 +409,18 @@ static int si4713_powerup(struct si4713_device *sdev)
}
if (gpio_is_valid(sdev->gpio_reset))
gpio_set_value(sdev->gpio_reset, 0);
-   if (sdev->supplies) {
-   err = regulator_bulk_disable(sdev->supplies, sdev->supply_data);
+
+
+   if (sdev->vdd) {
+   err = regulator_disable(sdev->vdd);
if (err)
-   v4l2_err(&sdev->sd,
-"Failed to disable supplies: %d\n", err);
+   v4l2_err(&sdev->sd, "Failed to disable vdd: %d\n", err);
+   }
+
+   if (sdev->vio) {
+   err = regulator_disable(sdev->vio);
+   if (err)
+   v4l2_err(&sdev->sd, "Failed to disable vio: %d\n", err);
}
 
return err;
@@ -432,12 +449,21 @@ static int si4713_powerdown(struct si4713_device *sdev)
v4l2_dbg(1, debug, &sdev->sd, "Device in reset mode\n");
if (gpio_is_valid(sdev->gpio_reset))
gpio_set_value(sdev->gpio_reset, 0);
-   if (sdev->supplies) {
-   err = regulator_bulk_disable(sdev->supplies,
-sdev->supply_data);
-   if (err)
+
+   if (sdev->vdd) {
+   err = regulator_disable(sdev->vdd);
+   if (err) {
+   v4l2_err(&sdev->sd,
+   "Failed to disable vdd: %d\n", err);
+   }
+   }
+
+   if (sdev->vio) {
+   err = regulator_disable(sdev->vio);
+   if (err) {
v4l2_err(&sdev->sd,
-"Failed to disable supplies: %d\n", 
err);
+   "Failed to disable vio: %d\n", err);
+   }
}
sdev->power_state = POWER_OFF;
}
@@ -1441,17 +1467,26 @@ static int si4713_probe(struct i2c_client *client,
}
sdev->gpio_reset = pdata->gpio_reset;
gpio_direction_output(sdev->gpio_reset, 0);
-   sdev->supplies = pdata->supplies;
}
 
-   for (i = 0; i < sdev->supplies; i++)
-   sdev->supply_data[i].supply = pdata->supply_names[i];
+   sdev->vdd = devm_regulator_get_optional(&client->dev, "vdd");
+   if (IS_ERR(sdev->vdd)) {
+   rval = PTR_ERR(sdev->vdd);
+   if (rval == -EPROBE_DEFER)
+   goto exit;
+
+   dev_dbg(&client->dev, "no vdd regulator found: %d\n", rval);
+   sdev->vdd = NULL;
+   }
+
+   sdev->vio = devm_regulator_get_optional(&client->dev, "vio");
+   if (IS_ERR(sdev->vio)) {
+   rval = PTR_ERR(sdev->vio);
+   if (rval == -EPROBE_DEFER)
+   goto exit;
 
-   rval = regulator_bulk_get(&client->dev, sdev->supplies,
- sdev->supply_data);
-   if (rval) {
-   dev_err(&client->dev, "Cannot get regulators: %d\n", rval);
-   goto free_gpio;
+   dev_dbg(&client->dev, "no vio regulator found: %d\n", rval);
+   sdev->vio = NULL;
}
 
v4l2_i2c_subdev_init(&sdev->sd, cl

[RFCv2 0/8] [media] si4713 DT binding

[Sebastian Reichel]

Hi,

This is the RFCv2 patchset adding DT support to the si4713
radio transmitter i2c driver. The changes can be summarized
as follows:

 * Move regulator information back into the driver. The
   regulators needed are documented in the chip and have
   nothing to do with boarddata. Instead devm_regulator_get_optional
   is used and errors are handled quite loosely now. Maybe the USB
   driver should provide dummy regulators.
 * GPIO handling is updated to gpiod consumer interface, resulting
   in a driver cleanup and easy DT handling
 * The driver is updated to use managed resources wherever possible

So much about the nice stuff. But there is also

 * Instantiation of the platform device from the i2c (sub-)device. Since DT
   is not supposed to contain linuxisms the device is a simple i2c node
   resulting in the i2c probe function being called. Thus registering the main
   v4l device must happen from there.

Tested:
 * Compilation on torvalds/linux.git:master (based on 52d589a)
 * Booting in DT mode
 * Some simply driver queries using v4l2-ctl

Not tested:
 * The USB driver, since I do not own the USB dongle
 * The legacy platform code (only DT boot has been tested).
   (The legacy platform code is supposed to removed in the near future anyways)

Changes since RFCv1 (requested by Hans Verkuil):
 - splitted the patchset into more patches
 - replaced dev_info with dev_dbg for missing regulators
 - check for ENOSYS value from devm_gpiod_get (disabled GPIOLIB)

-- Sebastian

Sebastian Reichel (8):
  [media] si4713: switch to devm regulator API
  [media] si4713: switch reset gpio to devm_gpiod API
  [media] si4713: use managed memory allocation
  [media] si4713: use managed irq request
  [media] si4713: add device tree support
  [media] si4713: add DT binding documentation
  ARM: OMAP2: RX-51: update si4713 platform data
  [media] si4713: cleanup platform data

 Documentation/devicetree/bindings/media/si4713.txt |  30 
 arch/arm/mach-omap2/board-rx51-peripherals.c   |  69 -
 drivers/media/radio/si4713/radio-platform-si4713.c |  28 +---
 drivers/media/radio/si4713/si4713.c| 167 +
 drivers/media/radio/si4713/si4713.h|  15 +-
 include/media/radio-si4713.h   |  30 
 include/media/si4713.h |   4 +-
 7 files changed, 186 insertions(+), 157 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/si4713.txt
 delete mode 100644 include/media/radio-si4713.h

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

[RFCv2 3/8] [media] si4713: use managed memory allocation

[Sebastian Reichel]

Introduce the usage of managed memory allocation to
simplify the code slightly.

Signed-off-by: Sebastian Reichel 
---
 drivers/media/radio/si4713/si4713.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/media/radio/si4713/si4713.c 
b/drivers/media/radio/si4713/si4713.c
index e560a7e..efc5d6b 100644
--- a/drivers/media/radio/si4713/si4713.c
+++ b/drivers/media/radio/si4713/si4713.c
@@ -1450,7 +1450,7 @@ static int si4713_probe(struct i2c_client *client,
struct v4l2_ctrl_handler *hdl;
int rval, i;
 
-   sdev = kzalloc(sizeof(*sdev), GFP_KERNEL);
+   sdev = devm_kzalloc(&client->dev, sizeof(*sdev), GFP_KERNEL);
if (!sdev) {
dev_err(&client->dev, "Failed to alloc video device.\n");
rval = -ENOMEM;
@@ -1467,7 +1467,7 @@ static int si4713_probe(struct i2c_client *client,
} else {
rval = PTR_ERR(sdev->gpio_reset);
dev_err(&client->dev, "Failed to request gpio: %d\n", rval);
-   goto free_sdev;
+   goto exit;
}
 
sdev->vdd = devm_regulator_get_optional(&client->dev, "vdd");
@@ -1615,8 +1615,6 @@ free_irq:
free_irq(client->irq, sdev);
 free_ctrls:
v4l2_ctrl_handler_free(hdl);
-free_sdev:
-   kfree(sdev);
 exit:
return rval;
 }
@@ -1635,7 +1633,6 @@ static int si4713_remove(struct i2c_client *client)
 
v4l2_device_unregister_subdev(sd);
v4l2_ctrl_handler_free(sd->ctrl_handler);
-   kfree(sdev);
 
return 0;
 }
-- 
2.1.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

[RFCv2 5/8] [media] si4713: add device tree support

[Sebastian Reichel]

Add device tree support by changing the device registration order.
In the device tree the si4713 node is a normal I2C device, which
will be probed as such. Thus the V4L device must be probed from
the I2C device and not the other way around.

Signed-off-by: Sebastian Reichel 
---
 drivers/media/radio/si4713/radio-platform-si4713.c | 28 --
 drivers/media/radio/si4713/si4713.c| 34 --
 drivers/media/radio/si4713/si4713.h|  6 
 include/media/radio-si4713.h   | 30 ---
 include/media/si4713.h |  1 +
 5 files changed, 45 insertions(+), 54 deletions(-)
 delete mode 100644 include/media/radio-si4713.h

diff --git a/drivers/media/radio/si4713/radio-platform-si4713.c 
b/drivers/media/radio/si4713/radio-platform-si4713.c
index a47502a..2de5439 100644
--- a/drivers/media/radio/si4713/radio-platform-si4713.c
+++ b/drivers/media/radio/si4713/radio-platform-si4713.c
@@ -34,7 +34,7 @@
 #include 
 #include 
 #include 
-#include 
+#include "si4713.h"
 
 /* module parameters */
 static int radio_nr = -1;  /* radio device minor (-1 ==> auto assign) */
@@ -153,7 +153,6 @@ static int radio_si4713_pdriver_probe(struct 
platform_device *pdev)
 {
struct radio_si4713_platform_data *pdata = pdev->dev.platform_data;
struct radio_si4713_device *rsdev;
-   struct i2c_adapter *adapter;
struct v4l2_subdev *sd;
int rval = 0;
 
@@ -177,20 +176,11 @@ static int radio_si4713_pdriver_probe(struct 
platform_device *pdev)
goto exit;
}
 
-   adapter = i2c_get_adapter(pdata->i2c_bus);
-   if (!adapter) {
-   dev_err(&pdev->dev, "Cannot get i2c adapter %d\n",
-   pdata->i2c_bus);
-   rval = -ENODEV;
-   goto unregister_v4l2_dev;
-   }
-
-   sd = v4l2_i2c_new_subdev_board(&rsdev->v4l2_dev, adapter,
-  pdata->subdev_board_info, NULL);
-   if (!sd) {
+   sd = i2c_get_clientdata(pdata->subdev);
+   rval = v4l2_device_register_subdev(&rsdev->v4l2_dev, sd);
+   if (rval) {
dev_err(&pdev->dev, "Cannot get v4l2 subdevice\n");
-   rval = -ENODEV;
-   goto put_adapter;
+   goto unregister_v4l2_dev;
}
 
rsdev->radio_dev = radio_si4713_vdev_template;
@@ -202,14 +192,12 @@ static int radio_si4713_pdriver_probe(struct 
platform_device *pdev)
if (video_register_device(&rsdev->radio_dev, VFL_TYPE_RADIO, radio_nr)) 
{
dev_err(&pdev->dev, "Could not register video device.\n");
rval = -EIO;
-   goto put_adapter;
+   goto unregister_v4l2_dev;
}
dev_info(&pdev->dev, "New device successfully probed\n");
 
goto exit;
 
-put_adapter:
-   i2c_put_adapter(adapter);
 unregister_v4l2_dev:
v4l2_device_unregister(&rsdev->v4l2_dev);
 exit:
@@ -220,14 +208,10 @@ exit:
 static int radio_si4713_pdriver_remove(struct platform_device *pdev)
 {
struct v4l2_device *v4l2_dev = platform_get_drvdata(pdev);
-   struct v4l2_subdev *sd = list_entry(v4l2_dev->subdevs.next,
-   struct v4l2_subdev, list);
-   struct i2c_client *client = v4l2_get_subdevdata(sd);
struct radio_si4713_device *rsdev;
 
rsdev = container_of(v4l2_dev, struct radio_si4713_device, v4l2_dev);
video_unregister_device(&rsdev->radio_dev);
-   i2c_put_adapter(client->adapter);
v4l2_device_unregister(&rsdev->v4l2_dev);
 
return 0;
diff --git a/drivers/media/radio/si4713/si4713.c 
b/drivers/media/radio/si4713/si4713.c
index ebec16d..94fe3c6 100644
--- a/drivers/media/radio/si4713/si4713.c
+++ b/drivers/media/radio/si4713/si4713.c
@@ -1446,9 +1446,13 @@ static int si4713_probe(struct i2c_client *client,
const struct i2c_device_id *id)
 {
struct si4713_device *sdev;
-   struct si4713_platform_data *pdata = client->dev.platform_data;
struct v4l2_ctrl_handler *hdl;
-   int rval, i;
+   struct si4713_platform_data *pdata = client->dev.platform_data;
+   struct device_node *np = client->dev.of_node;
+   int rval;
+
+   struct radio_si4713_platform_data si4713_pdev_pdata;
+   struct platform_device *si4713_pdev;
 
sdev = devm_kzalloc(&client->dev, sizeof(*sdev), GFP_KERNEL);
if (!sdev) {
@@ -1608,8 +1612,31 @@ static int si4713_probe(struct i2c_client *client,
goto free_ctrls;
}
 
+   if ((pdata && pdata->is_platform_device) || np) {
+   si4713_pdev = platform_device_alloc("radio-si4713", -1);
+   if (!si4713_pdev)
+   goto put_main_pdev;
+
+   si4713_pdev_pdata.subdev = client;
+   rval = platform_device_add_data(si4713_pdev, &si4713_pdev_pdata,
+  

[RFCv2 7/8] ARM: OMAP2: RX-51: update si4713 platform data

[Sebastian Reichel]

This updates platform data related to Si4713, which
has been updated to be compatible with DT interface.

Signed-off-by: Sebastian Reichel 
---
 arch/arm/mach-omap2/board-rx51-peripherals.c | 69 +---
 1 file changed, 31 insertions(+), 38 deletions(-)

diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c 
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index ddfc8df..ec2e410 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -38,7 +39,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -760,46 +760,17 @@ static struct regulator_init_data rx51_vintdig = {
},
 };
 
-static const char * const si4713_supply_names[] = {
-   "vio",
-   "vdd",
-};
-
-static struct si4713_platform_data rx51_si4713_i2c_data __initdata_or_module = 
{
-   .supplies   = ARRAY_SIZE(si4713_supply_names),
-   .supply_names   = si4713_supply_names,
-   .gpio_reset = RX51_FMTX_RESET_GPIO,
-};
-
-static struct i2c_board_info rx51_si4713_board_info __initdata_or_module = {
-   I2C_BOARD_INFO("si4713", SI4713_I2C_ADDR_BUSEN_HIGH),
-   .platform_data  = &rx51_si4713_i2c_data,
-};
-
-static struct radio_si4713_platform_data rx51_si4713_data __initdata_or_module 
= {
-   .i2c_bus= 2,
-   .subdev_board_info = &rx51_si4713_board_info,
-};
-
-static struct platform_device rx51_si4713_dev __initdata_or_module = {
-   .name   = "radio-si4713",
-   .id = -1,
-   .dev= {
-   .platform_data  = &rx51_si4713_data,
+static struct gpiod_lookup_table rx51_fmtx_gpios_table = {
+   .dev_id = "2-0063",
+   .table = {
+   GPIO_LOOKUP("gpio.6", 3, "reset", GPIO_ACTIVE_HIGH), /* 163 */
+   { },
},
 };
 
-static __init void rx51_init_si4713(void)
+static __init void rx51_gpio_init(void)
 {
-   int err;
-
-   err = gpio_request_one(RX51_FMTX_IRQ, GPIOF_DIR_IN, "si4713 irq");
-   if (err) {
-   printk(KERN_ERR "Cannot request si4713 irq gpio. %d\n", err);
-   return;
-   }
-   rx51_si4713_board_info.irq = gpio_to_irq(RX51_FMTX_IRQ);
-   platform_device_register(&rx51_si4713_dev);
+   gpiod_add_lookup_table(&rx51_fmtx_gpios_table);
 }
 
 static int rx51_twlgpio_setup(struct device *dev, unsigned gpio, unsigned n)
@@ -1029,7 +1000,17 @@ static struct aic3x_pdata rx51_aic3x_data2 = {
.gpio_reset = 60,
 };
 
+static struct si4713_platform_data rx51_si4713_platform_data = {
+   .is_platform_device = true
+};
+
 static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_2[] = {
+#if IS_ENABLED(CONFIG_I2C_SI4713) && IS_ENABLED(CONFIG_PLATFORM_SI4713)
+   {
+   I2C_BOARD_INFO("si4713", 0x63),
+   .platform_data = &rx51_si4713_platform_data,
+   },
+#endif
{
I2C_BOARD_INFO("tlv320aic3x", 0x18),
.platform_data = &rx51_aic3x_data,
@@ -1070,6 +1051,10 @@ static struct i2c_board_info __initdata 
rx51_peripherals_i2c_board_info_3[] = {
 
 static int __init rx51_i2c_init(void)
 {
+#if IS_ENABLED(CONFIG_I2C_SI4713) && IS_ENABLED(CONFIG_PLATFORM_SI4713)
+   int err;
+#endif
+
if ((system_rev >= SYSTEM_REV_S_USES_VAUX3 && system_rev < 0x100) ||
system_rev >= SYSTEM_REV_B_USES_VAUX3) {
rx51_twldata.vaux3 = &rx51_vaux3_mmc;
@@ -1087,6 +1072,14 @@ static int __init rx51_i2c_init(void)
rx51_twldata.vdac->constraints.name = "VDAC";
 
omap_pmic_init(1, 2200, "twl5030", 7 + OMAP_INTC_START, &rx51_twldata);
+#if IS_ENABLED(CONFIG_I2C_SI4713) && IS_ENABLED(CONFIG_PLATFORM_SI4713)
+   err = gpio_request_one(RX51_FMTX_IRQ, GPIOF_DIR_IN, "si4713 irq");
+   if (err) {
+   printk(KERN_ERR "Cannot request si4713 irq gpio. %d\n", err);
+   return err;
+   }
+   rx51_peripherals_i2c_board_info_2[0].irq = gpio_to_irq(RX51_FMTX_IRQ);
+#endif
omap_register_i2c_bus(2, 100, rx51_peripherals_i2c_board_info_2,
  ARRAY_SIZE(rx51_peripherals_i2c_board_info_2));
 #if defined(CONFIG_SENSORS_LIS3_I2C) || defined(CONFIG_SENSORS_LIS3_I2C_MODULE)
@@ -1300,6 +1293,7 @@ static void __init rx51_init_omap3_rom_rng(void)
 
 void __init rx51_peripherals_init(void)
 {
+   rx51_gpio_init();
rx51_i2c_init();
regulator_has_full_constraints();
gpmc_onenand_init(board_onenand_data);
@@ -1307,7 +1301,6 @@ void __init rx51_peripherals_init(void)
rx51_add_gpio_keys();
rx51_init_wl1251();
rx51_init_tsc2005();
-   rx51_init_si4713();
rx51_init_lirc();
spi_register_board_info(rx51_peripherals_spi_board_info,
ARRAY_SIZE(rx51_peripherals_spi_board_info));
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-me

[RFCv2 2/8] [media] si4713: switch reset gpio to devm_gpiod API

[Sebastian Reichel]

This updates the driver to use the managed gpiod interface
instead of the unmanged old GPIO API. This is a preperation
for the introduction of device tree support.

Signed-off-by: Sebastian Reichel 
---
 drivers/media/radio/si4713/si4713.c | 38 +
 drivers/media/radio/si4713/si4713.h |  3 ++-
 2 files changed, 19 insertions(+), 22 deletions(-)

diff --git a/drivers/media/radio/si4713/si4713.c 
b/drivers/media/radio/si4713/si4713.c
index b335093..e560a7e 100644
--- a/drivers/media/radio/si4713/si4713.c
+++ b/drivers/media/radio/si4713/si4713.c
@@ -383,9 +383,9 @@ static int si4713_powerup(struct si4713_device *sdev)
}
}
 
-   if (gpio_is_valid(sdev->gpio_reset)) {
+   if (!IS_ERR(sdev->gpio_reset)) {
udelay(50);
-   gpio_set_value(sdev->gpio_reset, 1);
+   gpiod_set_value(sdev->gpio_reset, 1);
}
 
if (client->irq)
@@ -407,8 +407,8 @@ static int si4713_powerup(struct si4713_device *sdev)
SI4713_STC_INT | SI4713_CTS);
return err;
}
-   if (gpio_is_valid(sdev->gpio_reset))
-   gpio_set_value(sdev->gpio_reset, 0);
+   if (!IS_ERR(sdev->gpio_reset))
+   gpiod_set_value(sdev->gpio_reset, 0);
 
 
if (sdev->vdd) {
@@ -447,8 +447,8 @@ static int si4713_powerdown(struct si4713_device *sdev)
v4l2_dbg(1, debug, &sdev->sd, "Power down response: 0x%02x\n",
resp[0]);
v4l2_dbg(1, debug, &sdev->sd, "Device in reset mode\n");
-   if (gpio_is_valid(sdev->gpio_reset))
-   gpio_set_value(sdev->gpio_reset, 0);
+   if (!IS_ERR(sdev->gpio_reset))
+   gpiod_set_value(sdev->gpio_reset, 0);
 
if (sdev->vdd) {
err = regulator_disable(sdev->vdd);
@@ -1457,16 +1457,17 @@ static int si4713_probe(struct i2c_client *client,
goto exit;
}
 
-   sdev->gpio_reset = -1;
-   if (pdata && gpio_is_valid(pdata->gpio_reset)) {
-   rval = gpio_request(pdata->gpio_reset, "si4713 reset");
-   if (rval) {
-   dev_err(&client->dev,
-   "Failed to request gpio: %d\n", rval);
-   goto free_sdev;
-   }
-   sdev->gpio_reset = pdata->gpio_reset;
-   gpio_direction_output(sdev->gpio_reset, 0);
+   sdev->gpio_reset = devm_gpiod_get(&client->dev, "reset");
+   if (!IS_ERR(sdev->gpio_reset)) {
+   gpiod_direction_output(sdev->gpio_reset, 0);
+   } else if (PTR_ERR(sdev->gpio_reset) == -ENOENT) {
+   dev_dbg(&client->dev, "No reset GPIO assigned\n");
+   } else if (PTR_ERR(sdev->gpio_reset) == -ENOSYS) {
+   dev_dbg(&client->dev, "No reset GPIO support\n");
+   } else {
+   rval = PTR_ERR(sdev->gpio_reset);
+   dev_err(&client->dev, "Failed to request gpio: %d\n", rval);
+   goto free_sdev;
}
 
sdev->vdd = devm_regulator_get_optional(&client->dev, "vdd");
@@ -1614,9 +1615,6 @@ free_irq:
free_irq(client->irq, sdev);
 free_ctrls:
v4l2_ctrl_handler_free(hdl);
-free_gpio:
-   if (gpio_is_valid(sdev->gpio_reset))
-   gpio_free(sdev->gpio_reset);
 free_sdev:
kfree(sdev);
 exit:
@@ -1637,8 +1635,6 @@ static int si4713_remove(struct i2c_client *client)
 
v4l2_device_unregister_subdev(sd);
v4l2_ctrl_handler_free(sd->ctrl_handler);
-   if (gpio_is_valid(sdev->gpio_reset))
-   gpio_free(sdev->gpio_reset);
kfree(sdev);
 
return 0;
diff --git a/drivers/media/radio/si4713/si4713.h 
b/drivers/media/radio/si4713/si4713.h
index ed28ed2..7c2479f 100644
--- a/drivers/media/radio/si4713/si4713.h
+++ b/drivers/media/radio/si4713/si4713.h
@@ -16,6 +16,7 @@
 #define SI4713_I2C_H
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -236,7 +237,7 @@ struct si4713_device {
struct completion work;
struct regulator *vdd;
struct regulator *vio;
-   int gpio_reset;
+   struct gpio_desc *gpio_reset;
u32 power_state;
u32 rds_enabled;
u32 frequency;
-- 
2.1.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

[RFCv2 6/8] [media] si4713: add DT binding documentation

[Sebastian Reichel]

This patch adds the DT bindings documentation for Silicon Labs Si4713 FM
radio transmitter.

Signed-off-by: Sebastian Reichel 
---
 Documentation/devicetree/bindings/media/si4713.txt | 30 ++
 1 file changed, 30 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/si4713.txt

diff --git a/Documentation/devicetree/bindings/media/si4713.txt 
b/Documentation/devicetree/bindings/media/si4713.txt
new file mode 100644
index 000..5ee5552
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/si4713.txt
@@ -0,0 +1,30 @@
+* Silicon Labs FM Radio transmitter
+
+The Silicon Labs Si4713 is an FM radio transmitter with receive power scan
+supporting 76-108 MHz. It includes an RDS encoder and has both, a stereo-analog
+and a digital interface, which supports I2S, left-justified and a custom
+DSP-mode format. It is programmable through an I2C interface.
+
+Required Properties:
+- compatible: Should contain "silabs,si4713"
+- reg: the I2C address of the device
+
+Optional Properties:
+- interrupts-extended: Interrupt specifier for the chips interrupt
+- reset-gpios: GPIO specifier for the chips reset line
+- vdd-supply: phandle for Vdd regulator
+- vio-supply: phandle for Vio regulator
+
+Example:
+
+&i2c2 {
+fmtx: si4713@63 {
+compatible = "silabs,si4713";
+reg = <0x63>;
+
+interrupts-extended = <&gpio2 21 IRQ_TYPE_EDGE_FALLING>; /* 53 
*/
+reset-gpios = <&gpio6 3 GPIO_ACTIVE_HIGH>; /* 163 */
+vio-supply = <&vio>;
+vdd-supply = <&vaux1>;
+};
+};
-- 
2.1.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

[RFCv2 4/8] [media] si4713: use managed irq request

[Sebastian Reichel]

Introduce the usage of managed irq request to
simplify the code slightly.

Signed-off-by: Sebastian Reichel 
---
 drivers/media/radio/si4713/si4713.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/media/radio/si4713/si4713.c 
b/drivers/media/radio/si4713/si4713.c
index efc5d6b..ebec16d 100644
--- a/drivers/media/radio/si4713/si4713.c
+++ b/drivers/media/radio/si4713/si4713.c
@@ -1590,7 +1590,7 @@ static int si4713_probe(struct i2c_client *client,
sdev->sd.ctrl_handler = hdl;
 
if (client->irq) {
-   rval = request_irq(client->irq,
+   rval = devm_request_irq(&client->dev, client->irq,
si4713_handler, IRQF_TRIGGER_FALLING,
client->name, sdev);
if (rval < 0) {
@@ -1605,14 +1605,11 @@ static int si4713_probe(struct i2c_client *client,
rval = si4713_initialize(sdev);
if (rval < 0) {
v4l2_err(&sdev->sd, "Failed to probe device information.\n");
-   goto free_irq;
+   goto free_ctrls;
}
 
return 0;
 
-free_irq:
-   if (client->irq)
-   free_irq(client->irq, sdev);
 free_ctrls:
v4l2_ctrl_handler_free(hdl);
 exit:
@@ -1628,9 +1625,6 @@ static int si4713_remove(struct i2c_client *client)
if (sdev->power_state)
si4713_set_power_state(sdev, POWER_DOWN);
 
-   if (client->irq > 0)
-   free_irq(client->irq, sdev);
-
v4l2_device_unregister_subdev(sd);
v4l2_ctrl_handler_free(sd->ctrl_handler);
 
-- 
2.1.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

[RFCv2 8/8] [media] si4713: cleanup platform data

[Sebastian Reichel]

Remove unreferenced members from the platform
data's structure.

Signed-off-by: Sebastian Reichel 
---
 include/media/si4713.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/include/media/si4713.h b/include/media/si4713.h
index 343b8fb5..be4f58e 100644
--- a/include/media/si4713.h
+++ b/include/media/si4713.h
@@ -23,9 +23,6 @@
  * Platform dependent definition
  */
 struct si4713_platform_data {
-   const char * const *supply_names;
-   unsigned supplies;
-   int gpio_reset; /* < 0 if not used */
bool is_platform_device;
 };
 
-- 
2.1.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] [media] s5p_mfc: Remove redundant casts

[Rasmus Villemoes]

Both sides of these assignments actually have type "const struct
vb2_mem_ops *", so the casts are unnecessary and slightly confusing.

Signed-off-by: Rasmus Villemoes 
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c | 4 ++--
 1 file 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 165bc86..8daf291 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -815,7 +815,7 @@ static int s5p_mfc_open(struct file *file)
ret = -ENOENT;
goto err_queue_init;
}
-   q->mem_ops = (struct vb2_mem_ops *)&vb2_dma_contig_memops;
+   q->mem_ops = &vb2_dma_contig_memops;
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
ret = vb2_queue_init(q);
if (ret) {
@@ -837,7 +837,7 @@ static int s5p_mfc_open(struct file *file)
ret = -ENOENT;
goto err_queue_init;
}
-   q->mem_ops = (struct vb2_mem_ops *)&vb2_dma_contig_memops;
+   q->mem_ops = &vb2_dma_contig_memops;
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
ret = vb2_queue_init(q);
if (ret) {
-- 
2.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

[ANNOUNCE] Media summit Report - October, 17-18 2014 - Düsseldorf

[Mauro Carvalho Chehab]

This report is also available in html at: 
http://linuxtv.org/news.php?entry=2014-10-21.mchehab

In the name of the organizing committee, I'd like to thank you all for
being there with us during those two days.

There were several good discussions that happened during the meeting,
aimed to improve even more the Linux media subsystem.

Also, it was agreed during the meeting that we'll try to reach an even
broader audience on the next events. So we're counting with all you
on our next year's event(s).

Thanks!
Mauro

-

Attendees, in alphabetical order:

NAME- EMAIL - ORGANIZATION
Brad Love   - bl...@hauppauge.com   - Hauppauge
Chris Kohn  - christian.k...@xilinx.com - Xilinx
Friedrich Schwittay - fschwit...@pctvsystems.com- PCTV
Guennaddi Liakhovetski  - g.liakhovet...@gmx.de - Intel
Hans de Goede   - hdego...@redhat.com   - Red hat
Hans Verkuil- hverk...@xs4all.nl- Cisco
Henning Garbers - hgarb...@pctvsystems.com  - PCTV
Johannes Stezenbach - j...@linuxtv.org  - LinuxTV
Julien Beraud   - julien.ber...@parrot.com  - Parrot 
(www.parrot.com)
Kamil Debski- k.deb...@samsung.com  - Samsung
Laurent Pinchart- laurent.pinch...@ideasonboard.com - Ideas on board
Lucas Stach - l.st...@pengutronix.de- Pengutronix
Mauro Carvalho Chehab   - mche...@osg.samsung.com   - Samsung
Mike Krufky - mkru...@linuxtv.org   - Samsung
Nicolas Dufresne- nicolas.dufre...@collabora.com- Collabora
Pawel Osciak- pa...@osciak.com  - Google
Peter Griffin   - peter.grif...@linaro.org  - Linaro/ST
Philipp Zabel   - p.za...@pengutronix.de- Pengutronix
Ralph Metzler   - r...@metzlerbros.de   - Meltzler 
Brothers
Ricardo Ribalda Delgado - rica...@qtec.com  - Qtechnolgy A/S
Sakari Ailus- sakari.ai...@linux.intel.com  - Intel

Thursday:


1) Configuration stores - Hans Verkuil
   ===

- Need to report which settings/controls were applied

- Drivers needs to be able to report full/limited Android CameraHAL v3 support
(full means full synchronization support)

- We probably need a mechanism to be able to remove (free) config stores

- Can we use APPLY(0) instead of CLOSE?

- Per buffer or per frame configuration? Note: there is no notion of frame IDs
yet in V4L2.

- Would be nice to be able to disable APPLY, perhaps a flag for the core similar
to HAS STORE

2) Android camera HAL v3 - Sakari Ailus
   

http://www.retiisi.org.uk/v4l2/foil/android-camera-hal-v3-v4l2.pdf
- Capture requests queued lead to returned buffers in order, best effort to make
per-buffer configuration apply correctly needed

- Capture requests/returned buffers do not map directly to QBUF/DQBUF because
multiple buffers in different formats may be produced from a single request.
Some outputs could be implemented in software, e.g. multiple YUV outputs when
hardware simply does not contain as many.

- Should statistical data be returned in a separate video buffer queue? Might be
associated via sequence number, probably separate frame ID better

- 3A library input: frame metadata, depends on sensor, might be in-frame or
out-of band. If possible, separate buffer queue prepared to get to it early.

- HAL v3 needs Start Of Frame and End Of Frame events

- If there is no hardware mechanism for synchronization, apply sensor settings
as soon as possible after SOF and hope for the best. It is possible to verify
the timing has been successful in the user space.

- Sensor settings and ISP settings applied at different points in time, as
sensor settings usally take effect on the following frame

- Sensors may implement all or parts of the ISP themselves. It may not be
feasible to implement hal v3 full profile for such sensors.

- Start of Exposure events not to be implemented in the kernel. HAL must
calculate the event time based on other available information, such as end of
frame (or start of frame event) and other frame timing parameters.

- Some metadata tags could be mapped to V4L2 (compound) controls, they are
associated with a single capture request. Some metadata tags (statistics) are
produced from video buffer queues. Other metadata tags originate from HAL.

- Needs a guarantee that a single capture request will produce all buffers
requested by it with the request's parameters, needs per-buffer configuration,
associating buffers with a certain frame.

- A working halv3 implementation for UVC (limited profile) would be nice to have

- A working halv3 implementation on top of some hardware (full

Re: [media] CODA960: Fails to allocate memory

[Hans Verkuil]

On 10/21/2014 03:42 PM, Jean-Michel Hautbois wrote:

Hi Hans,

2014-10-21 15:27 GMT+02:00 Hans Verkuil :



On 10/21/2014 03:16 PM, Jean-Michel Hautbois wrote:


Hi,

I am trying to use the CODA960 driver on a 3.18 kernel.
It seems pretty good when the module is probed (appart from the
unsupported firmware version) but when I try using the encoder, it
fails allocating dma buffers.

Here is the DT part I added :
&vpu {
  compatible = "fsl,imx6q-vpu";
  clocks = <&clks 168>, <&clks 140>, <&clks 142>;
  clock-names = "per", "ahb", "ocram";
  iramsize = <0x21000>;
  iram = <&ocram>;
  resets = <&src 1>;
  status = "okay";
};

When booting, I see :
[4.410645] coda 204.vpu: Firmware code revision: 46056
[4.416312] coda 204.vpu: Initialized CODA960.
[4.421123] coda 204.vpu: Unsupported firmware version: 3.1.1
[4.483577] coda 204.vpu: codec registered as /dev/video[0-1]

I can start v4l2-ctl and it shows that the device seems to be ok :
   v4l2-ctl --all -d /dev/video1
Driver Info (not using libv4l2):
  Driver name   : coda
  Card type : CODA960
  Bus info  : platform:coda
  Driver version: 3.18.0
  Capabilities  : 0x84208000
  Video Memory-to-Memory
  Streaming
  Extended Pix Format
  Device Capabilities
  Device Caps   : 0x04208000
  Video Memory-to-Memory
  Streaming
  Extended Pix Format
Priority: 2
Format Video Capture:
  Width/Height  : 1920/1088
  Pixel Format  : 'YU12'
  Field : None
  Bytes per Line: 1920
  Size Image: 3133440
  Colorspace: HDTV and modern devices (ITU709)
  Flags :
Format Video Output:
  Width/Height  : 1920/1088
  Pixel Format  : 'H264'
  Field : None
  Bytes per Line: 0
  Size Image: 1048576
  Colorspace: HDTV and modern devices (ITU709)
  Flags :
Selection: compose, Left 0, Top 0, Width 1920, Height 1088
Selection: compose_default, Left 0, Top 0, Width 1920, Height 1088
Selection: compose_bounds, Left 0, Top 0, Width 1920, Height 1088
Selection: compose_padded, Left 0, Top 0, Width 1920, Height 1088
Selection: crop, Left 0, Top 0, Width 1920, Height 1088
Selection: crop_default, Left 0, Top 0, Width 1920, Height 1088
Selection: crop_bounds, Left 0, Top 0, Width 1920, Height 1088

User Controls

  horizontal_flip (bool)   : default=0 value=0
vertical_flip (bool)   : default=0 value=0

Codec Controls

   video_gop_size (int): min=1 max=60 step=1
default=16 value=16
video_bitrate (int): min=0 max=32767000 step=1
default=0 value=0
  number_of_intra_refresh_mbs (int): min=0 max=8160 step=1
default=0 value=0
 sequence_header_mode (menu)   : min=0 max=1 default=1 value=1
 maximum_bytes_in_a_slice (int): min=1 max=1073741823 step=1
default=500 value=500
 number_of_mbs_in_a_slice (int): min=1 max=1073741823 step=1
default=1 value=1
slice_partitioning_method (menu)   : min=0 max=2 default=0 value=0
h264_i_frame_qp_value (int): min=0 max=51 step=1
default=25 value=25
h264_p_frame_qp_value (int): min=0 max=51 step=1
default=25 value=25
h264_maximum_qp_value (int): min=0 max=51 step=1
default=51 value=51
h264_loop_filter_alpha_offset (int): min=0 max=15 step=1 default=0
value=0
 h264_loop_filter_beta_offset (int): min=0 max=15 step=1 default=0
value=0
h264_loop_filter_mode (menu)   : min=0 max=1 default=0 value=0
   mpeg4_i_frame_qp_value (int): min=1 max=31 step=1 default=2
value=2
   mpeg4_p_frame_qp_value (int): min=1 max=31 step=1 default=2
value=2
  horizontal_flip (bool)   : default=0 value=0
vertical_flip (bool)   : default=0 value=0




But when I try to get a file outputed, it fails :

v4l2-ctl -d1 --stream-out-mmap --stream-mmap --stream-to x.raw
[ 1197.292256] coda 204.vpu: dma_alloc_coherent of size 1048576 failed
VIDIOC_REQBUFS: failed: Cannot allocate memory

Did I forget to do something ?



I assume this is physically contiguous memory. Do you have that much phys.
cont. memory
available at all? If the memory is fragmented you won't be able to get it.

Use cma (contiguous memory allocator). You probably have to do very little
expect add
a kernel option to assign enough memory for these buffers.


I added a cma=128M in order to reserve some meory, and it fails...
well, differently :).

~# v4l2-ctl -d1 --stream-out-mmap --stream-mmap --stream-to x.raw
[   56.372023] alloc_contig_range test_pages_isolated(48400, 486fd) failed
[   56.459627] [ cut here ]
[   56.464273] WARNING: CPU: 1 PID: 838 at
drivers/media/v4

Re: [media] CODA960: Fails to allocate memory

[Jean-Michel Hautbois]

Hi Hans,

2014-10-21 15:27 GMT+02:00 Hans Verkuil :
>
>
> On 10/21/2014 03:16 PM, Jean-Michel Hautbois wrote:
>>
>> Hi,
>>
>> I am trying to use the CODA960 driver on a 3.18 kernel.
>> It seems pretty good when the module is probed (appart from the
>> unsupported firmware version) but when I try using the encoder, it
>> fails allocating dma buffers.
>>
>> Here is the DT part I added :
>> &vpu {
>>  compatible = "fsl,imx6q-vpu";
>>  clocks = <&clks 168>, <&clks 140>, <&clks 142>;
>>  clock-names = "per", "ahb", "ocram";
>>  iramsize = <0x21000>;
>>  iram = <&ocram>;
>>  resets = <&src 1>;
>>  status = "okay";
>> };
>>
>> When booting, I see :
>> [4.410645] coda 204.vpu: Firmware code revision: 46056
>> [4.416312] coda 204.vpu: Initialized CODA960.
>> [4.421123] coda 204.vpu: Unsupported firmware version: 3.1.1
>> [4.483577] coda 204.vpu: codec registered as /dev/video[0-1]
>>
>> I can start v4l2-ctl and it shows that the device seems to be ok :
>>   v4l2-ctl --all -d /dev/video1
>> Driver Info (not using libv4l2):
>>  Driver name   : coda
>>  Card type : CODA960
>>  Bus info  : platform:coda
>>  Driver version: 3.18.0
>>  Capabilities  : 0x84208000
>>  Video Memory-to-Memory
>>  Streaming
>>  Extended Pix Format
>>  Device Capabilities
>>  Device Caps   : 0x04208000
>>  Video Memory-to-Memory
>>  Streaming
>>  Extended Pix Format
>> Priority: 2
>> Format Video Capture:
>>  Width/Height  : 1920/1088
>>  Pixel Format  : 'YU12'
>>  Field : None
>>  Bytes per Line: 1920
>>  Size Image: 3133440
>>  Colorspace: HDTV and modern devices (ITU709)
>>  Flags :
>> Format Video Output:
>>  Width/Height  : 1920/1088
>>  Pixel Format  : 'H264'
>>  Field : None
>>  Bytes per Line: 0
>>  Size Image: 1048576
>>  Colorspace: HDTV and modern devices (ITU709)
>>  Flags :
>> Selection: compose, Left 0, Top 0, Width 1920, Height 1088
>> Selection: compose_default, Left 0, Top 0, Width 1920, Height 1088
>> Selection: compose_bounds, Left 0, Top 0, Width 1920, Height 1088
>> Selection: compose_padded, Left 0, Top 0, Width 1920, Height 1088
>> Selection: crop, Left 0, Top 0, Width 1920, Height 1088
>> Selection: crop_default, Left 0, Top 0, Width 1920, Height 1088
>> Selection: crop_bounds, Left 0, Top 0, Width 1920, Height 1088
>>
>> User Controls
>>
>>  horizontal_flip (bool)   : default=0 value=0
>>vertical_flip (bool)   : default=0 value=0
>>
>> Codec Controls
>>
>>   video_gop_size (int): min=1 max=60 step=1
>> default=16 value=16
>>video_bitrate (int): min=0 max=32767000 step=1
>> default=0 value=0
>>  number_of_intra_refresh_mbs (int): min=0 max=8160 step=1
>> default=0 value=0
>> sequence_header_mode (menu)   : min=0 max=1 default=1 value=1
>> maximum_bytes_in_a_slice (int): min=1 max=1073741823 step=1
>> default=500 value=500
>> number_of_mbs_in_a_slice (int): min=1 max=1073741823 step=1
>> default=1 value=1
>>slice_partitioning_method (menu)   : min=0 max=2 default=0 value=0
>>h264_i_frame_qp_value (int): min=0 max=51 step=1
>> default=25 value=25
>>h264_p_frame_qp_value (int): min=0 max=51 step=1
>> default=25 value=25
>>h264_maximum_qp_value (int): min=0 max=51 step=1
>> default=51 value=51
>>h264_loop_filter_alpha_offset (int): min=0 max=15 step=1 default=0
>> value=0
>> h264_loop_filter_beta_offset (int): min=0 max=15 step=1 default=0
>> value=0
>>h264_loop_filter_mode (menu)   : min=0 max=1 default=0 value=0
>>   mpeg4_i_frame_qp_value (int): min=1 max=31 step=1 default=2
>> value=2
>>   mpeg4_p_frame_qp_value (int): min=1 max=31 step=1 default=2
>> value=2
>>  horizontal_flip (bool)   : default=0 value=0
>>vertical_flip (bool)   : default=0 value=0
>>
>>
>>
>>
>> But when I try to get a file outputed, it fails :
>>
>> v4l2-ctl -d1 --stream-out-mmap --stream-mmap --stream-to x.raw
>> [ 1197.292256] coda 204.vpu: dma_alloc_coherent of size 1048576 failed
>> VIDIOC_REQBUFS: failed: Cannot allocate memory
>>
>> Did I forget to do something ?
>
>
> I assume this is physically contiguous memory. Do you have that much phys.
> cont. memory
> available at all? If the memory is fragmented you won't be able to get it.
>
> Use cma (contiguous memory allocator). You probably have to do very little
> expect add
> a kernel option to assign enough memory for these buffers.

I added a cma=128M in order to reserve some meory, and it fails...
well, differently :).

~# v4l2-ctl -d1 --strea

Re: [media] CODA960: Fails to allocate memory

[Hans Verkuil]

On 10/21/2014 03:16 PM, Jean-Michel Hautbois wrote:

Hi,

I am trying to use the CODA960 driver on a 3.18 kernel.
It seems pretty good when the module is probed (appart from the
unsupported firmware version) but when I try using the encoder, it
fails allocating dma buffers.

Here is the DT part I added :
&vpu {
 compatible = "fsl,imx6q-vpu";
 clocks = <&clks 168>, <&clks 140>, <&clks 142>;
 clock-names = "per", "ahb", "ocram";
 iramsize = <0x21000>;
 iram = <&ocram>;
 resets = <&src 1>;
 status = "okay";
};

When booting, I see :
[4.410645] coda 204.vpu: Firmware code revision: 46056
[4.416312] coda 204.vpu: Initialized CODA960.
[4.421123] coda 204.vpu: Unsupported firmware version: 3.1.1
[4.483577] coda 204.vpu: codec registered as /dev/video[0-1]

I can start v4l2-ctl and it shows that the device seems to be ok :
  v4l2-ctl --all -d /dev/video1
Driver Info (not using libv4l2):
 Driver name   : coda
 Card type : CODA960
 Bus info  : platform:coda
 Driver version: 3.18.0
 Capabilities  : 0x84208000
 Video Memory-to-Memory
 Streaming
 Extended Pix Format
 Device Capabilities
 Device Caps   : 0x04208000
 Video Memory-to-Memory
 Streaming
 Extended Pix Format
Priority: 2
Format Video Capture:
 Width/Height  : 1920/1088
 Pixel Format  : 'YU12'
 Field : None
 Bytes per Line: 1920
 Size Image: 3133440
 Colorspace: HDTV and modern devices (ITU709)
 Flags :
Format Video Output:
 Width/Height  : 1920/1088
 Pixel Format  : 'H264'
 Field : None
 Bytes per Line: 0
 Size Image: 1048576
 Colorspace: HDTV and modern devices (ITU709)
 Flags :
Selection: compose, Left 0, Top 0, Width 1920, Height 1088
Selection: compose_default, Left 0, Top 0, Width 1920, Height 1088
Selection: compose_bounds, Left 0, Top 0, Width 1920, Height 1088
Selection: compose_padded, Left 0, Top 0, Width 1920, Height 1088
Selection: crop, Left 0, Top 0, Width 1920, Height 1088
Selection: crop_default, Left 0, Top 0, Width 1920, Height 1088
Selection: crop_bounds, Left 0, Top 0, Width 1920, Height 1088

User Controls

 horizontal_flip (bool)   : default=0 value=0
   vertical_flip (bool)   : default=0 value=0

Codec Controls

  video_gop_size (int): min=1 max=60 step=1
default=16 value=16
   video_bitrate (int): min=0 max=32767000 step=1
default=0 value=0
 number_of_intra_refresh_mbs (int): min=0 max=8160 step=1
default=0 value=0
sequence_header_mode (menu)   : min=0 max=1 default=1 value=1
maximum_bytes_in_a_slice (int): min=1 max=1073741823 step=1
default=500 value=500
number_of_mbs_in_a_slice (int): min=1 max=1073741823 step=1
default=1 value=1
   slice_partitioning_method (menu)   : min=0 max=2 default=0 value=0
   h264_i_frame_qp_value (int): min=0 max=51 step=1
default=25 value=25
   h264_p_frame_qp_value (int): min=0 max=51 step=1
default=25 value=25
   h264_maximum_qp_value (int): min=0 max=51 step=1
default=51 value=51
   h264_loop_filter_alpha_offset (int): min=0 max=15 step=1 default=0 
value=0
h264_loop_filter_beta_offset (int): min=0 max=15 step=1 default=0 
value=0
   h264_loop_filter_mode (menu)   : min=0 max=1 default=0 value=0
  mpeg4_i_frame_qp_value (int): min=1 max=31 step=1 default=2 
value=2
  mpeg4_p_frame_qp_value (int): min=1 max=31 step=1 default=2 
value=2
 horizontal_flip (bool)   : default=0 value=0
   vertical_flip (bool)   : default=0 value=0




But when I try to get a file outputed, it fails :

v4l2-ctl -d1 --stream-out-mmap --stream-mmap --stream-to x.raw
[ 1197.292256] coda 204.vpu: dma_alloc_coherent of size 1048576 failed
VIDIOC_REQBUFS: failed: Cannot allocate memory

Did I forget to do something ?


I assume this is physically contiguous memory. Do you have that much phys. 
cont. memory
available at all? If the memory is fragmented you won't be able to get it.

Use cma (contiguous memory allocator). You probably have to do very little 
expect add
a kernel option to assign enough memory for these buffers.

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: [v4l-utils RFC 0/2] libmediatext library

[Hans de Goede]

Hi Sakari,

On 10/21/2014 12:40 PM, Sakari Ailus wrote:
> Hi,
> 
> This is a tiny library for parsing text-based media link, V4L2 sub-device
> format (and selection) configurations as well as controls with limited
> types.

Hmm, we also have:

[PATCH/RFC v2 1/4] Add a media device configuration file parser.

How do these 2 relate ?

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

[media] CODA960: Fails to allocate memory

[Jean-Michel Hautbois]

Hi,

I am trying to use the CODA960 driver on a 3.18 kernel.
It seems pretty good when the module is probed (appart from the
unsupported firmware version) but when I try using the encoder, it
fails allocating dma buffers.

Here is the DT part I added :
&vpu {
compatible = "fsl,imx6q-vpu";
clocks = <&clks 168>, <&clks 140>, <&clks 142>;
clock-names = "per", "ahb", "ocram";
iramsize = <0x21000>;
iram = <&ocram>;
resets = <&src 1>;
status = "okay";
};

When booting, I see :
[4.410645] coda 204.vpu: Firmware code revision: 46056
[4.416312] coda 204.vpu: Initialized CODA960.
[4.421123] coda 204.vpu: Unsupported firmware version: 3.1.1
[4.483577] coda 204.vpu: codec registered as /dev/video[0-1]

I can start v4l2-ctl and it shows that the device seems to be ok :
 v4l2-ctl --all -d /dev/video1
Driver Info (not using libv4l2):
Driver name   : coda
Card type : CODA960
Bus info  : platform:coda
Driver version: 3.18.0
Capabilities  : 0x84208000
Video Memory-to-Memory
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x04208000
Video Memory-to-Memory
Streaming
Extended Pix Format
Priority: 2
Format Video Capture:
Width/Height  : 1920/1088
Pixel Format  : 'YU12'
Field : None
Bytes per Line: 1920
Size Image: 3133440
Colorspace: HDTV and modern devices (ITU709)
Flags :
Format Video Output:
Width/Height  : 1920/1088
Pixel Format  : 'H264'
Field : None
Bytes per Line: 0
Size Image: 1048576
Colorspace: HDTV and modern devices (ITU709)
Flags :
Selection: compose, Left 0, Top 0, Width 1920, Height 1088
Selection: compose_default, Left 0, Top 0, Width 1920, Height 1088
Selection: compose_bounds, Left 0, Top 0, Width 1920, Height 1088
Selection: compose_padded, Left 0, Top 0, Width 1920, Height 1088
Selection: crop, Left 0, Top 0, Width 1920, Height 1088
Selection: crop_default, Left 0, Top 0, Width 1920, Height 1088
Selection: crop_bounds, Left 0, Top 0, Width 1920, Height 1088

User Controls

horizontal_flip (bool)   : default=0 value=0
  vertical_flip (bool)   : default=0 value=0

Codec Controls

 video_gop_size (int): min=1 max=60 step=1
default=16 value=16
  video_bitrate (int): min=0 max=32767000 step=1
default=0 value=0
number_of_intra_refresh_mbs (int): min=0 max=8160 step=1
default=0 value=0
   sequence_header_mode (menu)   : min=0 max=1 default=1 value=1
   maximum_bytes_in_a_slice (int): min=1 max=1073741823 step=1
default=500 value=500
   number_of_mbs_in_a_slice (int): min=1 max=1073741823 step=1
default=1 value=1
  slice_partitioning_method (menu)   : min=0 max=2 default=0 value=0
  h264_i_frame_qp_value (int): min=0 max=51 step=1
default=25 value=25
  h264_p_frame_qp_value (int): min=0 max=51 step=1
default=25 value=25
  h264_maximum_qp_value (int): min=0 max=51 step=1
default=51 value=51
  h264_loop_filter_alpha_offset (int): min=0 max=15 step=1 default=0 value=0
   h264_loop_filter_beta_offset (int): min=0 max=15 step=1 default=0 value=0
  h264_loop_filter_mode (menu)   : min=0 max=1 default=0 value=0
 mpeg4_i_frame_qp_value (int): min=1 max=31 step=1 default=2 value=2
 mpeg4_p_frame_qp_value (int): min=1 max=31 step=1 default=2 value=2
horizontal_flip (bool)   : default=0 value=0
  vertical_flip (bool)   : default=0 value=0




But when I try to get a file outputed, it fails :

v4l2-ctl -d1 --stream-out-mmap --stream-mmap --stream-to x.raw
[ 1197.292256] coda 204.vpu: dma_alloc_coherent of size 1048576 failed
VIDIOC_REQBUFS: failed: Cannot allocate memory

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

Re: [PATCH v2 1/6] media: add media token device resource framework

[Takashi Iwai]

At Tue, 21 Oct 2014 13:58:59 +0200,
Hans Verkuil wrote:
> 
> 
> 
> On 10/21/2014 01:51 PM, Takashi Iwai wrote:
> > At Tue, 21 Oct 2014 12:46:03 +0200,
> > Hans Verkuil wrote:
> >>
> >> Hi Shuah,
> >>
> >> As promised, here is my review for this patch series.
> >>
> >> On 10/14/2014 04:58 PM, Shuah Khan wrote:
> >>> Add media token device resource framework to allow sharing
> >>> resources such as tuner, dma, audio etc. across media drivers
> >>> and non-media sound drivers that control media hardware. The
> >>> Media token resource is created at the main struct device that
> >>> is common to all drivers that claim various pieces of the main
> >>> media device, which allows them to find the resource using the
> >>> main struct device. As an example, digital, analog, and
> >>> snd-usb-audio drivers can use the media token resource API
> >>> using the main struct device for the interface the media device
> >>> is attached to.
> >>>
> >>> A shared media tokens resource is created using devres framework
> >>> for drivers to find and lock/unlock. Creating a shared devres
> >>> helps avoid creating data structure dependencies between drivers.
> >>> This media token resource contains media token for tuner, and
> >>> audio. When tuner token is requested, audio token is issued.
> >>
> >> Did you mean: 'tuner token is issued' instead of audio token?
> >>
> >> I also have the same question as Takashi: why do we have an audio
> >> token in the first place? While you are streaming audio over alsa
> >> the underlying tuner must be marked as being in use. It's all about
> >> the tuner, since that's the resource that is being shared, not about
> >> audio as such.
> >>
> >> For the remainder of my review I will ignore the audio-related code
> >> and concentrate only on the tuner part.
> >>
> >>> Subsequent token (for tuner and audio) gets from the same task
> >>> and task in the same tgid succeed. This allows applications that
> >>> make multiple v4l2 ioctls to work with the first call acquiring
> >>> the token and applications that create separate threads to handle
> >>> video and audio functions.
> >>>
> >>> Signed-off-by: Shuah Khan 
> >>> ---
> >>>MAINTAINERS  |2 +
> >>>include/linux/media_tknres.h |   50 +
> >>>lib/Makefile |2 +
> >>>lib/media_tknres.c   |  237 
> >>> ++
> >>
> >> I am still not convinced myself that this should be a generic API.
> >> The only reason we need it today is for sharing tuners. Which is almost
> >> a purely media thing with USB audio as the single non-media driver that
> >> will be affected. Today I see no use case outside of tuners. I would
> >> probably want to keep this inside drivers/media.
> >>
> >> If this is going to be expanded it can always be moved to lib later.
> >
> > Well, my argument is that it should be more generic if it were
> > intended to be put in lib.  It'd be fine to put into drivers/media,
> > but this code snippet must be a separate module.  Otherwise usb-audio
> > would grab the whole media stuff even if not needed at all.
> 
> Certainly.
> 
> >
> > (snip)
> >> I also discovered that you are missing MODULE_AUTHOR, MODULE_DESCRIPTION
> >> and above all MODULE_LICENSE. Without the MODULE_LICENSE it won't link this
> >> module to the GPL devres_* functions. It took me some time to figure that
> >> out.
> >
> > It was a code in lib, so it cannot be a module at all :)
> 
> Well, it depends on CONFIG_MEDIA_SUPPORT which is 'm' in my case, so it
> compiles as a module :-)

Ah, I thought it was a boolean, but yes, this can be a module indeed.
Then I don't think it's worth to put in lib.


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

RE: [PATCH v2 14/14] [media] s5p-mfc: Don't change the image size to smaller than the request.

[Kamil Debski]

Hi,

> From: Hans Verkuil [mailto:hverk...@xs4all.nl]
> Sent: Tuesday, October 21, 2014 1:35 PM
> 
> Hi,
> 
> Let me chime in as well, based on the discussions I had last week in
> Düsseldorf:
> 
> On 10/09/2014 12:06 PM, Kamil Debski wrote:
> > Hi,
> >
> >> From: Nicolas Dufresne [mailto:nicolas.dufre...@collabora.com]
> >> Sent: Wednesday, October 08, 2014 4:35 PM
> >>
> >>
> >> Le 2014-10-08 06:24, Kamil Debski a écrit :
> >>> Hi,
> >>>
> >>> This patch seems complicated and I do not understand your motives.
> >>>
> >>> Could you explain what is the problem with the current aligning of
> >> the
> >>> values?
> >>> Is this a hardware problem? Which MFC version does it affect?
> >>> Is it a software problem? If so, maybe the user space application
> >> should
> >>> take extra care on what value it passes/receives to try_fmt?
> >> This looks like something I wanted to bring here as an RFC but never
> >> manage to get the time. In an Odroid Integration we have started
> using
> >> the following simple patch to work around this:
> >>
> >> https://github.com/dsd/linux-
> >> odroid/commit/c76b38c1d682b9870ea3b00093ad6500a9c5f5f6
> >>
> >> The context is that right now we have decided that alignment in
> s_fmt
> >> shall be done with a closest rounding. So the format returned may be
> >> bigger, or smaller, that's basically random. I've been digging
> through
> >> a
> >> lot, and so far I have found no rational that explains this choice
> >> other
> >> that this felt right.
> >>
> >> In real life, whenever the resulting format is smaller then request,
> >> there is little we can do other then fail or try again blindly other
> >> sizes. But with bigger raw buffers, we can use zero-copy  cropping
> >> techniques to keep going. Here's a example:
> >>
> >> image_generator -> hw_converter -> display
> >>
> >> As hw_converter is a V4L2 M2M, an ideal use case here would be for
> >> image_generator to use buffers from the hw_converter. For the
> scenario,
> >> it is likely that a fixed video size is wanted, but this size is
> also
> >> likely not to match HW requirement. If hw_converter decide to give
> back
> >> something smaller, there is nothing image_generator can do. It would
> >> have to try again with random size to find out that best match. It's
> a
> >> bit silly to force that on application, as the hw_converter know the
> >> closest best match, which is simply the next valid bigger size if
> that
> >> exist.
> >>
> >> hope that helps,
> >> Nicolas
> >
> > Nicolas, thank you for shedding light on this problem. I see that it
> is
> > not MFC specific. It seems that the problem applies to all
> Video4Linux2
> > devices that use v4l_bound_align_image. I agree with you that this
> deservers
> > an RFC and some discussion as this would change the behaviour of
> quite
> > a few drivers.
> >
> > I think the documentation does not specify how TRY_FMT/S_FMT should
> adjust
> > the parameters. Maybe it would a good idea to add some flagS that
> determine
> > the behaviour?
> 
> I think we should add flags here as well. NEAREST (the default),
> ROUND_DOWN and
> ROUND_UP. Existing calls will use NEAREST. I can think of use-cases for
> all
> three of these, and I think the caller should just have to specify what
> is
> needed.
> 
> Just replacing the algorithm used seems asking for problems, you want
> to be
> able to select what you want to do.

I agree with Hans here. Nicolas, Pawel, I understand your problem with
the nearest value behaviour and I think this should be resolved right.

I think the flags could be added to the flags field of v4l2_pix_format (and
its multiplane counterpart). Something along the lines:
V4L2_PIX_FMT_FLAG_ALIGN_GE, V4L2_PIX_FMT_FLAG_ALIGN_LE (akin to the flags
used in the selection API).

The function v4l2_bound_align could be then modified to take one more
argument and act accordingly. No flags set would mean the current behaviour,
and when flags are set it would either round up, down or return an error
if the exact value cannot be used.

What do you think?

Best wishes,
-- 
Kamil Debski
Samsung R&D Institute Poland

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

Re: [PATCH v2 14/14] [media] s5p-mfc: Don't change the image size to smaller than the request.

[Nicolas Dufresne]

Le 2014-10-21 07:34, Hans Verkuil a écrit :


I think we should add flags here as well. NEAREST (the default), 
ROUND_DOWN and
ROUND_UP. Existing calls will use NEAREST. I can think of use-cases 
for all
three of these, and I think the caller should just have to specify 
what is

needed.

Just replacing the algorithm used seems asking for problems, you want 
to be
able to select what you want to do. 


One more thing, we realize that in selection scenario, we do want 
nearest or lowest, so indeed a flag that let user space choose is the best.


Nicolas

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

Re: [PATCH v2 1/6] media: add media token device resource framework

[Hans Verkuil]

On 10/21/2014 01:51 PM, Takashi Iwai wrote:

At Tue, 21 Oct 2014 12:46:03 +0200,
Hans Verkuil wrote:


Hi Shuah,

As promised, here is my review for this patch series.

On 10/14/2014 04:58 PM, Shuah Khan wrote:

Add media token device resource framework to allow sharing
resources such as tuner, dma, audio etc. across media drivers
and non-media sound drivers that control media hardware. The
Media token resource is created at the main struct device that
is common to all drivers that claim various pieces of the main
media device, which allows them to find the resource using the
main struct device. As an example, digital, analog, and
snd-usb-audio drivers can use the media token resource API
using the main struct device for the interface the media device
is attached to.

A shared media tokens resource is created using devres framework
for drivers to find and lock/unlock. Creating a shared devres
helps avoid creating data structure dependencies between drivers.
This media token resource contains media token for tuner, and
audio. When tuner token is requested, audio token is issued.


Did you mean: 'tuner token is issued' instead of audio token?

I also have the same question as Takashi: why do we have an audio
token in the first place? While you are streaming audio over alsa
the underlying tuner must be marked as being in use. It's all about
the tuner, since that's the resource that is being shared, not about
audio as such.

For the remainder of my review I will ignore the audio-related code
and concentrate only on the tuner part.


Subsequent token (for tuner and audio) gets from the same task
and task in the same tgid succeed. This allows applications that
make multiple v4l2 ioctls to work with the first call acquiring
the token and applications that create separate threads to handle
video and audio functions.

Signed-off-by: Shuah Khan 
---
   MAINTAINERS  |2 +
   include/linux/media_tknres.h |   50 +
   lib/Makefile |2 +
   lib/media_tknres.c   |  237 
++


I am still not convinced myself that this should be a generic API.
The only reason we need it today is for sharing tuners. Which is almost
a purely media thing with USB audio as the single non-media driver that
will be affected. Today I see no use case outside of tuners. I would
probably want to keep this inside drivers/media.

If this is going to be expanded it can always be moved to lib later.


Well, my argument is that it should be more generic if it were
intended to be put in lib.  It'd be fine to put into drivers/media,
but this code snippet must be a separate module.  Otherwise usb-audio
would grab the whole media stuff even if not needed at all.


Certainly.



(snip)

I also discovered that you are missing MODULE_AUTHOR, MODULE_DESCRIPTION
and above all MODULE_LICENSE. Without the MODULE_LICENSE it won't link this
module to the GPL devres_* functions. It took me some time to figure that
out.


It was a code in lib, so it cannot be a module at all :)


Well, it depends on CONFIG_MEDIA_SUPPORT which is 'm' in my case, so it
compiles as a module :-)

Regards,

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

Re: [PATCH v2 1/6] media: add media token device resource framework

[Takashi Iwai]

At Tue, 21 Oct 2014 12:46:03 +0200,
Hans Verkuil wrote:
> 
> Hi Shuah,
> 
> As promised, here is my review for this patch series.
> 
> On 10/14/2014 04:58 PM, Shuah Khan wrote:
> > Add media token device resource framework to allow sharing
> > resources such as tuner, dma, audio etc. across media drivers
> > and non-media sound drivers that control media hardware. The
> > Media token resource is created at the main struct device that
> > is common to all drivers that claim various pieces of the main
> > media device, which allows them to find the resource using the
> > main struct device. As an example, digital, analog, and
> > snd-usb-audio drivers can use the media token resource API
> > using the main struct device for the interface the media device
> > is attached to.
> >
> > A shared media tokens resource is created using devres framework
> > for drivers to find and lock/unlock. Creating a shared devres
> > helps avoid creating data structure dependencies between drivers.
> > This media token resource contains media token for tuner, and
> > audio. When tuner token is requested, audio token is issued.
> 
> Did you mean: 'tuner token is issued' instead of audio token?
> 
> I also have the same question as Takashi: why do we have an audio
> token in the first place? While you are streaming audio over alsa
> the underlying tuner must be marked as being in use. It's all about
> the tuner, since that's the resource that is being shared, not about
> audio as such.
> 
> For the remainder of my review I will ignore the audio-related code
> and concentrate only on the tuner part.
> 
> > Subsequent token (for tuner and audio) gets from the same task
> > and task in the same tgid succeed. This allows applications that
> > make multiple v4l2 ioctls to work with the first call acquiring
> > the token and applications that create separate threads to handle
> > video and audio functions.
> >
> > Signed-off-by: Shuah Khan 
> > ---
> >   MAINTAINERS  |2 +
> >   include/linux/media_tknres.h |   50 +
> >   lib/Makefile |2 +
> >   lib/media_tknres.c   |  237 
> > ++
> 
> I am still not convinced myself that this should be a generic API.
> The only reason we need it today is for sharing tuners. Which is almost
> a purely media thing with USB audio as the single non-media driver that
> will be affected. Today I see no use case outside of tuners. I would
> probably want to keep this inside drivers/media.
> 
> If this is going to be expanded it can always be moved to lib later.

Well, my argument is that it should be more generic if it were
intended to be put in lib.  It'd be fine to put into drivers/media,
but this code snippet must be a separate module.  Otherwise usb-audio
would grab the whole media stuff even if not needed at all.

(snip)
> I also discovered that you are missing MODULE_AUTHOR, MODULE_DESCRIPTION
> and above all MODULE_LICENSE. Without the MODULE_LICENSE it won't link this
> module to the GPL devres_* functions. It took me some time to figure that
> out.

It was a code in lib, so it cannot be a module at all :)


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

Re: [PATCH v2 14/14] [media] s5p-mfc: Don't change the image size to smaller than the request.

[Hans Verkuil]

Hi,

Let me chime in as well, based on the discussions I had last week in
Düsseldorf:

On 10/09/2014 12:06 PM, Kamil Debski wrote:

Hi,


From: Nicolas Dufresne [mailto:nicolas.dufre...@collabora.com]
Sent: Wednesday, October 08, 2014 4:35 PM


Le 2014-10-08 06:24, Kamil Debski a écrit :

Hi,

This patch seems complicated and I do not understand your motives.

Could you explain what is the problem with the current aligning of

the

values?
Is this a hardware problem? Which MFC version does it affect?
Is it a software problem? If so, maybe the user space application

should

take extra care on what value it passes/receives to try_fmt?

This looks like something I wanted to bring here as an RFC but never
manage to get the time. In an Odroid Integration we have started using
the following simple patch to work around this:

https://github.com/dsd/linux-
odroid/commit/c76b38c1d682b9870ea3b00093ad6500a9c5f5f6

The context is that right now we have decided that alignment in s_fmt
shall be done with a closest rounding. So the format returned may be
bigger, or smaller, that's basically random. I've been digging through
a
lot, and so far I have found no rational that explains this choice
other
that this felt right.

In real life, whenever the resulting format is smaller then request,
there is little we can do other then fail or try again blindly other
sizes. But with bigger raw buffers, we can use zero-copy  cropping
techniques to keep going. Here's a example:

image_generator -> hw_converter -> display

As hw_converter is a V4L2 M2M, an ideal use case here would be for
image_generator to use buffers from the hw_converter. For the scenario,
it is likely that a fixed video size is wanted, but this size is also
likely not to match HW requirement. If hw_converter decide to give back
something smaller, there is nothing image_generator can do. It would
have to try again with random size to find out that best match. It's a
bit silly to force that on application, as the hw_converter know the
closest best match, which is simply the next valid bigger size if that
exist.

hope that helps,
Nicolas


Nicolas, thank you for shedding light on this problem. I see that it is
not MFC specific. It seems that the problem applies to all Video4Linux2
devices that use v4l_bound_align_image. I agree with you that this deservers
an RFC and some discussion as this would change the behaviour of quite
a few drivers.

I think the documentation does not specify how TRY_FMT/S_FMT should adjust
the parameters. Maybe it would a good idea to add some flagS that determine
the behaviour?


I think we should add flags here as well. NEAREST (the default), ROUND_DOWN and
ROUND_UP. Existing calls will use NEAREST. I can think of use-cases for all
three of these, and I think the caller should just have to specify what is
needed.

Just replacing the algorithm used seems asking for problems, you want to be
able to select what you want to do.

Regards,

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

Re: [PATCH v2] media: soc_camera: rcar_vin: Add BT.709 24-bit RGB888 input support

[Yoshihiro Kaneko]

Hello Sergei,

2014-10-21 19:22 GMT+09:00 Sergei Shtylyov :
> Hello.
>
> On 10/21/2014 9:08 AM, Yoshihiro Kaneko wrote:
>
>> From: Koji Matsuoka 
>
>
>> Signed-off-by: Koji Matsuoka 
>> Signed-off-by: Yoshihiro Kaneko 
>> ---
>
>
>> This patch is against master branch of linuxtv.org/media_tree.git.
>
>
>> v2 [Yoshihiro Kaneko]
>> * remove unused/useless definition as suggested by Sergei Shtylyov
>
>
>I didn't say it's useless, I just suspected that you missed the necessary
> test somewhere...

Sorry for my inaccurate description.

>
>>   drivers/media/platform/soc_camera/rcar_vin.c | 9 +
>>   1 file changed, 9 insertions(+)
>
>
>> diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
>> b/drivers/media/platform/soc_camera/rcar_vin.c
>> index 20defcb..cb5e682 100644
>> --- a/drivers/media/platform/soc_camera/rcar_vin.c
>> +++ b/drivers/media/platform/soc_camera/rcar_vin.c
>> @@ -74,6 +74,7 @@
>>   #define VNMC_INF_YUV10_BT656  (2 << 16)
>>   #define VNMC_INF_YUV10_BT601  (3 << 16)
>>   #define VNMC_INF_YUV16(5 << 16)
>> +#define VNMC_INF_RGB888(6 << 16)
>>   #define VNMC_VUP  (1 << 10)
>>   #define VNMC_IM_ODD   (0 << 3)
>>   #define VNMC_IM_ODD_EVEN  (1 << 3)
>
> [...]
>>
>> @@ -331,6 +336,9 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
>> if (output_is_yuv)
>> vnmc |= VNMC_BPS;
>>
>> +   if (vnmc & VNMC_INF_RGB888)
>> +   vnmc ^= VNMC_BPS;
>> +
>
>
>Hm, this also changes the behavior for VNMC_INF_YUV16 and
> VNMC_INF_YUV10_BT{601|656}. Is this actually intended?

Probably this code is incorrect.
Thank you for your review.

Thanks,
Kaneko

>
> [...]
>
> WBR, Sergei
>
--
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 v3 13/13] [media] s5p-mfc: fix a race in interrupt flags handling

[Arun Kumar K]

From: Pawel Osciak 

Interrupt result flags have to be cleared before a hardware job is run.
Otherwise, if they are cleared asynchronously, we may end up clearing them
after the interrupt for which we wanted to wait has already arrived, thus
overwriting the job results that we intended to wait for.

To prevent this, clear the flags only under hw_lock and before running
a hardware job.

Signed-off-by: Pawel Osciak 
Signed-off-by: Kiran AVND 
Signed-off-by: Arun Kumar K 
---
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c   |2 --
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c|3 ---
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|1 -
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c |   13 ++---
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |   12 ++--
 5 files changed, 4 insertions(+), 27 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index 7c3eaa5..86d43d9 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -468,7 +468,6 @@ int s5p_mfc_open_mfc_inst(struct s5p_mfc_dev *dev, struct 
s5p_mfc_ctx *ctx)
}
 
set_work_bit_irqsave(ctx);
-   s5p_mfc_clean_ctx_int_flags(ctx);
s5p_mfc_hw_call_void(dev->mfc_ops, try_run, dev);
if (s5p_mfc_wait_for_done_ctx(ctx,
S5P_MFC_R2H_CMD_OPEN_INSTANCE_RET, 0)) {
@@ -494,7 +493,6 @@ void s5p_mfc_close_mfc_inst(struct s5p_mfc_dev *dev, struct 
s5p_mfc_ctx *ctx)
 {
ctx->state = MFCINST_RETURN_INST;
set_work_bit_irqsave(ctx);
-   s5p_mfc_clean_ctx_int_flags(ctx);
s5p_mfc_hw_call_void(dev->mfc_ops, try_run, dev);
/* Wait until instance is returned or timeout occurred */
if (s5p_mfc_wait_for_done_ctx(ctx,
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index de90465..74bcec8 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -334,7 +334,6 @@ static int vidioc_g_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
MFCINST_RES_CHANGE_END)) {
/* If the MFC is parsing the header,
 * so wait until it is finished */
-   s5p_mfc_clean_ctx_int_flags(ctx);
s5p_mfc_wait_for_done_ctx(ctx, S5P_MFC_R2H_CMD_SEQ_DONE_RET,
0);
}
@@ -746,7 +745,6 @@ static int s5p_mfc_dec_g_v_ctrl(struct v4l2_ctrl *ctrl)
return -EINVAL;
}
/* Should wait for the header to be parsed */
-   s5p_mfc_clean_ctx_int_flags(ctx);
s5p_mfc_wait_for_done_ctx(ctx,
S5P_MFC_R2H_CMD_SEQ_DONE_RET, 0);
if (ctx->state >= MFCINST_HEAD_PARSED &&
@@ -1058,7 +1056,6 @@ static void s5p_mfc_stop_streaming(struct vb2_queue *q)
if (IS_MFCV6_PLUS(dev) && (ctx->state == MFCINST_RUNNING)) {
ctx->state = MFCINST_FLUSH;
set_work_bit_irqsave(ctx);
-   s5p_mfc_clean_ctx_int_flags(ctx);
s5p_mfc_hw_call_void(dev->mfc_ops, try_run, dev);
if (s5p_mfc_wait_for_done_ctx(ctx,
S5P_MFC_R2H_CMD_DPB_FLUSH_RET, 0))
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 6a1c890..7f919e4 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -1663,7 +1663,6 @@ static int s5p_mfc_enc_g_v_ctrl(struct v4l2_ctrl *ctrl)
return -EINVAL;
}
/* Should wait for the header to be produced */
-   s5p_mfc_clean_ctx_int_flags(ctx);
s5p_mfc_wait_for_done_ctx(ctx,
S5P_MFC_R2H_CMD_SEQ_DONE_RET, 0);
if (ctx->state >= MFCINST_HEAD_PARSED &&
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
index 7cf0796..0c4fcf2 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
@@ -1178,7 +1178,6 @@ static void s5p_mfc_run_res_change(struct s5p_mfc_ctx 
*ctx)
 
s5p_mfc_set_dec_stream_buffer_v5(ctx, 0, 0, 0);
dev->curr_ctx = ctx->num;
-   s5p_mfc_clean_ctx_int_flags(ctx);
s5p_mfc_decode_one_frame_v5(ctx, MFC_DEC_RES_CHANGE);
 }
 
@@ -1192,7 +1191,6 @@ static int s5p_mfc_run_dec_frame(struct s5p_mfc_ctx *ctx, 
int last_frame)
last_frame = MFC_DEC_LAST_FRAME;
s5p_mfc_set_dec_stream_buffer_v5(ctx, 0, 0, 0);
dev->curr_ctx = ctx->num;
-   s5p_mfc_clean_ctx_int_flags(ctx);
s5p_mfc_

[PATCH v3 12/13] [media] s5p-mfc: fix V4L2_CID_MIN_BUFFERS_FOR_CAPTURE on resolution change.

[Arun Kumar K]

From: Pawel Osciak 

G_CTRL on V4L2_CID_MIN_BUFFERS_FOR_CAPTURE will fail if userspace happens to
query it after getting a resolution change event and before the codec has
a chance to parse the header and switch to an initialized state.

Signed-off-by: Pawel Osciak 
Signed-off-by: Kiran AVND 
Signed-off-by: Arun Kumar K 
---
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index a98fe02..de90465 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -740,7 +740,8 @@ static int s5p_mfc_dec_g_v_ctrl(struct v4l2_ctrl *ctrl)
ctx->state < MFCINST_ABORT) {
ctrl->val = ctx->pb_count;
break;
-   } else if (ctx->state != MFCINST_INIT) {
+   } else if (ctx->state != MFCINST_INIT &&
+   ctx->state != MFCINST_RES_CHANGE_END) {
v4l2_err(&dev->v4l2_dev, "Decoding not initialised\n");
return -EINVAL;
}
-- 
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

[PATCH v3 10/13] [media] s5p-mfc: flush dpbs when resolution changes

[Arun Kumar K]

From: Kiran AVND 

While resolution change is detected by MFC, we flush out
older dpbs, send the resolution change event to application,
and then accept further queuing of new src buffers.

Sometimes, we error out during dpb flush because of lack of src
buffers. Since we have not started decoding new resolution yet,
it is simpler to push zero-size buffer until we flush out all dpbs.

This is already been done while handling EOS command, and this patch
extends the same logic to resolution change as well.

Signed-off-by: Kiran AVND 
Signed-off-by: Arun Kumar K 
---
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |   20 ++--
 1 file changed, 2 insertions(+), 18 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index 8798b14..7b1cf73 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -1532,27 +1532,11 @@ static inline int s5p_mfc_get_new_ctx(struct 
s5p_mfc_dev *dev)
 static inline void s5p_mfc_run_dec_last_frames(struct s5p_mfc_ctx *ctx)
 {
struct s5p_mfc_dev *dev = ctx->dev;
-   struct s5p_mfc_buf *temp_vb;
-   unsigned long flags;
-
-   spin_lock_irqsave(&dev->irqlock, flags);
-
-   /* Frames are being decoded */
-   if (list_empty(&ctx->src_queue)) {
-   mfc_debug(2, "No src buffers.\n");
-   spin_unlock_irqrestore(&dev->irqlock, flags);
-   return;
-   }
-   /* Get the next source buffer */
-   temp_vb = list_entry(ctx->src_queue.next, struct s5p_mfc_buf, list);
-   temp_vb->flags |= MFC_BUF_FLAG_USED;
-   s5p_mfc_set_dec_stream_buffer_v6(ctx,
-   vb2_dma_contig_plane_dma_addr(temp_vb->b, 0), 0, 0);
-   spin_unlock_irqrestore(&dev->irqlock, flags);
 
+   s5p_mfc_set_dec_stream_buffer_v6(ctx, 0, 0, 0);
dev->curr_ctx = ctx->num;
s5p_mfc_clean_ctx_int_flags(ctx);
-   s5p_mfc_decode_one_frame_v6(ctx, 1);
+   s5p_mfc_decode_one_frame_v6(ctx, MFC_DEC_LAST_FRAME);
 }
 
 static inline int s5p_mfc_run_dec_frame(struct s5p_mfc_ctx *ctx)
-- 
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

[PATCH v3 11/13] [media] s5p-mfc: Remove unused alloc field from private buffer struct.

[Arun Kumar K]

From: Pawel Osciak 

This field is no longer used as MFC driver doesn't use vb2 alloc contexts
anymore.

Signed-off-by: Pawel Osciak 
Signed-off-by: Kiran AVND 
Signed-off-by: Arun Kumar K 
---
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h |3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 5b0c334..15f7663 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -237,8 +237,6 @@ struct s5p_mfc_variant {
 
 /**
  * struct s5p_mfc_priv_buf - represents internal used buffer
- * @alloc: allocation-specific context for each buffer
- * (videobuf2 allocator)
  * @ofs:   offset of each buffer, will be used for MFC
  * @virt:  kernel virtual address, only valid when the
  * buffer accessed by driver
@@ -246,7 +244,6 @@ struct s5p_mfc_variant {
  * @size:  size of the buffer
  */
 struct s5p_mfc_priv_buf {
-   void*alloc;
unsigned long   ofs;
void*virt;
dma_addr_t  dma;
-- 
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

[PATCH v3 06/13] [media] s5p-mfc: check mfc bus ctrl before reset

[Arun Kumar K]

From: Kiran AVND 

during reset sequence, it is advisable to follow the below
sequence, in order to avoid unexpected behavior from MFC
. set SFR 0x7110 MFC_BUS_RESET_CTRL 0x1
  // wait for REQ_STATUS to be 1
. get SFR 0x7110 MFC_BUS_RESET_CTRL 0x3
  // reset now

Signed-off-by: Kiran AVND 
Signed-off-by: Arun Kumar K 
---
 drivers/media/platform/s5p-mfc/regs-mfc-v6.h  |1 +
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c |   25 -
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v6.h 
b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
index 51cb2dd..83e01f3 100644
--- a/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
+++ b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
@@ -71,6 +71,7 @@
 #define S5P_FIMV_R2H_CMD_ENC_BUFFER_FUL_RET_V6 16
 #define S5P_FIMV_R2H_CMD_ERR_RET_V632
 
+#define S5P_FIMV_MFC_BUS_RESET_CTRL0x7110
 #define S5P_FIMV_FW_VERSION_V6 0xf000
 
 #define S5P_FIMV_INSTANCE_ID_V60xf008
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index f5bb6b2..0d3661b 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -129,6 +129,25 @@ int s5p_mfc_release_firmware(struct s5p_mfc_dev *dev)
return 0;
 }
 
+int s5p_mfc_bus_reset(struct s5p_mfc_dev *dev)
+{
+   unsigned int status;
+   unsigned long timeout;
+
+   /* Reset */
+   mfc_write(dev, 0x1, S5P_FIMV_MFC_BUS_RESET_CTRL);
+   timeout = jiffies + msecs_to_jiffies(MFC_BW_TIMEOUT);
+   /* Check bus status */
+   do {
+   if (time_after(jiffies, timeout)) {
+   mfc_err("Timeout while resetting MFC.\n");
+   return -EIO;
+   }
+   status = mfc_read(dev, S5P_FIMV_MFC_BUS_RESET_CTRL);
+   } while ((status & 0x2) == 0);
+   return 0;
+}
+
 /* Reset the device */
 int s5p_mfc_reset(struct s5p_mfc_dev *dev)
 {
@@ -147,11 +166,15 @@ int s5p_mfc_reset(struct s5p_mfc_dev *dev)
for (i = 0; i < S5P_FIMV_REG_CLEAR_COUNT_V6; i++)
mfc_write(dev, 0, S5P_FIMV_REG_CLEAR_BEGIN_V6 + (i*4));
 
+   /* check bus reset control before reset */
+   if (dev->risc_on)
+   if (s5p_mfc_bus_reset(dev))
+   return -EIO;
/* Reset
 * set RISC_ON to 0 during power_on & wake_up.
 * V6 needs RISC_ON set to 0 during reset also.
 */
-   if ((!dev->risc_on) || (!IS_MFCV7(dev)))
+   if ((!dev->risc_on) || (!IS_MFCV7_PLUS(dev)))
mfc_write(dev, 0, S5P_FIMV_RISC_ON_V6);
 
mfc_write(dev, 0x1FFF, S5P_FIMV_MFC_RESET_V6);
-- 
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

[PATCH v3 07/13] [media] s5p-mfc: Don't crash the kernel if the watchdog kicks in.

[Arun Kumar K]

From: Pawel Osciak 

If the software watchdog kicks in, the watchdog worker is not synchronized
with hardware interrupts and does not block other instances. It's possible
for it to clear the hw_lock, making other instances trigger a BUG() on
hw_lock checks. Since it's not fatal to clear the hw_lock to zero twice,
just WARN in those cases for now. We should not explode, as firmware will
return errors as needed for other instances after it's reloaded, or they
will time out.

A clean fix should involve killing other instances when watchdog kicks in,
but requires a major redesign of locking in the driver.

Signed-off-by: Pawel Osciak 
Signed-off-by: Kiran AVND 
Signed-off-by: Arun Kumar K 
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c |   21 +++--
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index eb71055..8620236 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -342,8 +342,7 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx *ctx,
ctx->state = MFCINST_RES_CHANGE_INIT;
s5p_mfc_hw_call_void(dev->mfc_ops, clear_int_flags, dev);
wake_up_ctx(ctx, reason, err);
-   if (test_and_clear_bit(0, &dev->hw_lock) == 0)
-   BUG();
+   WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0);
s5p_mfc_clock_off();
s5p_mfc_hw_call_void(dev->mfc_ops, try_run, dev);
return;
@@ -415,8 +414,7 @@ leave_handle_frame:
clear_work_bit(ctx);
s5p_mfc_hw_call_void(dev->mfc_ops, clear_int_flags, dev);
wake_up_ctx(ctx, reason, err);
-   if (test_and_clear_bit(0, &dev->hw_lock) == 0)
-   BUG();
+   WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0);
s5p_mfc_clock_off();
/* if suspending, wake up device and do not try_run again*/
if (test_bit(0, &dev->enter_suspend))
@@ -463,8 +461,7 @@ static void s5p_mfc_handle_error(struct s5p_mfc_dev *dev,
break;
}
}
-   if (test_and_clear_bit(0, &dev->hw_lock) == 0)
-   BUG();
+   WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0);
s5p_mfc_hw_call_void(dev->mfc_ops, clear_int_flags, dev);
s5p_mfc_clock_off();
wake_up_dev(dev, reason, err);
@@ -518,8 +515,7 @@ static void s5p_mfc_handle_seq_done(struct s5p_mfc_ctx *ctx,
}
s5p_mfc_hw_call_void(dev->mfc_ops, clear_int_flags, dev);
clear_work_bit(ctx);
-   if (test_and_clear_bit(0, &dev->hw_lock) == 0)
-   BUG();
+   WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0);
s5p_mfc_clock_off();
s5p_mfc_hw_call_void(dev->mfc_ops, try_run, dev);
wake_up_ctx(ctx, reason, err);
@@ -557,16 +553,14 @@ static void s5p_mfc_handle_init_buffers(struct 
s5p_mfc_ctx *ctx,
} else {
ctx->dpb_flush_flag = 0;
}
-   if (test_and_clear_bit(0, &dev->hw_lock) == 0)
-   BUG();
+   WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0);
 
s5p_mfc_clock_off();
 
wake_up(&ctx->queue);
s5p_mfc_hw_call_void(dev->mfc_ops, try_run, dev);
} else {
-   if (test_and_clear_bit(0, &dev->hw_lock) == 0)
-   BUG();
+   WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0);
 
s5p_mfc_clock_off();
 
@@ -643,8 +637,7 @@ static irqreturn_t s5p_mfc_irq(int irq, void *priv)
mfc_err("post_frame_start() failed\n");
s5p_mfc_hw_call_void(dev->mfc_ops, clear_int_flags, 
dev);
wake_up_ctx(ctx, reason, err);
-   if (test_and_clear_bit(0, &dev->hw_lock) == 0)
-   BUG();
+   WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0);
s5p_mfc_clock_off();
s5p_mfc_hw_call_void(dev->mfc_ops, try_run, dev);
} else {
-- 
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

[PATCH v3 09/13] [media] s5p-mfc: De-init MFC when watchdog kicks in

[Arun Kumar K]

From: Arun Mankuzhi 

If the software watchdog kicks in, we need to de-init MFC
before reloading firmware and re-intializing it again.

Signed-off-by: Arun Mankuzhi 
Signed-off-by: Kiran AVND 
Signed-off-by: Arun Kumar K 
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c |4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 8620236..39f8f2a 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -159,6 +159,10 @@ static void s5p_mfc_watchdog_worker(struct work_struct 
*work)
}
clear_bit(0, &dev->hw_lock);
spin_unlock_irqrestore(&dev->irqlock, flags);
+
+   /* De-init MFC */
+   s5p_mfc_deinit_hw(dev);
+
/* Double check if there is at least one instance running.
 * If no instance is in memory than no firmware should be present */
if (dev->num_inst > 0) {
-- 
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

[PATCH v3 08/13] [media] s5p-mfc: modify mfc wakeup sequence for V8

[Arun Kumar K]

From: Arun Mankuzhi 

>From MFC V8, the MFC wakeup sequence has changed.
MFC wakeup command has to be sent after the host receives
firmware load complete status from risc.

Signed-off-by: Arun Mankuzhi 
Signed-off-by: Kiran AVND 
Signed-off-by: Arun Kumar K 
---
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c |   78 +++--
 1 file changed, 61 insertions(+), 17 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index 0d3661b..7c3eaa5 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -353,6 +353,58 @@ int s5p_mfc_sleep(struct s5p_mfc_dev *dev)
return ret;
 }
 
+static int s5p_mfc_v8_wait_wakeup(struct s5p_mfc_dev *dev)
+{
+   int ret;
+
+   /* Release reset signal to the RISC */
+   dev->risc_on = 1;
+   mfc_write(dev, 0x1, S5P_FIMV_RISC_ON_V6);
+
+   if (s5p_mfc_wait_for_done_dev(dev, S5P_MFC_R2H_CMD_FW_STATUS_RET)) {
+   mfc_err("Failed to reset MFCV8\n");
+   return -EIO;
+   }
+   mfc_debug(2, "Write command to wakeup MFCV8\n");
+   ret = s5p_mfc_hw_call(dev->mfc_cmds, wakeup_cmd, dev);
+   if (ret) {
+   mfc_err("Failed to send command to MFCV8 - timeout\n");
+   return ret;
+   }
+
+   if (s5p_mfc_wait_for_done_dev(dev, S5P_MFC_R2H_CMD_WAKEUP_RET)) {
+   mfc_err("Failed to wakeup MFC\n");
+   return -EIO;
+   }
+   return ret;
+}
+
+static int s5p_mfc_wait_wakeup(struct s5p_mfc_dev *dev)
+{
+   int ret;
+
+   /* Send MFC wakeup command */
+   ret = s5p_mfc_hw_call(dev->mfc_cmds, wakeup_cmd, dev);
+   if (ret) {
+   mfc_err("Failed to send command to MFC - timeout\n");
+   return ret;
+   }
+
+   /* Release reset signal to the RISC */
+   if (IS_MFCV6_PLUS(dev)) {
+   dev->risc_on = 1;
+   mfc_write(dev, 0x1, S5P_FIMV_RISC_ON_V6);
+   } else {
+   mfc_write(dev, 0x3ff, S5P_FIMV_SW_RESET);
+   }
+
+   if (s5p_mfc_wait_for_done_dev(dev, S5P_MFC_R2H_CMD_WAKEUP_RET)) {
+   mfc_err("Failed to wakeup MFC\n");
+   return -EIO;
+   }
+   return ret;
+}
+
 int s5p_mfc_wakeup(struct s5p_mfc_dev *dev)
 {
int ret;
@@ -365,6 +417,7 @@ int s5p_mfc_wakeup(struct s5p_mfc_dev *dev)
ret = s5p_mfc_reset(dev);
if (ret) {
mfc_err("Failed to reset MFC - timeout\n");
+   s5p_mfc_clock_off();
return ret;
}
mfc_debug(2, "Done MFC reset..\n");
@@ -373,25 +426,16 @@ int s5p_mfc_wakeup(struct s5p_mfc_dev *dev)
/* 2. Initialize registers of channel I/F */
s5p_mfc_clear_cmds(dev);
s5p_mfc_clean_dev_int_flags(dev);
-   /* 3. Initialize firmware */
-   ret = s5p_mfc_hw_call(dev->mfc_cmds, wakeup_cmd, dev);
-   if (ret) {
-   mfc_err("Failed to send command to MFC - timeout\n");
-   return ret;
-   }
-   /* 4. Release reset signal to the RISC */
-   if (IS_MFCV6_PLUS(dev)) {
-   dev->risc_on = 1;
-   mfc_write(dev, 0x1, S5P_FIMV_RISC_ON_V6);
-   }
+   /* 3. Send MFC wakeup command and wait for completion*/
+   if (IS_MFCV8(dev))
+   ret = s5p_mfc_v8_wait_wakeup(dev);
else
-   mfc_write(dev, 0x3ff, S5P_FIMV_SW_RESET);
-   mfc_debug(2, "Ok, now will write a command to wakeup the system\n");
-   if (s5p_mfc_wait_for_done_dev(dev, S5P_MFC_R2H_CMD_WAKEUP_RET)) {
-   mfc_err("Failed to load firmware\n");
-   return -EIO;
-   }
+   ret = s5p_mfc_wait_wakeup(dev);
+
s5p_mfc_clock_off();
+   if (ret)
+   return ret;
+
dev->int_cond = 0;
if (dev->int_err != 0 || dev->int_type !=
S5P_MFC_R2H_CMD_WAKEUP_RET) {
-- 
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

[PATCH v3 01/13] [media] s5p-mfc: support MIN_BUFFERS query for encoder

[Arun Kumar K]

From: Kiran AVND 

Add V4L2_CID_MIN_BUFFERS_FOR_OUTPUT query for encoder.
Once mfc encoder state is HEAD_PARSED, which is sequence
header produced, dpb_count is avaialable. Let user space
query this value.

Signed-off-by: Kiran AVND 
Signed-off-by: Arun Kumar K 
---
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c |   42 ++
 1 file changed, 42 insertions(+)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index a904a1c..4816f31 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -690,6 +690,16 @@ static struct mfc_control controls[] = {
.step = 1,
.default_value = 0,
},
+   {
+   .id = V4L2_CID_MIN_BUFFERS_FOR_OUTPUT,
+   .type = V4L2_CTRL_TYPE_INTEGER,
+   .name = "Minimum number of output bufs",
+   .minimum = 1,
+   .maximum = 32,
+   .step = 1,
+   .default_value = 1,
+   .is_volatile = 1,
+   },
 };
 
 #define NUM_CTRLS ARRAY_SIZE(controls)
@@ -1624,8 +1634,40 @@ static int s5p_mfc_enc_s_ctrl(struct v4l2_ctrl *ctrl)
return ret;
 }
 
+static int s5p_mfc_enc_g_v_ctrl(struct v4l2_ctrl *ctrl)
+{
+   struct s5p_mfc_ctx *ctx = ctrl_to_ctx(ctrl);
+   struct s5p_mfc_dev *dev = ctx->dev;
+
+   switch (ctrl->id) {
+   case V4L2_CID_MIN_BUFFERS_FOR_OUTPUT:
+   if (ctx->state >= MFCINST_HEAD_PARSED &&
+   ctx->state < MFCINST_ABORT) {
+   ctrl->val = ctx->pb_count;
+   break;
+   } else if (ctx->state != MFCINST_INIT) {
+   v4l2_err(&dev->v4l2_dev, "Encoding not initialised\n");
+   return -EINVAL;
+   }
+   /* Should wait for the header to be produced */
+   s5p_mfc_clean_ctx_int_flags(ctx);
+   s5p_mfc_wait_for_done_ctx(ctx,
+   S5P_MFC_R2H_CMD_SEQ_DONE_RET, 0);
+   if (ctx->state >= MFCINST_HEAD_PARSED &&
+   ctx->state < MFCINST_ABORT) {
+   ctrl->val = ctx->pb_count;
+   } else {
+   v4l2_err(&dev->v4l2_dev, "Encoding not initialised\n");
+   return -EINVAL;
+   }
+   break;
+   }
+   return 0;
+}
+
 static const struct v4l2_ctrl_ops s5p_mfc_enc_ctrl_ops = {
.s_ctrl = s5p_mfc_enc_s_ctrl,
+   .g_volatile_ctrl = s5p_mfc_enc_g_v_ctrl,
 };
 
 static int vidioc_s_parm(struct file *file, void *priv,
-- 
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

[PATCH v3 04/13] [media] s5p-mfc: Only set timestamp/timecode for new frames.

[Arun Kumar K]

From: Ilja Friedel 

Timestamp i of a previously decoded buffer was overwritten for some
H.264 streams with timestamp i+1 of the next buffer. This happened when
encountering frame_type S5P_FIMV_DECODE_FRAME_SKIPPED, indicating no
new frame.

In most cases this wrong indexing might not have been noticed except
for a one frame delay in frame presentation. For H.264 streams though
that require reordering of frames for presentation, it caused a slightly
erratic presentation time lookup and consequently dropped frames in the
Pepper Flash plugin.

Signed-off-by: Ilja H. Friedel 
Signed-off-by: Kiran AVND 
Signed-off-by: Arun Kumar K 
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c |   12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 79c9537..eb71055 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -220,11 +220,14 @@ static void s5p_mfc_handle_frame_copy_time(struct 
s5p_mfc_ctx *ctx)
size_t dec_y_addr;
unsigned int frame_type;
 
-   dec_y_addr = s5p_mfc_hw_call(dev->mfc_ops, get_dec_y_adr, dev);
+   /* Make sure we actually have a new frame before continuing. */
frame_type = s5p_mfc_hw_call(dev->mfc_ops, get_dec_frame_type, dev);
+   if (frame_type == S5P_FIMV_DECODE_FRAME_SKIPPED)
+   return;
+   dec_y_addr = s5p_mfc_hw_call(dev->mfc_ops, get_dec_y_adr, dev);
 
/* Copy timestamp / timecode from decoded src to dst and set
-  appropriate flags */
+  appropriate flags. */
src_buf = list_entry(ctx->src_queue.next, struct s5p_mfc_buf, list);
list_for_each_entry(dst_buf, &ctx->dst_queue, list) {
if (vb2_dma_contig_plane_dma_addr(dst_buf->b, 0) == dec_y_addr) 
{
@@ -250,6 +253,11 @@ static void s5p_mfc_handle_frame_copy_time(struct 
s5p_mfc_ctx *ctx)
dst_buf->b->v4l2_buf.flags |=
V4L2_BUF_FLAG_BFRAME;
break;
+   default:
+   /* Don't know how to handle
+  S5P_FIMV_DECODE_FRAME_OTHER_FRAME. */
+   mfc_debug(2, "Unexpected frame type: %d\n",
+   frame_type);
}
break;
}
-- 
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

[PATCH v3 02/13] [media] s5p-mfc: Fix REQBUFS(0) for encoder.

[Arun Kumar K]

From: Pawel Osciak 

Handle REQBUFS(0) for CAPTURE queue as well. Also use the proper queue to call
it on for OUTPUT.

Signed-off-by: Pawel Osciak 
Signed-off-by: Kiran AVND 
Signed-off-by: Arun Kumar K 
---
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c |   13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 4816f31..6a1c890 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -1147,6 +1147,11 @@ static int vidioc_reqbufs(struct file *file, void *priv,
(reqbufs->memory != V4L2_MEMORY_USERPTR))
return -EINVAL;
if (reqbufs->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
+   if (reqbufs->count == 0) {
+   ret = vb2_reqbufs(&ctx->vq_dst, reqbufs);
+   ctx->capture_state = QUEUE_FREE;
+   return ret;
+   }
if (ctx->capture_state != QUEUE_FREE) {
mfc_err("invalid capture state: %d\n",
ctx->capture_state);
@@ -1168,6 +1173,14 @@ static int vidioc_reqbufs(struct file *file, void *priv,
return -ENOMEM;
}
} else if (reqbufs->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
+   if (reqbufs->count == 0) {
+   mfc_debug(2, "Freeing buffers\n");
+   ret = vb2_reqbufs(&ctx->vq_src, reqbufs);
+   s5p_mfc_hw_call(dev->mfc_ops, release_codec_buffers,
+   ctx);
+   ctx->output_state = QUEUE_FREE;
+   return ret;
+   }
if (ctx->output_state != QUEUE_FREE) {
mfc_err("invalid output state: %d\n",
ctx->output_state);
-- 
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

[PATCH v3 05/13] [media] s5p-mfc: keep RISC ON during reset for V7/V8

[Arun Kumar K]

From: Kiran AVND 

Reset sequence for MFC V7 and V8 do not need RISC_ON
to be set to 0, while for MFC V6 it is still needed.

Also, remove a couple of register settings during Reset
which are not needed from V6 onwards.

Signed-off-by: Kiran AVND 
Signed-off-by: Arun Kumar K 
---
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h |1 +
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c   |   25 ++-
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 3e41ca1..5b0c334 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -340,6 +340,7 @@ struct s5p_mfc_dev {
struct s5p_mfc_hw_cmds *mfc_cmds;
const struct s5p_mfc_regs *mfc_regs;
enum s5p_mfc_fw_ver fw_ver;
+   bool risc_on; /* indicates if RISC is on or off */
 };
 
 /**
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index 0c885a8..f5bb6b2 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -139,12 +139,6 @@ int s5p_mfc_reset(struct s5p_mfc_dev *dev)
mfc_debug_enter();
 
if (IS_MFCV6_PLUS(dev)) {
-   /* Reset IP */
-   /*  except RISC, reset */
-   mfc_write(dev, 0xFEE, S5P_FIMV_MFC_RESET_V6);
-   /*  reset release */
-   mfc_write(dev, 0x0, S5P_FIMV_MFC_RESET_V6);
-
/* Zero Initialization of MFC registers */
mfc_write(dev, 0, S5P_FIMV_RISC2HOST_CMD_V6);
mfc_write(dev, 0, S5P_FIMV_HOST2RISC_CMD_V6);
@@ -153,8 +147,13 @@ int s5p_mfc_reset(struct s5p_mfc_dev *dev)
for (i = 0; i < S5P_FIMV_REG_CLEAR_COUNT_V6; i++)
mfc_write(dev, 0, S5P_FIMV_REG_CLEAR_BEGIN_V6 + (i*4));
 
-   /* Reset */
-   mfc_write(dev, 0, S5P_FIMV_RISC_ON_V6);
+   /* Reset
+* set RISC_ON to 0 during power_on & wake_up.
+* V6 needs RISC_ON set to 0 during reset also.
+*/
+   if ((!dev->risc_on) || (!IS_MFCV7(dev)))
+   mfc_write(dev, 0, S5P_FIMV_RISC_ON_V6);
+
mfc_write(dev, 0x1FFF, S5P_FIMV_MFC_RESET_V6);
mfc_write(dev, 0, S5P_FIMV_MFC_RESET_V6);
} else {
@@ -226,6 +225,7 @@ int s5p_mfc_init_hw(struct s5p_mfc_dev *dev)
/* 0. MFC reset */
mfc_debug(2, "MFC reset..\n");
s5p_mfc_clock_on();
+   dev->risc_on = 0;
ret = s5p_mfc_reset(dev);
if (ret) {
mfc_err("Failed to reset MFC - timeout\n");
@@ -238,8 +238,10 @@ int s5p_mfc_init_hw(struct s5p_mfc_dev *dev)
s5p_mfc_clear_cmds(dev);
/* 3. Release reset signal to the RISC */
s5p_mfc_clean_dev_int_flags(dev);
-   if (IS_MFCV6_PLUS(dev))
+   if (IS_MFCV6_PLUS(dev)) {
+   dev->risc_on = 1;
mfc_write(dev, 0x1, S5P_FIMV_RISC_ON_V6);
+   }
else
mfc_write(dev, 0x3ff, S5P_FIMV_SW_RESET);
mfc_debug(2, "Will now wait for completion of firmware transfer\n");
@@ -336,6 +338,7 @@ int s5p_mfc_wakeup(struct s5p_mfc_dev *dev)
/* 0. MFC reset */
mfc_debug(2, "MFC reset..\n");
s5p_mfc_clock_on();
+   dev->risc_on = 0;
ret = s5p_mfc_reset(dev);
if (ret) {
mfc_err("Failed to reset MFC - timeout\n");
@@ -354,8 +357,10 @@ int s5p_mfc_wakeup(struct s5p_mfc_dev *dev)
return ret;
}
/* 4. Release reset signal to the RISC */
-   if (IS_MFCV6_PLUS(dev))
+   if (IS_MFCV6_PLUS(dev)) {
+   dev->risc_on = 1;
mfc_write(dev, 0x1, S5P_FIMV_RISC_ON_V6);
+   }
else
mfc_write(dev, 0x3ff, S5P_FIMV_SW_RESET);
mfc_debug(2, "Ok, now will write a command to wakeup the system\n");
-- 
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

[PATCH v3 03/13] [media] s5p-mfc: clear 'enter_suspend' flag if suspend fails

[Arun Kumar K]

From: Prathyush K 

The enter_suspend flag is set after we enter mfc suspend function but if
suspend fails after that due to any reason (like hardware timeout etc),
this flag must be cleared before returning an error. Otherwise, this
flag never gets cleared and the MFC suspend will always return an error
on subsequent tries. If clock off fails, disable hw_lock also.

Signed-off-by: Prathyush K 
Signed-off-by: Kiran AVND 
Signed-off-by: Arun Kumar K 
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 165bc86..79c9537 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1284,11 +1284,17 @@ static int s5p_mfc_suspend(struct device *dev)
m_dev->int_cond, msecs_to_jiffies(MFC_INT_TIMEOUT));
if (ret == 0) {
mfc_err("Waiting for hardware to finish timed out\n");
+   clear_bit(0, &m_dev->enter_suspend);
return -EIO;
}
}
 
-   return s5p_mfc_sleep(m_dev);
+   ret = s5p_mfc_sleep(m_dev);
+   if (ret) {
+   clear_bit(0, &m_dev->enter_suspend);
+   clear_bit(0, &m_dev->hw_lock);
+   }
+   return ret;
 }
 
 static int s5p_mfc_resume(struct device *dev)
-- 
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

[PATCH v3 00/13] Fixes from Chrome OS tree for MFC driver

[Arun Kumar K]

Upstreaming the fixes which have gone in to Chrome OS tree for MFC driver.
Tested on MFCV8, MFCV7 and MFCV6 based Exynos5 based boards, peach-pi
(5800), peach-pit (5420) and snow (5250).

Changes from v2:
1) Rebased on latest media-tree
2) Dropped the patch (14/14) from previous set
   s5p-mfc: Don't change the image size to smaller than the request.

Changes from v1:
1) Addressed all review comments from Kamil.
2) Dropped patches
   [media] s5p-mfc: set B-frames as 2 while encoding
   [media] s5p-mfc: remove reduntant clock on & clock off
   [media] s5p-mfc: don't disable clock when next ctx is pending
3) Rebased on media-tree

Arun Mankuzhi (2):
  [media] s5p-mfc: modify mfc wakeup sequence for V8
  [media] s5p-mfc: De-init MFC when watchdog kicks in

Ilja Friedel (1):
  [media] s5p-mfc: Only set timestamp/timecode for new frames.

Kiran AVND (4):
  [media] s5p-mfc: support MIN_BUFFERS query for encoder
  [media] s5p-mfc: keep RISC ON during reset for V7/V8
  [media] s5p-mfc: check mfc bus ctrl before reset
  [media] s5p-mfc: flush dpbs when resolution changes

Pawel Osciak (5):
  [media] s5p-mfc: Fix REQBUFS(0) for encoder.
  [media] s5p-mfc: Don't crash the kernel if the watchdog kicks in.
  [media] s5p-mfc: Remove unused alloc field from private buffer
struct.
  [media] s5p-mfc: fix V4L2_CID_MIN_BUFFERS_FOR_CAPTURE on resolution
change.
  [media] s5p-mfc: fix a race in interrupt flags handling

Prathyush K (1):
  [media] s5p-mfc: clear 'enter_suspend' flag if suspend fails

 drivers/media/platform/s5p-mfc/regs-mfc-v6.h|1 +
 drivers/media/platform/s5p-mfc/s5p_mfc.c|   45 +
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h |4 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c   |  122 ++-
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c|6 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|   54 ++
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c |   13 +--
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |   32 +-
 8 files changed, 188 insertions(+), 89 deletions(-)

-- 
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: [PATCH v2 1/6] media: add media token device resource framework

[Hans Verkuil]

Hi Shuah,

As promised, here is my review for this patch series.

On 10/14/2014 04:58 PM, Shuah Khan wrote:

Add media token device resource framework to allow sharing
resources such as tuner, dma, audio etc. across media drivers
and non-media sound drivers that control media hardware. The
Media token resource is created at the main struct device that
is common to all drivers that claim various pieces of the main
media device, which allows them to find the resource using the
main struct device. As an example, digital, analog, and
snd-usb-audio drivers can use the media token resource API
using the main struct device for the interface the media device
is attached to.

A shared media tokens resource is created using devres framework
for drivers to find and lock/unlock. Creating a shared devres
helps avoid creating data structure dependencies between drivers.
This media token resource contains media token for tuner, and
audio. When tuner token is requested, audio token is issued.


Did you mean: 'tuner token is issued' instead of audio token?

I also have the same question as Takashi: why do we have an audio
token in the first place? While you are streaming audio over alsa
the underlying tuner must be marked as being in use. It's all about
the tuner, since that's the resource that is being shared, not about
audio as such.

For the remainder of my review I will ignore the audio-related code
and concentrate only on the tuner part.


Subsequent token (for tuner and audio) gets from the same task
and task in the same tgid succeed. This allows applications that
make multiple v4l2 ioctls to work with the first call acquiring
the token and applications that create separate threads to handle
video and audio functions.

Signed-off-by: Shuah Khan 
---
  MAINTAINERS  |2 +
  include/linux/media_tknres.h |   50 +
  lib/Makefile |2 +
  lib/media_tknres.c   |  237 ++


I am still not convinced myself that this should be a generic API.
The only reason we need it today is for sharing tuners. Which is almost
a purely media thing with USB audio as the single non-media driver that
will be affected. Today I see no use case outside of tuners. I would
probably want to keep this inside drivers/media.

If this is going to be expanded it can always be moved to lib later.


  4 files changed, 291 insertions(+)
  create mode 100644 include/linux/media_tknres.h
  create mode 100644 lib/media_tknres.c

diff --git a/MAINTAINERS b/MAINTAINERS
index e80a275..9216179 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5864,6 +5864,8 @@ F:include/uapi/linux/v4l2-*
  F:include/uapi/linux/meye.h
  F:include/uapi/linux/ivtv*
  F:include/uapi/linux/uvcvideo.h
+F: include/linux/media_tknres.h
+F: lib/media_tknres.c

  MEDIAVISION PRO MOVIE STUDIO DRIVER
  M:Hans Verkuil 
diff --git a/include/linux/media_tknres.h b/include/linux/media_tknres.h
new file mode 100644
index 000..6d37327
--- /dev/null
+++ b/include/linux/media_tknres.h
@@ -0,0 +1,50 @@
+/*
+ * media_tknres.h - managed media token resource
+ *
+ * Copyright (c) 2014 Shuah Khan 
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ *
+ * This file is released under the GPLv2.
+ */
+#ifndef __LINUX_MEDIA_TOKEN_H
+#define __LINUX_MEDIA_TOKEN_H
+
+struct device;
+
+#if defined(CONFIG_MEDIA_SUPPORT)
+extern int media_tknres_create(struct device *dev);
+extern int media_tknres_destroy(struct device *dev);
+
+extern int media_get_tuner_tkn(struct device *dev);
+extern int media_put_tuner_tkn(struct device *dev);
+
+extern int media_get_audio_tkn(struct device *dev);
+extern int media_put_audio_tkn(struct device *dev);
+#else
+static inline int media_tknres_create(struct device *dev)
+{
+   return 0;
+}
+static inline int media_tknres_destroy(struct device *dev)
+{
+   return 0;
+}
+static inline int media_get_tuner_tkn(struct device *dev)
+{
+   return 0;
+}
+static inline int media_put_tuner_tkn(struct device *dev)
+{
+   return 0;
+}
+static int media_get_audio_tkn(struct device *dev)
+{
+   return 0;
+}
+static int media_put_audio_tkn(struct device *dev)
+{
+   return 0;
+}
+#endif
+
+#endif /* __LINUX_MEDIA_TOKEN_H */
diff --git a/lib/Makefile b/lib/Makefile
index d6b4bc4..6f21695 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -139,6 +139,8 @@ obj-$(CONFIG_DQL) += dynamic_queue_limits.o

  obj-$(CONFIG_GLOB) += glob.o

+obj-$(CONFIG_MEDIA_SUPPORT) += media_tknres.o
+
  obj-$(CONFIG_MPILIB) += mpi/
  obj-$(CONFIG_SIGNATURE) += digsig.o

diff --git a/lib/media_tknres.c b/lib/media_tknres.c
new file mode 100644
index 000..e0a36cb
--- /dev/null
+++ b/lib/media_tknres.c
@@ -0,0 +1,237 @@
+/*
+ * media_tknres.c - managed media token resource
+ *
+ * Copyright (c) 2014 Shuah Khan 
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ *
+ * This file is released under the GPLv2.
+ */
+/*
+ * Media devices often have hardware resources that are

[v4l-utils RFC 2/2] mediatext: Add library

[Sakari Ailus]

libmediatext is a helper library for converting configurations (Media
controller links, V4L2 controls and V4L2 sub-device media bus formats and
selections) from text-based form into IOCTLs.

libmediatext depends on libv4l2subdev and libmediactl.

Signed-off-by: Sakari Ailus 
Signed-off-by: Teemu Tuominen 
---
 libmediatext.pc.in |  10 ++
 utils/media-ctl/Makefile.am|  10 +-
 utils/media-ctl/libmediatext.pc.in |  10 ++
 utils/media-ctl/mediatext-test.c   |  65 
 utils/media-ctl/mediatext.c| 210 +
 utils/media-ctl/mediatext.h|  29 +
 6 files changed, 332 insertions(+), 2 deletions(-)
 create mode 100644 libmediatext.pc.in
 create mode 100644 utils/media-ctl/libmediatext.pc.in
 create mode 100644 utils/media-ctl/mediatext-test.c
 create mode 100644 utils/media-ctl/mediatext.c
 create mode 100644 utils/media-ctl/mediatext.h

diff --git a/libmediatext.pc.in b/libmediatext.pc.in
new file mode 100644
index 000..6aa6353
--- /dev/null
+++ b/libmediatext.pc.in
@@ -0,0 +1,10 @@
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+libdir=@libdir@
+includedir=@includedir@
+
+Name: libmediatext
+Description: Media controller and V4L2 text-based configuration library
+Version: @PACKAGE_VERSION@
+Cflags: -I${includedir}
+Libs: -L${libdir} -lmediatext
diff --git a/utils/media-ctl/Makefile.am b/utils/media-ctl/Makefile.am
index a3931fb..3e883e0 100644
--- a/utils/media-ctl/Makefile.am
+++ b/utils/media-ctl/Makefile.am
@@ -1,4 +1,4 @@
-noinst_LTLIBRARIES = libmediactl.la libv4l2subdev.la
+noinst_LTLIBRARIES = libmediactl.la libv4l2subdev.la libmediatext.la
 
 libmediactl_la_SOURCES = libmediactl.c mediactl-priv.h
 libmediactl_la_CFLAGS = -static $(LIBUDEV_CFLAGS)
@@ -9,9 +9,15 @@ libv4l2subdev_la_LIBADD = libmediactl.la
 libv4l2subdev_la_CFLAGS = -static
 libv4l2subdev_la_LDFLAGS = -static
 
+libmediatext_la_SOURCES = mediatext.c
+libmediatext_la_CFLAGS = -static $(LIBUDEV_CFLAGS)
+libmediatext_la_LDFLAGS = -static $(LIBUDEV_LIBS)
+
 mediactl_includedir=$(includedir)/mediactl
 noinst_HEADERS = mediactl.h v4l2subdev.h
 
-bin_PROGRAMS = media-ctl
+bin_PROGRAMS = media-ctl mediatext-test
 media_ctl_SOURCES = media-ctl.c options.c options.h tools.h
 media_ctl_LDADD = libmediactl.la libv4l2subdev.la
+mediatext_test_SOURCES = mediatext-test.c
+mediatext_test_LDADD = libmediatext.la libmediactl.la libv4l2subdev.la
diff --git a/utils/media-ctl/libmediatext.pc.in 
b/utils/media-ctl/libmediatext.pc.in
new file mode 100644
index 000..6aa6353
--- /dev/null
+++ b/utils/media-ctl/libmediatext.pc.in
@@ -0,0 +1,10 @@
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+libdir=@libdir@
+includedir=@includedir@
+
+Name: libmediatext
+Description: Media controller and V4L2 text-based configuration library
+Version: @PACKAGE_VERSION@
+Cflags: -I${includedir}
+Libs: -L${libdir} -lmediatext
diff --git a/utils/media-ctl/mediatext-test.c b/utils/media-ctl/mediatext-test.c
new file mode 100644
index 000..296b8c0
--- /dev/null
+++ b/utils/media-ctl/mediatext-test.c
@@ -0,0 +1,65 @@
+/*
+ * libmediatext test program
+ *
+ * Copyright (C) 2013 Intel Corporation
+ *
+ * Contact: Sakari Ailus 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; either version 2.1 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public License
+ * along with this program. If not, see .
+ */
+
+#include 
+#include 
+#include 
+
+#include "mediactl.h"
+#include "mediatext.h"
+
+int main(int argc, char *argv[])
+{
+   struct media_device *device;
+   int rval;
+
+   if (argc != 3) {
+   fprintf(stderr, "usage: %s  \n\n", 
argv[0]);
+   fprintf(stderr, "\tstring := [ v4l2-ctrl |�v4l2-mbus | 
link-reset | link-conf]\n\n");
+   fprintf(stderr, "\tv4l2-ctrl := \"entity\" ctrl_type ctrl_id 
ctrl_value\n");
+   fprintf(stderr, "\tctrl_type := [ int | int64 | bitmask ]\n");
+   fprintf(stderr, "\tctrl_value := [ %%d | %%PRId64 | 
bitmask_value ]\n");
+   fprintf(stderr, "\tbitmask_value := b\n\n");
+   fprintf(stderr, "\tv4l2-mbus := \n");
+   fprintf(stderr, "\tlink-conf := \"entity\":pad -> 
\"entity\":pad[link-flags]\n");
+   return EXIT_FAILURE;
+   }
+
+   device = media_device_new(argv[1]);
+   if (!device)
+   return EXIT_FAILURE;
+
+   media_debug_set_handler(device, (void (*)(void *, ...))fprintf, stdout);
+
+   rval = media_device_enumerate

[v4l-utils RFC 1/2] mediactl: Separate entity and pad parsing

[Sakari Ailus]

Sometimes it's useful to be able to parse the entity independent of the pad.
Separate entity parsing into media_parse_entity().

Signed-off-by: Sakari Ailus 
---
 utils/media-ctl/libmediactl.c | 28 
 utils/media-ctl/mediactl.h| 14 ++
 2 files changed, 38 insertions(+), 4 deletions(-)

diff --git a/utils/media-ctl/libmediactl.c b/utils/media-ctl/libmediactl.c
index ec360bd..e17d86e 100644
--- a/utils/media-ctl/libmediactl.c
+++ b/utils/media-ctl/libmediactl.c
@@ -770,10 +770,10 @@ int media_device_add_entity(struct media_device *media,
return 0;
 }
 
-struct media_pad *media_parse_pad(struct media_device *media,
- const char *p, char **endp)
+struct media_entity *media_parse_entity(struct media_device *media,
+   const char *p, char **endp)
 {
-   unsigned int entity_id, pad;
+   unsigned int entity_id;
struct media_entity *entity;
char *end;
 
@@ -810,7 +810,27 @@ struct media_pad *media_parse_pad(struct media_device 
*media,
return NULL;
}
}
-   for (; isspace(*end); ++end);
+   for (p = end; isspace(*p); ++p);
+
+   *endp = (char *)p;
+
+   return entity;
+}
+
+struct media_pad *media_parse_pad(struct media_device *media,
+ const char *p, char **endp)
+{
+   unsigned int pad;
+   struct media_entity *entity;
+   char *end;
+
+   if (endp == NULL)
+   endp = &end;
+
+   entity = media_parse_entity(media, p, &end);
+   if (!entity)
+   return NULL;
+   *endp = end;
 
if (*end != ':') {
media_dbg(media, "Expected ':'\n", *end);
diff --git a/utils/media-ctl/mediactl.h b/utils/media-ctl/mediactl.h
index 77ac182..3faee71 100644
--- a/utils/media-ctl/mediactl.h
+++ b/utils/media-ctl/mediactl.h
@@ -368,6 +368,20 @@ int media_setup_link(struct media_device *media,
 int media_reset_links(struct media_device *media);
 
 /**
+ * @brief Parse string to an entity on the media device.
+ * @param media - media device.
+ * @param p - input string
+ * @param endp - pointer to string where parsing ended
+ *
+ * Parse NULL terminated string describing an entity and return its
+ * struct media_entity instance.
+ *
+ * @return Pointer to struct media_entity on success, NULL on failure.
+ */
+struct media_entity *media_parse_entity(struct media_device *media,
+   const char *p, char **endp);
+
+/**
  * @brief Parse string to a pad on the media device.
  * @param media - media device.
  * @param p - input string
-- 
2.1.0.231.g7484e3b

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

[v4l-utils RFC 0/2] libmediatext library

[Sakari Ailus]

Hi,

This is a tiny library for parsing text-based media link, V4L2 sub-device
format (and selection) configurations as well as controls with limited
types.

This is hardly ready as such but what's there should work.

-- 
Regards,
Sakari

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

Re: [PATCH v2] media: soc_camera: rcar_vin: Add BT.709 24-bit RGB888 input support

[Sergei Shtylyov]

Hello.

On 10/21/2014 9:08 AM, Yoshihiro Kaneko wrote:


From: Koji Matsuoka 



Signed-off-by: Koji Matsuoka 
Signed-off-by: Yoshihiro Kaneko 
---



This patch is against master branch of linuxtv.org/media_tree.git.



v2 [Yoshihiro Kaneko]
* remove unused/useless definition as suggested by Sergei Shtylyov


   I didn't say it's useless, I just suspected that you missed the necessary 
test somewhere...



  drivers/media/platform/soc_camera/rcar_vin.c | 9 +
  1 file changed, 9 insertions(+)



diff --git a/drivers/media/platform/soc_camera/rcar_vin.c 
b/drivers/media/platform/soc_camera/rcar_vin.c
index 20defcb..cb5e682 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -74,6 +74,7 @@
  #define VNMC_INF_YUV10_BT656  (2 << 16)
  #define VNMC_INF_YUV10_BT601  (3 << 16)
  #define VNMC_INF_YUV16(5 << 16)
+#define VNMC_INF_RGB888(6 << 16)
  #define VNMC_VUP  (1 << 10)
  #define VNMC_IM_ODD   (0 << 3)
  #define VNMC_IM_ODD_EVEN  (1 << 3)

[...]

@@ -331,6 +336,9 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
if (output_is_yuv)
vnmc |= VNMC_BPS;

+   if (vnmc & VNMC_INF_RGB888)
+   vnmc ^= VNMC_BPS;
+


   Hm, this also changes the behavior for VNMC_INF_YUV16 and 
VNMC_INF_YUV10_BT{601|656}. Is this actually intended?


[...]

WBR, Sergei

--
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/RFC v2 1/4] Add a media device configuration file parser.

[Jacek Anaszewski]

Hi Sakari,

On 10/21/2014 11:26 AM, Sakari Ailus wrote:

Hi Jacek,

On Tue, Oct 21, 2014 at 09:17:00AM +0200, Jacek Anaszewski wrote:
...

+ * The V4L2 control group format:
+ *
+ * v4l2-controls {
+ * : 
+ * : 
+ * ...
+ * : 
+ * }


I didn't know you were working on this.


Actually I did the main part of work around 1,5 year ago as a part
of familiarizing myself with V4L2 media controller API.


:-D

I think it's about time we get things like this to libv4l.


Definitely :)



I have a small library which does essentially the same. The implementation
is incomplete, that's why I hadn't posted it to the list. We could perhaps
discuss this a little bit tomorrow. When would you be available, in case you
are?


I will be available around 8 hours from now on.


I couldn't see you on #v4l, would an hour from now (13:30 Finnish time) be
ok for you?


What about 14:00 Finnish time?


What would you think of using a little bit more condensed format for this,
similar to that of libmediactl?



Could you spot a place where the format is defined?


At the moment there's none, but I thought of a similar format used by
libmediactl.


OK, to be discussed.

Best Regards,
Jacek Anaszewski

--
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/RFC v2 1/4] Add a media device configuration file parser.

[Sakari Ailus]

Hi Jacek,

On Tue, Oct 21, 2014 at 09:17:00AM +0200, Jacek Anaszewski wrote:
...
> >>+ * The V4L2 control group format:
> >>+ *
> >>+ * v4l2-controls {
> >>+ * : 
> >>+ * : 
> >>+ * ...
> >>+ * : 
> >>+ * }
> >
> >I didn't know you were working on this.
> 
> Actually I did the main part of work around 1,5 year ago as a part
> of familiarizing myself with V4L2 media controller API.

:-D

I think it's about time we get things like this to libv4l.

> >
> >I have a small library which does essentially the same. The implementation
> >is incomplete, that's why I hadn't posted it to the list. We could perhaps
> >discuss this a little bit tomorrow. When would you be available, in case you
> >are?
> 
> I will be available around 8 hours from now on.

I couldn't see you on #v4l, would an hour from now (13:30 Finnish time) be
ok for you?

> >What would you think of using a little bit more condensed format for this,
> >similar to that of libmediactl?
> >
> 
> Could you spot a place where the format is defined?

At the moment there's none, but I thought of a similar format used by
libmediactl.

-- 
Cheers,

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

Re: [PATCH v2 07/14] [media] s5p-mfc: Don't crash the kernel if the watchdog kicks in.

[Arun Kumar K]

Hi Kamil,

Kiran will not be available to handle review comments of these patches.
So I will be pushing the updated patchset rebased on media-tree.

I hope all patches are good to merge except
[media] s5p-mfc: Don't change the image size to smaller than the request.

I will drop this one patch and send all others in v3 version.

Regards
Arun

On Wed, Oct 8, 2014 at 3:56 PM, Kamil Debski  wrote:
> Hi,
>
> This patch does not apply to the current media tree.
>
> commit cf3167cf1e969b17671a4d3d956d22718a8ceb85)
> Author: Antti Palosaari 
> Date:   Fri Sep 26 22:45:36 2014 -0300
>
> [media] pt3: fix DTV FE I2C driver load error paths
>
> Best wishes,
> --
> Kamil Debski
> Samsung R&D Institute Poland
>
>
>> -Original Message-
>> From: Kiran AVND [mailto:avnd.ki...@samsung.com]
>> Sent: Friday, September 26, 2014 6:52 AM
>> To: linux-media@vger.kernel.org
>> Cc: k.deb...@samsung.com; wuchen...@chromium.org; posc...@chromium.org;
>> aru...@samsung.com; i...@chromium.org; prathyus...@samsung.com;
>> arun...@samsung.com; ki...@chromium.org
>> Subject: [PATCH v2 07/14] [media] s5p-mfc: Don't crash the kernel if
>> the watchdog kicks in.
>>
>> From: Pawel Osciak 
>>
>> If the software watchdog kicks in, the watchdog worker is not
>> synchronized with hardware interrupts and does not block other
>> instances. It's possible for it to clear the hw_lock, making other
>> instances trigger a BUG() on hw_lock checks. Since it's not fatal to
>> clear the hw_lock to zero twice, just WARN in those cases for now. We
>> should not explode, as firmware will return errors as needed for other
>> instances after it's reloaded, or they will time out.
>>
>> A clean fix should involve killing other instances when watchdog kicks
>> in, but requires a major redesign of locking in the driver.
>>
>> Signed-off-by: Pawel Osciak 
>> Signed-off-by: Kiran AVND 
>> ---
>>  drivers/media/platform/s5p-mfc/s5p_mfc.c |   25 +++---
>> ---
>>  1 file changed, 7 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
>> b/drivers/media/platform/s5p-mfc/s5p_mfc.c
>> index 3fc2f8a..8d5da0c 100644
>> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
>> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
>> @@ -337,8 +337,7 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx
>> *ctx,
>>   ctx->state = MFCINST_RES_CHANGE_INIT;
>>   s5p_mfc_hw_call(dev->mfc_ops, clear_int_flags, dev);
>>   wake_up_ctx(ctx, reason, err);
>> - if (test_and_clear_bit(0, &dev->hw_lock) == 0)
>> - BUG();
>> + WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0);
>>   s5p_mfc_clock_off();
>>   s5p_mfc_hw_call(dev->mfc_ops, try_run, dev);
>>   return;
>> @@ -410,8 +409,7 @@ leave_handle_frame:
>>   clear_work_bit(ctx);
>>   s5p_mfc_hw_call(dev->mfc_ops, clear_int_flags, dev);
>>   wake_up_ctx(ctx, reason, err);
>> - if (test_and_clear_bit(0, &dev->hw_lock) == 0)
>> - BUG();
>> + WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0);
>>   s5p_mfc_clock_off();
>>   /* if suspending, wake up device and do not try_run again*/
>>   if (test_bit(0, &dev->enter_suspend))
>> @@ -458,8 +456,7 @@ static void s5p_mfc_handle_error(struct s5p_mfc_dev
>> *dev,
>>   break;
>>   }
>>   }
>> - if (test_and_clear_bit(0, &dev->hw_lock) == 0)
>> - BUG();
>> + WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0);
>>   s5p_mfc_hw_call(dev->mfc_ops, clear_int_flags, dev);
>>   s5p_mfc_clock_off();
>>   wake_up_dev(dev, reason, err);
>> @@ -513,8 +510,7 @@ static void s5p_mfc_handle_seq_done(struct
>> s5p_mfc_ctx *ctx,
>>   }
>>   s5p_mfc_hw_call(dev->mfc_ops, clear_int_flags, dev);
>>   clear_work_bit(ctx);
>> - if (test_and_clear_bit(0, &dev->hw_lock) == 0)
>> - BUG();
>> + WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0);
>>   s5p_mfc_clock_off();
>>   s5p_mfc_hw_call(dev->mfc_ops, try_run, dev);
>>   wake_up_ctx(ctx, reason, err);
>> @@ -552,19 +548,13 @@ static void s5p_mfc_handle_init_buffers(struct
>> s5p_mfc_ctx *ctx,
>>   } else {
>>   ctx->dpb_flush_flag = 0;
>>   }
>> - if (test_and_clear_bit(0, &dev->hw_lock) == 0)
>> - BUG();
>> -
>> + WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0);
>>   s5p_mfc_clock_off();
>> -
>>   wake_up(&ctx->queue);
>>   s5p_mfc_hw_call(dev->mfc_ops, try_run, dev);
>>   } else {
>> - if (test_and_clear_bit(0, &dev->hw_lock) == 0)
>> - BUG();
>> -
>> + WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0);
>>   s5p_mfc_clock_off();
>> -
>>   wake_up(&ctx->queue);
>>   }
>>  }
>> @@ -638,8 +628,7 @@ static irqreturn_t s5p_mfc_irq(int irq, void *

Re: [PATCH/RFC v2 1/4] Add a media device configuration file parser.

[Jacek Anaszewski]

Hi Sakari,

On 10/20/2014 11:44 PM, Sakari Ailus wrote:

Hi Jacek,

On Fri, Oct 17, 2014 at 04:54:39PM +0200, Jacek Anaszewski wrote:

This patch adds a parser for a media device configuration
file. The parser expects the configuration file containing
links end v4l2-controls definitions as described in the
header file being added. The links describe connections
between media entities and v4l2-controls define the target
sub-devices for particular user controls related ioctl calls.

Signed-off-by: Jacek Anaszewski 
Acked-by: Kyungmin Park 
Cc: Mauro Carvalho Chehab 
Cc: Hans Verkuil 
---
  lib/include/libv4l2-media-conf-parser.h |  148 +++
  lib/libv4l2/libv4l2-media-conf-parser.c |  441 +++
  2 files changed, 589 insertions(+)
  create mode 100644 lib/include/libv4l2-media-conf-parser.h
  create mode 100644 lib/libv4l2/libv4l2-media-conf-parser.c

diff --git a/lib/include/libv4l2-media-conf-parser.h 
b/lib/include/libv4l2-media-conf-parser.h
new file mode 100644
index 000..b2dba3a
--- /dev/null
+++ b/lib/include/libv4l2-media-conf-parser.h
@@ -0,0 +1,148 @@
+/*
+ * Parser of media device configuration file.
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ *  http://www.samsung.com
+ *
+ * Author: Jacek Anaszewski 
+ *
+ * The configuration file has to comply with following format:
+ *
+ * Link description entry format:
+ *
+ * link {
+ * source_entity: 
+ * source_pad: 
+ * sink_entity: 
+ * sink_pad: 
+ * }


Could you use the existing libmediactl format? The parser exists as well.


Of course, I will switch to using it.


As a matter of fact, I have a few patches to make it easier to user in a
library.

libmediactl appears to be located under utils/media-ctl. Perhaps it's be
better placed under lib. Cc Laurent.


+ * The V4L2 control group format:
+ *
+ * v4l2-controls {
+ * : 
+ * : 
+ * ...
+ * : 
+ * }


I didn't know you were working on this.


Actually I did the main part of work around 1,5 year ago as a part
of familiarizing myself with V4L2 media controller API.



I have a small library which does essentially the same. The implementation
is incomplete, that's why I hadn't posted it to the list. We could perhaps
discuss this a little bit tomorrow. When would you be available, in case you
are?


I will be available around 8 hours from now on.


What would you think of using a little bit more condensed format for this,
similar to that of libmediactl?



Could you spot a place where the format is defined?

Best Regards,
Jacek Anaszewski

--
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: soc_camera: rcar_vin: Enable VSYNC field toggle mode

[Geert Uytterhoeven]

Hi Kaneko-san,

On Tue, Oct 21, 2014 at 5:30 AM, Yoshihiro Kaneko  wrote:
>>> --- a/drivers/media/platform/soc_camera/rcar_vin.c
>>> +++ b/drivers/media/platform/soc_camera/rcar_vin.c
>>> @@ -108,6 +108,7 @@
>>>   #define VNDMR2_VPS(1 << 30)
>>>   #define VNDMR2_HPS(1 << 29)
>>>   #define VNDMR2_FTEV   (1 << 17)
>>> +#define VNDMR2_VLV_1   (1 << 12)
>>
>>Please instead do:
>>
>> #define VNDMR2_VLV(n)   ((n & 0xf) << 12)
>
> It's unclear to me why the style of the new #define should differ
> from those of the existing ones.

I think Sergey wants to say that unlike for the other fields, there are
multiple possible values for the VLV field.

By providing the single macro definition

#define VNDMR2_VLV(n)   ((n & 0xf) << 12)

you can easily provide a way to set any of VNDMR2_VLV_n.

I hope this explanation makes it clearer.

Gr{oetje,eeting}s,

Geert

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

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