Re: [PATCH 01/12] trivial: drivers/media/usb/gspca/gspca.c: fix the indentation of a comment

[Antonio Ospite]

On Wed,  4 Jun 2014 14:03:39 +0200
Antonio Ospite  wrote:

> Fix indentation of a comment, put it on the same level of the code it
> refers to.
>
> Signed-off-by: Antonio Ospite 
> Cc: Hans de Goede 
> Cc: linux-media@vger.kernel.org

Ping, I cannot see this in any upstream repository.
Here is the linux-media patchwork link:
https://patchwork.linuxtv.org/patch/24155/

Thanks,
   Antonio

> ---
>  drivers/media/usb/gspca/gspca.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/usb/gspca/gspca.c b/drivers/media/usb/gspca/gspca.c
> index f3a7ace..f4bae98 100644
> --- a/drivers/media/usb/gspca/gspca.c
> +++ b/drivers/media/usb/gspca/gspca.c
> @@ -870,9 +870,8 @@ static int gspca_init_transfer(struct gspca_dev 
> *gspca_dev)
>   ep_tb[0].alt = gspca_dev->alt;
>   alt_idx = 1;
>   } else {
> -
> - /* else, compute the minimum bandwidth
> -  * and build the endpoint table */
> + /* else, compute the minimum bandwidth
> +  * and build the endpoint table */
>   alt_idx = build_isoc_ep_tb(gspca_dev, intf, ep_tb);
>   if (alt_idx <= 0) {
>   pr_err("no transfer endpoint found\n");
> -- 
> 2.0.0
> 
> 


-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
--
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 02/12] trivial: drivers/media/usb/gspca/gspca.h: indent with TABs, not spaces

[Antonio Ospite]

On Wed,  4 Jun 2014 14:03:40 +0200
Antonio Ospite  wrote:

> Signed-off-by: Antonio Ospite 
> Cc: Hans de Goede 
> Cc: linux-media@vger.kernel.org

Ping.
linux-media patchwork link:
https://patchwork.linuxtv.org/patch/24156/

Thanks,
   Antonio

> ---
>  drivers/media/usb/gspca/gspca.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/usb/gspca/gspca.h b/drivers/media/usb/gspca/gspca.h
> index 300642d..c1273e5 100644
> --- a/drivers/media/usb/gspca/gspca.h
> +++ b/drivers/media/usb/gspca/gspca.h
> @@ -234,6 +234,6 @@ int gspca_resume(struct usb_interface *intf);
>  int gspca_expo_autogain(struct gspca_dev *gspca_dev, int avg_lum,
>   int desired_avg_lum, int deadzone, int gain_knee, int exposure_knee);
>  int gspca_coarse_grained_expo_autogain(struct gspca_dev *gspca_dev,
> -int avg_lum, int desired_avg_lum, int deadzone);
> + int avg_lum, int desired_avg_lum, int deadzone);
>  
>  #endif /* GSPCAV2_H */
> -- 
> 2.0.0
> 


-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
--
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: HVR 900 (USB ID 2040:6500) no analogue sound reloaded

[Oravecz Csaba]

Sun Aug 31 17:07:00 2014 =?windows-1252?Q?Frank_Sch=E4fer?= kirjutas:
> 
> 
> Am 22.08.2014 um 21:03 schrieb Oravecz Csaba:
> > I reported this issue earlier but for some reason it went pretty much
> > unnoticed. The essence is that with the newest em28xx drivers now present in
> > 3.14 kernels (i'm on stock fedora 3.14.15-100.fc19.i686.PAE) I can't get
> > analogue sound from this card.
> >
> > I see that the code snippet that produced this output in the pre 3.14 
> > versions
> >
> > em2882/3 #0: Config register raw data: 0x50
> > em2882/3 #0: AC97 vendor ID = 0x
> > em2882/3 #0: AC97 features = 0x6a90
> > em2882/3 #0: Empia 202 AC97 audio processor detected
> >
> > is still there in em28xx-core.c, however, there is nothing like that in
> > current kernel logs so it seems that this part of the code is just skipped,
> > which I tend to think is not the intended behaviour. I have not gone any
> > further to investigate the issue, rather I've simply copied the 'old' em28xx
> 
> Thank you for reporting this issue.
> I suspect reverting commit b99f0aadd3 "[media] em28xx: check if a device
> has audio earlier" will resolve it.
> Can you check that ?

Yes, that has indeed solved the problem. I assume this will slowly propagate
into the mainstraim distros, in the meantime i can happily use the custom
compiled reverted drivers.
Thanks,
o.cs.


--
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: s5p-mfc should allow multiple call to REQBUFS before we start streaming

[Kamil Debski]

Hi Nicolas,


> From: Nicolas Dufresne [mailto:nicolas.dufre...@collabora.com]
> Sent: Friday, August 29, 2014 3:47 PM
> 
> Hi Kamil,
> 
> after a discussion on IRC, we concluded that s5p-mfc have this bug that
> disallow multiple reqbufs calls before streaming. This has the impact
> that it forces to call REQBUFS(0) before setting the new number of
> buffers during re-negotiation, and is against the spec too.

I was out of office last week. Could you shed more light on this subject?
Do you have the irc log?

> As an example, in reqbufs_output() REQBUFS is only allowed in
> QUEUE_FREE state, and setting buffers exits this state. We think that
> the call to
>  electrons.com/ident?i=reqbufs_output>s5p_mfc_open_mfc_inst()
> should be post-poned until STREAMON is called.
> 

How is this connected to the renegotiation scenario?
Are you sure you wanted to mention s5p_mfc_open_mfc_inst?
 
> cheers,
> Nicolas
> 

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 4/5] tc90522: add driver for Toshiba TC90522 quad demodulator

[Akihiro TSUKADA]

Hi,

> Also, I would like to see all new drivers (demod and tuner) implemented
> as a standard kernel I2C drivers (or any other bus). I have converted
> already quite many drivers, si2168, si2157, m88ds3103, m88ts2022,
> it913x, tda18212, ...

I wrote the code in the old style using dvb_attach()
because (I felt) it is simpler than using i2c_new_device() by
introducing new i2c-related data structures,
registering to both dvb and i2c, without any new practical
features that i2c client provides.

But if the use of dvb_attach() is (almost) deprecated and
i2c client driver is the standard/prefered way,
I'll convert my code.

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

Re: [PATCH v2 2/2] adv7604: Use DT parsing in dummy creation

[Jean-Michel Hautbois]

2014-08-31 19:18 GMT+02:00 Laurent Pinchart :
> Hi Jean-Michel,
>
> Thank you for the patch.
>
> On Friday 29 August 2014 17:15:03 Jean-Michel Hautbois wrote:
>> This patch uses DT in order to parse addresses for dummy devices of adv7604.
>> The ADV7604 has thirteen 256-byte maps that can be accessed via the main
>> I²C ports. Each map has it own I²C address and acts
>> as a standard slave device on the I²C bus.
>>
>> If nothing is defined, it uses default addresses.
>> The main prupose is using two adv76xx on the same i2c bus.
>>
>> Signed-off-by: Jean-Michel Hautbois 
>> ---
>>  .../devicetree/bindings/media/i2c/adv7604.txt  | 17 +-
>>  drivers/media/i2c/adv7604.c| 60 ---
>>  2 files changed, 55 insertions(+), 22 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
>> b/Documentation/devicetree/bindings/media/i2c/adv7604.txt index
>> c27cede..8486b5c 100644
>> --- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
>> +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
>> @@ -10,8 +10,12 @@ Required Properties:
>>
>>- compatible: Must contain one of the following
>>  - "adi,adv7611" for the ADV7611
>> +- "adi,adv7604" for the ADV7604
>
> Addition of ADV7604 support is unrelated to the subject and needs to be split
> into a separate patch.

OK, I will do that.

