[PATCH 1/2 v3] media: Add mem2mem deinterlacing driver.
Some video decoders such as tvp5150 provide separate
video fields (V4L2_FIELD_SEQ_TB/BT). This driver uses
dmaengine to convert this format to V4L2_FIELD_INTERLACED_TB/BT
(weaving) or V4L2_FIELD_NONE (line doubling) so that the
image can be displayed or processed.
Of course there will be combing effect in the image but this
can be accepted for some low quality applications.
Currently only YUV420 and YUYV formats are supported but
it can be extended later.
Signed-off-by: Javier Martin
---
Changes since v2:
- Passes all v4l2-compliance tests.
- Field conversion is now properly documented.
- Behavior of try_fmt and set_fmt is fixed.
---
drivers/media/video/Kconfig |8 +
drivers/media/video/Makefile |2 +
drivers/media/video/m2m-deinterlace.c | 1119 +
3 files changed, 1129 insertions(+)
create mode 100644 drivers/media/video/m2m-deinterlace.c
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 9cebf7b..c0b9233 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -1188,6 +1188,14 @@ config VIDEO_CODA
Coda is a range of video codec IPs that supports
H.264, MPEG-4, and other video formats.
+config VIDEO_MEM2MEM_DEINTERLACE
+ tristate "Deinterlace support"
+ depends on VIDEO_DEV && VIDEO_V4L2 && DMA_ENGINE
+ select VIDEOBUF2_DMA_CONTIG
+ select V4L2_MEM2MEM_DEV
+ help
+ Generic deinterlacing V4L2 driver.
+
config VIDEO_SAMSUNG_S5P_G2D
tristate "Samsung S5P and EXYNOS4 G2D 2d graphics accelerator driver"
depends on VIDEO_DEV && VIDEO_V4L2 && PLAT_S5P
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index a04c307..b6a01b1 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -189,6 +189,8 @@ obj-$(CONFIG_VIDEO_ATMEL_ISI) += atmel-isi.o
obj-$(CONFIG_VIDEO_MX2_EMMAPRP)+= mx2_emmaprp.o
obj-$(CONFIG_VIDEO_CODA) += coda.o
+obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)+= m2m-deinterlace.o
+
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_FIMC) += s5p-fimc/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG) += s5p-jpeg/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC)+= s5p-mfc/
diff --git a/drivers/media/video/m2m-deinterlace.c
b/drivers/media/video/m2m-deinterlace.c
new file mode 100644
index 000..1107167
--- /dev/null
+++ b/drivers/media/video/m2m-deinterlace.c
@@ -0,0 +1,1119 @@
+/*
+ * V4L2 deinterlacing support.
+ *
+ * Copyright (c) 2012 Vista Silicon S.L.
+ * Javier Martin
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#define MEM2MEM_TEST_MODULE_NAME "mem2mem-deinterlace"
+
+MODULE_DESCRIPTION("mem2mem device which supports deinterlacing using
dmaengine");
+MODULE_AUTHOR("Javier Martin v4l2_dev, "%s: " fmt, __func__, ## arg)
+
+struct deinterlace_fmt {
+ char*name;
+ u32 fourcc;
+ /* Types the format can be used for */
+ u32 types;
+};
+
+static struct deinterlace_fmt formats[] = {
+ {
+ .name = "YUV 4:2:0 Planar",
+ .fourcc = V4L2_PIX_FMT_YUV420,
+ .types = MEM2MEM_CAPTURE | MEM2MEM_OUTPUT,
+ },
+ {
+ .name = "YUYV 4:2:2",
+ .fourcc = V4L2_PIX_FMT_YUYV,
+ .types = MEM2MEM_CAPTURE | MEM2MEM_OUTPUT,
+ },
+};
+
+#define NUM_FORMATS ARRAY_SIZE(formats)
+
+/* Per-queue, driver-specific private data */
+struct deinterlace_q_data {
+ unsigned intwidth;
+ unsigned intheight;
+ unsigned intsizeimage;
+ struct deinterlace_fmt *fmt;
+ enum v4l2_field field;
+};
+
+enum {
+ V4L2_M2M_SRC = 0,
+ V4L2_M2M_DST = 1,
+};
+
+enum {
+ YUV420_DMA_Y_ODD,
+ YUV420_DMA_Y_EVEN,
+ YUV420_DMA_U_ODD,
+ YUV420_DMA_U_EVEN,
+ YUV420_DMA_V_ODD,
+ YUV420_DMA_V_EVEN,
+ YUV420_DMA_Y_ODD_DOUBLING,
+ YUV420_DMA_U_ODD_DOUBLING,
+ YUV420_DMA_V_ODD_DOUBLING,
+ YUYV_DMA_ODD,
+ YUYV_DMA_EVEN,
+ YUYV_DMA_EVEN_DOUBLING,
+};
+
+/* Source and destination queue data */
+static struct deinterlace_q_data q_data[2];
+
+static struct deinterlace_q_data *get_q_data(enum v4l2_buf_type type)
+{
+ switch (type) {
+ case V4L2_BUF_TYPE_VIDEO_OUTPUT:
+ return &q_data[V4L2_M2M_SRC];
+ case V4L2_BUF_TYPE_VIDEO_CAPTURE:
+ return &q_data[V4L2_M2M_DST];
+ default:
+ BUG();
+ }
+ return NULL;
+}
+
+static struct deinterlace_fmt *find_format(struct v4l2_format *f)
+{
+ struct deinterlace_fmt *fmt;
Re: Supporting 3D formats in V4L2
Hi Hans Thanks for your comments. Best Regards Soby Mathew On Mon, Jul 23, 2012 at 6:14 PM, Hans Verkuil wrote: > On Mon July 23 2012 14:35:14 Soby Mathew wrote: >> Hi Hans, >> Thanks for the reply and I was going through the HDMI1.4 spec again. >> The 'active space' is part of the Vactive and Vactive is sum of active >> video and active space. >> >> > No, as I understand it active_space is just part of the active video. So >> > the >> > timings struct is fine, it's just that the height parameter for e.g. 720p >> > in >> > frame pack format is 2*720 + vfrontporch + vsync + vbackporch. That's the >> > height >> > of the frame that will have to be DMAed from/to the receiver/transmitter. >> >> In this case (assuming frame packed) the total height should be 2*720 >> + 30 + vfrontporch + vsync + vbackporch. >> >> Sorry, but if I am understanding you correct, in case of 3D frame >> packed format, the height field can be 'active video + active space'. > > Right. > >> So the application need to treat the buffers appropriately according >> to the 3D format detected. Would this be a good solution? > > Right. So the application will need to obtain the timings somehow (either from > v4l2-dv-timings.h, or from VIDIOC_G/QUERY_DV_TIMINGS) so it knows how to > interpret the captured data and how large the buffer size has to be in the > first > place. > > I think it will all work out, but you would have to actually implement it to > be > sure I haven't forgotten anything. > > Frankly, I'd say that the frame_packed format is something you want to avoid > :-) > It's pretty weird. > > Regards, > > Hans > >> >> >> > I think the only thing that needs to be done is that the appropriate >> > timings are >> > added to linux/v4l2-dv-timings.h. >> >> Yes , the standard 3 D timings need to be added to this file which can >> be taken up. >> >> > Regards, >> > >> > Hans >> > >> >> >> Best Regards >> Soby Mathew >> -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] kthread_worker: reimplement flush_kthread_work() to allow freeing the work item being executed
On Mon, 2012-07-23 at 10:12 -0700, Tejun Heo wrote: > Hello, > > On Sun, Jul 22, 2012 at 04:46:54PM -0400, Andy Walls wrote: > > Hmmm, I didn't know about the constraint about 'known to be alive' in > > the other email I just sent. > > > > That might make calling flush_kthread_work() hard for a user to use, if > > the user lets the work get freed by another thread executing the work. > > Umm... flushing a freed work item doesn't make any sense at all. The > pointer itself loses the ability to identify anything. What if it > gets recycled to another work item which happens to depend on the > flusher to make forward progress? You now have a circular dependency > through a recycled memory area. Good luck hunting that down. > > For pretty much any API, allowing dangling pointers as argument is > insane. If you want to flush self-freeing work items, flush the > kthread_worker. That's how it is with workqueue and how it should be > with kthread_worker too. Hi, Ah. My problem was that I mentally assigned the wrong rationale for why you reworked flush_kthread_work(). Thank you for your patience and explanations. Sorry for the noise. For patch 2/2: Reviewed-by: Andy Walls Regards, Andy -- 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 1/2] V4L: Add capability flags for memory-to-memory devices
> From: Sylwester Nawrocki [mailto:sylvester.nawro...@gmail.com] > Sent: 30 June 2012 21:24 > > This patch adds new V4L2_CAP_VIDEO_M2M and V4L2_CAP_VIDEO_M2M_MPLANE > capability > flags that are intended to be used for memory-to-memory (M2M) devices, > instead > of ORed V4L2_CAP_VIDEO_CAPTURE and V4L2_CAP_VIDEO_OUTPUT. > > V4L2_CAP_VIDEO_M2M flag is added at the drivers, CAPTURE and OUTPUT > capability > flags are left untouched and will be removed in future, after a > transition > period required for existing applications to be adapted to check only for > V4L2_CAP_VIDEO_M2M. > > Signed-off-by: Sylwester Nawrocki For s5p-mfc and g2d: Acked-by: Kamil Debski -- 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, RESEND] ov9640: fix missing break
From: Alan Cox Without this rev2 ends up behaving as rev3 Reported-by: dcb...@hotmail.com Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=44081 Signed-off-by: Alan Cox --- drivers/media/video/ov9640.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/video/ov9640.c b/drivers/media/video/ov9640.c index 23412de..9ed4ba4 100644 --- a/drivers/media/video/ov9640.c +++ b/drivers/media/video/ov9640.c @@ -605,6 +605,7 @@ static int ov9640_video_probe(struct i2c_client *client) devname = "ov9640"; priv->model = V4L2_IDENT_OV9640; priv->revision = 2; + break; case OV9640_V3: devname = "ov9640"; priv->model = V4L2_IDENT_OV9640; -- 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, RESEND] cx25821,medusa: incorrect check on decoder type
From: Alan Cox
Unsupported requests should be ignored but in fact affected VDEC_A
Reported-by: dcb...@hotmail.com
Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=44051
Signed-off-by: Alan Cox
---
drivers/media/video/cx25821/cx25821-medusa-video.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/video/cx25821/cx25821-medusa-video.c
b/drivers/media/video/cx25821/cx25821-medusa-video.c
index 313fb20..6a92e5c 100644
--- a/drivers/media/video/cx25821/cx25821-medusa-video.c
+++ b/drivers/media/video/cx25821/cx25821-medusa-video.c
@@ -499,7 +499,7 @@ static void medusa_set_decoderduration(struct cx25821_dev
*dev, int decoder,
mutex_lock(&dev->lock);
/* no support */
- if (decoder < VDEC_A && decoder > VDEC_H) {
+ if (decoder < VDEC_A || decoder > VDEC_H) {
mutex_unlock(&dev->lock);
return;
}
--
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, RESEND] az6007: fix incorrect memcpy
From: Alan Cox
Some parts of the C language are subtle and evil. This is one example.
Reported-by: dcb...@hotmail.com
Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=44041
Signed-off-by: Alan Cox
---
drivers/media/dvb/dvb-usb/az6007.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/dvb/dvb-usb/az6007.c
b/drivers/media/dvb/dvb-usb/az6007.c
index 8ffcad0..86861e6 100644
--- a/drivers/media/dvb/dvb-usb/az6007.c
+++ b/drivers/media/dvb/dvb-usb/az6007.c
@@ -590,7 +590,7 @@ static int az6007_read_mac_addr(struct dvb_usb_device *d,
u8 mac[6])
int ret;
ret = az6007_read(d, AZ6007_READ_DATA, 6, 0, st->data, 6);
- memcpy(mac, st->data, sizeof(mac));
+ memcpy(mac, st->data, 6);
if (ret > 0)
deb_info("%s: mac is %pM\n", __func__, mac);
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] drivers/staging/media/easycap/easycap_main.c: add missing usb_free_urb
From: Julia Lawall
Add missing usb_free_urb on failure path after usb_alloc_urb.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@km exists@
local idexpression e;
expression e1,e2,e3;
type T,T1;
identifier f;
@@
* e = usb_alloc_urb(...)
... when any
when != e = e1
when != e1 = (T)e
when != e1(...,(T)e,...)
when != &e->f
if(...) { ... when != e2(...,(T1)e,...)
when != e3 = e
when forall
(
return <+...e...+>;
|
* return ...;
) }
//
Signed-off-by: Julia Lawall
---
drivers/staging/media/easycap/easycap_main.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/media/easycap/easycap_main.c
b/drivers/staging/media/easycap/easycap_main.c
index a1c45e4..8269c77 100644
--- a/drivers/staging/media/easycap/easycap_main.c
+++ b/drivers/staging/media/easycap/easycap_main.c
@@ -3083,6 +3083,7 @@ static int create_video_urbs(struct easycap *peasycap)
peasycap->allocation_video_urb += 1;
pdata_urb = kzalloc(sizeof(struct data_urb), GFP_KERNEL);
if (!pdata_urb) {
+ usb_free_urb(purb);
SAM("ERROR: Could not allocate struct data_urb.\n");
return -ENOMEM;
}
--
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] cx25821: Remove bad strcpy to read-only char*
Hey Hans, On Thu, Jul 19, 2012 at 10:41 AM, Hans Verkuil wrote: > On Thu 19 July 2012 15:32:21 Ezequiel Garcia wrote: >> On Thu, Jul 19, 2012 at 8:17 AM, Hans Verkuil wrote: >> > Ezequiel, >> > >> > Can you post this patch again, but this time to Linus Torvalds as well? >> > >> > See e.g. http://www.spinics.net/lists/linux-media/msg50407.html how I did >> > that. >> > >> > It would be good to have this fixed in 3.5. I'm afraid that by the time >> > Mauro is back 3.5 will be released and this is a nasty bug. >> > >> >> Okey, I'll do that. Shouldn't this go to stable also? > > Definitely, but it have to be upstreamed first before it can go to stable. > I was just reading through Documentation/stable_kernel_rules.txt and I found this: "Procedure for submitting patches to the -stable tree: [snip] - To have the patch automatically included in the stable tree, add the tag Cc: sta...@vger.kernel.org in the sign-off area. Once the patch is merged it will be applied to the stable tree without anything else needing to be done by the author or subsystem maintainer." So, it was sufficient to Cc this patch to stable and Greg would queued it automatically when Linus' merges it. This is also here: http://www.kroah.com/log/linux/stable-status-01-2012.html Just wanted you to know this (if you don't already). Ezequiel. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH for stable] cx25821: Remove bad strcpy to read-only char*
Hi Greg,
This patch is already in Linus' tree and I really think it should go into stable
as well. You will find this bug in every kernel from the moment cx25821 went
out of staging.
I just read Documentation/stable_kernel_rules.txt, so I guess it was enough
to add a tag "Cc: sta...@vger.kernel.org" in the patch (right?).
Now I know it :-)
If I'm doing anything wrong, just yell at me.
Thanks,
Ezequiel.
>From 1859521e76226687e79e1452b040fd3e02c469d8 Mon Sep 17 00:00:00 2001
From: Ezequiel Garcia
Date: Wed, 18 Jul 2012 10:05:26 -0300
Subject: [PATCH] cx25821: Remove bad strcpy to read-only char*
The strcpy was being used to set the name of the board.
Since the destination char* was read-only and the name
is set statically at compile time; this was both
wrong and redundant.
The type of char* is changed to const char* to prevent
future errors.
Reported-by: Radek Masin
Signed-off-by: Ezequiel Garcia
---
drivers/media/video/cx25821/cx25821-core.c |3 ---
drivers/media/video/cx25821/cx25821.h |2 +-
2 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/cx25821/cx25821-core.c
b/drivers/media/video/cx25821/cx25821-core.c
index 7930ca5..235bf7d 100644
--- a/drivers/media/video/cx25821/cx25821-core.c
+++ b/drivers/media/video/cx25821/cx25821-core.c
@@ -912,9 +912,6 @@ static int cx25821_dev_setup(struct cx25821_dev *dev)
list_add_tail(&dev->devlist, &cx25821_devlist);
mutex_unlock(&cx25821_devlist_mutex);
- strcpy(cx25821_boards[UNKNOWN_BOARD].name, "unknown");
- strcpy(cx25821_boards[CX25821_BOARD].name, "cx25821");
-
if (dev->pci->device != 0x8210) {
pr_info("%s(): Exiting. Incorrect Hardware device = 0x%02x\n",
__func__, dev->pci->device);
diff --git a/drivers/media/video/cx25821/cx25821.h
b/drivers/media/video/cx25821/cx25821.h
index b9aa801..029f293 100644
--- a/drivers/media/video/cx25821/cx25821.h
+++ b/drivers/media/video/cx25821/cx25821.h
@@ -187,7 +187,7 @@ enum port {
};
struct cx25821_board {
- char *name;
+ const char *name;
enum port porta;
enum port portb;
enum port portc;
--
1.7.8.6
--
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: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
Apologies for my late reply -- I plan to attend the conference!!! I am looking to book everything today... I think I'm going to Barcelona as well -- will you guys go to both conferences? On Sat, Jul 21, 2012 at 1:06 AM, Guennadi Liakhovetski wrote: > Hi Mauro > > On Tue, 17 Jul 2012, Guennadi Liakhovetski wrote: > >> Hi Mauro >> >> On Tue, 17 Jul 2012, Mauro Carvalho Chehab wrote: >> >> > As we did in 2012, we're planning to do a media summit again at KS/2012. >> > >> > The KS/2012 will happen in San Diego, CA, US, between Aug 26-28, just >> > before the LinuxCon North America. >> > >> > In order to do it, I'd like to know who is interested on participate, >> > and to get proposals about what subjects will be discussed there, >> > in order to start planning the agenda. >> >> I'd love to attend, especially since, as you have seen, I've started doing >> some work on V4L DT bindings, but so far it very much looks like I won't >> be able to do so unfortunately. > > Things change and sometimes also to the better:-) Looks like I'll be able > to attend actually. So, please add me to the list. > > Thanks > Guennadi > >> > Thanks! >> > Mauro >> > >> > Mensagem original >> > Assunto: Re: [Ksummit-2012-discuss] Organising Mini Summits within the >> > Kernel Summit >> > Data: Fri, 13 Jul 2012 13:37:08 -0400 >> > De: Theodore Ts'o >> > Para: James Bottomley >> > CC: ksummit-2012-disc...@lists.linux-foundation.org, linux-kernel >> > >> > >> > On Wed, Jul 11, 2012 at 09:09:15AM +0100, James Bottomley wrote: >> > > Hi All, >> > > >> > > We have set aside the second day of the kernel summit (Tuesday 28 >> > > August) as mini-summit day. So far we have only the PCI mini summit on >> > > this day, so if you can think of other topics, please send them to the >> > > kernel summit discuss list: >> > > >> > > ksummit-2012-disc...@lists.linux-foundation.org >> > > >> > > Looking at the available rooms, we think we can run about four or five >> > > mini summits. >> > > >> > > As an added incentive, mini summit organisers get to pick who they >> > > invite and all the people they pick will get an automatic invitation to >> > > the third day of the kernel summit (but not the core first day) and the >> > > evening events. >> > >> > OK, so far I believe I've heard concrete suggestions from identified >> > (or fairly well identified :-) stuckees willing to organize >> > mini-summits for: >> > >> > * ARM >> > * Media >> > * PCI >> > * memcg >> > >> > I may have missed some, so if people could send a message to the >> > discuss list with [MINI-SUMMIT] in the subbject line and the name of >> > the proposed mini-summit, that would be really helpful. Please >> > indicate whether you are volunteering to help organize the proposed >> > mini-summit, or identify someone you think can be volunteered. :-) >> > >> > Things that we will be asking the mini-summit chars to determine, in >> > addition to who should be given invites for Tuesday and Wednesday is >> > an estimate of how much time you need, and a list of sub-topics (and >> > who might lead the sub-topic discussion). We will be asking you to >> > create a fairly well-defined schedule, with 30 and 60 minute slots, so >> > that we can publish a schedule and so that people who might need to >> > hop between mini-summits, have a chance to do so. So please start >> > thinking about how long each of your sub-topics will need to be, and >> > who might be needed for a particular sub-topic's discussion to be >> > successful. There may be a number of developers, with fingers in >> > multiple subsystem, where scheduling may become a bit of a challenge. >> > >> > Thanks!! >> > >> > - Ted >> > ___ >> > Ksummit-2012-discuss mailing list >> > ksummit-2012-disc...@lists.linux-foundation.org >> > https://lists.linux-foundation.org/mailman/listinfo/ksummit-2012-discuss >> > >> > >> > >> > ___ >> > Workshop-2011 mailing list >> > workshop-2...@linuxtv.org >> > http://www.linuxtv.org/cgi-bin/mailman/listinfo/workshop-2011 >> > >> >> --- >> Guennadi Liakhovetski, Ph.D. >> Freelance Open-Source Software Developer >> http://www.open-technology.de/ >> >> ___ >> Workshop-2011 mailing list >> workshop-2...@linuxtv.org >> http://www.linuxtv.org/cgi-bin/mailman/listinfo/workshop-2011 >> > > --- > Guennadi Liakhovetski, Ph.D. > Freelance Open-Source Software Developer > http://www.open-technology.de/ > > ___ > Workshop-2011 mailing list > workshop-2...@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/workshop-2011 -- 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:Tue Jul 24 19:00:23 CEST 2012 git hash:931efdf58bd83af8d0578a6cc53421675daf6d41 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: ERRORS linux-git-arm-eabi-exynos: OK linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L-DVB specification 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: Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
Hello, Le mardi 17 juillet 2012 20:30:53 Mauro Carvalho Chehab, vous avez écrit : > As we did in 2012, we're planning to do a media summit again at KS/2012. > > The KS/2012 will happen in San Diego, CA, US, between Aug 26-28, just > before the LinuxCon North America. > > In order to do it, I'd like to know who is interested on participate, > and to get proposals about what subjects will be discussed there, > in order to start planning the agenda. If it's of interest to anyone, I could probably present a bunch of issues with V4L2 and DVB from userspace perspective. Regards, -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- 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 summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
On Tue, Jul 24, 2012 at 4:05 PM, Rémi Denis-Courmont wrote: > If it's of interest to anyone, I could probably present a bunch of issues with > V4L2 and DVB from userspace perspective. Remi, I would strongly be in favor of this. One thing that we get far to little of is feedback from actual userland developers making use of the V4L and DVB interfaces (aside from the SoC vendors, which is a completely different target audience than the traditional V4L and DVB consumers) 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: Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
Devin Heitmueller wrote: >On Tue, Jul 24, 2012 at 4:05 PM, Rémi Denis-Courmont >wrote: >> If it's of interest to anyone, I could probably present a bunch of >issues with >> V4L2 and DVB from userspace perspective. > >Remi, > >I would strongly be in favor of this. One thing that we get far to >little of is feedback from actual userland developers making use of >the V4L and DVB interfaces (aside from the SoC vendors, which is a >completely different target audience than the traditional V4L and DVB >consumers) > >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 Ditto. Input from user application developers is something that kernel developers need and value greatly. Note, that I will not be at the workshop of Plumbers this year. :( Regards, Andy -- 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 summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
Le mardi 24 juillet 2012 23:31:42 Andy Walls, vous avez écrit : > >I would strongly be in favor of this. One thing that we get far to > >little of is feedback from actual userland developers making use of > >the V4L and DVB interfaces (aside from the SoC vendors, which is a > >completely different target audience than the traditional V4L and DVB > >consumers) > > > >Devin > > Ditto. Input from user application developers is something that kernel > developers need and value greatly. > > Note, that I will not be at the workshop of Plumbers this year. :( Is the media summit timed with LPC or the kernel summit? If I come, I have to leave on Thursday to catch the VideoLAN conference in Paris on the next week- end... -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- 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/2] v4l: Add factory register values form S5K4ECGX sensor
Hi Sangwook,
On 07/20/2012 12:03 PM, Sangwook Lee wrote:
> Hi Sylwester
>
> Thank for the review.
>
> On 19 July 2012 20:40, Sylwester Nawrocki
> wrote:
>> On 07/19/2012 02:14 PM, Sangwook Lee wrote:
...
>>> Add factory default settings for S5K4ECGX sensor registers.
>>> I copied them from the reference code of Samsung S.LSI.
>>
>> I'm pretty sure we can do better than that. I've started S5K6AAFX sensor
>> driver development with similar set of write-only register address/value
>> arrays, that stored mainly register default values after the device reset,
>> or were configuring presets that were never used.
>>
>> If you lok at the s5k6aa driver, you'll find only one relatively small
>> array of register values for the analog processing block settings.
>> It's true that I had to reverse engineer a couple of things, but I also
>>
>> had a relatively good datasheet for the sensor.
>>
>
> Yes, I already saw analog settings in s5k6aa. Compared to s5k6aa,
> I couldn't also understand why the sensor has lots of initial values.
> Is it because s5k4ecgx is slightly more complicated than s5k6aa ?
IIRC, original S5K6AAFX driver had similar number of initial values that
were being written during initialization through I2C bus. But that's true
the s5k4ecgx is more complex, it has more still capture features built in.
>>> According to comments from the reference code, they do not
>>> recommend any changes of these settings.
>>
>> Yes, but it doesn't mean cannot convert, at least part of, those ugly
>> tables into function calls.
>
>
> Yes, the biggest table seems to be one time for boot-up, at least I need to
> remove one more macro (token)
That would be a good start. Also 2 most significant bytes of register
addresses seem redundant, you'll find there mostly 0xD000 and 0x7000.
Dropping the token and 2 MS address bytes would decrease the single entry
size from 10 to 4 bytes. Given that there is about 3000 table entries
the driver's code size would decrease by 18 kB.
BTW, you didn't make those arrays "const", so it's all copied to RAM
during initialization...
>>
>> Have you tried to contact Samsung S.LSI for a datasheet that would
>> contain better registers' description ?
>
>
> As you might know, there is a limitation for me to get those information. :-)
I find it odd, given that you guys work on software support for one of
official Exynos4 reference platforms. It's really surprising.
Maybe you should just contact the right persons ?
> Instead, if I look into the source code of Google Nexus S which uses s5k4ecgx,
>
>https://android.googlesource.com/kernel/samsung.git
>
> I can discover that both Google and Samsung are using the same huge table
> just for initial settings from the sensor booting-up. I added the
> original author
> of this sensor driver. Hopes he might add some comments :-)
Yeah, that would be great.
I think, this pattern of using register/value arrays is good for quick
development of drivers for many different sensors - you just switch the
tables and everything else mostly stays the same. However, V4L2 mainline
standards are a bit different. It would be good to convert as many of
those arrays to functions calls as possible.
Also using vmalloc is an overkill IMO. I suspect you could use this
function (with minimal adaptations):
8<---
static int s5k6aa_write_array(struct v4l2_subdev *sd,
const struct s5k6aa_regval *msg)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
u16 addr_incr = 0;
int ret = 0;
while (msg->addr != S5K6AA_TERM) {
if (addr_incr != 2)
ret = s5k6aa_i2c_write(client, REG_CMDWR_ADDRL,
msg->addr);
if (ret)
break;
ret = s5k6aa_i2c_write(client, REG_CMDBUF0_ADDR, msg->val);
if (ret)
break;
/* Assume that msg->addr is always less than 0xfffc */
addr_incr = (msg + 1)->addr - msg->addr;
msg++;
}
return ret;
}
8<--
instead of s5k4ecgx_prep_buffer() and s5k4ecgx_write_burst(). But that
would have to be confirmed with the datasheet or by experimentation.
--
Thanks,
Sylwester
--
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] s2255drv: Add MODULE_FIRMWARE statement
Cc: Mauro Carvalho Chehab
Cc: Dean Anderson
Cc: Hans Verkuil
Cc: Dan Carpenter
Cc: Hans de Goede
Cc: linux-media@vger.kernel.org
Signed-off-by: Tim Gardner
---
drivers/media/video/s2255drv.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/video/s2255drv.c b/drivers/media/video/s2255drv.c
index 01c2179..95007dd 100644
--- a/drivers/media/video/s2255drv.c
+++ b/drivers/media/video/s2255drv.c
@@ -2686,3 +2686,4 @@ MODULE_DESCRIPTION("Sensoray 2255 Video for Linux
driver");
MODULE_AUTHOR("Dean Anderson (Sensoray Company Inc.)");
MODULE_LICENSE("GPL");
MODULE_VERSION(S2255_VERSION);
+MODULE_FIRMWARE(FIRMWARE_FILE_NAME);
--
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: Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
On 07/24/2012 11:11 PM, Devin Heitmueller wrote: On Tue, Jul 24, 2012 at 4:05 PM, Rémi Denis-Courmont wrote: If it's of interest to anyone, I could probably present a bunch of issues with V4L2 and DVB from userspace perspective. Remi, I would strongly be in favor of this. One thing that we get far to little of is feedback from actual userland developers making use of the V4L and DVB interfaces (aside from the SoC vendors, which is a completely different target audience than the traditional V4L and DVB consumers) I wonder if it is wise to merge both DVB and V4L2 APIs, add needed DVB stuff to V4L2 API and finally remove whole DVB API. V4L2 API seems to be much more feature rich, developed more actively and maybe has less problems than current DVB API. 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
Re: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
On Tue, Jul 24, 2012 at 5:50 PM, Antti Palosaari wrote: > On 07/24/2012 11:11 PM, Devin Heitmueller wrote: >> >> On Tue, Jul 24, 2012 at 4:05 PM, Rémi Denis-Courmont >> wrote: >>> >>> If it's of interest to anyone, I could probably present a bunch of issues >>> with >>> V4L2 and DVB from userspace perspective. >> >> >> Remi, >> >> >> I would strongly be in favor of this. One thing that we get far to >> little of is feedback from actual userland developers making use of >> the V4L and DVB interfaces (aside from the SoC vendors, which is a >> completely different target audience than the traditional V4L and DVB >> consumers) > > > I wonder if it is wise to merge both DVB and V4L2 APIs, add needed DVB stuff > to V4L2 API and finally remove whole DVB API. V4L2 API seems to be much more > feature rich, developed more actively and maybe has less problems than > current DVB API. lets never do that. -- 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: tda18271 driver power consumption
On Sun, Jul 22, 2012 at 3:59 PM, Antti Palosaari wrote: > Moi Michael, > I just realized tda18271 driver eats 160mA too much current after attach. > This means, there is power management bug. > > When I plug my nanoStick it eats total 240mA, after tda18271 sleep is called > it eats only 80mA total which is reasonable. If I use Digital Devices > tda18271c2dd driver it is total 110mA after attach, which is also quite OK. Thanks for the report -- I will take a look at it. ...patches are welcome, of course :-) -Mike -- 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 summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
On Tue, Jul 24, 2012 at 5:50 PM, Antti Palosaari wrote: > I wonder if it is wise to merge both DVB and V4L2 APIs, add needed DVB stuff > to V4L2 API and finally remove whole DVB API. V4L2 API seems to be much more > feature rich, developed more actively and maybe has less problems than > current DVB API. This may just be a case of "the grass is always greener on the other side of the fence". The V4L2 subsystem has more than it's share of problems - you just don't see them since you don't work with that code on a regular basis. 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: tda18271 driver power consumption
On 07/25/2012 12:55 AM, Michael Krufky wrote: On Sun, Jul 22, 2012 at 3:59 PM, Antti Palosaari wrote: Moi Michael, I just realized tda18271 driver eats 160mA too much current after attach. This means, there is power management bug. When I plug my nanoStick it eats total 240mA, after tda18271 sleep is called it eats only 80mA total which is reasonable. If I use Digital Devices tda18271c2dd driver it is total 110mA after attach, which is also quite OK. Thanks for the report -- I will take a look at it. ...patches are welcome, of course :-) I suspect it does some tweaking on attach() and chip leaves powered (I saw demod debugs at calls I2C-gate control quite many times thus this suspicion). When chip is powered-up it is usually in some sleep state by default. Also, on attach() there should be no I/O unless very good reason. For example chip ID is allowed to read and download firmware in case it is really needed to continue - like for tuner communication. What I found quickly testing few DVB USB sticks there seems to be very much power management problems... I am now waiting for new multimeter in order to make better measurements and likely return fixing these issues later. 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
Re: tda18271 driver power consumption
On Tue, Jul 24, 2012 at 6:12 PM, Antti Palosaari wrote: > On 07/25/2012 12:55 AM, Michael Krufky wrote: >> >> On Sun, Jul 22, 2012 at 3:59 PM, Antti Palosaari wrote: >>> >>> Moi Michael, >>> I just realized tda18271 driver eats 160mA too much current after attach. >>> This means, there is power management bug. >>> >>> When I plug my nanoStick it eats total 240mA, after tda18271 sleep is >>> called >>> it eats only 80mA total which is reasonable. If I use Digital Devices >>> tda18271c2dd driver it is total 110mA after attach, which is also quite >>> OK. >> >> >> Thanks for the report -- I will take a look at it. >> >> ...patches are welcome, of course :-) > > > I suspect it does some tweaking on attach() and chip leaves powered (I saw > demod debugs at calls I2C-gate control quite many times thus this > suspicion). When chip is powered-up it is usually in some sleep state by > default. Also, on attach() there should be no I/O unless very good reason. > For example chip ID is allowed to read and download firmware in case it is > really needed to continue - like for tuner communication. > > > What I found quickly testing few DVB USB sticks there seems to be very much > power management problems... I am now waiting for new multimeter in order to > make better measurements and likely return fixing these issues later. The driver does some calibration during attach, some of which is a one-time initialization to determine a temperature differential for tune calculation later on, which can take some time on slower USB buses. The "fix" for the power usage issue would just be to make sure to sleep the device before exiting the attach() function. I'm not looking to remove the calibration from the attach -- this was done on purpose. -Mike -- 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: tda18271 driver power consumption
On Tue, Jul 24, 2012 at 6:17 PM, Michael Krufky wrote: > On Tue, Jul 24, 2012 at 6:12 PM, Antti Palosaari wrote: >> On 07/25/2012 12:55 AM, Michael Krufky wrote: >>> >>> On Sun, Jul 22, 2012 at 3:59 PM, Antti Palosaari wrote: Moi Michael, I just realized tda18271 driver eats 160mA too much current after attach. This means, there is power management bug. When I plug my nanoStick it eats total 240mA, after tda18271 sleep is called it eats only 80mA total which is reasonable. If I use Digital Devices tda18271c2dd driver it is total 110mA after attach, which is also quite OK. >>> >>> >>> Thanks for the report -- I will take a look at it. >>> >>> ...patches are welcome, of course :-) >> >> >> I suspect it does some tweaking on attach() and chip leaves powered (I saw >> demod debugs at calls I2C-gate control quite many times thus this >> suspicion). When chip is powered-up it is usually in some sleep state by >> default. Also, on attach() there should be no I/O unless very good reason. >> For example chip ID is allowed to read and download firmware in case it is >> really needed to continue - like for tuner communication. >> >> >> What I found quickly testing few DVB USB sticks there seems to be very much >> power management problems... I am now waiting for new multimeter in order to >> make better measurements and likely return fixing these issues later. > > The driver does some calibration during attach, some of which is a > one-time initialization to determine a temperature differential for > tune calculation later on, which can take some time on slower USB > buses. The "fix" for the power usage issue would just be to make sure > to sleep the device before exiting the attach() function. > > I'm not looking to remove the calibration from the attach -- this was > done on purpose. > Antti, After looking again, I realize that we are purposefully not sleeping the device before we exit the attach() function. The tda18271 is commonly found in multi-chip designs that may or may not include an analog demodulator and / or other tda18271 tuners. In such designs, the chips tend to be daisy-chained to each other, using the xtal output and loop-thru features of the tda18271. We set the required features in the attach-time configuration structure. However, we must keep in mind that this is a hybrid tuner chip, and the analog side of the bridge driver may actually come up before the digital side. Since the actual configuration tends to be done in the digital bring-up, the analog side is brought up within tuner.ko using the most generic one-size-fits all configuration, which gets overridden when the digital side initializes. It is absolutely crucial that if we actually need the xtal output feature enabled, that it must *never* be turned off, otherwise the i2c bus may get wedged unrecoverably. So, we make sure to leave this feature enabled during the attach function, since we don't yet know at that point whether there is another "instance" of this same tuner yet to be initialized. It is not safe to power off that feature until after we are sure that the bridge has completely initialized. In order to rectify this issue from within your driver, you should call sleep after you complete the attach. For instance, this is what we do in the cx23885 driver: if (fe0->dvb.frontend->ops.analog_ops.standby) fe0->dvb.frontend->ops.analog_ops.standby(fe0->dvb.frontend); ...except you should call into the tuner_ops->sleep() function instead of analog_demod_ops->standby() Does this clear things up for you? Regards, Mike Krufky -- 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: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
Hello Mauro, We would like to participate in the media summit at San Diego. Can you please reserve 2 seats for us. If possible we would like to reserve a session to present how we have used the linuxTV to model our devices and support our use cases. We will also consolidate and pass on a list of questions related to spec ambiguities and hope to get it clarified during the summit! Can you please confirm back on the feasibility of our attendance? Regards Naveen Krishnamurthy ST Microelectronics. -Original Message- From: workshop-2011-boun...@linuxtv.org [mailto:workshop-2011-boun...@linuxtv.org] On Behalf Of Mauro Carvalho Chehab Sent: Tuesday, July 17, 2012 10:31 AM To: Linux Media Mailing List; workshop-2...@linuxtv.org Subject: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit As we did in 2012, we're planning to do a media summit again at KS/2012. The KS/2012 will happen in San Diego, CA, US, between Aug 26-28, just before the LinuxCon North America. In order to do it, I'd like to know who is interested on participate, and to get proposals about what subjects will be discussed there, in order to start planning the agenda. Thanks! Mauro Mensagem original Assunto: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit Data: Fri, 13 Jul 2012 13:37:08 -0400 De: Theodore Ts'o Para: James Bottomley CC: ksummit-2012-disc...@lists.linux-foundation.org, linux-kernel On Wed, Jul 11, 2012 at 09:09:15AM +0100, James Bottomley wrote: > Hi All, > > We have set aside the second day of the kernel summit (Tuesday 28 > August) as mini-summit day. So far we have only the PCI mini summit on > this day, so if you can think of other topics, please send them to the > kernel summit discuss list: > > ksummit-2012-disc...@lists.linux-foundation.org > > Looking at the available rooms, we think we can run about four or five > mini summits. > > As an added incentive, mini summit organisers get to pick who they > invite and all the people they pick will get an automatic invitation to > the third day of the kernel summit (but not the core first day) and the > evening events. OK, so far I believe I've heard concrete suggestions from identified (or fairly well identified :-) stuckees willing to organize mini-summits for: * ARM * Media * PCI * memcg I may have missed some, so if people could send a message to the discuss list with [MINI-SUMMIT] in the subbject line and the name of the proposed mini-summit, that would be really helpful. Please indicate whether you are volunteering to help organize the proposed mini-summit, or identify someone you think can be volunteered. :-) Things that we will be asking the mini-summit chars to determine, in addition to who should be given invites for Tuesday and Wednesday is an estimate of how much time you need, and a list of sub-topics (and who might lead the sub-topic discussion). We will be asking you to create a fairly well-defined schedule, with 30 and 60 minute slots, so that we can publish a schedule and so that people who might need to hop between mini-summits, have a chance to do so. So please start thinking about how long each of your sub-topics will need to be, and who might be needed for a particular sub-topic's discussion to be successful. There may be a number of developers, with fingers in multiple subsystem, where scheduling may become a bit of a challenge. Thanks!! - Ted ___ Ksummit-2012-discuss mailing list ksummit-2012-disc...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/ksummit-2012-discuss ___ Workshop-2011 mailing list workshop-2...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/workshop-2011 -- 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: tda18271 driver power consumption
On 07/25/2012 03:15 AM, Michael Krufky wrote: On Tue, Jul 24, 2012 at 6:17 PM, Michael Krufky wrote: On Tue, Jul 24, 2012 at 6:12 PM, Antti Palosaari wrote: On 07/25/2012 12:55 AM, Michael Krufky wrote: On Sun, Jul 22, 2012 at 3:59 PM, Antti Palosaari wrote: Moi Michael, I just realized tda18271 driver eats 160mA too much current after attach. This means, there is power management bug. When I plug my nanoStick it eats total 240mA, after tda18271 sleep is called it eats only 80mA total which is reasonable. If I use Digital Devices tda18271c2dd driver it is total 110mA after attach, which is also quite OK. Thanks for the report -- I will take a look at it. ...patches are welcome, of course :-) I suspect it does some tweaking on attach() and chip leaves powered (I saw demod debugs at calls I2C-gate control quite many times thus this suspicion). When chip is powered-up it is usually in some sleep state by default. Also, on attach() there should be no I/O unless very good reason. For example chip ID is allowed to read and download firmware in case it is really needed to continue - like for tuner communication. What I found quickly testing few DVB USB sticks there seems to be very much power management problems... I am now waiting for new multimeter in order to make better measurements and likely return fixing these issues later. The driver does some calibration during attach, some of which is a one-time initialization to determine a temperature differential for tune calculation later on, which can take some time on slower USB buses. The "fix" for the power usage issue would just be to make sure to sleep the device before exiting the attach() function. I'm not looking to remove the calibration from the attach -- this was done on purpose. Antti, After looking again, I realize that we are purposefully not sleeping the device before we exit the attach() function. The tda18271 is commonly found in multi-chip designs that may or may not include an analog demodulator and / or other tda18271 tuners. In such designs, the chips tend to be daisy-chained to each other, using the xtal output and loop-thru features of the tda18271. We set the required features in the attach-time configuration structure. However, we must keep in mind that this is a hybrid tuner chip, and the analog side of the bridge driver may actually come up before the digital side. Since the actual configuration tends to be done in the digital bring-up, the analog side is brought up within tuner.ko using the most generic one-size-fits all configuration, which gets overridden when the digital side initializes. It is absolutely crucial that if we actually need the xtal output feature enabled, that it must *never* be turned off, otherwise the i2c bus may get wedged unrecoverably. So, we make sure to leave this feature enabled during the attach function, since we don't yet know at that point whether there is another "instance" of this same tuner yet to be initialized. It is not safe to power off that feature until after we are sure that the bridge has completely initialized. In order to rectify this issue from within your driver, you should call sleep after you complete the attach. For instance, this is what we do in the cx23885 driver: if (fe0->dvb.frontend->ops.analog_ops.standby) fe0->dvb.frontend->ops.analog_ops.standby(fe0->dvb.frontend); ...except you should call into the tuner_ops->sleep() function instead of analog_demod_ops->standby() Does this clear things up for you? Surely this is possible and it will resolve power drain issue. But it is not nice looking and causes more deviation compared to others. Could you add configuration option "bool do_not_powerdown_on_attach" ? I have quite many tda18271 devices here and all those are DVB onlỵ (OK, PCTV 520e is DVB + analog, but analog is not supported). Having configuration parameter sounds like better plan. 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
Re: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
Hi Naveen, On Wed July 25 2012 02:17:25 Naveen KRISHNAMURTHY wrote: > Hello Mauro, > > We would like to participate in the media summit at San Diego. Can you > please reserve 2 seats for us. If possible we would like to reserve a > session to present how we have used the linuxTV to model our devices and > support our use cases. We will also consolidate and pass on a list of > questions related to spec ambiguities and hope to get it clarified during > the summit! Please pass that list on to me. I'm doing the section on V4L2 spec ambiguities etc., so I'd like to merge all just questions in one session. Note that my session only deals with V4L2 issues. For DVB issues someone else would have to coordinate that. Regards, Hans > > Can you please confirm back on the feasibility of our attendance? > > Regards > Naveen Krishnamurthy > ST Microelectronics. > > -Original Message- > From: workshop-2011-boun...@linuxtv.org > [mailto:workshop-2011-boun...@linuxtv.org] On Behalf Of Mauro Carvalho > Chehab Sent: Tuesday, July 17, 2012 10:31 AM > To: Linux Media Mailing List; workshop-2...@linuxtv.org > Subject: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: > [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit > > As we did in 2012, we're planning to do a media summit again at KS/2012. > > The KS/2012 will happen in San Diego, CA, US, between Aug 26-28, just > before the LinuxCon North America. > > In order to do it, I'd like to know who is interested on participate, > and to get proposals about what subjects will be discussed there, > in order to start planning the agenda. > > Thanks! > Mauro > > Mensagem original > Assunto: Re: [Ksummit-2012-discuss] Organising Mini Summits within the > Kernel Summit Data: Fri, 13 Jul 2012 13:37:08 -0400 > De: Theodore Ts'o > Para: James Bottomley > CC: ksummit-2012-disc...@lists.linux-foundation.org, linux-kernel > > > On Wed, Jul 11, 2012 at 09:09:15AM +0100, James Bottomley wrote: > > Hi All, > > > > We have set aside the second day of the kernel summit (Tuesday 28 > > August) as mini-summit day. So far we have only the PCI mini summit on > > this day, so if you can think of other topics, please send them to the > > kernel summit discuss list: > > > > ksummit-2012-disc...@lists.linux-foundation.org > > > > Looking at the available rooms, we think we can run about four or five > > mini summits. > > > > As an added incentive, mini summit organisers get to pick who they > > invite and all the people they pick will get an automatic invitation to > > the third day of the kernel summit (but not the core first day) and the > > evening events. > > OK, so far I believe I've heard concrete suggestions from identified > (or fairly well identified :-) stuckees willing to organize > mini-summits for: > > * ARM > * Media > * PCI > * memcg > > I may have missed some, so if people could send a message to the > discuss list with [MINI-SUMMIT] in the subbject line and the name of > the proposed mini-summit, that would be really helpful. Please > indicate whether you are volunteering to help organize the proposed > mini-summit, or identify someone you think can be volunteered. :-) > > Things that we will be asking the mini-summit chars to determine, in > addition to who should be given invites for Tuesday and Wednesday is > an estimate of how much time you need, and a list of sub-topics (and > who might lead the sub-topic discussion). We will be asking you to > create a fairly well-defined schedule, with 30 and 60 minute slots, so > that we can publish a schedule and so that people who might need to > hop between mini-summits, have a chance to do so. So please start > thinking about how long each of your sub-topics will need to be, and > who might be needed for a particular sub-topic's discussion to be > successful. There may be a number of developers, with fingers in > multiple subsystem, where scheduling may become a bit of a challenge. > > Thanks!! > > - Ted > ___ > Ksummit-2012-discuss mailing list > ksummit-2012-disc...@lists.linux-foundation.org > https://lists.linux-foundation.org/mailman/listinfo/ksummit-2012-discuss > > > > ___ > Workshop-2011 mailing list > workshop-2...@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/workshop-2011 > > ___ > Workshop-2011 mailing list > workshop-2...@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/workshop-2011 -- 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: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
On Tue July 24 2012 19:40:27 Michael Krufky wrote: > Apologies for my late reply -- I plan to attend the conference!!! Looking forward to seeing you again! > I am looking to book everything today... I think I'm going to Barcelona > as well -- will you guys go to both conferences? I'll be in Barcelona as well. Regards, Hans > > On Sat, Jul 21, 2012 at 1:06 AM, Guennadi Liakhovetski > > wrote: > > Hi Mauro > > > > On Tue, 17 Jul 2012, Guennadi Liakhovetski wrote: > >> Hi Mauro > >> > >> On Tue, 17 Jul 2012, Mauro Carvalho Chehab wrote: > >> > As we did in 2012, we're planning to do a media summit again at > >> > KS/2012. > >> > > >> > The KS/2012 will happen in San Diego, CA, US, between Aug 26-28, just > >> > before the LinuxCon North America. > >> > > >> > In order to do it, I'd like to know who is interested on participate, > >> > and to get proposals about what subjects will be discussed there, > >> > in order to start planning the agenda. > >> > >> I'd love to attend, especially since, as you have seen, I've started > >> doing some work on V4L DT bindings, but so far it very much looks like > >> I won't be able to do so unfortunately. > > > > Things change and sometimes also to the better:-) Looks like I'll be able > > to attend actually. So, please add me to the list. > > > > Thanks > > Guennadi > > > >> > Thanks! > >> > Mauro > >> > > >> > Mensagem original > >> > Assunto: Re: [Ksummit-2012-discuss] Organising Mini Summits within the > >> > Kernel Summit Data: Fri, 13 Jul 2012 13:37:08 -0400 > >> > De: Theodore Ts'o > >> > Para: James Bottomley > >> > CC: ksummit-2012-disc...@lists.linux-foundation.org, linux-kernel > >> > > >> > > >> > On Wed, Jul 11, 2012 at 09:09:15AM +0100, James Bottomley wrote: > >> > > Hi All, > >> > > > >> > > We have set aside the second day of the kernel summit (Tuesday 28 > >> > > August) as mini-summit day. So far we have only the PCI mini summit > >> > > on this day, so if you can think of other topics, please send them > >> > > to the kernel summit discuss list: > >> > > > >> > > ksummit-2012-disc...@lists.linux-foundation.org > >> > > > >> > > Looking at the available rooms, we think we can run about four or > >> > > five mini summits. > >> > > > >> > > As an added incentive, mini summit organisers get to pick who they > >> > > invite and all the people they pick will get an automatic invitation > >> > > to the third day of the kernel summit (but not the core first day) > >> > > and the evening events. > >> > > >> > OK, so far I believe I've heard concrete suggestions from identified > >> > (or fairly well identified :-) stuckees willing to organize > >> > mini-summits for: > >> > > >> > * ARM > >> > * Media > >> > * PCI > >> > * memcg > >> > > >> > I may have missed some, so if people could send a message to the > >> > discuss list with [MINI-SUMMIT] in the subbject line and the name of > >> > the proposed mini-summit, that would be really helpful. Please > >> > indicate whether you are volunteering to help organize the proposed > >> > mini-summit, or identify someone you think can be volunteered. :-) > >> > > >> > Things that we will be asking the mini-summit chars to determine, in > >> > addition to who should be given invites for Tuesday and Wednesday is > >> > an estimate of how much time you need, and a list of sub-topics (and > >> > who might lead the sub-topic discussion). We will be asking you to > >> > create a fairly well-defined schedule, with 30 and 60 minute slots, so > >> > that we can publish a schedule and so that people who might need to > >> > hop between mini-summits, have a chance to do so. So please start > >> > thinking about how long each of your sub-topics will need to be, and > >> > who might be needed for a particular sub-topic's discussion to be > >> > successful. There may be a number of developers, with fingers in > >> > multiple subsystem, where scheduling may become a bit of a challenge. > >> > > >> > Thanks!! > >> > > >> > - Ted > >> > > >> > ___ > >> > Ksummit-2012-discuss mailing list > >> > ksummit-2012-disc...@lists.linux-foundation.org > >> > https://lists.linux-foundation.org/mailman/listinfo/ksummit-2012-discu > >> > ss > >> > > >> > > >> > > >> > ___ > >> > Workshop-2011 mailing list > >> > workshop-2...@linuxtv.org > >> > http://www.linuxtv.org/cgi-bin/mailman/listinfo/workshop-2011 > >> > >> --- > >> Guennadi Liakhovetski, Ph.D. > >> Freelance Open-Source Software Developer > >> http://www.open-technology.de/ > >> > >> ___ > >> Workshop-2011 mailing list > >> workshop-2...@linuxtv.org > >> http://www.linuxtv.org/cgi-bin/mailman/listinfo/workshop-2011 > > > > --- > > Guennadi Liakhovetski, Ph.D. > > Freelance Open-Source Software Developer > > http://www.open-technology.de/ > > > > __
Re: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
On Tue July 24 2012 22:37:35 Rémi Denis-Courmont wrote: > Le mardi 24 juillet 2012 23:31:42 Andy Walls, vous avez écrit : > > >I would strongly be in favor of this. One thing that we get far to > > >little of is feedback from actual userland developers making use of > > >the V4L and DVB interfaces (aside from the SoC vendors, which is a > > >completely different target audience than the traditional V4L and DVB > > >consumers) > > > > > >Devin > > > > Ditto. Input from user application developers is something that kernel > > developers need and value greatly. > > > > Note, that I will not be at the workshop of Plumbers this year. :( > > Is the media summit timed with LPC or the kernel summit? If I come, I have > to leave on Thursday to catch the VideoLAN conference in Paris on the next > week- end... It's timed with the kernel summit and it will be on Tuesday. So you should have ample time. And feedback to us from a user perspective would be very useful. As others have mentioned, we do not see that often enough. 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
[PATCH 1/3] ARM: dma-mapping: define ARCH_HAS_DMA_MMAP_COHERENT
ARCH_HAS_DMA_MMAP_COHERENT indicates that there is dma_mmap_coherent() API in this architecture. The name is already defined in PowerPC. Signed-off-by: Hideki EIRAKU --- arch/arm/include/asm/dma-mapping.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h index bbef15d..f41cd30 100644 --- a/arch/arm/include/asm/dma-mapping.h +++ b/arch/arm/include/asm/dma-mapping.h @@ -187,6 +187,7 @@ extern int arm_dma_mmap(struct device *dev, struct vm_area_struct *vma, struct dma_attrs *attrs); #define dma_mmap_coherent(d, v, c, h, s) dma_mmap_attrs(d, v, c, h, s, NULL) +#define ARCH_HAS_DMA_MMAP_COHERENT static inline int dma_mmap_attrs(struct device *dev, struct vm_area_struct *vma, void *cpu_addr, dma_addr_t dma_addr, -- 1.7.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
[PATCH 0/3] Use dma_mmap_coherent to support IOMMU mapper
There is a dma_mmap_coherent() API in some architectures. This API provides a mmap function for memory allocated by dma_alloc_coherent(). Some drivers mmap a dma_addr_t returned by dma_alloc_coherent() as a physical address. But such drivers do not work correctly when IOMMU mapper is used. Hideki EIRAKU (3): ARM: dma-mapping: define ARCH_HAS_DMA_MMAP_COHERENT media: videobuf2-dma-contig: use dma_mmap_coherent if available fbdev: sh_mobile_lcdc: use dma_mmap_coherent if available arch/arm/include/asm/dma-mapping.h |1 + drivers/media/video/videobuf2-dma-contig.c | 18 ++ drivers/video/sh_mobile_lcdcfb.c | 14 ++ 3 files changed, 33 insertions(+), 0 deletions(-) -- 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 3/3] fbdev: sh_mobile_lcdc: use dma_mmap_coherent if available
fb_mmap() implemented in fbmem.c uses smem_start as the physical
address of the frame buffer. In the sh_mobile_lcdc driver, the
smem_start is a dma_addr_t that is not a physical address when IOMMU is
enabled. dma_mmap_coherent() maps the address correctly. It is
available on ARM platforms.
Signed-off-by: Hideki EIRAKU
---
drivers/video/sh_mobile_lcdcfb.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
index e672698..65732c4 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -1393,6 +1393,17 @@ static int sh_mobile_lcdc_blank(int blank, struct
fb_info *info)
return 0;
}
+#ifdef ARCH_HAS_DMA_MMAP_COHERENT
+static int
+sh_mobile_fb_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+ struct sh_mobile_lcdc_chan *ch = info->par;
+
+ return dma_mmap_coherent(ch->lcdc->dev, vma, ch->fb_mem,
+ch->dma_handle, ch->fb_size);
+}
+#endif
+
static struct fb_ops sh_mobile_lcdc_ops = {
.owner = THIS_MODULE,
.fb_setcolreg = sh_mobile_lcdc_setcolreg,
@@ -1408,6 +1419,9 @@ static struct fb_ops sh_mobile_lcdc_ops = {
.fb_release = sh_mobile_release,
.fb_check_var = sh_mobile_check_var,
.fb_set_par = sh_mobile_set_par,
+#ifdef ARCH_HAS_DMA_MMAP_COHERENT
+ .fb_mmap= sh_mobile_fb_mmap,
+#endif
};
static void
--
1.7.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
[PATCH 2/3] media: videobuf2-dma-contig: use dma_mmap_coherent if available
Previously the vb2_dma_contig_mmap() function was using a dma_addr_t as a
physical address. The two addressses are not necessarily the same.
For example, when using the IOMMU funtion on certain platforms, dma_addr_t
addresses are not directly mappable physical address.
dma_mmap_coherent() maps the address correctly.
It is available on ARM platforms.
Signed-off-by: Hideki EIRAKU
---
drivers/media/video/videobuf2-dma-contig.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media/video/videobuf2-dma-contig.c
index 4b71326..4dc85ab 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -101,14 +101,32 @@ static unsigned int vb2_dma_contig_num_users(void
*buf_priv)
static int vb2_dma_contig_mmap(void *buf_priv, struct vm_area_struct *vma)
{
struct vb2_dc_buf *buf = buf_priv;
+#ifdef ARCH_HAS_DMA_MMAP_COHERENT
+ int ret;
+#endif
if (!buf) {
printk(KERN_ERR "No buffer to map\n");
return -EINVAL;
}
+#ifdef ARCH_HAS_DMA_MMAP_COHERENT
+ vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+ ret = dma_mmap_coherent(buf->conf->dev, vma, buf->vaddr, buf->dma_addr,
+ buf->size);
+ if (ret) {
+ pr_err("Remapping memory failed, error: %d\n", ret);
+ return ret;
+ }
+ vma->vm_flags |= VM_DONTEXPAND | VM_RESERVED;
+ vma->vm_private_data = &buf->handler;
+ vma->vm_ops = &vb2_common_vm_ops;
+ vma->vm_ops->open(vma);
+ return 0;
+#else
return vb2_mmap_pfn_range(vma, buf->dma_addr, buf->size,
&vb2_common_vm_ops, &buf->handler);
+#endif
}
static void *vb2_dma_contig_get_userptr(void *alloc_ctx, unsigned long vaddr,
--
1.7.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
