Re: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz
Am Samstag, den 28.03.2009, 05:48 +0100 schrieb hermann pitton: > Am Samstag, den 28.03.2009, 05:32 +0100 schrieb hermann pitton: > > Am Samstag, den 28.03.2009, 00:58 -0300 schrieb Mauro Carvalho Chehab: > > > On Sat, 28 Mar 2009 00:23:55 +0100 > > > hermann pitton wrote: > > > > > > > Hi, > > > > > > > > Am Freitag, den 27.03.2009, 07:38 -0300 schrieb Mauro Carvalho Chehab: > > > > > On Fri, 27 Mar 2009 02:39:07 +0100 > > > > > hermann pitton wrote: > > > > > > > > > > > But my main concern is, if it once arrived at patchwork formally, > > > > > > it is > > > > > > out of sight for most of us and might miss proper review, except > > > > > > you are > > > > > > sure you can always guarantee that. I don't want to start to argue > > > > > > about > > > > > > all what happened in the past. > > > > > > > > > > > > So, at least, if some patch arrived there mysteriously ;), the > > > > > > linux-media list should be informed that it is there now and last > > > > > > time > > > > > > to speak off, in case anything is not fully clear, before vanishing > > > > > > into > > > > > > some black hole until you find it in the next kernel release ... > > > > > > > > > > The only way to send patches to patchwork is to submit it via > > > > > linux-media list. > > > > > There's no other way. So, all patch discussions and reviews should > > > > > happen at > > > > > the ML, by replying at the patch email (or by replying another reply). > > > > > Patchwork will keep track of such replies as well. > > > > > > > > > > > > > What happened so far with this patches is quite funny, > > > > for me some black hole seems to be involved. > > > > > > > > Klaas did send them the first time, also directly to me, on Tue, 24 Mar > > > > 2009 23:14:11 +0100. > > > > > > > > Now I can see you have pulled them in already on Wednesday. > > > > http://linuxtv.org/hg/v4l-dvb/rev/5efa9fbc8a88 > > > > > > > > There is no trace anymore on patchwork visible to me. > > > > http://patchwork.kernel.org/project/linux-media/list > > > > So I don't know how you processed them. > > > > > > The above link uses the default patchwork filtering. By default it shows > > > only > > > patches where there's an action required (e. g. New or Under Review > > > patches). > > > > > > To view a full list of the patches, you need to click at filters and > > > select any. > > > > > > You'll see all patches: > > > http://patchwork.kernel.org/project/linux-media/list/?state=* > > > > > > In the specific case od Klaas, this is his patch: > > > > > > http://patchwork.kernel.org/patch/14405/ > > > > > > > Most confusing is, that Klaas obviously did not receive a mail > > > > notification from linuxtv-commits that his patch came in. > > > > > > > > > > > Last message date: Fri Feb 15 19:45:02 CET 2008 > > > > Archived on: Fri Feb 15 19:45:04 CET 2008 > > > > > > > > Is it broken or only the archive not up to date? > > > > > > > > > > I've received the notification here: > > > > > > From: Patch from klaas de waal > > > To: linuxtv-comm...@linuxtv.org > > > Cc: , Mauro Carvalho Chehab , klaas de waal > > > > > > Subject: [linuxtv-commits] [hg:v4l-dvb] tda827x: fix locking issues with > > > DVB-C > > > Date: Fri, 27 Mar 2009 18:05:01 +0100 > > > Reply-To: klaas de waal via Mercurial > > > Sender: linuxtv-commits-boun...@linuxtv.org > > > > > > The patch number 11236 was added via Mauro Carvalho Chehab > > > > > > to http://linuxtv.org/hg/v4l-dvb master development tree. > > > > > > Klaas should be received this also. Maybe some anti-spam filtering on his > > > side? > > > > > > You'll probably see this also at the linuxtv-commits archives. > > > > > > > Why else he would have posted a second time on > > > > Wed, 25 Mar 2009 21:53:02 +0100 not knowing anything about the status of > > > > his patches, which made me believe I should try to help him? > > > > > > > > The timestamp on your mercurial commit of them is > > > > Wed Mar 25 20:53:02 2009 + (2 days ago) > > > > That is the time when his second email arrived converted to Greenwich > > > > time? Or how could you commit within the same second that mail arrived? > > > > > > > This is the time the patches have on both of his original mails. > > > > --- a/linux/drivers/media/common/tuners/tda827x.c Tue Mar 24 21:12:47 > > > > 2009 + > > > > --- a/linux/drivers/media/common/tuners/tda827x.c Tue Mar 24 21:12:47 > > > > 2009 + > > > > > > The import scripts will try to preserve the original date of the sent > > > email. > > > > > > So, the date there is when the code were presented to public. > > > > > > > How can I ever know when they were really added and if they went through > > > > patchwork :) > > > > > > > > I was just about to suggest Klaas should try again with [PATCH] in the > > > > subject until they are listed at patchwork. > > > > > > If the patch was received by patchwork, and "disappeared", all you need > > > to do > > > is to click on filter and
Re: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz
Am Samstag, den 28.03.2009, 05:32 +0100 schrieb hermann pitton: > Am Samstag, den 28.03.2009, 00:58 -0300 schrieb Mauro Carvalho Chehab: > > On Sat, 28 Mar 2009 00:23:55 +0100 > > hermann pitton wrote: > > > > > Hi, > > > > > > Am Freitag, den 27.03.2009, 07:38 -0300 schrieb Mauro Carvalho Chehab: > > > > On Fri, 27 Mar 2009 02:39:07 +0100 > > > > hermann pitton wrote: > > > > > > > > > But my main concern is, if it once arrived at patchwork formally, it > > > > > is > > > > > out of sight for most of us and might miss proper review, except you > > > > > are > > > > > sure you can always guarantee that. I don't want to start to argue > > > > > about > > > > > all what happened in the past. > > > > > > > > > > So, at least, if some patch arrived there mysteriously ;), the > > > > > linux-media list should be informed that it is there now and last time > > > > > to speak off, in case anything is not fully clear, before vanishing > > > > > into > > > > > some black hole until you find it in the next kernel release ... > > > > > > > > The only way to send patches to patchwork is to submit it via > > > > linux-media list. > > > > There's no other way. So, all patch discussions and reviews should > > > > happen at > > > > the ML, by replying at the patch email (or by replying another reply). > > > > Patchwork will keep track of such replies as well. > > > > > > > > > > What happened so far with this patches is quite funny, > > > for me some black hole seems to be involved. > > > > > > Klaas did send them the first time, also directly to me, on Tue, 24 Mar > > > 2009 23:14:11 +0100. > > > > > > Now I can see you have pulled them in already on Wednesday. > > > http://linuxtv.org/hg/v4l-dvb/rev/5efa9fbc8a88 > > > > > > There is no trace anymore on patchwork visible to me. > > > http://patchwork.kernel.org/project/linux-media/list > > > So I don't know how you processed them. > > > > The above link uses the default patchwork filtering. By default it shows > > only > > patches where there's an action required (e. g. New or Under Review > > patches). > > > > To view a full list of the patches, you need to click at filters and select > > any. > > > > You'll see all patches: > > http://patchwork.kernel.org/project/linux-media/list/?state=* > > > > In the specific case od Klaas, this is his patch: > > > > http://patchwork.kernel.org/patch/14405/ > > > > > Most confusing is, that Klaas obviously did not receive a mail > > > notification from linuxtv-commits that his patch came in. > > > > > > > > Last message date: Fri Feb 15 19:45:02 CET 2008 > > > Archived on: Fri Feb 15 19:45:04 CET 2008 > > > > > > Is it broken or only the archive not up to date? > > > > > > > I've received the notification here: > > > > From: Patch from klaas de waal > > To: linuxtv-comm...@linuxtv.org > > Cc: , Mauro Carvalho Chehab , klaas de waal > > > > Subject: [linuxtv-commits] [hg:v4l-dvb] tda827x: fix locking issues with > > DVB-C > > Date: Fri, 27 Mar 2009 18:05:01 +0100 > > Reply-To: klaas de waal via Mercurial > > Sender: linuxtv-commits-boun...@linuxtv.org > > > > The patch number 11236 was added via Mauro Carvalho Chehab > > > > to http://linuxtv.org/hg/v4l-dvb master development tree. > > > > Klaas should be received this also. Maybe some anti-spam filtering on his > > side? > > > > You'll probably see this also at the linuxtv-commits archives. > > > > > Why else he would have posted a second time on > > > Wed, 25 Mar 2009 21:53:02 +0100 not knowing anything about the status of > > > his patches, which made me believe I should try to help him? > > > > > > The timestamp on your mercurial commit of them is > > > Wed Mar 25 20:53:02 2009 + (2 days ago) > > > That is the time when his second email arrived converted to Greenwich > > > time? Or how could you commit within the same second that mail arrived? > > > > > This is the time the patches have on both of his original mails. > > > --- a/linux/drivers/media/common/tuners/tda827x.c Tue Mar 24 21:12:47 > > > 2009 + > > > --- a/linux/drivers/media/common/tuners/tda827x.c Tue Mar 24 21:12:47 > > > 2009 + > > > > The import scripts will try to preserve the original date of the sent email. > > > > So, the date there is when the code were presented to public. > > > > > How can I ever know when they were really added and if they went through > > > patchwork :) > > > > > > I was just about to suggest Klaas should try again with [PATCH] in the > > > subject until they are listed at patchwork. > > > > If the patch was received by patchwork, and "disappeared", all you need to > > do > > is to click on filter and select a proper filter, like: > > > > http://patchwork.kernel.org/project/linux-media/list/?submitter=klaas&state=* > > > > This will present all patches authored by "klaas", and their state. Ah, if > > you > > click on the patch, you'll see all the patch history, including the > > sent/received emails. Even this ema
Re: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz
Am Samstag, den 28.03.2009, 00:58 -0300 schrieb Mauro Carvalho Chehab: > On Sat, 28 Mar 2009 00:23:55 +0100 > hermann pitton wrote: > > > Hi, > > > > Am Freitag, den 27.03.2009, 07:38 -0300 schrieb Mauro Carvalho Chehab: > > > On Fri, 27 Mar 2009 02:39:07 +0100 > > > hermann pitton wrote: > > > > > > > But my main concern is, if it once arrived at patchwork formally, it is > > > > out of sight for most of us and might miss proper review, except you are > > > > sure you can always guarantee that. I don't want to start to argue about > > > > all what happened in the past. > > > > > > > > So, at least, if some patch arrived there mysteriously ;), the > > > > linux-media list should be informed that it is there now and last time > > > > to speak off, in case anything is not fully clear, before vanishing into > > > > some black hole until you find it in the next kernel release ... > > > > > > The only way to send patches to patchwork is to submit it via linux-media > > > list. > > > There's no other way. So, all patch discussions and reviews should happen > > > at > > > the ML, by replying at the patch email (or by replying another reply). > > > Patchwork will keep track of such replies as well. > > > > > > > What happened so far with this patches is quite funny, > > for me some black hole seems to be involved. > > > > Klaas did send them the first time, also directly to me, on Tue, 24 Mar > > 2009 23:14:11 +0100. > > > > Now I can see you have pulled them in already on Wednesday. > > http://linuxtv.org/hg/v4l-dvb/rev/5efa9fbc8a88 > > > > There is no trace anymore on patchwork visible to me. > > http://patchwork.kernel.org/project/linux-media/list > > So I don't know how you processed them. > > The above link uses the default patchwork filtering. By default it shows only > patches where there's an action required (e. g. New or Under Review patches). > > To view a full list of the patches, you need to click at filters and select > any. > > You'll see all patches: > http://patchwork.kernel.org/project/linux-media/list/?state=* > > In the specific case od Klaas, this is his patch: > > http://patchwork.kernel.org/patch/14405/ > > > Most confusing is, that Klaas obviously did not receive a mail > > notification from linuxtv-commits that his patch came in. > > > > > Last message date: Fri Feb 15 19:45:02 CET 2008 > > Archived on: Fri Feb 15 19:45:04 CET 2008 > > > > Is it broken or only the archive not up to date? > > > > I've received the notification here: > > From: Patch from klaas de waal > To: linuxtv-comm...@linuxtv.org > Cc: , Mauro Carvalho Chehab , klaas de waal > > Subject: [linuxtv-commits] [hg:v4l-dvb] tda827x: fix locking issues with DVB-C > Date: Fri, 27 Mar 2009 18:05:01 +0100 > Reply-To: klaas de waal via Mercurial > Sender: linuxtv-commits-boun...@linuxtv.org > > The patch number 11236 was added via Mauro Carvalho Chehab > > to http://linuxtv.org/hg/v4l-dvb master development tree. > > Klaas should be received this also. Maybe some anti-spam filtering on his > side? > > You'll probably see this also at the linuxtv-commits archives. > > > Why else he would have posted a second time on > > Wed, 25 Mar 2009 21:53:02 +0100 not knowing anything about the status of > > his patches, which made me believe I should try to help him? > > > > The timestamp on your mercurial commit of them is > > Wed Mar 25 20:53:02 2009 + (2 days ago) > > That is the time when his second email arrived converted to Greenwich > > time? Or how could you commit within the same second that mail arrived? > > > This is the time the patches have on both of his original mails. > > --- a/linux/drivers/media/common/tuners/tda827x.c Tue Mar 24 21:12:47 2009 > > + > > --- a/linux/drivers/media/common/tuners/tda827x.c Tue Mar 24 21:12:47 2009 > > + > > The import scripts will try to preserve the original date of the sent email. > > So, the date there is when the code were presented to public. > > > How can I ever know when they were really added and if they went through > > patchwork :) > > > > I was just about to suggest Klaas should try again with [PATCH] in the > > subject until they are listed at patchwork. > > If the patch was received by patchwork, and "disappeared", all you need to do > is to click on filter and select a proper filter, like: > > http://patchwork.kernel.org/project/linux-media/list/?submitter=klaas&state=* > > This will present all patches authored by "klaas", and their state. Ah, if you > click on the patch, you'll see all the patch history, including the > sent/received emails. Even this email should be added there by patchwork ;) > > Cheers, > Mauro Mauro, you are joking. How I ever could come to that from here? http://patchwork.kernel.org/project/linux-media/list I'm forced to read the source code. There seems to be some serious utf8 bug too. Cheers, Hermann -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the
Re: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz
On Sat, 28 Mar 2009 00:23:55 +0100 hermann pitton wrote: > Hi, > > Am Freitag, den 27.03.2009, 07:38 -0300 schrieb Mauro Carvalho Chehab: > > On Fri, 27 Mar 2009 02:39:07 +0100 > > hermann pitton wrote: > > > > > But my main concern is, if it once arrived at patchwork formally, it is > > > out of sight for most of us and might miss proper review, except you are > > > sure you can always guarantee that. I don't want to start to argue about > > > all what happened in the past. > > > > > > So, at least, if some patch arrived there mysteriously ;), the > > > linux-media list should be informed that it is there now and last time > > > to speak off, in case anything is not fully clear, before vanishing into > > > some black hole until you find it in the next kernel release ... > > > > The only way to send patches to patchwork is to submit it via linux-media > > list. > > There's no other way. So, all patch discussions and reviews should happen at > > the ML, by replying at the patch email (or by replying another reply). > > Patchwork will keep track of such replies as well. > > > > What happened so far with this patches is quite funny, > for me some black hole seems to be involved. > > Klaas did send them the first time, also directly to me, on Tue, 24 Mar > 2009 23:14:11 +0100. > > Now I can see you have pulled them in already on Wednesday. > http://linuxtv.org/hg/v4l-dvb/rev/5efa9fbc8a88 > > There is no trace anymore on patchwork visible to me. > http://patchwork.kernel.org/project/linux-media/list > So I don't know how you processed them. The above link uses the default patchwork filtering. By default it shows only patches where there's an action required (e. g. New or Under Review patches). To view a full list of the patches, you need to click at filters and select any. You'll see all patches: http://patchwork.kernel.org/project/linux-media/list/?state=* In the specific case od Klaas, this is his patch: http://patchwork.kernel.org/patch/14405/ > Most confusing is, that Klaas obviously did not receive a mail > notification from linuxtv-commits that his patch came in. > > Last message date: Fri Feb 15 19:45:02 CET 2008 > Archived on: Fri Feb 15 19:45:04 CET 2008 > > Is it broken or only the archive not up to date? > I've received the notification here: From: Patch from klaas de waal To: linuxtv-comm...@linuxtv.org Cc: , Mauro Carvalho Chehab , klaas de waal Subject: [linuxtv-commits] [hg:v4l-dvb] tda827x: fix locking issues with DVB-C Date: Fri, 27 Mar 2009 18:05:01 +0100 Reply-To: klaas de waal via Mercurial Sender: linuxtv-commits-boun...@linuxtv.org The patch number 11236 was added via Mauro Carvalho Chehab to http://linuxtv.org/hg/v4l-dvb master development tree. Klaas should be received this also. Maybe some anti-spam filtering on his side? You'll probably see this also at the linuxtv-commits archives. > Why else he would have posted a second time on > Wed, 25 Mar 2009 21:53:02 +0100 not knowing anything about the status of > his patches, which made me believe I should try to help him? > > The timestamp on your mercurial commit of them is > Wed Mar 25 20:53:02 2009 + (2 days ago) > That is the time when his second email arrived converted to Greenwich > time? Or how could you commit within the same second that mail arrived? > This is the time the patches have on both of his original mails. > --- a/linux/drivers/media/common/tuners/tda827x.c Tue Mar 24 21:12:47 2009 > + > --- a/linux/drivers/media/common/tuners/tda827x.c Tue Mar 24 21:12:47 2009 > + The import scripts will try to preserve the original date of the sent email. So, the date there is when the code were presented to public. > How can I ever know when they were really added and if they went through > patchwork :) > > I was just about to suggest Klaas should try again with [PATCH] in the > subject until they are listed at patchwork. If the patch was received by patchwork, and "disappeared", all you need to do is to click on filter and select a proper filter, like: http://patchwork.kernel.org/project/linux-media/list/?submitter=klaas&state=* This will present all patches authored by "klaas", and their state. Ah, if you click on the patch, you'll see all the patch history, including the sent/received emails. Even this email should be added there by patchwork ;) Cheers, 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: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz
[snip] > This is the time the patches have on both of his original mails. > --- a/linux/drivers/media/common/tuners/tda827x.c Tue Mar 24 21:12:47 2009 > + > --- a/linux/drivers/media/common/tuners/tda827x.c Tue Mar 24 21:12:47 2009 > + Hmm, how this could ever happen? I'm not able to copy and paste this from evolution with even the recommended preformatted option enabled. How I could ever submit any further patches? > How can I ever know when they were really added and if they went through > patchwork :) So I tried several editors and did still provide such BS. The last time I remember to have seen such was in 2005 with SECAM L' and it was going on over half a year. Cheers, Hermann -- 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: how about adding FOCUS mode?
Hi,
2009. 03. 28, 오전 1:19, Laurent Pinchart 작성:
Hi,
On Friday 27 March 2009 08:24:27 Hans Verkuil wrote:
On Friday 27 March 2009 07:20:51 Kim, Heung Jun wrote:
Hello, Hans & everyone.
I'm trying to adapt the various FOCUS MODE int the NEC ISP driver.
NEC ISP supports 4 focus mode, AUTO/MACRO/MANUAL/FULL or NORMAL.
but, i think that it's a little insufficient to use V4L2 FOCUS
Feature.
so, suggest that,
- change V4L2_CID_FOCUS_AUTO's type from boolean to interger, and
add
the following enumerations for CID values.
enum v4l2_focus_mode {
V4L2_FOCUS_AUTO= 0,
V4L2_FOCUS_MACRO= 1,
V4L2_FOCUS_MANUAL= 2,
V4L2_FOCUS_NORMAL= 3,
V4L2_FOCUS_LASTP= 3,
};
how about this usage? i wanna get some advice about FOCUS MODE.
V4L2_CID_FOCUS_AUTO is meant to change the auto-focus mode. Can you
describe
FOCUS_MACRO and FOCUS_NORMAL in more details ? Are they auto-focus
modes or
just focus presets ?
As far as I know, they represent focus lens movement range.
If you set to AF macro, focus lens scans near range first, so that
focusing movement could finish earlier.
This seems more logical to me:
enum v4l2_focus_mode {
V4L2_FOCUS_MANUAL = 0,
V4L2_FOCUS_AUTO_NORMAL = 1,
V4L2_FOCUS_AUTO_MACRO = 2,
};
At least this maps the current boolean values correctly. I'm not
sure from
your decription what the fourth auto focus mode is supposed to be.
Does an auto-macro focus mode really exists ?
Sure, you can find in some digital camera or brand new high end camera
phones.
By the way, sorry for answering instead of heungjun Kim. I work with
him actually.
Is it OK?
Cheers,
Nate
But I think it might be better to have a separate control that
allows you
to set the auto-focus mode. I can imagine that different devices
might have
different auto-focus modes.
I've CC-ed Laurent since this is more his field than mine.
Regards,
Laurent Pinchart
--
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 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: [RFC][PATCH 1/2] Sensor orientation reporting
On Friday 27 Mar 2009, Mauro Carvalho Chehab wrote: > On Sun, 15 Mar 2009 22:29:48 + > > Adam Baker wrote: > > Add support to the SQ-905 driver to pass back to user space the > > sensor orientation information obtained from the camera during init. > > Modifies gspca and the videodev2.h header to create the necessary > > API. > > Please provide also the V4L2 specs change to include those new controls. I hadn't forgotten this, it was just taking rather longer than expected to put together a working build system for the documentation (In the end I concluded the quickest approach was a complete OS upgrade to get working versions of the docbook tools and config files). Adam -- 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
[PULL] http://hg.jannau.net/hdpvr-merge/
Hi Mauro, please pull from http://hg.jannau.net/hdpvr-merge/ for hdpvr: add struct v4l2_device hdpvr: convert printing macros to v4l2_* with struct v4l2_device hdpvr: empty internal device buffer after stopping streaming hdpvr-control.c | 22 +++--- hdpvr-core.c| 65 + hdpvr-video.c | 87 +--- hdpvr.h |4 ++ 4 files changed, 114 insertions(+), 64 deletions(-) thanks, Janne -- 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: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz
Hi, Am Freitag, den 27.03.2009, 07:38 -0300 schrieb Mauro Carvalho Chehab: > On Fri, 27 Mar 2009 02:39:07 +0100 > hermann pitton wrote: > > > But my main concern is, if it once arrived at patchwork formally, it is > > out of sight for most of us and might miss proper review, except you are > > sure you can always guarantee that. I don't want to start to argue about > > all what happened in the past. > > > > So, at least, if some patch arrived there mysteriously ;), the > > linux-media list should be informed that it is there now and last time > > to speak off, in case anything is not fully clear, before vanishing into > > some black hole until you find it in the next kernel release ... > > The only way to send patches to patchwork is to submit it via linux-media > list. > There's no other way. So, all patch discussions and reviews should happen at > the ML, by replying at the patch email (or by replying another reply). > Patchwork will keep track of such replies as well. > What happened so far with this patches is quite funny, for me some black hole seems to be involved. Klaas did send them the first time, also directly to me, on Tue, 24 Mar 2009 23:14:11 +0100. Now I can see you have pulled them in already on Wednesday. http://linuxtv.org/hg/v4l-dvb/rev/5efa9fbc8a88 There is no trace anymore on patchwork visible to me. http://patchwork.kernel.org/project/linux-media/list So I don't know how you processed them. Most confusing is, that Klaas obviously did not receive a mail notification from linuxtv-commits that his patch came in. Last message date: Fri Feb 15 19:45:02 CET 2008 Archived on: Fri Feb 15 19:45:04 CET 2008 Is it broken or only the archive not up to date? Why else he would have posted a second time on Wed, 25 Mar 2009 21:53:02 +0100 not knowing anything about the status of his patches, which made me believe I should try to help him? The timestamp on your mercurial commit of them is Wed Mar 25 20:53:02 2009 + (2 days ago) That is the time when his second email arrived converted to Greenwich time? Or how could you commit within the same second that mail arrived? This is the time the patches have on both of his original mails. --- a/linux/drivers/media/common/tuners/tda827x.c Tue Mar 24 21:12:47 2009 + --- a/linux/drivers/media/common/tuners/tda827x.c Tue Mar 24 21:12:47 2009 + How can I ever know when they were really added and if they went through patchwork :) I was just about to suggest Klaas should try again with [PATCH] in the subject until they are listed at patchwork. Cheers, Hermann -- 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] v4l2: fill reserved fields of VIDIOC_ENUMAUDIO also
On Fri, 27 Mar 2009, Hans Verkuil wrote: > On Friday 27 March 2009 20:45:40 Trent Piepho wrote: > > On Fri, 27 Mar 2009, Mauro Carvalho Chehab wrote: > > > On Wed, 25 Mar 2009 17:51:39 +0100 > > > > > > N?meth M?rton wrote: > > > > From: M?rton N?meth > > > > > > > > When enumerating audio inputs with VIDIOC_ENUMAUDIO the gspca_sunplus > > > > driver does not fill the reserved fields of the struct v4l2_audio > > > > with zeros as required by V4L2 API revision 0.24 [1]. Add the missing > > > > initializations to the V4L2 framework. > > > > > > > > The patch was tested with v4l-test 0.10 [2] with gspca_sunplus driver > > > > and with Trust 610 LCD pow...@m ZOOM webcam. > > > > > > It didn't apply against the development tree. Anyway, a recent patch > > > removed the need of memset there. the memory fill with zero now happens > > > at the same code we copy the structure values. > > > > That code is in video_ioctl2, which gspca doesn't use. > > Yes, gspca does use video_ioctl2. You're probably confused with uvcvideo, > which doesn't use it. You're right, I was thinking about N?meth's earlier patches for the same things in uvcvideo. This patch wasn't for gspca anyway, it was for the v4l2 core, and Mauro's right it's not necessary as my patch series fixed all these problems. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l parent for usb device interface or device?
On Thu, Mar 26, 2009 at 06:31:55PM -0700, David Brownell wrote:
> On Thursday 26 March 2009, Janne Grunau wrote:
>
> > I noticed a problem after
> > changing the hdpvr driver accordingly.
> >
> > With parent set to the usb interface there is no longer easy access to
> > the usb device properties like the serial number through sysfs. I know
> > that a couple of user with more than one device use the serial number
> > to set static device nodes through udev.
>
> The serial number is still available, but it's coupled to the USB
> device not its interface. Make your udev script hop up a level or
> two in the driver model tree, as appropriate.
yes, ATTRS{} still matches. There are udev howtos around which suggest
ATTRS{} just matches one level up and not the entire path. I tried it but
had unfortunately a typo in the udev rule. Sorry for the noise.
Janne
--
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] v4l2: fill reserved fields of VIDIOC_ENUMAUDIO also
On Friday 27 March 2009 20:45:40 Trent Piepho wrote: > On Fri, 27 Mar 2009, Mauro Carvalho Chehab wrote: > > On Wed, 25 Mar 2009 17:51:39 +0100 > > > > Németh Márton wrote: > > > From: Márton Németh > > > > > > When enumerating audio inputs with VIDIOC_ENUMAUDIO the gspca_sunplus > > > driver does not fill the reserved fields of the struct v4l2_audio > > > with zeros as required by V4L2 API revision 0.24 [1]. Add the missing > > > initializations to the V4L2 framework. > > > > > > The patch was tested with v4l-test 0.10 [2] with gspca_sunplus driver > > > and with Trust 610 LCD pow...@m ZOOM webcam. > > > > It didn't apply against the development tree. Anyway, a recent patch > > removed the need of memset there. the memory fill with zero now happens > > at the same code we copy the structure values. > > That code is in video_ioctl2, which gspca doesn't use. Yes, gspca does use video_ioctl2. You're probably confused with uvcvideo, which doesn't use it. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH resend] DVB: firedtv: FireDTV S2 problems with tuning solved
This came in via linux1394-devel. If there are no objections, I'll include it in my pull request to Linus which I want to send in a few hours. It's also good to send to stable. Date: Thu, Mar 26, 2009 22:36:52 +0100 (CET) From: Beat Michel Liechti Subject: DVB: firedtv: FireDTV S2 problems with tuning solved Signed-off-by: Beat Michel Liechti Tuning was broken on FireDTV S2 (and presumably FloppyDTV S2) because a wrong opcode was sent. The box only gave "not implemented" responses. Changing the opcode to _TUNE_QPSK2 fixes this for good. Cc: sta...@kernel.org Signed-off-by: Stefan Richter --- drivers/media/dvb/firewire/firedtv-avc.c |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) Index: linux/drivers/media/dvb/firewire/firedtv-avc.c === --- linux.orig/drivers/media/dvb/firewire/firedtv-avc.c +++ linux/drivers/media/dvb/firewire/firedtv-avc.c @@ -135,6 +135,7 @@ static const char *debug_fcp_opcode(unsi case SFE_VENDOR_OPCODE_REGISTER_REMOTE_CONTROL: return "RegisterRC"; case SFE_VENDOR_OPCODE_LNB_CONTROL: return "LNBControl"; case SFE_VENDOR_OPCODE_TUNE_QPSK: return "TuneQPSK"; + case SFE_VENDOR_OPCODE_TUNE_QPSK2: return "TuneQPSK2"; case SFE_VENDOR_OPCODE_HOST2CA: return "Host2CA"; case SFE_VENDOR_OPCODE_CA2HOST: return "CA2Host"; } @@ -266,7 +267,10 @@ static void avc_tuner_tuneqpsk(struct fi c->operand[0] = SFE_VENDOR_DE_COMPANYID_0; c->operand[1] = SFE_VENDOR_DE_COMPANYID_1; c->operand[2] = SFE_VENDOR_DE_COMPANYID_2; - c->operand[3] = SFE_VENDOR_OPCODE_TUNE_QPSK; + if (fdtv->type == FIREDTV_DVB_S2) + c->operand[3] = SFE_VENDOR_OPCODE_TUNE_QPSK2; + else + c->operand[3] = SFE_VENDOR_OPCODE_TUNE_QPSK; c->operand[4] = (params->frequency >> 24) & 0xff; c->operand[5] = (params->frequency >> 16) & 0xff; -- Stefan Richter -=-==--= --== ==-== http://arcgraph.de/sr/ -- 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] v4l2: fill reserved fields of VIDIOC_ENUMAUDIO also
On Fri, 27 Mar 2009, Mauro Carvalho Chehab wrote: > On Wed, 25 Mar 2009 17:51:39 +0100 > N?meth M?rton wrote: > > > From: M?rton N?meth > > > > When enumerating audio inputs with VIDIOC_ENUMAUDIO the gspca_sunplus driver > > does not fill the reserved fields of the struct v4l2_audio with zeros as > > required by V4L2 API revision 0.24 [1]. Add the missing initializations to > > the V4L2 framework. > > > > The patch was tested with v4l-test 0.10 [2] with gspca_sunplus driver and > > with Trust 610 LCD pow...@m ZOOM webcam. > > It didn't apply against the development tree. Anyway, a recent patch removed > the need of memset there. the memory fill with zero now happens at the same > code we copy the structure values. That code is in video_ioctl2, which gspca doesn't use. -- 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: [RFC][PATCH 1/2] Sensor orientation reporting
On Sun, 15 Mar 2009 22:29:48 +
Adam Baker wrote:
> Add support to the SQ-905 driver to pass back to user space the
> sensor orientation information obtained from the camera during init.
> Modifies gspca and the videodev2.h header to create the necessary
> API.
>
> Signed-off-by: Adam Baker
>
> ---
[snip]
> diff -r 1248509d8bed linux/drivers/media/video/gspca/gspca.h
> --- a/linux/drivers/media/video/gspca/gspca.h Sat Mar 14
> 08:44:42 2009 +0100
> +++ b/linux/drivers/media/video/gspca/gspca.h Sun Mar 15
> 22:25:34 2009 +
> @@ -168,6 +168,7 @@ struct gspca_dev {
> __u8 alt; /* USB alternate setting */
> __u8 nbalt; /* number of USB alternate settings */
>u8 bulk; /* image transfer by 0:isoc / 1:bulk
> */
> + u32 input_flags;/* value for ENUM_INPUT status flags
> */ };
[snip]
Hi Adam,
This 'input_flags' should better go to the 'struct cam' (line 59).
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
[cron job] v4l-dvb daily build 2.6.22 and up: WARNINGS, 2.6.16-2.6.21: 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 Mar 27 19:00:06 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11244:b1596c6517c9 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29-armv5: OK linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29-armv5-omap2: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29-m32r: OK linux-2.6.22.19-mips: OK linux-2.6.26-mips: WARNINGS linux-2.6.27-mips: WARNINGS linux-2.6.28-mips: WARNINGS linux-2.6.29-mips: WARNINGS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.11-x86_64: WARNINGS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: WARNINGS linux-2.6.28-x86_64: WARNINGS linux-2.6.29-x86_64: WARNINGS fw/apps: WARNINGS sparse (linux-2.6.29): ERRORS linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS 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 V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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: use usb interface as parent
On Fri, 27 Mar 2009 10:35:43 +0100 Hans de Goede wrote: > Hi all, Hi Hans, > As discussed in the: > "v4l parent for usb device interface or device?" > thread, here is a patch for gspca to make it use > the usb interface as its parent device, instead > of the usb device. [snip] Applied, thanks. This patch may solve the microphone problem that some people have... 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] Remove debug output from stb6100_cfg.h
Mauro Carvalho Chehab wrote:
> Manu,
>
> If ok to you, please ack.
>
> On Thu, 26 Mar 2009 10:45:53 +0100
> Artem Makhutov wrote:
>
> This patch removes the debug output from stb6100_cfg.h as it is flooding
> the syslog with tuning data during normal operation.
>
> Signed-off-by: Artem Makhutov
>
Looks okay,
Acked-by: Manu Abraham
> --- linux.old/drivers/media/dvb/frontends/stb6100_cfg.h 2009-03-26
> 10:28:57.0 +0100
> +++ linux/drivers/media/dvb/frontends/stb6100_cfg.h 2009-03-26
> 10:29:52.0 +0100
> @@ -36,7 +36,6 @@
> return err;
> }
> *frequency = t_state.frequency;
> - printk("%s: Frequency=%d\n", __func__, t_state.frequency);
> }
> return 0;
> }
> @@ -59,7 +58,6 @@
> return err;
> }
> }
> - printk("%s: Frequency=%d\n", __func__, t_state.frequency);
> return 0;
> }
>
> @@ -81,7 +79,6 @@
> }
> *bandwidth = t_state.bandwidth;
> }
> - printk("%s: Bandwidth=%d\n", __func__, t_state.bandwidth);
> return 0;
> }
>
> @@ -103,6 +100,5 @@
> return err;
> }
> }
> - printk("%s: Bandwidth=%d\n", __func__, t_state.bandwidth);
> return 0;
> }
>
--
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 review] gspca - mr97310a: return error instead of -1 in sd_mod_init
On Fri, 27 Mar 2009 19:08:22 +0300 Alexey Klimov wrote: > Hello, Jean-Francois > > What do you think about such small cleanup ? > > --- > Patch reformats sd_mod_init in the way to make it return error code > from usb_register instead of -1. > > Signed-off-by: Alexey Klimov [snip] Applied. Thanks. -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
Devin Heitmueller wrote: > On Wed, Mar 25, 2009 at 6:02 PM, Manu Abraham wrote: >> Sure, of course. Here is an updated list based on the information >> that you accumulated. I have corrected some of them, which were not >> accurate. > > Before I comment any further on your email, could you please clarify > what you mean by "Relative, confirms to API". The current DVB API > specification does not specify any units of measure for the content of > the field, so I am not sure what you mean by this. Sorry about not responding earlier, wasn't feeling well at all and hence. By Relative, i meant dimensionless, but still it makes some sense based on some documented references. What i mean "relative" is that the API expects something like this. http://linuxtv.org/hg/dvb-apps/file/5fbdd3f898b1/util/szap/README Regards, Manu -- 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
[PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/
Hi Mauro, Please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb/ for: changeset: 11224:2258bd92f522 gspca - vc032x: Remove the JPEG tables of mi1320_soc. changeset: 11225:ea6d8f0cd083 gspca - m5602-s5k4aa: No more "default" mode changeset: 11226:630fa8f75f42 gspca - m5602-s5k4aa: Add start function and VGA resolution init. changeset: 11227:7b14d00aa61c gspca - m5602: Simplify error handling changeset: 11228:89647a4acf75 gspca - m5602-ov9650: Add QCIF resolution support changeset: 11229:7578294f06cd gspca - m5602-ov9650: Clean up ov9650_start() function. changeset: 11230:8863f4fdf25e gspca - m5602-s5k83a: Add led support to the s5k83a sensor. changeset: 11231:817e36da4fd9 gspca - m5602-ov9650: Set the ov9650 sensor in soft sleep when inactive. changeset: 11232:9d0a113a28a4 gspca - m5602-ov9650: Always init the ov9650 before starting a stream changeset: 11233:871b2546315d gspca - m5602: Rework v4l ctrl handling in all sensors changeset: 11234:04c1227d412f gspca - m5602-ov9650: Checkpatch fixes changeset: 11235:089b896afa94 gspca - m5602-mt9m111: Separate mode vectors per sensor. changeset: 11236:531f8383ff70 gspca - m5602-mt9m111: Move v4l2 controls to main sensor file. changeset: 11237:ea5335dfb00e gspca - m5602: Remove an unused member in the sd struct. changeset: 11238:f915d64a686e gspca - m5602: Constify all sensor structs changeset: 11239:be006d6783fb gspca - m5602-ov9650: Autogain is on by default changeset: 11240:ad9622150aea gspca - m5602-ov9650: Auto white balancing is on by default changeset: 11241:82263c1cbdee gspca - m5602-ov9650: Don't read exposure data from COM1. changeset: 11242:a640fe97ac35 gspca - m5602: Improve error handling in the ov9650 driver changeset: 11243:9d70484bfca5 gspca - m5602-ov9650: Synthesize modesetting. changeset: 11244:dc66997ccf36 gspca - m5602-ov9650: Replace a magic constant with a define changeset: 11245:ecbaf91c8745 gspca - m5602-ov9650: Add a disconnect hook, setup a ctrl cache ctrl. changeset: 11246:0310786ebedc gspca - m5602-ov9650: Use the local ctrl cache. Adjust image on vflip. changeset: 11247:1bebd29cecc3 gspca - m5602: Move the vflip quirk to probe stage. changeset: 11248:6b4f4f173a66 gspca - m5602: Don't touch hflip/vflip register on Read/Modify/Write changeset: 11249:7c1aa8d0507f gspca - m5602: Minor cleanups 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 implementing V4L2_CAP_STREAMING for zr364xx driver
Here is the patch with the modifications you asked.
Em Friday 27 March 2009, Mauro Carvalho Chehab escreveu:
> On Wed, 25 Mar 2009 20:25:10 -0300
>
> Lamarque Vieira Souza wrote:
> > Hi,
> >
> > I have implemented V4L2_CAP_STREAMING for the zr364xx driver (see
> > the attached file). Could you review the code for me? My
> > Creative PC-CAM 880 works, but I do not have any other webcam to test the
> > code. Besides the streaming implementation the patch also does:
> >
> > . re-implement V4L2_CAP_READWRITE using videobuf.
> >
> > . copy cam->udev->product to the card field of the v4l2_capability
> > struct. That gives more information to the users about the webcam.
> >
> > . move the brightness setting code from before requesting a frame (in
> > read_frame) to the vidioc_s_ctrl ioctl. This way the brightness code is
> > executed only when the application request a change in brightness and not
> > before every frame read. Is there any reason to set the brightness before
> > every frame read?
> >
> > . comment part of zr364xx_vidioc_try_fmt_vid_cap. Skype + libv4l do not
> > work if it is there and libv4's maintainer told me it is a driver bug, so
> > I fix it.
> >
> > This patch is needed for applications such as mplayer, Kopete+libv4l and
> > Skype+libv4l can make use of the webcam that comes with zr364xx chip. The
> > patch is big, if you need it splitted into small patches I can do it.
>
> Your patch didn't apply:
>
> patching file drivers/media/video/zr364xx.c
> Hunk #4 FAILED at 37.
> Hunk #5 succeeded at 114 (offset 2 lines).
> Hunk #7 succeeded at 474 (offset 2 lines).
> Hunk #9 succeeded at 782 (offset 2 lines).
> Hunk #11 succeeded at 848 (offset 2 lines).
> Hunk #13 succeeded at 918 (offset 2 lines).
> Hunk #15 succeeded at 1198 (offset 2 lines).
> Hunk #17 succeeded at 1242 (offset 2 lines).
> Hunk #19 succeeded at 1373 (offset 2 lines).
> Hunk #21 succeeded at 1409 (offset 2 lines).
> Hunk #23 succeeded at 1532 (offset 2 lines).
> 1 out of 24 hunks FAILED -- saving rejects to file
> drivers/media/video/zr364xx.c.rej Patch doesn't apply
>
> Probably because you didn't generate it against the development tree. Could
> you please re-generate it against: http://linuxtv.org/hg/v4l-dvbg/v4l-dvb
>
> The better is to clone it using:
> hg clone http://linuxtv.org/hg/v4l-dvb
>
>
> Also, please test it against checkpatch tool, since there are a few coding
> style issues like:
>
> }
> else {
>
> and
> if (foo)
> {
>
> Violating Linux codingstyle. For more info, please read the README.patches
> file at the tree.
>
> > Lamarque V. Souza
> > http://www.geographicguide.com/brazil.htm
> > Linux User #57137 - http://counter.li.org/
>
> Legal! outro brasileiro na lista! Bem vindo ao time.
Hehe, obrigado.
--
Lamarque V. Souza
http://www.geographicguide.com/brazil.htm
Linux User #57137 - http://counter.li.org/
--- v4l-dvb/linux/drivers/media/video/zr364xx.c 2009-03-27 15:18:54.050413997 -0300
+++ v4l-dvb/linux-lvs/drivers/media/video/zr364xx.c 2009-03-27 15:22:47.914414277 -0300
@@ -1,5 +1,5 @@
/*
- * Zoran 364xx based USB webcam module version 0.72
+ * Zoran 364xx based USB webcam module version 0.73
*
* Allows you to use your USB webcam with V4L2 applications
* This is still in heavy developpement !
@@ -10,6 +10,8 @@
* Heavily inspired by usb-skeleton.c, vicam.c, cpia.c and spca50x.c drivers
* V4L2 version inspired by meye.c driver
*
+ * Some video buffer code by Lamarque based on s2255drv.c and vivi.c drivers.
+ *
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
@@ -25,7 +27,6 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
-
#include
#include
#include
@@ -36,25 +37,34 @@
#include
#include
#include
+#include
#include "compat.h"
/* Version Information */
-#define DRIVER_VERSION "v0.72"
+#define DRIVER_VERSION "v0.73"
+#define ZR364_VERSION_CODE KERNEL_VERSION(0, 7, 3)
#define DRIVER_AUTHOR "Antoine Jacquet, http://royale.zerezo.com/";
#define DRIVER_DESC "Zoran 364xx"
/* Camera */
-#define FRAMES 2
+#define FRAMES 1
#define MAX_FRAME_SIZE 10
#define BUFFER_SIZE 0x1000
#define CTRL_TIMEOUT 500
+#define ZR364XX_DEF_BUFS 4
+#define ZR364XX_READ_IDLE 0
+#define ZR364XX_READ_FRAME 1
/* Debug macro */
-#define DBG(x...) if (debug) printk(KERN_INFO KBUILD_MODNAME x)
-
+#define DBG(fmt, args...) \
+ do { \
+ if (debug) { \
+ printk(KERN_INFO KBUILD_MODNAME " " fmt, ##args); \
+ } \
+ } while (0)
/* Init methods, need to find nicer names for these
* the exact names of the chipsets would be the best if someone finds it */
@@ -103,24 +113,97 @@ static struct usb_device_id device_table
MODULE_DEVICE_TABLE(usb, device_table);
+struct zr364xx_mode {
+ u32 color; /* output video color format */
+ u
Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Wed, Mar 25, 2009 at 6:27 PM, Devin Heitmueller wrote: > Before I comment any further on your email, could you please clarify > what you mean by "Relative, confirms to API". The current DVB API > specification does not specify any units of measure for the content of > the field, so I am not sure what you mean by this. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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
topro 6800 driver
Hello. Today I became to be (un)happy owner of 06a2:0003 device. I found nice discussion here in this list, but I've just subscribed to it. So, I have some free time to test and improve existent code. If I will be helpful, tell me, please! (I'm using Fedora 9, but I could compile any additional driver for that 2.6.27.15 kernel) -- With Best Regards, Andy Shevchenko -- 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: [question] about open/release and vidioc_g_input/vidioc_s_input functions
On Friday 27 March 2009 18:34:01 Alexey Klimov wrote:
> On Fri, Mar 27, 2009 at 7:50 PM, Hans Verkuil wrote:
> > On Friday 27 March 2009 17:44:05 Alexey Klimov wrote:
> >> Hello, Hans
> >>
> >> On Tue, 2009-03-24 at 08:06 +0100, Hans Verkuil wrote:
> >> > On Tuesday 24 March 2009 00:14:07 Alexey Klimov wrote:
> >> > > Hello, all
> >> > >
> >> > > ...
> >> > > static int terratec_open(struct file *file)
> >> > > {
> >> > > return 0;
> >> > > }
> >> > >
> >> > > static int terratec_release(struct file *file)
> >> > > {
> >> > > return 0;
> >> > > }
> >> > > ...
> >> > >
> >> > > ...
> >> > >
> >> > > Such code used in many radio-drivers as i understand.
> >> > >
> >> > > Is it good to place this empty and almost empty functions in:
> >> > > (here i see two variants)
> >> > >
> >> > > 1) In header file that be in linux/drivers/media/radio/ directory.
> >> > > Later, we can move some generic/or repeating code in this header.
> >> > >
> >> > > 2) In any v4l header. What header may contain this ?
> >> > >
> >> > > ?
> >> > >
> >> > > For what ? Well, as i understand we can decrease amount of lines
> >> > > and provide this simple generic functions. It's like
> >> > > video_device_release_empty function behaviour. Maybe not only
> >> > > radio drivers can use such vidioc_g_input and vidioc_s_input.
> >> > >
> >> > > Is it worth ?
> >> >
> >> > I don't think it is worth doing this for g/s_input. I think it is
> >> > useful to have them here: it makes it very clear that there is just
> >> > a single input and the overhead in both lines and actual bytes is
> >> > minimal.
> >> >
> >> > But for the empty open and release functions you could easily handle
> >> > that in v4l2-dev.c: if you leave the open and release callbacks to
> >> > NULL, then v4l2_open and v4l2_release can just return 0. That would
> >> > be nice.
> >> >
> >> > Regards,
> >> >
> >> > Hans
> >>
> >> May i ask help with this ?
> >> Hans, should it be looks like:
> >>
> >> diff -r 56cf0f1772f7 linux/drivers/media/radio/radio-terratec.c
> >> --- a/linux/drivers/media/radio/radio-terratec.c Mon Mar 23
> >> 19:18:34 2009 -0300 +++ b/linux/drivers/media/radio/radio-terratec.c
> >> Fri Mar 27 19:32:38 2009 +0300 @@ -333,20 +333,8 @@
> >> return a->index ? -EINVAL : 0;
> >> }
> >>
> >> -static int terratec_open(struct file *file)
> >> -{
> >> - return 0;
> >> -}
> >> -
> >> -static int terratec_release(struct file *file)
> >> -{
> >> - return 0;
> >> -}
> >> -
> >> static const struct v4l2_file_operations terratec_fops = {
> >> .owner = THIS_MODULE,
> >> - .open = terratec_open,
> >> - .release= terratec_release,
> >> .ioctl = video_ioctl2,
> >> };
> >>
> >> diff -r 56cf0f1772f7 linux/drivers/media/video/v4l2-dev.c
> >> --- a/linux/drivers/media/video/v4l2-dev.cMon Mar 23 19:18:34 2009
> >> -0300 +++ b/linux/drivers/media/video/v4l2-dev.cFri Mar 27
> >> 19:32:38 2009 +0300 @@ -264,7 +264,10 @@
> >> /* and increase the device refcount */
> >> video_get(vdev);
> >> mutex_unlock(&videodev_lock);
> >> - ret = vdev->fops->open(filp);
> >> + if (vdev->fops->open == NULL)
> >> + ret = 0;
> >> + else
> >> + ret = vdev->fops->open(filp);
> >> /* decrease the refcount in case of an error */
> >> if (ret)
> >> video_put(vdev);
> >> @@ -275,7 +278,12 @@
> >> static int v4l2_release(struct inode *inode, struct file *filp)
> >> {
> >> struct video_device *vdev = video_devdata(filp);
> >> - int ret = vdev->fops->release(filp);
> >> + int ret;
> >> +
> >> + if (vdev->fops->release == NULL)
> >> + ret = 0;
> >> + else
> >> + ret = vdev->fops->release(filp);
> >>
> >> /* decrease the refcount unconditionally since the release()
> >> return value is ignored. */
> >>
> >> ?
> >>
> >> Or in v4l2_open function i can check if vdev->fops->open == NULL
> >> before video_get(vdev); (increasing the device refcount), and if it's
> >> NULL then unlock_mutex and return 0 ?
> >> And the same in v4l2_release - just return 0 in the begining of
> >> function in case vdev->fops->release == NULL ?
> >>
> >> What approach is better ?
> >
> > This is simpler:
> >
> > diff -r 2e0c6ff1bda3 linux/drivers/media/video/v4l2-dev.c
> > --- a/linux/drivers/media/video/v4l2-dev.c Mon Mar 23 19:01:18
> > 2009 +0100
> > +++ b/linux/drivers/media/video/v4l2-dev.c Fri Mar 27 17:47:51
> > 2009 +0100
> > @@ -250,7 +250,7 @@
> > static int v4l2_open(struct inode *inode, struct file *filp)
> > {
> >struct video_device *vdev;
> > - int ret;
> > + int ret = 0;
> >
> >/* Check if the video device is available */
> >mutex_lock(&videodev_lock);
> > @@ -264,7 +264,9 @@
> >/* and increase the device refcount */
> >video_get(vdev);
> >mutex_unlock(&videodev_lock);
> > - ret = vdev->fops->op
Re: [question] about open/release and vidioc_g_input/vidioc_s_input functions
On Fri, Mar 27, 2009 at 7:50 PM, Hans Verkuil wrote:
> On Friday 27 March 2009 17:44:05 Alexey Klimov wrote:
>> Hello, Hans
>>
>> On Tue, 2009-03-24 at 08:06 +0100, Hans Verkuil wrote:
>> > On Tuesday 24 March 2009 00:14:07 Alexey Klimov wrote:
>> > > Hello, all
>> > >
>> > > ...
>> > > static int terratec_open(struct file *file)
>> > > {
>> > > return 0;
>> > > }
>> > >
>> > > static int terratec_release(struct file *file)
>> > > {
>> > > return 0;
>> > > }
>> > > ...
>> > >
>> > > ...
>> > >
>> > > Such code used in many radio-drivers as i understand.
>> > >
>> > > Is it good to place this empty and almost empty functions in:
>> > > (here i see two variants)
>> > >
>> > > 1) In header file that be in linux/drivers/media/radio/ directory.
>> > > Later, we can move some generic/or repeating code in this header.
>> > >
>> > > 2) In any v4l header. What header may contain this ?
>> > >
>> > > ?
>> > >
>> > > For what ? Well, as i understand we can decrease amount of lines and
>> > > provide this simple generic functions. It's like
>> > > video_device_release_empty function behaviour. Maybe not only radio
>> > > drivers can use such vidioc_g_input and vidioc_s_input.
>> > >
>> > > Is it worth ?
>> >
>> > I don't think it is worth doing this for g/s_input. I think it is
>> > useful to have them here: it makes it very clear that there is just a
>> > single input and the overhead in both lines and actual bytes is
>> > minimal.
>> >
>> > But for the empty open and release functions you could easily handle
>> > that in v4l2-dev.c: if you leave the open and release callbacks to
>> > NULL, then v4l2_open and v4l2_release can just return 0. That would be
>> > nice.
>> >
>> > Regards,
>> >
>> > Hans
>>
>> May i ask help with this ?
>> Hans, should it be looks like:
>>
>> diff -r 56cf0f1772f7 linux/drivers/media/radio/radio-terratec.c
>> --- a/linux/drivers/media/radio/radio-terratec.c Mon Mar 23 19:18:34
>> 2009
>> -0300 +++ b/linux/drivers/media/radio/radio-terratec.cFri Mar 27
>> 19:32:38 2009 +0300 @@ -333,20 +333,8 @@
>> return a->index ? -EINVAL : 0;
>> }
>>
>> -static int terratec_open(struct file *file)
>> -{
>> - return 0;
>> -}
>> -
>> -static int terratec_release(struct file *file)
>> -{
>> - return 0;
>> -}
>> -
>> static const struct v4l2_file_operations terratec_fops = {
>> .owner = THIS_MODULE,
>> - .open = terratec_open,
>> - .release= terratec_release,
>> .ioctl = video_ioctl2,
>> };
>>
>> diff -r 56cf0f1772f7 linux/drivers/media/video/v4l2-dev.c
>> --- a/linux/drivers/media/video/v4l2-dev.cMon Mar 23 19:18:34 2009 -0300
>> +++ b/linux/drivers/media/video/v4l2-dev.cFri Mar 27 19:32:38 2009 +0300
>> @@ -264,7 +264,10 @@
>> /* and increase the device refcount */
>> video_get(vdev);
>> mutex_unlock(&videodev_lock);
>> - ret = vdev->fops->open(filp);
>> + if (vdev->fops->open == NULL)
>> + ret = 0;
>> + else
>> + ret = vdev->fops->open(filp);
>> /* decrease the refcount in case of an error */
>> if (ret)
>> video_put(vdev);
>> @@ -275,7 +278,12 @@
>> static int v4l2_release(struct inode *inode, struct file *filp)
>> {
>> struct video_device *vdev = video_devdata(filp);
>> - int ret = vdev->fops->release(filp);
>> + int ret;
>> +
>> + if (vdev->fops->release == NULL)
>> + ret = 0;
>> + else
>> + ret = vdev->fops->release(filp);
>>
>> /* decrease the refcount unconditionally since the release()
>> return value is ignored. */
>>
>> ?
>>
>> Or in v4l2_open function i can check if vdev->fops->open == NULL before
>> video_get(vdev); (increasing the device refcount), and if it's NULL then
>> unlock_mutex and return 0 ?
>> And the same in v4l2_release - just return 0 in the begining of function
>> in case vdev->fops->release == NULL ?
>>
>> What approach is better ?
>
> This is simpler:
>
> diff -r 2e0c6ff1bda3 linux/drivers/media/video/v4l2-dev.c
> --- a/linux/drivers/media/video/v4l2-dev.c Mon Mar 23 19:01:18 2009
> +0100
> +++ b/linux/drivers/media/video/v4l2-dev.c Fri Mar 27 17:47:51 2009
> +0100
> @@ -250,7 +250,7 @@
> static int v4l2_open(struct inode *inode, struct file *filp)
> {
>struct video_device *vdev;
> - int ret;
> + int ret = 0;
>
>/* Check if the video device is available */
>mutex_lock(&videodev_lock);
> @@ -264,7 +264,9 @@
>/* and increase the device refcount */
>video_get(vdev);
>mutex_unlock(&videodev_lock);
> - ret = vdev->fops->open(filp);
> + if (vdev->fops->open)
> + ret = vdev->fops->open(filp);
> +
>/* decrease the refcount in case of an error */
>if (ret)
>video_put(vdev);
> @@ -275,7 +277,10 @@
> static int v4l2_release(struct inode *inode, struct file *filp)
> {
>struct video_device *vdev = v
Re: [RFC][PATCH 1/2] Sensor orientation reporting
On Sun, 15 Mar 2009 22:29:48 +
Adam Baker wrote:
> Add support to the SQ-905 driver to pass back to user space the
> sensor orientation information obtained from the camera during init.
> Modifies gspca and the videodev2.h header to create the necessary
> API.
Please provide also the V4L2 specs change to include those new controls.
>
> Signed-off-by: Adam Baker
>
> ---
> diff -r 1248509d8bed linux/drivers/media/video/gspca/gspca.c
> --- a/linux/drivers/media/video/gspca/gspca.c Sat Mar 14 08:44:42 2009 +0100
> +++ b/linux/drivers/media/video/gspca/gspca.c Sun Mar 15 22:25:34 2009 +
> @@ -1147,6 +1147,7 @@ static int vidioc_enum_input(struct file
> if (input->index != 0)
> return -EINVAL;
> input->type = V4L2_INPUT_TYPE_CAMERA;
> + input->status = gspca_dev->input_flags;
> strncpy(input->name, gspca_dev->sd_desc->name,
> sizeof input->name);
> return 0;
> diff -r 1248509d8bed linux/drivers/media/video/gspca/gspca.h
> --- a/linux/drivers/media/video/gspca/gspca.h Sat Mar 14 08:44:42 2009 +0100
> +++ b/linux/drivers/media/video/gspca/gspca.h Sun Mar 15 22:25:34 2009 +
> @@ -168,6 +168,7 @@ struct gspca_dev {
> __u8 alt; /* USB alternate setting */
> __u8 nbalt; /* number of USB alternate settings */
> u8 bulk;/* image transfer by 0:isoc / 1:bulk */
> + u32 input_flags;/* value for ENUM_INPUT status flags */
> };
>
> int gspca_dev_probe(struct usb_interface *intf,
> diff -r 1248509d8bed linux/drivers/media/video/gspca/sq905.c
> --- a/linux/drivers/media/video/gspca/sq905.c Sat Mar 14 08:44:42 2009 +0100
> +++ b/linux/drivers/media/video/gspca/sq905.c Sun Mar 15 22:25:34 2009 +
> @@ -357,6 +357,12 @@ static int sd_init(struct gspca_dev *gsp
> gspca_dev->cam.nmodes = ARRAY_SIZE(sq905_mode);
> if (!(ident & SQ905_HIRES_MASK))
> gspca_dev->cam.nmodes--;
> +
> + if (ident & SQ905_ORIENTATION_MASK)
> + gspca_dev->input_flags = V4L2_IN_ST_VFLIP;
> + else
> + gspca_dev->input_flags = V4L2_IN_ST_VFLIP |
> + V4L2_IN_ST_HFLIP;
> return 0;
> }
>
> diff -r 1248509d8bed linux/include/linux/videodev2.h
> --- a/linux/include/linux/videodev2.h Sat Mar 14 08:44:42 2009 +0100
> +++ b/linux/include/linux/videodev2.h Sun Mar 15 22:25:34 2009 +
> @@ -736,6 +736,11 @@ struct v4l2_input {
> #define V4L2_IN_ST_NO_SIGNAL 0x0002
> #define V4L2_IN_ST_NO_COLOR0x0004
>
> +/* field 'status' - sensor orientation */
> +/* If sensor is mounted upside down set both bits */
> +#define V4L2_IN_ST_HFLIP 0x0010 /* Output is flipped horizontally
> */
> +#define V4L2_IN_ST_VFLIP 0x0020 /* Output is flipped vertically */
> +
> /* field 'status' - analog */
> #define V4L2_IN_ST_NO_H_LOCK 0x0100 /* No horizontal sync lock */
> #define V4L2_IN_ST_COLOR_KILL 0x0200 /* Color killer is active */
> --
> 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
Cheers,
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: [PATCH] Remove debug output from stb6100_cfg.h
Manu,
If ok to you, please ack.
On Thu, 26 Mar 2009 10:45:53 +0100
Artem Makhutov wrote:
This patch removes the debug output from stb6100_cfg.h as it is flooding
the syslog with tuning data during normal operation.
Signed-off-by: Artem Makhutov
--- linux.old/drivers/media/dvb/frontends/stb6100_cfg.h 2009-03-26
10:28:57.0 +0100
+++ linux/drivers/media/dvb/frontends/stb6100_cfg.h 2009-03-26
10:29:52.0 +0100
@@ -36,7 +36,6 @@
return err;
}
*frequency = t_state.frequency;
- printk("%s: Frequency=%d\n", __func__, t_state.frequency);
}
return 0;
}
@@ -59,7 +58,6 @@
return err;
}
}
- printk("%s: Frequency=%d\n", __func__, t_state.frequency);
return 0;
}
@@ -81,7 +79,6 @@
}
*bandwidth = t_state.bandwidth;
}
- printk("%s: Bandwidth=%d\n", __func__, t_state.bandwidth);
return 0;
}
@@ -103,6 +100,5 @@
return err;
}
}
- printk("%s: Bandwidth=%d\n", __func__, t_state.bandwidth);
return 0;
}
Cheers,
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: [question] about open/release and vidioc_g_input/vidioc_s_input functions
On Friday 27 March 2009 17:44:05 Alexey Klimov wrote:
> Hello, Hans
>
> On Tue, 2009-03-24 at 08:06 +0100, Hans Verkuil wrote:
> > On Tuesday 24 March 2009 00:14:07 Alexey Klimov wrote:
> > > Hello, all
> > >
> > > ...
> > > static int terratec_open(struct file *file)
> > > {
> > > return 0;
> > > }
> > >
> > > static int terratec_release(struct file *file)
> > > {
> > > return 0;
> > > }
> > > ...
> > >
> > > ...
> > >
> > > Such code used in many radio-drivers as i understand.
> > >
> > > Is it good to place this empty and almost empty functions in:
> > > (here i see two variants)
> > >
> > > 1) In header file that be in linux/drivers/media/radio/ directory.
> > > Later, we can move some generic/or repeating code in this header.
> > >
> > > 2) In any v4l header. What header may contain this ?
> > >
> > > ?
> > >
> > > For what ? Well, as i understand we can decrease amount of lines and
> > > provide this simple generic functions. It's like
> > > video_device_release_empty function behaviour. Maybe not only radio
> > > drivers can use such vidioc_g_input and vidioc_s_input.
> > >
> > > Is it worth ?
> >
> > I don't think it is worth doing this for g/s_input. I think it is
> > useful to have them here: it makes it very clear that there is just a
> > single input and the overhead in both lines and actual bytes is
> > minimal.
> >
> > But for the empty open and release functions you could easily handle
> > that in v4l2-dev.c: if you leave the open and release callbacks to
> > NULL, then v4l2_open and v4l2_release can just return 0. That would be
> > nice.
> >
> > Regards,
> >
> > Hans
>
> May i ask help with this ?
> Hans, should it be looks like:
>
> diff -r 56cf0f1772f7 linux/drivers/media/radio/radio-terratec.c
> --- a/linux/drivers/media/radio/radio-terratec.c Mon Mar 23 19:18:34 2009
> -0300 +++ b/linux/drivers/media/radio/radio-terratec.cFri Mar 27
> 19:32:38 2009 +0300 @@ -333,20 +333,8 @@
> return a->index ? -EINVAL : 0;
> }
>
> -static int terratec_open(struct file *file)
> -{
> - return 0;
> -}
> -
> -static int terratec_release(struct file *file)
> -{
> - return 0;
> -}
> -
> static const struct v4l2_file_operations terratec_fops = {
> .owner = THIS_MODULE,
> - .open = terratec_open,
> - .release= terratec_release,
> .ioctl = video_ioctl2,
> };
>
> diff -r 56cf0f1772f7 linux/drivers/media/video/v4l2-dev.c
> --- a/linux/drivers/media/video/v4l2-dev.cMon Mar 23 19:18:34 2009 -0300
> +++ b/linux/drivers/media/video/v4l2-dev.cFri Mar 27 19:32:38 2009 +0300
> @@ -264,7 +264,10 @@
> /* and increase the device refcount */
> video_get(vdev);
> mutex_unlock(&videodev_lock);
> - ret = vdev->fops->open(filp);
> + if (vdev->fops->open == NULL)
> + ret = 0;
> + else
> + ret = vdev->fops->open(filp);
> /* decrease the refcount in case of an error */
> if (ret)
> video_put(vdev);
> @@ -275,7 +278,12 @@
> static int v4l2_release(struct inode *inode, struct file *filp)
> {
> struct video_device *vdev = video_devdata(filp);
> - int ret = vdev->fops->release(filp);
> + int ret;
> +
> + if (vdev->fops->release == NULL)
> + ret = 0;
> + else
> + ret = vdev->fops->release(filp);
>
> /* decrease the refcount unconditionally since the release()
> return value is ignored. */
>
> ?
>
> Or in v4l2_open function i can check if vdev->fops->open == NULL before
> video_get(vdev); (increasing the device refcount), and if it's NULL then
> unlock_mutex and return 0 ?
> And the same in v4l2_release - just return 0 in the begining of function
> in case vdev->fops->release == NULL ?
>
> What approach is better ?
This is simpler:
diff -r 2e0c6ff1bda3 linux/drivers/media/video/v4l2-dev.c
--- a/linux/drivers/media/video/v4l2-dev.c Mon Mar 23 19:01:18 2009
+0100
+++ b/linux/drivers/media/video/v4l2-dev.c Fri Mar 27 17:47:51 2009
+0100
@@ -250,7 +250,7 @@
static int v4l2_open(struct inode *inode, struct file *filp)
{
struct video_device *vdev;
- int ret;
+ int ret = 0;
/* Check if the video device is available */
mutex_lock(&videodev_lock);
@@ -264,7 +264,9 @@
/* and increase the device refcount */
video_get(vdev);
mutex_unlock(&videodev_lock);
- ret = vdev->fops->open(filp);
+ if (vdev->fops->open)
+ ret = vdev->fops->open(filp);
+
/* decrease the refcount in case of an error */
if (ret)
video_put(vdev);
@@ -275,7 +277,10 @@
static int v4l2_release(struct inode *inode, struct file *filp)
{
struct video_device *vdev = video_devdata(filp);
- int ret = vdev->fops->release(filp);
+ int ret = 0;
+
+ if (vdev->fops->release)
+ ret = vdev->fops->release(filp);
/* decrease the refcount unconditionally since th
Re: [PATCH 1/5] CSI camera interface driver for MX1
On Fri, 27 Mar 2009 15:39:59 +0200 Darius Augulis wrote: > Mauro Carvalho Chehab wrote: > > On Fri, 27 Mar 2009 11:37:23 +0200 > > Darius Augulis wrote: > > > >> Mauro Carvalho Chehab wrote: > >>> Hi Darius, > >>> > >>> Please always base your patches against the last v4l-dvb tree or > linux-next. > >>> This is specially important those days, where v4l core is suffering > several > >>> changes. > > > > Btw, you shouldn't be c/c a list that requires subscription. Every time I > send > > something, I got such errors: > > I sent it to ARM Linux ML, because it has lot of ARM stuff and there are > people who maintain ARM/MXC. > You probably could remove some CC from your reply message? If the subject is important to ARM people, the reply messages should be there as well. Otherwise you shouldn't c/c it since the beginning ;) Subscribers only list are not good for patches discussion, and aren't recommended by Linux practices. The issues become evident on such discussions where more than one subsystem is envolved. We've switched this year to linux-media@vger.kernel.org mainly due to that: the anti-spam filters at VGER are so efficient that we don't need to be subscribers-only anymore. I suggest that you try to argue with ARM list maintainer to do the same. At the mean time, please c/c only lists that don't require subscriptions, since people shouldn't be forced to subscribe just to reply an email, and it is not polite to send emails refusing their comments. Cheers, 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: [question] about open/release and vidioc_g_input/vidioc_s_input functions
Hello, Hans
On Tue, 2009-03-24 at 08:06 +0100, Hans Verkuil wrote:
> On Tuesday 24 March 2009 00:14:07 Alexey Klimov wrote:
> > Hello, all
> >
> > ...
> > static int terratec_open(struct file *file)
> > {
> > return 0;
> > }
> >
> > static int terratec_release(struct file *file)
> > {
> > return 0;
> > }
> > ...
> >
> > ...
> >
> > Such code used in many radio-drivers as i understand.
> >
> > Is it good to place this empty and almost empty functions in:
> > (here i see two variants)
> >
> > 1) In header file that be in linux/drivers/media/radio/ directory.
> > Later, we can move some generic/or repeating code in this header.
> >
> > 2) In any v4l header. What header may contain this ?
> >
> > ?
> >
> > For what ? Well, as i understand we can decrease amount of lines and
> > provide this simple generic functions. It's like
> > video_device_release_empty function behaviour. Maybe not only radio
> > drivers can use such vidioc_g_input and vidioc_s_input.
> >
> > Is it worth ?
>
> I don't think it is worth doing this for g/s_input. I think it is useful to
> have them here: it makes it very clear that there is just a single input
> and the overhead in both lines and actual bytes is minimal.
>
> But for the empty open and release functions you could easily handle that in
> v4l2-dev.c: if you leave the open and release callbacks to NULL, then
> v4l2_open and v4l2_release can just return 0. That would be nice.
>
> Regards,
>
> Hans
>
May i ask help with this ?
Hans, should it be looks like:
diff -r 56cf0f1772f7 linux/drivers/media/radio/radio-terratec.c
--- a/linux/drivers/media/radio/radio-terratec.cMon Mar 23 19:18:34
2009 -0300
+++ b/linux/drivers/media/radio/radio-terratec.cFri Mar 27 19:32:38
2009 +0300
@@ -333,20 +333,8 @@
return a->index ? -EINVAL : 0;
}
-static int terratec_open(struct file *file)
-{
- return 0;
-}
-
-static int terratec_release(struct file *file)
-{
- return 0;
-}
-
static const struct v4l2_file_operations terratec_fops = {
.owner = THIS_MODULE,
- .open = terratec_open,
- .release= terratec_release,
.ioctl = video_ioctl2,
};
diff -r 56cf0f1772f7 linux/drivers/media/video/v4l2-dev.c
--- a/linux/drivers/media/video/v4l2-dev.c Mon Mar 23 19:18:34 2009 -0300
+++ b/linux/drivers/media/video/v4l2-dev.c Fri Mar 27 19:32:38 2009 +0300
@@ -264,7 +264,10 @@
/* and increase the device refcount */
video_get(vdev);
mutex_unlock(&videodev_lock);
- ret = vdev->fops->open(filp);
+ if (vdev->fops->open == NULL)
+ ret = 0;
+ else
+ ret = vdev->fops->open(filp);
/* decrease the refcount in case of an error */
if (ret)
video_put(vdev);
@@ -275,7 +278,12 @@
static int v4l2_release(struct inode *inode, struct file *filp)
{
struct video_device *vdev = video_devdata(filp);
- int ret = vdev->fops->release(filp);
+ int ret;
+
+ if (vdev->fops->release == NULL)
+ ret = 0;
+ else
+ ret = vdev->fops->release(filp);
/* decrease the refcount unconditionally since the release()
return value is ignored. */
?
Or in v4l2_open function i can check if vdev->fops->open == NULL before
video_get(vdev); (increasing the device refcount), and if it's NULL then
unlock_mutex and return 0 ?
And the same in v4l2_release - just return 0 in the begining of function
in case vdev->fops->release == NULL ?
What approach is better ?
--
Best regards, Klimov Alexey
--
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 implementing V4L2_CAP_STREAMING for zr364xx driver
On Wed, 25 Mar 2009 20:25:10 -0300
Lamarque Vieira Souza wrote:
> Hi,
>
> I have implemented V4L2_CAP_STREAMING for the zr364xx driver (see the
> attached file). Could you review the code for me? My
> Creative PC-CAM 880 works, but I do not have any other webcam to test the
> code. Besides the streaming implementation the patch also does:
>
> . re-implement V4L2_CAP_READWRITE using videobuf.
>
> . copy cam->udev->product to the card field of the v4l2_capability struct.
> That gives more information to the users about the webcam.
>
> . move the brightness setting code from before requesting a frame (in
> read_frame) to the vidioc_s_ctrl ioctl. This way the brightness code is
> executed only when the application request a change in brightness and not
> before every frame read. Is there any reason to set the brightness before
> every frame read?
>
> . comment part of zr364xx_vidioc_try_fmt_vid_cap. Skype + libv4l do not work
> if it is there and libv4's maintainer told me it is a driver bug, so I fix it.
>
> This patch is needed for applications such as mplayer, Kopete+libv4l
> and
> Skype+libv4l can make use of the webcam that comes with zr364xx chip. The
> patch is big, if you need it splitted into small patches I can do it.
Your patch didn't apply:
patching file drivers/media/video/zr364xx.c
Hunk #4 FAILED at 37.
Hunk #5 succeeded at 114 (offset 2 lines).
Hunk #7 succeeded at 474 (offset 2 lines).
Hunk #9 succeeded at 782 (offset 2 lines).
Hunk #11 succeeded at 848 (offset 2 lines).
Hunk #13 succeeded at 918 (offset 2 lines).
Hunk #15 succeeded at 1198 (offset 2 lines).
Hunk #17 succeeded at 1242 (offset 2 lines).
Hunk #19 succeeded at 1373 (offset 2 lines).
Hunk #21 succeeded at 1409 (offset 2 lines).
Hunk #23 succeeded at 1532 (offset 2 lines).
1 out of 24 hunks FAILED -- saving rejects to file
drivers/media/video/zr364xx.c.rej
Patch doesn't apply
Probably because you didn't generate it against the development tree. Could you
please re-generate it against:
http://linuxtv.org/hg/v4l-dvbg/v4l-dvb
The better is to clone it using:
hg clone http://linuxtv.org/hg/v4l-dvb
Also, please test it against checkpatch tool, since there are a few coding
style issues like:
}
else {
and
if (foo)
{
Violating Linux codingstyle. For more info, please read the README.patches file
at the tree.
> Lamarque V. Souza
> http://www.geographicguide.com/brazil.htm
> Linux User #57137 - http://counter.li.org/
Legal! outro brasileiro na lista! Bem vindo ao time.
Cheers,
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: [PATCH] v4l2: fill reserved fields of VIDIOC_ENUMAUDIO also
On Wed, 25 Mar 2009 17:51:39 +0100 Németh Márton wrote: > From: Márton Németh > > When enumerating audio inputs with VIDIOC_ENUMAUDIO the gspca_sunplus driver > does not fill the reserved fields of the struct v4l2_audio with zeros as > required by V4L2 API revision 0.24 [1]. Add the missing initializations to > the V4L2 framework. > > The patch was tested with v4l-test 0.10 [2] with gspca_sunplus driver and > with Trust 610 LCD pow...@m ZOOM webcam. It didn't apply against the development tree. Anyway, a recent patch removed the need of memset there. the memory fill with zero now happens at the same code we copy the structure values. Cheers, 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: how about adding FOCUS mode?
Hi,
On Friday 27 March 2009 08:24:27 Hans Verkuil wrote:
> On Friday 27 March 2009 07:20:51 Kim, Heung Jun wrote:
> > Hello, Hans & everyone.
> >
> > I'm trying to adapt the various FOCUS MODE int the NEC ISP driver.
> > NEC ISP supports 4 focus mode, AUTO/MACRO/MANUAL/FULL or NORMAL.
> > but, i think that it's a little insufficient to use V4L2 FOCUS Feature.
> >
> > so, suggest that,
> >
> > - change V4L2_CID_FOCUS_AUTO's type from boolean to interger, and add
> > the following enumerations for CID values.
> >
> > enum v4l2_focus_mode {
> > V4L2_FOCUS_AUTO= 0,
> > V4L2_FOCUS_MACRO= 1,
> > V4L2_FOCUS_MANUAL= 2,
> > V4L2_FOCUS_NORMAL= 3,
> > V4L2_FOCUS_LASTP= 3,
> > };
> >
> > how about this usage? i wanna get some advice about FOCUS MODE.
V4L2_CID_FOCUS_AUTO is meant to change the auto-focus mode. Can you describe
FOCUS_MACRO and FOCUS_NORMAL in more details ? Are they auto-focus modes or
just focus presets ?
> This seems more logical to me:
>
> enum v4l2_focus_mode {
> V4L2_FOCUS_MANUAL = 0,
> V4L2_FOCUS_AUTO_NORMAL = 1,
> V4L2_FOCUS_AUTO_MACRO = 2,
> };
>
> At least this maps the current boolean values correctly. I'm not sure from
> your decription what the fourth auto focus mode is supposed to be.
Does an auto-macro focus mode really exists ?
> But I think it might be better to have a separate control that allows you
> to set the auto-focus mode. I can imagine that different devices might have
> different auto-focus modes.
>
> I've CC-ed Laurent since this is more his field than mine.
Regards,
Laurent Pinchart
--
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 review] gspca - mr97310a: return error instead of -1 in sd_mod_init
Hello, Jean-Francois
What do you think about such small cleanup ?
---
Patch reformats sd_mod_init in the way to make it return error code from
usb_register instead of -1.
Signed-off-by: Alexey Klimov
--
diff -r 56cf0f1772f7 linux/drivers/media/video/gspca/mr97310a.c
--- a/linux/drivers/media/video/gspca/mr97310a.cMon Mar 23 19:18:34
2009 -0300
+++ b/linux/drivers/media/video/gspca/mr97310a.cFri Mar 27 01:42:28
2009 +0300
@@ -347,8 +347,10 @@
/* -- module insert / remove -- */
static int __init sd_mod_init(void)
{
- if (usb_register(&sd_driver) < 0)
- return -1;
+ int ret;
+ ret = usb_register(&sd_driver);
+ if (ret < 0)
+ return ret;
PDEBUG(D_PROBE, "registered");
return 0;
}
--
Best regards, Klimov Alexey
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] CSI camera interface driver for MX1
On Fri, 27 Mar 2009, Russell King - ARM Linux wrote: > On Fri, Mar 27, 2009 at 05:18:18PM +0200, Darius Augulis wrote: > > > You use an FIQ for SoF, and spin_lock_irqsave() to protect. Don't they > > > only disable IRQs and not FIQs? But it seems your FIQ cannot cause any > > > trouble, so, it should be fine. Do you really need an FIQ? > > This is precisely the area where FIQs can't be used. You can't take > spinlocks (even IRQ-safe spinlocks) from FIQs. Why? You'll deadlock. > > Consider: > > spin_lock_irqsave(lock, flags); > ... > FIQ happens > FIQ: spin_lock_irqsave(lock, flags); <=== deadlock > > And there's nothing you can do about that. And no, converting this > locking primitive to also disable FIQs means that then FIQs will be > subject to the same latency as normal IRQs. > > In fact, in uniprocessor mode, you might as well completely forget the > spinlock, because the lock part is a no-op, and the IRQ disable has no > effect on FIQs. > > If you're going to be using FIQs in C code, you need to be _very_ _very_ > careful about what you do. Calling normal kernel functions is generally > not going to be safe in any way. No, they are not calling C from FIQs and they are not protecting against FIQs with a spinlock_irq*, that was my misinterpretation, sorry. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- 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
trouble with v4l-dvb compilation, compat.h: redefinition of 'usb_endpoint_type'
Hello, I went to /usr/src/linux and run "git pull" (so i get 2.6.29-git1), and make new kernel. Then i updated v4l-dvb repository(hg pull, hg update) and configured to compile, for example dsbr100 radio driver. I get such message: tux v4l-dvb # make make -C /w/new/v4l-dvb/v4l make[1]: Entering directory `/w/new/v4l-dvb/v4l' ./scripts/make_myconfig.pl make[1]: Leaving directory `/w/new/v4l-dvb/v4l' make[1]: Entering directory `/w/new/v4l-dvb/v4l' perl scripts/make_config_compat.pl /lib/modules/2.6.29/source ./.myconfig ./config-compat.h creating symbolic links... Kernel build directory is /lib/modules/2.6.29/build make -C /lib/modules/2.6.29/build SUBDIRS=/w/new/v4l-dvb/v4l modules make[2]: Entering directory `/usr/src/linux-2.6' CC [M] /w/new/v4l-dvb/v4l/tuner-xc2028.o CC [M] /w/new/v4l-dvb/v4l/tuner-simple.o CC [M] /w/new/v4l-dvb/v4l/tuner-types.o CC [M] /w/new/v4l-dvb/v4l/mt20xx.o CC [M] /w/new/v4l-dvb/v4l/tda8290.o CC [M] /w/new/v4l-dvb/v4l/tea5767.o CC [M] /w/new/v4l-dvb/v4l/tea5761.o CC [M] /w/new/v4l-dvb/v4l/tda9887.o CC [M] /w/new/v4l-dvb/v4l/xc5000.o CC [M] /w/new/v4l-dvb/v4l/mc44s803.o CC [M] /w/new/v4l-dvb/v4l/v4l2-dev.o CC [M] /w/new/v4l-dvb/v4l/v4l2-ioctl.o CC [M] /w/new/v4l-dvb/v4l/v4l2-device.o CC [M] /w/new/v4l-dvb/v4l/v4l2-subdev.o LD [M] /w/new/v4l-dvb/v4l/videodev.o CC [M] /w/new/v4l-dvb/v4l/v4l2-int-device.o CC [M] /w/new/v4l-dvb/v4l/v4l2-common.o /w/new/v4l-dvb/v4l/v4l2-common.c: In function 'v4l2_i2c_new_subdev': /w/new/v4l-dvb/v4l/v4l2-common.c:834: warning: format not a string literal and no format arguments /w/new/v4l-dvb/v4l/v4l2-common.c: In function 'v4l2_i2c_new_probed_subdev': /w/new/v4l-dvb/v4l/v4l2-common.c:902: warning: format not a string literal and no format arguments CC [M] /w/new/v4l-dvb/v4l/v4l1-compat.o CC [M] /w/new/v4l-dvb/v4l/dsbr100.o In file included from /w/new/v4l-dvb/v4l/dsbr100.c:94: /w/new/v4l-dvb/v4l/compat.h:396: error: redefinition of 'usb_endpoint_type' include/linux/usb/ch9.h:377: error: previous definition of 'usb_endpoint_type' was here make[3]: *** [/w/new/v4l-dvb/v4l/dsbr100.o] Error 1 make[2]: *** [_module_/w/new/v4l-dvb/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-2.6' make[1]: *** [default] Error 2 make[1]: Leaving directory `/w/new/v4l-dvb/v4l' make: *** [all] Error 2 tux v4l-dvb # Well, i have such messages for radio-si470x and radio-mr800 too. This drivers compile ok in kernel from kernel.org. As i understand this is compat.h trouble ? -- Best regards, Klimov Alexey -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] CSI camera interface driver for MX1
On Fri, Mar 27, 2009 at 05:18:18PM +0200, Darius Augulis wrote: > > You use an FIQ for SoF, and spin_lock_irqsave() to protect. Don't they > > only disable IRQs and not FIQs? But it seems your FIQ cannot cause any > > trouble, so, it should be fine. Do you really need an FIQ? This is precisely the area where FIQs can't be used. You can't take spinlocks (even IRQ-safe spinlocks) from FIQs. Why? You'll deadlock. Consider: spin_lock_irqsave(lock, flags); ... FIQ happens FIQ:spin_lock_irqsave(lock, flags); <=== deadlock And there's nothing you can do about that. And no, converting this locking primitive to also disable FIQs means that then FIQs will be subject to the same latency as normal IRQs. In fact, in uniprocessor mode, you might as well completely forget the spinlock, because the lock part is a no-op, and the IRQ disable has no effect on FIQs. If you're going to be using FIQs in C code, you need to be _very_ _very_ careful about what you do. Calling normal kernel functions is generally not going to be safe in any way. -- 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: [linux-dvb] Patch for DigitalNow TinyTwin remote.
Hei Stuart,
I would like to thank you!
Someone should really examine that more. Take some sniffs to see how
Windows handle that.
http://www.linuxtv.org/pipermail/linux-dvb/2008-November/030292.html
http://linuxtv.org/wiki/index.php/MSI_DigiVox_mini_II_V3.0
I had a look at the links, the problem I had did not stop after pressing a key on the keyboard. Also, with this kernel (2.6.29_rc7) using 'options usbhid quirks=0x13d3:0x3226:0x0004' had no effect, I believe there have been some changes to usbhid in 2.6.28, either way
the old macro '#define HID_QUIRK_IGNORE 0x0004' is not in hid.h in this kernel version. The only way to stop it was to unplug the device. (Trying to type rmmod was impossible as the input from the remote would keep coming!)
I'd be happy to have a look in to usb sniffing, are there any decent tutorials
on how to do this?
take sniff:
http://www.pcausa.com/Utilities/UsbSnoop/default.htm
use parser to sniff:
v4l2-apps/util/parse-sniffusb2.pl
and try to look parsed log. You can see USB-protocol rather easily by
comparing driver code and sniff.
I am also not sure about HID changes.
And also could you test whether AzureWave IR-tables are OK because
device looks just same, even remote.
You're absolutely right! The TinyTwin worked with the AzureWave tables
(af9015_rc_keys_twinhan and af9015_ir_table_twinhan).
I can see in af9015.h there is an ir table (af9015_ir_table_twinhan) with 50 entries, a key table (af9015_rc_keys_twinhan) with 53 entries and that while the remote has 53 keys, the device can only handle 50 of them (the first 50 in the ir table if > 50). I've also
found two ir tables from Windows drivers (one from the supplied CD and the one I previously mentioned for Windows MCE). This is an example entry in an ir table:
you are correct, 50 entries is max size.
1 , 2 , 3 , 4 , 5 , 6 , 7
0x00, 0xff, 0x16, 0xe9, 0x28, 0x0c, 0x00
I'm assuming columns 3 & 4 correspond to the key pressed and columns 5 & 6 correspond to the code returned when that key is pressed. In all tables, 3 & 4 are the same while 5 & 6 are sometimes different. I'm assuming that 5 & 6 are important if usbhid attaches itself
to the device, however, if dvb_usb_af9015 attaches itself then they seem somewhat arbitrary as the key table only needs to match the ir table to get the correct key press from af9015_rc_query.
bytes 1-4 are remote code, 1 & 2 is like device address and 3 & 4
contains key code. Last 3 bytes are some data returned by chip, HID /
key code.
http://www.sbprojects.com/knowledge/ir/rc6.htm
http://www.sbprojects.com/knowledge/ir/nec.htm
I wrote a simple programme to look at all the ir and key tables. Looking at af9015_rc_keys_twinhan and af9015_ir_table_twinhan in af9015.h shows there is no entry in af9015_ir_table_twinhan for A/V, Zoom+ or Zoom- and there are two entries with '0x00, 0x0e'
corresponding to KEY_POWER and KEY_INFO (I believe the entry '{ 0x00, 0x0e, KEY_POWER }' should be '{ 0x00, 0x4d, KEY_STOP }') in af9015_rc_keys_twinhan.
I'm not sure if columns 5 & 6 need to be specific values, but I've attached a
complete list (53 ir table entries and 53 corresponding key table entries). Of
course, we can only use 50 of them at a time!
Also, how does the AzureWave handle the remote? Does it use the usbhid driver
or dvb_usb_af9015? If it uses dvb_usb_af9015, then I think the TinyTwin should
use it as well and it would be necessary to stop usbhid from attaching to the
device.
When I added remote support the reason I used polling was that I didn't
get HID working. I don't know why. And I haven't even sniffed how
Windows driver handles that - only uploaded ir-table to the device as
seen from sniffs.
Could you make patch that adds AzureWave remote to the TinyTwin? 2.6.30
merge windows is now open. I will try to examine this remote issue
during weekend. Use this tree http://linuxtv.org/hg/~anttip/af9015/
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] CSI camera interface driver for MX1
Hi Guennadi,
+/*
+ * Videobuf operations
+ */
+static int imx_videobuf_setup(struct videobuf_queue *vq, unsigned int *count,
+ unsigned int *size)
+{
+ struct soc_camera_device *icd = vq->priv_data;
+
+ *size = icd->width * icd->height *
+ ((icd->current_fmt->depth + 7) >> 3);
+
+ if (0 == *count)
+ *count = 32;
Doesn't look like a good idea to me. You don't restrict picture sizes in
your try_fmt / set_fmt and here you default to 32 buffers...
I'm not sure about this one. Should I leave this unchanged?
+ struct imx_camera_dev *pcdev = ici->priv;
+ struct imx_buffer *buf = container_of(vb, struct imx_buffer, vb);
+ unsigned long flags;
+
+ dev_dbg(&icd->dev, "%s (vb=0x%p) 0x%08lx %d\n", __func__,
+ vb, vb->baddr, vb->bsize);
+ spin_lock_irqsave(&pcdev->lock, flags);
You use an FIQ for SoF, and spin_lock_irqsave() to protect. Don't they
only disable IRQs and not FIQs? But it seems your FIQ cannot cause any
trouble, so, it should be fine. Do you really need an FIQ?
yes, FIQ is necessary. Because IRQ is to slow. When SoF is detected, DMA must
be activated immediately, but not to early.
Whe tried to use IRQ, and many starts of frames were missed.
May I remove these spin_lock_irqsave's?
+
+ list_add_tail(&vb->queue, &pcdev->capture);
+
+ vb->state = VIDEOBUF_ACTIVE;
+
+ if (!pcdev->active) {
+ pcdev->active = buf;
+
+ /* setup sg list for future DMA */
+ if (!imx_camera_setup_dma(pcdev)) {
+ unsigned int temp;
+ /* enable SOF irq */
+ temp = __raw_readl(pcdev->base + CSICR1) |
+ CSICR1_SOF_INTEN;
Hm, looks like an error in the datasheet:
SOF_INTEN Start Of Frame Interrupt--SOF interrupt status bit; set Read:
Bit 16 when interrupt occurs. 0 = No
interrupt
1 = SOF
interrupt occurred
Write:
0 = No
action
1 =
Clears bit
This is not a status bit, but a control "SoF interrupt enable" bit, right?
Yes, probably it's only 'small' error in datasheet :)
+static void imx_camera_dma_irq(int channel, void *data)
+{
+ struct imx_camera_dev *pcdev = data;
+ struct imx_buffer *buf;
+ unsigned long flags;
+ struct videobuf_buffer *vb;
+
+ spin_lock_irqsave(&pcdev->lock, flags);
+
+ imx_dma_disable(channel);
+
+ if (unlikely(!pcdev->active)) {
+ dev_err(pcdev->dev, "DMA End IRQ with no active buffer\n");
+ goto out;
+ }
+
+ vb = &pcdev->active->vb;
+ buf = container_of(vb, struct imx_buffer, vb);
+ WARN_ON(buf->inwork || list_empty(&vb->queue));
+ dev_dbg(pcdev->dev, "%s (vb=0x%p) 0x%08lx %d\n", __func__,
+ vb, vb->baddr, vb->bsize);
+
+ imx_camera_wakeup(pcdev, vb, buf);
AFAIU, your flow looks as follows:
1. configure DMA, enable Start of Frame FIQ
2. enable DMA, DMA IRQ, disable SoF FIQ
3. disable DMA, report completed buffer, goto 1
is it ok?
+static int imx_camera_set_bus_param(struct soc_camera_device *icd, __u32
pixfmt)
+{
+ struct soc_camera_host *ici =
+ to_soc_camera_host(icd->dev.parent);
+ struct imx_camera_dev *pcdev = ici->priv;
+ unsigned long camera_flags, common_flags;
+ unsigned int csicr1;
+ int ret;
+
+ camera_flags = icd->ops->query_bus_param(icd);
+
+ common_flags = soc_camera_bus_param_compatible(camera_flags,
+ CSI_BUS_FLAGS);
+ if (!common_flags)
+ return -EINVAL;
+
+ if (!(common_flags & SOCAM_DATAWIDTH_8)) {
I don't understand this. In your CSI_BUS_FLAGS you only support 8 bits. If
the camera doesn't support it, you get a 0 back in common_flags and return
-EINVAL above. So, this test seems redundant.
yes, this is uneeded. I removed this already.
+static struct soc_camera_host_ops imx_soc_camera_host_ops = {
+ .owner = THIS_MODULE,
+ .add= imx_camera_add_device,
+ .remove = imx_camera_remove_device,
+ .set_fmt= imx_camera_set_fmt,
+ .try_fmt= imx_camera_try_fmt,
+ .init_videobuf = imx_camera_init_videobuf,
+ .reqbufs= imx_camera_reqbufs,
+ .poll = imx_camera_poll,
+ .querycap = imx_camera_querycap,
+ .set_bus_param = imx_camera_set_bus_param,
You are not implementing this against a current v4l tree. Please, rebase
onto, e.g., linux-next. You will have to
RE: [linux-dvb] Pinnacle dual Hybrid pro PCI-express - linuxTV!
Hi, I also own a pair of Pinnacle 3010ix. Luca, where should the PCI ID go? I can't believe that adding a new card to the supported card list is just that simple. Do you know a web page with information about it?. Thanks -Mensaje original- De: linux-dvb-boun...@linuxtv.org [mailto:linux-dvb-boun...@linuxtv.org] En nombre de Luca Tettamanti Enviado el: jueves, 15 de enero de 2009 16:44 Para: Catimimi CC: linux-...@linuxtv.org; Linux-media Asunto: Re: [linux-dvb] Pinnacle dual Hybrid pro PCI-express - linuxTV! On Wed, Jan 14, 2009 at 10:28 AM, Catimimi wrote: > try without the ".ko", i.e. instead, use: > > modprobe saa716x_hybrid > > OK, shame on me, it works but nothing happens. Of course ;-) The PCI ID of the card is not listed. I happen to have the same card, you can add the ID to the list but note that the frontend is not there yet... so the module will load, will print some something... and that's it. I have a couple of patches queued and I plan to do some experimentation in the weekend though ;) Luca ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- 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: [ADMIN] linuxtv.org is moving
On Fri, Mar 27, 2009 at 02:20:58AM +0200, Antti Palosaari wrote: > > [cr...@localhost v4l-dvb]$ hg push > ssh://ant...@linuxtv.org/hg/~anttip/af9015 > pushing to ssh://ant...@linuxtv.org/hg/~anttip/af9015 > searching for changes > remote: abort: No space left on device > [cr...@localhost v4l-dvb]$ host linuxtv.org > linuxtv.org has address 217.160.6.122 > > I removed 5-6 my old devel trees, still no space :o This issue should be resolved now, /tmp had insufficient space. BTW: it is faster and uses less disk space to use hg-menu to clone the v4l-dvb tree on the server (hg then uses hardlinks), and push your changes on top of it. ssh -t ant...@linuxtv.org hg-menu Johannes -- 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] uvcvideo: add zero fill for VIDIOC_ENUM_FMT
On Wednesday 25 March 2009 07:59:30 Németh Márton wrote:
> From: Márton Németh
>
> When enumerating formats with VIDIOC_ENUM_FMT the uvcvideo driver does not
> fill the reserved fields of the struct v4l2_fmtdesc with zeros as required
> by V4L2 API revision 0.24 [1]. Add the missing initializations.
>
> The patch was tested with v4l-test 0.10 [2] with CNF7129 webcam found on
> EeePC 901.
>
> References:
> [1] V4L2 API specification, revision 0.24
> http://v4l2spec.bytesex.org/spec/r8367.htm
>
> [2] v4l-test: Test environment for Video For Linux Two API
> http://v4l-test.sourceforge.net/
>
> Signed-off-by: Márton Németh
Applied, thanks.
> ---
> --- linux-2.6.29/drivers/media/video/uvc/uvc_v4l2.c.orig 2009-03-24
> 00:12:14.0 +0100 +++
> linux-2.6.29/drivers/media/video/uvc/uvc_v4l2.c 2009-03-25
> 07:24:42.0 +0100 @@ -673,11 +673,19 @@ static long
> uvc_v4l2_do_ioctl(struct fil
> {
> struct v4l2_fmtdesc *fmt = arg;
> struct uvc_format *format;
> + __u32 index;
> + enum v4l2_buf_type type;
>
> if (fmt->type != video->streaming->type ||
> fmt->index >= video->streaming->nformats)
> return -EINVAL;
>
> + index = fmt->index;
> + type = fmt->type;
> + memset(fmt, 0, sizeof(*fmt));
> + fmt->index = index;
> + fmt->type = type;
> +
> format = &video->streaming->format[fmt->index];
> fmt->flags = 0;
> if (format->flags & UVC_FMT_FLAG_COMPRESSED)
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] CSI camera interface driver for MX1
Mauro Carvalho Chehab wrote: > On Fri, 27 Mar 2009 11:37:23 +0200 > Darius Augulis wrote: > >> Mauro Carvalho Chehab wrote: >>> Hi Darius, >>> >>> Please always base your patches against the last v4l-dvb tree or linux-next. >>> This is specially important those days, where v4l core is suffering several >>> changes. > > Btw, you shouldn't be c/c a list that requires subscription. Every time I send > something, I got such errors: I sent it to ARM Linux ML, because it has lot of ARM stuff and there are people who maintain ARM/MXC. You probably could remove some CC from your reply message? -- 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] Remove stream pipe draining code for CXUSB D680 DMB
On Fri, Mar 27, 2009 at 6:07 PM, Mauro Carvalho Chehab wrote: > On Wed, 18 Mar 2009 00:00:10 +0800 > David Wong wrote: > >> CXUSB D680 DMB pipe draining code found to be problematic for new >> kernels (eg. kernel 2.6.27 @ Ubuntu 8.10) > > Could you please provide a clearer description? Why is it problematic? Also, > please don't test against a distro-patched kernel, but against vanilla kernel. > Since the patch will appear after 2.6.29, you should test using 2.6.29. > > Cheers, > Mauro > With that pipe draining code, the USB controller response is weird, i2c doesn't work. But Timothy Lee said he need that to drain the pipe after hibernate. Seems some TS data remains in the pipe that troubles mplayer. Regards, David -- 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] Support for Legend Silicon LGS8913/LGS8GL5/LGS8GXX China DMB-TH digital demodulator
On Fri, Mar 27, 2009 at 5:57 PM, Mauro Carvalho Chehab
wrote:
> On Tue, 17 Mar 2009 23:55:05 +0800
> David Wong wrote:
>
>> +#undef USE_FAKE_SIGNAL_STRENGTH
>
> Hmm... why do you need this upstream? Is the signal strength working? If so,
> just remove this test code.
I don't know if I should remove the that signal strength code.
LGS8913 codes already use a very slow loop get get signal strength.
It loops from 1 to 915 (for 915 guard intervals), set a register and then read.
Such loop is very slow, that's why I add a fake signal strength.
for LGS8GL5 and newer chips, it reads two register to roughly get the
AGC output value.
seems LGS8913 can use the new method too. Perhaps we can remove the
fake signal strength code.
>
>> +
>> +static void lgs8gxx_auto_lock(struct lgs8gxx_state *priv);
>
> I don't see why do you need to prototype this function.
No problem, to be removed.
>
>> +
>> +static int debug = 0;
>
> Don't initialize static vars to zero. Kernel already does this, and static
> initialization requires eats some space.
No problem.
>
>> +static int lgs8gxx_set_fe(struct dvb_frontend *fe,
>> + struct dvb_frontend_parameters *fe_params)
>> +{
>> + struct lgs8gxx_state *priv = fe->demodulator_priv;
>> +
>> + dprintk("%s\n", __func__);
>> +
>> + /* set frequency */
>> + if (fe->ops.tuner_ops.set_params) {
>> + fe->ops.tuner_ops.set_params(fe, fe_params);
>> + if (fe->ops.i2c_gate_ctrl)
>> + fe->ops.i2c_gate_ctrl(fe, 0);
>> + }
>> +
>> + /* Hardcoded to use auto as much as possible */
>> + fe_params->u.ofdm.code_rate_HP = FEC_AUTO;
>> + fe_params->u.ofdm.guard_interval = GUARD_INTERVAL_AUTO;
>> + fe_params->u.ofdm.transmission_mode = TRANSMISSION_MODE_AUTO;
>
> Hmm... this is weird.
>
> That's said, maybe you may need some DVBS2 API additions for DMB. You should
> propose some API additions and provide a patch for it.
That's the code copied from another frontend when I start the work.
But currently I would like to make it AUTO only.
Yes, I think there is a need for DMB-TH API.
FYI, DMB-TH is union of two modes, single carrier and multi-carrier.
The multi carrier mode is very DVB-T 8MHz alike.
The single carrier mode, I guess, is ATSC like.
I am not very familiar with RF and DTV technology and there is no
single carrier mode broadcast in Hong Kong.
It is very welcome to open a new thread to discuss proposal for DMB-TH API
> + fe_params->u.ofdm.code_rate_HP = translated_fec;
> + fe_params->u.ofdm.code_rate_LP = translated_fec;
>
> The gcc optimizer will produce the same code, but this way would be cleaner
> for
> those who are reading the source code.
OK.
>
>> +static
>> +int lgs8gxx_get_tune_settings(struct dvb_frontend *fe,
>> + struct dvb_frontend_tune_settings *fesettings)
>> +{
>> + /* FIXME: copy from tda1004x.c */
>
> It would be nice if you fix those FIXME's.
>
>> + fesettings->min_delay_ms = 800;
>> + /* Drift compensation makes no sense for DVB-T */
>
> DVB-T???
That's the code copy from tda1004x. What is that delay for?
>
>> +static int lgs8gxx_read_snr(struct dvb_frontend *fe, u16 *snr)
>> +{
>> + struct lgs8gxx_state *priv = fe->demodulator_priv;
>> + u8 t;
>> + *snr = 0;
>> +
>> + lgs8gxx_read_reg(priv, 0x95, &t);
>> + dprintk("AVG Noise=0x%02X\n", t);
>> + *snr = 256 - t;
>> + *snr <<= 8;
>> + dprintk("snr=0x%x\n", *snr);
>> +
>> + return 0;
>> +}
>
> I dunno if you are following all those discussions about SNR. We're trying to
> standardize the meaning for all those status reads (SNR, signal strength, etc.
>
> Nothing were decided yet, but while we don't take a decision, the better is if
> you provide some comments at the source code specifying what's the unit for
> each of those status (dB? 0.1 dB steps? dB * 256 ?).
Yes, I read your SNR discussion.
The register read is called average noise magnitude, but I don't know the unit.
There is no description from vendor.
>
>> +static struct dvb_frontend_ops lgs8gxx_ops = {
>> + .info = {
>> + .name = "Legend Silicon LGS8913/LGS8GXX DMB-TH",
>> + .type = FE_OFDM,
>> + .frequency_min = 47400,
>> + .frequency_max = 85800,
>> + .frequency_stepsize = 1,
>> + .caps =
>> + FE_CAN_FEC_1_2 | FE_CAN_FEC_2_3 | FE_CAN_FEC_3_4 |
>> + FE_CAN_FEC_5_6 | FE_CAN_FEC_7_8 | FE_CAN_FEC_AUTO |
>> + FE_CAN_QPSK |
>> + FE_CAN_QAM_16 | FE_CAN_QAM_64 | FE_CAN_QAM_AUTO |
>> + FE_CAN_TRANSMISSION_MODE_AUTO | FE_CAN_GUARD_INTERVAL_AUTO
>> + },
>
> Also here we should reflect the proper DMB parameters, after the API
> additions.
>
> ---
>
> Before submitting patches, please check they with checkpatch.pl ( see
> http://linuxtv.org/hg/v4l-dvb/raw-file/tip/README.patches for the submission
> procedures).
>
> P
Re: [linux-dvb] Patch: IR-support for Tevii s460
On Thu, 26 Mar 2009 20:02:40 +0100 Bernd Strauß wrote: > The remote control which comes with this card doesn't work out of the box. > This patch changes that. Works with LIRC and /dev/input/eventX. Why people insist on sending patches to the legacy list? If you don't send the patch to linux-media@vger.kernel.org, it is likely that nobody will catch. Patchwork doesn't handle patches on this list. Cheers, 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: [PATCH 1/5] CSI camera interface driver for MX1
On Fri, 27 Mar 2009 11:37:23 +0200 Darius Augulis wrote: > Mauro Carvalho Chehab wrote: > > Hi Darius, > > > > Please always base your patches against the last v4l-dvb tree or linux-next. > > This is specially important those days, where v4l core is suffering several > > changes. > Btw, you shouldn't be c/c a list that requires subscription. Every time I send something, I got such errors: From: linux-arm-kernel-boun...@lists.arm.linux.org.uk To: mche...@infradead.org Subject: Your message to Linux-arm-kernel awaits moderator approval Date: Fri, 27 Mar 2009 10:34:51 + Sender: linux-arm-kernel-boun...@lists.arm.linux.org.uk Your mail to 'Linux-arm-kernel' with the subject Re: [PATCH 1/5] CSI camera interface driver for MX1 Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://lists.arm.linux.org.uk/mailman/confirm/linux-arm-kernel/f04eda1d528be13a0d486acf4663a17ca96b05bd Cheers, 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: [RFC] Another OV7670 Soc-camera driver
On Tue, 24 Mar 2009 09:36:35 +0200 Darius wrote: > Hi All, > > seems everybody has their own OV7670 driver... I have one written from > scratch too. > It is written using Omnivision user manual, application note, and register > reference settings. > Omnivision provides settings arrays for every resolution (VGA, QVGA, QQVGA, > CIF, QCIF). > This driver has lot of harcoded magic numbers. Of course OV7670 has lot of > undocumented mystery and strange bugs. > Maybe my work could be useful merging all available OV7670 drivers into > single one. > This driver is tested with MXLADS v2.0 board. > > So there it is: Well, now, we have 3 drivers for the same device... We should really try to merge those three into one. AFAIK, Jonathan driver were also written using the Omnivision docs. Cheers, 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: [PATCH] gspca: add missing .type field check in VIDIOC_G_PARM
On Thu, 19 Mar 2009 17:47:13 -0700 (PDT) Trent Piepho wrote: > On Thu, 19 Mar 2009, [UTF-8] Németh Márton wrote: > > The gspca webcam driver does not check the .type field of struct > > v4l2_streamparm. > > This field is an input parameter for the driver according to V4L2 API > > specification, > > revision 0.24 [1]. Add the missing check. > > I think this check could go in the v4l2 core too. It already does a > similar check for QUERYBUF, QBUF, DQBUF, etc. If the driver doesn't > provide a method for ->vidioc_try_fmt_foo() then the v4l2 core will reject > a call with .type == V4L2_BUF_TYPE_foo. > > It seems like it should be ok to do this for S_PARM and G_PARM too. I agree. Could you provide such patch? Cheers, 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: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz
On Fri, 27 Mar 2009 02:39:07 +0100 hermann pitton wrote: > But my main concern is, if it once arrived at patchwork formally, it is > out of sight for most of us and might miss proper review, except you are > sure you can always guarantee that. I don't want to start to argue about > all what happened in the past. > > So, at least, if some patch arrived there mysteriously ;), the > linux-media list should be informed that it is there now and last time > to speak off, in case anything is not fully clear, before vanishing into > some black hole until you find it in the next kernel release ... The only way to send patches to patchwork is to submit it via linux-media list. There's no other way. So, all patch discussions and reviews should happen at the ML, by replying at the patch email (or by replying another reply). Patchwork will keep track of such replies as well. Cheers, 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: [PATCH 1/5] CSI camera interface driver for MX1
On Fri, 27 Mar 2009 11:37:23 +0200 Darius Augulis wrote: > Mauro Carvalho Chehab wrote: > > Hi Darius, > > > > Please always base your patches against the last v4l-dvb tree or linux-next. > > This is specially important those days, where v4l core is suffering several > > changes. > > Hi, > > could you please advice which v4l-dvb Git repository I should pull from? > Because git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/devel.git does > not have any new stuff now. During the merge window, all patches that are ready for submission are moved to: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git > git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-next.git is > marked as "unstable" for testing purposes. > What is better to base my patches on? > > Darius. Cheers, 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
VDR User wrote: > On Thu, Mar 19, 2009 at 11:55 PM, Manu Abraham wrote: >> * At the peak, you will get the maximum quality >> * falling down the slope to the left and right you will get falling >> signal strengths >> * Still rolling down, you will get increasing ERROR's, with still >> UNCORRECTABLES being steady. >> * Still falling down at the thresholds where you are about to loose >> frontend LOCK, you will see UNCORRECTABLE's getting incremented. >> >> Couple this logic into a program, with a feedback to the ROTOR and >> you get an automated satellite positioner, with a good fine tuned >> position. > > This would make for a very very useful tool to have. I can't count > the number of times I've seen people inquire about tools to help them > aim their dish and this sounds like the perfect solution to that long > standing problem. Especially if it returned the network id once it's > achieve a lock so the user can see if he's pointed to the correct > satellite. If you have a motor and you are able to automatically peak satellites, the only thing missing is a program to find all the signals automatically, including the ones which are turned on and off in a matter of minutes. Just google for *blindscan* (and maybe my name) to find a utility I wrote years ago and abandoned after failing to get the corresponding mt312-autosymbolrate kernel patch integrated. Next step, automatically upload found signals on some site, maybe including a frame from the received video stream and let users comment/moderate interesting ones on a sort of forum. :-) H, feeds... Best regards. -- Roberto Ragusamail at robertoragusa.it -- 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] radio-mr800.c: Missing mutex include
On Wed, 18 Mar 2009 00:42:08 +0300 Alexey Klimov wrote: > On Tue, 2009-03-17 at 22:00 +0100, Alessio Igor Bogani wrote: > > radio-mr800.c uses struct mutex, so while seems to be > > pulled in indirectly by one of the headers it already includes, the > > right thing is to include it directly. > > > Hello, Alessio > > Patch looks okay for my eyes. > If it useful it should be applied. > > Thank you! > > Mauro, if patch is okay please apply it. > If you need my ack - here it is: > Acked-by: Alexey Klimov If the mutex.h were already included by another kernel header, I don't see why to include it again. If a later patch remove the mutex.h from the header, then the patch author should take care of this change anyway. Cheers, 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: [PATCH] Remove stream pipe draining code for CXUSB D680 DMB
On Wed, 18 Mar 2009 00:00:10 +0800 David Wong wrote: > CXUSB D680 DMB pipe draining code found to be problematic for new > kernels (eg. kernel 2.6.27 @ Ubuntu 8.10) Could you please provide a clearer description? Why is it problematic? Also, please don't test against a distro-patched kernel, but against vanilla kernel. Since the patch will appear after 2.6.29, you should test using 2.6.29. Cheers, 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: [PATCH] CXUSB D680 DMB using unified lgs8gxx driver
On Tue, 17 Mar 2009 23:56:57 +0800 David Wong wrote: > This patch replace the use of lgs8gl5 driver by unified lgs8gxx driver, for > CXUSB D680 DMB (MagicPro ProHDTV) > > David T.L. Wong Patch is ok. However, as it depends on the previous one, I'll mark it as RFC. When you submit back the previous patch (plus the API patch), re-submit the other patches on this series. Also, since those patches are dependent, please number they at the subject, as: [PATCH 01/05] ... [PATCH 05/05] This allows us to be sure about the proper patch order to apply. Cheers, 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: [PATCH] Support for Legend Silicon LGS8913/LGS8GL5/LGS8GXX China DMB-TH digital demodulator
On Tue, 17 Mar 2009 23:55:05 +0800
David Wong wrote:
> +#undef USE_FAKE_SIGNAL_STRENGTH
Hmm... why do you need this upstream? Is the signal strength working? If so,
just remove this test code.
> +
> +static void lgs8gxx_auto_lock(struct lgs8gxx_state *priv);
I don't see why do you need to prototype this function.
> +
> +static int debug = 0;
Don't initialize static vars to zero. Kernel already does this, and static
initialization requires eats some space.
> +static int lgs8gxx_set_fe(struct dvb_frontend *fe,
> + struct dvb_frontend_parameters *fe_params)
> +{
> + struct lgs8gxx_state *priv = fe->demodulator_priv;
> +
> + dprintk("%s\n", __func__);
> +
> + /* set frequency */
> + if (fe->ops.tuner_ops.set_params) {
> + fe->ops.tuner_ops.set_params(fe, fe_params);
> + if (fe->ops.i2c_gate_ctrl)
> + fe->ops.i2c_gate_ctrl(fe, 0);
> + }
> +
> + /* Hardcoded to use auto as much as possible */
> + fe_params->u.ofdm.code_rate_HP = FEC_AUTO;
> + fe_params->u.ofdm.guard_interval = GUARD_INTERVAL_AUTO;
> + fe_params->u.ofdm.transmission_mode = TRANSMISSION_MODE_AUTO;
Hmm... this is weird.
That's said, maybe you may need some DVBS2 API additions for DMB. You should
propose some API additions and provide a patch for it.
> + /* FEC. No exact match for DMB-TH, pick approx. value */
> + switch(t & LGS_FEC_MASK) {
> + case LGS_FEC_0_4: /* FEC 0.4 */
> + translated_fec = FEC_1_2;
> + break;
> + case LGS_FEC_0_6: /* FEC 0.6 */
> + translated_fec = FEC_2_3;
> + break;
> + case LGS_FEC_0_8: /* FEC 0.8 */
> + translated_fec = FEC_5_6;
> + break;
> + default:
> + translated_fec = FEC_1_2;
> + }
Same here: if there's no exact match, we should first patch the core files to
improve the API, and then use the correct values.
> + fe_params->u.ofdm.code_rate_HP =
> + fe_params->u.ofdm.code_rate_LP = translated_fec;
The above seems weird. It would be better to do:
+ fe_params->u.ofdm.code_rate_HP = translated_fec;
+ fe_params->u.ofdm.code_rate_LP = translated_fec;
The gcc optimizer will produce the same code, but this way would be cleaner for
those who are reading the source code.
> +static
> +int lgs8gxx_get_tune_settings(struct dvb_frontend *fe,
> + struct dvb_frontend_tune_settings *fesettings)
> +{
> + /* FIXME: copy from tda1004x.c */
It would be nice if you fix those FIXME's.
> + fesettings->min_delay_ms = 800;
> + /* Drift compensation makes no sense for DVB-T */
DVB-T???
> +static int lgs8gxx_read_snr(struct dvb_frontend *fe, u16 *snr)
> +{
> + struct lgs8gxx_state *priv = fe->demodulator_priv;
> + u8 t;
> + *snr = 0;
> +
> + lgs8gxx_read_reg(priv, 0x95, &t);
> + dprintk("AVG Noise=0x%02X\n", t);
> + *snr = 256 - t;
> + *snr <<= 8;
> + dprintk("snr=0x%x\n", *snr);
> +
> + return 0;
> +}
I dunno if you are following all those discussions about SNR. We're trying to
standardize the meaning for all those status reads (SNR, signal strength, etc.
Nothing were decided yet, but while we don't take a decision, the better is if
you provide some comments at the source code specifying what's the unit for
each of those status (dB? 0.1 dB steps? dB * 256 ?).
> +static struct dvb_frontend_ops lgs8gxx_ops = {
> + .info = {
> + .name = "Legend Silicon LGS8913/LGS8GXX DMB-TH",
> + .type = FE_OFDM,
> + .frequency_min = 47400,
> + .frequency_max = 85800,
> + .frequency_stepsize = 1,
> + .caps =
> + FE_CAN_FEC_1_2 | FE_CAN_FEC_2_3 | FE_CAN_FEC_3_4 |
> + FE_CAN_FEC_5_6 | FE_CAN_FEC_7_8 | FE_CAN_FEC_AUTO |
> + FE_CAN_QPSK |
> + FE_CAN_QAM_16 | FE_CAN_QAM_64 | FE_CAN_QAM_AUTO |
> + FE_CAN_TRANSMISSION_MODE_AUTO | FE_CAN_GUARD_INTERVAL_AUTO
> + },
Also here we should reflect the proper DMB parameters, after the API additions.
---
Before submitting patches, please check they with checkpatch.pl ( see
http://linuxtv.org/hg/v4l-dvb/raw-file/tip/README.patches for the submission
procedures).
Please fix the CodingStyle errors detected by the tool:
ERROR: do not initialise statics to 0 or NULL
#91: FILE: linux/drivers/media/dvb/frontends/lgs8gxx.c:43:
+static int debug = 0;
WARNING: printk() should include KERN_ facility level
#145: FILE: linux/drivers/media/dvb/frontends/lgs8gxx.c:97:
+ printk("%s: reg=0x%02X, data=0x%02X\n", __func__, reg, b1[0]);
ERROR: do not use C99 // comments
#164: FILE: linux/drivers/media/dvb/frontends/lgs8gxx.c:116:
+ if_conf = 0x10; // AGC output on;
ERROR: spaces required around that ':' (ctx:VxV)
#167: FILE: linux/drivers/media/dvb/frontends/lgs8gxx.c:119:
+ ((config->ext_adc) ? 0x80:
Re: [linux-dvb] [ADMIN] linuxtv.org is moving
On Fri, Mar 27, 2009 at 10:44:33AM +1000, Torgeir Veimo wrote: > > So how do I unsubscribe from linux-dvb? It seems that I still gets some > mails from this list, but information on how to unsubscribe is lost from > the website. Every mail from the list contains the link for the Mailman web interface. Johannes -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] CSI camera interface driver for MX1
Mauro Carvalho Chehab wrote: Hi Darius, Please always base your patches against the last v4l-dvb tree or linux-next. This is specially important those days, where v4l core is suffering several changes. Hi, could you please advice which v4l-dvb Git repository I should pull from? Because git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/devel.git does not have any new stuff now. git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-next.git is marked as "unstable" for testing purposes. What is better to base my patches on? Darius. -- 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: libv4l, yuv420 and gspca-stv06xx conversion
2009/3/25 Hans de Goede : > > > On 03/23/2009 08:40 PM, Erik Andrén wrote: >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Hi Hans, >> I'm trying to get gstreamer and the yuv420 format conversion in >> libv4l to play nice with the gspca-stv06xx driver. Currently this is >> not working. >> >> The resolution of the vv6410 sensor is 356*292 pixels and the native >> format of the camera is V4L2_PIX_FMT_SGRBG8. >> This produces a total image size of 103952 bytes which gets page >> aligned to 106496. >> >> When requesting to conversion to yuv420 in gstreamer I launch >> gst-launch with the following parameters: >> gst-launch-0.10 -v v4l2src queue-size=4 ! ffmpegcolorspace ! xvimageink >> >> gstreamer then proceeds with complaining that it received a frame of >> size 155928 bytes but it expected a frame of size 156512 bytes. >> >> The delivered 155928 size seems sane as 155928 / 356 gives 438 and >> 155928 / 292 gives 534. >> >> Furthermore, the difference between the received size and the >> expected size is 584 bytes which is 2x the height. >> >> Anyhow, I hacked libv4l2.c and padded the frame with 584 in order to >> acheive the requested 156512 bytes. This worked and yielded the >> attached image. >> >> I'm currently at loss what's the root cause of this. >> >> Could the page align interfer somehow with the frame size? >> What's the correct image size? The converted image is clearly correct. >> > > I think that something in the gstreamer stack expect the U and V planes of > the YUV planar data, to have each line start 32 bit word aligned. So they > expect us to add 2 bytes of padding after each line of U and V data. > > That would give us 2 x (292 / 2) extra bytes for the U and for the V plane, > so 2 x (2 x (292 / 2)) = 584 bytes of additional data, and would also > explain the color banding in the image you've attached. > > Now the question is, is gstreamer right in assuming this padding? > You're right in that gstreamer expects: outsize = GST_ROUND_UP_4 (*w) * GST_ROUND_UP_2 (*h); outsize += 2 * ((GST_ROUND_UP_8 (*w) / 2) * (GST_ROUND_UP_2 (*h) / 2)); I tried to hack around this by changing the 8 to a 4 which produces the same image as when I added the 584 offset. My take is that the alignment is also used somewhere else in the gstreamer stack. I'll try to post on their devel list and see if I can get any tips on how to resolve this problem. Best regards, Erik > The v4l2 standard is pretty clear on this: > http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec/c2030.htm#V4L2-PIX-FORMAT > > And then the bytesperline description, clearly says the what gstreamer > expects is wrong. > But what is normal for other YUV420 planar data producing sources? > > Regards, > > Hans > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH]: gspca: use usb interface as parent
Hi all, As discussed in the: "v4l parent for usb device interface or device?" thread, here is a patch for gspca to make it use the usb interface as its parent device, instead of the usb device. Regards, Hans p.s. I'll also push a patch to my libv4l repo, with matching libv4l changes so that libv4l's upside down cam detections stays working with this change. Note: this libv4l patch also fixes libv4l upside down detection for the new device numbering style. diff -r c28651a2c2c3 linux/drivers/media/video/gspca/gspca.c --- a/linux/drivers/media/video/gspca/gspca.c Thu Mar 26 09:44:15 2009 +0100 +++ b/linux/drivers/media/video/gspca/gspca.c Fri Mar 27 10:32:24 2009 +0100 @@ -1958,7 +1958,7 @@ /* init video stuff */ memcpy(&gspca_dev->vdev, &gspca_template, sizeof gspca_template); - gspca_dev->vdev.parent = &dev->dev; + gspca_dev->vdev.parent = &intf->dev; gspca_dev->module = module; gspca_dev->present = 1; ret = video_register_device(&gspca_dev->vdev,
Re: how about adding FOCUS mode?
Hello Hans, and Laurent
On Fri, Mar 27, 2009 at 4:24 PM, Hans Verkuil wrote:
> On Friday 27 March 2009 07:20:51 Kim, Heung Jun wrote:
>> Hello, Hans & everyone.
>>
>> I'm trying to adapt the various FOCUS MODE int the NEC ISP driver.
>> NEC ISP supports 4 focus mode, AUTO/MACRO/MANUAL/FULL or NORMAL.
>> but, i think that it's a little insufficient to use V4L2 FOCUS Feature.
>>
>> so, suggest that,
>>
>> - change V4L2_CID_FOCUS_AUTO's type from boolean to interger, and add
>> the following enumerations for CID values.
>>
>> enum v4l2_focus_mode {
>> V4L2_FOCUS_AUTO = 0,
>> V4L2_FOCUS_MACRO = 1,
>> V4L2_FOCUS_MANUAL = 2,
>> V4L2_FOCUS_NORMAL = 3,
>> V4L2_FOCUS_LASTP = 3,
>> };
>>
>> how about this usage? i wanna get some advice about FOCUS MODE.
>
> This seems more logical to me:
>
> enum v4l2_focus_mode {
> V4L2_FOCUS_MANUAL = 0,
> V4L2_FOCUS_AUTO_NORMAL = 1,
> V4L2_FOCUS_AUTO_MACRO = 2,
> };
I think it could be more than that. Because some ISP devices support
much more presets like "AF-S" and "AF-C".
I mean AF Static? or something for AF-S and AF continuous for AF-C...
>
> At least this maps the current boolean values correctly. I'm not sure from
> your decription what the fourth auto focus mode is supposed to be.
>
> But I think it might be better to have a separate control that allows you to
> set the auto-focus mode. I can imagine that different devices might have
> different auto-focus modes.
You are right. But on the other hand, it seems to be not bad using API
in same way as EXPOSURE CID (V4L2_CID_EXPOSURE_AUTO) to avoid
confusion.
Cheers,
Nate
>
> I've CC-ed Laurent since this is more his field than mine.
>
> Regards,
>
> Hans
>
>>
>> Thanks,
>> Riverful
>
>
>
> --
> Hans Verkuil - video4linux developer - sponsored by TANDBERG
> --
> 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 unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] CSI camera interface driver for MX1
On Fri, Mar 27, 2009 at 08:33:27AM +0100, Holger Schurig wrote: > > Sparse is another tool which can be used while building the > > kernel to increase the build time checking, but it can be > > quite noisy, so please only look at stuff which pops up for > > your specific area. > > To get rid of some of the warnings, you can analyze only the > parts of the source that you're working on. You just need sparse > in your PATH and issue: > > $ make SUBDIRS=arch/arm/mach-mx2 C=2 > > > Unfortunately, the arm tree is a bit different to mainline linux, > because > > $ make SUBDIRS=arch/arm C=2 > arch/arm/Makefile:31: *** Recursive variable `KBUILD_CFLAGS' > references itself (eventually). Stop. > make: *** [_module_arch/arm] Error 2 Line 31 is the KBUILD_CFLAGS line of: ifeq ($(CONFIG_FRAME_POINTER),y) KBUILD_CFLAGS +=-fno-omit-frame-pointer -mapcs -mno-sched-prolog endif which is _not_ a recursive definition. Either your make is broken or you have local changes to that line. -- 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
DMB-TH patches
Hi all, Anyone would like to take care of my patch related to DMB-TH? at least putting them into some development branch? The unified lgs8gxx code is much complete compare to the reverse engineered lgs8gl5, and It is tested by lgs8gl5 original author Timothy Lee. The patches are: http://patchwork.kernel.org/patch/12633/ http://patchwork.kernel.org/patch/12634/ http://patchwork.kernel.org/patch/12636/ http://www.spinics.net/lists/linux-media/msg03655.html David -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] CSI camera interface driver for MX1
> Sparse is another tool which can be used while building the > kernel to increase the build time checking, but it can be > quite noisy, so please only look at stuff which pops up for > your specific area. To get rid of some of the warnings, you can analyze only the parts of the source that you're working on. You just need sparse in your PATH and issue: $ make SUBDIRS=arch/arm/mach-mx2 C=2 Unfortunately, the arm tree is a bit different to mainline linux, because $ make SUBDIRS=arch/arm C=2 arch/arm/Makefile:31: *** Recursive variable `KBUILD_CFLAGS' references itself (eventually). Stop. make: *** [_module_arch/arm] Error 2 breaks, with and without sparse: -- 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 v3] ov772x: add edge contrl support
Hello Morimoto-san
On Wed, 25 Mar 2009, morimoto.kunin...@renesas.com wrote:
> > Whatever this "edge" does, isn't it so, that "threshold," "upper," and
> > "lower" parameters configure it and "strength" actually enforces the
> > changes? Say, if strength == 0, edge control is off, and as soon as you
> > switch it to != 0, it is on with all the configured parameters? If my
> > guess is right, wouldn't it make sense to first configure parameters and
> > then set strength? If you agree, I'll just swap them when committing, so,
> > you don't have to resend. Just please either confirm that you agree, or
> > explain why I am wrong.
>
> I don't know detail of these register's order.
> Because my datasheet doesn't have detail explain.
>
> For example, does "strength" actually enforce
> all of configured parameters change ?
>
> So, I tried to test whether these register setting
> order were important.
>
> It seems to be independent apparently respectively.
> For example, I can change only "upper" register and
> the setting was effective.
So, you _do_ know what that parameter does - if you can verify what effect
it produces on the camera? So, that's just what I was asking - what do
these settings do? What changes do you observe when you manipulate them?
And this your observation actually suffices to me to preserve your
original order of register writes. If documentation says nothing about it,
and as long as it works - we can keep it.
> So, I will ask to maker about these register's behavior.
> Because it seems to relate to other register.
> So, please ignore this patch until I get answer. sorry.
Well, I don't think we have to wait for an answer for too long. If they
don't reply within 1-2 days, let's just take the patch as is (with the
single minor correction I proposed).
> > +#define OV772X_EDGECTRL(s, t, u, l)\
> > +{ \
> > + .strength = (s & 0x1F), \
> > + .threshold = (t & 0x0F), \
> > + .upper = (u & 0xFF), \
> > + .lower = (l & 0xFF), \
> > +}
>
> I will fix this in next =)
That's up to you. This is a minor formatting correction, which I can do
myself when merging. But if you like, you can send an update, sure.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v4l-dvb-maintainer] [PATCH] Allow the user to restrict the RC5 address
On Thursday 26 March 2009 19:45:53 Udo A. Steinberg wrote: > On Thu, 26 Mar 2009 12:45:18 -0400 Steven Toth (ST) wrote: > > ST> I too tend to have multiple remotes, I don't think it's that unusual > for ST> long standing Hauppauge customers to have many boards with many > types of ST> remotes. > ST> > ST> > It might be better to have an option to explicitly allow old > Hauppauge ST> > remotes that send 0x00. > ST> > > ST> I could live with this. It relegates older remotes but those remotes > ST> are no longer made. This feels like a good compromise. > > How about changing the parameter such that it is a filter mask? The > default value of 0x0 would accept all remotes. For non-zero values, each > bit set in the parameter would filter the device address corresponding to > that bit, e.g. 0x1 would filter address 0x0, 0x8000 would filter > address 0x1f, etc. Seems way to complicated to me. Remember that end users have no idea about the device addresses, so it should be a simple to understand module option. So I'd just go with Steve's preference. Regards, Hans > > Cheers, > > - Udo -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: how about adding FOCUS mode?
On Friday 27 March 2009 07:20:51 Kim, Heung Jun wrote:
> Hello, Hans & everyone.
>
> I'm trying to adapt the various FOCUS MODE int the NEC ISP driver.
> NEC ISP supports 4 focus mode, AUTO/MACRO/MANUAL/FULL or NORMAL.
> but, i think that it's a little insufficient to use V4L2 FOCUS Feature.
>
> so, suggest that,
>
> - change V4L2_CID_FOCUS_AUTO's type from boolean to interger, and add
> the following enumerations for CID values.
>
> enum v4l2_focus_mode {
> V4L2_FOCUS_AUTO = 0,
> V4L2_FOCUS_MACRO = 1,
> V4L2_FOCUS_MANUAL = 2,
> V4L2_FOCUS_NORMAL = 3,
> V4L2_FOCUS_LASTP = 3,
> };
>
> how about this usage? i wanna get some advice about FOCUS MODE.
This seems more logical to me:
enum v4l2_focus_mode {
V4L2_FOCUS_MANUAL = 0,
V4L2_FOCUS_AUTO_NORMAL = 1,
V4L2_FOCUS_AUTO_MACRO = 2,
};
At least this maps the current boolean values correctly. I'm not sure from
your decription what the fourth auto focus mode is supposed to be.
But I think it might be better to have a separate control that allows you to
set the auto-focus mode. I can imagine that different devices might have
different auto-focus modes.
I've CC-ed Laurent since this is more his field than mine.
Regards,
Hans
>
> Thanks,
> Riverful
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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