>> -  - reg: I2C slave address
>> +  - reg: I2C slave addresses
>> +The ADV7604 has thirteen 256-byte maps that can be accessed via the
>> main
>> +I²C ports. Each map has it own I²C address and acts
>> +as a standard slave device on the I²C bus.
>>
>>- hpd-gpios: References to the GPIOs that control the HDMI hot-plug
>>  detection pins, one per HDMI input. The active flag indicates the GPIO
>> @@ -32,6 +36,12 @@ The digital output port node must contain at least one
>> endpoint. Optional Properties:
>>
>>- reset-gpios: Reference to the GPIO connected to the device's reset pin.
>> +  - reg-names : Names of maps with programmable addresses.
>> + It can contain any map needing another address than default 
>> one.
>> + Possible maps names are :
>> +ADV7604 : "main", "avlink", "cec", "infoframe", "esdp", "dpp", "afe",
>> "rep",
>> + "edid", "hdmi", "test", "cp", "vdp"
>> +ADV7611 : "main", "cec", "infoframe", "afe", "rep", "edid", "hdmi", "cp"
>>
>>  Optional Endpoint Properties:
>>
>> @@ -50,7 +60,10 @@ Example:
>>
>>   hdmi_receiver@4c {
>>   compatible = "adi,adv7611";
>> - reg = <0x4c>;
>> + /* edid page will be accessible @ 0x66 on i2c bus */
>> + /* other maps keep their default addresses */
>> + reg = <0x4c 0x66>;
>> + reg-names = "main", "edid";
>>
>>   reset-gpios = <&ioexp 0 GPIO_ACTIVE_LOW>;
>>   hpd-gpios = <&ioexp 2 GPIO_ACTIVE_HIGH>;
>> diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
>> index d4fa213..56037dd 100644
>> --- a/drivers/media/i2c/adv7604.c
>> +++ b/drivers/media/i2c/adv7604.c
>> @@ -326,6 +326,22 @@ static const struct adv7604_video_standards
>> adv7604_prim_mode_hdmi_gr[] = { { },
>>  };
>>
>> +static const char const *adv7604_secondary_names[] = {
>> + "main", /* ADV7604_PAGE_IO */
>> + "avlink", /* ADV7604_PAGE_AVLINK */
>> + "cec", /* ADV7604_PAGE_CEC */
>> + "infoframe", /* ADV7604_PAGE_INFOFRAME */
>> + "esdp", /* ADV7604_PAGE_ESDP */
>> + "dpp", /* ADV7604_PAGE_DPP */
>> + "afe", /* ADV7604_PAGE_AFE */
>> + "rep", /* ADV7604_PAGE_REP */
>> + "edid", /* ADV7604_PAGE_EDID */
>> + "hdmi", /* ADV7604_PAGE_HDMI */
>> + "test", /* ADV7604_PAGE_TEST */
>> + "cp", /* ADV7604_PAGE_CP */
>> + "vdp" /* ADV7604_PAGE_VDP */
>> +};
>> +
>>  /* ---
>> */
>>
>>  static inline struct adv7604_state *to_state(struct v4l2_subdev *sd)
>> @@ -2528,13 +2544,31 @@ static void adv7604_unregister_clients(struct
>> adv7604_state *state) }
>>
>>  static struct i2c_client *adv7604_dummy_client(struct v4l2_subdev *sd,
>> - u8 addr, u8 io_reg)
>> + unsigned int i)
>>  {
>>   struct i2c_client *client = v4l2_get_subdevdata(sd);
>> + struct adv7604_platform_data *pdata = client->dev.platform_data;
>> + unsigned int io_reg = 0xf2 + i;
>> + unsigned int default_addr = io_read(sd, io_reg) >> 1;
>
> This modifies the behaviour of the driver. It previously used fixed default
> addresses in the DT case, and now defaults to whatever has been programmed in
> the chip. This might not be an issue in itself, but it should be documented in
> the commit message (and possibly split to a separate patch).

Then, let's decide if this is a problem or not :) ? I naively thought
that it would be good to have default address, if defined in platform
data, 

[PATCH 3/4] s5p-jpeg: avoid overwriting JPEG_CNTL register settings

[Jacek Anaszewski]

Take into account the JPEG_CNTL register value read before
setting SYS_INT_EN bit field.

Signed-off-by: Jacek Anaszewski 
---
 drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c 
b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
index 2de81c7..d9ce40f 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
@@ -193,9 +193,9 @@ void exynos4_jpeg_set_sys_int_enable(void __iomem *base, 
int value)
reg = readl(base + EXYNOS4_JPEG_CNTL_REG) & ~(EXYNOS4_SYS_INT_EN);
 
if (value == 1)
-   writel(EXYNOS4_SYS_INT_EN, base + EXYNOS4_JPEG_CNTL_REG);
+   writel(reg | EXYNOS4_SYS_INT_EN, base + EXYNOS4_JPEG_CNTL_REG);
else
-   writel(~EXYNOS4_SYS_INT_EN, base + EXYNOS4_JPEG_CNTL_REG);
+   writel(reg & ~EXYNOS4_SYS_INT_EN, base + EXYNOS4_JPEG_CNTL_REG);
 }
 
 void exynos4_jpeg_set_stream_buf_address(void __iomem *base,
-- 
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 2/4] s5p-jpeg: remove stray call to readl

[Jacek Anaszewski]

There is no need to read INT_EN_REG before enabling interrupts.

Signed-off-by: Jacek Anaszewski 
---
 drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c |3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c 
b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
index da8d6a1..2de81c7 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
@@ -151,9 +151,6 @@ void exynos4_jpeg_set_enc_out_fmt(void __iomem *base, 
unsigned int out_fmt)
 
 void exynos4_jpeg_set_interrupt(void __iomem *base)
 {
-   unsigned int reg;
-
-   reg = readl(base + EXYNOS4_INT_EN_REG) & ~EXYNOS4_INT_EN_MASK;
writel(EXYNOS4_INT_EN_ALL, base + EXYNOS4_INT_EN_REG);
 }
 
-- 
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 1/4] s5p-jpeg: Avoid assigning readl result

[Jacek Anaszewski]

Avoid gcc warning when -Wunused-but-set-variable is enabled.
The readl return value need not to be assigned to any variable
as the reading itself is just a part of a sequence required
for clearing the interrupt flag.

Signed-off-by: Jacek Anaszewski 
---
 drivers/media/platform/s5p-jpeg/jpeg-hw-s5p.c |6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-s5p.c 
b/drivers/media/platform/s5p-jpeg/jpeg-hw-s5p.c
index 52407d7..e3b8e67 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-hw-s5p.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-s5p.c
@@ -324,11 +324,9 @@ int s5p_jpeg_stream_stat_ok(void __iomem *regs)
 
 void s5p_jpeg_clear_int(void __iomem *regs)
 {
-   unsigned long reg;
-
-   reg = readl(regs + S5P_JPGINTST);
+   readl(regs + S5P_JPGINTST);
writel(S5P_INT_RELEASE, regs + S5P_JPGCOM);
-   reg = readl(regs + S5P_JPGOPR);
+   readl(regs + S5P_JPGOPR);
 }
 
 unsigned int s5p_jpeg_compressed_size(void __iomem *regs)
-- 
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 4/4] s5p-jpeg: fix HUF_TBL_EN bit clearing path

[Jacek Anaszewski]

Use proper bitwise operator while clearing HUF_TBL_EN bit.

Signed-off-by: Jacek Anaszewski 
---
 drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c 
b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
index d9ce40f..e51c078 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
@@ -182,7 +182,7 @@ void exynos4_jpeg_set_huf_table_enable(void __iomem *base, 
int value)
writel(reg | EXYNOS4_HUF_TBL_EN,
base + EXYNOS4_JPEG_CNTL_REG);
else
-   writel(reg | ~EXYNOS4_HUF_TBL_EN,
+   writel(reg & ~EXYNOS4_HUF_TBL_EN,
base + EXYNOS4_JPEG_CNTL_REG);
 }
 
-- 
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] v4l: vsp1: fix driver dependencies

[Bartlomiej Zolnierkiewicz]

Renesas VSP1 Video Processing Engine support should be available
only on Renesas ARM SoCs.

Signed-off-by: Bartlomiej Zolnierkiewicz 
Acked-by: Kyungmin Park 
Cc: Simon Horman 
Cc: Magnus Damm 
---
 drivers/media/platform/Kconfig |1 +
 1 file changed, 1 insertion(+)

Index: b/drivers/media/platform/Kconfig
===
--- a/drivers/media/platform/Kconfig2014-09-01 14:51:37.024553544 +0200
+++ b/drivers/media/platform/Kconfig2014-09-01 15:17:34.284594657 +0200
@@ -213,6 +213,7 @@ config VIDEO_SH_VEU
 config VIDEO_RENESAS_VSP1
tristate "Renesas VSP1 Video Processing Engine"
depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && HAS_DMA
+   depends on ARCH_SHMOBILE || COMPILE_TEST
select VIDEOBUF2_DMA_CONTIG
---help---
  This is a V4L2 driver for the Renesas VSP1 video processing engine.

--
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] videobuf: Allow reqbufs(0) to free current buffers

[Hans Verkuil]

Hi Hans,

