Re: [PATCH] gspca_cpia1: Add lamp control for Intel Play QX3 microscope
Hi,
On 09/03/2010 03:09 AM, Andy Walls wrote:
# HG changeset patch
# User Andy Wallsawa...@radix.net
# Date 1283475832 14400
# Node ID 0d251a2976b46e11cc817207de191896718b93a3
# Parent a4c762698bcb138982b81cf59e5bc4b7155866a9
gspca_cpia1: Add lamp cotrol for Intel Play QX3 microscope
From: Andy Wallsawa...@md.metrocast.net
Add a v4l2 control to get the lamp control code working for the Intel Play
QX3 microscope. My daughter in middle school thought it was cool, and is now
examining the grossest specimens she can find.
Hehe, cool I'm very happy to hear the cpia1 driver actually being used in a
productive manner, that shows it is worth all the time and effort I've put
into
cleaning up / rewriting old v4l1 drivers :)
About the patch: first of all thanks. wrt lamps versus lights I'm indifferent.
The only thing I've notices is that you've made the controls instand apply.
Normally
controls setting changes when not streaming are just remembered and then applied
when the stream is initialized.
However your code sends the lamp settings to the device as soon as they are
changed, and does not send them on sd_start. The sending as soon as changes
makes sense. But did you check that this actually works, iow did you play with
the lamps control while not streaming ? and then tried to stream and see if
the settings stuck.
Also the not sending at sd_start, nor sd_init means that you assume that the
defaults in the driver (both lamps off) ar the same as of the device as you
never force that the device - driver settings are synced on driver load
or stream start. This may not be the case when resuming from suspend or
the driver is rmmod-ed insmod-ed. So assuming that the instant apply
of this control does not cause issues, you should add a call to
command_setlamps(gspca_dev); at the end of sd_init.
Regards,
Hans
Priority: normal
Signed-off-by: Andy Wallsawa...@md.metrocast.net
diff -r a4c762698bcb -r 0d251a2976b4 linux/drivers/media/video/gspca/cpia1.c
--- a/linux/drivers/media/video/gspca/cpia1.c Wed Aug 25 16:13:54 2010 -0300
+++ b/linux/drivers/media/video/gspca/cpia1.c Thu Sep 02 21:03:52 2010 -0400
@@ -333,8 +333,8 @@
} format;
struct {/* Intel QX3 specific data */
u8 qx3_detected;/* a QX3 is present */
- u8 toplight;/* top light lit , R/W */
- u8 bottomlight; /* bottom light lit, R/W */
+ u8 toplamp; /* top lamp lit , R/W */
+ u8 bottomlamp; /* bottom lamp lit, R/W */
u8 button; /* snapshot button pressed (R/O) */
u8 cradled; /* microscope is in cradle (R/O) */
} qx3;
@@ -373,6 +373,8 @@
static int sd_getfreq(struct gspca_dev *gspca_dev, __s32 *val);
static int sd_setcomptarget(struct gspca_dev *gspca_dev, __s32 val);
static int sd_getcomptarget(struct gspca_dev *gspca_dev, __s32 *val);
+static int sd_setlamps(struct gspca_dev *gspca_dev, __s32 val);
+static int sd_getlamps(struct gspca_dev *gspca_dev, __s32 *val);
static const struct ctrl sd_ctrls[] = {
{
@@ -447,6 +449,20 @@
.set = sd_setcomptarget,
.get = sd_getcomptarget,
},
+ {
+ {
+#define V4L2_CID_LAMPS (V4L2_CID_PRIVATE_BASE+1)
+ .id = V4L2_CID_LAMPS,
+ .type= V4L2_CTRL_TYPE_MENU,
+ .name= Lamps,
+ .minimum = 0,
+ .maximum = 3,
+ .step= 1,
+ .default_value = 0,
+ },
+ .set = sd_setlamps,
+ .get = sd_getlamps,
+ },
};
static const struct v4l2_pix_format mode[] = {
@@ -766,8 +782,8 @@
params-compressionTarget.targetQ = 5; /* From windows driver */
params-qx3.qx3_detected = 0;
- params-qx3.toplight = 0;
- params-qx3.bottomlight = 0;
+ params-qx3.toplamp = 0;
+ params-qx3.bottomlamp = 0;
params-qx3.button = 0;
params-qx3.cradled = 0;
}
@@ -1059,17 +1075,16 @@
0, sd-params.streamStartLine, 0, 0);
}
-#if 0 /* Currently unused */ /* keep */
-static int command_setlights(struct gspca_dev *gspca_dev)
+static int command_setlamps(struct gspca_dev *gspca_dev)
{
struct sd *sd = (struct sd *) gspca_dev;
- int ret, p1, p2;
+ int ret, p;
if (!sd-params.qx3.qx3_detected)
return 0;
- p1 = (sd-params.qx3.bottomlight == 0) 1;
- p2 = (sd-params.qx3.toplight == 0) 3;
+ p = (sd-params.qx3.toplamp== 0) ? 0x8 : 0;
+ p |= (sd-params.qx3.bottomlamp == 0) ? 0x2 : 0;
ret = do_command(gspca_dev, CPIA_COMMAND_WriteVCReg,
0x90, 0x8F, 0x50, 0);
@@ -1077,9 +1092,8 @@
return ret;
return do_command(gspca_dev,
Re: [PATCH] LED control
Hans == Hans de Goede hdego...@redhat.com writes: Hi, + entryconstantV4L2_CID_LEDS/constant/entry + entryinteger/entry + entrySwitch on or off the LED(s) or illuminator(s) of the device. + The control type and values depend on the driver and may be either + a single boolean (0: off, 1:on) or the index in a menu type./entry + /row Hans I think that using one control for both status leds (which is Hans what we are usually talking about) and illuminator(s) is a bad Hans idea. I'm fine with standardizing these, but can we please have 2 Hans CID's one for status lights and one for the led. Esp, as I can Hans easily see us supporting a microscope in the future where the Hans microscope itself or other devices with the same bridge will have Hans a status led, so then we will need 2 separate controls anyways. Why does this need to go through the v4l2 api and not just use the standard LED (sysfs) api in the first place? -- Bye, Peter Korsgaard -- 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] LED control
Hi, On 09/05/2010 10:04 AM, Peter Korsgaard wrote: Hans == Hans de Goedehdego...@redhat.com writes: Hi, + entryconstantV4L2_CID_LEDS/constant/entry + entryinteger/entry + entrySwitch on or off the LED(s) or illuminator(s) of the device. + The control type and values depend on the driver and may be either + a single boolean (0: off, 1:on) or the index in a menu type./entry + /row Hans I think that using one control for both status leds (which is Hans what we are usually talking about) and illuminator(s) is a bad Hans idea. I'm fine with standardizing these, but can we please have 2 Hans CID's one for status lights and one for the led. Esp, as I can Hans easily see us supporting a microscope in the future where the Hans microscope itself or other devices with the same bridge will have Hans a status led, so then we will need 2 separate controls anyways. Why does this need to go through the v4l2 api and not just use the standard LED (sysfs) api in the first place? Quoting from the reply by Jean-Francois Moine to a patch adding illuminator control support to the cpia1 driver where this proposal is a result of: ### As many gspca users are waiting for a light/LED/illuminator/lamp control, I tried to define a standard one in March 2009: http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/3095 A second, but more restrictive, attempt was done by Németh Márton in February 2010: http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/16705 The main objection to that proposals was that the sysfs LED interface should be used instead: http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/3114 A patch in this way was done by Németh Márton in February 2010: http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/16670 but it was rather complex, and there was no consensus http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/17111 ### So using the sysfs interface for this is non trivial. Most cameras don't offer any hardware dimming / blinking features, but we do want to do an auto setting where the led goes on when streaming and goes off again when not streaming. So the sysfs interface is not a good match to what we need. A more important argument IMHO however is that the LED control is just one element of many things one can control on (some) webcams, things like focus, pan and tilt for the more fancy ones also come into play. Not to mention contrast, brightness etc. settings. Currently we have one central API for this which is the v4l2 ctrl API, and we have several apps which dynamically build up a UI for this depending on the ctrls advertised by the device. Adding a LED ctrl to the v4l2 API will make this automatically show up in these apps and give the user one central place to control everything related to the camera. Where as using the led sysfs API would mean that the led control will basically stay invisible to the end user unless we start patching all apps to also use support this API, requiring all v4l2 apps to grow code to support a whole new api just to turn on / off a led does not seem like a good idea to me. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gspca_cpia1: Add lamp control for Intel Play QX3 microscope
Hi,
p.s. (forgot to mention this in my previous mail)
On 09/03/2010 03:09 AM, Andy Walls wrote:
snip
@@ -447,6 +449,20 @@
.set = sd_setcomptarget,
.get = sd_getcomptarget,
},
+ {
+ {
+#define V4L2_CID_LAMPS (V4L2_CID_PRIVATE_BASE+1)
+ .id = V4L2_CID_LAMPS,
+ .type= V4L2_CTRL_TYPE_MENU,
+ .name= Lamps,
+ .minimum = 0,
+ .maximum = 3,
+ .step= 1,
+ .default_value = 0,
+ },
+ .set = sd_setlamps,
+ .get = sd_getlamps,
+ },
};
static const struct v4l2_pix_format mode[] = {
We only want this control to be available on the qx3 and not on
all cpia1 devices, so you need to add something like the following to
sd_config:
if (!(id-idVendor == 0x0813 id-idProduct == 0x0001))
gspca_dev-ctrl_dis = 1 LAMPS_IDX;
Where LAMPS_IDX is a define giving the index of V4L2_CID_LAMPS in the
sd_ctrls array, see the ov519 gspca driver for example.
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: ibmcam (xrilink_cit) and konica webcam driver porting to gspca update
Hi, On 08/31/2010 11:43 PM, David Ellingsworth wrote: Hans, I haven't had any success with this driver as of yet. My camera is shown here: http://www.amazon.com/IBM-Net-Camera-Pro-camera/dp/B0009MH25U The part number listed on the bottom is 22P5086. It's also labeled as being an IBM Net Camera Pro. Ah ok, so you have the same one as I have, that model was never supported by the old ibmcam driver, so I take it you never had it working with the old ibmcam driver ? When I plug the camera in, it is detected by the driver but it does not seem to function in this mode. Every attempt to obtain video from it using qv4l2 results in a black or green image. If I use the ibm_netcam_pro module option Given that is the same camera as I have using the ibm_netcam_pro module option is definitely the right thing to do. I noticed in your lsusb -v output that you're doing this from within vmware? I think that is the cause of things not working. This camera will not even work when connected through a real hub, let alone through a virtual one. The only way this camera works for me is when it is connected to a usb port directly on the motherboard, running Linux directly on the hardware, can you please try 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: [PATCH] LED control
On Sun, 05 Sep 2010 09:56:54 +0200 Hans de Goede hdego...@redhat.com wrote: I think that using one control for both status leds (which is what we are usually talking about) and illuminator(s) is a bad idea. I'm fine with standardizing these, but can we please have 2 CID's one for status lights and one for the led. Esp, as I can easily see us supporting a microscope in the future where the microscope itself or other devices with the same bridge will have a status led, so then we will need 2 separate controls anyways. Hi Hans, I was not thinking about the status light (I do not see any other usage for it), but well about illuminators which I saw only in microscopes. So, which is the better name? V4L2_CID_LAMPS? V4L2_CID_ILLUMINATORS? Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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] LED control
Hi, On 09/05/2010 10:56 AM, Jean-Francois Moine wrote: On Sun, 05 Sep 2010 09:56:54 +0200 Hans de Goedehdego...@redhat.com wrote: I think that using one control for both status leds (which is what we are usually talking about) and illuminator(s) is a bad idea. I'm fine with standardizing these, but can we please have 2 CID's one for status lights and one for the led. Esp, as I can easily see us supporting a microscope in the future where the microscope itself or other devices with the same bridge will have a status led, so then we will need 2 separate controls anyways. Hi Hans, I was not thinking about the status light (I do not see any other usage for it), but well about illuminators which I saw only in microscopes. Ah, ok thanks for clarifying. For some more on this see p.s. below. So, which is the better name? V4L2_CID_LAMPS? V4L2_CID_ILLUMINATORS? I think that V4L2_CID_ILLUMINATORS together with a comment in the .h and explanation in the spec that this specifically applies to microscopes would be good. Regards, Hans p.s. I think it would be good to have a V4L2_CID_STATUS_LED too. In many drivers we are explicitly controlling the led by register writes. Some people may very well prefer the led to always be off. I know that uvc logitech cameras have controls for the status led through the extended uvc controls. Once we have a standardized LED control, we can move the logitech uvc cams over from using their own private one to this one. Once this is in place I would like to build some framework in to gspca for supporting this control in gspca (the control would be handled by the core, and sub drivers would have an sd_set_led function). While at it could you write a proposal / patch for adding this control to the spec as well ? -- 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
some question about
dear all: I saw there is a Audio Devices Rev. 2.0 Spec and Adopters Agreement on the usb org. But so far my device can bought are FS instead of HS. Since I need HS audio device which list in Audio Devices Rev. 2.0 Spec and Adopters Agreement to verification the performance of my host. I try very hard to find some possible devices with linux support on the net. per your experience, are below 2 meet Audio Devices Rev. 2.0 Spec and Adopters Agreement? WinTV-HVR-1950 high performance USB TV tuner WinTV-HVR-950Q for laptop and notebooks if they are not would you please tell me where and what device meet the spec requirement and also supported by linux. appreciate your help, miloody -- 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: some question about
On Sun, Sep 5, 2010 at 11:36 AM, loody milo...@gmail.com wrote: WinTV-HVR-1950 high performance USB TV tuner WinTV-HVR-950Q for laptop and notebooks Both these devices are supported under Linux, and in fact are unlikely to work properly with only Full Speed USB. At least the 950q definitely requires High speed (I put a check in there to specifically not load the driver otherwise). 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: some question about
On Sun, Sep 5, 2010 at 11:48 AM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Sun, Sep 5, 2010 at 11:36 AM, loody milo...@gmail.com wrote: WinTV-HVR-1950 high performance USB TV tuner WinTV-HVR-950Q for laptop and notebooks Both these devices are supported under Linux, and in fact are unlikely to work properly with only Full Speed USB. At least the 950q definitely requires High speed (I put a check in there to specifically not load the driver otherwise). I perhaps misread your original email. While the 950q does present itself as a USB audio class device, the 1950 does not. It only provides MPEG encoded output (containing both the audio and video), and is not a USB audio class device. So while both these devices will work under Linux on a high speed interface, if you specifically require the device to identify itself as a USB audio class device, only the 950q does this. 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: [PATCH/RFCv4 0/6] The Contiguous Memory Allocator framework
On Fri, Sep 03, 2010 at 07:29:43PM +0900, KAMEZAWA Hiroyuki wrote:
On Thu, 2 Sep 2010 17:54:24 +0900
KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com wrote:
Here is a rough code for this.
here is a _tested_ one.
If I tested correctly, I allocated 40MB of contigous pages by the new
funciton.
I'm grad this can be some hints for people.
Great!
I didn't look into the detail but the concept seems to be good.
If someone doesn't need complex intelligent(ex, shared, private, [first|best]
fit, buddy),
this is enough for that. So I think this will be good regardless of CMA.
I will look into this more detaily and think idea to improve.
Thanks, Kame. :)
Thanks,
-Kame
==
From: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
This patch as a memory allocator for contiguous memory larger than MAX_ORDER.
alloc_contig_pages(hint, size, list);
This function allocates 'size' of contigoues pages, whose physical address
is higher than 'hint'. size is specicied in byte unit.
size is byte, hint is pfn?
Allocated pages are all linked into the list and all of their page_count()
are set to 1. Return value is the top page.
free_contig_pages(list)
returns all pages in the list.
This patch does
- find an area which can be ISOLATED.
- migrate remaining pages in the area.
Migrate from there to where?
- steal chunk of pages from allocator.
Limitation is:
- retruned pages will be aligend to MAX_ORDER.
- returned length of page will be aligned to MAX_ORDER.
(so, the caller may have to return tails of pages by itself.)
What do you mean tail?
- may allocate contiguous pages which overlap node/zones.
Hmm.. Do we really need this?
This is fully experimental and written as example.
(Maybe need more patches to make this complete.)
Yes. But first impression of this patch is good to me.
This patch moves some amount of codes from memory_hotplug.c to
page_isolation.c and based on page-offline technique used by
memory_hotplug.c
Signed-off-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
---
include/linux/page-isolation.h | 10 +
mm/memory_hotplug.c| 84 --
mm/page_alloc.c| 32 +
mm/page_isolation.c| 244
+
4 files changed, 287 insertions(+), 83 deletions(-)
Index: mmotm-0827/mm/page_isolation.c
===
--- mmotm-0827.orig/mm/page_isolation.c
+++ mmotm-0827/mm/page_isolation.c
@@ -3,8 +3,11 @@
*/
#include linux/mm.h
+#include linux/swap.h
#include linux/page-isolation.h
#include linux/pageblock-flags.h
+#include linux/mm_inline.h
+#include linux/migrate.h
#include internal.h
static inline struct page *
@@ -140,3 +143,244 @@ int test_pages_isolated(unsigned long st
spin_unlock_irqrestore(zone-lock, flags);
return ret ? 0 : -EBUSY;
}
+
+#define CONTIG_ALLOC_MIGRATION_RETRY (5)
+
+/*
+ * Scanning pfn is much easier than scanning lru list.
+ * Scan pfn from start to end and Find LRU page.
+ */
+unsigned long scan_lru_pages(unsigned long start, unsigned long end)
+{
+ unsigned long pfn;
+ struct page *page;
+ for (pfn = start; pfn end; pfn++) {
+ if (pfn_valid(pfn)) {
+ page = pfn_to_page(pfn);
+ if (PageLRU(page))
+ return pfn;
+ }
+ }
+ return 0;
+}
+
+/* Migrate all LRU pages in the range to somewhere else */
+static struct page *
+hotremove_migrate_alloc(struct page *page, unsigned long private, int **x)
+{
+ /* This should be improved!! */
Yeb.
+ return alloc_page(GFP_HIGHUSER_MOVABLE);
+}
snip
+struct page *alloc_contig_pages(unsigned long long hint,
+ unsigned long size, struct list_head *list)
+{
+ unsigned long base, found, end, pages, start;
+ struct page *ret = NULL;
+ int nid, retry;
+
+ if (hint)
+ hint = ALIGN(hint, MAX_ORDER_NR_PAGES);
+ /* request size should be aligned to pageblock */
+ size = PAGE_SHIFT;
+ pages = ALIGN(size, MAX_ORDER_NR_PAGES);
+ found = 0;
+retry:
+ for_each_node_state(nid, N_HIGH_MEMORY) {
+ unsigned long node_end;
+ pg_data_t *node = NODE_DATA(nid);
+
+ node_end = node-node_start_pfn + node-node_spanned_pages;
+ /* does this node have proper range of memory ? */
+ if (node_end hint + pages)
+ continue;
+ base = hint;
+ if (base node-node_start_pfn)
+ base = node-node_start_pfn;
+
+ base = ALIGN(base, MAX_ORDER_NR_PAGES);
+ found = 0;
+ end = node_end ~(MAX_ORDER_NR_PAGES -1);
+ /* Maybe we can use this Node */
+ if (base + pages end)
+ found
Re: some question about
hi: 2010/9/5 Devin Heitmueller dheitmuel...@kernellabs.com: On Sun, Sep 5, 2010 at 11:48 AM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Sun, Sep 5, 2010 at 11:36 AM, loody milo...@gmail.com wrote: WinTV-HVR-1950 high performance USB TV tuner WinTV-HVR-950Q for laptop and notebooks Both these devices are supported under Linux, and in fact are unlikely to work properly with only Full Speed USB. At least the 950q definitely requires High speed (I put a check in there to specifically not load the driver otherwise). I perhaps misread your original email. While the 950q does present itself as a USB audio class device, the 1950 does not. It only provides MPEG encoded output (containing both the audio and video), and is not a USB audio class device. So while both these devices will work under Linux on a high speed interface, if you specifically require the device to identify itself as a USB audio class device, only the 950q does this. Devin would you mind to send me the device descriptors for me? I want to check whether the input/output unit and audio/video format does meet the spec. BTW, will the device support mp3 output? since the spec define mp3 as one of input/output format. that means if I put the raw data of mp3 to that device, it should play/record well. appreciate your help, miloody -- 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: some question about
On Sun, Sep 5, 2010 at 12:06 PM, loody milo...@gmail.com wrote: hi: 2010/9/5 Devin Heitmueller dheitmuel...@kernellabs.com: On Sun, Sep 5, 2010 at 11:48 AM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Sun, Sep 5, 2010 at 11:36 AM, loody milo...@gmail.com wrote: WinTV-HVR-1950 high performance USB TV tuner WinTV-HVR-950Q for laptop and notebooks Both these devices are supported under Linux, and in fact are unlikely to work properly with only Full Speed USB. At least the 950q definitely requires High speed (I put a check in there to specifically not load the driver otherwise). I perhaps misread your original email. While the 950q does present itself as a USB audio class device, the 1950 does not. It only provides MPEG encoded output (containing both the audio and video), and is not a USB audio class device. So while both these devices will work under Linux on a high speed interface, if you specifically require the device to identify itself as a USB audio class device, only the 950q does this. Devin would you mind to send me the device descriptors for me? I want to check whether the input/output unit and audio/video format does meet the spec. BTW, will the device support mp3 output? since the spec define mp3 as one of input/output format. that means if I put the raw data of mp3 to that device, it should play/record well. The device descriptors can be found here: http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-950Q#Identification The device does not support MP3 output (virtually no devices do as far as I know). It only provides raw 16-bit two channel PCM. The video format would not be in the spec you mentioned. It does work as a standard V4L2 device though, providing raw YUYV video frames. Perhaps if I better understood your intended application, I might be able to give better advice. 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: Kernel hangs after suspend to ram
Can you help me, please? Andrea Amorosi Il 01/09/2010 22:32, Andrea Amorosi ha scritto: Hi to all! I'm trying to use my Dikom DK-300 usb dvb-t device connected to an old laptop used as media player. The device works well but if I suspend the pc to ram (S3) when the Dikom usb stick is plugged in, the system hangs during the resume phase. So I've tried to create two scripts. The first one removes the driver before sleeping (the script is in the /etc/acpi/suspend.d directory) and the second one reloads it during the resume phase (this script is in /etc/acpi/resume.d directory). I've also inserted in the scripts some logs and it seems that the driver is correctly removed before the suspension, but then the pc hangs when resuming. Do you have some sugestion on how to resolve? Thank you, Andrea Amorosi -- 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 11/11] mt9m111: make use of testpattern
Guennadi Liakhovetski g.liakhovet...@gmx.de writes: Yes, but this has another disadvantage - if you do not use s_register / g_register, maybe you just have CONFIG_VIDEO_ADV_DEBUG off, then, once you load the module with the testpattern parameter, you cannot switch using testpatterns off again (without a reboot or a power cycle). With the original version you can load the driver with the parameter set, then unload it, load it without the parameter and testpattern would be cleared. In general, I think, using direct register access is discouraged, especially if there's a way to set the same functionality using driver's supported interfaces. I agree. If there is a way without debug registers, let's use it. Hm, if I'm not mistaken, it has once been mentioned, that these test-patterns can be nicely implemented using the S_INPUT ioctl(). Am I right? How about that? But we'd need a confirmation for that, I'm not 100% sure. I can't remember that. But if there is a standard ioctl (as seems to show videodev2.h), and that its use could mean camera's input is a testpattern or camera input is the normal optical flow, then we should use it. If not, the old way with debug registers is the only alternative I see without having to unload/reload the module (if it's a module and not statically embedded in the kernel). Cheers. -- Robert -- 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
[Q] camera test pattern as an alternative input?
In a currently running mt9m111 thread we're discussing ways to activate one of camera's (sensor's) test patterns. A module parameter has been proposed, earlier this has been done by just using the infamous VIDIOC_DBG_S_REGISTER. But then it occurred to me, that there has been previously such a discussion and it has been proposed to assign alternative inputs to various test patterns. So, you just issue a VIDIOC_S_INPUT to switch between the actual video input and one of test patterns. Can anyone else remember such a discussion or maybe just knows examples of such drivers? A couple of grep attempts haven't revealed anything. Is this a good idea? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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] gspca_cpia1: Add lamp control for Intel Play QX3 microscope
On Sun, 2010-09-05 at 10:03 +0200, Hans de Goede wrote:
Hi,
On 09/03/2010 03:09 AM, Andy Walls wrote:
# HG changeset patch
# User Andy Wallsawa...@radix.net
# Date 1283475832 14400
# Node ID 0d251a2976b46e11cc817207de191896718b93a3
# Parent a4c762698bcb138982b81cf59e5bc4b7155866a9
gspca_cpia1: Add lamp cotrol for Intel Play QX3 microscope
From: Andy Wallsawa...@md.metrocast.net
Add a v4l2 control to get the lamp control code working for the Intel Play
QX3 microscope. My daughter in middle school thought it was cool, and is
now
examining the grossest specimens she can find.
Hehe, cool I'm very happy to hear the cpia1 driver actually being used in a
productive manner, that shows it is worth all the time and effort I've put
into
cleaning up / rewriting old v4l1 drivers :)
Yes, thank you.
Now I have 10x, 60x, and 200x images of pencils, hair, dead skin,
fingernails, and insects. As soon as my kids figure out the microscope
body still works when removed from the base, I'm sure to have 10x, 60x,
and 200x images of eyes, mouths, ears, and nostrils... :P
About the patch: first of all thanks. wrt lamps versus lights I'm indifferent.
I don't care much either. Illuminator appears to be the correct term
for microscopy. The cpia2 (QX5) and gspca_cpia1 (QX3) drivers should
probably try to match on any user visible terminology such as the string
presented as the name of the control. The cpia2 driver has presented
the user with a Lights control.
I don't know much about photography or film, so I don't know what
artificial light sources that illuminate subject matter are called in
those fields.
The only thing I've notices is that you've made the controls instand apply.
Normally
controls setting changes when not streaming are just remembered and then
applied
when the stream is initialized.
However your code sends the lamp settings to the device as soon as they are
changed, and does not send them on sd_start. The sending as soon as changes
makes sense. But did you check that this actually works,
After a few minutes of playing with the microscope one realizes that one
must be able to change the illumination on-the-fly. Trying to get the
best image possible from a microscope is easiest when one can tweak as
much as possible in real-time: lighting, positioning, focus, etc.
Changing the illuminator settings does work during a capture, with no
apparent ill effects. Then again, one is usually starting from bad
illumination conditions searching for good illumination conditions, so
who cares about glitching a frame that doesn't look good.
iow did you play with
the lamps control while not streaming ? and then tried to stream and see if
the settings stuck.
Yes they do. 'v4l2-ctl -c lamps=n' was used to manipulate the control,
Cheese was use for streaming.
The lamps will stay in the last state commanded, regardless of when
streaming is started and stopped.
Also the not sending at sd_start, nor sd_init means that you assume that the
defaults in the driver (both lamps off) ar the same as of the device as you
never force that the device - driver settings are synced on driver load
or stream start. This may not be the case when resuming from suspend or
the driver is rmmod-ed insmod-ed.
1. manual `modprobe -r` followed by `modprobe` is not a case that the
normal end user cares about.
2. when this USB device is unplugged and plugged back in, its lights are
always off and the driver, as you note, always assumes they are off as
well.
3. suspend/resume: well, yes that case probably matters. :)
So assuming that the instant apply
of this control does not cause issues, you should add a call to
command_setlamps(gspca_dev); at the end of sd_init.
Easy enough.
Regards,
Andy
Regards,
Hans
Priority: normal
Signed-off-by: Andy Wallsawa...@md.metrocast.net
diff -r a4c762698bcb -r 0d251a2976b4 linux/drivers/media/video/gspca/cpia1.c
--- a/linux/drivers/media/video/gspca/cpia1.c Wed Aug 25 16:13:54
2010 -0300
+++ b/linux/drivers/media/video/gspca/cpia1.c Thu Sep 02 21:03:52
2010 -0400
@@ -333,8 +333,8 @@
} format;
struct {/* Intel QX3 specific data */
u8 qx3_detected;/* a QX3 is present */
- u8 toplight;/* top light lit , R/W */
- u8 bottomlight; /* bottom light lit, R/W */
+ u8 toplamp; /* top lamp lit , R/W */
+ u8 bottomlamp; /* bottom lamp lit, R/W */
u8 button; /* snapshot button pressed (R/O) */
u8 cradled; /* microscope is in cradle (R/O) */
} qx3;
@@ -373,6 +373,8 @@
static int sd_getfreq(struct gspca_dev *gspca_dev, __s32 *val);
static int sd_setcomptarget(struct gspca_dev *gspca_dev, __s32 val);
static int sd_getcomptarget(struct gspca_dev *gspca_dev, __s32 *val);
+static int
Re: [PATCH] LED control
On Sun, 2010-09-05 at 10:04 +0200, Peter Korsgaard wrote: Hans == Hans de Goede hdego...@redhat.com writes: Hi, + entryconstantV4L2_CID_LEDS/constant/entry + entryinteger/entry + entrySwitch on or off the LED(s) or illuminator(s) of the device. + The control type and values depend on the driver and may be either + a single boolean (0: off, 1:on) or the index in a menu type./entry + /row Hans I think that using one control for both status leds (which is Hans what we are usually talking about) and illuminator(s) is a bad Hans idea. I'm fine with standardizing these, but can we please have 2 Hans CID's one for status lights and one for the led. Esp, as I can Hans easily see us supporting a microscope in the future where the Hans microscope itself or other devices with the same bridge will have Hans a status led, so then we will need 2 separate controls anyways. Why does this need to go through the v4l2 api and not just use the standard LED (sysfs) api in the first place? It puts a larger burden on the application programmer. Video capture applications are already programmed to provide controls to the user using the V4L2 API for manipulating all aspects of the incoming video image. Using something different for turning on subject illumination would be an exceptional case. The V4L2 control API also allows applications to be written such that they need no apriori knowledge about a video driver's controls, and yet can still present all driver supported controls to the user for manipulation. The VIDIOC_QUERYCTL interface allows applications to discover controls and metadata to build a UI. Two applications that illustrate the point are 'qv4l2' (a Qt control GUI) and 'v4l2-ctl' (a CLI control UI) found here: http://git.linuxtv.org/v4l-utils.git?a=tree;f=utils;h=8d37309cc3b896d11fc77d9f275f82f02ee9c03d;hb=HEAD As an example, here is the output of v4l2-ctl -L for my QX3 microscope: $ v4l2-ctl -d /dev/video1 -L brightness (int) : min=0 max=100 step=1 default=50 value=50 contrast (int) : min=0 max=96 step=8 default=48 value=48 saturation (int) : min=0 max=100 step=1 default=50 value=50 light_frequency_filter (menu) : min=0 max=2 default=1 value=1 0: NoFliker 1: 50 Hz 2: 60 Hz compression_target (menu) : min=0 max=1 default=0 value=0 0: Quality 1: Framerate lamps (menu) : min=0 max=3 default=0 value=0 0: Off 1: Bottom 2: Top 3: Both And here is the output for my PVR-350 TV capture card: $ v4l2-ctl -d /dev/video2 -L User Controls brightness (int) : min=0 max=255 step=1 default=128 value=128 flags=slider contrast (int) : min=0 max=127 step=1 default=64 value=64 flags=slider saturation (int) : min=0 max=127 step=1 default=64 value=64 flags=slider hue (int) : min=-128 max=127 step=1 default=0 value=0 flags=slider volume (int) : min=0 max=65535 step=655 default=58880 value=58880 flags=slider mute (bool) : default=0 value=0 MPEG Encoder Controls stream_type (menu) : min=0 max=5 default=0 value=0 flags=update 0: MPEG-2 Program Stream 2: MPEG-1 System Stream 3: MPEG-2 DVD-compatible Stream 4: MPEG-1 VCD-compatible Stream 5: MPEG-2 SVCD-compatible Stream stream_vbi_format (menu) : min=0 max=1 default=0 value=0 0: No VBI 1: Private packet, IVTV format audio_sampling_frequency (menu) : min=0 max=2 default=1 value=1 0: 44.1 kHz 1: 48 kHz 2: 32 kHz audio_encoding (menu) : min=1 max=1 default=1 value=1 flags=update 1: MPEG-1/2 Layer II audio_layer_ii_bitrate (menu) : min=9 max=13 default=10 value=10 9: 192 kbps 10: 224 kbps 11: 256 kbps 12: 320 kbps 13: 384 kbps audio_stereo_mode (menu) : min=0 max=3 default=0 value=0 flags=update 0: Stereo 1: Joint Stereo 2: Dual 3: Mono audio_stereo_mode_extension
Re: [PATCH] gspca_cpia1: Add lamp control for Intel Play QX3 microscope
On Sun, 2010-09-05 at 10:24 +0200, Hans de Goede wrote:
Hi,
p.s. (forgot to mention this in my previous mail)
On 09/03/2010 03:09 AM, Andy Walls wrote:
snip
@@ -447,6 +449,20 @@
.set = sd_setcomptarget,
.get = sd_getcomptarget,
},
+ {
+ {
+#define V4L2_CID_LAMPS (V4L2_CID_PRIVATE_BASE+1)
+ .id = V4L2_CID_LAMPS,
+ .type= V4L2_CTRL_TYPE_MENU,
+ .name= Lamps,
+ .minimum = 0,
+ .maximum = 3,
+ .step= 1,
+ .default_value = 0,
+ },
+ .set = sd_setlamps,
+ .get = sd_getlamps,
+ },
};
static const struct v4l2_pix_format mode[] = {
We only want this control to be available on the qx3 and not on
all cpia1 devices,
Yes, I though about that, but couldn't think up a clean way of doing it
in the short amount of time I had available. I did know that the
control was essentially a NoOp, so I wasn't too concerned at the time.
so you need to add something like the following to
sd_config:
if (!(id-idVendor == 0x0813 id-idProduct == 0x0001))
gspca_dev-ctrl_dis = 1 LAMPS_IDX;
Where LAMPS_IDX is a define giving the index of V4L2_CID_LAMPS in the
sd_ctrls array, see the ov519 gspca driver for example.
Thanks for the pointer, I'll have a look.
Regards,
Andy
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] LED control
On Sun, 2010-09-05 at 15:54 +0200, Hans de Goede wrote: Hi, On 09/05/2010 10:56 AM, Jean-Francois Moine wrote: On Sun, 05 Sep 2010 09:56:54 +0200 Hans de Goedehdego...@redhat.com wrote: I think that using one control for both status leds (which is what we are usually talking about) and illuminator(s) is a bad idea. I'm fine with standardizing these, but can we please have 2 CID's one for status lights and one for the led. Esp, as I can easily see us supporting a microscope in the future where the microscope itself or other devices with the same bridge will have a status led, so then we will need 2 separate controls anyways. Hi Hans, I was not thinking about the status light (I do not see any other usage for it), but well about illuminators which I saw only in microscopes. Ah, ok thanks for clarifying. For some more on this see p.s. below. So, which is the better name? V4L2_CID_LAMPS? V4L2_CID_ILLUMINATORS? I think that V4L2_CID_ILLUMINATORS together with a comment in the .h and explanation in the spec that this specifically applies to microscopes would be good. I concur with ILLUMINATORS. The word makes it very clear the control is about actively putting light on a subject. A quick Goggle search shows that the term 'illuminator appears to apply to photography and IR cameras as well. Regards, Hans p.s. I think it would be good to have a V4L2_CID_STATUS_LED too. In many drivers we are explicitly controlling the led by register writes. Some people may very well prefer the led to always be off. I know that uvc logitech cameras have controls for the status led through the extended uvc controls. Once we have a standardized LED control, we can move the logitech uvc cams over from using their own private one to this one. I saw two use cases mentioned for status LEDs: 1. always off 2. driver automatically controls the LEDs. Can't that choice be handled with a module option, is there a case where one needs more control? Regards, Andy Once this is in place I would like to build some framework in to gspca for supporting this control in gspca (the control would be handled by the core, and sub drivers would have an sd_set_led function). While at it could you write a proposal / patch for adding this control to the spec as well ? -- 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: [Q] camera test pattern as an alternative input?
On Sun, 2010-09-05 at 19:09 +0200, Guennadi Liakhovetski wrote: In a currently running mt9m111 thread we're discussing ways to activate one of camera's (sensor's) test patterns. A module parameter has been proposed, earlier this has been done by just using the infamous VIDIOC_DBG_S_REGISTER. But then it occurred to me, that there has been previously such a discussion and it has been proposed to assign alternative inputs to various test patterns. So, you just issue a VIDIOC_S_INPUT to switch between the actual video input and one of test patterns. Can anyone else remember such a discussion or maybe just knows examples of such drivers? The SAA7127 Video Encoder has a test pattern generator. The saa7127.c file uses a module option to enable it a module probe time. It also appears the v4l2_subdev.s_routing method of the saa7127 module can also be used to switch to the test signal generator as input (So VIDIOC_S_INPUT looks like it should work, maybe?). There's your precedent. Also using VIDIOC_S_INPUT also makes a lot of sense to me. A test pattern is an input; just an internal one as opposed to an external one. A couple of grep attempts haven't revealed anything. Is this a good idea? I don't think it's bad. Working through implementation details might show you if anything is really bad (VIDIOC_ENUMINPUT, etc.). Regards, Andy Thanks Guennadi -- 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 2.6.26 and up: 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:Sun Sep 5 19:00:05 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 15139:6e0befab696a git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 1c1371c2fe53ded8ede3a0404c9415fbf3321328 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: WARNINGS linux-2.6.33-armv5: OK linux-2.6.34-armv5: WARNINGS linux-2.6.35.3-armv5: WARNINGS linux-2.6.36-rc2-armv5: ERRORS linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35.3-armv5-davinci: WARNINGS linux-2.6.36-rc2-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35.3-armv5-ixp: WARNINGS linux-2.6.36-rc2-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: WARNINGS linux-2.6.33-armv5-omap2: WARNINGS linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35.3-armv5-omap2: WARNINGS linux-2.6.36-rc2-armv5-omap2: ERRORS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: 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-rc2-i686: ERRORS linux-2.6.32.6-m32r: WARNINGS linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35.3-m32r: WARNINGS linux-2.6.36-rc2-m32r: ERRORS linux-2.6.32.6-mips: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-mips: WARNINGS linux-2.6.35.3-mips: WARNINGS linux-2.6.36-rc2-mips: ERRORS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-powerpc64: WARNINGS linux-2.6.35.3-powerpc64: WARNINGS linux-2.6.36-rc2-powerpc64: ERRORS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-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-rc2-x86_64: ERRORS linux-git-Module.symvers: ERRORS linux-git-armv5: ERRORS linux-git-armv5-davinci: ERRORS linux-git-armv5-ixp: ERRORS linux-git-armv5-omap2: ERRORS linux-git-i686: ERRORS linux-git-m32r: ERRORS linux-git-mips: ERRORS linux-git-powerpc64: ERRORS linux-git-x86_64: ERRORS spec: ERRORS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.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: [PATCH 0/2] V4L/DVB: OMAP_VOUT: Allow omap_vout to build without VRFB
-Original Message- From: Taneja, Archit Sent: Saturday, September 04, 2010 2:12 PM To: Hiremath, Vaibhav Cc: linux-o...@vger.kernel.org; linux-media@vger.kernel.org; Taneja, Archit Subject: [PATCH 0/2] V4L/DVB: OMAP_VOUT: Allow omap_vout to build without VRFB This lets omap_vout driver build and run without VRFB. It works along the lines of the following patch series: OMAP: DSS2: OMAPFB: Allow FB_OMAP2 to build without VRFB https://patchwork.kernel.org/patch/105371/ A variable rotation_type is introduced in omapvideo_info like the way in omapfb_info to make both vrfb and non vrfb rotation possible. [Hiremath, Vaibhav] Archit, Currently omap_vout driver only supports VRFB based rotation, it doesn't support SDMA based rotation (unlike OMAPFB) and neither you patch adds it. Thanks, Vaibhav Since VRFB is tightly coupled with the omap_vout driver, a handful of vrfb-specific functions have been defined and placed in omap_vout_vrfb.c This series applies along with the previously submitted patch: https://patchwork.kernel.org/patch/146401/ Archit Taneja (2): V4L/DVB: OMAP_VOUT: Create a seperate vrfb functions library V4L/DVB: OMAP_VOUT: Use rotation_type to choose between vrfb and sdram rotation drivers/media/video/omap/Kconfig |1 - drivers/media/video/omap/Makefile |1 + drivers/media/video/omap/omap_vout.c | 502 ++-- - drivers/media/video/omap/omap_vout_vrfb.c | 417 drivers/media/video/omap/omap_vout_vrfb.h | 40 +++ drivers/media/video/omap/omap_voutdef.h | 26 ++ 6 files changed, 582 insertions(+), 405 deletions(-) create mode 100644 drivers/media/video/omap/omap_vout_vrfb.c create mode 100644 drivers/media/video/omap/omap_vout_vrfb.h -- 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] LED control
Hi, On 09/05/2010 08:43 PM, Andy Walls wrote: On Sun, 2010-09-05 at 15:54 +0200, Hans de Goede wrote: Hi, On 09/05/2010 10:56 AM, Jean-Francois Moine wrote: On Sun, 05 Sep 2010 09:56:54 +0200 Hans de Goedehdego...@redhat.com wrote: I think that using one control for both status leds (which is what we are usually talking about) and illuminator(s) is a bad idea. I'm fine with standardizing these, but can we please have 2 CID's one for status lights and one for the led. Esp, as I can easily see us supporting a microscope in the future where the microscope itself or other devices with the same bridge will have a status led, so then we will need 2 separate controls anyways. Hi Hans, I was not thinking about the status light (I do not see any other usage for it), but well about illuminators which I saw only in microscopes. Ah, ok thanks for clarifying. For some more on this see p.s. below. So, which is the better name? V4L2_CID_LAMPS? V4L2_CID_ILLUMINATORS? I think that V4L2_CID_ILLUMINATORS together with a comment in the .h and explanation in the spec that this specifically applies to microscopes would be good. I concur with ILLUMINATORS. The word makes it very clear the control is about actively putting light on a subject. A quick Goggle search shows that the term 'illuminator appears to apply to photography and IR cameras as well. Regards, Hans p.s. I think it would be good to have a V4L2_CID_STATUS_LED too. In many drivers we are explicitly controlling the led by register writes. Some people may very well prefer the led to always be off. I know that uvc logitech cameras have controls for the status led through the extended uvc controls. Once we have a standardized LED control, we can move the logitech uvc cams over from using their own private one to this one. I saw two use cases mentioned for status LEDs: 1. always off 2. driver automatically controls the LEDs. Can't that choice be handled with a module option Sure, just like all other v4l2 controls could be a module option, that is not very userfriendly though. , is there a case where one needs more control? Not really. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8 V3] Many fixes for in-kernel decoding and for the ENE driver
On Sun, Sep 05, 2010 at 02:22:55AM +0300, Maxim Levitsky wrote: Hi, This is next version of my patchset. I addressed the comments from David Härdeman, And in addition to that did a lot of cleanups in the ENE driver. This includes new idle mode support that doesn't need 75 ms sample period. Timeouts are now handled in much cleaner way. Refactoring, even better register names, stale comments updated, some spelling errors were fixed. Any comments are welcome! Out patchsets conflict. Depending on which order Mauro wishes to merge them one of us will have to rebase. If mine is merged first, patch 2/8 in your set should not be necessary. Also, you seem to have forgotten to include linux-media and/or Mauro in the CC list? -- David Härdeman -- 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 7/8] IR: extend ir_raw_event and do refactoring
Comments inline...
On Sun, Sep 05, 2010 at 02:23:02AM +0300, Maxim Levitsky wrote:
Add new event types for timeout carrier report
Move timeout handling from ir_raw_event_store_with_filter to
ir-lirc-codec, where it is really needed.
Now lirc bridge ensures proper gap handling.
Extend lirc bridge for carrier timeout reports
Note: all new ir_raw_event variables now should be initialized
like that: DEFINE_RC_RAW_EVENT(ev);
To clean an existing event, use init_ir_raw_event(ev);
Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
---
drivers/media/IR/ene_ir.c |2 +-
drivers/media/IR/ir-core-priv.h| 11 +-
drivers/media/IR/ir-jvc-decoder.c |5 +-
drivers/media/IR/ir-lirc-codec.c | 78
+++-
drivers/media/IR/ir-nec-decoder.c |5 +-
drivers/media/IR/ir-raw-event.c| 43 +++-
drivers/media/IR/ir-rc5-decoder.c |5 +-
drivers/media/IR/ir-rc6-decoder.c |5 +-
drivers/media/IR/ir-sony-decoder.c |5 +-
drivers/media/IR/mceusb.c |3 +-
drivers/media/IR/streamzap.c |8 ++-
include/media/ir-core.h| 35 ++--
12 files changed, 146 insertions(+), 59 deletions(-)
diff --git a/drivers/media/IR/ene_ir.c b/drivers/media/IR/ene_ir.c
index 7880d9c..5ebafb5 100644
--- a/drivers/media/IR/ene_ir.c
+++ b/drivers/media/IR/ene_ir.c
@@ -701,7 +701,7 @@ static irqreturn_t ene_isr(int irq, void *data)
unsigned long flags;
irqreturn_t retval = IRQ_NONE;
struct ene_device *dev = (struct ene_device *)data;
- struct ir_raw_event ev;
+ DEFINE_RC_RAW_EVENT(ev);
spin_lock_irqsave(dev-hw_lock, flags);
diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index 5d7e08f..a287373 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -82,6 +82,10 @@ struct ir_raw_event_ctrl {
struct ir_input_dev *ir_dev;
struct lirc_driver *drv;
int carrier_low;
+ ktime_t timeout_start;
+ bool timeout;
+ bool send_timeout_reports;
+
} lirc;
};
@@ -109,9 +113,14 @@ static inline void decrease_duration(struct ir_raw_event
*ev, unsigned duration)
ev-duration -= duration;
}
+/* Returns true if event is normal pulse/space event */
+static inline bool is_timing_event(struct ir_raw_event ev)
+{
+ return !ev.carrier_report !ev.reset;
+}
+
#define TO_US(duration) DIV_ROUND_CLOSEST((duration),
1000)
#define TO_STR(is_pulse) ((is_pulse) ? pulse : space)
-#define IS_RESET(ev) (ev.duration == 0)
/*
* Routines from ir-sysfs.c - Meant to be called only internally inside
* ir-core
diff --git a/drivers/media/IR/ir-jvc-decoder.c
b/drivers/media/IR/ir-jvc-decoder.c
index 77a89c4..63dca6e 100644
--- a/drivers/media/IR/ir-jvc-decoder.c
+++ b/drivers/media/IR/ir-jvc-decoder.c
@@ -50,8 +50,9 @@ static int ir_jvc_decode(struct input_dev *input_dev,
struct ir_raw_event ev)
if (!(ir_dev-raw-enabled_protocols IR_TYPE_JVC))
return 0;
- if (IS_RESET(ev)) {
- data-state = STATE_INACTIVE;
+ if (!is_timing_event(ev)) {
+ if (ev.reset)
+ data-state = STATE_INACTIVE;
return 0;
}
diff --git a/drivers/media/IR/ir-lirc-codec.c
b/drivers/media/IR/ir-lirc-codec.c
index e63f757..15112db 100644
--- a/drivers/media/IR/ir-lirc-codec.c
+++ b/drivers/media/IR/ir-lirc-codec.c
@@ -32,6 +32,7 @@
static int ir_lirc_decode(struct input_dev *input_dev, struct ir_raw_event
ev)
{
struct ir_input_dev *ir_dev = input_get_drvdata(input_dev);
+ struct lirc_codec *lirc = ir_dev-raw-lirc;
int sample;
if (!(ir_dev-raw-enabled_protocols IR_TYPE_LIRC))
@@ -40,21 +41,57 @@ static int ir_lirc_decode(struct input_dev *input_dev,
struct ir_raw_event ev)
if (!ir_dev-raw-lirc.drv || !ir_dev-raw-lirc.drv-rbuf)
return -EINVAL;
- if (IS_RESET(ev))
+ /* Packet start */
+ if (ev.reset)
return 0;
- IR_dprintk(2, LIRC data transfer started (%uus %s)\n,
-TO_US(ev.duration), TO_STR(ev.pulse));
+ /* Carrier reports */
+ if (ev.carrier_report) {
+ sample = LIRC_FREQUENCY(ev.carrier);
+
+ /* Packet end */
+ } else if (ev.timeout) {
+
+ if (lirc-timeout)
+ return 0;
+
+ lirc-timeout_start = ktime_get();
+ lirc-timeout = true;
+
+ if (!lirc-send_timeout_reports)
+ return 0;
+
+ sample = LIRC_TIMEOUT(ev.duration / 1000);
- sample = ev.duration / 1000;
- if (ev.pulse)
- sample |= PULSE_BIT;
+ /* Normal sample */
+ } else {
+
+ if
Re: [PATCH 0/8 V3] Many fixes for in-kernel decoding and for the ENE driver
On Sun, 2010-09-05 at 23:06 +0200, David Härdeman wrote: On Sun, Sep 05, 2010 at 02:22:55AM +0300, Maxim Levitsky wrote: Hi, This is next version of my patchset. I addressed the comments from David Härdeman, And in addition to that did a lot of cleanups in the ENE driver. This includes new idle mode support that doesn't need 75 ms sample period. Timeouts are now handled in much cleaner way. Refactoring, even better register names, stale comments updated, some spelling errors were fixed. Any comments are welcome! Out patchsets conflict. Depending on which order Mauro wishes to merge them one of us will have to rebase. If mine is merged first, patch 2/8 in your set should not be necessary. Btw, I really welcome your patches. Indeed we need to resolve this. I hope to see this patchset in 2.6.36, because without it there are just too many bugs. Best regards, Maxim Levitsky -- 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 7/8] IR: extend ir_raw_event and do refactoring
On Sun, 2010-09-05 at 23:23 +0200, David Härdeman wrote:
Comments inline...
On Sun, Sep 05, 2010 at 02:23:02AM +0300, Maxim Levitsky wrote:
Add new event types for timeout carrier report
Move timeout handling from ir_raw_event_store_with_filter to
ir-lirc-codec, where it is really needed.
Now lirc bridge ensures proper gap handling.
Extend lirc bridge for carrier timeout reports
Note: all new ir_raw_event variables now should be initialized
like that: DEFINE_RC_RAW_EVENT(ev);
To clean an existing event, use init_ir_raw_event(ev);
Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
---
drivers/media/IR/ene_ir.c |2 +-
drivers/media/IR/ir-core-priv.h| 11 +-
drivers/media/IR/ir-jvc-decoder.c |5 +-
drivers/media/IR/ir-lirc-codec.c | 78
+++-
drivers/media/IR/ir-nec-decoder.c |5 +-
drivers/media/IR/ir-raw-event.c| 43 +++-
drivers/media/IR/ir-rc5-decoder.c |5 +-
drivers/media/IR/ir-rc6-decoder.c |5 +-
drivers/media/IR/ir-sony-decoder.c |5 +-
drivers/media/IR/mceusb.c |3 +-
drivers/media/IR/streamzap.c |8 ++-
include/media/ir-core.h| 35 ++--
12 files changed, 146 insertions(+), 59 deletions(-)
diff --git a/drivers/media/IR/ene_ir.c b/drivers/media/IR/ene_ir.c
index 7880d9c..5ebafb5 100644
--- a/drivers/media/IR/ene_ir.c
+++ b/drivers/media/IR/ene_ir.c
@@ -701,7 +701,7 @@ static irqreturn_t ene_isr(int irq, void *data)
unsigned long flags;
irqreturn_t retval = IRQ_NONE;
struct ene_device *dev = (struct ene_device *)data;
- struct ir_raw_event ev;
+ DEFINE_RC_RAW_EVENT(ev);
spin_lock_irqsave(dev-hw_lock, flags);
diff --git a/drivers/media/IR/ir-core-priv.h
b/drivers/media/IR/ir-core-priv.h
index 5d7e08f..a287373 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -82,6 +82,10 @@ struct ir_raw_event_ctrl {
struct ir_input_dev *ir_dev;
struct lirc_driver *drv;
int carrier_low;
+ ktime_t timeout_start;
+ bool timeout;
+ bool send_timeout_reports;
+
} lirc;
};
@@ -109,9 +113,14 @@ static inline void decrease_duration(struct
ir_raw_event *ev, unsigned duration)
ev-duration -= duration;
}
+/* Returns true if event is normal pulse/space event */
+static inline bool is_timing_event(struct ir_raw_event ev)
+{
+ return !ev.carrier_report !ev.reset;
+}
+
#define TO_US(duration)DIV_ROUND_CLOSEST((duration),
1000)
#define TO_STR(is_pulse) ((is_pulse) ? pulse : space)
-#define IS_RESET(ev) (ev.duration == 0)
/*
* Routines from ir-sysfs.c - Meant to be called only internally inside
* ir-core
diff --git a/drivers/media/IR/ir-jvc-decoder.c
b/drivers/media/IR/ir-jvc-decoder.c
index 77a89c4..63dca6e 100644
--- a/drivers/media/IR/ir-jvc-decoder.c
+++ b/drivers/media/IR/ir-jvc-decoder.c
@@ -50,8 +50,9 @@ static int ir_jvc_decode(struct input_dev *input_dev,
struct ir_raw_event ev)
if (!(ir_dev-raw-enabled_protocols IR_TYPE_JVC))
return 0;
- if (IS_RESET(ev)) {
- data-state = STATE_INACTIVE;
+ if (!is_timing_event(ev)) {
+ if (ev.reset)
+ data-state = STATE_INACTIVE;
return 0;
}
diff --git a/drivers/media/IR/ir-lirc-codec.c
b/drivers/media/IR/ir-lirc-codec.c
index e63f757..15112db 100644
--- a/drivers/media/IR/ir-lirc-codec.c
+++ b/drivers/media/IR/ir-lirc-codec.c
@@ -32,6 +32,7 @@
static int ir_lirc_decode(struct input_dev *input_dev, struct ir_raw_event
ev)
{
struct ir_input_dev *ir_dev = input_get_drvdata(input_dev);
+ struct lirc_codec *lirc = ir_dev-raw-lirc;
int sample;
if (!(ir_dev-raw-enabled_protocols IR_TYPE_LIRC))
@@ -40,21 +41,57 @@ static int ir_lirc_decode(struct input_dev *input_dev,
struct ir_raw_event ev)
if (!ir_dev-raw-lirc.drv || !ir_dev-raw-lirc.drv-rbuf)
return -EINVAL;
- if (IS_RESET(ev))
+ /* Packet start */
+ if (ev.reset)
return 0;
- IR_dprintk(2, LIRC data transfer started (%uus %s)\n,
- TO_US(ev.duration), TO_STR(ev.pulse));
+ /* Carrier reports */
+ if (ev.carrier_report) {
+ sample = LIRC_FREQUENCY(ev.carrier);
+
+ /* Packet end */
+ } else if (ev.timeout) {
+
+ if (lirc-timeout)
+ return 0;
+
+ lirc-timeout_start = ktime_get();
+ lirc-timeout = true;
+
+ if (!lirc-send_timeout_reports)
+ return 0;
+
+ sample = LIRC_TIMEOUT(ev.duration / 1000);
- sample = ev.duration / 1000;
- if (ev.pulse)
Cannot get Hauppauge HVR-1200 to work
I cannot get Hauppauge HVR-1200 to work. It is recognized correctly and the driver, including firmware, is being loaded. However, there are some errors: [ 36.320282] DVB: registering new adapter (saa7133[0]) [ 36.320290] DVB: registering adapter 0 frontend 0 (NXP TDA10048HN DVB-T)... [ 36.668044] tda10048_firmware_upload: waiting for firmware upload (dvb-fe-tda10048-1.0.fw)... [ 36.668060] saa7134 :01:05.0: firmware: requesting dvb-fe-tda10048-1.0.fw [ 37.119606] tda10048_firmware_upload: firmware read 24878 bytes. [ 37.119615] tda10048_firmware_upload: firmware uploading [ 41.252047] tda10048_firmware_upload: firmware uploaded [ 42.389045] tda18271_write_regs: ERROR: i2c_transfer returned: -5 [ 42.389056] tda18271_init: error -5 on line 805 [ 42.389067] tda18271_tune: error -5 on line 867 [ 42.389073] tda18271_set_analog_params: error -5 on line 1004 [ 353.877042] tda18271_write_regs: ERROR: i2c_transfer returned: -5 [ 353.877054] tda18271_init: error -5 on line 805 [ 353.877060] tda18271_tune: error -5 on line 867 [ 353.877065] tda18271_set_analog_params: error -5 on line 1004 The problem, of course, is not the error message per se, but the fact that I cannot tune to any station: w_scan -c IL ... ERROR: Sorry - i couldn't get any working frequency/transponder Nothing to scan!! Any suggestions ? -- 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/RFCv4 0/6] The Contiguous Memory Allocator framework
On Mon, 6 Sep 2010 00:57:53 +0900
Minchan Kim minchan@gmail.com wrote:
Thanks,
-Kame
==
From: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
This patch as a memory allocator for contiguous memory larger than
MAX_ORDER.
alloc_contig_pages(hint, size, list);
This function allocates 'size' of contigoues pages, whose physical address
is higher than 'hint'. size is specicied in byte unit.
size is byte, hint is pfn?
hint is physical address. What's annoying me is x86-32, should I use physaddr_t
or
pfn
Allocated pages are all linked into the list and all of their page_count()
are set to 1. Return value is the top page.
free_contig_pages(list)
returns all pages in the list.
This patch does
- find an area which can be ISOLATED.
- migrate remaining pages in the area.
Migrate from there to where?
somewhere.
- steal chunk of pages from allocator.
Limitation is:
- retruned pages will be aligend to MAX_ORDER.
- returned length of page will be aligned to MAX_ORDER.
(so, the caller may have to return tails of pages by itself.)
What do you mean tail?
Ah, the allocator returns MAX_ORDER aligned pages, then,
[y]
x+y = allocated
x = will be used.
y = will be unsused.
I call 'y' as tail, here.
- may allocate contiguous pages which overlap node/zones.
Hmm.. Do we really need this?
Unnecessary. please consider this as BUG.
This code just check pfn of allocated area but doesn't check which
zone/node the pfn is tied to.
For example, I hear IBM has following kind of memory layout.
| Node0 | Node1 | Node2 | Node0 | Node2 | Node1| .
So, some check should be added to avoid to allocate chunk of pages
spreads out to multiple nodes.
(I hope walk_page_range() can do enough jobs for us, but I'm not sure.
I need to add zone check, at least)
This is fully experimental and written as example.
(Maybe need more patches to make this complete.)
Yes. But first impression of this patch is good to me.
This patch moves some amount of codes from memory_hotplug.c to
page_isolation.c and based on page-offline technique used by
memory_hotplug.c
Signed-off-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
---
include/linux/page-isolation.h | 10 +
mm/memory_hotplug.c| 84 --
mm/page_alloc.c| 32 +
mm/page_isolation.c| 244
+
4 files changed, 287 insertions(+), 83 deletions(-)
Index: mmotm-0827/mm/page_isolation.c
===
--- mmotm-0827.orig/mm/page_isolation.c
+++ mmotm-0827/mm/page_isolation.c
@@ -3,8 +3,11 @@
*/
#include linux/mm.h
+#include linux/swap.h
#include linux/page-isolation.h
#include linux/pageblock-flags.h
+#include linux/mm_inline.h
+#include linux/migrate.h
#include internal.h
static inline struct page *
@@ -140,3 +143,244 @@ int test_pages_isolated(unsigned long st
spin_unlock_irqrestore(zone-lock, flags);
return ret ? 0 : -EBUSY;
}
+
+#define CONTIG_ALLOC_MIGRATION_RETRY (5)
+
+/*
+ * Scanning pfn is much easier than scanning lru list.
+ * Scan pfn from start to end and Find LRU page.
+ */
+unsigned long scan_lru_pages(unsigned long start, unsigned long end)
+{
+ unsigned long pfn;
+ struct page *page;
+ for (pfn = start; pfn end; pfn++) {
+ if (pfn_valid(pfn)) {
+ page = pfn_to_page(pfn);
+ if (PageLRU(page))
+ return pfn;
+ }
+ }
+ return 0;
+}
+
+/* Migrate all LRU pages in the range to somewhere else */
+static struct page *
+hotremove_migrate_alloc(struct page *page, unsigned long private, int **x)
+{
+ /* This should be improved!! */
Yeb.
+ return alloc_page(GFP_HIGHUSER_MOVABLE);
+}
snip
+struct page *alloc_contig_pages(unsigned long long hint,
+ unsigned long size, struct list_head *list)
+{
+ unsigned long base, found, end, pages, start;
+ struct page *ret = NULL;
+ int nid, retry;
+
+ if (hint)
+ hint = ALIGN(hint, MAX_ORDER_NR_PAGES);
+ /* request size should be aligned to pageblock */
+ size = PAGE_SHIFT;
+ pages = ALIGN(size, MAX_ORDER_NR_PAGES);
+ found = 0;
+retry:
+ for_each_node_state(nid, N_HIGH_MEMORY) {
+ unsigned long node_end;
+ pg_data_t *node = NODE_DATA(nid);
+
+ node_end = node-node_start_pfn + node-node_spanned_pages;
+ /* does this node have proper range of memory ? */
+ if (node_end hint + pages)
+ continue;
+ base = hint;
+ if (base node-node_start_pfn)
+ base =
RE: [PATCH 0/2] V4L/DVB: OMAP_VOUT: Allow omap_vout to build without VRFB
Hi, Hiremath, Vaibhav wrote: -Original Message- From: Taneja, Archit Sent: Saturday, September 04, 2010 2:12 PM To: Hiremath, Vaibhav Cc: linux-o...@vger.kernel.org; linux-media@vger.kernel.org; Taneja, Archit Subject: [PATCH 0/2] V4L/DVB: OMAP_VOUT: Allow omap_vout to build without VRFB This lets omap_vout driver build and run without VRFB. It works along the lines of the following patch series: OMAP: DSS2: OMAPFB: Allow FB_OMAP2 to build without VRFB https://patchwork.kernel.org/patch/105371/ A variable rotation_type is introduced in omapvideo_info like the way in omapfb_info to make both vrfb and non vrfb rotation possible. [Hiremath, Vaibhav] Archit, Currently omap_vout driver only supports VRFB based rotation, it doesn't support SDMA based rotation (unlike OMAPFB) and neither you patch adds it. [Archit]The above description in the git commit is a mistake from my end. The main purpose of the patch is to get omap_vout running without VRFB. I am not sure if we need to enable SDMA rotation for V4L2 though, we would always have vrfb and tiler on omap3 and omap4 respectively. How do you think things should be handled in the non vrfb case? Should we try to get rotation running or should the driver return an error if userspace tries to enable rotation in a non-vrfb mode? Thanks, Archit Since VRFB is tightly coupled with the omap_vout driver, a handful of vrfb-specific functions have been defined and placed in omap_vout_vrfb.c This series applies along with the previously submitted patch: https://patchwork.kernel.org/patch/146401/ Archit Taneja (2): V4L/DVB: OMAP_VOUT: Create a seperate vrfb functions library V4L/DVB: OMAP_VOUT: Use rotation_type to choose between vrfb and sdram rotation drivers/media/video/omap/Kconfig |1 - drivers/media/video/omap/Makefile |1 + drivers/media/video/omap/omap_vout.c | 502 ++-- - drivers/media/video/omap/omap_vout_vrfb.c | 417 drivers/media/video/omap/omap_vout_vrfb.h | 40 +++ drivers/media/video/omap/omap_voutdef.h | 26 ++ 6 files changed, 582 insertions(+), 405 deletions(-) create mode 100644 drivers/media/video/omap/omap_vout_vrfb.c create mode 100644 drivers/media/video/omap/omap_vout_vrfb.h-- 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
