Fwd: v4l2: The device does not support the streaming I/O method.
I am trying to capture input from /dev/video0 which is Hauppauge Win 150 MCE PCI card but I get the following error which has no record on google [video4linux2,v4l2 @ 0xb080d60] The device does not support the streaming I/O method. /dev/video0: Function not implemented Here is the ffmpeg command ffmpeg -y -f:v video4linux2 -i /dev/video0 -f:a alsa -ac 1 -i hw:1,0 -threads 2 -override_ffserver -flags +global_header -vcodec libx264 -s 320x240 -preset superfast -r 7.5 -acodec aac -ar 44100 ipgoeshere:port/dvbstest.ffm Disregard the DVB syntax, not relevant Any idea what is causing the error? -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
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: Fri Dec 27 04:00:16 CET 2013 git branch: test git hash: 7d459937dc09bb8e448d9985ec4623779427d8a5 gcc version:i686-linux-gcc (GCC) 4.8.2 sparse version: 0.4.5-rc1 host hardware: x86_64 host os:3.12-0.slh.2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: ERRORS 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.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12-i686: OK linux-3.13-rc1-i686: OK linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: WARNINGS linux-3.11.1-x86_64: WARNINGS linux-3.12-x86_64: WARNINGS linux-3.13-rc1-x86_64: WARNINGS apps: OK spec-git: OK sparse version: 0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.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: DMABUF doesn't work when frame size not equal to the size of GPU bo
Ping for reply! 2013/12/25 Chuanbo Weng : > Hi all, > >(My environment is intel platform, HD4000 GPU, kernel 3.10.19, > logitech 270 webcam) >As title said, I discover this issue when I run the program > shown by Laurent Pinchart: > http://www.mail-archive.com/linux-media@vger.kernel.org/msg54806.html > > If the frame is (width, height) = (640, 480), DMABUF works well. > If the frame is (width, height) = (160, 120), v4lfd receives no event. > > > And I dig into drm kernel code, find that: i915_gem_create will create > a GPU buffer object on intel platform. The size of GPU bo will be > bigger than frame size, for the reason that i915_gem_create will > roundup the bo size to multiple of PAGE_SIZE when the frame is (width, > height) = (160, 120). > For (width, height) = (640, 480), the frame size is already multiple > of PAGE_SIZE, so GPU bo is exactly equal to frame size. > > I also dump the uvc driver infomation, there is some infomation i > think maybe important: > uvcvideo: Stream 1 error event 07 01 len 4 > > Looking forward to the discussion! > > Thanks, > Chuanbo Weng -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] media: soc_camera: rcar_vin: Add preliminary R-Car M2 support
Hi Valentine,
Thank you for the patch.
On Thursday 26 December 2013 19:31:49 Valentine Barshak wrote:
> This adds R-Car M2 (R8A7791) VIN support. Both H2 and M2
> variants look the same from the driver's point of view,
> so use GEN2 id for both.
>
> Changes in V2:
> * Used the same (RCAR_GEN2) id for both H2 and M2 variants
> since they are no different from the driver's point of view.
>
> Signed-off-by: Valentine Barshak
Acked-by: Laurent Pinchart
> ---
> drivers/media/platform/soc_camera/rcar_vin.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
> b/drivers/media/platform/soc_camera/rcar_vin.c index 6866bb4..3b1c05a
> 100644
> --- a/drivers/media/platform/soc_camera/rcar_vin.c
> +++ b/drivers/media/platform/soc_camera/rcar_vin.c
> @@ -106,7 +106,7 @@
> #define VIN_MAX_HEIGHT 2048
>
> enum chip_id {
> - RCAR_H2,
> + RCAR_GEN2,
> RCAR_H1,
> RCAR_M1,
> RCAR_E1,
> @@ -302,7 +302,7 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
> dmr = 0;
> break;
> case V4L2_PIX_FMT_RGB32:
> - if (priv->chip == RCAR_H2 || priv->chip == RCAR_H1 ||
> + if (priv->chip == RCAR_GEN2 || priv->chip == RCAR_H1 ||
> priv->chip == RCAR_E1) {
> dmr = VNDMR_EXRGB;
> break;
> @@ -1384,7 +1384,8 @@ static struct soc_camera_host_ops rcar_vin_host_ops =
> { };
>
> static struct platform_device_id rcar_vin_id_table[] = {
> - { "r8a7790-vin", RCAR_H2 },
> + { "r8a7791-vin", RCAR_GEN2 },
> + { "r8a7790-vin", RCAR_GEN2 },
> { "r8a7779-vin", RCAR_H1 },
> { "r8a7778-vin", RCAR_M1 },
> { "uPD35004-vin", RCAR_E1 },
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A list of Linux drivers
Moi Jahn There is not very many suitable alternatives that are available on market as of today. Maybe PCTV 460e/461e only?. 460e is older one which is replaced by 461e. I think it is currently bigger change to get new 461e if you order one. 460e is em28xx + tda10071 461e is em28xx + m88ds3103 460e has been supported ages, but 461e was added recently. That means you will need to compile 461e drivers separately. And I am not even sure if it works for MIPS. I have simply no hardware to test. Anyhow, possible fix should be rather easy. regards Antti On 26.12.2013 15:16, Jahn wrote: Peter, Thank you for the reply. But I would like to use a USB tuner with my satelite receiver( as the second tuner) and not sure which tuner will suit the best my needs. So I wonder if there is a list of tuners (with Linux drivers) that I can choose from . Or can anyone advice a good/cheap DVB-S2 USB tuner? Preferably with open source driver Thank you for your reply. Check the file: drivers/media/tuners/Kconfig On Thu, Dec 26, 2013 at 12:03 PM, Jahn wrote: > Is there available a list of tuners that are supported in Linux ( those that have a driver) > preferably in MIPS Linux ? > Thanks > > -- 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 -- Peter -- 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 -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: question about drivers/media/usb/gspca/kinect.c
Hi,
Forwarding this to Antonio, the author of the kinect driver, who is
the best person to answer this.
Regards,
Hans
Original Message
Subject: question about drivers/media/usb/gspca/kinect.c
Date: Wed, 25 Dec 2013 20:00:34 +0100 (CET)
From: Julia Lawall
To: hdego...@redhat.com, m.che...@samsung.com, linux-media@vger.kernel.org,
linux-ker...@vger.kernel.org
The following code, in the function send_cmd, looks too concise:
do {
actual_len = kinect_read(udev, ibuf, 0x200);
} while (actual_len == 0);
PDEBUG(D_USBO, "Control reply: %d", res);
if (actual_len < sizeof(*rhdr)) {
pr_err("send_cmd: Input control transfer failed (%d)\n", res);
return res;
}
It seems that actual_len might be less than sizeof(*rhdr) either because
an error code is returned by the call to kinect_read or because a shorter
length is returned than the desired one. In the error code case, I would
guess that one would want to return the error code, but I don't know what
on would want to return in the other case. In any case, res is not
defined by this code, so what is returned is whatever the result of the
previous call to kinect_write happened to be.
How should the code be changed?
thanks,
julia
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] media: soc_camera: rcar_vin: Add preliminary R-Car M2 support
This adds R-Car M2 (R8A7791) VIN support. Both H2 and M2
variants look the same from the driver's point of view,
so use GEN2 id for both.
Changes in V2:
* Used the same (RCAR_GEN2) id for both H2 and M2 variants
since they are no different from the driver's point of view.
Signed-off-by: Valentine Barshak
---
drivers/media/platform/soc_camera/rcar_vin.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 6866bb4..3b1c05a 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -106,7 +106,7 @@
#define VIN_MAX_HEIGHT 2048
enum chip_id {
- RCAR_H2,
+ RCAR_GEN2,
RCAR_H1,
RCAR_M1,
RCAR_E1,
@@ -302,7 +302,7 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
dmr = 0;
break;
case V4L2_PIX_FMT_RGB32:
- if (priv->chip == RCAR_H2 || priv->chip == RCAR_H1 ||
+ if (priv->chip == RCAR_GEN2 || priv->chip == RCAR_H1 ||
priv->chip == RCAR_E1) {
dmr = VNDMR_EXRGB;
break;
@@ -1384,7 +1384,8 @@ static struct soc_camera_host_ops rcar_vin_host_ops = {
};
static struct platform_device_id rcar_vin_id_table[] = {
- { "r8a7790-vin", RCAR_H2 },
+ { "r8a7791-vin", RCAR_GEN2 },
+ { "r8a7790-vin", RCAR_GEN2 },
{ "r8a7779-vin", RCAR_H1 },
{ "r8a7778-vin", RCAR_M1 },
{ "uPD35004-vin", RCAR_E1 },
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: soc_camera: rcar_vin: Add preliminary R-Car M2 support
On 12/26/2013 06:18 PM, Laurent Pinchart wrote:
Hi Valentine,
Thank you for the patch.
On Tuesday 24 December 2013 00:28:06 Valentine Barshak wrote:
This adds R-Car M2 (R8A7791) VIN support.
Signed-off-by: Valentine Barshak
---
drivers/media/platform/soc_camera/rcar_vin.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c index 6866bb4..8b79727
100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -106,6 +106,7 @@
#define VIN_MAX_HEIGHT2048
enum chip_id {
+ RCAR_M2,
RCAR_H2,
What about renaming RCAR_H2 to RCAR_GEN2 instead, and using RCAR_GEN2 for both
r8a7790 and r8a7791 (but keeping the "r8a7790-vin" and "r8a7791-vin" device
IDs as you've done below) ? They're identical so far (at least from what's
implemented in the driver, you might be aware of features specific to the H2
or M2 that are not yet supported but will be implemented in the near future).
Yes, the driver won't see any difference at this point.
The h/w (at least the input data formats supported) seems a bit different
though.
The M2 variant doesn't seem to support 4-bit data (AOT H2).
I'm not aware or any M2 or H2 specific features that need to be implemented in
the near future.
I've preferred to keep them separate just in case.
I wouldn't mind to use the same (GEN2) id for both but we may need to split
them in the future.
RCAR_H1,
RCAR_M1,
@@ -302,8 +303,8 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
dmr = 0;
break;
case V4L2_PIX_FMT_RGB32:
- if (priv->chip == RCAR_H2 || priv->chip == RCAR_H1 ||
- priv->chip == RCAR_E1) {
+ if (priv->chip == RCAR_M2 || priv->chip == RCAR_H2 ||
+ priv->chip == RCAR_H1 || priv->chip == RCAR_E1) {
dmr = VNDMR_EXRGB;
break;
}
@@ -1384,6 +1385,7 @@ static struct soc_camera_host_ops rcar_vin_host_ops =
{ };
static struct platform_device_id rcar_vin_id_table[] = {
+ { "r8a7791-vin", RCAR_M2 },
{ "r8a7790-vin", RCAR_H2 },
{ "r8a7779-vin", RCAR_H1 },
{ "r8a7778-vin", RCAR_M1 },
Thanks,
Val.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCHv2] em28xx: split analog part into a separate module
Em Thu, 26 Dec 2013 12:55:06 +0100
Frank Schäfer escreveu:
> Hi Mauro,
>
> Am 22.12.2013 13:47, schrieb Mauro Carvalho Chehab:
> > Now that dvb-only devices start to happen, it makes sense
> > to split the analog part on a separate module.
> >
> > Signed-off-by: Mauro Carvalho Chehab
> >
> > -
> >
> > This is a respin of https://patchwork.linuxtv.org/patch/17967/
> >
> > v2: add a dev->has_video to signalize if the device has a video interface,
> > and
> > fix some locks
> >
> > Compile-tested only.
> >
> > ---
> > drivers/media/usb/em28xx/Kconfig| 6 +-
> > drivers/media/usb/em28xx/Makefile | 5 +-
> > drivers/media/usb/em28xx/em28xx-cards.c | 94 ++
> > drivers/media/usb/em28xx/em28xx-core.c | 12 +++
> > drivers/media/usb/em28xx/em28xx-video.c | 133
> >
> > drivers/media/usb/em28xx/em28xx.h | 17 ++--
> > 6 files changed, 150 insertions(+), 117 deletions(-)
> >
> > diff --git a/drivers/media/usb/em28xx/Kconfig
> > b/drivers/media/usb/em28xx/Kconfig
> > index d6ba514d31eb..838fc9dbb747 100644
> > --- a/drivers/media/usb/em28xx/Kconfig
> > +++ b/drivers/media/usb/em28xx/Kconfig
> > @@ -1,8 +1,12 @@
> > config VIDEO_EM28XX
> > - tristate "Empia EM28xx USB video capture support"
> > + tristate "Empia EM28xx USB devices support"
> > depends on VIDEO_DEV && I2C
> > select VIDEO_TUNER
> > select VIDEO_TVEEPROM
> > +
> > +config VIDEO_EM28XX_V4L2
> > + tristate "Empia EM28xx analog TV, video capture and/or webcam support"
> > + depends on VIDEO_EM28XX && I2C
> VIDEO_EM28XX already depends on I2C.
>
> > select VIDEOBUF2_VMALLOC
> > select VIDEO_SAA711X if MEDIA_SUBDRV_AUTOSELECT
> > select VIDEO_TVP5150 if MEDIA_SUBDRV_AUTOSELECT
> > diff --git a/drivers/media/usb/em28xx/Makefile
> > b/drivers/media/usb/em28xx/Makefile
> > index ad6d48557940..3e2b6b54817d 100644
> > --- a/drivers/media/usb/em28xx/Makefile
> > +++ b/drivers/media/usb/em28xx/Makefile
> > @@ -1,10 +1,11 @@
> > -em28xx-y +=em28xx-video.o em28xx-i2c.o em28xx-cards.o
> > -em28xx-y +=em28xx-core.o em28xx-vbi.o em28xx-camera.o
> > +em28xx-y +=em28xx-core.o em28xx-i2c.o em28xx-cards.o
> >
> > +em28xx-v4l-objs := em28xx-video.o em28xx-vbi.o em28xx-camera.o
> > em28xx-alsa-objs := em28xx-audio.o
> > em28xx-rc-objs := em28xx-input.o
> >
> > obj-$(CONFIG_VIDEO_EM28XX) += em28xx.o
> > +obj-$(CONFIG_VIDEO_EM28XX_V4L2) += em28xx-v4l.o
> > obj-$(CONFIG_VIDEO_EM28XX_ALSA) += em28xx-alsa.o
> > obj-$(CONFIG_VIDEO_EM28XX_DVB) += em28xx-dvb.o
> > obj-$(CONFIG_VIDEO_EM28XX_RC) += em28xx-rc.o
> > diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
> > b/drivers/media/usb/em28xx/em28xx-cards.c
> > index 36853f16bf97..e1ffd9c6e79d 100644
> > --- a/drivers/media/usb/em28xx/em28xx-cards.c
> > +++ b/drivers/media/usb/em28xx/em28xx-cards.c
> > @@ -2106,7 +2106,7 @@ struct em28xx_board em28xx_boards[] = {
> > },
> > /* 1b80:e1cc Delock 61959
> > * Empia EM2874B + Micronas DRX 3913KA2 + NXP TDA18271HDC2
> > - * mostly the same as MaxMedia UB-425-TC but different remote */
> > +* mostly the same as MaxMedia UB-425-TC but different remote */
> > [EM2874_BOARD_DELOCK_61959] = {
> > .name = "Delock 61959",
> > .tuner_type= TUNER_ABSENT,
> > @@ -2955,11 +2955,12 @@ static void request_module_async(struct work_struct
> > *work)
> > em28xx_init_extension(dev);
> >
> > #if defined(CONFIG_MODULES) && defined(MODULE)
> > + if (!dev->has_video)
> > + request_module("em28xx-v4l2");
> if (dev->has_video)
> What about audio devices ?
Audio only devices don't need em28xx-v4l2. With the current way,
em28xx-video.c doesn't initialize the v4l2 interfaces on those.
> > if (dev->has_audio_class)
> > request_module("snd-usb-audio");
> > else if (dev->has_alsa_audio)
> > request_module("em28xx-alsa");
> > -
> > if (dev->board.has_dvb)
> > request_module("em28xx-dvb");
> > if (dev->board.buttons ||
> > @@ -2988,8 +2989,6 @@ void em28xx_release_resources(struct em28xx *dev)
> > {
> > /*FIXME: I2C IR should be disconnected */
> >
> > - em28xx_release_analog_resources(dev);
> > -
> > if (dev->def_i2c_bus)
> > em28xx_i2c_unregister(dev, 1);
> > em28xx_i2c_unregister(dev, 0);
> > @@ -3014,7 +3013,6 @@ static int em28xx_init_dev(struct em28xx *dev, struct
> > usb_device *udev,
> >struct usb_interface *interface,
> >int minor)
> > {
> > - struct v4l2_ctrl_handler *hdl = &dev->ctrl_handler;
> > int retval;
> > static const char *default_chip_name = "em28xx";
> > const char *chip_name = default_chip_name;
> > @@ -3141,15 +3139,6 @@ static int em28xx_init_dev(struct em28xx *dev,
> > struct usb_device *udev,
> > }
> > }
> >
> > - retval = v4l2_device_register(&interface->dev, &dev->v4l2_dev);
> > -
Re: [PATCH] media: soc_camera: rcar_vin: Add preliminary R-Car M2 support
Hi Valentine,
Thank you for the patch.
On Tuesday 24 December 2013 00:28:06 Valentine Barshak wrote:
> This adds R-Car M2 (R8A7791) VIN support.
>
> Signed-off-by: Valentine Barshak
> ---
> drivers/media/platform/soc_camera/rcar_vin.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
> b/drivers/media/platform/soc_camera/rcar_vin.c index 6866bb4..8b79727
> 100644
> --- a/drivers/media/platform/soc_camera/rcar_vin.c
> +++ b/drivers/media/platform/soc_camera/rcar_vin.c
> @@ -106,6 +106,7 @@
> #define VIN_MAX_HEIGHT 2048
>
> enum chip_id {
> + RCAR_M2,
> RCAR_H2,
What about renaming RCAR_H2 to RCAR_GEN2 instead, and using RCAR_GEN2 for both
r8a7790 and r8a7791 (but keeping the "r8a7790-vin" and "r8a7791-vin" device
IDs as you've done below) ? They're identical so far (at least from what's
implemented in the driver, you might be aware of features specific to the H2
or M2 that are not yet supported but will be implemented in the near future).
> RCAR_H1,
> RCAR_M1,
> @@ -302,8 +303,8 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
> dmr = 0;
> break;
> case V4L2_PIX_FMT_RGB32:
> - if (priv->chip == RCAR_H2 || priv->chip == RCAR_H1 ||
> - priv->chip == RCAR_E1) {
> + if (priv->chip == RCAR_M2 || priv->chip == RCAR_H2 ||
> + priv->chip == RCAR_H1 || priv->chip == RCAR_E1) {
> dmr = VNDMR_EXRGB;
> break;
> }
> @@ -1384,6 +1385,7 @@ static struct soc_camera_host_ops rcar_vin_host_ops =
> { };
>
> static struct platform_device_id rcar_vin_id_table[] = {
> + { "r8a7791-vin", RCAR_M2 },
> { "r8a7790-vin", RCAR_H2 },
> { "r8a7779-vin", RCAR_H1 },
> { "r8a7778-vin", RCAR_M1 },
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A list of Linux drivers
Peter, Thank you for the reply. But I would like to use a USB tuner with my satelite receiver( as the second tuner) and not sure which tuner will suit the best my needs. So I wonder if there is a list of tuners (with Linux drivers) that I can choose from . Or can anyone advice a good/cheap DVB-S2 USB tuner? Preferably with open source driver Thank you for your reply. > Check the file: drivers/media/tuners/Kconfig > > On Thu, Dec 26, 2013 at 12:03 PM, Jahn wrote: > > Is there available a list of tuners that are supported in Linux ( > those that have a driver) > preferably in MIPS Linux ? > Thanks > > -- > > 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 > > > > -- > Peter > -- > 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: A list of Linux drivers
Check the file: drivers/media/tuners/Kconfig On Thu, Dec 26, 2013 at 12:03 PM, Jahn wrote: > Is there available a list of tuners that are supported in Linux ( those > that have a driver) > preferably in MIPS Linux ? > Thanks > > -- > 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 -- Peter -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCHv2] em28xx: split analog part into a separate module
Hi Mauro,
Am 22.12.2013 13:47, schrieb Mauro Carvalho Chehab:
> Now that dvb-only devices start to happen, it makes sense
> to split the analog part on a separate module.
>
> Signed-off-by: Mauro Carvalho Chehab
>
> -
>
> This is a respin of https://patchwork.linuxtv.org/patch/17967/
>
> v2: add a dev->has_video to signalize if the device has a video interface, and
> fix some locks
>
> Compile-tested only.
>
> ---
> drivers/media/usb/em28xx/Kconfig| 6 +-
> drivers/media/usb/em28xx/Makefile | 5 +-
> drivers/media/usb/em28xx/em28xx-cards.c | 94 ++
> drivers/media/usb/em28xx/em28xx-core.c | 12 +++
> drivers/media/usb/em28xx/em28xx-video.c | 133
>
> drivers/media/usb/em28xx/em28xx.h | 17 ++--
> 6 files changed, 150 insertions(+), 117 deletions(-)
>
> diff --git a/drivers/media/usb/em28xx/Kconfig
> b/drivers/media/usb/em28xx/Kconfig
> index d6ba514d31eb..838fc9dbb747 100644
> --- a/drivers/media/usb/em28xx/Kconfig
> +++ b/drivers/media/usb/em28xx/Kconfig
> @@ -1,8 +1,12 @@
> config VIDEO_EM28XX
> - tristate "Empia EM28xx USB video capture support"
> + tristate "Empia EM28xx USB devices support"
> depends on VIDEO_DEV && I2C
> select VIDEO_TUNER
> select VIDEO_TVEEPROM
> +
> +config VIDEO_EM28XX_V4L2
> + tristate "Empia EM28xx analog TV, video capture and/or webcam support"
> + depends on VIDEO_EM28XX && I2C
VIDEO_EM28XX already depends on I2C.
> select VIDEOBUF2_VMALLOC
> select VIDEO_SAA711X if MEDIA_SUBDRV_AUTOSELECT
> select VIDEO_TVP5150 if MEDIA_SUBDRV_AUTOSELECT
> diff --git a/drivers/media/usb/em28xx/Makefile
> b/drivers/media/usb/em28xx/Makefile
> index ad6d48557940..3e2b6b54817d 100644
> --- a/drivers/media/usb/em28xx/Makefile
> +++ b/drivers/media/usb/em28xx/Makefile
> @@ -1,10 +1,11 @@
> -em28xx-y += em28xx-video.o em28xx-i2c.o em28xx-cards.o
> -em28xx-y += em28xx-core.o em28xx-vbi.o em28xx-camera.o
> +em28xx-y += em28xx-core.o em28xx-i2c.o em28xx-cards.o
>
> +em28xx-v4l-objs := em28xx-video.o em28xx-vbi.o em28xx-camera.o
> em28xx-alsa-objs := em28xx-audio.o
> em28xx-rc-objs := em28xx-input.o
>
> obj-$(CONFIG_VIDEO_EM28XX) += em28xx.o
> +obj-$(CONFIG_VIDEO_EM28XX_V4L2) += em28xx-v4l.o
> obj-$(CONFIG_VIDEO_EM28XX_ALSA) += em28xx-alsa.o
> obj-$(CONFIG_VIDEO_EM28XX_DVB) += em28xx-dvb.o
> obj-$(CONFIG_VIDEO_EM28XX_RC) += em28xx-rc.o
> diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
> b/drivers/media/usb/em28xx/em28xx-cards.c
> index 36853f16bf97..e1ffd9c6e79d 100644
> --- a/drivers/media/usb/em28xx/em28xx-cards.c
> +++ b/drivers/media/usb/em28xx/em28xx-cards.c
> @@ -2106,7 +2106,7 @@ struct em28xx_board em28xx_boards[] = {
> },
> /* 1b80:e1cc Delock 61959
>* Empia EM2874B + Micronas DRX 3913KA2 + NXP TDA18271HDC2
> - * mostly the same as MaxMedia UB-425-TC but different remote */
> + * mostly the same as MaxMedia UB-425-TC but different remote */
> [EM2874_BOARD_DELOCK_61959] = {
> .name = "Delock 61959",
> .tuner_type= TUNER_ABSENT,
> @@ -2955,11 +2955,12 @@ static void request_module_async(struct work_struct
> *work)
> em28xx_init_extension(dev);
>
> #if defined(CONFIG_MODULES) && defined(MODULE)
> + if (!dev->has_video)
> + request_module("em28xx-v4l2");
if (dev->has_video)
What about audio devices ?
> if (dev->has_audio_class)
> request_module("snd-usb-audio");
> else if (dev->has_alsa_audio)
> request_module("em28xx-alsa");
> -
> if (dev->board.has_dvb)
> request_module("em28xx-dvb");
> if (dev->board.buttons ||
> @@ -2988,8 +2989,6 @@ void em28xx_release_resources(struct em28xx *dev)
> {
> /*FIXME: I2C IR should be disconnected */
>
> - em28xx_release_analog_resources(dev);
> -
> if (dev->def_i2c_bus)
> em28xx_i2c_unregister(dev, 1);
> em28xx_i2c_unregister(dev, 0);
> @@ -3014,7 +3013,6 @@ static int em28xx_init_dev(struct em28xx *dev, struct
> usb_device *udev,
> struct usb_interface *interface,
> int minor)
> {
> - struct v4l2_ctrl_handler *hdl = &dev->ctrl_handler;
> int retval;
> static const char *default_chip_name = "em28xx";
> const char *chip_name = default_chip_name;
> @@ -3141,15 +3139,6 @@ static int em28xx_init_dev(struct em28xx *dev, struct
> usb_device *udev,
> }
> }
>
> - retval = v4l2_device_register(&interface->dev, &dev->v4l2_dev);
> - if (retval < 0) {
> - em28xx_errdev("Call to v4l2_device_register() failed!\n");
> - return retval;
> - }
> -
> - v4l2_ctrl_handler_init(hdl, 8);
> - dev->v4l2_dev.ctrl_handler = hdl;
> -
> rt_mutex_init(&dev->i2c_bus_lock);
>
> /* register i2c bus 0 */
> @@ -3178,75 +3167,11 @@ static int em28xx_init_dev(struct em28xx *d
[PATCH v3.5 13/19] media: dvb_core: slight optimization of addr compare
Use possibly more efficient ether_addr_equal
instead of memcmp.
Cc: Mauro Carvalho Chehab
Cc: linux-media@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Yang Yingliang
Signed-off-by: Ding Tianhong
---
drivers/media/dvb-core/dvb_net.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb-core/dvb_net.c b/drivers/media/dvb-core/dvb_net.c
index f91c80c..8a86b30 100644
--- a/drivers/media/dvb-core/dvb_net.c
+++ b/drivers/media/dvb-core/dvb_net.c
@@ -179,7 +179,7 @@ static __be16 dvb_net_eth_type_trans(struct sk_buff *skb,
eth = eth_hdr(skb);
if (*eth->h_dest & 1) {
- if(memcmp(eth->h_dest,dev->broadcast, ETH_ALEN)==0)
+ if(ether_addr_equal(eth->h_dest,dev->broadcast))
skb->pkt_type=PACKET_BROADCAST;
else
skb->pkt_type=PACKET_MULTICAST;
@@ -674,11 +674,13 @@ static void dvb_net_ule( struct net_device *dev, const u8
*buf, size_t buf_len )
if (priv->rx_mode != RX_MODE_PROMISC) {
if (priv->ule_skb->data[0] &
0x01) {
/* multicast or
broadcast */
- if
(memcmp(priv->ule_skb->data, bc_addr, ETH_ALEN)) {
+ if
(!ether_addr_equal(priv->ule_skb->data, bc_addr)) {
/* multicast */
if
(priv->rx_mode == RX_MODE_MULTI) {
int i;
- for(i =
0; i < priv->multi_num && memcmp(priv->ule_skb->data, priv->multi_macs[i],
ETH_ALEN); i++)
+ for(i =
0; i < priv->multi_num &&
+
!ether_addr_equal(priv->ule_skb->data,
+
priv->multi_macs[i]); i++)
;
if (i
== priv->multi_num)
drop = 1;
@@ -688,7 +690,7 @@ static void dvb_net_ule( struct net_device *dev, const u8
*buf, size_t buf_len )
}
/* else: broadcast */
}
- else if
(memcmp(priv->ule_skb->data, dev->dev_addr, ETH_ALEN))
+ else if
(!ether_addr_equal(priv->ule_skb->data, dev->dev_addr))
drop = 1;
/* else: destination address
matches the MAC address of our receiver device */
}
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 13/19] media: dvb_core: slight optimization of addr compare
On 2013/12/25 18:57, Sergei Shtylyov wrote:
> Hello.
>
> On 25-12-2013 7:29, Ding Tianhong wrote:
>
>> Use possibly more efficient ether_addr_equal
>> instead of memcmp.
>
>> Cc: Mauro Carvalho Chehab
>> Cc: linux-media@vger.kernel.org
>> Cc: linux-ker...@vger.kernel.org
>> Signed-off-by: Yang Yingliang
>> Signed-off-by: Ding Tianhong
>> ---
>> drivers/media/dvb-core/dvb_net.c | 8
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>
>> diff --git a/drivers/media/dvb-core/dvb_net.c
>> b/drivers/media/dvb-core/dvb_net.c
>> index f91c80c..3dfc33b 100644
>> --- a/drivers/media/dvb-core/dvb_net.c
>> +++ b/drivers/media/dvb-core/dvb_net.c
>> @@ -179,7 +179,7 @@ static __be16 dvb_net_eth_type_trans(struct sk_buff *skb,
>> eth = eth_hdr(skb);
>>
>> if (*eth->h_dest & 1) {
>> -if(memcmp(eth->h_dest,dev->broadcast, ETH_ALEN)==0)
>> +if(ether_addr_equal(eth->h_dest,dev->broadcast))
>
>There should be space after comma.
>
>> @@ -674,11 +674,11 @@ static void dvb_net_ule( struct net_device *dev, const
>> u8 *buf, size_t buf_len )
>> if (priv->rx_mode != RX_MODE_PROMISC) {
>> if (priv->ule_skb->data[0] & 0x01) {
>> /* multicast or broadcast */
>> -if (memcmp(priv->ule_skb->data, bc_addr,
>> ETH_ALEN)) {
>> +if (!ether_addr_equal(priv->ule_skb->data,
>> bc_addr)) {
>> /* multicast */
>> if (priv->rx_mode == RX_MODE_MULTI) {
>> int i;
>> -for(i = 0; i < priv->multi_num &&
>> memcmp(priv->ule_skb->data, priv->multi_macs[i], ETH_ALEN); i++)
>> +for(i = 0; i < priv->multi_num &&
>> !ether_addr_equal(priv->ule_skb->data, priv->multi_macs[i]); i++)
>
>Shouldn't this line be broken?
>
ok, thanks.
Regards
>> ;
>> if (i == priv->multi_num)
>> drop = 1;
>
> WBR, Sergei
>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
A list of Linux drivers
Is there available a list of tuners that are supported in Linux ( those that have a driver) preferably in MIPS Linux ? Thanks -- 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