At first glance this looks fine. But making changes in videobuf is always scary 
:-)
so I hope Marek can look at this as well.

How well was this tested?

I'll try do test this as well.

Regards,

Hans

On 08/31/2014 12:19 PM, Hans de Goede wrote:
> All the infrastructure for this is already there, and despite our desires for
> the old videobuf code to go away, it is currently still in use in 18 drivers.
> 
> Allowing reqbufs(0) makes these drivers behave consistent with modern drivers,
> making live easier for userspace, see e.g. :
> https://bugzilla.gnome.org/show_bug.cgi?id=735660
> 
> Signed-off-by: Hans de Goede 
> ---
>  drivers/media/v4l2-core/videobuf-core.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/videobuf-core.c 
> b/drivers/media/v4l2-core/videobuf-core.c
> index fb5ee5d..b91a266 100644
> --- a/drivers/media/v4l2-core/videobuf-core.c
> +++ b/drivers/media/v4l2-core/videobuf-core.c
> @@ -441,11 +441,6 @@ int videobuf_reqbufs(struct videobuf_queue *q,
>   unsigned int size, count;
>   int retval;
>  
> - if (req->count < 1) {
> - dprintk(1, "reqbufs: count invalid (%d)\n", req->count);
> - return -EINVAL;
> - }
> -
>   if (req->memory != V4L2_MEMORY_MMAP &&
>   req->memory != V4L2_MEMORY_USERPTR  &&
>   req->memory != V4L2_MEMORY_OVERLAY) {
> @@ -471,6 +466,12 @@ int videobuf_reqbufs(struct videobuf_queue *q,
>   goto done;
>   }
>  
> + if (req->count == 0) {
> + dprintk(1, "reqbufs: count invalid (%d)\n", req->count);
> + retval = __videobuf_free(q);
> + goto done;
> + }
> +
>   count = req->count;
>   if (count > VIDEO_MAX_FRAME)
>   count = VIDEO_MAX_FRAME;
> 

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

[PULL patches for 3.18]: 2 gspca cleanup patches

[Hans de Goede]

Hi Mauro,

Please pull from my tree for 2 minor gspca cleanup patches:

The following changes since commit b250392f7b5062cf026b1423e27265e278fd6b30:

  [media] media: ttpci: fix av7110 build to be compatible with 
CONFIG_INPUT_EVDEV (2014-08-21 15:25:38 -0500)

are available in the git repository at:

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

for you to fetch changes up to 9f1b73b7a113e7b6d01d6cfe1cb5146be9b04088:

  trivial: drivers/media/usb/gspca/gspca.h: indent with TABs, not spaces 
(2014-09-01 16:14:25 +0200)


Antonio Ospite (2):
  trivial: drivers/media/usb/gspca/gspca.c: fix the indentation of a comment
  trivial: drivers/media/usb/gspca/gspca.h: indent with TABs, not spaces

 drivers/media/usb/gspca/gspca.c | 5 ++---
 drivers/media/usb/gspca/gspca.h | 2 +-
 2 files changed, 3 insertions(+), 4 deletions(-)

Thanks & Regards,

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

Re: [PATCH] videobuf: Allow reqbufs(0) to free current buffers

[Hans de Goede]

Hi,

On 09/01/2014 03:29 PM, Hans Verkuil wrote:
> Hi Hans,
> 
> At first glance this looks fine. But making changes in videobuf is always 
> scary :-)
> so I hope Marek can look at this as well.
> 
> How well was this tested?

I ran some tests on bttv which all ran well.

Note that the code already allowed for going from say 4 buffers to 1,
and the old code path for reqbufs was already calling __videobuf_free()
before re-allocating the buffers again. So in essence this just changes
things to allow the 4 buffers to 1 case to also be 4 buffers to 0.

Regards,

Hans


> 
> I'll try do test this as well.
> 
> Regards,
> 
>   Hans
> 
> On 08/31/2014 12:19 PM, Hans de Goede wrote:
>> All the infrastructure for this is already there, and despite our desires for
>> the old videobuf code to go away, it is currently still in use in 18 drivers.
>>
>> Allowing reqbufs(0) makes these drivers behave consistent with modern 
>> drivers,
>> making live easier for userspace, see e.g. :
>> https://bugzilla.gnome.org/show_bug.cgi?id=735660
>>
>> Signed-off-by: Hans de Goede 
>> ---
>>  drivers/media/v4l2-core/videobuf-core.c | 11 ++-
>>  1 file changed, 6 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/media/v4l2-core/videobuf-core.c 
>> b/drivers/media/v4l2-core/videobuf-core.c
>> index fb5ee5d..b91a266 100644
>> --- a/drivers/media/v4l2-core/videobuf-core.c
>> +++ b/drivers/media/v4l2-core/videobuf-core.c
>> @@ -441,11 +441,6 @@ int videobuf_reqbufs(struct videobuf_queue *q,
>>  unsigned int size, count;
>>  int retval;
>>  
>> -if (req->count < 1) {
>> -dprintk(1, "reqbufs: count invalid (%d)\n", req->count);
>> -return -EINVAL;
>> -}
>> -
>>  if (req->memory != V4L2_MEMORY_MMAP &&
>>  req->memory != V4L2_MEMORY_USERPTR  &&
>>  req->memory != V4L2_MEMORY_OVERLAY) {
>> @@ -471,6 +466,12 @@ int videobuf_reqbufs(struct videobuf_queue *q,
>>  goto done;
>>  }
>>  
>> +if (req->count == 0) {
>> +dprintk(1, "reqbufs: count invalid (%d)\n", req->count);
>> +retval = __videobuf_free(q);
>> +goto done;
>> +}
>> +
>>  count = req->count;
>>  if (count > VIDEO_MAX_FRAME)
>>  count = VIDEO_MAX_FRAME;
>>
> 
--
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: s5p-mfc should allow multiple call to REQBUFS before we start streaming

[Nicolas Dufresne]

Le 2014-09-01 05:43, Kamil Debski a écrit :

Hi Nicolas,



From: Nicolas Dufresne [mailto:nicolas.dufre...@collabora.com]
Sent: Friday, August 29, 2014 3:47 PM

Hi Kamil,

after a discussion on IRC, we concluded that s5p-mfc have this bug that
disallow multiple reqbufs calls before streaming. This has the impact
that it forces to call REQBUFS(0) before setting the new number of
buffers during re-negotiation, and is against the spec too.

I was out of office last week. Could you shed more light on this subject?
Do you have the irc log?


Sorry I didn't record this one, but feel free to ping Hans V.

As an example, in reqbufs_output() REQBUFS is only allowed in
QUEUE_FREE state, and setting buffers exits this state. We think that
the call to
s5p_mfc_open_mfc_inst()
should be post-poned until STREAMON is called.


How is this connected to the renegotiation scenario?
Are you sure you wanted to mention s5p_mfc_open_mfc_inst?
This limitation in MFC causes an important conflict between old videobuf 
and new videobuf2 drivers. Old videobuf driver (before Hans G. proposed 
patch) refuse REQBUFS(0). As MFC code has this bug that refuse 
REBBUFS(N) if buffers are already allocated, it makes all this 
completely incompatible. This open_mfc call seems to be the only reason 
REQBUFS() cannot be called multiple time, though I must say you are 
better placed then me to figure this out.


cheers,
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] v4l: vsp1: fix driver dependencies

[Geert Uytterhoeven]

On Mon, Sep 1, 2014 at 3:18 PM, Bartlomiej Zolnierkiewicz
 wrote:
> Renesas VSP1 Video Processing Engine support should be available
> only on Renesas ARM SoCs.

Thanks!

> Signed-off-by: Bartlomiej Zolnierkiewicz 
> Acked-by: Kyungmin Park 
> Cc: Simon Horman 
> Cc: Magnus Damm 

Acked-by: Geert Uytterhoeven 

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

sale cisco switches

[AMY]

HI
We sale cisco new and original switches and routers, following is   the product 
and price list.
If you are interested, please contact me!
WS-C3750X-24S-S  
WS-C3750X-48P-S  
WS-C2960S-24TS-L  
WS-C2960S-48TS-L  
WS-C2960S-48LPS-L  
WS-C2960S-48FPS-L  
WS-C2960S-48LPD-L  
WS-C2960S-48FPD-L 
MY SKYPE ID:AMY122388
REGARD.
AMY

Re: strange empia device

[Frank Schäfer]

Am 31.08.2014 um 17:41 schrieb Lorenzo Marcantonio:
> On Sun, Aug 31, 2014 at 04:50:08PM +0200, Frank Schäfer wrote:
>> Hmm... could you send us the output of "lsusb -v -d 1b80:e31d ?
> Sure, here is it. However it seems that roxio violated the most sacred
> USB rule (i.e. they use that vid/pid for two different kinds of
> hardware); 
What's the other device using this vid:pid and which hardware does it use ?

> in fact even people on Windows have troubles with it (and
> a guaranteed blue screen on Win8, it seems :D)
>
> I already had some experience in reverse engineering a webcam (in fact
> I even 'patched' the 8051 firmware and fully disassembled the win driver
> for one chinese Cypress EZ2 based cam), but that was very painful and
> I don't actually want to repeat the experience :D
There is very likely no need to patch a firmware. ;-)
The big task is the integrated decoder. Makes no fun without a datasheet. :/

>
> Bus 002 Device 005: ID 1b80:e31d Afatech 
> Device Descriptor:
>   bLength18
>   bDescriptorType 1
>   bcdUSB   2.00
>   bDeviceClass0 (Defined at Interface level)
>   bDeviceSubClass 0 
>   bDeviceProtocol 0 
>   bMaxPacketSize064
>   idVendor   0x1b80 Afatech
>   idProduct  0xe31d 
>   bcdDevice1.00
>   iManufacturer   0 
>   iProduct1 Roxio Video Capture USB
>   iSerial 2 0
>   bNumConfigurations  1
>   Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength  406
> bNumInterfaces  3
> bConfigurationValue 1
> iConfiguration  0 
> bmAttributes 0x80
>   (Bus Powered)
> MaxPower  500mA
> Interface Descriptor:
>   bLength 9
>   bDescriptorType 4
>   bInterfaceNumber0
>   bAlternateSetting   0
>   bNumEndpoints   4
>   bInterfaceClass   255 Vendor Specific Class
>   bInterfaceSubClass  0 
>   bInterfaceProtocol255 
>   iInterface  0 
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81  EP 1 IN
> bmAttributes3
>   Transfer TypeInterrupt
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0001  1x 1 bytes
> bInterval  11
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x82  EP 2 IN
> bmAttributes1
>   Transfer TypeIsochronous
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x  1x 0 bytes
> bInterval   1
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x84  EP 4 IN
> bmAttributes1
>   Transfer TypeIsochronous
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x  1x 0 bytes
> bInterval   1
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x8a  EP 10 IN
> bmAttributes2
>   Transfer TypeBulk
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0200  1x 512 bytes
> bInterval   0
> Interface Descriptor:
>   bLength 9
>   bDescriptorType 4
>   bInterfaceNumber0
>   bAlternateSetting   1
>   bNumEndpoints   4
>   bInterfaceClass   255 Vendor Specific Class
>   bInterfaceSubClass  0 
>   bInterfaceProtocol255 
>   iInterface  0 
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81  EP 1 IN
> bmAttributes3
>   Transfer TypeInterrupt
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0001  1x 1 bytes
> bInterval  11
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x82  EP 2 IN
> bmAttributes1
>   Transfer TypeIsochronous
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x  1x 0 bytes
> bInterval   1
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5

Re: HVR 900 (USB ID 2040:6500) no analogue sound reloaded

[Frank Schäfer]

Am 01.09.2014 um 09:31 schrieb Oravecz Csaba:
> Sun Aug 31 17:07:00 2014 =?windows-1252?Q?Frank_Sch=E4fer?= kirjutas:
>>
>> Am 22.08.2014 um 21:03 schrieb Oravecz Csaba:
>>> I reported this issue earlier but for some reason it went pretty much
>>> unnoticed. The essence is that with the newest em28xx drivers now present in
>>> 3.14 kernels (i'm on stock fedora 3.14.15-100.fc19.i686.PAE) I can't get
>>> analogue sound from this card.
>>>
>>> I see that the code snippet that produced this output in the pre 3.14 
>>> versions
>>>
>>> em2882/3 #0: Config register raw data: 0x50
>>> em2882/3 #0: AC97 vendor ID = 0x
>>> em2882/3 #0: AC97 features = 0x6a90
>>> em2882/3 #0: Empia 202 AC97 audio processor detected
>>>
>>> is still there in em28xx-core.c, however, there is nothing like that in
>>> current kernel logs so it seems that this part of the code is just skipped,
>>> which I tend to think is not the intended behaviour. I have not gone any
>>> further to investigate the issue, rather I've simply copied the 'old' em28xx
>> Thank you for reporting this issue.
>> I suspect reverting commit b99f0aadd3 "[media] em28xx: check if a device
>> has audio earlier" will resolve it.
>> Can you check that ?
> Yes, that has indeed solved the problem. I assume this will slowly propagate
> into the mainstraim distros, in the meantime i can happily use the custom
> compiled reverted drivers.
> Thanks,
> o.cs.
Ok, thanks for testing.
I will send a patch reverting this commit later this evening.

Regards,
Frank
--
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: strange empia device

[Lorenzo Marcantonio]

On Mon, Sep 01, 2014 at 08:14:25PM +0200, Frank Schäfer wrote:

> What's the other device using this vid:pid and which hardware does it use ?

The previous generation of the tool:

http://www.linuxtv.org/wiki/index.php/RoxioEasyVHStoDVD

... an easycap DC60+ clone. Doubly hating it since I bought is sure that
it would have been supported!

> The big task is the integrated decoder. Makes no fun without a datasheet. :/

I presume that with decoder you mean the composite to YUV translator... With 
the datasheet is too easy :D strange thing is eMPIA says that linux
is supported for some of their chip. But of course the 2980 isn't even
advertised and probably they only give you docs if you buy 100K pieces:(

> Thanks, looks like the other em2980 we have seen (Dazzle Video Capture
> USB V1.0).

Please tell if there are other tests or captures you need. By the way,
even on Windows, transfer seems flaky. If the bus is not perfectly
idle or there is some nontrivial CPU load often it loses transfer sync
and the image get "split" (probably an isoc transfer get lost and it
doesn't number the packets or something). Had the same problem with the
other chinese camera I used (USB suckitude knows no limits:P)

-- 
Lorenzo Marcantonio
Logos Srl
--
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 for 3.17] Revert "[media] em28xx: check if a device has audio earlier"

[Frank Schäfer]

This reverts

commit b99f0aadd33fad269c8e62b5bec8b5c012a44a56
Author: Mauro Carvalho Chehab 
Date:   Fri Dec 27 00:16:13 2013 -0300

[media] em28xx: check if a device has audio earlier

Better to split chipset detection from the audio setup. So, move the
detection code to em28xx_init_dev().

It broke analog audio of the Hauppauge winTV HVR 900 and very likely many other 
em28xx devices.


Background:
The local variable has_audio in em28xx_usb_probe() describes if the currently 
probed _usb_interface_ has an audio endpoint, while dev->audio_mode.has_audio 
means that the _device_ as a whole provides analog audio.
Hence it is wrong to set dev->audio_mode.has_audio = has_audio in 
em28xx_usb_probe().
As result, audio support is no longer detected and configured on devices which 
have the audio endpoint on a separate interface, because em28xx_audio_setup() 
bails out immediately at the beginning.


Revert the faulty commit to restore the old audio detection procedure, which 
checks 
the chip configuration register to determine if the device has analog audio.

Cc: # 3.14 to 3.16
Reported-by: Oravecz Csaba 
Tested-by: Oravecz Csaba 
Signed-off-by: Frank Schäfer 
---
 drivers/media/usb/em28xx/em28xx-cards.c | 11 ---
 drivers/media/usb/em28xx/em28xx-core.c  | 12 +++-
 2 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
b/drivers/media/usb/em28xx/em28xx-cards.c
index a7e24848..912ea1b 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -3098,16 +3098,6 @@ static int em28xx_init_dev(struct em28xx *dev, struct 
usb_device *udev,
}
}
 
-   if (dev->chip_id == CHIP_ID_EM2870 ||
-   dev->chip_id == CHIP_ID_EM2874 ||
-   dev->chip_id == CHIP_ID_EM28174 ||
-   dev->chip_id == CHIP_ID_EM28178) {
-   /* Digital only device - don't load any alsa module */
-   dev->audio_mode.has_audio = false;
-   dev->has_audio_class = false;
-   dev->has_alsa_audio = false;
-   }
-
if (chip_name != default_chip_name)
printk(KERN_INFO DRIVER_NAME
   ": chip ID is %s\n", chip_name);
@@ -3377,7 +3367,6 @@ static int em28xx_usb_probe(struct usb_interface 
*interface,
dev->alt   = -1;
dev->is_audio_only = has_audio && !(has_video || has_dvb);
dev->has_alsa_audio = has_audio;
-   dev->audio_mode.has_audio = has_audio;
dev->has_video = has_video;
dev->ifnum = ifnum;
 
diff --git a/drivers/media/usb/em28xx/em28xx-core.c 
b/drivers/media/usb/em28xx/em28xx-core.c
index 523d7e9..0f6caa4 100644
--- a/drivers/media/usb/em28xx/em28xx-core.c
+++ b/drivers/media/usb/em28xx/em28xx-core.c
@@ -506,8 +506,18 @@ int em28xx_audio_setup(struct em28xx *dev)
int vid1, vid2, feat, cfg;
u32 vid;
 
-   if (!dev->audio_mode.has_audio)
+   if (dev->chip_id == CHIP_ID_EM2870 ||
+   dev->chip_id == CHIP_ID_EM2874 ||
+   dev->chip_id == CHIP_ID_EM28174 ||
+   dev->chip_id == CHIP_ID_EM28178) {
+   /* Digital only device - don't load any alsa module */
+   dev->audio_mode.has_audio = false;
+   dev->has_audio_class = false;
+   dev->has_alsa_audio = false;
return 0;
+   }
+
+   dev->audio_mode.has_audio = true;
 
/* See how this device is configured */
cfg = em28xx_read_reg(dev, EM28XX_R00_CHIPCFG);
-- 
1.8.4.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: strange empia device

[Frank Schäfer]

Am 01.09.2014 um 21:03 schrieb Lorenzo Marcantonio:
> On Mon, Sep 01, 2014 at 08:14:25PM +0200, Frank Schäfer wrote:
>
>> What's the other device using this vid:pid and which hardware does it use ?
> The previous generation of the tool:
>
> http://www.linuxtv.org/wiki/index.php/RoxioEasyVHStoDVD
>
> ... an easycap DC60+ clone. Doubly hating it since I bought is sure that
> it would have been supported!
>
>> The big task is the integrated decoder. Makes no fun without a datasheet. :/
> I presume that with decoder you mean the composite to YUV translator... 
Yes.

> With the datasheet is too easy :D 
:D

> strange thing is eMPIA says that linux
> is supported for some of their chip. But of course the 2980 isn't even
> advertised 
It had been advertised in past, but they removed all informations about
it from their website. :-(

> and probably they only give you docs if you buy 100K pieces:(
...and sign an NDA (non-disclosure agreement).

>
>> Thanks, looks like the other em2980 we have seen (Dazzle Video Capture
>> USB V1.0).
> Please tell if there are other tests or captures you need.
At the moment, no.

>  By the way,
> even on Windows, transfer seems flaky. If the bus is not perfectly
> idle or there is some nontrivial CPU load often it loses transfer sync
> and the image get "split" (probably an isoc transfer get lost and it
> doesn't number the packets or something). 
Not our problem. ;-)

Regards,
Frank


> Had the same problem with the
> other chinese camera I used (USB suckitude knows no limits:P)


--
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] v4l: vsp1: fix driver dependencies

[Simon Horman]

On Mon, Sep 01, 2014 at 06:32:56PM +0200, Geert Uytterhoeven wrote:
> On Mon, Sep 1, 2014 at 3:18 PM, Bartlomiej Zolnierkiewicz
>  wrote:
> > Renesas VSP1 Video Processing Engine support should be available
> > only on Renesas ARM SoCs.
> 
> Thanks!
> 
> > Signed-off-by: Bartlomiej Zolnierkiewicz 
> > Acked-by: Kyungmin Park 
> > Cc: Simon Horman 
> > Cc: Magnus Damm 
> 
> Acked-by: Geert Uytterhoeven 

Acked-by: Simon Horman 
--
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

linux-media@vger.kernel.org

[Antti Palosaari]

Moikka Changbing and thanks to working that.

I reviewed the first patch and tested all these patches. It does not 
deadlock USB device anymore because of patch #1 so it is improvement. 
However, what I expect that patch, it should force device unregister but 
when I use tzap and unplug running device, it does not stop tzap, but 
continues zapping until app is killed using ctrl-c.

I used same(?) WinTV Aero for my tests.
$ tzap -r "YLE TV1" -a 0 -f 1 -c ~/.tzap/channels.conf_

Sep 02 02:50:38 localhost.localdomain kernel: usb 1-2: USB disconnect, 
device number 6
Sep 02 02:50:38 localhost.localdomain kernel: [57] dvb_usbv2_disconnect: 
usb 1-2: dvb_usbv2_disconnect: bInterfaceNumber=0
Sep 02 02:50:38 localhost.localdomain kernel: [57] dvb_usbv2_exit: usb 
1-2: dvb_usbv2_exit:
Sep 02 02:50:38 localhost.localdomain kernel: [57] 
dvb_usbv2_remote_exit: usb 1-2: dvb_usbv2_remote_exit:
Sep 02 02:50:38 localhost.localdomain kernel: [57] 
dvb_usbv2_adapter_exit: usb 1-2: dvb_usbv2_adapter_exit:
Sep 02 02:50:38 localhost.localdomain kernel: [57] 
dvb_usbv2_adapter_dvb_exit: usb 1-2: dvb_usbv2_adapter_dvb_exit: adap=0
Sep 02 02:50:38 localhost.localdomain kernel: [24239] 
dvb_usb_v2_generic_io: usb 1-2: dvb_usb_v2_generic_io: >>> aa 28
Sep 02 02:50:38 localhost.localdomain kernel: usb 1-2: dvb_usb_v2: 
usb_bulk_msg() failed=-19
Sep 02 02:50:38 localhost.localdomain kernel: 
mxl1x1sf_demod_get_rs_lock_status: error -19 on line 232
Sep 02 02:50:38 localhost.localdomain kernel: 
mxl111sf_demod_read_status: error -19 on line 452
Sep 02 02:50:39 localhost.localdomain kernel: [24238] 
dvb_usb_v2_generic_io: usb 1-2: dvb_usb_v2_generic_io: >>> aa 28
Sep 02 02:50:39 localhost.localdomain kernel: usb 1-2: dvb_usb_v2: 
usb_bulk_msg() failed=-19
Sep 02 02:50:39 localhost.localdomain kernel: 
mxl1x1sf_demod_get_rs_lock_status: error -19 on line 232
Sep 02 02:50:39 localhost.localdomain kernel: 
mxl111sf_demod_read_status: error -19 on line 452
Sep 02 02:50:39 localhost.localdomain kernel: [24238] 
dvb_usb_v2_generic_io: usb 1-2: dvb_usb_v2_generic_io: >>> aa 28

[.]
Sep 02 02:50:42 localhost.localdomain kernel: [24238] 
dvb_usb_v2_generic_io: usb 1-2: dvb_usb_v2_generic_io: >>> aa 2e
Sep 02 02:50:42 localhost.localdomain kernel: usb 1-2: dvb_usb_v2: 
usb_bulk_msg() failed=-19
Sep 02 02:50:42 localhost.localdomain kernel: 
mxl111sf_demod_read_ucblocks: error -19 on line 350
Sep 02 02:50:42 localhost.localdomain kernel: [24238] dvb_usb_stop_feed: 
usb 1-2: dvb_usb_stop_feed: adap=0 active_fe=1 feed_type=0 setting pid 
[no]: 0200 (0512) at index 0
Sep 02 02:50:42 localhost.localdomain kernel: [24239] dvb_usb_fe_sleep: 
usb 1-2: dvb_usb_fe_sleep: adap=0 fe=1
Sep 02 02:50:42 localhost.localdomain kernel: [24238] dvb_usb_stop_feed: 
usb 1-2: dvb_usb_stop_feed: adap=0 active_fe=1 feed_type=0 setting pid 
[no]: 028a (0650) at index 1
Sep 02 02:50:42 localhost.localdomain kernel: [24238] usb_urb_killv2: 
usb 1-2: usb_urb_killv2: kill urb=0
Sep 02 02:50:42 localhost.localdomain kernel: [24238] usb_urb_killv2: 
usb 1-2: usb_urb_killv2: kill urb=1
Sep 02 02:50:42 localhost.localdomain kernel: [24238] usb_urb_killv2: 
usb 1-2: usb_urb_killv2: kill urb=2
Sep 02 02:50:42 localhost.localdomain kernel: [24238] usb_urb_killv2: 
usb 1-2: usb_urb_killv2: kill urb=3
Sep 02 02:50:42 localhost.localdomain kernel: [24238] usb_urb_killv2: 
usb 1-2: usb_urb_killv2: kill urb=4
Sep 02 02:50:42 localhost.localdomain kernel: [24239] 
dvb_usbv2_device_power_ctrl: usb 1-2: dvb_usbv2_device_power_ctrl: power=0
Sep 02 02:50:42 localhost.localdomain kernel: [24239] dvb_usb_fe_sleep: 
usb 1-2: dvb_usb_fe_sleep: ret=0
Sep 02 02:50:42 localhost.localdomain kernel: [57] 
dvb_usbv2_adapter_stream_exit: usb 1-2: dvb_usbv2_adapter_stream_exit: 
adap=0
Sep 02 02:50:42 localhost.localdomain kernel: [57] usb_urb_free_urbs: 
usb 1-2: usb_urb_free_urbs: free urb=4
Sep 02 02:50:42 localhost.localdomain kernel: [57] usb_urb_free_urbs: 
usb 1-2: usb_urb_free_urbs: free urb=3
Sep 02 02:50:42 localhost.localdomain kernel: [57] usb_urb_free_urbs: 
usb 1-2: usb_urb_free_urbs: free urb=2
Sep 02 02:50:42 localhost.localdomain kernel: [57] usb_urb_free_urbs: 
usb 1-2: usb_urb_free_urbs: free urb=1
Sep 02 02:50:42 localhost.localdomain kernel: [57] usb_urb_free_urbs: 
usb 1-2: usb_urb_free_urbs: free urb=0
Sep 02 02:50:42 localhost.localdomain kernel: [57] 
usb_free_stream_buffers: usb 1-2: usb_free_stream_buffers: free buf=4
Sep 02 02:50:42 localhost.localdomain kernel: [57] 
usb_free_stream_buffers: usb 1-2: usb_free_stream_buffers: free buf=3
Sep 02 02:50:42 localhost.localdomain kernel: [57] 
usb_free_stream_buffers: usb 1-2: usb_free_stream_buffers: free buf=2
Sep 02 02:50:42 localhost.localdomain kernel: [57] 
usb_free_stream_buffers: usb 1-2: usb_free_stream_buffers: free buf=1
Sep 02 02:50:42 localhost.localdomain kernel: [57] 
usb_free_stream_buffers: usb 1-2: usb_free_stream_buffers: free buf=0
Sep 02 02:50:42 localhost.localdomain kernel: [57] 
dvb_usbv2_adapter_front

Re: strange empia device

[Andy Walls]

On Sun, 2014-08-31 at 16:47 +0200, Frank Schäfer wrote:
> Hi Lorenzo,
> 
> Am 25.08.2014 um 21:01 schrieb Lorenzo Marcantonio:
> > Just bought a roxio video capture dongle. Read around that it was an
> > easycap clone (supported, then); it seems it's not so anymore :(
> >
> > It identifies as 1b80:e31d Roxio Video Capture USB
> >
> > (it also uses audio class for audio)
> >
> > Now comes the funny thing. Inside there is the usual E2P memory,
> > a regulator or two and an empia marked EM2980 (*not* em2890!); some
> > passive and nothing else.
> >
> > Digging around in the driver cab (emBDA.inf) shows that it seems an
> > em28285 driver rebranded by roxio... it installs emBDAA.sys and
> > emOEMA.sys (pretty big: about 1.5MB combined!); also a 16KB merlinFW.rom
> > (presumably a firmware for the em chip? 

A Merlin firmware of 16 kB strongly suggests that this chip has an
integarted Conexant CX25843 (Merlin Audio + Thresher Video = Mako)
Broadtcast A/V decoder core.  The chip might only have a Merlin
integrated, but so far I've never encountered that.  It will be easy
enough to tell, if the Thresher registers don't respond or only respond
with junk.

The Merlin has an integrated 8051 microcontroller that, if you are
decoding SIF audio from an analog tuner, will periodically reprogram
registers in the Merlin core to do spectral analysis of the SIF to
determine the broadcast audio standard (BTSC, etc.).

A public datasheet for the CX25843 is here:
http://dl.ivtvdriver.org/datasheets/video/cx25840.pdf

There appear to be at least two families of CX25843 cores:

- the core in the stand-alone CX2584[0123] chips and the '843 core
integrated into the CX23418

- the core integrated into the CX2388[578] and CX2310[012] chips, which
have a slightly different register defintion in some places 


The cx25840 driver under linux handles most of these, except that the
cx18 driver has it's own fork of the cx25840 driver in its cx18-av-*
files.  The core is normally I2C connected, except for the one
integrated into the CX23418.

If the empia device driver needs to support a CX25843 core, I highly
recommend forking a copy of the cx25840 driver specifically for the
empia devices, as opposed to trying to fit in yet another variant in the
cx25840 driver itself. 

FWIW, since the CX2310[012] devices are also USB connected, maybe that
driver can provide some basis for comparison along with the USB traces
you already have.  (I haven't compared them myself.)

Regards,
Andy

>  I tought they were fixed
> > function); also the usual directshow .ax filter and some exe in
> > autorun (emmona.exe: firmware/setup loader?).
> >
> > Looking in the em28xx gave me the idea that that thing is not
> > supported (at least in my current 3.6.6)... however the empia sites says
> > (here http://www.empiatech.com/wp/video-grabber-em282xx/) 28284 should
> > be linux supported. Nothing said about 28285. And the chip is marked
> > 2980?! by the way, forcing the driver to load I get this:
> >
> > [ 3439.787701] em28xx: New device  Roxio Video Capture USB @ 480 Mbps 
> > (1b80:e31d, interface 0, class 0)
> > [ 3439.787704] em28xx: Video interface 0 found
> > [ 3439.787705] em28xx: DVB interface 0 found
> > [ 3439.787866] em28xx #0: em28xx chip ID = 146
> >
> > Is there any hope to make it work (even on git kernel there is nothing
> > for chip id 146...)?
> >
> 
> See http://www.spinics.net/lists/linux-media/msg73699.html
> 
> HTH,
> Frank
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

linux-media@vger.kernel.org

[Mauro Carvalho Chehab]

Em Tue, 02 Sep 2014 02:58:50 +0300
Antti Palosaari  escreveu:

> Moikka Changbing and thanks to working that.
> 
> I reviewed the first patch and tested all these patches. It does not 
> deadlock USB device anymore because of patch #1 so it is improvement. 
> However, what I expect that patch, it should force device unregister but 
> when I use tzap and unplug running device, it does not stop tzap, but 
> continues zapping until app is killed using ctrl-c.
> I used same(?) WinTV Aero for my tests.

...

> Is there any change to close all those /dev file handles when device 
> disappears?

Well, we may start returning -ENODEV when such event happens. 

At the frontend, we could use fe->exit = DVB_FE_DEVICE_REMOVED to
signalize it. I don't think that the demod frontend has something
similar.

Yet, it should be up to the userspace application to properly handle 
the error codes and close the devices on fatal non-recovery errors like
ENODEV. 

So, what we can do, at Kernel level, is to always return -ENODEV when
the device is known to be removed, and double check libdvbv5 if it
handles such error properly.

Regards,
Mauro

> 
> regards
> Antti
> 
> 
> On 08/21/2014 05:05 AM, Changbing Xiong wrote:
> > when usb-type tuner is pulled out, user applications did not close device's 
> > FD,
> > and go on polling the device, we should return POLLERR directly.
> >
> > Signed-off-by: Changbing Xiong 
> > ---
> >   drivers/media/dvb-core/dmxdev.c |6 +-
> >   1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/dvb-core/dmxdev.c 
> > b/drivers/media/dvb-core/dmxdev.c
> > index 7a5c070..42b5e70 100755
> > --- a/drivers/media/dvb-core/dmxdev.c
> > +++ b/drivers/media/dvb-core/dmxdev.c
> > @@ -1085,9 +1085,10 @@ static long dvb_demux_ioctl(struct file *file, 
> > unsigned int cmd,
> >   static unsigned int dvb_demux_poll(struct file *file, poll_table *wait)
> >   {
> > struct dmxdev_filter *dmxdevfilter = file->private_data;
> > +   struct dmxdev *dmxdev = dmxdevfilter->dev;
> > unsigned int mask = 0;
> >
> > -   if (!dmxdevfilter)
> > +   if ((!dmxdevfilter) || (dmxdev->exit))
> > return POLLERR;
> >
> > poll_wait(file, &dmxdevfilter->buffer.queue, wait);
> > @@ -1181,6 +1182,9 @@ static unsigned int dvb_dvr_poll(struct file *file, 
> > poll_table *wait)
> >
> > dprintk("function : %s\n", __func__);
> >
> > +   if (dmxdev->exit)
> > +   return POLLERR;
> > +
> > poll_wait(file, &dmxdev->dvr_buffer.queue, wait);
> >
> > if ((file->f_flags & O_ACCMODE) == O_RDONLY) {
> > --
> > 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

dvbv5-scan segfaults when invalid freqs got from tables

[Antti Palosaari]

Mauro,
Could you look that one too?

There is utterly broken data got from tables and it crashes always.

Antti

[crope@localhost dvb]$ ./dvbv5-scan mux-Oulu-t2
Scanning frequency #1 17750
Lock   (0x1f)
Service Showtime, provider DNA: reserved
Service Eurosport 2, provider DNA: reserved
Service Nelonen Maailma, provider DNA: reserved
Service Nelonen Nappula, provider DNA: reserved
Service Nelonen Prime, provider DNA: reserved
Service National Geographic, provider DNA: reserved
Service Investigation Discovery, provider DNA: reserved
Service Nelonen PRO 2 HD, provider DNA: reserved
Service MTV Sport 1 HD, provider DNA: reserved
Service Nelonen PRO 2 HD, provider DNA: reserved
Service Nelonen PRO 3, provider DNA: reserved
WARNING  Service ID 103 not found on PMT!
Service Nelonen PRO 4 , provider DNA: reserved
WARNING  Service ID 104 not found on PMT!
Service Nelonen PRO 5, provider DNA: reserved
WARNING  Service ID 105 not found on PMT!
Service Nelonen PRO 6, provider DNA: reserved
WARNING  Service ID 106 not found on PMT!
Service Nelonen PRO 7, provider DNA: reserved
WARNING  Service ID 107 not found on PMT!
Service Nelonen PRO 8, provider DNA: reserved
WARNING  Service ID 108 not found on PMT!
New transponder/channel found: #6: 1510003450
New transponder/channel found: #7: -2110588416
New transponder/channel found: #8: -587352536
New transponder/channel found: #9: 410
New transponder/channel found: #10: 511181010
New transponder/channel found: #11: -2133687758
New transponder/channel found: #12: -2132410148
New transponder/channel found: #13: 1745048284
New transponder/channel found: #14: 59046400
New transponder/channel found: #15: -1225129104
New transponder/channel found: #16: -603751716
New transponder/channel found: #17: 589880320
New transponder/channel found: #18: -1728445454
New transponder/channel found: #19: -100422436
New transponder/channel found: #20: 61004800
New transponder/channel found: #21: -891551084
New transponder/channel found: #22: -541710336
New transponder/channel found: #23: 106270
New transponder/channel found: #24: -536651392
New transponder/channel found: #25: 1375964032
New transponder/channel found: #26: 1308867968
New transponder/channel found: #27: -1241286784
New transponder/channel found: #28: 1879277952
New transponder/channel found: #29: 2049126272
New transponder/channel found: #30: -2080137344
New transponder/channel found: #31: -1744569984
New transponder/channel found: #32: -234638464
New transponder/channel found: #33: -1409046144
New transponder/channel found: #34: -1576808064
New transponder/channel found: #35: -905798784
New transponder/channel found: #36: -1778513088
New transponder/channel found: #37: -1520083210
Scanning frequency #2 20550
Lock   (0x1f)
DMX_SET_FILTER failed (PID = 0x): 27 File too large
ERRORerror while waiting for PAT table
Scanning frequency #3 21950
Lock   (0x1f)
ERRORdvb_read_sections: no data read on section filter
ERRORerror while waiting for PAT table
Scanning frequency #4 49800
Lock   (0x1f)
ERRORdvb_read_sections: no data read on section filter
ERRORerror while waiting for PAT table
Scanning frequency #5 57000
Lock   (0x1f)
ERRORdvb_read_sections: no data read on section filter
ERRORerror while waiting for PAT table
Scanning frequency #6 1510003450
ERRORcommand STREAM_ID (42) not found during store
ERRORFE_SET_PROPERTY: Invalid argument
ERRORdvb_fe_set_parms failed: Invalid argument
Scanning frequency #7 -2110588416
ERRORcommand STREAM_ID (42) not found during store
ERRORFE_SET_PROPERTY: Invalid argument
ERRORdvb_fe_set_parms failed: Invalid argument
Scanning frequency #8 -587352536
ERRORcommand STREAM_ID (42) not found during store
ERRORFE_SET_PROPERTY: Invalid argument
ERRORdvb_fe_set_parms failed: Invalid argument
Scanning frequency #9 410
ERRORcommand STREAM_ID (42) not found during store
ERRORFE_SET_PROPERTY: Invalid argument
ERRORdvb_fe_set_parms failed: Invalid argument
Scanning frequency #10 511181010
ERRORcommand STREAM_ID (42) not found during store
   (0x00)
Scanning frequency #11 -2133687758
ERRORcommand STREAM_ID (42) not found during store
ERRORFE_SET_PROPERTY: Invalid argument
ERRORdvb_fe_set_parms failed: Invalid argument
Scanning frequency #12 -2132410148
ERRORcommand STREAM_ID (42) not found during store
ERRORFE_SET_PROPERTY: Invalid argument
ERRORdvb_fe_set_parms failed: Invalid argument
Scanning frequency #13 1745048284
ERRORcommand STREAM_ID (42) not found during store
ERRORFE_SET_PROPERTY: Invalid argument
ERRORdvb_fe_set_parms failed: Invalid argument
Scanning frequency #14 59046400
ERRORcommand STREAM_ID (42) not found during store
ERRORFE_SET_PROPERTY: Invalid argument
ERRORdvb_fe_set_parms failed: Invalid argument
Scanning frequency #15 -1225129104
ERRORcommand STREAM_ID (42) not found during store
ERRORFE_SET_PROPERTY: Invalid argument
ERROR

cron job: media_tree daily build: WARNINGS

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:   Tue Sep  2 04:00:18 CEST 2014
git branch: test
git hash:   b250392f7b5062cf026b1423e27265e278fd6b30
gcc version:i686-linux-gcc (GCC) 4.9.1
sparse version: v0.5.0-20-g7abd8a7
host hardware:  x86_64
host os:3.16-1.slh.1-amd64

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

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

linux-media@vger.kernel.org

[Changbing Xiong]

> Well, we may start returning -ENODEV when such event happens. 

> At the frontend, we could use fe->exit = DVB_FE_DEVICE_REMOVED to
> signalize it. I don't think that the demod frontend has something
> similar.

> Yet, it should be up to the userspace application to properly handle 
> the error codes and close the devices on fatal non-recovery errors like
> ENODEV. 

> So, what we can do, at Kernel level, is to always return -ENODEV when
> the device is known to be removed, and double check libdvbv5 if it
> handles such error properly.

 well, we do not use libdvbv5, and  -ENODEV can be returned by read syscall,  
but for poll syscall,  -ENODEV can never be returned to user, as negative number
 is invalid  type for poll returned value. please refer to my second patch.

and in our usage, whether to read the device is up to the poll result. if tuner 
is plugged out, 
and there is no data in dvr ringbuffer. then user code will still go on polling 
the dvr device and never stop.
if POLLERR is returned, then user will perform read dvr, and then -ENODEV can 
be got, and 
user will stop polling dvr device.

the first patch is enough to fix the deadlock issue.
the second patch is used to correct the wrong type of returned value.
the third patch is used to provide user a better controlling logic.

linux-media@vger.kernel.org

[Mauro Carvalho Chehab]

Em Tue, 02 Sep 2014 03:16:00 + (GMT)
Changbing Xiong  escreveu:

> 
> > Well, we may start returning -ENODEV when such event happens. 
> 
> > At the frontend, we could use fe->exit = DVB_FE_DEVICE_REMOVED to
> > signalize it. I don't think that the demod frontend has something
> > similar.
> 
> > Yet, it should be up to the userspace application to properly handle 
> > the error codes and close the devices on fatal non-recovery errors like
> > ENODEV. 
> 
> > So, what we can do, at Kernel level, is to always return -ENODEV when
> > the device is known to be removed, and double check libdvbv5 if it
> > handles such error properly.
> 
>  well, we do not use libdvbv5,

The upstream stuff I maintain, related to it, are the media subsystems
and libdvbv5. Of course, other apps will need to be patched as well.

> and  -ENODEV can be returned by read syscall,  
> but for poll syscall,

Actually, poll() may return an error as well (from poll() manpage):

"RETURN VALUE
   On success, a positive number is returned; this is the number of struc‐
   tures which have nonzero revents fields (in other words, those descrip‐
   tors  with events or errors reported).  A value of 0 indicates that the
   call timed out and no file descriptors were ready.   On  error,  -1  is
   returned, and errno is set appropriately."

So, if the Kernel returns -ENODEV, the glibc poll() wrapper would return -1
and errno will be ENODEV. Never actually tested if this works on poll()
though.

>  -ENODEV can never be returned to user, as negative number
>  is invalid  type for poll returned value. please refer to my second patch.
> 
> and in our usage, whether to read the device is up to the poll result. if 
> tuner is plugged out, 
> and there is no data in dvr ringbuffer. then user code will still go on 
> polling the dvr device and never stop.
> if POLLERR is returned, then user will perform read dvr, and then -ENODEV can 
> be got, and 
> user will stop polling dvr device.

Your app should be also be handling poll() errors, as there are already
other errors that poll() can return.

> the first patch is enough to fix the deadlock issue.
> the second patch is used to correct the wrong type of returned value.
> the third patch is used to provide user a better controlling logic.

I'll take a deeper look and do some tests on your patches likely
tomorrow. 

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

[PATCH] UVC: Remove extra commit on resume()

[Guennadi Liakhovetski]

From: Aviv Greenberg 

The UVC spec is a bit vague wrt devices using bulk endpoints,
specifically, how to signal to a device to start streaming.

For devices using isoc endpoints, the sequence for start streaming is:
1) The host sends PROBE_CONTROL(SET_CUR) PROBE_CONTROL(GET_CUR)
2) Host selects desired config and calls COMMIT_CONTROL(SET_CUR)
3) Host selects an alt interface other then zero - e.g 
SELECT_ALTERNATE_INTERFACE(1)
4) The device starts streaming

However for devices using bulk endpoints, there must be *no* alt interface
other than setting zero. From the UVC spec:
"A VideoStreaming interface containing a bulk endpoint for streaming shall
support only alternate setting zero. Additional alternate settings containing
bulk endpoints are not permitted in a device that is compliant with the Video
Class specification."

So for devices using bulk endpoints, step #3 above is irrelevant, and thus
cannot be used as an indication for the device to start streaming.
So in practice, such devices start streaming immediately after a
COMMIT_CONTROL(SET_CUR).

In the uvc resume() handler, an unsolicited commit is sent, which causes
devices using bulk endpoints to start streaming unintentionally.

This patch modifies resume() handler to send a commit only if streaming
needs to be reestablished, i.e if the device was actually streaming before is
was suspended.

Signed-off-by: Aviv Greenberg 
Signed-off-by: Guennadi Liakhovetski 
---
 drivers/media/usb/uvc/uvc_video.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/usb/uvc/uvc_video.c 
b/drivers/media/usb/uvc/uvc_video.c
index 3394c34..c111de2 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -1709,15 +1709,15 @@ int uvc_video_resume(struct uvc_streaming *stream, int 
reset)
 
uvc_video_clock_reset(stream);
 
+   if (!uvc_queue_streaming(&stream->queue))
+   return 0;
+
ret = uvc_commit_video(stream, &stream->ctrl);
if (ret < 0) {
uvc_queue_enable(&stream->queue, 0);
return ret;
}
 
-   if (!uvc_queue_streaming(&stream->queue))
-   return 0;
-
ret = uvc_init_video(stream, GFP_NOIO);
if (ret < 0)
uvc_queue_enable(&stream->queue, 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

Re: strange empia device

[Lorenzo Marcantonio]

On Mon, Sep 01, 2014 at 07:58:52PM -0400, Andy Walls wrote:
> A Merlin firmware of 16 kB strongly suggests that this chip has an
> integarted Conexant CX25843 (Merlin Audio + Thresher Video = Mako)
> Broadtcast A/V decoder core.  The chip might only have a Merlin
> integrated, but so far I've never encountered that.  It will be easy
> enough to tell, if the Thresher registers don't respond or only respond
> with junk.

However I strongly suspect that these drivers are for a whole *family*
of empia device. The oem ini by roxio talks about three different
parts... probably they give one sys file for everyone and the oem
customizes the ini.

In short the merlin fw may not be actually used for *this* part but only
for other empia devices/configurations.

Otherwise I wonder *why* a fscking 1.5MB of sys driver for a mostly dumb
capture device...

-- 
Lorenzo Marcantonio
Logos Srl
--
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

linux-media@vger.kernel.org

[Changbing Xiong]

> Actually, poll() may return an error as well (from poll() manpage):

> "RETURN VALUE
>On success, a positive number is returned; this is the number of struc‐
>tures which have nonzero revents fields (in other words, those descrip‐
>tors  with events or errors reported).  A value of 0 indicates that the
>call timed out and no file descriptors were ready.   On  error,  -1  is
>returned, and errno is set appropriately."

> So, if the Kernel returns -ENODEV, the glibc poll() wrapper would return -1
> and errno will be ENODEV. Never actually tested if this works on poll()
> though.

> Actually, poll() may return an error as well (from poll() manpage):

> "RETURN VALUE
>On success, a positive number is returned; this is the number of struc‐
>tures which have nonzero revents fields (in other words, those descrip‐
>tors  with events or errors reported).  A value of 0 indicates that the
>call timed out and no file descriptors were ready.   On  error,  -1  is
>returned, and errno is set appropriately."

> So, if the Kernel returns -ENODEV, the glibc poll() wrapper would return -1
> and errno will be ENODEV. Never actually tested if this works on poll()
> though.

maybe the poll() manpage is wrong.
The standard system call poll() can not get -ENODEV from errno. 
My experiment has proved that I was right(return -ENODEV directly in 
dvb_dvr_poll).  
and you can also check code of do_poll() and do_sys_poll() in select.c file, it 
also shows that -ENODEV is invalid.

please also check that.

thanks!
Xiong changbing

--- Original Message ---
Sender : Mauro Carvalho Chehab Director/SRBR-Open 
Source/삼성전자
Date : 九月 02, 2014 15:00 (GMT+09:00)
Title : Re: [PATCH 3/3] media: check status of dmxdev->exit in poll functions 
of demux&dvr

Em Tue, 02 Sep 2014 03:16:00 + (GMT)
Changbing Xiong escreveu:

> 
> > Well, we may start returning -ENODEV when such event happens. 
> 
> > At the frontend, we could use fe->exit = DVB_FE_DEVICE_REMOVED to
> > signalize it. I don't think that the demod frontend has something
> > similar.
> 
> > Yet, it should be up to the userspace application to properly handle 
> > the error codes and close the devices on fatal non-recovery errors like
> > ENODEV. 
> 
> > So, what we can do, at Kernel level, is to always return -ENODEV when
> > the device is known to be removed, and double check libdvbv5 if it
> > handles such error properly.
> 
>  well, we do not use libdvbv5,

The upstream stuff I maintain, related to it, are the media subsystems
and libdvbv5. Of course, other apps will need to be patched as well.

> and  -ENODEV can be returned by read syscall,  
> but for poll syscall,

Actually, poll() may return an error as well (from poll() manpage):

"RETURN VALUE
   On success, a positive number is returned; this is the number of struc‐
   tures which have nonzero revents fields (in other words, those descrip‐
   tors  with events or errors reported).  A value of 0 indicates that the
   call timed out and no file descriptors were ready.   On  error,  -1  is
   returned, and errno is set appropriately."

So, if the Kernel returns -ENODEV, the glibc poll() wrapper would return -1
and errno will be ENODEV. Never actually tested if this works on poll()
though.

>  -ENODEV can never be returned to user, as negative number
>  is invalid  type for poll returned value. please refer to my second patch.
> 
> and in our usage, whether to read the device is up to the poll result. if 
> tuner is plugged out, 
> and there is no data in dvr ringbuffer. then user code will still go on 
> polling the dvr device and never stop.
> if POLLERR is returned, then user will perform read dvr, and then -ENODEV can 
> be got, and 
> user will stop polling dvr device.

Your app should be also be handling poll() errors, as there are already
other errors that poll() can return.

> the first patch is enough to fix the deadlock issue.
> the second patch is used to correct the wrong type of returned value.
> the third patch is used to provide user a better controlling logic.

I'll take a deeper look and do some tests on your patches likely
tomorrow. 

Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  
http://vger.kernel.org/majordomo-info.htmlN�r��yb�X��ǧv�^�)޺{.n�+{���bj)w*jg����ݢj/���z�ޖ��2�ޙ&�)ߡ�a�����G���h��j:+v���w��٥