Re: [PATCH] media: soc_camera: rcar_vin: Enable VSYNC field toggle mode
Hi Kaneko-san,
On Tue, Oct 21, 2014 at 5:30 AM, Yoshihiro Kaneko ykaneko0...@gmail.com wrote:
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -108,6 +108,7 @@
#define VNDMR2_VPS(1 30)
#define VNDMR2_HPS(1 29)
#define VNDMR2_FTEV (1 17)
+#define VNDMR2_VLV_1 (1 12)
Please instead do:
#define VNDMR2_VLV(n) ((n 0xf) 12)
It's unclear to me why the style of the new #define should differ
from those of the existing ones.
I think Sergey wants to say that unlike for the other fields, there are
multiple possible values for the VLV field.
By providing the single macro definition
#define VNDMR2_VLV(n) ((n 0xf) 12)
you can easily provide a way to set any of VNDMR2_VLV_n.
I hope this explanation makes it clearer.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2 1/4] Add a media device configuration file parser.
Hi Sakari,
On 10/20/2014 11:44 PM, Sakari Ailus wrote:
Hi Jacek,
On Fri, Oct 17, 2014 at 04:54:39PM +0200, Jacek Anaszewski wrote:
This patch adds a parser for a media device configuration
file. The parser expects the configuration file containing
links end v4l2-controls definitions as described in the
header file being added. The links describe connections
between media entities and v4l2-controls define the target
sub-devices for particular user controls related ioctl calls.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Mauro Carvalho Chehab mche...@osg.samsung.com
Cc: Hans Verkuil hans.verk...@cisco.com
---
lib/include/libv4l2-media-conf-parser.h | 148 +++
lib/libv4l2/libv4l2-media-conf-parser.c | 441 +++
2 files changed, 589 insertions(+)
create mode 100644 lib/include/libv4l2-media-conf-parser.h
create mode 100644 lib/libv4l2/libv4l2-media-conf-parser.c
diff --git a/lib/include/libv4l2-media-conf-parser.h
b/lib/include/libv4l2-media-conf-parser.h
new file mode 100644
index 000..b2dba3a
--- /dev/null
+++ b/lib/include/libv4l2-media-conf-parser.h
@@ -0,0 +1,148 @@
+/*
+ * Parser of media device configuration file.
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Author: Jacek Anaszewski j.anaszew...@samsung.com
+ *
+ * The configuration file has to comply with following format:
+ *
+ * Link description entry format:
+ *
+ * link {
+ * TABsource_entity: entity_nameLF
+ * TABsource_pad: pad_idLF
+ * TABsink_entity: entity_nameLF
+ * TABsink_pad: pad_idLF
+ * }
Could you use the existing libmediactl format? The parser exists as well.
Of course, I will switch to using it.
As a matter of fact, I have a few patches to make it easier to user in a
library.
libmediactl appears to be located under utils/media-ctl. Perhaps it's be
better placed under lib. Cc Laurent.
+ * The V4L2 control group format:
+ *
+ * v4l2-controls {
+ * TABcontrol1_name: entity_nameLF
+ * TABcontrol2_name: entity_nameLF
+ * ...
+ * TABcontrolN_name: entity_nameLF
+ * }
I didn't know you were working on this.
Actually I did the main part of work around 1,5 year ago as a part
of familiarizing myself with V4L2 media controller API.
I have a small library which does essentially the same. The implementation
is incomplete, that's why I hadn't posted it to the list. We could perhaps
discuss this a little bit tomorrow. When would you be available, in case you
are?
I will be available around 8 hours from now on.
What would you think of using a little bit more condensed format for this,
similar to that of libmediactl?
Could you spot a place where the format is defined?
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 07/14] [media] s5p-mfc: Don't crash the kernel if the watchdog kicks in.
Hi Kamil,
Kiran will not be available to handle review comments of these patches.
So I will be pushing the updated patchset rebased on media-tree.
I hope all patches are good to merge except
[media] s5p-mfc: Don't change the image size to smaller than the request.
I will drop this one patch and send all others in v3 version.
Regards
Arun
On Wed, Oct 8, 2014 at 3:56 PM, Kamil Debski k.deb...@samsung.com wrote:
Hi,
This patch does not apply to the current media tree.
commit cf3167cf1e969b17671a4d3d956d22718a8ceb85)
Author: Antti Palosaari cr...@iki.fi
Date: Fri Sep 26 22:45:36 2014 -0300
[media] pt3: fix DTV FE I2C driver load error paths
Best wishes,
--
Kamil Debski
Samsung RD Institute Poland
-Original Message-
From: Kiran AVND [mailto:avnd.ki...@samsung.com]
Sent: Friday, September 26, 2014 6:52 AM
To: linux-media@vger.kernel.org
Cc: k.deb...@samsung.com; wuchen...@chromium.org; posc...@chromium.org;
aru...@samsung.com; i...@chromium.org; prathyus...@samsung.com;
arun...@samsung.com; ki...@chromium.org
Subject: [PATCH v2 07/14] [media] s5p-mfc: Don't crash the kernel if
the watchdog kicks in.
From: Pawel Osciak posc...@chromium.org
If the software watchdog kicks in, the watchdog worker is not
synchronized with hardware interrupts and does not block other
instances. It's possible for it to clear the hw_lock, making other
instances trigger a BUG() on hw_lock checks. Since it's not fatal to
clear the hw_lock to zero twice, just WARN in those cases for now. We
should not explode, as firmware will return errors as needed for other
instances after it's reloaded, or they will time out.
A clean fix should involve killing other instances when watchdog kicks
in, but requires a major redesign of locking in the driver.
Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc.c | 25 +++---
---
1 file changed, 7 insertions(+), 18 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 3fc2f8a..8d5da0c 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -337,8 +337,7 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx
*ctx,
ctx-state = MFCINST_RES_CHANGE_INIT;
s5p_mfc_hw_call(dev-mfc_ops, clear_int_flags, dev);
wake_up_ctx(ctx, reason, err);
- if (test_and_clear_bit(0, dev-hw_lock) == 0)
- BUG();
+ WARN_ON(test_and_clear_bit(0, dev-hw_lock) == 0);
s5p_mfc_clock_off();
s5p_mfc_hw_call(dev-mfc_ops, try_run, dev);
return;
@@ -410,8 +409,7 @@ leave_handle_frame:
clear_work_bit(ctx);
s5p_mfc_hw_call(dev-mfc_ops, clear_int_flags, dev);
wake_up_ctx(ctx, reason, err);
- if (test_and_clear_bit(0, dev-hw_lock) == 0)
- BUG();
+ WARN_ON(test_and_clear_bit(0, dev-hw_lock) == 0);
s5p_mfc_clock_off();
/* if suspending, wake up device and do not try_run again*/
if (test_bit(0, dev-enter_suspend))
@@ -458,8 +456,7 @@ static void s5p_mfc_handle_error(struct s5p_mfc_dev
*dev,
break;
}
}
- if (test_and_clear_bit(0, dev-hw_lock) == 0)
- BUG();
+ WARN_ON(test_and_clear_bit(0, dev-hw_lock) == 0);
s5p_mfc_hw_call(dev-mfc_ops, clear_int_flags, dev);
s5p_mfc_clock_off();
wake_up_dev(dev, reason, err);
@@ -513,8 +510,7 @@ static void s5p_mfc_handle_seq_done(struct
s5p_mfc_ctx *ctx,
}
s5p_mfc_hw_call(dev-mfc_ops, clear_int_flags, dev);
clear_work_bit(ctx);
- if (test_and_clear_bit(0, dev-hw_lock) == 0)
- BUG();
+ WARN_ON(test_and_clear_bit(0, dev-hw_lock) == 0);
s5p_mfc_clock_off();
s5p_mfc_hw_call(dev-mfc_ops, try_run, dev);
wake_up_ctx(ctx, reason, err);
@@ -552,19 +548,13 @@ static void s5p_mfc_handle_init_buffers(struct
s5p_mfc_ctx *ctx,
} else {
ctx-dpb_flush_flag = 0;
}
- if (test_and_clear_bit(0, dev-hw_lock) == 0)
- BUG();
-
+ WARN_ON(test_and_clear_bit(0, dev-hw_lock) == 0);
s5p_mfc_clock_off();
-
wake_up(ctx-queue);
s5p_mfc_hw_call(dev-mfc_ops, try_run, dev);
} else {
- if (test_and_clear_bit(0, dev-hw_lock) == 0)
- BUG();
-
+ WARN_ON(test_and_clear_bit(0, dev-hw_lock) == 0);
s5p_mfc_clock_off();
-
wake_up(ctx-queue);
}
}
@@ -638,8 +628,7 @@ static irqreturn_t s5p_mfc_irq(int irq, void *priv)
mfc_err(post_frame_start() failed\n);
s5p_mfc_hw_call(dev-mfc_ops, clear_int_flags, dev);
Re: [PATCH/RFC v2 1/4] Add a media device configuration file parser.
Hi Jacek,
On Tue, Oct 21, 2014 at 09:17:00AM +0200, Jacek Anaszewski wrote:
...
+ * The V4L2 control group format:
+ *
+ * v4l2-controls {
+ * TABcontrol1_name: entity_nameLF
+ * TABcontrol2_name: entity_nameLF
+ * ...
+ * TABcontrolN_name: entity_nameLF
+ * }
I didn't know you were working on this.
Actually I did the main part of work around 1,5 year ago as a part
of familiarizing myself with V4L2 media controller API.
:-D
I think it's about time we get things like this to libv4l.
I have a small library which does essentially the same. The implementation
is incomplete, that's why I hadn't posted it to the list. We could perhaps
discuss this a little bit tomorrow. When would you be available, in case you
are?
I will be available around 8 hours from now on.
I couldn't see you on #v4l, would an hour from now (13:30 Finnish time) be
ok for you?
What would you think of using a little bit more condensed format for this,
similar to that of libmediactl?
Could you spot a place where the format is defined?
At the moment there's none, but I thought of a similar format used by
libmediactl.
--
Cheers,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2 1/4] Add a media device configuration file parser.
Hi Sakari,
On 10/21/2014 11:26 AM, Sakari Ailus wrote:
Hi Jacek,
On Tue, Oct 21, 2014 at 09:17:00AM +0200, Jacek Anaszewski wrote:
...
+ * The V4L2 control group format:
+ *
+ * v4l2-controls {
+ * TABcontrol1_name: entity_nameLF
+ * TABcontrol2_name: entity_nameLF
+ * ...
+ * TABcontrolN_name: entity_nameLF
+ * }
I didn't know you were working on this.
Actually I did the main part of work around 1,5 year ago as a part
of familiarizing myself with V4L2 media controller API.
:-D
I think it's about time we get things like this to libv4l.
Definitely :)
I have a small library which does essentially the same. The implementation
is incomplete, that's why I hadn't posted it to the list. We could perhaps
discuss this a little bit tomorrow. When would you be available, in case you
are?
I will be available around 8 hours from now on.
I couldn't see you on #v4l, would an hour from now (13:30 Finnish time) be
ok for you?
What about 14:00 Finnish time?
What would you think of using a little bit more condensed format for this,
similar to that of libmediactl?
Could you spot a place where the format is defined?
At the moment there's none, but I thought of a similar format used by
libmediactl.
OK, to be discussed.
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] media: soc_camera: rcar_vin: Add BT.709 24-bit RGB888 input support
Hello.
On 10/21/2014 9:08 AM, Yoshihiro Kaneko wrote:
From: Koji Matsuoka koji.matsuoka...@renesas.com
Signed-off-by: Koji Matsuoka koji.matsuoka...@renesas.com
Signed-off-by: Yoshihiro Kaneko ykaneko0...@gmail.com
---
This patch is against master branch of linuxtv.org/media_tree.git.
v2 [Yoshihiro Kaneko]
* remove unused/useless definition as suggested by Sergei Shtylyov
I didn't say it's useless, I just suspected that you missed the necessary
test somewhere...
drivers/media/platform/soc_camera/rcar_vin.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 20defcb..cb5e682 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -74,6 +74,7 @@
#define VNMC_INF_YUV10_BT656 (2 16)
#define VNMC_INF_YUV10_BT601 (3 16)
#define VNMC_INF_YUV16(5 16)
+#define VNMC_INF_RGB888(6 16)
#define VNMC_VUP (1 10)
#define VNMC_IM_ODD (0 3)
#define VNMC_IM_ODD_EVEN (1 3)
[...]
@@ -331,6 +336,9 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
if (output_is_yuv)
vnmc |= VNMC_BPS;
+ if (vnmc VNMC_INF_RGB888)
+ vnmc ^= VNMC_BPS;
+
Hm, this also changes the behavior for VNMC_INF_YUV16 and
VNMC_INF_YUV10_BT{601|656}. Is this actually intended?
[...]
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[v4l-utils RFC 1/2] mediactl: Separate entity and pad parsing
Sometimes it's useful to be able to parse the entity independent of the pad.
Separate entity parsing into media_parse_entity().
Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com
---
utils/media-ctl/libmediactl.c | 28
utils/media-ctl/mediactl.h| 14 ++
2 files changed, 38 insertions(+), 4 deletions(-)
diff --git a/utils/media-ctl/libmediactl.c b/utils/media-ctl/libmediactl.c
index ec360bd..e17d86e 100644
--- a/utils/media-ctl/libmediactl.c
+++ b/utils/media-ctl/libmediactl.c
@@ -770,10 +770,10 @@ int media_device_add_entity(struct media_device *media,
return 0;
}
-struct media_pad *media_parse_pad(struct media_device *media,
- const char *p, char **endp)
+struct media_entity *media_parse_entity(struct media_device *media,
+ const char *p, char **endp)
{
- unsigned int entity_id, pad;
+ unsigned int entity_id;
struct media_entity *entity;
char *end;
@@ -810,7 +810,27 @@ struct media_pad *media_parse_pad(struct media_device
*media,
return NULL;
}
}
- for (; isspace(*end); ++end);
+ for (p = end; isspace(*p); ++p);
+
+ *endp = (char *)p;
+
+ return entity;
+}
+
+struct media_pad *media_parse_pad(struct media_device *media,
+ const char *p, char **endp)
+{
+ unsigned int pad;
+ struct media_entity *entity;
+ char *end;
+
+ if (endp == NULL)
+ endp = end;
+
+ entity = media_parse_entity(media, p, end);
+ if (!entity)
+ return NULL;
+ *endp = end;
if (*end != ':') {
media_dbg(media, Expected ':'\n, *end);
diff --git a/utils/media-ctl/mediactl.h b/utils/media-ctl/mediactl.h
index 77ac182..3faee71 100644
--- a/utils/media-ctl/mediactl.h
+++ b/utils/media-ctl/mediactl.h
@@ -368,6 +368,20 @@ int media_setup_link(struct media_device *media,
int media_reset_links(struct media_device *media);
/**
+ * @brief Parse string to an entity on the media device.
+ * @param media - media device.
+ * @param p - input string
+ * @param endp - pointer to string where parsing ended
+ *
+ * Parse NULL terminated string describing an entity and return its
+ * struct media_entity instance.
+ *
+ * @return Pointer to struct media_entity on success, NULL on failure.
+ */
+struct media_entity *media_parse_entity(struct media_device *media,
+ const char *p, char **endp);
+
+/**
* @brief Parse string to a pad on the media device.
* @param media - media device.
* @param p - input string
--
2.1.0.231.g7484e3b
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[v4l-utils RFC 0/2] libmediatext library
Hi, This is a tiny library for parsing text-based media link, V4L2 sub-device format (and selection) configurations as well as controls with limited types. This is hardly ready as such but what's there should work. -- Regards, Sakari -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[v4l-utils RFC 2/2] mediatext: Add library
libmediatext is a helper library for converting configurations (Media
controller links, V4L2 controls and V4L2 sub-device media bus formats and
selections) from text-based form into IOCTLs.
libmediatext depends on libv4l2subdev and libmediactl.
Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com
Signed-off-by: Teemu Tuominen teemu.tuomi...@intel.com
---
libmediatext.pc.in | 10 ++
utils/media-ctl/Makefile.am| 10 +-
utils/media-ctl/libmediatext.pc.in | 10 ++
utils/media-ctl/mediatext-test.c | 65
utils/media-ctl/mediatext.c| 210 +
utils/media-ctl/mediatext.h| 29 +
6 files changed, 332 insertions(+), 2 deletions(-)
create mode 100644 libmediatext.pc.in
create mode 100644 utils/media-ctl/libmediatext.pc.in
create mode 100644 utils/media-ctl/mediatext-test.c
create mode 100644 utils/media-ctl/mediatext.c
create mode 100644 utils/media-ctl/mediatext.h
diff --git a/libmediatext.pc.in b/libmediatext.pc.in
new file mode 100644
index 000..6aa6353
--- /dev/null
+++ b/libmediatext.pc.in
@@ -0,0 +1,10 @@
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+libdir=@libdir@
+includedir=@includedir@
+
+Name: libmediatext
+Description: Media controller and V4L2 text-based configuration library
+Version: @PACKAGE_VERSION@
+Cflags: -I${includedir}
+Libs: -L${libdir} -lmediatext
diff --git a/utils/media-ctl/Makefile.am b/utils/media-ctl/Makefile.am
index a3931fb..3e883e0 100644
--- a/utils/media-ctl/Makefile.am
+++ b/utils/media-ctl/Makefile.am
@@ -1,4 +1,4 @@
-noinst_LTLIBRARIES = libmediactl.la libv4l2subdev.la
+noinst_LTLIBRARIES = libmediactl.la libv4l2subdev.la libmediatext.la
libmediactl_la_SOURCES = libmediactl.c mediactl-priv.h
libmediactl_la_CFLAGS = -static $(LIBUDEV_CFLAGS)
@@ -9,9 +9,15 @@ libv4l2subdev_la_LIBADD = libmediactl.la
libv4l2subdev_la_CFLAGS = -static
libv4l2subdev_la_LDFLAGS = -static
+libmediatext_la_SOURCES = mediatext.c
+libmediatext_la_CFLAGS = -static $(LIBUDEV_CFLAGS)
+libmediatext_la_LDFLAGS = -static $(LIBUDEV_LIBS)
+
mediactl_includedir=$(includedir)/mediactl
noinst_HEADERS = mediactl.h v4l2subdev.h
-bin_PROGRAMS = media-ctl
+bin_PROGRAMS = media-ctl mediatext-test
media_ctl_SOURCES = media-ctl.c options.c options.h tools.h
media_ctl_LDADD = libmediactl.la libv4l2subdev.la
+mediatext_test_SOURCES = mediatext-test.c
+mediatext_test_LDADD = libmediatext.la libmediactl.la libv4l2subdev.la
diff --git a/utils/media-ctl/libmediatext.pc.in
b/utils/media-ctl/libmediatext.pc.in
new file mode 100644
index 000..6aa6353
--- /dev/null
+++ b/utils/media-ctl/libmediatext.pc.in
@@ -0,0 +1,10 @@
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+libdir=@libdir@
+includedir=@includedir@
+
+Name: libmediatext
+Description: Media controller and V4L2 text-based configuration library
+Version: @PACKAGE_VERSION@
+Cflags: -I${includedir}
+Libs: -L${libdir} -lmediatext
diff --git a/utils/media-ctl/mediatext-test.c b/utils/media-ctl/mediatext-test.c
new file mode 100644
index 000..296b8c0
--- /dev/null
+++ b/utils/media-ctl/mediatext-test.c
@@ -0,0 +1,65 @@
+/*
+ * libmediatext test program
+ *
+ * Copyright (C) 2013 Intel Corporation
+ *
+ * Contact: Sakari Ailus sakari.ai...@linux.intel.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; either version 2.1 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include stdio.h
+#include stdlib.h
+#include string.h
+
+#include mediactl.h
+#include mediatext.h
+
+int main(int argc, char *argv[])
+{
+ struct media_device *device;
+ int rval;
+
+ if (argc != 3) {
+ fprintf(stderr, usage: %s media device string\n\n,
argv[0]);
+ fprintf(stderr, \tstring := [ v4l2-ctrl |�v4l2-mbus |
link-reset | link-conf]\n\n);
+ fprintf(stderr, \tv4l2-ctrl := \entity\ ctrl_type ctrl_id
ctrl_value\n);
+ fprintf(stderr, \tctrl_type := [ int | int64 | bitmask ]\n);
+ fprintf(stderr, \tctrl_value := [ %%d | %%PRId64 |
bitmask_value ]\n);
+ fprintf(stderr, \tbitmask_value := bbinary_number\n\n);
+ fprintf(stderr, \tv4l2-mbus := \n);
+ fprintf(stderr, \tlink-conf := \entity\:pad -
\entity\:pad[link-flags]\n);
+ return EXIT_FAILURE;
+ }
+
+ device = media_device_new(argv[1]);
+ if (!device)
+ return EXIT_FAILURE;
+
+
Re: [PATCH v2 1/6] media: add media token device resource framework
Hi Shuah,
As promised, here is my review for this patch series.
On 10/14/2014 04:58 PM, Shuah Khan wrote:
Add media token device resource framework to allow sharing
resources such as tuner, dma, audio etc. across media drivers
and non-media sound drivers that control media hardware. The
Media token resource is created at the main struct device that
is common to all drivers that claim various pieces of the main
media device, which allows them to find the resource using the
main struct device. As an example, digital, analog, and
snd-usb-audio drivers can use the media token resource API
using the main struct device for the interface the media device
is attached to.
A shared media tokens resource is created using devres framework
for drivers to find and lock/unlock. Creating a shared devres
helps avoid creating data structure dependencies between drivers.
This media token resource contains media token for tuner, and
audio. When tuner token is requested, audio token is issued.
Did you mean: 'tuner token is issued' instead of audio token?
I also have the same question as Takashi: why do we have an audio
token in the first place? While you are streaming audio over alsa
the underlying tuner must be marked as being in use. It's all about
the tuner, since that's the resource that is being shared, not about
audio as such.
For the remainder of my review I will ignore the audio-related code
and concentrate only on the tuner part.
Subsequent token (for tuner and audio) gets from the same task
and task in the same tgid succeed. This allows applications that
make multiple v4l2 ioctls to work with the first call acquiring
the token and applications that create separate threads to handle
video and audio functions.
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
MAINTAINERS |2 +
include/linux/media_tknres.h | 50 +
lib/Makefile |2 +
lib/media_tknres.c | 237 ++
I am still not convinced myself that this should be a generic API.
The only reason we need it today is for sharing tuners. Which is almost
a purely media thing with USB audio as the single non-media driver that
will be affected. Today I see no use case outside of tuners. I would
probably want to keep this inside drivers/media.
If this is going to be expanded it can always be moved to lib later.
4 files changed, 291 insertions(+)
create mode 100644 include/linux/media_tknres.h
create mode 100644 lib/media_tknres.c
diff --git a/MAINTAINERS b/MAINTAINERS
index e80a275..9216179 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5864,6 +5864,8 @@ F:include/uapi/linux/v4l2-*
F:include/uapi/linux/meye.h
F:include/uapi/linux/ivtv*
F:include/uapi/linux/uvcvideo.h
+F: include/linux/media_tknres.h
+F: lib/media_tknres.c
MEDIAVISION PRO MOVIE STUDIO DRIVER
M:Hans Verkuil hverk...@xs4all.nl
diff --git a/include/linux/media_tknres.h b/include/linux/media_tknres.h
new file mode 100644
index 000..6d37327
--- /dev/null
+++ b/include/linux/media_tknres.h
@@ -0,0 +1,50 @@
+/*
+ * media_tknres.h - managed media token resource
+ *
+ * Copyright (c) 2014 Shuah Khan shua...@osg.samsung.com
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ *
+ * This file is released under the GPLv2.
+ */
+#ifndef __LINUX_MEDIA_TOKEN_H
+#define __LINUX_MEDIA_TOKEN_H
+
+struct device;
+
+#if defined(CONFIG_MEDIA_SUPPORT)
+extern int media_tknres_create(struct device *dev);
+extern int media_tknres_destroy(struct device *dev);
+
+extern int media_get_tuner_tkn(struct device *dev);
+extern int media_put_tuner_tkn(struct device *dev);
+
+extern int media_get_audio_tkn(struct device *dev);
+extern int media_put_audio_tkn(struct device *dev);
+#else
+static inline int media_tknres_create(struct device *dev)
+{
+ return 0;
+}
+static inline int media_tknres_destroy(struct device *dev)
+{
+ return 0;
+}
+static inline int media_get_tuner_tkn(struct device *dev)
+{
+ return 0;
+}
+static inline int media_put_tuner_tkn(struct device *dev)
+{
+ return 0;
+}
+static int media_get_audio_tkn(struct device *dev)
+{
+ return 0;
+}
+static int media_put_audio_tkn(struct device *dev)
+{
+ return 0;
+}
+#endif
+
+#endif /* __LINUX_MEDIA_TOKEN_H */
diff --git a/lib/Makefile b/lib/Makefile
index d6b4bc4..6f21695 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -139,6 +139,8 @@ obj-$(CONFIG_DQL) += dynamic_queue_limits.o
obj-$(CONFIG_GLOB) += glob.o
+obj-$(CONFIG_MEDIA_SUPPORT) += media_tknres.o
+
obj-$(CONFIG_MPILIB) += mpi/
obj-$(CONFIG_SIGNATURE) += digsig.o
diff --git a/lib/media_tknres.c b/lib/media_tknres.c
new file mode 100644
index 000..e0a36cb
--- /dev/null
+++ b/lib/media_tknres.c
@@ -0,0 +1,237 @@
+/*
+ * media_tknres.c - managed media token resource
+ *
+ * Copyright (c) 2014 Shuah Khan shua...@osg.samsung.com
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ *
+ * This file is
[PATCH v3 03/13] [media] s5p-mfc: clear 'enter_suspend' flag if suspend fails
From: Prathyush K prathyus...@samsung.com
The enter_suspend flag is set after we enter mfc suspend function but if
suspend fails after that due to any reason (like hardware timeout etc),
this flag must be cleared before returning an error. Otherwise, this
flag never gets cleared and the MFC suspend will always return an error
on subsequent tries. If clock off fails, disable hw_lock also.
Signed-off-by: Prathyush K prathyus...@samsung.com
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 165bc86..79c9537 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1284,11 +1284,17 @@ static int s5p_mfc_suspend(struct device *dev)
m_dev-int_cond, msecs_to_jiffies(MFC_INT_TIMEOUT));
if (ret == 0) {
mfc_err(Waiting for hardware to finish timed out\n);
+ clear_bit(0, m_dev-enter_suspend);
return -EIO;
}
}
- return s5p_mfc_sleep(m_dev);
+ ret = s5p_mfc_sleep(m_dev);
+ if (ret) {
+ clear_bit(0, m_dev-enter_suspend);
+ clear_bit(0, m_dev-hw_lock);
+ }
+ return ret;
}
static int s5p_mfc_resume(struct device *dev)
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 00/13] Fixes from Chrome OS tree for MFC driver
Upstreaming the fixes which have gone in to Chrome OS tree for MFC driver. Tested on MFCV8, MFCV7 and MFCV6 based Exynos5 based boards, peach-pi (5800), peach-pit (5420) and snow (5250). Changes from v2: 1) Rebased on latest media-tree 2) Dropped the patch (14/14) from previous set s5p-mfc: Don't change the image size to smaller than the request. Changes from v1: 1) Addressed all review comments from Kamil. 2) Dropped patches [media] s5p-mfc: set B-frames as 2 while encoding [media] s5p-mfc: remove reduntant clock on clock off [media] s5p-mfc: don't disable clock when next ctx is pending 3) Rebased on media-tree Arun Mankuzhi (2): [media] s5p-mfc: modify mfc wakeup sequence for V8 [media] s5p-mfc: De-init MFC when watchdog kicks in Ilja Friedel (1): [media] s5p-mfc: Only set timestamp/timecode for new frames. Kiran AVND (4): [media] s5p-mfc: support MIN_BUFFERS query for encoder [media] s5p-mfc: keep RISC ON during reset for V7/V8 [media] s5p-mfc: check mfc bus ctrl before reset [media] s5p-mfc: flush dpbs when resolution changes Pawel Osciak (5): [media] s5p-mfc: Fix REQBUFS(0) for encoder. [media] s5p-mfc: Don't crash the kernel if the watchdog kicks in. [media] s5p-mfc: Remove unused alloc field from private buffer struct. [media] s5p-mfc: fix V4L2_CID_MIN_BUFFERS_FOR_CAPTURE on resolution change. [media] s5p-mfc: fix a race in interrupt flags handling Prathyush K (1): [media] s5p-mfc: clear 'enter_suspend' flag if suspend fails drivers/media/platform/s5p-mfc/regs-mfc-v6.h|1 + drivers/media/platform/s5p-mfc/s5p_mfc.c| 45 + drivers/media/platform/s5p-mfc/s5p_mfc_common.h |4 +- drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 122 ++- drivers/media/platform/s5p-mfc/s5p_mfc_dec.c|6 +- drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 54 ++ drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c | 13 +-- drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 32 +- 8 files changed, 188 insertions(+), 89 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 01/13] [media] s5p-mfc: support MIN_BUFFERS query for encoder
From: Kiran AVND avnd.ki...@samsung.com
Add V4L2_CID_MIN_BUFFERS_FOR_OUTPUT query for encoder.
Once mfc encoder state is HEAD_PARSED, which is sequence
header produced, dpb_count is avaialable. Let user space
query this value.
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 42 ++
1 file changed, 42 insertions(+)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index a904a1c..4816f31 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -690,6 +690,16 @@ static struct mfc_control controls[] = {
.step = 1,
.default_value = 0,
},
+ {
+ .id = V4L2_CID_MIN_BUFFERS_FOR_OUTPUT,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Minimum number of output bufs,
+ .minimum = 1,
+ .maximum = 32,
+ .step = 1,
+ .default_value = 1,
+ .is_volatile = 1,
+ },
};
#define NUM_CTRLS ARRAY_SIZE(controls)
@@ -1624,8 +1634,40 @@ static int s5p_mfc_enc_s_ctrl(struct v4l2_ctrl *ctrl)
return ret;
}
+static int s5p_mfc_enc_g_v_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct s5p_mfc_ctx *ctx = ctrl_to_ctx(ctrl);
+ struct s5p_mfc_dev *dev = ctx-dev;
+
+ switch (ctrl-id) {
+ case V4L2_CID_MIN_BUFFERS_FOR_OUTPUT:
+ if (ctx-state = MFCINST_HEAD_PARSED
+ ctx-state MFCINST_ABORT) {
+ ctrl-val = ctx-pb_count;
+ break;
+ } else if (ctx-state != MFCINST_INIT) {
+ v4l2_err(dev-v4l2_dev, Encoding not initialised\n);
+ return -EINVAL;
+ }
+ /* Should wait for the header to be produced */
+ s5p_mfc_clean_ctx_int_flags(ctx);
+ s5p_mfc_wait_for_done_ctx(ctx,
+ S5P_MFC_R2H_CMD_SEQ_DONE_RET, 0);
+ if (ctx-state = MFCINST_HEAD_PARSED
+ ctx-state MFCINST_ABORT) {
+ ctrl-val = ctx-pb_count;
+ } else {
+ v4l2_err(dev-v4l2_dev, Encoding not initialised\n);
+ return -EINVAL;
+ }
+ break;
+ }
+ return 0;
+}
+
static const struct v4l2_ctrl_ops s5p_mfc_enc_ctrl_ops = {
.s_ctrl = s5p_mfc_enc_s_ctrl,
+ .g_volatile_ctrl = s5p_mfc_enc_g_v_ctrl,
};
static int vidioc_s_parm(struct file *file, void *priv,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 04/13] [media] s5p-mfc: Only set timestamp/timecode for new frames.
From: Ilja Friedel i...@chromium.org
Timestamp i of a previously decoded buffer was overwritten for some
H.264 streams with timestamp i+1 of the next buffer. This happened when
encountering frame_type S5P_FIMV_DECODE_FRAME_SKIPPED, indicating no
new frame.
In most cases this wrong indexing might not have been noticed except
for a one frame delay in frame presentation. For H.264 streams though
that require reordering of frames for presentation, it caused a slightly
erratic presentation time lookup and consequently dropped frames in the
Pepper Flash plugin.
Signed-off-by: Ilja H. Friedel i...@google.com
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 79c9537..eb71055 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -220,11 +220,14 @@ static void s5p_mfc_handle_frame_copy_time(struct
s5p_mfc_ctx *ctx)
size_t dec_y_addr;
unsigned int frame_type;
- dec_y_addr = s5p_mfc_hw_call(dev-mfc_ops, get_dec_y_adr, dev);
+ /* Make sure we actually have a new frame before continuing. */
frame_type = s5p_mfc_hw_call(dev-mfc_ops, get_dec_frame_type, dev);
+ if (frame_type == S5P_FIMV_DECODE_FRAME_SKIPPED)
+ return;
+ dec_y_addr = s5p_mfc_hw_call(dev-mfc_ops, get_dec_y_adr, dev);
/* Copy timestamp / timecode from decoded src to dst and set
- appropriate flags */
+ appropriate flags. */
src_buf = list_entry(ctx-src_queue.next, struct s5p_mfc_buf, list);
list_for_each_entry(dst_buf, ctx-dst_queue, list) {
if (vb2_dma_contig_plane_dma_addr(dst_buf-b, 0) == dec_y_addr)
{
@@ -250,6 +253,11 @@ static void s5p_mfc_handle_frame_copy_time(struct
s5p_mfc_ctx *ctx)
dst_buf-b-v4l2_buf.flags |=
V4L2_BUF_FLAG_BFRAME;
break;
+ default:
+ /* Don't know how to handle
+ S5P_FIMV_DECODE_FRAME_OTHER_FRAME. */
+ mfc_debug(2, Unexpected frame type: %d\n,
+ frame_type);
}
break;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 02/13] [media] s5p-mfc: Fix REQBUFS(0) for encoder.
From: Pawel Osciak posc...@chromium.org
Handle REQBUFS(0) for CAPTURE queue as well. Also use the proper queue to call
it on for OUTPUT.
Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 4816f31..6a1c890 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -1147,6 +1147,11 @@ static int vidioc_reqbufs(struct file *file, void *priv,
(reqbufs-memory != V4L2_MEMORY_USERPTR))
return -EINVAL;
if (reqbufs-type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
+ if (reqbufs-count == 0) {
+ ret = vb2_reqbufs(ctx-vq_dst, reqbufs);
+ ctx-capture_state = QUEUE_FREE;
+ return ret;
+ }
if (ctx-capture_state != QUEUE_FREE) {
mfc_err(invalid capture state: %d\n,
ctx-capture_state);
@@ -1168,6 +1173,14 @@ static int vidioc_reqbufs(struct file *file, void *priv,
return -ENOMEM;
}
} else if (reqbufs-type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
+ if (reqbufs-count == 0) {
+ mfc_debug(2, Freeing buffers\n);
+ ret = vb2_reqbufs(ctx-vq_src, reqbufs);
+ s5p_mfc_hw_call(dev-mfc_ops, release_codec_buffers,
+ ctx);
+ ctx-output_state = QUEUE_FREE;
+ return ret;
+ }
if (ctx-output_state != QUEUE_FREE) {
mfc_err(invalid output state: %d\n,
ctx-output_state);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 05/13] [media] s5p-mfc: keep RISC ON during reset for V7/V8
From: Kiran AVND avnd.ki...@samsung.com
Reset sequence for MFC V7 and V8 do not need RISC_ON
to be set to 0, while for MFC V6 it is still needed.
Also, remove a couple of register settings during Reset
which are not needed from V6 onwards.
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc_common.h |1 +
drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 25 ++-
2 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 3e41ca1..5b0c334 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -340,6 +340,7 @@ struct s5p_mfc_dev {
struct s5p_mfc_hw_cmds *mfc_cmds;
const struct s5p_mfc_regs *mfc_regs;
enum s5p_mfc_fw_ver fw_ver;
+ bool risc_on; /* indicates if RISC is on or off */
};
/**
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index 0c885a8..f5bb6b2 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -139,12 +139,6 @@ int s5p_mfc_reset(struct s5p_mfc_dev *dev)
mfc_debug_enter();
if (IS_MFCV6_PLUS(dev)) {
- /* Reset IP */
- /* except RISC, reset */
- mfc_write(dev, 0xFEE, S5P_FIMV_MFC_RESET_V6);
- /* reset release */
- mfc_write(dev, 0x0, S5P_FIMV_MFC_RESET_V6);
-
/* Zero Initialization of MFC registers */
mfc_write(dev, 0, S5P_FIMV_RISC2HOST_CMD_V6);
mfc_write(dev, 0, S5P_FIMV_HOST2RISC_CMD_V6);
@@ -153,8 +147,13 @@ int s5p_mfc_reset(struct s5p_mfc_dev *dev)
for (i = 0; i S5P_FIMV_REG_CLEAR_COUNT_V6; i++)
mfc_write(dev, 0, S5P_FIMV_REG_CLEAR_BEGIN_V6 + (i*4));
- /* Reset */
- mfc_write(dev, 0, S5P_FIMV_RISC_ON_V6);
+ /* Reset
+* set RISC_ON to 0 during power_on wake_up.
+* V6 needs RISC_ON set to 0 during reset also.
+*/
+ if ((!dev-risc_on) || (!IS_MFCV7(dev)))
+ mfc_write(dev, 0, S5P_FIMV_RISC_ON_V6);
+
mfc_write(dev, 0x1FFF, S5P_FIMV_MFC_RESET_V6);
mfc_write(dev, 0, S5P_FIMV_MFC_RESET_V6);
} else {
@@ -226,6 +225,7 @@ int s5p_mfc_init_hw(struct s5p_mfc_dev *dev)
/* 0. MFC reset */
mfc_debug(2, MFC reset..\n);
s5p_mfc_clock_on();
+ dev-risc_on = 0;
ret = s5p_mfc_reset(dev);
if (ret) {
mfc_err(Failed to reset MFC - timeout\n);
@@ -238,8 +238,10 @@ int s5p_mfc_init_hw(struct s5p_mfc_dev *dev)
s5p_mfc_clear_cmds(dev);
/* 3. Release reset signal to the RISC */
s5p_mfc_clean_dev_int_flags(dev);
- if (IS_MFCV6_PLUS(dev))
+ if (IS_MFCV6_PLUS(dev)) {
+ dev-risc_on = 1;
mfc_write(dev, 0x1, S5P_FIMV_RISC_ON_V6);
+ }
else
mfc_write(dev, 0x3ff, S5P_FIMV_SW_RESET);
mfc_debug(2, Will now wait for completion of firmware transfer\n);
@@ -336,6 +338,7 @@ int s5p_mfc_wakeup(struct s5p_mfc_dev *dev)
/* 0. MFC reset */
mfc_debug(2, MFC reset..\n);
s5p_mfc_clock_on();
+ dev-risc_on = 0;
ret = s5p_mfc_reset(dev);
if (ret) {
mfc_err(Failed to reset MFC - timeout\n);
@@ -354,8 +357,10 @@ int s5p_mfc_wakeup(struct s5p_mfc_dev *dev)
return ret;
}
/* 4. Release reset signal to the RISC */
- if (IS_MFCV6_PLUS(dev))
+ if (IS_MFCV6_PLUS(dev)) {
+ dev-risc_on = 1;
mfc_write(dev, 0x1, S5P_FIMV_RISC_ON_V6);
+ }
else
mfc_write(dev, 0x3ff, S5P_FIMV_SW_RESET);
mfc_debug(2, Ok, now will write a command to wakeup the system\n);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 06/13] [media] s5p-mfc: check mfc bus ctrl before reset
From: Kiran AVND avnd.ki...@samsung.com
during reset sequence, it is advisable to follow the below
sequence, in order to avoid unexpected behavior from MFC
. set SFR 0x7110 MFC_BUS_RESET_CTRL 0x1
// wait for REQ_STATUS to be 1
. get SFR 0x7110 MFC_BUS_RESET_CTRL 0x3
// reset now
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/regs-mfc-v6.h |1 +
drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 25 -
2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
index 51cb2dd..83e01f3 100644
--- a/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
+++ b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
@@ -71,6 +71,7 @@
#define S5P_FIMV_R2H_CMD_ENC_BUFFER_FUL_RET_V6 16
#define S5P_FIMV_R2H_CMD_ERR_RET_V632
+#define S5P_FIMV_MFC_BUS_RESET_CTRL0x7110
#define S5P_FIMV_FW_VERSION_V6 0xf000
#define S5P_FIMV_INSTANCE_ID_V60xf008
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index f5bb6b2..0d3661b 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -129,6 +129,25 @@ int s5p_mfc_release_firmware(struct s5p_mfc_dev *dev)
return 0;
}
+int s5p_mfc_bus_reset(struct s5p_mfc_dev *dev)
+{
+ unsigned int status;
+ unsigned long timeout;
+
+ /* Reset */
+ mfc_write(dev, 0x1, S5P_FIMV_MFC_BUS_RESET_CTRL);
+ timeout = jiffies + msecs_to_jiffies(MFC_BW_TIMEOUT);
+ /* Check bus status */
+ do {
+ if (time_after(jiffies, timeout)) {
+ mfc_err(Timeout while resetting MFC.\n);
+ return -EIO;
+ }
+ status = mfc_read(dev, S5P_FIMV_MFC_BUS_RESET_CTRL);
+ } while ((status 0x2) == 0);
+ return 0;
+}
+
/* Reset the device */
int s5p_mfc_reset(struct s5p_mfc_dev *dev)
{
@@ -147,11 +166,15 @@ int s5p_mfc_reset(struct s5p_mfc_dev *dev)
for (i = 0; i S5P_FIMV_REG_CLEAR_COUNT_V6; i++)
mfc_write(dev, 0, S5P_FIMV_REG_CLEAR_BEGIN_V6 + (i*4));
+ /* check bus reset control before reset */
+ if (dev-risc_on)
+ if (s5p_mfc_bus_reset(dev))
+ return -EIO;
/* Reset
* set RISC_ON to 0 during power_on wake_up.
* V6 needs RISC_ON set to 0 during reset also.
*/
- if ((!dev-risc_on) || (!IS_MFCV7(dev)))
+ if ((!dev-risc_on) || (!IS_MFCV7_PLUS(dev)))
mfc_write(dev, 0, S5P_FIMV_RISC_ON_V6);
mfc_write(dev, 0x1FFF, S5P_FIMV_MFC_RESET_V6);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 07/13] [media] s5p-mfc: Don't crash the kernel if the watchdog kicks in.
From: Pawel Osciak posc...@chromium.org
If the software watchdog kicks in, the watchdog worker is not synchronized
with hardware interrupts and does not block other instances. It's possible
for it to clear the hw_lock, making other instances trigger a BUG() on
hw_lock checks. Since it's not fatal to clear the hw_lock to zero twice,
just WARN in those cases for now. We should not explode, as firmware will
return errors as needed for other instances after it's reloaded, or they
will time out.
A clean fix should involve killing other instances when watchdog kicks in,
but requires a major redesign of locking in the driver.
Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index eb71055..8620236 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -342,8 +342,7 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx *ctx,
ctx-state = MFCINST_RES_CHANGE_INIT;
s5p_mfc_hw_call_void(dev-mfc_ops, clear_int_flags, dev);
wake_up_ctx(ctx, reason, err);
- if (test_and_clear_bit(0, dev-hw_lock) == 0)
- BUG();
+ WARN_ON(test_and_clear_bit(0, dev-hw_lock) == 0);
s5p_mfc_clock_off();
s5p_mfc_hw_call_void(dev-mfc_ops, try_run, dev);
return;
@@ -415,8 +414,7 @@ leave_handle_frame:
clear_work_bit(ctx);
s5p_mfc_hw_call_void(dev-mfc_ops, clear_int_flags, dev);
wake_up_ctx(ctx, reason, err);
- if (test_and_clear_bit(0, dev-hw_lock) == 0)
- BUG();
+ WARN_ON(test_and_clear_bit(0, dev-hw_lock) == 0);
s5p_mfc_clock_off();
/* if suspending, wake up device and do not try_run again*/
if (test_bit(0, dev-enter_suspend))
@@ -463,8 +461,7 @@ static void s5p_mfc_handle_error(struct s5p_mfc_dev *dev,
break;
}
}
- if (test_and_clear_bit(0, dev-hw_lock) == 0)
- BUG();
+ WARN_ON(test_and_clear_bit(0, dev-hw_lock) == 0);
s5p_mfc_hw_call_void(dev-mfc_ops, clear_int_flags, dev);
s5p_mfc_clock_off();
wake_up_dev(dev, reason, err);
@@ -518,8 +515,7 @@ static void s5p_mfc_handle_seq_done(struct s5p_mfc_ctx *ctx,
}
s5p_mfc_hw_call_void(dev-mfc_ops, clear_int_flags, dev);
clear_work_bit(ctx);
- if (test_and_clear_bit(0, dev-hw_lock) == 0)
- BUG();
+ WARN_ON(test_and_clear_bit(0, dev-hw_lock) == 0);
s5p_mfc_clock_off();
s5p_mfc_hw_call_void(dev-mfc_ops, try_run, dev);
wake_up_ctx(ctx, reason, err);
@@ -557,16 +553,14 @@ static void s5p_mfc_handle_init_buffers(struct
s5p_mfc_ctx *ctx,
} else {
ctx-dpb_flush_flag = 0;
}
- if (test_and_clear_bit(0, dev-hw_lock) == 0)
- BUG();
+ WARN_ON(test_and_clear_bit(0, dev-hw_lock) == 0);
s5p_mfc_clock_off();
wake_up(ctx-queue);
s5p_mfc_hw_call_void(dev-mfc_ops, try_run, dev);
} else {
- if (test_and_clear_bit(0, dev-hw_lock) == 0)
- BUG();
+ WARN_ON(test_and_clear_bit(0, dev-hw_lock) == 0);
s5p_mfc_clock_off();
@@ -643,8 +637,7 @@ static irqreturn_t s5p_mfc_irq(int irq, void *priv)
mfc_err(post_frame_start() failed\n);
s5p_mfc_hw_call_void(dev-mfc_ops, clear_int_flags,
dev);
wake_up_ctx(ctx, reason, err);
- if (test_and_clear_bit(0, dev-hw_lock) == 0)
- BUG();
+ WARN_ON(test_and_clear_bit(0, dev-hw_lock) == 0);
s5p_mfc_clock_off();
s5p_mfc_hw_call_void(dev-mfc_ops, try_run, dev);
} else {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 09/13] [media] s5p-mfc: De-init MFC when watchdog kicks in
From: Arun Mankuzhi aru...@samsung.com
If the software watchdog kicks in, we need to de-init MFC
before reloading firmware and re-intializing it again.
Signed-off-by: Arun Mankuzhi aru...@samsung.com
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 8620236..39f8f2a 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -159,6 +159,10 @@ static void s5p_mfc_watchdog_worker(struct work_struct
*work)
}
clear_bit(0, dev-hw_lock);
spin_unlock_irqrestore(dev-irqlock, flags);
+
+ /* De-init MFC */
+ s5p_mfc_deinit_hw(dev);
+
/* Double check if there is at least one instance running.
* If no instance is in memory than no firmware should be present */
if (dev-num_inst 0) {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 08/13] [media] s5p-mfc: modify mfc wakeup sequence for V8
From: Arun Mankuzhi aru...@samsung.com
From MFC V8, the MFC wakeup sequence has changed.
MFC wakeup command has to be sent after the host receives
firmware load complete status from risc.
Signed-off-by: Arun Mankuzhi aru...@samsung.com
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 78 +++--
1 file changed, 61 insertions(+), 17 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index 0d3661b..7c3eaa5 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -353,6 +353,58 @@ int s5p_mfc_sleep(struct s5p_mfc_dev *dev)
return ret;
}
+static int s5p_mfc_v8_wait_wakeup(struct s5p_mfc_dev *dev)
+{
+ int ret;
+
+ /* Release reset signal to the RISC */
+ dev-risc_on = 1;
+ mfc_write(dev, 0x1, S5P_FIMV_RISC_ON_V6);
+
+ if (s5p_mfc_wait_for_done_dev(dev, S5P_MFC_R2H_CMD_FW_STATUS_RET)) {
+ mfc_err(Failed to reset MFCV8\n);
+ return -EIO;
+ }
+ mfc_debug(2, Write command to wakeup MFCV8\n);
+ ret = s5p_mfc_hw_call(dev-mfc_cmds, wakeup_cmd, dev);
+ if (ret) {
+ mfc_err(Failed to send command to MFCV8 - timeout\n);
+ return ret;
+ }
+
+ if (s5p_mfc_wait_for_done_dev(dev, S5P_MFC_R2H_CMD_WAKEUP_RET)) {
+ mfc_err(Failed to wakeup MFC\n);
+ return -EIO;
+ }
+ return ret;
+}
+
+static int s5p_mfc_wait_wakeup(struct s5p_mfc_dev *dev)
+{
+ int ret;
+
+ /* Send MFC wakeup command */
+ ret = s5p_mfc_hw_call(dev-mfc_cmds, wakeup_cmd, dev);
+ if (ret) {
+ mfc_err(Failed to send command to MFC - timeout\n);
+ return ret;
+ }
+
+ /* Release reset signal to the RISC */
+ if (IS_MFCV6_PLUS(dev)) {
+ dev-risc_on = 1;
+ mfc_write(dev, 0x1, S5P_FIMV_RISC_ON_V6);
+ } else {
+ mfc_write(dev, 0x3ff, S5P_FIMV_SW_RESET);
+ }
+
+ if (s5p_mfc_wait_for_done_dev(dev, S5P_MFC_R2H_CMD_WAKEUP_RET)) {
+ mfc_err(Failed to wakeup MFC\n);
+ return -EIO;
+ }
+ return ret;
+}
+
int s5p_mfc_wakeup(struct s5p_mfc_dev *dev)
{
int ret;
@@ -365,6 +417,7 @@ int s5p_mfc_wakeup(struct s5p_mfc_dev *dev)
ret = s5p_mfc_reset(dev);
if (ret) {
mfc_err(Failed to reset MFC - timeout\n);
+ s5p_mfc_clock_off();
return ret;
}
mfc_debug(2, Done MFC reset..\n);
@@ -373,25 +426,16 @@ int s5p_mfc_wakeup(struct s5p_mfc_dev *dev)
/* 2. Initialize registers of channel I/F */
s5p_mfc_clear_cmds(dev);
s5p_mfc_clean_dev_int_flags(dev);
- /* 3. Initialize firmware */
- ret = s5p_mfc_hw_call(dev-mfc_cmds, wakeup_cmd, dev);
- if (ret) {
- mfc_err(Failed to send command to MFC - timeout\n);
- return ret;
- }
- /* 4. Release reset signal to the RISC */
- if (IS_MFCV6_PLUS(dev)) {
- dev-risc_on = 1;
- mfc_write(dev, 0x1, S5P_FIMV_RISC_ON_V6);
- }
+ /* 3. Send MFC wakeup command and wait for completion*/
+ if (IS_MFCV8(dev))
+ ret = s5p_mfc_v8_wait_wakeup(dev);
else
- mfc_write(dev, 0x3ff, S5P_FIMV_SW_RESET);
- mfc_debug(2, Ok, now will write a command to wakeup the system\n);
- if (s5p_mfc_wait_for_done_dev(dev, S5P_MFC_R2H_CMD_WAKEUP_RET)) {
- mfc_err(Failed to load firmware\n);
- return -EIO;
- }
+ ret = s5p_mfc_wait_wakeup(dev);
+
s5p_mfc_clock_off();
+ if (ret)
+ return ret;
+
dev-int_cond = 0;
if (dev-int_err != 0 || dev-int_type !=
S5P_MFC_R2H_CMD_WAKEUP_RET) {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 10/13] [media] s5p-mfc: flush dpbs when resolution changes
From: Kiran AVND avnd.ki...@samsung.com
While resolution change is detected by MFC, we flush out
older dpbs, send the resolution change event to application,
and then accept further queuing of new src buffers.
Sometimes, we error out during dpb flush because of lack of src
buffers. Since we have not started decoding new resolution yet,
it is simpler to push zero-size buffer until we flush out all dpbs.
This is already been done while handling EOS command, and this patch
extends the same logic to resolution change as well.
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 20 ++--
1 file changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index 8798b14..7b1cf73 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -1532,27 +1532,11 @@ static inline int s5p_mfc_get_new_ctx(struct
s5p_mfc_dev *dev)
static inline void s5p_mfc_run_dec_last_frames(struct s5p_mfc_ctx *ctx)
{
struct s5p_mfc_dev *dev = ctx-dev;
- struct s5p_mfc_buf *temp_vb;
- unsigned long flags;
-
- spin_lock_irqsave(dev-irqlock, flags);
-
- /* Frames are being decoded */
- if (list_empty(ctx-src_queue)) {
- mfc_debug(2, No src buffers.\n);
- spin_unlock_irqrestore(dev-irqlock, flags);
- return;
- }
- /* Get the next source buffer */
- temp_vb = list_entry(ctx-src_queue.next, struct s5p_mfc_buf, list);
- temp_vb-flags |= MFC_BUF_FLAG_USED;
- s5p_mfc_set_dec_stream_buffer_v6(ctx,
- vb2_dma_contig_plane_dma_addr(temp_vb-b, 0), 0, 0);
- spin_unlock_irqrestore(dev-irqlock, flags);
+ s5p_mfc_set_dec_stream_buffer_v6(ctx, 0, 0, 0);
dev-curr_ctx = ctx-num;
s5p_mfc_clean_ctx_int_flags(ctx);
- s5p_mfc_decode_one_frame_v6(ctx, 1);
+ s5p_mfc_decode_one_frame_v6(ctx, MFC_DEC_LAST_FRAME);
}
static inline int s5p_mfc_run_dec_frame(struct s5p_mfc_ctx *ctx)
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 11/13] [media] s5p-mfc: Remove unused alloc field from private buffer struct.
From: Pawel Osciak posc...@chromium.org
This field is no longer used as MFC driver doesn't use vb2 alloc contexts
anymore.
Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc_common.h |3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 5b0c334..15f7663 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -237,8 +237,6 @@ struct s5p_mfc_variant {
/**
* struct s5p_mfc_priv_buf - represents internal used buffer
- * @alloc: allocation-specific context for each buffer
- * (videobuf2 allocator)
* @ofs: offset of each buffer, will be used for MFC
* @virt: kernel virtual address, only valid when the
* buffer accessed by driver
@@ -246,7 +244,6 @@ struct s5p_mfc_variant {
* @size: size of the buffer
*/
struct s5p_mfc_priv_buf {
- void*alloc;
unsigned long ofs;
void*virt;
dma_addr_t dma;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 13/13] [media] s5p-mfc: fix a race in interrupt flags handling
From: Pawel Osciak posc...@chromium.org
Interrupt result flags have to be cleared before a hardware job is run.
Otherwise, if they are cleared asynchronously, we may end up clearing them
after the interrupt for which we wanted to wait has already arrived, thus
overwriting the job results that we intended to wait for.
To prevent this, clear the flags only under hw_lock and before running
a hardware job.
Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c |2 --
drivers/media/platform/s5p-mfc/s5p_mfc_dec.c|3 ---
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|1 -
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c | 13 ++---
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 12 ++--
5 files changed, 4 insertions(+), 27 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index 7c3eaa5..86d43d9 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -468,7 +468,6 @@ int s5p_mfc_open_mfc_inst(struct s5p_mfc_dev *dev, struct
s5p_mfc_ctx *ctx)
}
set_work_bit_irqsave(ctx);
- s5p_mfc_clean_ctx_int_flags(ctx);
s5p_mfc_hw_call_void(dev-mfc_ops, try_run, dev);
if (s5p_mfc_wait_for_done_ctx(ctx,
S5P_MFC_R2H_CMD_OPEN_INSTANCE_RET, 0)) {
@@ -494,7 +493,6 @@ void s5p_mfc_close_mfc_inst(struct s5p_mfc_dev *dev, struct
s5p_mfc_ctx *ctx)
{
ctx-state = MFCINST_RETURN_INST;
set_work_bit_irqsave(ctx);
- s5p_mfc_clean_ctx_int_flags(ctx);
s5p_mfc_hw_call_void(dev-mfc_ops, try_run, dev);
/* Wait until instance is returned or timeout occurred */
if (s5p_mfc_wait_for_done_ctx(ctx,
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index de90465..74bcec8 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -334,7 +334,6 @@ static int vidioc_g_fmt(struct file *file, void *priv,
struct v4l2_format *f)
MFCINST_RES_CHANGE_END)) {
/* If the MFC is parsing the header,
* so wait until it is finished */
- s5p_mfc_clean_ctx_int_flags(ctx);
s5p_mfc_wait_for_done_ctx(ctx, S5P_MFC_R2H_CMD_SEQ_DONE_RET,
0);
}
@@ -746,7 +745,6 @@ static int s5p_mfc_dec_g_v_ctrl(struct v4l2_ctrl *ctrl)
return -EINVAL;
}
/* Should wait for the header to be parsed */
- s5p_mfc_clean_ctx_int_flags(ctx);
s5p_mfc_wait_for_done_ctx(ctx,
S5P_MFC_R2H_CMD_SEQ_DONE_RET, 0);
if (ctx-state = MFCINST_HEAD_PARSED
@@ -1058,7 +1056,6 @@ static void s5p_mfc_stop_streaming(struct vb2_queue *q)
if (IS_MFCV6_PLUS(dev) (ctx-state == MFCINST_RUNNING)) {
ctx-state = MFCINST_FLUSH;
set_work_bit_irqsave(ctx);
- s5p_mfc_clean_ctx_int_flags(ctx);
s5p_mfc_hw_call_void(dev-mfc_ops, try_run, dev);
if (s5p_mfc_wait_for_done_ctx(ctx,
S5P_MFC_R2H_CMD_DPB_FLUSH_RET, 0))
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 6a1c890..7f919e4 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -1663,7 +1663,6 @@ static int s5p_mfc_enc_g_v_ctrl(struct v4l2_ctrl *ctrl)
return -EINVAL;
}
/* Should wait for the header to be produced */
- s5p_mfc_clean_ctx_int_flags(ctx);
s5p_mfc_wait_for_done_ctx(ctx,
S5P_MFC_R2H_CMD_SEQ_DONE_RET, 0);
if (ctx-state = MFCINST_HEAD_PARSED
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
index 7cf0796..0c4fcf2 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
@@ -1178,7 +1178,6 @@ static void s5p_mfc_run_res_change(struct s5p_mfc_ctx
*ctx)
s5p_mfc_set_dec_stream_buffer_v5(ctx, 0, 0, 0);
dev-curr_ctx = ctx-num;
- s5p_mfc_clean_ctx_int_flags(ctx);
s5p_mfc_decode_one_frame_v5(ctx, MFC_DEC_RES_CHANGE);
}
@@ -1192,7 +1191,6 @@ static int s5p_mfc_run_dec_frame(struct s5p_mfc_ctx *ctx,
int last_frame)
last_frame = MFC_DEC_LAST_FRAME;
s5p_mfc_set_dec_stream_buffer_v5(ctx, 0, 0, 0);
dev-curr_ctx = ctx-num;
-
[PATCH v3 12/13] [media] s5p-mfc: fix V4L2_CID_MIN_BUFFERS_FOR_CAPTURE on resolution change.
From: Pawel Osciak posc...@chromium.org
G_CTRL on V4L2_CID_MIN_BUFFERS_FOR_CAPTURE will fail if userspace happens to
query it after getting a resolution change event and before the codec has
a chance to parse the header and switch to an initialized state.
Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc_dec.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index a98fe02..de90465 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -740,7 +740,8 @@ static int s5p_mfc_dec_g_v_ctrl(struct v4l2_ctrl *ctrl)
ctx-state MFCINST_ABORT) {
ctrl-val = ctx-pb_count;
break;
- } else if (ctx-state != MFCINST_INIT) {
+ } else if (ctx-state != MFCINST_INIT
+ ctx-state != MFCINST_RES_CHANGE_END) {
v4l2_err(dev-v4l2_dev, Decoding not initialised\n);
return -EINVAL;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] media: soc_camera: rcar_vin: Add BT.709 24-bit RGB888 input support
Hello Sergei,
2014-10-21 19:22 GMT+09:00 Sergei Shtylyov sergei.shtyl...@cogentembedded.com:
Hello.
On 10/21/2014 9:08 AM, Yoshihiro Kaneko wrote:
From: Koji Matsuoka koji.matsuoka...@renesas.com
Signed-off-by: Koji Matsuoka koji.matsuoka...@renesas.com
Signed-off-by: Yoshihiro Kaneko ykaneko0...@gmail.com
---
This patch is against master branch of linuxtv.org/media_tree.git.
v2 [Yoshihiro Kaneko]
* remove unused/useless definition as suggested by Sergei Shtylyov
I didn't say it's useless, I just suspected that you missed the necessary
test somewhere...
Sorry for my inaccurate description.
drivers/media/platform/soc_camera/rcar_vin.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 20defcb..cb5e682 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -74,6 +74,7 @@
#define VNMC_INF_YUV10_BT656 (2 16)
#define VNMC_INF_YUV10_BT601 (3 16)
#define VNMC_INF_YUV16(5 16)
+#define VNMC_INF_RGB888(6 16)
#define VNMC_VUP (1 10)
#define VNMC_IM_ODD (0 3)
#define VNMC_IM_ODD_EVEN (1 3)
[...]
@@ -331,6 +336,9 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
if (output_is_yuv)
vnmc |= VNMC_BPS;
+ if (vnmc VNMC_INF_RGB888)
+ vnmc ^= VNMC_BPS;
+
Hm, this also changes the behavior for VNMC_INF_YUV16 and
VNMC_INF_YUV10_BT{601|656}. Is this actually intended?
Probably this code is incorrect.
Thank you for your review.
Thanks,
Kaneko
[...]
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 14/14] [media] s5p-mfc: Don't change the image size to smaller than the request.
Hi, Let me chime in as well, based on the discussions I had last week in Düsseldorf: On 10/09/2014 12:06 PM, Kamil Debski wrote: Hi, From: Nicolas Dufresne [mailto:nicolas.dufre...@collabora.com] Sent: Wednesday, October 08, 2014 4:35 PM Le 2014-10-08 06:24, Kamil Debski a écrit : Hi, This patch seems complicated and I do not understand your motives. Could you explain what is the problem with the current aligning of the values? Is this a hardware problem? Which MFC version does it affect? Is it a software problem? If so, maybe the user space application should take extra care on what value it passes/receives to try_fmt? This looks like something I wanted to bring here as an RFC but never manage to get the time. In an Odroid Integration we have started using the following simple patch to work around this: https://github.com/dsd/linux- odroid/commit/c76b38c1d682b9870ea3b00093ad6500a9c5f5f6 The context is that right now we have decided that alignment in s_fmt shall be done with a closest rounding. So the format returned may be bigger, or smaller, that's basically random. I've been digging through a lot, and so far I have found no rational that explains this choice other that this felt right. In real life, whenever the resulting format is smaller then request, there is little we can do other then fail or try again blindly other sizes. But with bigger raw buffers, we can use zero-copy cropping techniques to keep going. Here's a example: image_generator - hw_converter - display As hw_converter is a V4L2 M2M, an ideal use case here would be for image_generator to use buffers from the hw_converter. For the scenario, it is likely that a fixed video size is wanted, but this size is also likely not to match HW requirement. If hw_converter decide to give back something smaller, there is nothing image_generator can do. It would have to try again with random size to find out that best match. It's a bit silly to force that on application, as the hw_converter know the closest best match, which is simply the next valid bigger size if that exist. hope that helps, Nicolas Nicolas, thank you for shedding light on this problem. I see that it is not MFC specific. It seems that the problem applies to all Video4Linux2 devices that use v4l_bound_align_image. I agree with you that this deservers an RFC and some discussion as this would change the behaviour of quite a few drivers. I think the documentation does not specify how TRY_FMT/S_FMT should adjust the parameters. Maybe it would a good idea to add some flagS that determine the behaviour? I think we should add flags here as well. NEAREST (the default), ROUND_DOWN and ROUND_UP. Existing calls will use NEAREST. I can think of use-cases for all three of these, and I think the caller should just have to specify what is needed. Just replacing the algorithm used seems asking for problems, you want to be able to select what you want to do. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] media: add media token device resource framework
At Tue, 21 Oct 2014 12:46:03 +0200, Hans Verkuil wrote: Hi Shuah, As promised, here is my review for this patch series. On 10/14/2014 04:58 PM, Shuah Khan wrote: Add media token device resource framework to allow sharing resources such as tuner, dma, audio etc. across media drivers and non-media sound drivers that control media hardware. The Media token resource is created at the main struct device that is common to all drivers that claim various pieces of the main media device, which allows them to find the resource using the main struct device. As an example, digital, analog, and snd-usb-audio drivers can use the media token resource API using the main struct device for the interface the media device is attached to. A shared media tokens resource is created using devres framework for drivers to find and lock/unlock. Creating a shared devres helps avoid creating data structure dependencies between drivers. This media token resource contains media token for tuner, and audio. When tuner token is requested, audio token is issued. Did you mean: 'tuner token is issued' instead of audio token? I also have the same question as Takashi: why do we have an audio token in the first place? While you are streaming audio over alsa the underlying tuner must be marked as being in use. It's all about the tuner, since that's the resource that is being shared, not about audio as such. For the remainder of my review I will ignore the audio-related code and concentrate only on the tuner part. Subsequent token (for tuner and audio) gets from the same task and task in the same tgid succeed. This allows applications that make multiple v4l2 ioctls to work with the first call acquiring the token and applications that create separate threads to handle video and audio functions. Signed-off-by: Shuah Khan shua...@osg.samsung.com --- MAINTAINERS |2 + include/linux/media_tknres.h | 50 + lib/Makefile |2 + lib/media_tknres.c | 237 ++ I am still not convinced myself that this should be a generic API. The only reason we need it today is for sharing tuners. Which is almost a purely media thing with USB audio as the single non-media driver that will be affected. Today I see no use case outside of tuners. I would probably want to keep this inside drivers/media. If this is going to be expanded it can always be moved to lib later. Well, my argument is that it should be more generic if it were intended to be put in lib. It'd be fine to put into drivers/media, but this code snippet must be a separate module. Otherwise usb-audio would grab the whole media stuff even if not needed at all. (snip) I also discovered that you are missing MODULE_AUTHOR, MODULE_DESCRIPTION and above all MODULE_LICENSE. Without the MODULE_LICENSE it won't link this module to the GPL devres_* functions. It took me some time to figure that out. It was a code in lib, so it cannot be a module at all :) Takashi -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] media: add media token device resource framework
On 10/21/2014 01:51 PM, Takashi Iwai wrote: At Tue, 21 Oct 2014 12:46:03 +0200, Hans Verkuil wrote: Hi Shuah, As promised, here is my review for this patch series. On 10/14/2014 04:58 PM, Shuah Khan wrote: Add media token device resource framework to allow sharing resources such as tuner, dma, audio etc. across media drivers and non-media sound drivers that control media hardware. The Media token resource is created at the main struct device that is common to all drivers that claim various pieces of the main media device, which allows them to find the resource using the main struct device. As an example, digital, analog, and snd-usb-audio drivers can use the media token resource API using the main struct device for the interface the media device is attached to. A shared media tokens resource is created using devres framework for drivers to find and lock/unlock. Creating a shared devres helps avoid creating data structure dependencies between drivers. This media token resource contains media token for tuner, and audio. When tuner token is requested, audio token is issued. Did you mean: 'tuner token is issued' instead of audio token? I also have the same question as Takashi: why do we have an audio token in the first place? While you are streaming audio over alsa the underlying tuner must be marked as being in use. It's all about the tuner, since that's the resource that is being shared, not about audio as such. For the remainder of my review I will ignore the audio-related code and concentrate only on the tuner part. Subsequent token (for tuner and audio) gets from the same task and task in the same tgid succeed. This allows applications that make multiple v4l2 ioctls to work with the first call acquiring the token and applications that create separate threads to handle video and audio functions. Signed-off-by: Shuah Khan shua...@osg.samsung.com --- MAINTAINERS |2 + include/linux/media_tknres.h | 50 + lib/Makefile |2 + lib/media_tknres.c | 237 ++ I am still not convinced myself that this should be a generic API. The only reason we need it today is for sharing tuners. Which is almost a purely media thing with USB audio as the single non-media driver that will be affected. Today I see no use case outside of tuners. I would probably want to keep this inside drivers/media. If this is going to be expanded it can always be moved to lib later. Well, my argument is that it should be more generic if it were intended to be put in lib. It'd be fine to put into drivers/media, but this code snippet must be a separate module. Otherwise usb-audio would grab the whole media stuff even if not needed at all. Certainly. (snip) I also discovered that you are missing MODULE_AUTHOR, MODULE_DESCRIPTION and above all MODULE_LICENSE. Without the MODULE_LICENSE it won't link this module to the GPL devres_* functions. It took me some time to figure that out. It was a code in lib, so it cannot be a module at all :) Well, it depends on CONFIG_MEDIA_SUPPORT which is 'm' in my case, so it compiles as a module :-) Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 14/14] [media] s5p-mfc: Don't change the image size to smaller than the request.
Le 2014-10-21 07:34, Hans Verkuil a écrit : I think we should add flags here as well. NEAREST (the default), ROUND_DOWN and ROUND_UP. Existing calls will use NEAREST. I can think of use-cases for all three of these, and I think the caller should just have to specify what is needed. Just replacing the algorithm used seems asking for problems, you want to be able to select what you want to do. One more thing, we realize that in selection scenario, we do want nearest or lowest, so indeed a flag that let user space choose is the best. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 14/14] [media] s5p-mfc: Don't change the image size to smaller than the request.
Hi, From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Tuesday, October 21, 2014 1:35 PM Hi, Let me chime in as well, based on the discussions I had last week in Düsseldorf: On 10/09/2014 12:06 PM, Kamil Debski wrote: Hi, From: Nicolas Dufresne [mailto:nicolas.dufre...@collabora.com] Sent: Wednesday, October 08, 2014 4:35 PM Le 2014-10-08 06:24, Kamil Debski a écrit : Hi, This patch seems complicated and I do not understand your motives. Could you explain what is the problem with the current aligning of the values? Is this a hardware problem? Which MFC version does it affect? Is it a software problem? If so, maybe the user space application should take extra care on what value it passes/receives to try_fmt? This looks like something I wanted to bring here as an RFC but never manage to get the time. In an Odroid Integration we have started using the following simple patch to work around this: https://github.com/dsd/linux- odroid/commit/c76b38c1d682b9870ea3b00093ad6500a9c5f5f6 The context is that right now we have decided that alignment in s_fmt shall be done with a closest rounding. So the format returned may be bigger, or smaller, that's basically random. I've been digging through a lot, and so far I have found no rational that explains this choice other that this felt right. In real life, whenever the resulting format is smaller then request, there is little we can do other then fail or try again blindly other sizes. But with bigger raw buffers, we can use zero-copy cropping techniques to keep going. Here's a example: image_generator - hw_converter - display As hw_converter is a V4L2 M2M, an ideal use case here would be for image_generator to use buffers from the hw_converter. For the scenario, it is likely that a fixed video size is wanted, but this size is also likely not to match HW requirement. If hw_converter decide to give back something smaller, there is nothing image_generator can do. It would have to try again with random size to find out that best match. It's a bit silly to force that on application, as the hw_converter know the closest best match, which is simply the next valid bigger size if that exist. hope that helps, Nicolas Nicolas, thank you for shedding light on this problem. I see that it is not MFC specific. It seems that the problem applies to all Video4Linux2 devices that use v4l_bound_align_image. I agree with you that this deservers an RFC and some discussion as this would change the behaviour of quite a few drivers. I think the documentation does not specify how TRY_FMT/S_FMT should adjust the parameters. Maybe it would a good idea to add some flagS that determine the behaviour? I think we should add flags here as well. NEAREST (the default), ROUND_DOWN and ROUND_UP. Existing calls will use NEAREST. I can think of use-cases for all three of these, and I think the caller should just have to specify what is needed. Just replacing the algorithm used seems asking for problems, you want to be able to select what you want to do. I agree with Hans here. Nicolas, Pawel, I understand your problem with the nearest value behaviour and I think this should be resolved right. I think the flags could be added to the flags field of v4l2_pix_format (and its multiplane counterpart). Something along the lines: V4L2_PIX_FMT_FLAG_ALIGN_GE, V4L2_PIX_FMT_FLAG_ALIGN_LE (akin to the flags used in the selection API). The function v4l2_bound_align could be then modified to take one more argument and act accordingly. No flags set would mean the current behaviour, and when flags are set it would either round up, down or return an error if the exact value cannot be used. What do you think? Best wishes, -- Kamil Debski Samsung 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 1/6] media: add media token device resource framework
At Tue, 21 Oct 2014 13:58:59 +0200, Hans Verkuil wrote: On 10/21/2014 01:51 PM, Takashi Iwai wrote: At Tue, 21 Oct 2014 12:46:03 +0200, Hans Verkuil wrote: Hi Shuah, As promised, here is my review for this patch series. On 10/14/2014 04:58 PM, Shuah Khan wrote: Add media token device resource framework to allow sharing resources such as tuner, dma, audio etc. across media drivers and non-media sound drivers that control media hardware. The Media token resource is created at the main struct device that is common to all drivers that claim various pieces of the main media device, which allows them to find the resource using the main struct device. As an example, digital, analog, and snd-usb-audio drivers can use the media token resource API using the main struct device for the interface the media device is attached to. A shared media tokens resource is created using devres framework for drivers to find and lock/unlock. Creating a shared devres helps avoid creating data structure dependencies between drivers. This media token resource contains media token for tuner, and audio. When tuner token is requested, audio token is issued. Did you mean: 'tuner token is issued' instead of audio token? I also have the same question as Takashi: why do we have an audio token in the first place? While you are streaming audio over alsa the underlying tuner must be marked as being in use. It's all about the tuner, since that's the resource that is being shared, not about audio as such. For the remainder of my review I will ignore the audio-related code and concentrate only on the tuner part. Subsequent token (for tuner and audio) gets from the same task and task in the same tgid succeed. This allows applications that make multiple v4l2 ioctls to work with the first call acquiring the token and applications that create separate threads to handle video and audio functions. Signed-off-by: Shuah Khan shua...@osg.samsung.com --- MAINTAINERS |2 + include/linux/media_tknres.h | 50 + lib/Makefile |2 + lib/media_tknres.c | 237 ++ I am still not convinced myself that this should be a generic API. The only reason we need it today is for sharing tuners. Which is almost a purely media thing with USB audio as the single non-media driver that will be affected. Today I see no use case outside of tuners. I would probably want to keep this inside drivers/media. If this is going to be expanded it can always be moved to lib later. Well, my argument is that it should be more generic if it were intended to be put in lib. It'd be fine to put into drivers/media, but this code snippet must be a separate module. Otherwise usb-audio would grab the whole media stuff even if not needed at all. Certainly. (snip) I also discovered that you are missing MODULE_AUTHOR, MODULE_DESCRIPTION and above all MODULE_LICENSE. Without the MODULE_LICENSE it won't link this module to the GPL devres_* functions. It took me some time to figure that out. It was a code in lib, so it cannot be a module at all :) Well, it depends on CONFIG_MEDIA_SUPPORT which is 'm' in my case, so it compiles as a module :-) Ah, I thought it was a boolean, but yes, this can be a module indeed. Then I don't think it's worth to put in lib. Takashi -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[media] CODA960: Fails to allocate memory
Hi,
I am trying to use the CODA960 driver on a 3.18 kernel.
It seems pretty good when the module is probed (appart from the
unsupported firmware version) but when I try using the encoder, it
fails allocating dma buffers.
Here is the DT part I added :
vpu {
compatible = fsl,imx6q-vpu;
clocks = clks 168, clks 140, clks 142;
clock-names = per, ahb, ocram;
iramsize = 0x21000;
iram = ocram;
resets = src 1;
status = okay;
};
When booting, I see :
[4.410645] coda 204.vpu: Firmware code revision: 46056
[4.416312] coda 204.vpu: Initialized CODA960.
[4.421123] coda 204.vpu: Unsupported firmware version: 3.1.1
[4.483577] coda 204.vpu: codec registered as /dev/video[0-1]
I can start v4l2-ctl and it shows that the device seems to be ok :
v4l2-ctl --all -d /dev/video1
Driver Info (not using libv4l2):
Driver name : coda
Card type : CODA960
Bus info : platform:coda
Driver version: 3.18.0
Capabilities : 0x84208000
Video Memory-to-Memory
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04208000
Video Memory-to-Memory
Streaming
Extended Pix Format
Priority: 2
Format Video Capture:
Width/Height : 1920/1088
Pixel Format : 'YU12'
Field : None
Bytes per Line: 1920
Size Image: 3133440
Colorspace: HDTV and modern devices (ITU709)
Flags :
Format Video Output:
Width/Height : 1920/1088
Pixel Format : 'H264'
Field : None
Bytes per Line: 0
Size Image: 1048576
Colorspace: HDTV and modern devices (ITU709)
Flags :
Selection: compose, Left 0, Top 0, Width 1920, Height 1088
Selection: compose_default, Left 0, Top 0, Width 1920, Height 1088
Selection: compose_bounds, Left 0, Top 0, Width 1920, Height 1088
Selection: compose_padded, Left 0, Top 0, Width 1920, Height 1088
Selection: crop, Left 0, Top 0, Width 1920, Height 1088
Selection: crop_default, Left 0, Top 0, Width 1920, Height 1088
Selection: crop_bounds, Left 0, Top 0, Width 1920, Height 1088
User Controls
horizontal_flip (bool) : default=0 value=0
vertical_flip (bool) : default=0 value=0
Codec Controls
video_gop_size (int): min=1 max=60 step=1
default=16 value=16
video_bitrate (int): min=0 max=32767000 step=1
default=0 value=0
number_of_intra_refresh_mbs (int): min=0 max=8160 step=1
default=0 value=0
sequence_header_mode (menu) : min=0 max=1 default=1 value=1
maximum_bytes_in_a_slice (int): min=1 max=1073741823 step=1
default=500 value=500
number_of_mbs_in_a_slice (int): min=1 max=1073741823 step=1
default=1 value=1
slice_partitioning_method (menu) : min=0 max=2 default=0 value=0
h264_i_frame_qp_value (int): min=0 max=51 step=1
default=25 value=25
h264_p_frame_qp_value (int): min=0 max=51 step=1
default=25 value=25
h264_maximum_qp_value (int): min=0 max=51 step=1
default=51 value=51
h264_loop_filter_alpha_offset (int): min=0 max=15 step=1 default=0 value=0
h264_loop_filter_beta_offset (int): min=0 max=15 step=1 default=0 value=0
h264_loop_filter_mode (menu) : min=0 max=1 default=0 value=0
mpeg4_i_frame_qp_value (int): min=1 max=31 step=1 default=2 value=2
mpeg4_p_frame_qp_value (int): min=1 max=31 step=1 default=2 value=2
horizontal_flip (bool) : default=0 value=0
vertical_flip (bool) : default=0 value=0
But when I try to get a file outputed, it fails :
v4l2-ctl -d1 --stream-out-mmap --stream-mmap --stream-to x.raw
[ 1197.292256] coda 204.vpu: dma_alloc_coherent of size 1048576 failed
VIDIOC_REQBUFS: failed: Cannot allocate memory
Did I forget to do something ?
Thanks,
JM
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v4l-utils RFC 0/2] libmediatext library
Hi Sakari, On 10/21/2014 12:40 PM, Sakari Ailus wrote: Hi, This is a tiny library for parsing text-based media link, V4L2 sub-device format (and selection) configurations as well as controls with limited types. Hmm, we also have: [PATCH/RFC v2 1/4] Add a media device configuration file parser. How do these 2 relate ? Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [media] CODA960: Fails to allocate memory
On 10/21/2014 03:16 PM, Jean-Michel Hautbois wrote:
Hi,
I am trying to use the CODA960 driver on a 3.18 kernel.
It seems pretty good when the module is probed (appart from the
unsupported firmware version) but when I try using the encoder, it
fails allocating dma buffers.
Here is the DT part I added :
vpu {
compatible = fsl,imx6q-vpu;
clocks = clks 168, clks 140, clks 142;
clock-names = per, ahb, ocram;
iramsize = 0x21000;
iram = ocram;
resets = src 1;
status = okay;
};
When booting, I see :
[4.410645] coda 204.vpu: Firmware code revision: 46056
[4.416312] coda 204.vpu: Initialized CODA960.
[4.421123] coda 204.vpu: Unsupported firmware version: 3.1.1
[4.483577] coda 204.vpu: codec registered as /dev/video[0-1]
I can start v4l2-ctl and it shows that the device seems to be ok :
v4l2-ctl --all -d /dev/video1
Driver Info (not using libv4l2):
Driver name : coda
Card type : CODA960
Bus info : platform:coda
Driver version: 3.18.0
Capabilities : 0x84208000
Video Memory-to-Memory
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04208000
Video Memory-to-Memory
Streaming
Extended Pix Format
Priority: 2
Format Video Capture:
Width/Height : 1920/1088
Pixel Format : 'YU12'
Field : None
Bytes per Line: 1920
Size Image: 3133440
Colorspace: HDTV and modern devices (ITU709)
Flags :
Format Video Output:
Width/Height : 1920/1088
Pixel Format : 'H264'
Field : None
Bytes per Line: 0
Size Image: 1048576
Colorspace: HDTV and modern devices (ITU709)
Flags :
Selection: compose, Left 0, Top 0, Width 1920, Height 1088
Selection: compose_default, Left 0, Top 0, Width 1920, Height 1088
Selection: compose_bounds, Left 0, Top 0, Width 1920, Height 1088
Selection: compose_padded, Left 0, Top 0, Width 1920, Height 1088
Selection: crop, Left 0, Top 0, Width 1920, Height 1088
Selection: crop_default, Left 0, Top 0, Width 1920, Height 1088
Selection: crop_bounds, Left 0, Top 0, Width 1920, Height 1088
User Controls
horizontal_flip (bool) : default=0 value=0
vertical_flip (bool) : default=0 value=0
Codec Controls
video_gop_size (int): min=1 max=60 step=1
default=16 value=16
video_bitrate (int): min=0 max=32767000 step=1
default=0 value=0
number_of_intra_refresh_mbs (int): min=0 max=8160 step=1
default=0 value=0
sequence_header_mode (menu) : min=0 max=1 default=1 value=1
maximum_bytes_in_a_slice (int): min=1 max=1073741823 step=1
default=500 value=500
number_of_mbs_in_a_slice (int): min=1 max=1073741823 step=1
default=1 value=1
slice_partitioning_method (menu) : min=0 max=2 default=0 value=0
h264_i_frame_qp_value (int): min=0 max=51 step=1
default=25 value=25
h264_p_frame_qp_value (int): min=0 max=51 step=1
default=25 value=25
h264_maximum_qp_value (int): min=0 max=51 step=1
default=51 value=51
h264_loop_filter_alpha_offset (int): min=0 max=15 step=1 default=0
value=0
h264_loop_filter_beta_offset (int): min=0 max=15 step=1 default=0
value=0
h264_loop_filter_mode (menu) : min=0 max=1 default=0 value=0
mpeg4_i_frame_qp_value (int): min=1 max=31 step=1 default=2
value=2
mpeg4_p_frame_qp_value (int): min=1 max=31 step=1 default=2
value=2
horizontal_flip (bool) : default=0 value=0
vertical_flip (bool) : default=0 value=0
But when I try to get a file outputed, it fails :
v4l2-ctl -d1 --stream-out-mmap --stream-mmap --stream-to x.raw
[ 1197.292256] coda 204.vpu: dma_alloc_coherent of size 1048576 failed
VIDIOC_REQBUFS: failed: Cannot allocate memory
Did I forget to do something ?
I assume this is physically contiguous memory. Do you have that much phys.
cont. memory
available at all? If the memory is fragmented you won't be able to get it.
Use cma (contiguous memory allocator). You probably have to do very little
expect add
a kernel option to assign enough memory for these buffers.
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [media] CODA960: Fails to allocate memory
Hi Hans,
2014-10-21 15:27 GMT+02:00 Hans Verkuil hverk...@xs4all.nl:
On 10/21/2014 03:16 PM, Jean-Michel Hautbois wrote:
Hi,
I am trying to use the CODA960 driver on a 3.18 kernel.
It seems pretty good when the module is probed (appart from the
unsupported firmware version) but when I try using the encoder, it
fails allocating dma buffers.
Here is the DT part I added :
vpu {
compatible = fsl,imx6q-vpu;
clocks = clks 168, clks 140, clks 142;
clock-names = per, ahb, ocram;
iramsize = 0x21000;
iram = ocram;
resets = src 1;
status = okay;
};
When booting, I see :
[4.410645] coda 204.vpu: Firmware code revision: 46056
[4.416312] coda 204.vpu: Initialized CODA960.
[4.421123] coda 204.vpu: Unsupported firmware version: 3.1.1
[4.483577] coda 204.vpu: codec registered as /dev/video[0-1]
I can start v4l2-ctl and it shows that the device seems to be ok :
v4l2-ctl --all -d /dev/video1
Driver Info (not using libv4l2):
Driver name : coda
Card type : CODA960
Bus info : platform:coda
Driver version: 3.18.0
Capabilities : 0x84208000
Video Memory-to-Memory
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04208000
Video Memory-to-Memory
Streaming
Extended Pix Format
Priority: 2
Format Video Capture:
Width/Height : 1920/1088
Pixel Format : 'YU12'
Field : None
Bytes per Line: 1920
Size Image: 3133440
Colorspace: HDTV and modern devices (ITU709)
Flags :
Format Video Output:
Width/Height : 1920/1088
Pixel Format : 'H264'
Field : None
Bytes per Line: 0
Size Image: 1048576
Colorspace: HDTV and modern devices (ITU709)
Flags :
Selection: compose, Left 0, Top 0, Width 1920, Height 1088
Selection: compose_default, Left 0, Top 0, Width 1920, Height 1088
Selection: compose_bounds, Left 0, Top 0, Width 1920, Height 1088
Selection: compose_padded, Left 0, Top 0, Width 1920, Height 1088
Selection: crop, Left 0, Top 0, Width 1920, Height 1088
Selection: crop_default, Left 0, Top 0, Width 1920, Height 1088
Selection: crop_bounds, Left 0, Top 0, Width 1920, Height 1088
User Controls
horizontal_flip (bool) : default=0 value=0
vertical_flip (bool) : default=0 value=0
Codec Controls
video_gop_size (int): min=1 max=60 step=1
default=16 value=16
video_bitrate (int): min=0 max=32767000 step=1
default=0 value=0
number_of_intra_refresh_mbs (int): min=0 max=8160 step=1
default=0 value=0
sequence_header_mode (menu) : min=0 max=1 default=1 value=1
maximum_bytes_in_a_slice (int): min=1 max=1073741823 step=1
default=500 value=500
number_of_mbs_in_a_slice (int): min=1 max=1073741823 step=1
default=1 value=1
slice_partitioning_method (menu) : min=0 max=2 default=0 value=0
h264_i_frame_qp_value (int): min=0 max=51 step=1
default=25 value=25
h264_p_frame_qp_value (int): min=0 max=51 step=1
default=25 value=25
h264_maximum_qp_value (int): min=0 max=51 step=1
default=51 value=51
h264_loop_filter_alpha_offset (int): min=0 max=15 step=1 default=0
value=0
h264_loop_filter_beta_offset (int): min=0 max=15 step=1 default=0
value=0
h264_loop_filter_mode (menu) : min=0 max=1 default=0 value=0
mpeg4_i_frame_qp_value (int): min=1 max=31 step=1 default=2
value=2
mpeg4_p_frame_qp_value (int): min=1 max=31 step=1 default=2
value=2
horizontal_flip (bool) : default=0 value=0
vertical_flip (bool) : default=0 value=0
But when I try to get a file outputed, it fails :
v4l2-ctl -d1 --stream-out-mmap --stream-mmap --stream-to x.raw
[ 1197.292256] coda 204.vpu: dma_alloc_coherent of size 1048576 failed
VIDIOC_REQBUFS: failed: Cannot allocate memory
Did I forget to do something ?
I assume this is physically contiguous memory. Do you have that much phys.
cont. memory
available at all? If the memory is fragmented you won't be able to get it.
Use cma (contiguous memory allocator). You probably have to do very little
expect add
a kernel option to assign enough memory for these buffers.
I added a cma=128M in order to reserve some meory, and it fails...
well, differently :).
~# v4l2-ctl -d1 --stream-out-mmap --stream-mmap --stream-to x.raw
[ 56.372023] alloc_contig_range test_pages_isolated(48400, 486fd) failed
[ 56.459627] [ cut here ]
[ 56.464273] WARNING: CPU: 1 PID: 838 at
Re: [media] CODA960: Fails to allocate memory
On 10/21/2014 03:42 PM, Jean-Michel Hautbois wrote:
Hi Hans,
2014-10-21 15:27 GMT+02:00 Hans Verkuil hverk...@xs4all.nl:
On 10/21/2014 03:16 PM, Jean-Michel Hautbois wrote:
Hi,
I am trying to use the CODA960 driver on a 3.18 kernel.
It seems pretty good when the module is probed (appart from the
unsupported firmware version) but when I try using the encoder, it
fails allocating dma buffers.
Here is the DT part I added :
vpu {
compatible = fsl,imx6q-vpu;
clocks = clks 168, clks 140, clks 142;
clock-names = per, ahb, ocram;
iramsize = 0x21000;
iram = ocram;
resets = src 1;
status = okay;
};
When booting, I see :
[4.410645] coda 204.vpu: Firmware code revision: 46056
[4.416312] coda 204.vpu: Initialized CODA960.
[4.421123] coda 204.vpu: Unsupported firmware version: 3.1.1
[4.483577] coda 204.vpu: codec registered as /dev/video[0-1]
I can start v4l2-ctl and it shows that the device seems to be ok :
v4l2-ctl --all -d /dev/video1
Driver Info (not using libv4l2):
Driver name : coda
Card type : CODA960
Bus info : platform:coda
Driver version: 3.18.0
Capabilities : 0x84208000
Video Memory-to-Memory
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04208000
Video Memory-to-Memory
Streaming
Extended Pix Format
Priority: 2
Format Video Capture:
Width/Height : 1920/1088
Pixel Format : 'YU12'
Field : None
Bytes per Line: 1920
Size Image: 3133440
Colorspace: HDTV and modern devices (ITU709)
Flags :
Format Video Output:
Width/Height : 1920/1088
Pixel Format : 'H264'
Field : None
Bytes per Line: 0
Size Image: 1048576
Colorspace: HDTV and modern devices (ITU709)
Flags :
Selection: compose, Left 0, Top 0, Width 1920, Height 1088
Selection: compose_default, Left 0, Top 0, Width 1920, Height 1088
Selection: compose_bounds, Left 0, Top 0, Width 1920, Height 1088
Selection: compose_padded, Left 0, Top 0, Width 1920, Height 1088
Selection: crop, Left 0, Top 0, Width 1920, Height 1088
Selection: crop_default, Left 0, Top 0, Width 1920, Height 1088
Selection: crop_bounds, Left 0, Top 0, Width 1920, Height 1088
User Controls
horizontal_flip (bool) : default=0 value=0
vertical_flip (bool) : default=0 value=0
Codec Controls
video_gop_size (int): min=1 max=60 step=1
default=16 value=16
video_bitrate (int): min=0 max=32767000 step=1
default=0 value=0
number_of_intra_refresh_mbs (int): min=0 max=8160 step=1
default=0 value=0
sequence_header_mode (menu) : min=0 max=1 default=1 value=1
maximum_bytes_in_a_slice (int): min=1 max=1073741823 step=1
default=500 value=500
number_of_mbs_in_a_slice (int): min=1 max=1073741823 step=1
default=1 value=1
slice_partitioning_method (menu) : min=0 max=2 default=0 value=0
h264_i_frame_qp_value (int): min=0 max=51 step=1
default=25 value=25
h264_p_frame_qp_value (int): min=0 max=51 step=1
default=25 value=25
h264_maximum_qp_value (int): min=0 max=51 step=1
default=51 value=51
h264_loop_filter_alpha_offset (int): min=0 max=15 step=1 default=0
value=0
h264_loop_filter_beta_offset (int): min=0 max=15 step=1 default=0
value=0
h264_loop_filter_mode (menu) : min=0 max=1 default=0 value=0
mpeg4_i_frame_qp_value (int): min=1 max=31 step=1 default=2
value=2
mpeg4_p_frame_qp_value (int): min=1 max=31 step=1 default=2
value=2
horizontal_flip (bool) : default=0 value=0
vertical_flip (bool) : default=0 value=0
But when I try to get a file outputed, it fails :
v4l2-ctl -d1 --stream-out-mmap --stream-mmap --stream-to x.raw
[ 1197.292256] coda 204.vpu: dma_alloc_coherent of size 1048576 failed
VIDIOC_REQBUFS: failed: Cannot allocate memory
Did I forget to do something ?
I assume this is physically contiguous memory. Do you have that much phys.
cont. memory
available at all? If the memory is fragmented you won't be able to get it.
Use cma (contiguous memory allocator). You probably have to do very little
expect add
a kernel option to assign enough memory for these buffers.
I added a cma=128M in order to reserve some meory, and it fails...
well, differently :).
~# v4l2-ctl -d1 --stream-out-mmap --stream-mmap --stream-to x.raw
[ 56.372023] alloc_contig_range test_pages_isolated(48400, 486fd) failed
[ 56.459627] [ cut here ]
[ 56.464273] WARNING: CPU: 1 PID: 838 at
[ANNOUNCE] Media summit Report - October, 17-18 2014 - Düsseldorf
This report is also available in html at: http://linuxtv.org/news.php?entry=2014-10-21.mchehab In the name of the organizing committee, I'd like to thank you all for being there with us during those two days. There were several good discussions that happened during the meeting, aimed to improve even more the Linux media subsystem. Also, it was agreed during the meeting that we'll try to reach an even broader audience on the next events. So we're counting with all you on our next year's event(s). Thanks! Mauro - Attendees, in alphabetical order: NAME- EMAIL - ORGANIZATION Brad Love - bl...@hauppauge.com - Hauppauge Chris Kohn - christian.k...@xilinx.com - Xilinx Friedrich Schwittay - fschwit...@pctvsystems.com- PCTV Guennaddi Liakhovetski - g.liakhovet...@gmx.de - Intel Hans de Goede - hdego...@redhat.com - Red hat Hans Verkuil- hverk...@xs4all.nl- Cisco Henning Garbers - hgarb...@pctvsystems.com - PCTV Johannes Stezenbach - j...@linuxtv.org - LinuxTV Julien Beraud - julien.ber...@parrot.com - Parrot (www.parrot.com) Kamil Debski- k.deb...@samsung.com - Samsung Laurent Pinchart- laurent.pinch...@ideasonboard.com - Ideas on board Lucas Stach - l.st...@pengutronix.de- Pengutronix Mauro Carvalho Chehab - mche...@osg.samsung.com - Samsung Mike Krufky - mkru...@linuxtv.org - Samsung Nicolas Dufresne- nicolas.dufre...@collabora.com- Collabora Pawel Osciak- pa...@osciak.com - Google Peter Griffin - peter.grif...@linaro.org - Linaro/ST Philipp Zabel - p.za...@pengutronix.de- Pengutronix Ralph Metzler - r...@metzlerbros.de - Meltzler Brothers Ricardo Ribalda Delgado - rica...@qtec.com - Qtechnolgy A/S Sakari Ailus- sakari.ai...@linux.intel.com - Intel Thursday: 1) Configuration stores - Hans Verkuil === - Need to report which settings/controls were applied - Drivers needs to be able to report full/limited Android CameraHAL v3 support (full means full synchronization support) - We probably need a mechanism to be able to remove (free) config stores - Can we use APPLY(0) instead of CLOSE? - Per buffer or per frame configuration? Note: there is no notion of frame IDs yet in V4L2. - Would be nice to be able to disable APPLY, perhaps a flag for the core similar to HAS STORE 2) Android camera HAL v3 - Sakari Ailus http://www.retiisi.org.uk/v4l2/foil/android-camera-hal-v3-v4l2.pdf - Capture requests queued lead to returned buffers in order, best effort to make per-buffer configuration apply correctly needed - Capture requests/returned buffers do not map directly to QBUF/DQBUF because multiple buffers in different formats may be produced from a single request. Some outputs could be implemented in software, e.g. multiple YUV outputs when hardware simply does not contain as many. - Should statistical data be returned in a separate video buffer queue? Might be associated via sequence number, probably separate frame ID better - 3A library input: frame metadata, depends on sensor, might be in-frame or out-of band. If possible, separate buffer queue prepared to get to it early. - HAL v3 needs Start Of Frame and End Of Frame events - If there is no hardware mechanism for synchronization, apply sensor settings as soon as possible after SOF and hope for the best. It is possible to verify the timing has been successful in the user space. - Sensor settings and ISP settings applied at different points in time, as sensor settings usally take effect on the following frame - Sensors may implement all or parts of the ISP themselves. It may not be feasible to implement hal v3 full profile for such sensors. - Start of Exposure events not to be implemented in the kernel. HAL must calculate the event time based on other available information, such as end of frame (or start of frame event) and other frame timing parameters. - Some metadata tags could be mapped to V4L2 (compound) controls, they are associated with a single capture request. Some metadata tags (statistics) are produced from video buffer queues. Other metadata tags originate from HAL. - Needs a guarantee that a single capture request will produce all buffers requested by it with the request's parameters, needs per-buffer configuration, associating buffers with a certain frame. - A working halv3 implementation for UVC (limited profile) would be nice to have - A working halv3 implementation on top of some hardware
[PATCH] [media] s5p_mfc: Remove redundant casts
Both sides of these assignments actually have type const struct
vb2_mem_ops *, so the casts are unnecessary and slightly confusing.
Signed-off-by: Rasmus Villemoes li...@rasmusvillemoes.dk
---
drivers/media/platform/s5p-mfc/s5p_mfc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 165bc86..8daf291 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -815,7 +815,7 @@ static int s5p_mfc_open(struct file *file)
ret = -ENOENT;
goto err_queue_init;
}
- q-mem_ops = (struct vb2_mem_ops *)vb2_dma_contig_memops;
+ q-mem_ops = vb2_dma_contig_memops;
q-timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
ret = vb2_queue_init(q);
if (ret) {
@@ -837,7 +837,7 @@ static int s5p_mfc_open(struct file *file)
ret = -ENOENT;
goto err_queue_init;
}
- q-mem_ops = (struct vb2_mem_ops *)vb2_dma_contig_memops;
+ q-mem_ops = vb2_dma_contig_memops;
q-timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
ret = vb2_queue_init(q);
if (ret) {
--
2.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 8/8] [media] si4713: cleanup platform data
Remove unreferenced members from the platform
data's structure.
Signed-off-by: Sebastian Reichel s...@kernel.org
---
include/media/si4713.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/media/si4713.h b/include/media/si4713.h
index 343b8fb5..be4f58e 100644
--- a/include/media/si4713.h
+++ b/include/media/si4713.h
@@ -23,9 +23,6 @@
* Platform dependent definition
*/
struct si4713_platform_data {
- const char * const *supply_names;
- unsigned supplies;
- int gpio_reset; /* 0 if not used */
bool is_platform_device;
};
--
2.1.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 6/8] [media] si4713: add DT binding documentation
This patch adds the DT bindings documentation for Silicon Labs Si4713 FM
radio transmitter.
Signed-off-by: Sebastian Reichel s...@kernel.org
---
Documentation/devicetree/bindings/media/si4713.txt | 30 ++
1 file changed, 30 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/si4713.txt
diff --git a/Documentation/devicetree/bindings/media/si4713.txt
b/Documentation/devicetree/bindings/media/si4713.txt
new file mode 100644
index 000..5ee5552
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/si4713.txt
@@ -0,0 +1,30 @@
+* Silicon Labs FM Radio transmitter
+
+The Silicon Labs Si4713 is an FM radio transmitter with receive power scan
+supporting 76-108 MHz. It includes an RDS encoder and has both, a stereo-analog
+and a digital interface, which supports I2S, left-justified and a custom
+DSP-mode format. It is programmable through an I2C interface.
+
+Required Properties:
+- compatible: Should contain silabs,si4713
+- reg: the I2C address of the device
+
+Optional Properties:
+- interrupts-extended: Interrupt specifier for the chips interrupt
+- reset-gpios: GPIO specifier for the chips reset line
+- vdd-supply: phandle for Vdd regulator
+- vio-supply: phandle for Vio regulator
+
+Example:
+
+i2c2 {
+fmtx: si4713@63 {
+compatible = silabs,si4713;
+reg = 0x63;
+
+interrupts-extended = gpio2 21 IRQ_TYPE_EDGE_FALLING; /* 53
*/
+reset-gpios = gpio6 3 GPIO_ACTIVE_HIGH; /* 163 */
+vio-supply = vio;
+vdd-supply = vaux1;
+};
+};
--
2.1.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 2/8] [media] si4713: switch reset gpio to devm_gpiod API
This updates the driver to use the managed gpiod interface
instead of the unmanged old GPIO API. This is a preperation
for the introduction of device tree support.
Signed-off-by: Sebastian Reichel s...@kernel.org
---
drivers/media/radio/si4713/si4713.c | 38 +
drivers/media/radio/si4713/si4713.h | 3 ++-
2 files changed, 19 insertions(+), 22 deletions(-)
diff --git a/drivers/media/radio/si4713/si4713.c
b/drivers/media/radio/si4713/si4713.c
index b335093..e560a7e 100644
--- a/drivers/media/radio/si4713/si4713.c
+++ b/drivers/media/radio/si4713/si4713.c
@@ -383,9 +383,9 @@ static int si4713_powerup(struct si4713_device *sdev)
}
}
- if (gpio_is_valid(sdev-gpio_reset)) {
+ if (!IS_ERR(sdev-gpio_reset)) {
udelay(50);
- gpio_set_value(sdev-gpio_reset, 1);
+ gpiod_set_value(sdev-gpio_reset, 1);
}
if (client-irq)
@@ -407,8 +407,8 @@ static int si4713_powerup(struct si4713_device *sdev)
SI4713_STC_INT | SI4713_CTS);
return err;
}
- if (gpio_is_valid(sdev-gpio_reset))
- gpio_set_value(sdev-gpio_reset, 0);
+ if (!IS_ERR(sdev-gpio_reset))
+ gpiod_set_value(sdev-gpio_reset, 0);
if (sdev-vdd) {
@@ -447,8 +447,8 @@ static int si4713_powerdown(struct si4713_device *sdev)
v4l2_dbg(1, debug, sdev-sd, Power down response: 0x%02x\n,
resp[0]);
v4l2_dbg(1, debug, sdev-sd, Device in reset mode\n);
- if (gpio_is_valid(sdev-gpio_reset))
- gpio_set_value(sdev-gpio_reset, 0);
+ if (!IS_ERR(sdev-gpio_reset))
+ gpiod_set_value(sdev-gpio_reset, 0);
if (sdev-vdd) {
err = regulator_disable(sdev-vdd);
@@ -1457,16 +1457,17 @@ static int si4713_probe(struct i2c_client *client,
goto exit;
}
- sdev-gpio_reset = -1;
- if (pdata gpio_is_valid(pdata-gpio_reset)) {
- rval = gpio_request(pdata-gpio_reset, si4713 reset);
- if (rval) {
- dev_err(client-dev,
- Failed to request gpio: %d\n, rval);
- goto free_sdev;
- }
- sdev-gpio_reset = pdata-gpio_reset;
- gpio_direction_output(sdev-gpio_reset, 0);
+ sdev-gpio_reset = devm_gpiod_get(client-dev, reset);
+ if (!IS_ERR(sdev-gpio_reset)) {
+ gpiod_direction_output(sdev-gpio_reset, 0);
+ } else if (PTR_ERR(sdev-gpio_reset) == -ENOENT) {
+ dev_dbg(client-dev, No reset GPIO assigned\n);
+ } else if (PTR_ERR(sdev-gpio_reset) == -ENOSYS) {
+ dev_dbg(client-dev, No reset GPIO support\n);
+ } else {
+ rval = PTR_ERR(sdev-gpio_reset);
+ dev_err(client-dev, Failed to request gpio: %d\n, rval);
+ goto free_sdev;
}
sdev-vdd = devm_regulator_get_optional(client-dev, vdd);
@@ -1614,9 +1615,6 @@ free_irq:
free_irq(client-irq, sdev);
free_ctrls:
v4l2_ctrl_handler_free(hdl);
-free_gpio:
- if (gpio_is_valid(sdev-gpio_reset))
- gpio_free(sdev-gpio_reset);
free_sdev:
kfree(sdev);
exit:
@@ -1637,8 +1635,6 @@ static int si4713_remove(struct i2c_client *client)
v4l2_device_unregister_subdev(sd);
v4l2_ctrl_handler_free(sd-ctrl_handler);
- if (gpio_is_valid(sdev-gpio_reset))
- gpio_free(sdev-gpio_reset);
kfree(sdev);
return 0;
diff --git a/drivers/media/radio/si4713/si4713.h
b/drivers/media/radio/si4713/si4713.h
index ed28ed2..7c2479f 100644
--- a/drivers/media/radio/si4713/si4713.h
+++ b/drivers/media/radio/si4713/si4713.h
@@ -16,6 +16,7 @@
#define SI4713_I2C_H
#include linux/regulator/consumer.h
+#include linux/gpio/consumer.h
#include media/v4l2-subdev.h
#include media/v4l2-ctrls.h
#include media/si4713.h
@@ -236,7 +237,7 @@ struct si4713_device {
struct completion work;
struct regulator *vdd;
struct regulator *vio;
- int gpio_reset;
+ struct gpio_desc *gpio_reset;
u32 power_state;
u32 rds_enabled;
u32 frequency;
--
2.1.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 4/8] [media] si4713: use managed irq request
Introduce the usage of managed irq request to
simplify the code slightly.
Signed-off-by: Sebastian Reichel s...@kernel.org
---
drivers/media/radio/si4713/si4713.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/media/radio/si4713/si4713.c
b/drivers/media/radio/si4713/si4713.c
index efc5d6b..ebec16d 100644
--- a/drivers/media/radio/si4713/si4713.c
+++ b/drivers/media/radio/si4713/si4713.c
@@ -1590,7 +1590,7 @@ static int si4713_probe(struct i2c_client *client,
sdev-sd.ctrl_handler = hdl;
if (client-irq) {
- rval = request_irq(client-irq,
+ rval = devm_request_irq(client-dev, client-irq,
si4713_handler, IRQF_TRIGGER_FALLING,
client-name, sdev);
if (rval 0) {
@@ -1605,14 +1605,11 @@ static int si4713_probe(struct i2c_client *client,
rval = si4713_initialize(sdev);
if (rval 0) {
v4l2_err(sdev-sd, Failed to probe device information.\n);
- goto free_irq;
+ goto free_ctrls;
}
return 0;
-free_irq:
- if (client-irq)
- free_irq(client-irq, sdev);
free_ctrls:
v4l2_ctrl_handler_free(hdl);
exit:
@@ -1628,9 +1625,6 @@ static int si4713_remove(struct i2c_client *client)
if (sdev-power_state)
si4713_set_power_state(sdev, POWER_DOWN);
- if (client-irq 0)
- free_irq(client-irq, sdev);
-
v4l2_device_unregister_subdev(sd);
v4l2_ctrl_handler_free(sd-ctrl_handler);
--
2.1.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 3/8] [media] si4713: use managed memory allocation
Introduce the usage of managed memory allocation to
simplify the code slightly.
Signed-off-by: Sebastian Reichel s...@kernel.org
---
drivers/media/radio/si4713/si4713.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/media/radio/si4713/si4713.c
b/drivers/media/radio/si4713/si4713.c
index e560a7e..efc5d6b 100644
--- a/drivers/media/radio/si4713/si4713.c
+++ b/drivers/media/radio/si4713/si4713.c
@@ -1450,7 +1450,7 @@ static int si4713_probe(struct i2c_client *client,
struct v4l2_ctrl_handler *hdl;
int rval, i;
- sdev = kzalloc(sizeof(*sdev), GFP_KERNEL);
+ sdev = devm_kzalloc(client-dev, sizeof(*sdev), GFP_KERNEL);
if (!sdev) {
dev_err(client-dev, Failed to alloc video device.\n);
rval = -ENOMEM;
@@ -1467,7 +1467,7 @@ static int si4713_probe(struct i2c_client *client,
} else {
rval = PTR_ERR(sdev-gpio_reset);
dev_err(client-dev, Failed to request gpio: %d\n, rval);
- goto free_sdev;
+ goto exit;
}
sdev-vdd = devm_regulator_get_optional(client-dev, vdd);
@@ -1615,8 +1615,6 @@ free_irq:
free_irq(client-irq, sdev);
free_ctrls:
v4l2_ctrl_handler_free(hdl);
-free_sdev:
- kfree(sdev);
exit:
return rval;
}
@@ -1635,7 +1633,6 @@ static int si4713_remove(struct i2c_client *client)
v4l2_device_unregister_subdev(sd);
v4l2_ctrl_handler_free(sd-ctrl_handler);
- kfree(sdev);
return 0;
}
--
2.1.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 5/8] [media] si4713: add device tree support
Add device tree support by changing the device registration order.
In the device tree the si4713 node is a normal I2C device, which
will be probed as such. Thus the V4L device must be probed from
the I2C device and not the other way around.
Signed-off-by: Sebastian Reichel s...@kernel.org
---
drivers/media/radio/si4713/radio-platform-si4713.c | 28 --
drivers/media/radio/si4713/si4713.c| 34 --
drivers/media/radio/si4713/si4713.h| 6
include/media/radio-si4713.h | 30 ---
include/media/si4713.h | 1 +
5 files changed, 45 insertions(+), 54 deletions(-)
delete mode 100644 include/media/radio-si4713.h
diff --git a/drivers/media/radio/si4713/radio-platform-si4713.c
b/drivers/media/radio/si4713/radio-platform-si4713.c
index a47502a..2de5439 100644
--- a/drivers/media/radio/si4713/radio-platform-si4713.c
+++ b/drivers/media/radio/si4713/radio-platform-si4713.c
@@ -34,7 +34,7 @@
#include media/v4l2-fh.h
#include media/v4l2-ctrls.h
#include media/v4l2-event.h
-#include media/radio-si4713.h
+#include si4713.h
/* module parameters */
static int radio_nr = -1; /* radio device minor (-1 == auto assign) */
@@ -153,7 +153,6 @@ static int radio_si4713_pdriver_probe(struct
platform_device *pdev)
{
struct radio_si4713_platform_data *pdata = pdev-dev.platform_data;
struct radio_si4713_device *rsdev;
- struct i2c_adapter *adapter;
struct v4l2_subdev *sd;
int rval = 0;
@@ -177,20 +176,11 @@ static int radio_si4713_pdriver_probe(struct
platform_device *pdev)
goto exit;
}
- adapter = i2c_get_adapter(pdata-i2c_bus);
- if (!adapter) {
- dev_err(pdev-dev, Cannot get i2c adapter %d\n,
- pdata-i2c_bus);
- rval = -ENODEV;
- goto unregister_v4l2_dev;
- }
-
- sd = v4l2_i2c_new_subdev_board(rsdev-v4l2_dev, adapter,
- pdata-subdev_board_info, NULL);
- if (!sd) {
+ sd = i2c_get_clientdata(pdata-subdev);
+ rval = v4l2_device_register_subdev(rsdev-v4l2_dev, sd);
+ if (rval) {
dev_err(pdev-dev, Cannot get v4l2 subdevice\n);
- rval = -ENODEV;
- goto put_adapter;
+ goto unregister_v4l2_dev;
}
rsdev-radio_dev = radio_si4713_vdev_template;
@@ -202,14 +192,12 @@ static int radio_si4713_pdriver_probe(struct
platform_device *pdev)
if (video_register_device(rsdev-radio_dev, VFL_TYPE_RADIO, radio_nr))
{
dev_err(pdev-dev, Could not register video device.\n);
rval = -EIO;
- goto put_adapter;
+ goto unregister_v4l2_dev;
}
dev_info(pdev-dev, New device successfully probed\n);
goto exit;
-put_adapter:
- i2c_put_adapter(adapter);
unregister_v4l2_dev:
v4l2_device_unregister(rsdev-v4l2_dev);
exit:
@@ -220,14 +208,10 @@ exit:
static int radio_si4713_pdriver_remove(struct platform_device *pdev)
{
struct v4l2_device *v4l2_dev = platform_get_drvdata(pdev);
- struct v4l2_subdev *sd = list_entry(v4l2_dev-subdevs.next,
- struct v4l2_subdev, list);
- struct i2c_client *client = v4l2_get_subdevdata(sd);
struct radio_si4713_device *rsdev;
rsdev = container_of(v4l2_dev, struct radio_si4713_device, v4l2_dev);
video_unregister_device(rsdev-radio_dev);
- i2c_put_adapter(client-adapter);
v4l2_device_unregister(rsdev-v4l2_dev);
return 0;
diff --git a/drivers/media/radio/si4713/si4713.c
b/drivers/media/radio/si4713/si4713.c
index ebec16d..94fe3c6 100644
--- a/drivers/media/radio/si4713/si4713.c
+++ b/drivers/media/radio/si4713/si4713.c
@@ -1446,9 +1446,13 @@ static int si4713_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct si4713_device *sdev;
- struct si4713_platform_data *pdata = client-dev.platform_data;
struct v4l2_ctrl_handler *hdl;
- int rval, i;
+ struct si4713_platform_data *pdata = client-dev.platform_data;
+ struct device_node *np = client-dev.of_node;
+ int rval;
+
+ struct radio_si4713_platform_data si4713_pdev_pdata;
+ struct platform_device *si4713_pdev;
sdev = devm_kzalloc(client-dev, sizeof(*sdev), GFP_KERNEL);
if (!sdev) {
@@ -1608,8 +1612,31 @@ static int si4713_probe(struct i2c_client *client,
goto free_ctrls;
}
+ if ((pdata pdata-is_platform_device) || np) {
+ si4713_pdev = platform_device_alloc(radio-si4713, -1);
+ if (!si4713_pdev)
+ goto put_main_pdev;
+
+ si4713_pdev_pdata.subdev = client;
+ rval =
[RFCv2 7/8] ARM: OMAP2: RX-51: update si4713 platform data
This updates platform data related to Si4713, which
has been updated to be compatible with DT interface.
Signed-off-by: Sebastian Reichel s...@kernel.org
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 69 +---
1 file changed, 31 insertions(+), 38 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index ddfc8df..ec2e410 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -23,6 +23,7 @@
#include linux/regulator/machine.h
#include linux/gpio.h
#include linux/gpio_keys.h
+#include linux/gpio/machine.h
#include linux/mmc/host.h
#include linux/power/isp1704_charger.h
#include linux/platform_data/spi-omap2-mcspi.h
@@ -38,7 +39,6 @@
#include sound/tlv320aic3x.h
#include sound/tpa6130a2-plat.h
-#include media/radio-si4713.h
#include media/si4713.h
#include linux/platform_data/leds-lp55xx.h
@@ -760,46 +760,17 @@ static struct regulator_init_data rx51_vintdig = {
},
};
-static const char * const si4713_supply_names[] = {
- vio,
- vdd,
-};
-
-static struct si4713_platform_data rx51_si4713_i2c_data __initdata_or_module =
{
- .supplies = ARRAY_SIZE(si4713_supply_names),
- .supply_names = si4713_supply_names,
- .gpio_reset = RX51_FMTX_RESET_GPIO,
-};
-
-static struct i2c_board_info rx51_si4713_board_info __initdata_or_module = {
- I2C_BOARD_INFO(si4713, SI4713_I2C_ADDR_BUSEN_HIGH),
- .platform_data = rx51_si4713_i2c_data,
-};
-
-static struct radio_si4713_platform_data rx51_si4713_data __initdata_or_module
= {
- .i2c_bus= 2,
- .subdev_board_info = rx51_si4713_board_info,
-};
-
-static struct platform_device rx51_si4713_dev __initdata_or_module = {
- .name = radio-si4713,
- .id = -1,
- .dev= {
- .platform_data = rx51_si4713_data,
+static struct gpiod_lookup_table rx51_fmtx_gpios_table = {
+ .dev_id = 2-0063,
+ .table = {
+ GPIO_LOOKUP(gpio.6, 3, reset, GPIO_ACTIVE_HIGH), /* 163 */
+ { },
},
};
-static __init void rx51_init_si4713(void)
+static __init void rx51_gpio_init(void)
{
- int err;
-
- err = gpio_request_one(RX51_FMTX_IRQ, GPIOF_DIR_IN, si4713 irq);
- if (err) {
- printk(KERN_ERR Cannot request si4713 irq gpio. %d\n, err);
- return;
- }
- rx51_si4713_board_info.irq = gpio_to_irq(RX51_FMTX_IRQ);
- platform_device_register(rx51_si4713_dev);
+ gpiod_add_lookup_table(rx51_fmtx_gpios_table);
}
static int rx51_twlgpio_setup(struct device *dev, unsigned gpio, unsigned n)
@@ -1029,7 +1000,17 @@ static struct aic3x_pdata rx51_aic3x_data2 = {
.gpio_reset = 60,
};
+static struct si4713_platform_data rx51_si4713_platform_data = {
+ .is_platform_device = true
+};
+
static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_2[] = {
+#if IS_ENABLED(CONFIG_I2C_SI4713) IS_ENABLED(CONFIG_PLATFORM_SI4713)
+ {
+ I2C_BOARD_INFO(si4713, 0x63),
+ .platform_data = rx51_si4713_platform_data,
+ },
+#endif
{
I2C_BOARD_INFO(tlv320aic3x, 0x18),
.platform_data = rx51_aic3x_data,
@@ -1070,6 +1051,10 @@ static struct i2c_board_info __initdata
rx51_peripherals_i2c_board_info_3[] = {
static int __init rx51_i2c_init(void)
{
+#if IS_ENABLED(CONFIG_I2C_SI4713) IS_ENABLED(CONFIG_PLATFORM_SI4713)
+ int err;
+#endif
+
if ((system_rev = SYSTEM_REV_S_USES_VAUX3 system_rev 0x100) ||
system_rev = SYSTEM_REV_B_USES_VAUX3) {
rx51_twldata.vaux3 = rx51_vaux3_mmc;
@@ -1087,6 +1072,14 @@ static int __init rx51_i2c_init(void)
rx51_twldata.vdac-constraints.name = VDAC;
omap_pmic_init(1, 2200, twl5030, 7 + OMAP_INTC_START, rx51_twldata);
+#if IS_ENABLED(CONFIG_I2C_SI4713) IS_ENABLED(CONFIG_PLATFORM_SI4713)
+ err = gpio_request_one(RX51_FMTX_IRQ, GPIOF_DIR_IN, si4713 irq);
+ if (err) {
+ printk(KERN_ERR Cannot request si4713 irq gpio. %d\n, err);
+ return err;
+ }
+ rx51_peripherals_i2c_board_info_2[0].irq = gpio_to_irq(RX51_FMTX_IRQ);
+#endif
omap_register_i2c_bus(2, 100, rx51_peripherals_i2c_board_info_2,
ARRAY_SIZE(rx51_peripherals_i2c_board_info_2));
#if defined(CONFIG_SENSORS_LIS3_I2C) || defined(CONFIG_SENSORS_LIS3_I2C_MODULE)
@@ -1300,6 +1293,7 @@ static void __init rx51_init_omap3_rom_rng(void)
void __init rx51_peripherals_init(void)
{
+ rx51_gpio_init();
rx51_i2c_init();
regulator_has_full_constraints();
gpmc_onenand_init(board_onenand_data);
@@ -1307,7 +1301,6 @@ void __init rx51_peripherals_init(void)
rx51_add_gpio_keys();
rx51_init_wl1251();
rx51_init_tsc2005();
- rx51_init_si4713();
[RFCv2 0/8] [media] si4713 DT binding
Hi, This is the RFCv2 patchset adding DT support to the si4713 radio transmitter i2c driver. The changes can be summarized as follows: * Move regulator information back into the driver. The regulators needed are documented in the chip and have nothing to do with boarddata. Instead devm_regulator_get_optional is used and errors are handled quite loosely now. Maybe the USB driver should provide dummy regulators. * GPIO handling is updated to gpiod consumer interface, resulting in a driver cleanup and easy DT handling * The driver is updated to use managed resources wherever possible So much about the nice stuff. But there is also * Instantiation of the platform device from the i2c (sub-)device. Since DT is not supposed to contain linuxisms the device is a simple i2c node resulting in the i2c probe function being called. Thus registering the main v4l device must happen from there. Tested: * Compilation on torvalds/linux.git:master (based on 52d589a) * Booting in DT mode * Some simply driver queries using v4l2-ctl Not tested: * The USB driver, since I do not own the USB dongle * The legacy platform code (only DT boot has been tested). (The legacy platform code is supposed to removed in the near future anyways) Changes since RFCv1 (requested by Hans Verkuil): - splitted the patchset into more patches - replaced dev_info with dev_dbg for missing regulators - check for ENOSYS value from devm_gpiod_get (disabled GPIOLIB) -- Sebastian Sebastian Reichel (8): [media] si4713: switch to devm regulator API [media] si4713: switch reset gpio to devm_gpiod API [media] si4713: use managed memory allocation [media] si4713: use managed irq request [media] si4713: add device tree support [media] si4713: add DT binding documentation ARM: OMAP2: RX-51: update si4713 platform data [media] si4713: cleanup platform data Documentation/devicetree/bindings/media/si4713.txt | 30 arch/arm/mach-omap2/board-rx51-peripherals.c | 69 - drivers/media/radio/si4713/radio-platform-si4713.c | 28 +--- drivers/media/radio/si4713/si4713.c| 167 + drivers/media/radio/si4713/si4713.h| 15 +- include/media/radio-si4713.h | 30 include/media/si4713.h | 4 +- 7 files changed, 186 insertions(+), 157 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/si4713.txt delete mode 100644 include/media/radio-si4713.h -- 2.1.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 1/8] [media] si4713: switch to devm regulator API
This switches back to the normal regulator API (but use
managed variant) in preparation for device tree support.
Signed-off-by: Sebastian Reichel s...@kernel.org
---
drivers/media/radio/si4713/si4713.c | 80 ++---
drivers/media/radio/si4713/si4713.h | 6 +--
2 files changed, 58 insertions(+), 28 deletions(-)
diff --git a/drivers/media/radio/si4713/si4713.c
b/drivers/media/radio/si4713/si4713.c
index b576555..b335093 100644
--- a/drivers/media/radio/si4713/si4713.c
+++ b/drivers/media/radio/si4713/si4713.c
@@ -23,6 +23,7 @@
#include linux/completion.h
#include linux/delay.h
+#include linux/err.h
#include linux/interrupt.h
#include linux/i2c.h
#include linux/slab.h
@@ -366,13 +367,22 @@ static int si4713_powerup(struct si4713_device *sdev)
if (sdev-power_state)
return 0;
- if (sdev-supplies) {
- err = regulator_bulk_enable(sdev-supplies, sdev-supply_data);
+ if (sdev-vdd) {
+ err = regulator_enable(sdev-vdd);
if (err) {
- v4l2_err(sdev-sd, Failed to enable supplies: %d\n,
err);
+ v4l2_err(sdev-sd, Failed to enable vdd: %d\n, err);
return err;
}
}
+
+ if (sdev-vio) {
+ err = regulator_enable(sdev-vio);
+ if (err) {
+ v4l2_err(sdev-sd, Failed to enable vio: %d\n, err);
+ return err;
+ }
+ }
+
if (gpio_is_valid(sdev-gpio_reset)) {
udelay(50);
gpio_set_value(sdev-gpio_reset, 1);
@@ -399,11 +409,18 @@ static int si4713_powerup(struct si4713_device *sdev)
}
if (gpio_is_valid(sdev-gpio_reset))
gpio_set_value(sdev-gpio_reset, 0);
- if (sdev-supplies) {
- err = regulator_bulk_disable(sdev-supplies, sdev-supply_data);
+
+
+ if (sdev-vdd) {
+ err = regulator_disable(sdev-vdd);
if (err)
- v4l2_err(sdev-sd,
-Failed to disable supplies: %d\n, err);
+ v4l2_err(sdev-sd, Failed to disable vdd: %d\n, err);
+ }
+
+ if (sdev-vio) {
+ err = regulator_disable(sdev-vio);
+ if (err)
+ v4l2_err(sdev-sd, Failed to disable vio: %d\n, err);
}
return err;
@@ -432,12 +449,21 @@ static int si4713_powerdown(struct si4713_device *sdev)
v4l2_dbg(1, debug, sdev-sd, Device in reset mode\n);
if (gpio_is_valid(sdev-gpio_reset))
gpio_set_value(sdev-gpio_reset, 0);
- if (sdev-supplies) {
- err = regulator_bulk_disable(sdev-supplies,
-sdev-supply_data);
- if (err)
+
+ if (sdev-vdd) {
+ err = regulator_disable(sdev-vdd);
+ if (err) {
+ v4l2_err(sdev-sd,
+ Failed to disable vdd: %d\n, err);
+ }
+ }
+
+ if (sdev-vio) {
+ err = regulator_disable(sdev-vio);
+ if (err) {
v4l2_err(sdev-sd,
-Failed to disable supplies: %d\n,
err);
+ Failed to disable vio: %d\n, err);
+ }
}
sdev-power_state = POWER_OFF;
}
@@ -1441,17 +1467,26 @@ static int si4713_probe(struct i2c_client *client,
}
sdev-gpio_reset = pdata-gpio_reset;
gpio_direction_output(sdev-gpio_reset, 0);
- sdev-supplies = pdata-supplies;
}
- for (i = 0; i sdev-supplies; i++)
- sdev-supply_data[i].supply = pdata-supply_names[i];
+ sdev-vdd = devm_regulator_get_optional(client-dev, vdd);
+ if (IS_ERR(sdev-vdd)) {
+ rval = PTR_ERR(sdev-vdd);
+ if (rval == -EPROBE_DEFER)
+ goto exit;
+
+ dev_dbg(client-dev, no vdd regulator found: %d\n, rval);
+ sdev-vdd = NULL;
+ }
+
+ sdev-vio = devm_regulator_get_optional(client-dev, vio);
+ if (IS_ERR(sdev-vio)) {
+ rval = PTR_ERR(sdev-vio);
+ if (rval == -EPROBE_DEFER)
+ goto exit;
- rval = regulator_bulk_get(client-dev, sdev-supplies,
- sdev-supply_data);
- if (rval) {
- dev_err(client-dev, Cannot get regulators: %d\n, rval);
- goto free_gpio;
+ dev_dbg(client-dev, no vio regulator found: %d\n, rval);
+ sdev-vio = NULL;
}
v4l2_i2c_subdev_init(sdev-sd, client,
Re: [media-workshop] [ANNOUNCE] Media summit Report - October, 17-18 2014 - Düsseldorf
Em Tue, 21 Oct 2014 12:53:16 -0200 Mauro Carvalho Chehab mche...@osg.samsung.com escreveu: This report is also available in html at: http://linuxtv.org/news.php?entry=2014-10-21.mchehab In the name of the organizing committee, I'd like to thank you all for being there with us during those two days. There were several good discussions that happened during the meeting, aimed to improve even more the Linux media subsystem. Also, it was agreed during the meeting that we'll try to reach an even broader audience on the next events. So we're counting with all you on our next year's event(s). Thanks! Mauro - Attendees, in alphabetical order: NAME - EMAIL - ORGANIZATION Brad Love - bl...@hauppauge.com - Hauppauge Chris Kohn- christian.k...@xilinx.com - Xilinx Friedrich Schwittay - fschwit...@pctvsystems.com- PCTV Guennaddi Liakhovetski- g.liakhovet...@gmx.de - Intel Hans de Goede - hdego...@redhat.com - Red hat Hans Verkuil - hverk...@xs4all.nl- Cisco Henning Garbers - hgarb...@pctvsystems.com - PCTV Johannes Stezenbach - j...@linuxtv.org - LinuxTV Julien Beraud - julien.ber...@parrot.com - Parrot (www.parrot.com) Kamil Debski - k.deb...@samsung.com - Samsung Laurent Pinchart - laurent.pinch...@ideasonboard.com - Ideas on board Lucas Stach - l.st...@pengutronix.de- Pengutronix Mauro Carvalho Chehab - mche...@osg.samsung.com - Samsung Mike Krufky - mkru...@linuxtv.org - Samsung Nicolas Dufresne - nicolas.dufre...@collabora.com- Collabora Pawel Osciak - pa...@osciak.com - Google Peter Griffin - peter.grif...@linaro.org - Linaro/ST Philipp Zabel - p.za...@pengutronix.de- Pengutronix Ralph Metzler - r...@metzlerbros.de - Meltzler Brothers Ricardo Ribalda Delgado - rica...@qtec.com - Qtechnolgy A/S Sakari Ailus - sakari.ai...@linux.intel.com - Intel Thursday: 1) Configuration stores - Hans Verkuil === - Need to report which settings/controls were applied - Drivers needs to be able to report full/limited Android CameraHAL v3 support (full means full synchronization support) - We probably need a mechanism to be able to remove (free) config stores - Can we use APPLY(0) instead of CLOSE? - Per buffer or per frame configuration? Note: there is no notion of frame IDs yet in V4L2. - Would be nice to be able to disable APPLY, perhaps a flag for the core similar to HAS STORE 2) Android camera HAL v3 - Sakari Ailus http://www.retiisi.org.uk/v4l2/foil/android-camera-hal-v3-v4l2.pdf - Capture requests queued lead to returned buffers in order, best effort to make per-buffer configuration apply correctly needed - Capture requests/returned buffers do not map directly to QBUF/DQBUF because multiple buffers in different formats may be produced from a single request. Some outputs could be implemented in software, e.g. multiple YUV outputs when hardware simply does not contain as many. - Should statistical data be returned in a separate video buffer queue? Might be associated via sequence number, probably separate frame ID better - 3A library input: frame metadata, depends on sensor, might be in-frame or out-of band. If possible, separate buffer queue prepared to get to it early. - HAL v3 needs Start Of Frame and End Of Frame events - If there is no hardware mechanism for synchronization, apply sensor settings as soon as possible after SOF and hope for the best. It is possible to verify the timing has been successful in the user space. - Sensor settings and ISP settings applied at different points in time, as sensor settings usally take effect on the following frame - Sensors may implement all or parts of the ISP themselves. It may not be feasible to implement hal v3 full profile for such sensors. - Start of Exposure events not to be implemented in the kernel. HAL must calculate the event time based on other available information, such as end of frame (or start of frame event) and other frame timing parameters. - Some metadata tags could be mapped to V4L2 (compound) controls, they are associated with a single capture request. Some metadata tags (statistics) are produced from video buffer queues. Other metadata tags originate from HAL. - Needs a guarantee that a single capture request will produce all buffers requested by it with the request's parameters, needs per-buffer configuration,
Re: [media-workshop] [ANNOUNCE] Media summit Report - October, 17-18 2014 - Düsseldorf
On 10/21/2014 05:26 PM, Mauro Carvalho Chehab wrote: Em Tue, 21 Oct 2014 12:53:16 -0200 Mauro Carvalho Chehab mche...@osg.samsung.com escreveu: This report is also available in html at: http://linuxtv.org/news.php?entry=2014-10-21.mchehab In the name of the organizing committee, I'd like to thank you all for being there with us during those two days. There were several good discussions that happened during the meeting, aimed to improve even more the Linux media subsystem. Also, it was agreed during the meeting that we'll try to reach an even broader audience on the next events. So we're counting with all you on our next year's event(s). Thanks! Mauro - Attendees, in alphabetical order: NAME- EMAIL - ORGANIZATION Brad Love - bl...@hauppauge.com - Hauppauge Chris Kohn - christian.k...@xilinx.com - Xilinx Friedrich Schwittay - fschwit...@pctvsystems.com- PCTV Guennaddi Liakhovetski - g.liakhovet...@gmx.de - Intel Hans de Goede - hdego...@redhat.com - Red hat Hans Verkuil- hverk...@xs4all.nl- Cisco Henning Garbers - hgarb...@pctvsystems.com - PCTV Johannes Stezenbach - j...@linuxtv.org - LinuxTV Julien Beraud - julien.ber...@parrot.com - Parrot (www.parrot.com) Kamil Debski- k.deb...@samsung.com - Samsung Laurent Pinchart- laurent.pinch...@ideasonboard.com - Ideas on board Lucas Stach - l.st...@pengutronix.de- Pengutronix Mauro Carvalho Chehab - mche...@osg.samsung.com - Samsung Mike Krufky - mkru...@linuxtv.org - Samsung Nicolas Dufresne- nicolas.dufre...@collabora.com- Collabora Pawel Osciak- pa...@osciak.com - Google Peter Griffin - peter.grif...@linaro.org - Linaro/ST Philipp Zabel - p.za...@pengutronix.de- Pengutronix Ralph Metzler - r...@metzlerbros.de - Meltzler Brothers Ricardo Ribalda Delgado - rica...@qtec.com - Qtechnolgy A/S Sakari Ailus- sakari.ai...@linux.intel.com - Intel Thursday: 1) Configuration stores - Hans Verkuil === - Need to report which settings/controls were applied - Drivers needs to be able to report full/limited Android CameraHAL v3 support (full means full synchronization support) - We probably need a mechanism to be able to remove (free) config stores - Can we use APPLY(0) instead of CLOSE? - Per buffer or per frame configuration? Note: there is no notion of frame IDs yet in V4L2. - Would be nice to be able to disable APPLY, perhaps a flag for the core similar to HAS STORE 2) Android camera HAL v3 - Sakari Ailus http://www.retiisi.org.uk/v4l2/foil/android-camera-hal-v3-v4l2.pdf - Capture requests queued lead to returned buffers in order, best effort to make per-buffer configuration apply correctly needed - Capture requests/returned buffers do not map directly to QBUF/DQBUF because multiple buffers in different formats may be produced from a single request. Some outputs could be implemented in software, e.g. multiple YUV outputs when hardware simply does not contain as many. - Should statistical data be returned in a separate video buffer queue? Might be associated via sequence number, probably separate frame ID better - 3A library input: frame metadata, depends on sensor, might be in-frame or out-of band. If possible, separate buffer queue prepared to get to it early. - HAL v3 needs Start Of Frame and End Of Frame events - If there is no hardware mechanism for synchronization, apply sensor settings as soon as possible after SOF and hope for the best. It is possible to verify the timing has been successful in the user space. - Sensor settings and ISP settings applied at different points in time, as sensor settings usally take effect on the following frame - Sensors may implement all or parts of the ISP themselves. It may not be feasible to implement hal v3 full profile for such sensors. - Start of Exposure events not to be implemented in the kernel. HAL must calculate the event time based on other available information, such as end of frame (or start of frame event) and other frame timing parameters. - Some metadata tags could be mapped to V4L2 (compound) controls, they are associated with a single capture request. Some metadata tags (statistics) are produced from video buffer queues. Other metadata tags originate from HAL. - Needs a guarantee that a single capture request will produce all buffers requested by it with the request's parameters, needs per-buffer configuration, associating buffers with a certain
Re: [media] CODA960: Fails to allocate memory
2014-10-21 15:49 GMT+02:00 Hans Verkuil hverk...@xs4all.nl:
On 10/21/2014 03:42 PM, Jean-Michel Hautbois wrote:
Hi Hans,
2014-10-21 15:27 GMT+02:00 Hans Verkuil hverk...@xs4all.nl:
On 10/21/2014 03:16 PM, Jean-Michel Hautbois wrote:
Hi,
I am trying to use the CODA960 driver on a 3.18 kernel.
It seems pretty good when the module is probed (appart from the
unsupported firmware version) but when I try using the encoder, it
fails allocating dma buffers.
Here is the DT part I added :
vpu {
compatible = fsl,imx6q-vpu;
clocks = clks 168, clks 140, clks 142;
clock-names = per, ahb, ocram;
iramsize = 0x21000;
iram = ocram;
resets = src 1;
status = okay;
};
When booting, I see :
[4.410645] coda 204.vpu: Firmware code revision: 46056
[4.416312] coda 204.vpu: Initialized CODA960.
[4.421123] coda 204.vpu: Unsupported firmware version: 3.1.1
[4.483577] coda 204.vpu: codec registered as /dev/video[0-1]
I can start v4l2-ctl and it shows that the device seems to be ok :
v4l2-ctl --all -d /dev/video1
Driver Info (not using libv4l2):
Driver name : coda
Card type : CODA960
Bus info : platform:coda
Driver version: 3.18.0
Capabilities : 0x84208000
Video Memory-to-Memory
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04208000
Video Memory-to-Memory
Streaming
Extended Pix Format
Priority: 2
Format Video Capture:
Width/Height : 1920/1088
Pixel Format : 'YU12'
Field : None
Bytes per Line: 1920
Size Image: 3133440
Colorspace: HDTV and modern devices (ITU709)
Flags :
Format Video Output:
Width/Height : 1920/1088
Pixel Format : 'H264'
Field : None
Bytes per Line: 0
Size Image: 1048576
Colorspace: HDTV and modern devices (ITU709)
Flags :
Selection: compose, Left 0, Top 0, Width 1920, Height 1088
Selection: compose_default, Left 0, Top 0, Width 1920, Height 1088
Selection: compose_bounds, Left 0, Top 0, Width 1920, Height 1088
Selection: compose_padded, Left 0, Top 0, Width 1920, Height 1088
Selection: crop, Left 0, Top 0, Width 1920, Height 1088
Selection: crop_default, Left 0, Top 0, Width 1920, Height 1088
Selection: crop_bounds, Left 0, Top 0, Width 1920, Height 1088
User Controls
horizontal_flip (bool) : default=0 value=0
vertical_flip (bool) : default=0 value=0
Codec Controls
video_gop_size (int): min=1 max=60 step=1
default=16 value=16
video_bitrate (int): min=0 max=32767000 step=1
default=0 value=0
number_of_intra_refresh_mbs (int): min=0 max=8160 step=1
default=0 value=0
sequence_header_mode (menu) : min=0 max=1 default=1
value=1
maximum_bytes_in_a_slice (int): min=1 max=1073741823 step=1
default=500 value=500
number_of_mbs_in_a_slice (int): min=1 max=1073741823 step=1
default=1 value=1
slice_partitioning_method (menu) : min=0 max=2 default=0
value=0
h264_i_frame_qp_value (int): min=0 max=51 step=1
default=25 value=25
h264_p_frame_qp_value (int): min=0 max=51 step=1
default=25 value=25
h264_maximum_qp_value (int): min=0 max=51 step=1
default=51 value=51
h264_loop_filter_alpha_offset (int): min=0 max=15 step=1
default=0
value=0
h264_loop_filter_beta_offset (int): min=0 max=15 step=1
default=0
value=0
h264_loop_filter_mode (menu) : min=0 max=1 default=0
value=0
mpeg4_i_frame_qp_value (int): min=1 max=31 step=1
default=2
value=2
mpeg4_p_frame_qp_value (int): min=1 max=31 step=1
default=2
value=2
horizontal_flip (bool) : default=0 value=0
vertical_flip (bool) : default=0 value=0
But when I try to get a file outputed, it fails :
v4l2-ctl -d1 --stream-out-mmap --stream-mmap --stream-to x.raw
[ 1197.292256] coda 204.vpu: dma_alloc_coherent of size 1048576
failed
VIDIOC_REQBUFS: failed: Cannot allocate memory
Did I forget to do something ?
I assume this is physically contiguous memory. Do you have that much
phys.
cont. memory
available at all? If the memory is fragmented you won't be able to get
it.
Use cma (contiguous memory allocator). You probably have to do very
little
expect add
a kernel option to assign enough memory for these buffers.
I added a cma=128M in order to reserve some meory, and it fails...
well, differently :).
~# v4l2-ctl -d1 --stream-out-mmap --stream-mmap --stream-to x.raw
[
Re: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api
On 10/16/2014 04:48 PM, Takashi Iwai wrote:
At Thu, 16 Oct 2014 08:39:14 -0600,
Shuah Khan wrote:
On 10/16/2014 08:16 AM, Takashi Iwai wrote:
At Thu, 16 Oct 2014 08:10:52 -0600,
Shuah Khan wrote:
On 10/16/2014 08:01 AM, Takashi Iwai wrote:
At Thu, 16 Oct 2014 07:10:37 -0600,
Shuah Khan wrote:
On 10/16/2014 06:00 AM, Lars-Peter Clausen wrote:
On 10/14/2014 04:58 PM, Shuah Khan wrote:
[...]
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
+err = media_get_audio_tkn(subs-dev-dev);
+if (err == -EBUSY) {
+dev_info(subs-dev-dev, %s device is busy\n,
+__func__);
In my opinion this should not dev_info() as this is out of band error
signaling and also as the potential to spam the log. The userspace
application is already properly notified by the return code.
Yes it has the potential to flood the dmesg especially with alsa,
I will remove the dev_info().
Yes. And, I think doing this in the trigger isn't the best.
Why not in open close?
My first cut of this change was in open and close. I saw pulseaudio
application go into this loop trying to open the device. To avoid
such problems, I went with trigger stat and stop. That made all the
pulseaudio continues attempts to open problems go away.
But now starting the stream gives the error, and PA would loop it
again, no?
Also, is this token restriction needed only for PCM? No mixer or
other controls?
snd_pcm_ops are the only ones media drivers implement and use. So
I don't think mixer is needed. If it is needed, it is not to hard
to add for that case.
Well, then I wonder what resource does actually conflict with
usb-audio and media drivers at all...?
audio for dvb/v4l apps gets disrupted when audio app starts. For
example, dvb or v4l app tuned to a channel, and when an audio app
starts. audio path needs protected to avoid conflicts between
digital and analog applications as well.
OK, then concentrating on only PCM is fine.
But, I'm still not convinced about doing the token management in the
trigger. The reason -EBUSY doesn't work is that it's the very same
error code when a PCM device is blocked by other processes. And
-EAGAIN is interpreted by PCM core to -EBUSY for historical reasons.
How applications (e.g. PA) should behave if the token get fails?
Shouldn't it retry or totally give up?
Quite often media apps open the alsa device at the start and then switch
between TV, radio or DVB mode. If the alsa device would claim the tuner
just by being opened (as opposed to actually using the tuner, which happens
when you start streaming), then that would make it impossible for the
application to switch tuner mode. In general you want to avoid that open()
will start configuring hardware since that can quite often be slow. Tuner
configuration in particular can be slow since several common tuners need
to load firmware over i2c. You only want to do that when it is really needed,
and not when some application (udev!) opens the device just to examine what
sort of device it is.
So claiming the tuner in the trigger seems to be the right place. If
returning EBUSY is a poor error code for alsa, then we can use something else
for that. EACCES perhaps?
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api
At Tue, 21 Oct 2014 17:42:51 +0200,
Hans Verkuil wrote:
On 10/16/2014 04:48 PM, Takashi Iwai wrote:
At Thu, 16 Oct 2014 08:39:14 -0600,
Shuah Khan wrote:
On 10/16/2014 08:16 AM, Takashi Iwai wrote:
At Thu, 16 Oct 2014 08:10:52 -0600,
Shuah Khan wrote:
On 10/16/2014 08:01 AM, Takashi Iwai wrote:
At Thu, 16 Oct 2014 07:10:37 -0600,
Shuah Khan wrote:
On 10/16/2014 06:00 AM, Lars-Peter Clausen wrote:
On 10/14/2014 04:58 PM, Shuah Khan wrote:
[...]
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
+err = media_get_audio_tkn(subs-dev-dev);
+if (err == -EBUSY) {
+dev_info(subs-dev-dev, %s device is busy\n,
+__func__);
In my opinion this should not dev_info() as this is out of band error
signaling and also as the potential to spam the log. The userspace
application is already properly notified by the return code.
Yes it has the potential to flood the dmesg especially with alsa,
I will remove the dev_info().
Yes. And, I think doing this in the trigger isn't the best.
Why not in open close?
My first cut of this change was in open and close. I saw pulseaudio
application go into this loop trying to open the device. To avoid
such problems, I went with trigger stat and stop. That made all the
pulseaudio continues attempts to open problems go away.
But now starting the stream gives the error, and PA would loop it
again, no?
Also, is this token restriction needed only for PCM? No mixer or
other controls?
snd_pcm_ops are the only ones media drivers implement and use. So
I don't think mixer is needed. If it is needed, it is not to hard
to add for that case.
Well, then I wonder what resource does actually conflict with
usb-audio and media drivers at all...?
audio for dvb/v4l apps gets disrupted when audio app starts. For
example, dvb or v4l app tuned to a channel, and when an audio app
starts. audio path needs protected to avoid conflicts between
digital and analog applications as well.
OK, then concentrating on only PCM is fine.
But, I'm still not convinced about doing the token management in the
trigger. The reason -EBUSY doesn't work is that it's the very same
error code when a PCM device is blocked by other processes. And
-EAGAIN is interpreted by PCM core to -EBUSY for historical reasons.
How applications (e.g. PA) should behave if the token get fails?
Shouldn't it retry or totally give up?
Quite often media apps open the alsa device at the start and then switch
between TV, radio or DVB mode. If the alsa device would claim the tuner
just by being opened (as opposed to actually using the tuner, which happens
when you start streaming),
What about parameter changes? The sound devices have to be configured
before using. Don't they influence on others at all, i.e. you can
change the PCM sample rate etc during TV, radio or DVB is running?
then that would make it impossible for the
application to switch tuner mode. In general you want to avoid that open()
will start configuring hardware since that can quite often be slow. Tuner
configuration in particular can be slow since several common tuners need
to load firmware over i2c. You only want to do that when it is really needed,
and not when some application (udev!) opens the device just to examine what
sort of device it is.
But most apps close the device soon after that, no?
Which programs keep the PCM device (not the control) opened without
actually using?
So claiming the tuner in the trigger seems to be the right place. If
returning EBUSY is a poor error code for alsa, then we can use something else
for that. EACCES perhaps?
Sorry, I'm not convinced by that. If the device has to be controlled
exclusively, the right position is the open/close. Otherwise, the
program cannot know when it becomes inaccessible out of sudden during
its operation.
Takashi
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api
Sorry, I'm not convinced by that. If the device has to be controlled exclusively, the right position is the open/close. Otherwise, the program cannot know when it becomes inaccessible out of sudden during its operation. I can say that I've definitely seen cases where if you configure a device as the default capture device in PulseAudio, then pulse will continue to capture from it even if you're not actively capturing the audio from pulse. I only spotted this because I had a USB analyzer on the device and was dumbfounded when the ISOC packets kept arriving even after I had closed VLC. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api
At Tue, 21 Oct 2014 12:08:59 -0400, Devin Heitmueller wrote: Sorry, I'm not convinced by that. If the device has to be controlled exclusively, the right position is the open/close. Otherwise, the program cannot know when it becomes inaccessible out of sudden during its operation. I can say that I've definitely seen cases where if you configure a device as the default capture device in PulseAudio, then pulse will continue to capture from it even if you're not actively capturing the audio from pulse. I only spotted this because I had a USB analyzer on the device and was dumbfounded when the ISOC packets kept arriving even after I had closed VLC. You might have had an input monitor active in some PA apps? PA shouldn't do it as default. If it does unintentionally, you should report it to PA guys. Takashi -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] DocBook: Reduce noise from make cleandocs
I've got a harmless warning when running make cleandocs on an already cleaned tree: Documentation/DocBook/media/Makefile:28: recipe for target 'cleanmediadocs' failed make[1]: [cleanmediadocs] Error 1 (ignored) Suppress this by passing -f to rm. Signed-off-by: Takashi Iwai ti...@suse.de --- Documentation/DocBook/media/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/DocBook/media/Makefile b/Documentation/DocBook/media/Makefile index df2962d9e11e..8bf7c6191296 100644 --- a/Documentation/DocBook/media/Makefile +++ b/Documentation/DocBook/media/Makefile @@ -25,7 +25,7 @@ GENFILES := $(addprefix $(MEDIA_OBJ_DIR)/, $(MEDIA_TEMP)) PHONY += cleanmediadocs cleanmediadocs: - -@rm `find $(MEDIA_OBJ_DIR) -type l` $(GENFILES) $(OBJIMGFILES) 2/dev/null + -@rm -f `find $(MEDIA_OBJ_DIR) -type l` $(GENFILES) $(OBJIMGFILES) 2/dev/null $(obj)/media_api.xml: $(GENFILES) FORCE -- 2.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [media] CODA960: Fails to allocate memory
Hi Jean-Michel, Am Dienstag, den 21.10.2014, 17:39 +0200 schrieb Jean-Michel Hautbois: [...] And the output is now : v4l2-ctl -d1 --stream-out-mmap --stream-mmap --stream-to x.raw [ 6208.240919] coda 204.vpu: Not output type [ 6208.245316] coda 204.vpu: streamon_out (N), streamon_cap (Y) [ 6208.251353] coda 204.vpu: fill bitstream [ 6208.255653] coda 204.vpu: fill bitstream payload : 0 VIDIOC_STREAMON: failed: Invalid argument Any idea ? JM $ trace-cmd record -e v4l2* v4l2-ctl -d13 --stream-out-mmap --stream-mmap --stream-to x.raw [...] $ trace-cmd report -R | grep bytesused [...] v4l2-ctl-308 [003] 1030.861067: v4l2_qbuf: minor=44 index=0 type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 v4l2-ctl-308 [003] 1030.861292: v4l2_qbuf: minor=44 index=1 type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 v4l2-ctl-308 [003] 1030.861471: v4l2_qbuf: minor=44 index=2 type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 v4l2-ctl-308 [003] 1030.861638: v4l2_qbuf: minor=44 index=3 type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 v4l2-ctl-308 [003] 1030.862301: v4l2_qbuf: minor=44 index=0 type=2 bytesused=3133440 flags=16387 field=1 timestamp=1030852944000 timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 v4l2-ctl-308 [003] 1030.862490: v4l2_qbuf: minor=44 index=1 type=2 bytesused=3133440 flags=16387 field=1 timestamp=1030853139000 timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 v4l2-ctl-308 [003] 1030.862672: v4l2_qbuf: minor=44 index=2 type=2 bytesused=3133440 flags=16387 field=1 timestamp=1030853322000 timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 v4l2-ctl-308 [003] 1030.862841: v4l2_qbuf: minor=44 index=3 type=2 bytesused=3133440 flags=16387 field=1 timestamp=1030853491000 timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 The decoder is fed ~ 3 MiB input buffers, which it tries (and fails) to copy into the 1 MiB bitstream ringbuffer (currently hard-coded via the badly named CODA_MAX_FRAME_SIZE constant), so the bitstream payload in the ringbuffer is 0 during start_streaming. regards Philipp -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] coda: re-queue buffers if start_streaming fails
Patch b906352c2338 ([media] coda: dequeue buffers if start_streaming fails)
incorrectly marked buffers as DEQUEUED in case of start_streaming failure, when
in fact they should be set to QUEUED. The videobuf2 core warns about this.
Reported-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/platform/coda/coda-common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index ced4760..23ace447 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -1093,10 +1093,10 @@ static int coda_start_streaming(struct vb2_queue *q,
unsigned int count)
err:
if (q-type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
while ((buf = v4l2_m2m_src_buf_remove(ctx-fh.m2m_ctx)))
- v4l2_m2m_buf_done(buf, VB2_BUF_STATE_DEQUEUED);
+ v4l2_m2m_buf_done(buf, VB2_BUF_STATE_QUEUED);
} else {
while ((buf = v4l2_m2m_dst_buf_remove(ctx-fh.m2m_ctx)))
- v4l2_m2m_buf_done(buf, VB2_BUF_STATE_DEQUEUED);
+ v4l2_m2m_buf_done(buf, VB2_BUF_STATE_QUEUED);
}
return ret;
}
--
2.1.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [media] CODA960: Fails to allocate memory
Hi Philipp, 2014-10-21 18:21 GMT+02:00 Philipp Zabel p.za...@pengutronix.de: Hi Jean-Michel, Am Dienstag, den 21.10.2014, 17:39 +0200 schrieb Jean-Michel Hautbois: [...] And the output is now : v4l2-ctl -d1 --stream-out-mmap --stream-mmap --stream-to x.raw [ 6208.240919] coda 204.vpu: Not output type [ 6208.245316] coda 204.vpu: streamon_out (N), streamon_cap (Y) [ 6208.251353] coda 204.vpu: fill bitstream [ 6208.255653] coda 204.vpu: fill bitstream payload : 0 VIDIOC_STREAMON: failed: Invalid argument Any idea ? JM $ trace-cmd record -e v4l2* v4l2-ctl -d13 --stream-out-mmap --stream-mmap --stream-to x.raw [...] $ trace-cmd report -R | grep bytesused [...] v4l2-ctl-308 [003] 1030.861067: v4l2_qbuf: minor=44 index=0 type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 v4l2-ctl-308 [003] 1030.861292: v4l2_qbuf: minor=44 index=1 type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 v4l2-ctl-308 [003] 1030.861471: v4l2_qbuf: minor=44 index=2 type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 v4l2-ctl-308 [003] 1030.861638: v4l2_qbuf: minor=44 index=3 type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 v4l2-ctl-308 [003] 1030.862301: v4l2_qbuf: minor=44 index=0 type=2 bytesused=3133440 flags=16387 field=1 timestamp=1030852944000 timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 v4l2-ctl-308 [003] 1030.862490: v4l2_qbuf: minor=44 index=1 type=2 bytesused=3133440 flags=16387 field=1 timestamp=1030853139000 timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 v4l2-ctl-308 [003] 1030.862672: v4l2_qbuf: minor=44 index=2 type=2 bytesused=3133440 flags=16387 field=1 timestamp=1030853322000 timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 v4l2-ctl-308 [003] 1030.862841: v4l2_qbuf: minor=44 index=3 type=2 bytesused=3133440 flags=16387 field=1 timestamp=1030853491000 timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 The decoder is fed ~ 3 MiB input buffers, which it tries (and fails) to copy into the 1 MiB bitstream ringbuffer (currently hard-coded via the badly named CODA_MAX_FRAME_SIZE constant), so the bitstream payload in the ringbuffer is 0 during start_streaming. Mmmh, nice, didn't thought to get perf out of there :). Well, I understand it can't feed the ringbuffer, but is there a way to make the encoder work ? I could of course modify CODA_MAX_FRAME_SIZE but this is clearly not the good thing to do... Thanks, JM -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] DocBook: Reduce noise from make cleandocs
Em Tue, 21 Oct 2014 18:18:12 +0200 Takashi Iwai ti...@suse.de escreveu: I've got a harmless warning when running make cleandocs on an already cleaned tree: Documentation/DocBook/media/Makefile:28: recipe for target 'cleanmediadocs' failed make[1]: [cleanmediadocs] Error 1 (ignored) Suppress this by passing -f to rm. Signed-off-by: Takashi Iwai ti...@suse.de Assuming that this one would go via linux-doc tree: Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com --- Documentation/DocBook/media/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/DocBook/media/Makefile b/Documentation/DocBook/media/Makefile index df2962d9e11e..8bf7c6191296 100644 --- a/Documentation/DocBook/media/Makefile +++ b/Documentation/DocBook/media/Makefile @@ -25,7 +25,7 @@ GENFILES := $(addprefix $(MEDIA_OBJ_DIR)/, $(MEDIA_TEMP)) PHONY += cleanmediadocs cleanmediadocs: - -@rm `find $(MEDIA_OBJ_DIR) -type l` $(GENFILES) $(OBJIMGFILES) 2/dev/null + -@rm -f `find $(MEDIA_OBJ_DIR) -type l` $(GENFILES) $(OBJIMGFILES) 2/dev/null $(obj)/media_api.xml: $(GENFILES) FORCE -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api
On 10/21/2014 10:05 AM, Takashi Iwai wrote: At Tue, 21 Oct 2014 17:42:51 +0200, Hans Verkuil wrote: Quite often media apps open the alsa device at the start and then switch between TV, radio or DVB mode. If the alsa device would claim the tuner just by being opened (as opposed to actually using the tuner, which happens when you start streaming), What about parameter changes? The sound devices have to be configured before using. Don't they influence on others at all, i.e. you can change the PCM sample rate etc during TV, radio or DVB is running? Yes. kaffeine uses snd_usb_capture_ops ioctl - snd_pcm_lib_ioctl Other v4l and vlc (dvb) uses open/close as well as trigger start and stop. trigger start/stop is done by a special audio thread in some cases. open/close happens from the main thread. then that would make it impossible for the application to switch tuner mode. In general you want to avoid that open() will start configuring hardware since that can quite often be slow. Tuner configuration in particular can be slow since several common tuners need to load firmware over i2c. You only want to do that when it is really needed, and not when some application (udev!) opens the device just to examine what sort of device it is. But most apps close the device soon after that, no? Which programs keep the PCM device (not the control) opened without actually using? So claiming the tuner in the trigger seems to be the right place. If returning EBUSY is a poor error code for alsa, then we can use something else for that. EACCES perhaps? Sorry, I'm not convinced by that. If the device has to be controlled exclusively, the right position is the open/close. Otherwise, the program cannot know when it becomes inaccessible out of sudden during its operation. Let me share my test matrix for this patch series. Hans pointed out one test case I didn't know about as a result missed testing. Please see if any of the tests miss use-cases or break them: you can scroll down to the proposal at the end, if this is too much detail :) Digital active and analog starting testing: kaffeine running - v4l2-ctl --all - works - Changing channels works with the same token hold, even when frequency changes. Tested changing channels that force freq change. - vlc resource is busy with no disruption to kaffeine - xawtv - tuner busy when it tries to do ioctls that change tuner settings - snd_usb_pcm_open detects device is busy ( pcm open called from the same thread, trigger gets called from another thread ) - tvtime - tuner busy when it tries to do ioctls that change tuner settings with no disruption to kaffeine ( pcm open called from the same thread, trigger gets called from another thread ) - vlc - audio capture on WinTV HVR-950 - device is busy start vlc with no channels for this test - arecord to capture on WinTV HVR-950 - device busy vlc running vlc -v channels.xspf - v4l2-ctl --all - works - Changing channels works with the same token hold, even when frequency changes. Tested changing channels that force freq change. - kaffeine resource is busy with no disruption to vlc - xawtv - tuner busy when it tries to do ioctls that change tuner settings - snd_usb_pcm_open detects device is busy ( pcm open called from the same thread, trigger gets called from another thread ) - tvtime - tuner busy when it tries to do ioctls that change tuner settings with no disruption to kaffeine ( pcm open called from the same thread, trigger gets called from another thread ) - vlc - audio capture on WinTV HVR-950 - device is busy - arecord to capture on WinTV HVR-950 - device busy Analog active and start digital testing: xawtv -noalsa -c /dev/video1 - v4l2-ctl --all - works - start kaffeine - fails with device busy and no disruption - start vlc - fails with device busy and no disruption - tvtime - tuner busy when it tries to do ioctls that change tuner settings with no disruption to kaffeine - vlc - audio capture on WinTV HVR-950 - device is busy - arecord to capture on WinTV HVR-950 - device busy tvtime - v4l2-ctl --all - works - start kaffeine - fails with device busy and no disruption - start vlc - fails with device busy and no disruption - xawtv - tuner busy when it tries to do ioctls that change tuner settings with no disruption to kaffeine - vlc - audio capture on WinTV HVR-950 - device is busy - arecord to capture on WinTV HVR-950 - device busy The following audio/video start/stop combination tests: ( used arecord as well to test these cases, arecord ) - tvtime start/vlc start/vlc stop/tvtime stop no disruption to tvtime - tvtime start/vlc start/tvtie stop/vlc stop One tvtime stops, could trigger capture manually - vlc start/tvtime start/tvtime stop/vlc stop vlc audio capture continues, tvtime detect tuner busy - vlc start/tvtime start/vlc stop/tvtime start when vlc stops, tvtime could open the tuner device Repeated the above with kaffeine and vlc and
Re: [PATCH 2/2] [media] rc-core: change enabled_protocol default setting
On Mon, Oct 20, 2014 at 5:12 PM, David Härdeman da...@hardeman.nu wrote: On 2014-10-19 12:21, Tomas Melin wrote: Change default setting for enabled protocols. Instead of enabling all protocols, disable all except lirc during registration. Reduces overhead since all protocols not handled by default. Protocol to use will be enabled when keycode table is written by userspace. I can see the appeal in this, but now you've disabled automatic decoding for the protocol specified by the keymap for raw drivers? So this would also be a change, right? Yes, you are right. Atleast it potentially still could change expected behaviour. I agree with Mauro that the proper long-term fix would be to teach the LIRC userspace daemon to enable the lirc protocol as/when necessary, but something similar to the patch below (but lirc + keymap protocol...if that's possible to implement in a non-intrusive manner, I haven't checked TBH) might be a good idea as an interim measure? I think it looks feasible to implement that way. I'll look in to it and send a new patch series. Tomas Signed-off-by: Tomas Melin tomas.me...@iki.fi --- drivers/media/rc/rc-ir-raw.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c index a118539..63d23d0 100644 --- a/drivers/media/rc/rc-ir-raw.c +++ b/drivers/media/rc/rc-ir-raw.c @@ -256,7 +256,8 @@ int ir_raw_event_register(struct rc_dev *dev) return -ENOMEM; dev-raw-dev = dev; - dev-enabled_protocols = ~0; + /* by default, disable all but lirc*/ + dev-enabled_protocols = RC_BIT_LIRC; rc = kfifo_alloc(dev-raw-kfifo, sizeof(struct ir_raw_event) * MAX_IR_EVENT_SIZE, GFP_KERNEL); -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] [media] rc-core: fix protocol_change regression in ir_raw_event_register
IR reciever using nuvoton-cir and lirc required additional configuration
steps after upgrade from kernel 3.16 to 3.17-rcX.
Bisected regression to commit da6e162d6a4607362f8478c715c797d84d449f8b
([media] rc-core: simplify sysfs code).
The regression comes from adding empty function change_protocol in
ir-raw.c. It changes behaviour so that only the protocol enabled by driver's
map_name will be active after registration. This breaks user space behaviour,
lirc does not get key press signals anymore.
Changed back to original behaviour by removing empty function
change_protocol in ir-raw.c. Instead only calling change_protocol for
drivers that actually have the function set up.
Signed-off-by: Tomas Melin tomas.me...@iki.fi
---
drivers/media/rc/rc-ir-raw.c |7 ---
drivers/media/rc/rc-main.c | 19 ---
2 files changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
index e8fff2a..a118539 100644
--- a/drivers/media/rc/rc-ir-raw.c
+++ b/drivers/media/rc/rc-ir-raw.c
@@ -240,12 +240,6 @@ ir_raw_get_allowed_protocols(void)
return protocols;
}
-static int change_protocol(struct rc_dev *dev, u64 *rc_type)
-{
- /* the caller will update dev-enabled_protocols */
- return 0;
-}
-
/*
* Used to (un)register raw event clients
*/
@@ -263,7 +257,6 @@ int ir_raw_event_register(struct rc_dev *dev)
dev-raw-dev = dev;
dev-enabled_protocols = ~0;
- dev-change_protocol = change_protocol;
rc = kfifo_alloc(dev-raw-kfifo,
sizeof(struct ir_raw_event) * MAX_IR_EVENT_SIZE,
GFP_KERNEL);
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index a7991c7..633c682 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1001,11 +1001,6 @@ static ssize_t store_protocols(struct device *device,
set_filter = dev-s_wakeup_filter;
}
- if (!change_protocol) {
- IR_dprintk(1, Protocol switching not supported\n);
- return -EINVAL;
- }
-
mutex_lock(dev-lock);
old_protocols = *current_protocols;
@@ -1013,12 +1008,14 @@ static ssize_t store_protocols(struct device *device,
rc = parse_protocol_change(new_protocols, buf);
if (rc 0)
goto out;
-
- rc = change_protocol(dev, new_protocols);
- if (rc 0) {
- IR_dprintk(1, Error setting protocols to 0x%llx\n,
- (long long)new_protocols);
- goto out;
+ /* Only if protocol change set up in driver */
+ if (change_protocol) {
+ rc = change_protocol(dev, new_protocols);
+ if (rc 0) {
+ IR_dprintk(1, Error setting protocols to 0x%llx\n,
+ (long long)new_protocols);
+ goto out;
+ }
}
if (new_protocols == old_protocols) {
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] [media] rc-core: change enabled_protocol default setting
Change default setting for enabled protocols.
Instead of enabling all protocols during registration,
disable all except default keymap and lirc.
Reduces overhead since all protocols not handled by default.
Protocol to use will be enabled when keycode table is written by userspace.
Signed-off-by: Tomas Melin tomas.me...@iki.fi
---
drivers/media/rc/rc-ir-raw.c |1 -
drivers/media/rc/rc-main.c |6 --
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
index a118539..d3b1e76 100644
--- a/drivers/media/rc/rc-ir-raw.c
+++ b/drivers/media/rc/rc-ir-raw.c
@@ -256,7 +256,6 @@ int ir_raw_event_register(struct rc_dev *dev)
return -ENOMEM;
dev-raw-dev = dev;
- dev-enabled_protocols = ~0;
rc = kfifo_alloc(dev-raw-kfifo,
sizeof(struct ir_raw_event) * MAX_IR_EVENT_SIZE,
GFP_KERNEL);
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 633c682..dcdf4cd 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1320,6 +1320,8 @@ int rc_register_device(struct rc_dev *dev)
rc_map = rc_map_get(RC_MAP_EMPTY);
if (!rc_map || !rc_map-scan || rc_map-size == 0)
return -EINVAL;
+ /* get default keymap type */
+ u64 rc_type = (1 rc_map-rc_type);
set_bit(EV_KEY, dev-input_dev-evbit);
set_bit(EV_REP, dev-input_dev-evbit);
@@ -1412,16 +1414,16 @@ int rc_register_device(struct rc_dev *dev)
raw_init = true;
}
rc = ir_raw_event_register(dev);
+ dev-enabled_protocols = (rc_type | RC_BIT_LIRC);
if (rc 0)
goto out_input;
}
if (dev-change_protocol) {
- u64 rc_type = (1 rc_map-rc_type);
rc = dev-change_protocol(dev, rc_type);
if (rc 0)
goto out_raw;
- dev-enabled_protocols = rc_type;
+ dev-enabled_protocols = (rc_type | RC_BIT_LIRC);
}
mutex_unlock(dev-lock);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Chrity Code: MP389
$1 Million USD. Has been donated to you kindly contact the donator Mr. Harry Black via personal email ( harryblac...@rogers.commailto:harryblac...@rogers.com ) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] DVBSky V3 PCIe card: add some changes to M88DS3103 for supporting the demod of M88RS6000
On 10/13/2014 09:44 AM, Nibble Max wrote:
M88RS6000 is the integrated chip, which includes tuner and demod.
Its internal demod is similar with M88DS3103 except some registers definition.
The main different part of this internal demod from others is its clock/pll
generation IP block sitting inside the tuner die.
So clock/pll functions should be configed through its tuner i2c bus, NOT its
demod i2c bus.
The demod of M88RS6000 need the firmware: dvb-demod-m88rs6000.fw
firmware download link:
http://www.dvbsky.net/download/linux/dvbsky-firmware.tar.gz
@@ -250,6 +251,7 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
u16 u16tmp, divide_ratio;
u32 tuner_frequency, target_mclk;
s32 s32tmp;
+ struct m88rs6000_mclk_config mclk_cfg;
dev_dbg(priv-i2c-dev,
%s: delivery_system=%d modulation=%d frequency=%d
symbol_rate=%d inversion=%d pilot=%d rolloff=%d\n,
@@ -291,6 +293,26 @@ static int m88ds3103_set_frontend(struct dvb_frontend *fe)
if (ret)
goto err;
+ if (priv-chip_id == M88RS6000_CHIP_ID) {
+ ret = m88ds3103_wr_reg(priv, 0x06, 0xe0);
+ if (ret)
+ goto err;
+ if (fe-ops.tuner_ops.set_config) {
+ /* select main mclk */
+ mclk_cfg.config_op = 0;
+ mclk_cfg.TunerfreqMHz = c-frequency / 1000;
+ mclk_cfg.SymRateKSs = c-symbol_rate / 1000;
+ ret = fe-ops.tuner_ops.set_config(fe, mclk_cfg);
+ if (ret)
+ goto err;
+ priv-mclk_khz = mclk_cfg.MclkKHz;
+ }
+ ret = m88ds3103_wr_reg(priv, 0x06, 0x00);
+ if (ret)
+ goto err;
+ usleep_range(1, 2);
+ }
That looks odd and also ugly. You pass some values from demod to tuner
using set_config callback. Tuner driver can get symbol_rate and
frequency just similarly from property cache than demod. Why you do it
like that?
Clock is provided by tuner as you mention. I see you use that to pass
used clock frequency from tuner to demod. This does not look nice and I
would like to see clock framework instead. Or calculate clock on both
drivers. Does the demod clock even needs to be changed? I think it is
only TS stream size which defines used clock frequency - smaller the TS
bitstream, the smaller the clock frequency needed = optimizes power
consumption a little. But TS clock is calculated on tuner driver in any
case?
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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: Wed Oct 22 04:00:29 CEST 2014 git branch: test git hash: 1ef24960ab78554fe7e8e77d8fc86524fbd60d3c gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-20-g7abd8a7 host hardware: x86_64 host os:3.17-0.slh.1-amd64 linux-git-arm-at91: ERRORS linux-git-arm-davinci: ERRORS linux-git-arm-exynos: ERRORS linux-git-arm-mx: ERRORS linux-git-arm-omap: ERRORS linux-git-arm-omap1: ERRORS linux-git-arm-pxa: ERRORS linux-git-blackfin: ERRORS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: ERRORS linux-git-powerpc64: OK linux-git-sh: ERRORS linux-git-x86_64: OK linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: WARNINGS linux-3.11.1-i686: WARNINGS linux-3.12.23-i686: WARNINGS linux-3.13.11-i686: WARNINGS linux-3.14.9-i686: WARNINGS linux-3.15.2-i686: WARNINGS linux-3.16-i686: WARNINGS linux-3.17-i686: OK linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: WARNINGS linux-3.11.1-x86_64: WARNINGS linux-3.12.23-x86_64: WARNINGS linux-3.13.11-x86_64: WARNINGS linux-3.14.9-x86_64: WARNINGS linux-3.15.2-x86_64: WARNINGS linux-3.16-x86_64: WARNINGS linux-3.17-x86_64: WARNINGS apps: OK spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: soc_camera: rcar_vin: Enable VSYNC field toggle mode
Hi Geert-san,
2014-10-21 16:09 GMT+09:00 Geert Uytterhoeven ge...@linux-m68k.org:
Hi Kaneko-san,
On Tue, Oct 21, 2014 at 5:30 AM, Yoshihiro Kaneko ykaneko0...@gmail.com
wrote:
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -108,6 +108,7 @@
#define VNDMR2_VPS(1 30)
#define VNDMR2_HPS(1 29)
#define VNDMR2_FTEV (1 17)
+#define VNDMR2_VLV_1 (1 12)
Please instead do:
#define VNDMR2_VLV(n) ((n 0xf) 12)
It's unclear to me why the style of the new #define should differ
from those of the existing ones.
I think Sergey wants to say that unlike for the other fields, there are
multiple possible values for the VLV field.
By providing the single macro definition
#define VNDMR2_VLV(n) ((n 0xf) 12)
you can easily provide a way to set any of VNDMR2_VLV_n.
I hope this explanation makes it clearer.
Thank you for the clarification!
I'll update this patch sooner.
Thanks,
Kaneko
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like
that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] media: soc_camera: rcar_vin: Enable VSYNC field toggle mode
From: Koji Matsuoka koji.matsuoka...@renesas.com By applying this patch, it sets to VSYNC field toggle mode not only at the time of progressive mode but at the time of an interlace mode. Signed-off-by: Koji Matsuoka koji.matsuoka...@renesas.com Signed-off-by: Yoshihiro Kaneko ykaneko0...@gmail.com --- This patch is against master branch of linuxtv.org/media_tree.git. v2 [Yoshihiro Kaneko] * improve the macro definition for the VLV field drivers/media/platform/soc_camera/rcar_vin.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/soc_camera/rcar_vin.c b/drivers/media/platform/soc_camera/rcar_vin.c index 9300076..beaf8e5 100644 --- a/drivers/media/platform/soc_camera/rcar_vin.c +++ b/drivers/media/platform/soc_camera/rcar_vin.c @@ -107,6 +107,7 @@ #define VNDMR2_VPS (1 30) #define VNDMR2_HPS (1 29) #define VNDMR2_FTEV(1 17) +#define VNDMR2_VLV(n) ((n 0xf) 12) #define VIN_MAX_WIDTH 2048 #define VIN_MAX_HEIGHT 2048 @@ -827,7 +828,7 @@ static int rcar_vin_set_bus_param(struct soc_camera_device *icd) if (ret 0 ret != -ENOIOCTLCMD) return ret; - val = priv-field == V4L2_FIELD_NONE ? VNDMR2_FTEV : 0; + val = VNDMR2_FTEV | VNDMR2_VLV(1); if (!(common_flags V4L2_MBUS_VSYNC_ACTIVE_LOW)) val |= VNDMR2_VPS; if (!(common_flags V4L2_MBUS_HSYNC_ACTIVE_LOW)) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: [PATCH 3/3] DVBSky V3 PCIe card: add some changes to M88DS3103for supporting the demod of M88RS6000
On 10/13/2014 09:44 AM, Nibble Max wrote:
M88RS6000 is the integrated chip, which includes tuner and demod.
Its internal demod is similar with M88DS3103 except some registers
definition.
The main different part of this internal demod from others is its clock/pll
generation IP block sitting inside the tuner die.
So clock/pll functions should be configed through its tuner i2c bus, NOT its
demod i2c bus.
The demod of M88RS6000 need the firmware: dvb-demod-m88rs6000.fw
firmware download link:
http://www.dvbsky.net/download/linux/dvbsky-firmware.tar.gz
@@ -250,6 +251,7 @@ static int m88ds3103_set_frontend(struct dvb_frontend
*fe)
u16 u16tmp, divide_ratio;
u32 tuner_frequency, target_mclk;
s32 s32tmp;
+struct m88rs6000_mclk_config mclk_cfg;
dev_dbg(priv-i2c-dev,
%s: delivery_system=%d modulation=%d frequency=%d
symbol_rate=%d inversion=%d pilot=%d rolloff=%d\n,
@@ -291,6 +293,26 @@ static int m88ds3103_set_frontend(struct dvb_frontend
*fe)
if (ret)
goto err;
+if (priv-chip_id == M88RS6000_CHIP_ID) {
+ret = m88ds3103_wr_reg(priv, 0x06, 0xe0);
+if (ret)
+goto err;
+if (fe-ops.tuner_ops.set_config) {
+/* select main mclk */
+mclk_cfg.config_op = 0;
+mclk_cfg.TunerfreqMHz = c-frequency / 1000;
+mclk_cfg.SymRateKSs = c-symbol_rate / 1000;
+ret = fe-ops.tuner_ops.set_config(fe, mclk_cfg);
+if (ret)
+goto err;
+priv-mclk_khz = mclk_cfg.MclkKHz;
+}
+ret = m88ds3103_wr_reg(priv, 0x06, 0x00);
+if (ret)
+goto err;
+usleep_range(1, 2);
+}
That looks odd and also ugly. You pass some values from demod to tuner
using set_config callback. Tuner driver can get symbol_rate and
frequency just similarly from property cache than demod. Why you do it
like that?
Clock is provided by tuner as you mention. I see you use that to pass
used clock frequency from tuner to demod. This does not look nice and I
would like to see clock framework instead. Or calculate clock on both
drivers. Does the demod clock even needs to be changed? I think it is
only TS stream size which defines used clock frequency - smaller the TS
bitstream, the smaller the clock frequency needed = optimizes power
consumption a little. But TS clock is calculated on tuner driver in any
case?
Yes, M88RS6000 looks odd. This integrated chip has two part die, tuner die and
demod die.
Its demod's clock(PLL) block is sitting insided the tuner die. The demod has no
PLL ip block that makes demod die smaller.
The demod's clock can be adjusted according to the transponder's frequency and
symbol rate.
So that the demod's clock and its harmonic frequency will not overlap with the
transponder's frequency range.
It will improve its tuner's sensitivity.
However the tuner driver can get the values from property cache.
Tuner driver does not know when need adjust this demod pll
and return the current demod pll value to the demod driver.
in struct dvb_tuner_ops, there is no call back to do this directly.
So I select the general set_config call back.
TS main clock of demdod also need to be controlled in the tuner die.
These demod's PLL registers have no relationship with tuner at all.
Logically, These demod's PLL registers should go with demod die as usual.
But in this case they goes with the tuner die physically and controlled through
tuner i2c bus.
The current dvb-frontend driver requires the tuner and demod to split into the
seperate drivers.
The demod driver will not access tuner i2c bus directly.
But this integrate chip has more tighter relationship of its tuner and demod
die.
That is reason why these odd call backs happen.
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
