Re: [PATCH 01/12] trivial: drivers/media/usb/gspca/gspca.c: fix the indentation of a comment
On Wed, 4 Jun 2014 14:03:39 +0200
Antonio Ospite a...@ao2.it wrote:
Fix indentation of a comment, put it on the same level of the code it
refers to.
Signed-off-by: Antonio Ospite a...@ao2.it
Cc: Hans de Goede hdego...@redhat.com
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
On Wed, 4 Jun 2014 14:03:40 +0200 Antonio Ospite a...@ao2.it wrote: Signed-off-by: Antonio Ospite a...@ao2.it Cc: Hans de Goede hdego...@redhat.com 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
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
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 http://lxr.free- electrons.com/ident?i=reqbufs_outputs5p_mfc_open_mfc_inst() should be post-poned until STREAMON is called. http://lxr.free-electrons.com/ident?i=reqbufs_output How is this connected to the renegotiation scenario? Are you sure you wanted to mention s5p_mfc_open_mfc_inst? cheers, Nicolas http://lxr.free-electrons.com/ident?i=reqbufs_output Best wishes, -- Kamil Debski Samsung RD 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
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
2014-08-31 19:18 GMT+02:00 Laurent Pinchart laurent.pinch...@ideasonboard.com:
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 jean-michel.hautb...@vodalys.com
---
.../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, use this one instead, and if it is in DT, it should be the prior
address to use (priority on DT and not on platform data).
But this is probably ideal for me but not for others ?
Thanks,
JM
--
To unsubscribe from this list: send the
[PATCH 3/4] s5p-jpeg: avoid overwriting JPEG_CNTL register settings
Take into account the JPEG_CNTL register value read before setting SYS_INT_EN bit field. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com --- 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
There is no need to read INT_EN_REG before enabling interrupts.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
---
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
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 j.anaszew...@samsung.com
---
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
Use proper bitwise operator while clearing HUF_TBL_EN bit. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com --- 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
Renesas VSP1 Video Processing Engine support should be available only on Renesas ARM SoCs. Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Simon Horman ho...@verge.net.au Cc: Magnus Damm magnus.d...@gmail.com --- 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
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 hdego...@redhat.com
---
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
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
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 hdego...@redhat.com
---
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
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 http://lxr.free- electrons.com/ident?i=reqbufs_outputs5p_mfc_open_mfc_inst() should be post-poned until STREAMON is called. http://lxr.free-electrons.com/ident?i=reqbufs_output 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
On Mon, Sep 1, 2014 at 3:18 PM, Bartlomiej Zolnierkiewicz
b.zolnier...@samsung.com wrote:
Renesas VSP1 Video Processing Engine support should be available
only on Renesas ARM SoCs.
Thanks!
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Simon Horman ho...@verge.net.au
Cc: Magnus Damm magnus.d...@gmail.com
Acked-by: Geert Uytterhoeven geert+rene...@glider.be
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
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
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 bEndpointAddress 0x84 EP 4 IN bmAttributes1 Transfer Type
Re: HVR 900 (USB ID 2040:6500) no analogue sound reloaded
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
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
This reverts
commit b99f0aadd33fad269c8e62b5bec8b5c012a44a56
Author: Mauro Carvalho Chehab m.che...@samsung.com
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: sta...@vger.kernel.org# 3.14 to 3.16
Reported-by: Oravecz Csaba orav...@nytud.mta.hu
Tested-by: Oravecz Csaba orav...@nytud.mta.hu
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
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
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
On Mon, Sep 01, 2014 at 06:32:56PM +0200, Geert Uytterhoeven wrote: On Mon, Sep 1, 2014 at 3:18 PM, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: Renesas VSP1 Video Processing Engine support should be available only on Renesas ARM SoCs. Thanks! Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Simon Horman ho...@verge.net.au Cc: Magnus Damm magnus.d...@gmail.com Acked-by: Geert Uytterhoeven geert+rene...@glider.be Acked-by: Simon Horman horms+rene...@verge.net.au -- 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] media: check status of dmxdev-exit in poll functions of demuxdvr
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_frontend_exit: usb
Re: strange empia device
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
Re: [PATCH 3/3] media: check status of dmxdev-exit in poll functions of demuxdvr
Em Tue, 02 Sep 2014 02:58:50 +0300
Antti Palosaari cr...@iki.fi 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 cb.xi...@samsung.com
---
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
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
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
Re: Re: [PATCH 3/3] media: check status of dmxdev-exit in poll functions of demuxdvr
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.
