[RFCv3 PATCH] poll: add poll_requested_events() function
This is the third version of this patch. The only change I've made is to
update three comments that were no longer in sync with the code after this
change. Thanks to Jonathan Corbet for pointing this out to me.
If there are no more comments, then I want to queue this for v3.1 via the
linux-media tree next week.
Regards,
Hans
In some cases the poll() implementation in a driver has to do different
things depending on the events the caller wants to poll for. An example is
when a driver needs to start a DMA engine if the caller polls for POLLIN,
but doesn't want to do that if POLLIN is not requested but instead only
POLLOUT or POLLPRI is requested. This is something that can happen in the
video4linux subsystem.
Unfortunately, the current epoll/poll/select implementation doesn't provide
that information reliably. The poll_table_struct does have it: it has a key
field with the event mask. But once a poll() call matches one or more bits
of that mask any following poll() calls are passed a NULL poll_table_struct
pointer.
The solution is to set the qproc field to NULL in poll_table_struct once
poll() matches the events, not the poll_table_struct pointer itself. That
way drivers can obtain the mask through a new poll_requested_events inline.
The poll_table_struct can still be NULL since some kernel code calls it
internally (netfs_state_poll() in ./drivers/staging/pohmelfs/netfs.h). In
that case poll_requested_events() returns ~0 (i.e. all events).
Since eventpoll always leaves the key field at ~0 instead of using the
requested events mask, that source was changed as well to properly fill in
the key field.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Reviewed-by: Jonathan Corbet cor...@lwn.net
---
fs/eventpoll.c | 19 +++
fs/select.c | 38 +-
include/linux/poll.h |7 ++-
3 files changed, 38 insertions(+), 26 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index f9cfd16..6a54a69 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -650,9 +650,12 @@ static int ep_read_events_proc(struct eventpoll *ep,
struct list_head *head,
void *priv)
{
struct epitem *epi, *tmp;
+ poll_table pt;
+ init_poll_funcptr(pt, NULL);
list_for_each_entry_safe(epi, tmp, head, rdllink) {
- if (epi-ffd.file-f_op-poll(epi-ffd.file, NULL)
+ pt.key = epi-event.events;
+ if (epi-ffd.file-f_op-poll(epi-ffd.file, pt)
epi-event.events)
return POLLIN | POLLRDNORM;
else {
@@ -946,6 +949,7 @@ static int ep_insert(struct eventpoll *ep, struct
epoll_event *event,
/* Initialize the poll table using the queue callback */
epq.epi = epi;
init_poll_funcptr(epq.pt, ep_ptable_queue_proc);
+ epq.pt.key = event-events;
/*
* Attach the item to the poll hooks and get current event bits.
@@ -1027,20 +1031,23 @@ static int ep_modify(struct eventpoll *ep, struct
epitem *epi, struct epoll_even
{
int pwake = 0;
unsigned int revents;
+ poll_table pt;
+
+ init_poll_funcptr(pt, NULL);
/*
* Set the new event interest mask before calling f_op-poll();
* otherwise we might miss an event that happens between the
* f_op-poll() call and the new event set registering.
*/
- epi-event.events = event-events;
+ epi-event.events = pt.key = event-events;
epi-event.data = event-data; /* protected by mtx */
/*
* Get current event bits. We can safely use the file* here because
* its usage count has been increased by the caller of this function.
*/
- revents = epi-ffd.file-f_op-poll(epi-ffd.file, NULL);
+ revents = epi-ffd.file-f_op-poll(epi-ffd.file, pt);
/*
* If the item is hot and it is not registered inside the ready
@@ -1075,6 +1082,9 @@ static int ep_send_events_proc(struct eventpoll *ep,
struct list_head *head,
unsigned int revents;
struct epitem *epi;
struct epoll_event __user *uevent;
+ poll_table pt;
+
+ init_poll_funcptr(pt, NULL);
/*
* We can loop without lock because we are passed a task private list.
@@ -1087,7 +1097,8 @@ static int ep_send_events_proc(struct eventpoll *ep,
struct list_head *head,
list_del_init(epi-rdllink);
- revents = epi-ffd.file-f_op-poll(epi-ffd.file, NULL)
+ pt.key = epi-event.events;
+ revents = epi-ffd.file-f_op-poll(epi-ffd.file, pt)
epi-event.events;
/*
diff --git a/fs/select.c b/fs/select.c
index d33418f..b6765cf 100644
--- a/fs/select.c
+++ b/fs/select.c
@@ -386,13 +386,11 @@ get_max:
static inline void wait_key_set(poll_table *wait, unsigned long in,
unsigned long out,
[patch] Staging: tm6000: remove unneeded check in get_next_buf()
We dereference buf on the line before so if it were NULL here we would have OOPsed earlier. Also list_entry() never returns NULL. And finally, we handled the situation where the list is empty earlier in the function. So this test isn't needed and I've removed it. Signed-off-by: Dan Carpenter erro...@gmail.com diff --git a/drivers/staging/tm6000/tm6000-video.c b/drivers/staging/tm6000/tm6000-video.c index 3fe6038..8d8b939 100644 --- a/drivers/staging/tm6000/tm6000-video.c +++ b/drivers/staging/tm6000/tm6000-video.c @@ -179,9 +179,6 @@ static inline void get_next_buf(struct tm6000_dmaqueue *dma_q, *buf = list_entry(dma_q-active.next, struct tm6000_buffer, vb.queue); - if (!buf) - return; - /* Cleans up buffer - Useful for testing for frame/URB loss */ outp = videobuf_to_vmalloc((*buf)-vb); -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] tea5764: Fix module parameter permissions
The third parameter of module_param is supposed to represent sysfs file permissions. A value of 1 leads to the following: $ ls -l /sys/module/radio_tea5764/parameters/ total 0 -x 1 root root 4096 Jul 8 09:17 use_xtal I am changing it to 0 to align with the other module parameters in this driver. Signed-off-by: Jean Delvare jdelv...@suse.de Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: Fabio Belavenuto belaven...@gmail.com --- drivers/media/radio/radio-tea5764.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-3.0-rc6.orig/drivers/media/radio/radio-tea5764.c 2011-05-20 10:41:19.0 +0200 +++ linux-3.0-rc6/drivers/media/radio/radio-tea5764.c 2011-07-08 09:15:16.0 +0200 @@ -596,7 +596,7 @@ MODULE_AUTHOR(DRIVER_AUTHOR); MODULE_DESCRIPTION(DRIVER_DESC); MODULE_LICENSE(GPL); -module_param(use_xtal, int, 1); +module_param(use_xtal, int, 0); MODULE_PARM_DESC(use_xtal, Chip have a xtal connected in board); module_param(radio_nr, int, 0); MODULE_PARM_DESC(radio_nr, video4linux device number to use); -- Jean Delvare Suse L3 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] tea5764: Fix module parameter permissions
Jean Delvare jdelv...@suse.de wrote: The third parameter of module_param is supposed to represent sysfs file permissions. A value of 1 leads to the following: $ ls -l /sys/module/radio_tea5764/parameters/ total 0 -x 1 root root 4096 Jul 8 09:17 use_xtal I am changing it to 0 to align with the other module parameters in this driver. Signed-off-by: Jean Delvare jdelv...@suse.de Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: Fabio Belavenuto belaven...@gmail.com --- drivers/media/radio/radio-tea5764.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-3.0-rc6.orig/drivers/media/radio/radio-tea5764.c 2011-05-20 10:41:19.0 +0200 +++ linux-3.0-rc6/drivers/media/radio/radio-tea5764.c 2011-07-08 09:15:16.0 +0200 @@ -596,7 +596,7 @@ MODULE_AUTHOR(DRIVER_AUTHOR); MODULE_DESCRIPTION(DRIVER_DESC); MODULE_LICENSE(GPL); -module_param(use_xtal, int, 1); +module_param(use_xtal, int, 0); MODULE_PARM_DESC(use_xtal, Chip have a xtal connected in board); module_param(radio_nr, int, 0); MODULE_PARM_DESC(radio_nr, video4linux device number to use); -- Jean Delvare Suse L3 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html To whomever might know: Was the intent of the 1 to set the default value of the parameter? 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: Pach under review.
Em 07-07-2011 23:12, Marco Diego Aurélio Mesquita escreveu: Hi! I would like to have my patch[1] ready for linux 3.0. It's a simple one-liner to solve an easy to fix problem. Is there anything I can do o accelerate the review process? Please, CC me your answers as I'm not subscribed to the list. Tanks! [1] https://patchwork.kernel.org/patch/849142/ Hi Marco, Hans is currently in vacations, so, we'll likely need to wait for his return. I prefer to not rush merging it, because I don't have the pac207 datasheets, and it is a good idea to have more tests on it. What webcams had you tested needing such fix? Thanks, Mauro -- 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: Pach under review.
Em 07-07-2011 23:12, Marco Diego Aurélio Mesquita escreveu: Hi! I would like to have my patch[1] ready for linux 3.0. It's a simple one-liner to solve an easy to fix problem. Is there anything I can do o accelerate the review process? Please, CC me your answers as I'm not subscribed to the list. Tanks! [1] https://patchwork.kernel.org/patch/849142/ Hi Marco, Hans is currently in vacations, so, we'll likely need to wait for his return. I prefer to not rush merging it, because I don't have the pac207 datasheets, and it is a good idea to have more tests on it. What webcams had you test needing such fix? Thanks, Mauro -- 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
[GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 drivers conversion to media controller API
Hi Mauro, The following changes since commit 6068c012c3741537c9f965be5b4249f989aa5efc: [media] v4l: Document V4L2 control endianness as machine endianness (2011-07-07 19:26:11 -0300) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-2.6-samsung s5p-fimc-next These patches convert FIMC and the sensor driver to media controller API, i.e. a top level media device is added to be able to manage at runtime attached sensors and all video processing entities present in the SoC. An additional subdev at FIMC capture driver exposes the scaler and composing functionality of the video capture IP. The previously existing functionality is entirely retained. I have introduced a few changes comparing to the last version (v3) sent to the ML, as commented below. Sylwester Nawrocki (28): s5p-fimc: Add support for runtime PM in the mem-to-mem driver s5p-fimc: Add media entity initialization s5p-fimc: Remove registration of video nodes from probe() s5p-fimc: Remove sclk_cam clock handling s5p-fimc: Limit number of available inputs to one s5p-fimc: Remove sensor management code from FIMC capture driver s5p-fimc: Remove v4l2_device from video capture and m2m driver s5p-fimc: Add the media device driver s5p-fimc: Conversion to use struct v4l2_fh - removed the check of return value from v4l2_fh_init as its signature has changed s5p-fimc: Conversion to the control framework s5p-fimc: Add media operations in the capture entity driver s5p-fimc: Add PM helper function for streaming control s5p-fimc: Correct color format enumeration s5p-fimc: Convert to use media pipeline operations s5p-fimc: Add subdev for the FIMC processing block - added setting of a default capture format in device open() s5p-fimc: Add support for camera capture in JPEG format s5p-fimc: Add v4l2_device notification support for single frame capture s5p-fimc: Use consistent names for the buffer list functions s5p-fimc: Add runtime PM support in the camera capture driver s5p-fimc: Correct crop offset alignment on exynos4 s5p-fimc: Remove single-planar capability flags noon010pc30: Do not ignore errors in initial controls setup noon010pc30: Convert to the pad level ops - removed unused variable and pad number prerequisite check in noon010_set_fmt noon010pc30: Clean up the s_power callback noon010pc30: Remove g_chip_ident operation handler s5p-csis: Handle all available power supplies - renamed 'supply' to 'supplies' in s5p-csis as per Laurent's suggestion s5p-csis: Rework of the system suspend/resume helpers s5p-csis: Enable v4l subdev device node drivers/media/video/Kconfig |4 +- drivers/media/video/noon010pc30.c | 173 ++-- drivers/media/video/s5p-fimc/Makefile |2 +- drivers/media/video/s5p-fimc/fimc-capture.c | 1424 +++ drivers/media/video/s5p-fimc/fimc-core.c| 1119 +++-- drivers/media/video/s5p-fimc/fimc-core.h| 222 +++-- drivers/media/video/s5p-fimc/fimc-mdevice.c | 859 drivers/media/video/s5p-fimc/fimc-mdevice.h | 118 +++ drivers/media/video/s5p-fimc/fimc-reg.c | 76 +- drivers/media/video/s5p-fimc/mipi-csis.c| 84 +- drivers/media/video/s5p-fimc/regs-fimc.h|8 +- include/media/s5p_fimc.h| 11 + include/media/v4l2-chip-ident.h |3 - 13 files changed, 2921 insertions(+), 1182 deletions(-) create mode 100644 drivers/media/video/s5p-fimc/fimc-mdevice.c create mode 100644 drivers/media/video/s5p-fimc/fimc-mdevice.h Regards, -- Sylwester Nawrocki Samsung Poland RD Center -- 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 6/8] drivers: add Contiguous Memory Allocator
On Tue, Jul 05, 2011 at 03:58:39PM +0200, Arnd Bergmann wrote: Ah, sorry I missed that patch on the mailing list, found it now in your for-next branch. I've been searching for this email to reply to for the last day or so... If I'm reading your ARM: DMA: steal memory for DMA coherent mappings correctly, the idea is to have a per-platform compile-time amount of memory that is reserved purely for coherent allocations and taking out of the buddy allocator, right? Yes, because every time I've looked at taking out memory mappings in the first level page tables, it's always been a major issue. We have a method where we can remove first level mappings on uniprocessor systems in the ioremap code just fine - we use that so that systems can setup section and supersection mappings. They can tear them down as well - and we update other tasks L1 page tables when they get switched in. This, however, doesn't work on SMP, because if you have a DMA allocation (which is permitted from IRQ context) you must have some way of removing the L1 page table entries from all CPUs TLBs and the page tables currently in use and any future page tables which those CPUs may switch to. The easy bit is future page tables - that can be done in the same way as the ioremap() code does with a generation number, checked when a new page table is switched in. The problem is the current CPUs, and as we know trying to call smp_call_function() with IRQs disabled is not permitted due to deadlock. So, in a SMP system, there is no safe way to remove L1 page table entries from IRQ context. That means if memory is mapped for the buddy allocators using L1 page table entries, then it is fixed for that application on a SMP system. However, that's not really what I wanted to find this email for. That is I'm dropping the ARM: DMA: steal memory for DMA coherent mappings patch for this merge window because - as I found out yesterday - it prevents the Assabet platform booting, and so would be a regression. Plus, I have a report of a regression with the streaming DMA API speculative prefetch fixes causing the IOP ADMA raid5 async offload stuff to explode - which may result in the streaming DMA API fixes being reverted (which will leave ARMv6+ vulnerable to data corruption.) As I have no time to work through the RAID5 code, async_tx code, and IOP ADMA code to get to the bottom of it (because of this flood of patches) I think a revert is looking likely - either that or I'll have to tell the bug reporter to go away, which really isn't on. It's on LKML if anyone's interested in trying to diagnose it, the PROBLEM: ARM-dma-mapping-fix-for-speculative-prefetching cause OOPS thread. -- 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: Pach under review.
Mauro Carvalho Chehab mche...@redhat.com wrote: Em 07-07-2011 23:12, Marco Diego Aurélio Mesquita escreveu: Hi! I would like to have my patch[1] ready for linux 3.0. It's a simple one-liner to solve an easy to fix problem. Is there anything I can do o accelerate the review process? Please, CC me your answers as I'm not subscribed to the list. Tanks! [1] https://patchwork.kernel.org/patch/849142/ Hi Marco, Hans is currently in vacations, so, we'll likely need to wait for his return. I prefer to not rush merging it, because I don't have the pac207 datasheets, and it is a good idea to have more tests on it. What webcams had you tested needing such fix? Thanks, Mauro -- 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 FWIW, a PAC207 datasheet is on line here: http://www.soiseek.com/PIXART/PAC207BCA/index.htm 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
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Fri Jul 8 19:01:02 CEST 2011 git hash:6068c012c3741537c9f965be5b4249f989aa5efc gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-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-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 spec-git: ERRORS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The 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: [GIT PULL for v3.0] OMAP_VOUT bug fixes and code cleanup
On Thu, 7 Jul 2011, JAIN, AMBER wrote: I think what David wants to say is that if we do not have DMA restrictions on OMAP we should have not used GFP_DMA flag for page allocation at first place. Is my understanding correct David? Right, and that's what the patch is doing. -- 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] One more Marvell cam patch series
Here is yet another set of marvell-cam patches. These ones clean up some
old cruft, fix one bug, and make it so that you don't have to drag in all
three videobuf2 modes if you don't want them. It looks like a lot of
churn, but the bulk of it is simply moving functions around into a more
logical organization.
The one thing that's not there, unfortunately, is the removal of the ov7670
dependency. If Linus does another round or two of rc's before 3.0, I may
just get that done for the merge window; otherwise that will have to be for
3.1. It's the top item on my list.
The patches can be pulled from:
git://git.lwn.net/linux-2.6.git for-mauro
Patches in this series:
Jonathan Corbet (6):
marvell-cam: delete struct mcam_sio_buffer
marvell-cam: core code reorganization
marvell-cam: remove {min,max}_buffers parameters
marvell-cam: power down mmp camera on registration failure
marvell-cam: Allow selection of supported buffer modes
marvell-cam: clean up a couple of unused cam structure fields
Kconfig |3
mcam-core.c | 1048 ++-
mcam-core.h | 69 ++-
mmp-driver.c |2
4 files changed, 601 insertions(+), 521 deletions(-)
Thanks,
jon
--
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/6] marvell-cam: remove {min,max}_buffers parameters
Somewhere along the way the code stopped actually paying any attention to them, and I doubt anybody has ever made use of them. Signed-off-by: Jonathan Corbet cor...@lwn.net --- drivers/media/video/marvell-ccic/mcam-core.c | 13 - 1 files changed, 0 insertions(+), 13 deletions(-) diff --git a/drivers/media/video/marvell-ccic/mcam-core.c b/drivers/media/video/marvell-ccic/mcam-core.c index 8a99ec2..9867b3b 100644 --- a/drivers/media/video/marvell-ccic/mcam-core.c +++ b/drivers/media/video/marvell-ccic/mcam-core.c @@ -72,19 +72,6 @@ MODULE_PARM_DESC(dma_buf_size, parameters require larger buffers, an attempt to reallocate will be made.); -static int min_buffers = 1; -module_param(min_buffers, uint, 0644); -MODULE_PARM_DESC(min_buffers, - The minimum number of streaming I/O buffers we are willing - to work with.); - -static int max_buffers = 10; -module_param(max_buffers, uint, 0644); -MODULE_PARM_DESC(max_buffers, - The maximum number of streaming I/O buffers an application - will be allowed to allocate. These buffers are big and live - in vmalloc space.); - static int flip; module_param(flip, bool, 0444); MODULE_PARM_DESC(flip, -- 1.7.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
[PATCH 4/6] marvell-cam: power down mmp camera on registration failure
If registration does not work, we don't want to leave the sensor powered on. Signed-off-by: Jonathan Corbet cor...@lwn.net --- drivers/media/video/marvell-ccic/mmp-driver.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/marvell-ccic/mmp-driver.c b/drivers/media/video/marvell-ccic/mmp-driver.c index 8415915..d6b7645 100644 --- a/drivers/media/video/marvell-ccic/mmp-driver.c +++ b/drivers/media/video/marvell-ccic/mmp-driver.c @@ -267,8 +267,8 @@ static int mmpcam_probe(struct platform_device *pdev) out_unregister: mccic_shutdown(mcam); - mmpcam_power_down(mcam); out_gpio2: + mmpcam_power_down(mcam); gpio_free(pdata-sensor_reset_gpio); out_gpio: gpio_free(pdata-sensor_power_gpio); -- 1.7.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
[PATCH 2/6] marvell-cam: core code reorganization
This code shows signs of having been mucked with over the last five years
or so; things were kind of mixed up. This patch reorders functions into a
more rational organization which, with luck, will facilitate making the
buffer modes selectable at configuration time. Code movement only: no
functional changes here.
Signed-off-by: Jonathan Corbet cor...@lwn.net
---
drivers/media/video/marvell-ccic/mcam-core.c | 914 +-
1 files changed, 465 insertions(+), 449 deletions(-)
diff --git a/drivers/media/video/marvell-ccic/mcam-core.c
b/drivers/media/video/marvell-ccic/mcam-core.c
index af5faa6..8a99ec2 100644
--- a/drivers/media/video/marvell-ccic/mcam-core.c
+++ b/drivers/media/video/marvell-ccic/mcam-core.c
@@ -157,29 +157,20 @@ static struct mcam_format_struct *mcam_find_format(u32
pixelformat)
}
/*
- * Start over with DMA buffers - dev_lock needed.
+ * The default format we use until somebody says otherwise.
*/
-static void mcam_reset_buffers(struct mcam_camera *cam)
-{
- int i;
-
- cam-next_buf = -1;
- for (i = 0; i cam-nbufs; i++)
- clear_bit(i, cam-flags);
-}
+static const struct v4l2_pix_format mcam_def_pix_format = {
+ .width = VGA_WIDTH,
+ .height = VGA_HEIGHT,
+ .pixelformat= V4L2_PIX_FMT_YUYV,
+ .field = V4L2_FIELD_NONE,
+ .bytesperline = VGA_WIDTH*2,
+ .sizeimage = VGA_WIDTH*VGA_HEIGHT*2,
+};
-static inline int mcam_needs_config(struct mcam_camera *cam)
-{
- return test_bit(CF_CONFIG_NEEDED, cam-flags);
-}
+static const enum v4l2_mbus_pixelcode mcam_def_mbus_code =
+ V4L2_MBUS_FMT_YUYV8_2X8;
-static void mcam_set_config_needed(struct mcam_camera *cam, int needed)
-{
- if (needed)
- set_bit(CF_CONFIG_NEEDED, cam-flags);
- else
- clear_bit(CF_CONFIG_NEEDED, cam-flags);
-}
/*
* The two-word DMA descriptor format used by the Armada 610 and like. There
@@ -210,6 +201,19 @@ static inline struct mcam_vb_buffer *vb_to_mvb(struct
vb2_buffer *vb)
return container_of(vb, struct mcam_vb_buffer, vb_buf);
}
+/*
+ * Hand a completed buffer back to user space.
+ */
+static void mcam_buffer_done(struct mcam_camera *cam, int frame,
+ struct vb2_buffer *vbuf)
+{
+ vbuf-v4l2_buf.bytesused = cam-pix_format.sizeimage;
+ vbuf-v4l2_buf.sequence = cam-buf_seq[frame];
+ vb2_set_plane_payload(vbuf, 0, cam-pix_format.sizeimage);
+ vb2_buffer_done(vbuf, VB2_BUF_STATE_DONE);
+}
+
+
/*
* Debugging and related.
@@ -222,11 +226,109 @@ static inline struct mcam_vb_buffer *vb_to_mvb(struct
vb2_buffer *vb)
dev_dbg((cam)-dev, fmt, ##arg);
+/*
+ * Flag manipulation helpers
+ */
+static void mcam_reset_buffers(struct mcam_camera *cam)
+{
+ int i;
+
+ cam-next_buf = -1;
+ for (i = 0; i cam-nbufs; i++)
+ clear_bit(i, cam-flags);
+}
+
+static inline int mcam_needs_config(struct mcam_camera *cam)
+{
+ return test_bit(CF_CONFIG_NEEDED, cam-flags);
+}
+
+static void mcam_set_config_needed(struct mcam_camera *cam, int needed)
+{
+ if (needed)
+ set_bit(CF_CONFIG_NEEDED, cam-flags);
+ else
+ clear_bit(CF_CONFIG_NEEDED, cam-flags);
+}
/* --- */
/*
- * Deal with the controller.
+ * Make the controller start grabbing images. Everything must
+ * be set up before doing this.
*/
+static void mcam_ctlr_start(struct mcam_camera *cam)
+{
+ /* set_bit performs a read, so no other barrier should be
+ needed here */
+ mcam_reg_set_bit(cam, REG_CTRL0, C0_ENABLE);
+}
+
+static void mcam_ctlr_stop(struct mcam_camera *cam)
+{
+ mcam_reg_clear_bit(cam, REG_CTRL0, C0_ENABLE);
+}
+
+/* --- */
+/*
+ * Code specific to the vmalloc buffer mode.
+ */
+
+/*
+ * Allocate in-kernel DMA buffers for vmalloc mode.
+ */
+static int mcam_alloc_dma_bufs(struct mcam_camera *cam, int loadtime)
+{
+ int i;
+
+ mcam_set_config_needed(cam, 1);
+ if (loadtime)
+ cam-dma_buf_size = dma_buf_size;
+ else
+ cam-dma_buf_size = cam-pix_format.sizeimage;
+ if (n_dma_bufs 3)
+ n_dma_bufs = 3;
+
+ cam-nbufs = 0;
+ for (i = 0; i n_dma_bufs; i++) {
+ cam-dma_bufs[i] = dma_alloc_coherent(cam-dev,
+ cam-dma_buf_size, cam-dma_handles + i,
+ GFP_KERNEL);
+ if (cam-dma_bufs[i] == NULL) {
+ cam_warn(cam, Failed to allocate DMA buffer\n);
+ break;
+ }
+ (cam-nbufs)++;
+ }
+
+ switch (cam-nbufs) {
+ case 1:
+ dma_free_coherent(cam-dev, cam-dma_buf_size,
+
[PATCH 1/6] marvell-cam: delete struct mcam_sio_buffer
This structure got passed over in the videobuf2 conversion; it has no
reason to exist now.
Signed-off-by: Jonathan Corbet cor...@lwn.net
---
drivers/media/video/marvell-ccic/mcam-core.h | 11 ---
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/marvell-ccic/mcam-core.h
b/drivers/media/video/marvell-ccic/mcam-core.h
index 55fd078..9a39e08 100644
--- a/drivers/media/video/marvell-ccic/mcam-core.h
+++ b/drivers/media/video/marvell-ccic/mcam-core.h
@@ -11,17 +11,6 @@
#include media/v4l2-dev.h
#include media/videobuf2-core.h
-/*
- * Tracking of streaming I/O buffers.
- * FIXME doesn't belong in this file
- */
-struct mcam_sio_buffer {
- struct list_head list;
- struct v4l2_buffer v4lbuf;
- char *buffer; /* Where it lives in kernel space */
- int mapcount;
- struct mcam_camera *cam;
-};
enum mcam_state {
S_NOTREADY, /* Not yet initialized */
--
1.7.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
[PATCH 6/6] marvell-cam: clean up a couple of unused cam structure fields
Delete a couple of leftover fields whose time has passed.
Signed-off-by: Jonathan Corbet cor...@lwn.net
---
drivers/media/video/marvell-ccic/mcam-core.c |2 --
drivers/media/video/marvell-ccic/mcam-core.h |3 ---
2 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/marvell-ccic/mcam-core.c
b/drivers/media/video/marvell-ccic/mcam-core.c
index 073e72c..83c1451 100644
--- a/drivers/media/video/marvell-ccic/mcam-core.c
+++ b/drivers/media/video/marvell-ccic/mcam-core.c
@@ -1638,7 +1638,6 @@ static void mcam_frame_complete(struct mcam_camera *cam,
int frame)
clear_bit(CF_DMA_ACTIVE, cam-flags);
cam-next_buf = frame;
cam-buf_seq[frame] = ++(cam-sequence);
- cam-last_delivered = frame;
frames++;
/*
* This should never happen
@@ -1741,7 +1740,6 @@ int mccic_register(struct mcam_camera *cam)
mcam_set_config_needed(cam, 1);
cam-pix_format = mcam_def_pix_format;
cam-mbus_code = mcam_def_mbus_code;
- INIT_LIST_HEAD(cam-dev_list);
INIT_LIST_HEAD(cam-buffers);
mcam_ctlr_init(cam);
diff --git a/drivers/media/video/marvell-ccic/mcam-core.h
b/drivers/media/video/marvell-ccic/mcam-core.h
index aa55255..917200e 100644
--- a/drivers/media/video/marvell-ccic/mcam-core.h
+++ b/drivers/media/video/marvell-ccic/mcam-core.h
@@ -116,8 +116,6 @@ struct mcam_camera {
struct v4l2_subdev *sensor;
unsigned short sensor_addr;
- struct list_head dev_list; /* link to other devices */
-
/* Videobuf2 stuff */
struct vb2_queue vb_queue;
struct list_head buffers; /* Available frames */
@@ -138,7 +136,6 @@ struct mcam_camera {
/* DMA buffers - DMA modes */
struct mcam_vb_buffer *vb_bufs[MAX_DMA_BUFS];
struct vb2_alloc_ctx *vb_alloc_ctx;
- unsigned short last_delivered;
/* Mode-specific ops, set at open time */
void (*dma_setup)(struct mcam_camera *cam);
--
1.7.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
[PATCH 5/6] marvell-cam: Allow selection of supported buffer modes
The Marvell camera core can support all three videobuf2 buffer modes, which
is slick, but it also requires that all three modes be built and present,
even though only one is likely to be used. This patch allows the supported
modes to be selected at configuration time, reducing the footprint of the
driver. Prior to this patch, the MMP camera driver looked like this:
mmp_camera 19092 0
videobuf2_core 15542 1 mmp_camera
videobuf2_dma_sg3173 1 mmp_camera
videobuf2_dma_contig 2188 1 mmp_camera
videobuf2_vmalloc 1718 1 mmp_camera
videobuf2_memops2100 3
videobuf2_dma_sg,videobuf2_dma_contig,videobuf2_vmalloc
Afterward, instead, with scatter/gather only configured:
mmp_camera 16021 0
videobuf2_core 15542 1 mmp_camera
videobuf2_dma_sg3173 1 mmp_camera
videobuf2_memops2100 1 videobuf2_dma_sg
The total goes from 43,813 bytes to 36,836.
The emphasis has been on simplicity and minimal #ifdef use rather than on
squeezing out every possible byte of code. For configuration, the driver
simply looks at which videobuf2 modes have been configured in and supports
them all; it's simplistic but should be good enough.
The cafe driver is set to support vmalloc and dma-contig; mmp supports only
dma-sg, since that's the only mode that really makes sense to use.
Signed-off-by: Jonathan Corbet cor...@lwn.net
---
drivers/media/video/marvell-ccic/Kconfig |3 -
drivers/media/video/marvell-ccic/mcam-core.c | 149 +-
drivers/media/video/marvell-ccic/mcam-core.h | 59 +-
3 files changed, 152 insertions(+), 59 deletions(-)
diff --git a/drivers/media/video/marvell-ccic/Kconfig
b/drivers/media/video/marvell-ccic/Kconfig
index 5be66e2..bf739e3 100644
--- a/drivers/media/video/marvell-ccic/Kconfig
+++ b/drivers/media/video/marvell-ccic/Kconfig
@@ -4,7 +4,6 @@ config VIDEO_CAFE_CCIC
select VIDEO_OV7670
select VIDEOBUF2_VMALLOC
select VIDEOBUF2_DMA_CONTIG
- select VIDEOBUF2_DMA_SG
---help---
This is a video4linux2 driver for the Marvell 88ALP01 integrated
CMOS camera controller. This is the controller found on first-
@@ -15,8 +14,6 @@ config VIDEO_MMP_CAMERA
depends on ARCH_MMP I2C VIDEO_V4L2
select VIDEO_OV7670
select I2C_GPIO
- select VIDEOBUF2_VMALLOC
- select VIDEOBUF2_DMA_CONTIG
select VIDEOBUF2_DMA_SG
---help---
This is a Video4Linux2 driver for the integrated camera
diff --git a/drivers/media/video/marvell-ccic/mcam-core.c
b/drivers/media/video/marvell-ccic/mcam-core.c
index 9867b3b..073e72c 100644
--- a/drivers/media/video/marvell-ccic/mcam-core.c
+++ b/drivers/media/video/marvell-ccic/mcam-core.c
@@ -37,6 +37,7 @@ static int frames;
static int singles;
static int delivered;
+#ifdef MCAM_MODE_VMALLOC
/*
* Internal DMA buffer management. Since the controller cannot do S/G I/O,
* we must have physically contiguous buffers to bring frames into.
@@ -71,6 +72,10 @@ MODULE_PARM_DESC(dma_buf_size,
The size of the allocated DMA buffers. If actual operating
parameters require larger buffers, an attempt to reallocate
will be made.);
+#else /* MCAM_MODE_VMALLOC */
+static const int alloc_bufs_at_read = 0;
+static const int n_dma_bufs = 3; /* Used by S/G_PARM */
+#endif /* MCAM_MODE_VMALLOC */
static int flip;
module_param(flip, bool, 0444);
@@ -256,6 +261,8 @@ static void mcam_ctlr_stop(struct mcam_camera *cam)
}
/* --- */
+
+#ifdef MCAM_MODE_VMALLOC
/*
* Code specific to the vmalloc buffer mode.
*/
@@ -381,6 +388,46 @@ static void mcam_frame_tasklet(unsigned long data)
}
+/*
+ * Make sure our allocated buffers are up to the task.
+ */
+static int mcam_check_dma_buffers(struct mcam_camera *cam)
+{
+ if (cam-nbufs 0 cam-dma_buf_size cam-pix_format.sizeimage)
+ mcam_free_dma_bufs(cam);
+ if (cam-nbufs == 0)
+ return mcam_alloc_dma_bufs(cam, 0);
+ return 0;
+}
+
+static void mcam_vmalloc_done(struct mcam_camera *cam, int frame)
+{
+ tasklet_schedule(cam-s_tasklet);
+}
+
+#else /* MCAM_MODE_VMALLOC */
+
+static inline int mcam_alloc_dma_bufs(struct mcam_camera *cam, int loadtime)
+{
+ return 0;
+}
+
+static inline void mcam_free_dma_bufs(struct mcam_camera *cam)
+{
+ return;
+}
+
+static inline int mcam_check_dma_buffers(struct mcam_camera *cam)
+{
+ return 0;
+}
+
+
+
+#endif /* MCAM_MODE_VMALLOC */
+
+
+#ifdef MCAM_MODE_DMA_CONTIG
/* -- */
/*
* DMA-contiguous code.
@@ -444,8 +491,9 @@ static void mcam_dma_contig_done(struct mcam_camera *cam,
int frame)
mcam_set_contig_buffer(cam, frame);
}
+#endif /* MCAM_MODE_DMA_CONTIG */
-
+#ifdef MCAM_MODE_DMA_SG
/*
where to find the old hg repo. ?
Dear all, I need the old revision of the mxl500x-af9015 to driver the USB device 07ca:815c from AVerMedia. Original path is: http://linuxtv.org/hg/~anttip/af9015-mxl500x the wanted revision is af9015-mxl500x-1487a7dcf22a or other newer/latest revision. One of my friend in his company has successfully use the driver to watch TV, but he cannot send the source to me according company policy. Is it not integrated into mainline kernel? Best Regards, cwz0522 -- 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: where to find the old hg repo. ?
On 07/09/2011 05:14 AM, Peter Chen wrote: Dear all, I need the old revision of the mxl500x-af9015 to driver the USB device 07ca:815c from AVerMedia. Original path is: http://linuxtv.org/hg/~anttip/af9015-mxl500x the wanted revision is af9015-mxl500x-1487a7dcf22a or other newer/latest revision. One of my friend in his company has successfully use the driver to watch TV, but he cannot send the source to me according company policy. Is it not integrated into mainline kernel? I removed it since it have been inside main Kernel ages. Are you sure product ID is 815c? Current driver does not have this ID and I am almost 100% sure it was never supported. You should add new device entry for that device to af9015.c in order to get it working. Please send patch. 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: RTL2831U driver updates
Hello RTL2831U driver is now available here realtek branch: http://git.linuxtv.org/anttip/media_tree.git From my side it is ready for merge. RTL2830 DVB-T demod === Driver is very limited, it basically just works, no any statistics. That's written totally from the scratch. RTL28XXU DVB USB I think it is also almost fully written from the scratch, but not sure since it have been so lng under the development. At least register definitions are from Realtek driver. Jan could you now find out copyrights, SOBs, etc. are correct? And how that should be merge... I wonder Maxim can add support for RTL2832U to RTL28XXU DVB USB. It should not be much work. I tested it with my RTL2832U device and some minor changes were needed. Remote controller seems to be only which is totally different between RTL2831U and RTL2832U (and 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: Fwd: [PATCH] STV22 Dual USB DVB-T Tuner HDTV linux kernel support
On 06/24/2011 12:37 AM, David wrote:
Hello:
I expect the patches finally are ok.
Hello and sorry for delay.
Your patch is not OK.
Biggest fault is that it does not increase .num_device_descs count. It
will break some other device. Don't try to add new devices between
existing devices. If you were added it correctly behind existing devices
you must already find out something is broken since device was not detected.
See that example how to add device:
http://kerneltrap.org/mailarchive/git-commits-head/2010/5/20/34349/thread
Good place, for example, to add your device is behind: AverMedia AVerTV
Volar Black HD (A850) device.
And here is example how to map remote:
http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg09016.html
Antti
This patches add
Signed-off-by: Emilio David Diaus Lopezreality...@yahoo.es
-
-- ./drivers/media/dvb/dvb-usb/af9015.c.orig2011-06-21
12:39:44.0 +0200
+++ ./drivers/media/dvb/dvb-usb/af9015.c2011-06-22
12:05:28.0 +0200
@@ -749,6 +749,8 @@ static const struct af9015_rc_setup af90
RC_MAP_AZUREWAVE_AD_TU700 },
{ (USB_VID_MSI_2 16) + USB_PID_MSI_DIGI_VOX_MINI_III,
RC_MAP_MSI_DIGIVOX_III },
+ { (USB_VID_KWORLD_2 16) + USB_PID_SVEON_STV22,
+ RC_MAP_MSI_DIGIVOX_III },
{ (USB_VID_LEADTEK 16) + USB_PID_WINFAST_DTV_DONGLE_GOLD,
RC_MAP_LEADTEK_Y04G0051 },
{ (USB_VID_AVERMEDIA 16) + USB_PID_AVERMEDIA_VOLAR_X,
@@ -1309,6 +1311,7 @@ static struct usb_device_id af9015_usb_t
USB_PID_TERRATEC_CINERGY_T_STICK_DUAL_RC)},
/* 35 */{USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_A850T)},
{USB_DEVICE(USB_VID_GTEK, USB_PID_TINYTWIN_3)},
+ {USB_DEVICE(USB_VID_KWORLD_2, USB_PID_SVEON_STV22)},
{0},
};
MODULE_DEVICE_TABLE(usb, af9015_usb_table);
@@ -1649,6 +1652,11 @@ static struct dvb_usb_device_properties
.warm_ids = {NULL},
},
{
+ .name = Sveon STV22 Dual USB DVB-T
Tuner HDTV ,
+ .cold_ids = {af9015_usb_table[37], NULL},
+ .warm_ids = {NULL},
+ },
+ {
.name = Leadtek WinFast DTV2000DS,
.cold_ids = {af9015_usb_table[29], NULL},
.warm_ids = {NULL},
--
--- ./drivers/media/dvb/dvb-usb/dvb-usb-ids.h.orig 2011-06-21
12:39:45.0 +0200
+++ ./drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2011-06-18
11:48:22.0 +0200
@@ -128,6 +128,7 @@
#define USB_PID_INTEL_CE9500 0x9500
#define USB_PID_KWORLD_399U0xe399
#define USB_PID_KWORLD_399U_2 0xe400
+#define USB_PID_SVEON_STV220xe401
#define USB_PID_KWORLD_395U0xe396
#define USB_PID_KWORLD_395U_2 0xe39b
#define USB_PID_KWORLD_395U_3 0xe395
1.1
---
Thanks for your time
goodbye
Emilio David Diaus López
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
