Re: [PATCH v6 1/2] media: add new mediabus format enums for dm365
Hi Prabhakar, Thanks for the patch! Just a few comments. On Fri, Jul 20, 2012 at 08:28:09PM +0530, Prabhakar Lad wrote: From: Manjunath Hadli manjunath.ha...@ti.com add new enum entries for supporting the media-bus formats on dm365. These include some bayer and some non-bayer formats. V4L2_MBUS_FMT_YDYUYDYV8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used internal to the hardware by the resizer. V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format that is supported by dm365 hardware. Acked-by: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Signed-off-by: Lad, Prabhakar prabhakar@ti.com Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Sakari Ailus sakari.ai...@iki.fi Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de --- Documentation/DocBook/media/v4l/subdev-formats.xml | 250 +++- include/linux/v4l2-mediabus.h | 10 +- 2 files changed, 252 insertions(+), 8 deletions(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 49c532e..01b2811 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml ... @@ -853,10 +921,16 @@ titlePacked YUV Formats/title paraThose data formats transfer pixel data as (possibly downsampled) Y, U - and V components. The format code is made of the following information. + and V components. Some formats include dummy bits in some of their samples + and are collectively referred to as YDYC (Y-Dummy-Y-Chroma) formats. + One cannot rely on the values of these dummy bits as those are undefined. + /para + paraThe format code is made of the following information. Also many raw bayer formats contain padding bits to align pixels to byte boundaries. We haven't had a situation where we'd have the same amount of information per pixel on a pixel format with and without padding. The definition of those formats does not require the padding bits to be zero, but in practice they always are. How about the dm series of chips; are the bits always zero? The OMAP 3 ISP spec doesn't specify that either AFAIR but in practice the ISP only writes zeros there. ... @@ -877,7 +951,21 @@ U, Y, V, Y order will be named constantV4L2_MBUS_FMT_UYVY8_2X8/constant. /para - paraThe following table lisst existing packet YUV formats./para + paraxref linkend=v4l2-mbus-pixelcode-yuv8/ list existing packet YUV s/list/lists/ ? Kind regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: 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 v6 2/2] v4l2: add new pixel formats supported on dm365
Hi Prabhakar,
Thanks for the patch.
On Fri, Jul 20, 2012 at 08:28:10PM +0530, Prabhakar Lad wrote:
From: Manjunath Hadli manjunath.ha...@ti.com
add new macro V4L2_PIX_FMT_SGRBG10ALAW8 and associated formats
to represent Bayer format frames compressed by A-LAW algorithm,
add V4L2_PIX_FMT_UV8 to represent storage of CbCr data (UV interleaved)
only.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
.../DocBook/media/v4l/pixfmt-srggb10alaw8.xml | 34 +++
Documentation/DocBook/media/v4l/pixfmt-uv8.xml | 62
Documentation/DocBook/media/v4l/pixfmt.xml |2 +
include/linux/videodev2.h |8 +++
4 files changed, 106 insertions(+), 0 deletions(-)
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-uv8.xml
diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
new file mode 100644
index 000..61cced5
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
@@ -0,0 +1,34 @@
+ refentry
+ refmeta
+ refentrytitle
+ V4L2_PIX_FMT_SRGGB10ALAW8 ('aRA8'),
+ V4L2_PIX_FMT_SGRBG10ALAW8 ('agA8'),
+ V4L2_PIX_FMT_SGBRG10ALAW8 ('aGA8'),
+ V4L2_PIX_FMT_SBGGR10ALAW8 ('aBA8'),
Could you use the same order as in Documentation/video4linux/4CCs.txt ? I
know it's different in some existing documentation.
Regards,
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: 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
[patch 1/2] [media] tuner-xc2028: fix = vs == typo
We intended to do a compare here, not an assignment.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
Static analysis bug. I don't own the hardware.
diff --git a/drivers/media/common/tuners/tuner-xc2028.c
b/drivers/media/common/tuners/tuner-xc2028.c
index f88f948..9e60285 100644
--- a/drivers/media/common/tuners/tuner-xc2028.c
+++ b/drivers/media/common/tuners/tuner-xc2028.c
@@ -756,7 +756,7 @@ retry:
* No need to reload base firmware if it matches and if the tuner
* is not at sleep mode
*/
- if ((priv-state = XC2028_ACTIVE)
+ if ((priv-state == XC2028_ACTIVE)
(((BASE | new_fw.type) BASE_TYPES) ==
(priv-cur_fw.type BASE_TYPES))) {
tuner_dbg(BASE firmware not changed.\n);
--
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/2] [media] tuner-xc2028: unlock on error in xc2028_get_afc()
We need to do a mutex_unlock(priv-lock) before returning. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com diff --git a/drivers/media/common/tuners/tuner-xc2028.c b/drivers/media/common/tuners/tuner-xc2028.c index 9e60285..ea0550e 100644 --- a/drivers/media/common/tuners/tuner-xc2028.c +++ b/drivers/media/common/tuners/tuner-xc2028.c @@ -978,7 +978,7 @@ static int xc2028_get_afc(struct dvb_frontend *fe, s32 *afc) /* Get AFC */ rc = xc2028_get_reg(priv, XREG_FREQ_ERROR, afc_reg); if (rc 0) - return rc; + goto ret; *afc = afc_reg * 15625; /* Hz */ -- 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 system Summit
Hello all, Le jeudi 12 juillet 2012 06:18:08 Mauro Carvalho Chehab, vous avez écrit : 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 Not sure what happened (or maybe my proposal were not clear enough), but I've submitted a proposal to have a media system summit on KS/2011. Last year was very productive for media developers, so we'd like to do it again ;) Do you guys expect to discuss anything relevant to userland? (V4L? DVB? ...?) -- 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 v6] media: coda: Add driver for Coda video codec.
On Fri July 20 2012 13:08:35 Javier Martin wrote: Coda is a range of video codecs from ChipsMedia that support H.264, H.263, MPEG4 and other video standards. Currently only support for the codadx6 included in the i.MX27 SoC is added. H.264 and MPEG4 video encoding are the only supported capabilities by now. Signed-off-by: Javier Martin javier.mar...@vista-silicon.com Reviewed-by: Philipp Zabelp.za...@pengutronix.de --- Changes since v5: - Fixed some v4l2-compliance issues. Some or all? Can you give me the 'v4l2-compliance -v1' output? Regards, Hans - Attended most of Sylwester's tips. -- 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
Hi Hans, On 07/17/2012 09:32 PM, Hans Verkuil wrote: On Tue July 17 2012 19:30:53 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 like to have 30 minutes to discuss a few V4L2 API ambiguities or just plain weirdness, just like I did last year. I'll make an RFC issues to discuss beforehand. I might also have a short presentation/demo of v4l2-compliance, as I believe more people need to know about that utility. What do you think about adding new M2M capability flag for memory-to-memory video devices ? I prepared an RFC patch for that already: http://www.mail-archive.com/linux-media@vger.kernel.org/msg48497.html I think that at least qualifies to your list of V4L2 API ambiguities, even though we have device_caps now. Using ORed OUTPUT and CAPTURE flags implies all existing applications must check now both flags when they're trying to discover a video capture or video output device. -- Regards, 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
Re: Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
On Sat July 21 2012 14:16:22 Sylwester Nawrocki wrote: Hi Hans, On 07/17/2012 09:32 PM, Hans Verkuil wrote: On Tue July 17 2012 19:30:53 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 like to have 30 minutes to discuss a few V4L2 API ambiguities or just plain weirdness, just like I did last year. I'll make an RFC issues to discuss beforehand. I might also have a short presentation/demo of v4l2-compliance, as I believe more people need to know about that utility. What do you think about adding new M2M capability flag for memory-to-memory video devices ? I prepared an RFC patch for that already: http://www.mail-archive.com/linux-media@vger.kernel.org/msg48497.html I think that at least qualifies to your list of V4L2 API ambiguities, even though we have device_caps now. Using ORed OUTPUT and CAPTURE flags implies all existing applications must check now both flags when they're trying to discover a video capture or video output device. I agree. I've added to my list (which is getting pretty long BTW, I will probably need more than 30 minutes). When adding support for M2M devices to v4l2-compliance I also noticed that using CAPTURE+OUTPUT is a rather awkward way to signal this capability, so I agree to adding a special cap bit for that. 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: Firmware in da wonderland
On 07/21/2012 06:32 PM, poma wrote: This one speak for itself; … usb 1-1: new high-speed USB device number 8 using ehci_hcd usb 1-1: New USB device found, idVendor=0ccd, idProduct=0097 usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1: Product: USB2.0 DVB-T TV Stick usb 1-1: Manufacturer: NEWMI usb 1-1: SerialNumber: 01010101061 dvb-usb: found a 'TerraTec Cinergy T Stick RC' in cold state, will try to load a firmware dvb-usb: did not find the firmware file. (dvb-usb-af9015.fw) Please see linux/Documentation/dvb/ for more details on firmware-problems. (-2) dvb_usb_af9015: probe of 1-1:1.0 failed with error -2 input: NEWMI USB2.0 DVB-T TV Stick as /devices/pci:00/:00:04.1/usb1/1-1/1-1:1.1/input/input18 generic-usb 0003:0CCD:0097.0007: input,hidraw6: USB HID v1.01 Keyboard [NEWMI USB2.0 DVB-T TV Stick] on usb-:00:04.1-1/input1 … FW path: /usr/lib/firmware/dvb-usb-af9015.fw Is it somehow related to Fedora UsrMove!? Or Fedora itself :) Bug 827538 - DVB USB device firmware requested in module_init() https://bugzilla.redhat.com/show_bug.cgi?id=827538 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: DVB core enhancements - comments please?
Morjens!
I am now working with that suspend/resume/power-management, as I got LNA
issues resolved.
On 07/03/2012 08:21 PM, Marko Ristola wrote:
Moikka Antti.
On 07/01/2012 02:11 PM, Antti Palosaari wrote:
Moikka Marko,
-- snip --
Hmm, I did some initial suspend / resume changes for DVB USB when I
rewrote it recently. On suspend, it just kills all ongoing urbs used
for streaming. And on resume it resubmit those urbs in order to resume
streaming. It just works as it doesn't hang computer anymore. What I
tested applications continued to show same television channels on resume.
The problem for that solution is that it does not have any power
management as power management is DVB-core responsibility. So it
continues eating current because chips are not put sleep and due to
that those DVB-core changes are required.
I think that runtime (RT) frontend power saving is a different thing.
It isn't necessarily suspend/resume thing.
Yes it is different thing (DVB-core runtime power-management). But as
there is currently implemented .init() and .sleep() callbacks both
frontend and tuner for power management I don't see why not to use those
for suspend and resume too.
I implemented runtime Frontend power saving in 2007 on that patch I
referenced.
I used dvb-core's existing functionality. Maybe this concept is
applicable for you too.
I added into Mantis bridge device initialization following functions:
+ mantis-fe-ops.tuner_ops.sleep =
mantis_dvb_tuner_sleep;
+ mantis-fe-ops.tuner_ops.init =
mantis_dvb_tuner_init;
tuner_ops.{sleep,init} modification had to be the last one.
I maintained in mantis-has_power the frontend's power status.
Maybe I could have read the active status from PCI context too.
The concept was something like:
- dvb-core has responsibility to call tuner_ops.sleep() and
tuner_ops.init() when applicable.
- Mantis PCI Bridge driver (or specific USB driver) has responsibility
to provide sleep and init implementations for the specific device.
- Mantis bridge device will do the whole task of frontend power
management, by calling Frontend's
tear down / initialization functions when necessary.
I looked it and reads your discussion too. That code seem never ended up
for Mantis.
But the idea is just basically same: use existing sleep() calls to put
device sleep on suspend and on resume use init() to wake-up again. You
stored existing parameters inside driver state and retuned using those
when set_frontend() get NULL as a parameter. Things has changed a little
after that and now those parameters are stored already in dvb-frontend
cache - which means a little less work for driver.
- What changes encrypted channels need?
I think none?
So after all, what I think currently, is:
* bridge sets and forwards .suspend() callback to dvb-core
* bridge sets and forwards .resume() callback to dvb-core
* on suspend, dvb-core puts device sleep
* on resume, dvb-core wake-ups device and inits tune (parameters are in
cache already)
Clearly, put hardware sleep similarly as in case frontend is in sleep,
but keep userland interface alive (frontend, demux, etc).
There is a quite lot of documentation to learn and overall whole Kernel
power-managent is very complex. Fortunately driver implementation is
very simple most cases. Also as changing DVB-core is needed it should be
extremely care not make any regressions.
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: [PATCH 1/2] kthread_worker: reorganize to prepare for flush_kthread_work() reimplementation
On Thu, 2012-07-19 at 14:15 -0700, Tejun Heo wrote:
From c9bba34243a86fb3ac82d1bdd0ce4bf796b79559 Mon Sep 17 00:00:00 2001
From: Tejun Heo t...@kernel.org
Date: Thu, 19 Jul 2012 13:52:53 -0700
Make the following two non-functional changes.
* Separate out insert_kthread_work() from queue_kthread_work().
* Relocate struct kthread_flush_work and kthread_flush_work_fn()
definitions above flush_kthread_work().
Signed-off-by: Tejun Heo t...@kernel.org
---
kernel/kthread.c | 40
1 files changed, 24 insertions(+), 16 deletions(-)
diff --git a/kernel/kthread.c b/kernel/kthread.c
index 3d3de63..7b8a678 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -378,6 +378,17 @@ repeat:
}
EXPORT_SYMBOL_GPL(kthread_worker_fn);
+/* insert @work before @pos in @worker */
Hi Tejun,
Would a comment that the caller should be holding worker-lock be useful
here? Anyway, comment or not:
Acked-by: Andy Walls aw...@md.metrocast.net
Regards,
Andy
+static void insert_kthread_work(struct kthread_worker *worker,
+struct kthread_work *work,
+struct list_head *pos)
+{
+ list_add_tail(work-node, pos);
+ work-queue_seq++;
+ if (likely(worker-task))
+ wake_up_process(worker-task);
+}
+
/**
* queue_kthread_work - queue a kthread_work
* @worker: target kthread_worker
@@ -395,10 +406,7 @@ bool queue_kthread_work(struct kthread_worker *worker,
spin_lock_irqsave(worker-lock, flags);
if (list_empty(work-node)) {
- list_add_tail(work-node, worker-work_list);
- work-queue_seq++;
- if (likely(worker-task))
- wake_up_process(worker-task);
+ insert_kthread_work(worker, work, worker-work_list);
ret = true;
}
spin_unlock_irqrestore(worker-lock, flags);
@@ -406,6 +414,18 @@ bool queue_kthread_work(struct kthread_worker *worker,
}
EXPORT_SYMBOL_GPL(queue_kthread_work);
+struct kthread_flush_work {
+ struct kthread_work work;
+ struct completion done;
+};
+
+static void kthread_flush_work_fn(struct kthread_work *work)
+{
+ struct kthread_flush_work *fwork =
+ container_of(work, struct kthread_flush_work, work);
+ complete(fwork-done);
+}
+
/**
* flush_kthread_work - flush a kthread_work
* @work: work to flush
@@ -436,18 +456,6 @@ void flush_kthread_work(struct kthread_work *work)
}
EXPORT_SYMBOL_GPL(flush_kthread_work);
-struct kthread_flush_work {
- struct kthread_work work;
- struct completion done;
-};
-
-static void kthread_flush_work_fn(struct kthread_work *work)
-{
- struct kthread_flush_work *fwork =
- container_of(work, struct kthread_flush_work, work);
- complete(fwork-done);
-}
-
/**
* flush_kthread_worker - flush all current works on a kthread_worker
* @worker: worker to flush
--
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: Firmware in da wonderland
On 07/21/2012 05:35 PM, Antti Palosaari wrote: On 07/21/2012 06:32 PM, poma wrote: This one speak for itself; … usb 1-1: new high-speed USB device number 8 using ehci_hcd usb 1-1: New USB device found, idVendor=0ccd, idProduct=0097 usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1: Product: USB2.0 DVB-T TV Stick usb 1-1: Manufacturer: NEWMI usb 1-1: SerialNumber: 01010101061 dvb-usb: found a 'TerraTec Cinergy T Stick RC' in cold state, will try to load a firmware dvb-usb: did not find the firmware file. (dvb-usb-af9015.fw) Please see linux/Documentation/dvb/ for more details on firmware-problems. (-2) dvb_usb_af9015: probe of 1-1:1.0 failed with error -2 input: NEWMI USB2.0 DVB-T TV Stick as /devices/pci:00/:00:04.1/usb1/1-1/1-1:1.1/input/input18 generic-usb 0003:0CCD:0097.0007: input,hidraw6: USB HID v1.01 Keyboard [NEWMI USB2.0 DVB-T TV Stick] on usb-:00:04.1-1/input1 … FW path: /usr/lib/firmware/dvb-usb-af9015.fw Is it somehow related to Fedora UsrMove!? Or Fedora itself :) Bug 827538 - DVB USB device firmware requested in module_init() https://bugzilla.redhat.com/show_bug.cgi?id=827538 Antti Live Fast(Driver) Die Young(Firmware) ;) Directed by Udev Systemd …firmware should in general be requested asynchronously… Obviously, some of communication in Red Hat RD team is done asynchronously, too. Nice. But Hey, Fedora is all about test drive ;) Antti, keep up the good work! regards, poma -- 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 Thu, 2012-07-19 at 14:16 -0700, Tejun Heo wrote:
From 06f9a06f4aeecdb9d07014713ab41b548ae219b5 Mon Sep 17 00:00:00 2001
From: Tejun Heo t...@kernel.org
Date: Thu, 19 Jul 2012 13:52:53 -0700
kthread_worker provides minimalistic workqueue-like interface for
users which need a dedicated worker thread (e.g. for realtime
priority). It has basic queue, flush_work, flush_worker operations
which mostly match the workqueue counterparts; however, due to the way
flush_work() is implemented, it has a noticeable difference of not
allowing work items to be freed while being executed.
While the current users of kthread_worker are okay with the current
behavior, the restriction does impede some valid use cases. Also,
removing this difference isn't difficult and actually makes the code
easier to understand.
This patch reimplements flush_kthread_work() such that it uses a
flush_work item instead of queue/done sequence numbers.
Signed-off-by: Tejun Heo t...@kernel.org
---
include/linux/kthread.h |8 +-
kernel/kthread.c| 48 ++
2 files changed, 29 insertions(+), 27 deletions(-)
Hi Tejun,
I have a question and comment below.
diff --git a/include/linux/kthread.h b/include/linux/kthread.h
index 0714b24..22ccf9d 100644
--- a/include/linux/kthread.h
+++ b/include/linux/kthread.h
@@ -49,8 +49,6 @@ extern int tsk_fork_get_node(struct task_struct *tsk);
* can be queued and flushed using queue/flush_kthread_work()
* respectively. Queued kthread_works are processed by a kthread
* running kthread_worker_fn().
- *
- * A kthread_work can't be freed while it is executing.
*/
struct kthread_work;
typedef void (*kthread_work_func_t)(struct kthread_work *work);
@@ -59,15 +57,14 @@ struct kthread_worker {
spinlock_t lock;
struct list_headwork_list;
struct task_struct *task;
+ struct kthread_work *current_work;
};
struct kthread_work {
struct list_headnode;
kthread_work_func_t func;
wait_queue_head_t done;
- atomic_tflushing;
- int queue_seq;
- int done_seq;
+ struct kthread_worker *worker;
};
#define KTHREAD_WORKER_INIT(worker) { \
@@ -79,7 +76,6 @@ struct kthread_work {
.node = LIST_HEAD_INIT((work).node),\
.func = (fn), \
.done = __WAIT_QUEUE_HEAD_INITIALIZER((work).done), \
- .flushing = ATOMIC_INIT(0), \
}
#define DEFINE_KTHREAD_WORKER(worker)
\
diff --git a/kernel/kthread.c b/kernel/kthread.c
index 7b8a678..4034b2b 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -360,16 +360,12 @@ repeat:
struct kthread_work, node);
list_del_init(work-node);
}
+ worker-current_work = work;
spin_unlock_irq(worker-lock);
if (work) {
__set_current_state(TASK_RUNNING);
work-func(work);
If the call to 'work-func(work);' frees the memory pointed to by
'work', 'worker-current_work' points to deallocated memory.
So 'worker-current_work' will only ever used as a unique 'work'
identifier to handle, correct?
- smp_wmb(); /* wmb worker-b0 paired with flush-b1 */
- work-done_seq = work-queue_seq;
- smp_mb(); /* mb worker-b1 paired with flush-b0 */
- if (atomic_read(work-flushing))
- wake_up_all(work-done);
} else if (!freezing(current))
schedule();
@@ -384,7 +380,7 @@ static void insert_kthread_work(struct kthread_worker
*worker,
struct list_head *pos)
{
list_add_tail(work-node, pos);
- work-queue_seq++;
+ work-worker = worker;
if (likely(worker-task))
wake_up_process(worker-task);
}
@@ -434,25 +430,35 @@ static void kthread_flush_work_fn(struct kthread_work
*work)
*/
void flush_kthread_work(struct kthread_work *work)
{
- int seq = work-queue_seq;
+ struct kthread_flush_work fwork = {
+ KTHREAD_WORK_INIT(fwork.work, kthread_flush_work_fn),
+ COMPLETION_INITIALIZER_ONSTACK(fwork.done),
+ };
+ struct kthread_worker *worker;
+ bool noop = false;
+
You might want a check for 'work == NULL' here, to gracefully handle
code like the following:
void driver_work_handler(struct kthread_work *work)
{
...
kfree(work);
}
struct kthread_work *driver_queue_batch(void)
{
struct kthread_work *work = NULL;
...
while (driver_more_stuff_todo()) {
work = kzalloc(sizeof(struct kthread work), GFP_WHATEVER);
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:Sat Jul 21 19:00:22 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/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.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
