Re: [PATCH] media: fix precedence in dvb/frontends/tda665x
Hi Randy, Thanks for catching the bug ! On Fri, Feb 26, 2010 at 2:57 AM, Randy Dunlap wrote: > From: Randy Dunlap > > Fix precedence so that data is used correctly. > Fixes sparse warning: > drivers/media/dvb/frontends/tda665x.c:136:55: warning: right shift by bigger > than source value > > Signed-off-by: Randy Dunlap > Cc: Manu Abraham Reviewed-by: Manu Abraham Acked-by: Manu Abraham > --- > drivers/media/dvb/frontends/tda665x.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- lnx-2633-spr.orig/drivers/media/dvb/frontends/tda665x.c > +++ lnx-2633-spr/drivers/media/dvb/frontends/tda665x.c > @@ -133,7 +133,7 @@ static int tda665x_set_state(struct dvb_ > frequency += config->ref_divider >> 1; > frequency /= config->ref_divider; > > - buf[0] = (u8) (frequency & 0x7f00) >> 8; > + buf[0] = (u8) ((frequency & 0x7f00) >> 8); > buf[1] = (u8) (frequency & 0x00ff) >> 0; > buf[2] = 0x80 | 0x40 | 0x02; > buf[3] = 0x00; > > -- 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: More videobuf and streaming I/O questions
>On Tuesday 23 February 2010 08:41:49 Pawel Osciak wrote: >> >On Mon, 22 Feb 2010 00:12:18 +0100 >> >Laurent Pinchart wrote: >> As for the REQBUF, I've always thought it'd be nice to be able to ask the >> driver for the "recommended" number of buffers that should be used by >> issuing a REQBUF with count=0... > >How would the driver come up with the number of recommended buffers ? >From the top of my head: when encoding a video stream, a codec driver could decide on the minimum number of input frames required (including reference frames, etc.). Or maybe I am missing something, what is your opinion on that? Best regards -- Pawel Osciak Linux Platform Group Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: You are now subscribed to linuxtv-dvb-apps
Hi, (I'm ow...@packages.qa.debian.org) On Thu, 25 Feb 2010, Brian Keck wrote: > On Thu, 25 Feb 2010 11:29:04 -, Simon Kenyon wrote: > >On 25/02/2010 11:08, ow...@packages.qa.debian.org wrote: > >> Processing commands for p...@qa.debian.org: > >>> Subject: Re: CONFIRM f156db6194c056981f5711b7ef302743 > >>> > >> linux-media@vger.kernel.org has been subscribed to > >> linuxtv-dvb-a...@packages > >.qa.debian.org. > >what is going on here? > > > > I'm subscribed to linux-media.vger.kernel.org & several debian lists. > Less than an hour ago I received the following, which was unexpected & > not understood, but I replied to it out of curiosity partly. You reply to subscription confirmation mails that you have not asked for? Seriously... I was expecting somehow that either the Debian maintainer or the upstream maintainer of linuxtv-dvb-apps thought that it was a good idea to receive Debian BTS mails on his mailing list. If that's not the case, someone should unsubscribe again (or I can do it for you). Ccing the debian maintainers to verify. Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V6 2/2] OMAP2/3: Add V4L2 DSS driver support in device.c
> -Original Message-
> From: Tony Lindgren [mailto:t...@atomide.com]
> Sent: Friday, February 26, 2010 3:44 AM
> To: Hiremath, Vaibhav
> Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org;
> hverk...@xs4all.nl
> Subject: Re: [PATCH-V6 2/2] OMAP2/3: Add V4L2 DSS driver support in device.c
>
> * hvaib...@ti.com [100223 01:25]:
> > From: Vaibhav Hiremath
> >
> >
> > Signed-off-by: Vaibhav Hiremath
> > ---
> > arch/arm/plat-omap/devices.c | 29 +
> > 1 files changed, 29 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/plat-omap/devices.c b/arch/arm/plat-omap/devices.c
> > index 30b5db7..64f2a3a 100644
> > --- a/arch/arm/plat-omap/devices.c
> > +++ b/arch/arm/plat-omap/devices.c
> > @@ -357,6 +357,34 @@ static void omap_init_wdt(void)
> > static inline void omap_init_wdt(void) {}
> > #endif
> >
> > +/*---
> */
> > +
> > +#if defined(CONFIG_VIDEO_OMAP2_VOUT) || \
> > + defined(CONFIG_VIDEO_OMAP2_VOUT_MODULE)
> > +#if defined (CONFIG_FB_OMAP2) || defined (CONFIG_FB_OMAP2_MODULE)
> > +static struct resource omap_vout_resource[3 - CONFIG_FB_OMAP2_NUM_FBS] =
> {
> > +};
> > +#else
> > +static struct resource omap_vout_resource[2] = {
> > +};
> > +#endif
> > +
> > +static struct platform_device omap_vout_device = {
> > + .name = "omap_vout",
> > + .num_resources = ARRAY_SIZE(omap_vout_resource),
> > + .resource = &omap_vout_resource[0],
> > + .id = -1,
> > +};
> > +static void omap_init_vout(void)
> > +{
> > + (void) platform_device_register(&omap_vout_device);
> > +}
>
> Allocation can still fail here, please handle the results.
>
[Hiremath, Vaibhav] Ok, will do that.
> > +#else
> > +static inline void omap_init_vout(void) {}
> > +#endif
> > +
> > +/*---
> */
> > +
> > /*
> > * This gets called after board-specific INIT_MACHINE, and initializes
> most
> > * on-chip peripherals accessible on this board (except for few like
> USB):
> > @@ -387,6 +415,7 @@ static int __init omap_init_devices(void)
> > omap_init_rng();
> > omap_init_uwire();
> > omap_init_wdt();
> > + omap_init_vout();
> > return 0;
> > }
> > arch_initcall(omap_init_devices);
>
> Looks like this should be in mach-omap2/devices.c instead if it's all
> omap2/3/4 specific.
>
[Hiremath, Vaibhav] For sure it's being used for OMAP2/3 and if I understand
correctly OMAP4 also uses it.
Thanks,
Vaibhav
> Regards,
>
> Tony
--
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
You do not have permission to post to the ad...@lists.myitforum.com list
Sorry, you do not have permission to post to the ad...@lists.myitforum.com mailing list. -- 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://www.kernellabs.com/hg/~dheitmueller/hvr-950q-pmfixes
Hello Mauro, Please pull from http://www.kernellabs.com/hg/~dheitmueller/hvr-950q-pmfixes for the following fixes: au8522: fix case where we don't perform the first tune after going digital au8522: fix race condition in switching from digital to analog mode Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Requested feedback on V4L2 driver design
Hi Chase, On Tuesday 16 February 2010 14:00:11 Maupin, Chase wrote: > Laurent, > > To follow up with some of the comments I made before I got additional > clarification about the commands supported by the proxy driver running on > the VPSS MCU. The proxy will support all of the commands used by V4L2 as > well as those proposed extensions to V4L2 that Hans has mentioned. > Basically, the list of commands supported at initial release is not only > those required today, but a full set for all the features of the VPSS. In > this was as new APIs are added to V4L2 the support for those features will > already be supported by the VPSS MCU proxy driver. Thank you for the clarification. A few things are still uncleared to me, as stated in my previous mail (from a few minutes ago). My main question is, if the VPSS API is full-featured and accessible from the master CPU, why do we need a proxy driver in the firmware at all ? > As for the license of the firmware this is still being worked. It is > currently under TI proprietary license and will be distributed as binary > under Technical Software Publicly Available (TSPA) which means it can be > obtained by anyone. If you feel that source code is required for the > firmware at launch to gain acceptance please let us know and we can start > working that issue. I think it would definitely help keeping the Linux driver and the VPSS firmware in sync if the VPSS firmware source was available. The firmware source code could even be distributed along with the Linux driver. By the way, will the firmware be loaded at runtime by the driver, or will it be stored internally in the chip ? -- 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
Re: Requested feedback on V4L2 driver design
Hi Chase, On Friday 12 February 2010 17:46:55 Maupin, Chase wrote: > Laurent, > > First let me thank you for taking time to review this. You're welcome. [snip] > > -Original Message- > > From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] > > Sent: Thursday, February 11, 2010 7:23 PM > > > > On Monday 08 February 2010 16:08:37 Maupin, Chase wrote: [snip] > > > If you have additional questions or need more information please feel > > > free to contact us (we have setup a mailing list at > > > vpss_driver_des...@list.ti.com) so we can answer them. > > > > I'll answer here as the instructions provided in the wiki to subscribe to > > the vpss_driver_design mailing list are incorrect (http://list.ti.com/ > > isn't accessible, the name has no A record associated to it). I've CC'ed > > the list in case subscription wouldn't be required to post. > > The page for subscribing to the list requires a my.TI login which you can > setup at > https://myportal.ti.com/portal/dt?provider=TIPassLoginSingleContainer<=m > yti&j5=2&j3=1&goto=https%3A%2F%2Fmy.ti.com%3A443%2Fcgi-bin%2Fhome.pl%3FDCMP > %3DTIHeaderTracking%26HQS%3DOther%2BOT%2Bhdr_my_ti. > However, your reply to the list should be fine without subscribing. Thanks for the information, but http://list.ti.com/ still can't be accessed. The host list.ti.com has no A record, an HTTP connection can't thus be established. > > 1. Multi-core design > > > > > > OMAP3 was already a dual-core system, OMAP4 (I assume all this is about > > the OMAP4 processors family) seems to push the concept one step further. > > > > With its heterogeneous multi-core design (ARM master CPU and slave DSPs), > > the OMAP architecture delivers high performances at the cost of higher > > development time and effort as users need to write software for completely > > different cores, usually using different toolchains. This is in my opinion > > a good (or at least acceptable) trade-off between CPU power, development > > time and power consumption (DSPs being more efficient at signal processing > > at the cost of a higher development complexity). > > > > I'm a bit puzzled, however, by how the VPSS MCU will help improving the > > situation compared to the OMAP3 design. The VPSS MCU will provide an API > > that will expose a fixed subset of the hardware capabilities. This is only > > a guess, but I suppose the firmware will be fairly generic, and that TI > > will provide customized versions to big customers tailored for their needs > > and use cases. The "official" kernel drivers will then need to be changed, > > and those changes will have no chance to be accepted in the mainline > > kernel. This will lead to forks and fragmentation of the developers base > > among the big players in the embedded markets. What will be the > > compensation for that ? How will the VPSS MCU provide higher performances > > than the OMAP3 model ? > > The firmware on the VPSS MCU will be able to configure/control all of the > functionality that the VPSS MCU has and will be the same for all > customers. The only part that may change is the proxy driver of the > firmware. The proxy driver is the piece that will be responsible for > taking the commands from the driver and telling the firmware to execute > the operation. As the proxy is the "tip of the firmware iceberg", it will be all the Linux driver will care about. Whether the firmware "backend" is able to configure and control all of the functionality that the VPSS MCU offers is then irrelevant, as the Linux driver will have no way to access that backend directly. Is my understanding correct ? > The initial version of the proxy will support all the standard V4L2 > operations. As new operations (such as on the fly video scaling) are added > to the V4L2 API the firmware may require an update to the proxy driver to > handle these requests, but the underlying code will remain the same. Different proxy versions will need different version of the Linux driver. That's where fragmentation of the developers base come into play, and that's the part that worries me. > For customers who wish to use features of the VPSS that are not supported > by the current V4L2 APIs there are OpenMax components being developed that > can also talk to the VPSS and support the full set of features of the > VPSS. These components allow for additional use cases such as > transferring data directly from other processing blocks such as the DSP to > the VPSS without ever returning to the host processor (tunneling). > However, the OpenMax API does not integrate with most existing software > such as applications that use V4L2 drivers for video capture and display. So the firmware "backend" will expose all its features through OpenMax, and the proxy will expose a V4L2-like API based on the firmware backend ? In that case why do we need a proxy at all, why can't the Linux driver access the firmware "backend" directly and configure it th
Re: More videobuf and streaming I/O questions
Hi Pavel, On Tuesday 23 February 2010 08:41:49 Pawel Osciak wrote: > >On Mon, 22 Feb 2010 00:12:18 +0100 > >Laurent Pinchart wrote: > >> On Saturday 20 February 2010 15:00:21 Hans Verkuil wrote: > >> > 1) The spec mentions that the memory field should be set for > >> > VIDIOC_DQBUF. But videobuf doesn't need it and it makes no sense to > >> > me either unless it is for symmetry with VIDIOC_QBUF. Strictly > >> > speaking QBUF doesn't need it either, but it is a good sanity check. > >> > > >> > Can I remove the statement in the spec that memory should be set > >> > for DQBUF? The alternative is to add a check against the memory > >> > field in videobuf, but that's rather scary. > >> > >> In that case I would remove it for QBUF as well, and state that the > >> memory field must be ignored by drivers (but should they fill it when > >> returning from QBUF/DQBUF ?) > > > >Agree. It seems that the memory field is not useful at all in the struct > >v4l2_buffer if a same process does reqbuf, qbuf, dqbuf and querybuf. > > In the current multi-plane buffer proposal, the memory field is required > in querybuf, qbuf and dqbuf for the v4l2-ioctl.c code to be able to > determine whether the planes array should be copied from/to user along > with the buffer. > Just wanted to add another view to the problem, as multiplanes are accepted > yet of course. Thanks for the reminder. I'm not against keeping the requirement for applications to set the memory field in the v4l2_buffer structure. QBUF and DQBUF should behave the same way though, they should both require the field to be set or not require it at all. > As for the REQBUF, I've always thought it'd be nice to be able to ask the > driver for the "recommended" number of buffers that should be used by > issuing a REQBUF with count=0... How would the driver come up with the number of recommended buffers ? -- 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
LifeView FlyDVB Hybrid TV(at)anywhere A/C PCI dvb-t card
Hi, I have a LifeView FlyDVB Hybrid TV(at)anywhere A/C PCI dvb-t card. It used to work, but doesn't any more. I was assuming that the card was broken, but I have found other references to the card being "unstable". Did something change in the driver maybe a year ago or so? -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: fix precedence in dvb/frontends/tda665x
From: Randy Dunlap Fix precedence so that data is used correctly. Fixes sparse warning: drivers/media/dvb/frontends/tda665x.c:136:55: warning: right shift by bigger than source value Signed-off-by: Randy Dunlap Cc: Manu Abraham --- drivers/media/dvb/frontends/tda665x.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- lnx-2633-spr.orig/drivers/media/dvb/frontends/tda665x.c +++ lnx-2633-spr/drivers/media/dvb/frontends/tda665x.c @@ -133,7 +133,7 @@ static int tda665x_set_state(struct dvb_ frequency += config->ref_divider >> 1; frequency /= config->ref_divider; - buf[0] = (u8) (frequency & 0x7f00) >> 8; + buf[0] = (u8) ((frequency & 0x7f00) >> 8); buf[1] = (u8) (frequency & 0x00ff) >> 0; buf[2] = 0x80 | 0x40 | 0x02; buf[3] = 0x00; -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V6 2/2] OMAP2/3: Add V4L2 DSS driver support in device.c
* hvaib...@ti.com [100223 01:25]:
> From: Vaibhav Hiremath
>
>
> Signed-off-by: Vaibhav Hiremath
> ---
> arch/arm/plat-omap/devices.c | 29 +
> 1 files changed, 29 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/plat-omap/devices.c b/arch/arm/plat-omap/devices.c
> index 30b5db7..64f2a3a 100644
> --- a/arch/arm/plat-omap/devices.c
> +++ b/arch/arm/plat-omap/devices.c
> @@ -357,6 +357,34 @@ static void omap_init_wdt(void)
> static inline void omap_init_wdt(void) {}
> #endif
>
> +/*---*/
> +
> +#if defined(CONFIG_VIDEO_OMAP2_VOUT) || \
> + defined(CONFIG_VIDEO_OMAP2_VOUT_MODULE)
> +#if defined (CONFIG_FB_OMAP2) || defined (CONFIG_FB_OMAP2_MODULE)
> +static struct resource omap_vout_resource[3 - CONFIG_FB_OMAP2_NUM_FBS] = {
> +};
> +#else
> +static struct resource omap_vout_resource[2] = {
> +};
> +#endif
> +
> +static struct platform_device omap_vout_device = {
> + .name = "omap_vout",
> + .num_resources = ARRAY_SIZE(omap_vout_resource),
> + .resource = &omap_vout_resource[0],
> + .id = -1,
> +};
> +static void omap_init_vout(void)
> +{
> + (void) platform_device_register(&omap_vout_device);
> +}
Allocation can still fail here, please handle the results.
> +#else
> +static inline void omap_init_vout(void) {}
> +#endif
> +
> +/*---*/
> +
> /*
> * This gets called after board-specific INIT_MACHINE, and initializes most
> * on-chip peripherals accessible on this board (except for few like USB):
> @@ -387,6 +415,7 @@ static int __init omap_init_devices(void)
> omap_init_rng();
> omap_init_uwire();
> omap_init_wdt();
> + omap_init_vout();
> return 0;
> }
> arch_initcall(omap_init_devices);
Looks like this should be in mach-omap2/devices.c instead if it's all
omap2/3/4 specific.
Regards,
Tony
--
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] saa7134: Fix IR support of some ASUS TV-FM 7135 variants
Hi Jean, Am Donnerstag, den 25.02.2010, 14:12 +0100 schrieb Jean Delvare: > On Sat, 20 Feb 2010 04:07:05 +0100, hermann pitton wrote: > > Are you still waiting for Daro's report? > > Yes, I am still waiting. Unfortunately neither Daro nor Roman reported > any test result so far. Now, if we go for my second patch, I guess we > might as well apply it right now. It only affects this one card (Asus > P7131 analog), and it was broken so far, so I don't think my patch can > do any bad. yes, we can go for your second patch without any risk. It even will work, but I'm wondering if I would have to buy such card, to get it through. Thanks for your time to review that. > > As said, I would prefer to see all OEMs _not_ following Philips/NXP > > eeprom rules running into their own trash on GNU/Linux too. > > > > Then we have facts. > > > > That is much better than to provide a golden cloud for them. At least I > > won't help to debug such later ... > > > > If you did not manage to decipher all OEM eeprom content already, > > just let's go with the per card solution for now. > > > > Are you aware, that my intention is _not_ to spread the use of random > > and potentially invalid eeprom content for some sort of such auto > > detection? > > > > The other solution is not lost and in mind, if we should need to come > > back to it and are in details. Preferably the OEMs should take the > > responsibility for such. > > > > We can see, that even those always doing best on it, can't provide the > > missing informations for different LNA stuff after the > > Hauppauge/Pinnacle merge until now. > > > > If you claim to know it better, please share with us. > > I'm not claiming anything, and to be honest, I have no idea what you're > talking about. Never mind. I'll keep you posted when it comes to further progress on such and input_init2 is the needed better solution. We have a whole chain of previously latest different Asus cards supported by PCI subsystem identification, only this single one fails on it and needs eeprom bogus detection. On the Pinnacle stuff we have a complete mess, concerning LNAs, likely even different LNAs, no LNA at all, different remotes etc., all with the same PCI subsystem. You can't even detect the LNA type, if you would know the meaning of the complete eeprom content, since some to us unknown check-sums are in use for that. That I try to tell. You are welcome, 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
v4l-utils repo progress report
Hi All, I've been working on and off on the new v4l-utils git repo. I've just pushed my latest work, some restructuring of the files under the utils dir, and I've replaced the old Makefiles which were meant for compilation inside the v4l-dvb hg tree with new ones which work for standalone compilation. I've ended up with including copies of a few recent kernel headers as that indeed was the easiest way. I'm using plane (GNU) make for now, as that seems to work very well and I very much like the clean and simple Makefiles this has resulted in (as opposed to the zillion line makefiles generated by autotools). And yes the Makefiles take into account that libsysfs and / or qt might not be installed and do not build the relevant bits when they are missing. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: Tree for February 22 (media/video/tvp7002)
On 02/25/10 12:34, Hans Verkuil wrote:
> On Thursday 25 February 2010 17:52:05 Randy Dunlap wrote:
>> On Mon, 22 Feb 2010 08:21:44 -0800 Randy Dunlap wrote:
>>
>>> On 02/21/10 22:22, Stephen Rothwell wrote:
>>>> Hi all,
>>>>
>>>> Changes since 20100219:
>>>
>>>
>>> drivers/media/video/tvp7002.c:896: error: 'struct tvp7002' has no member
>>> named 'registers'
>>
>> same problem in linux-next-20100225.
>>
>> so where are these registers??
>
> Hmm, that code is a remnant from older revisions of this driver.
> Unfortunately,
> when I compiled this driver before creating my pull request I forgot to turn
> on
> the CONFIG_VIDEO_ADV_DEBUG option and so I never saw it.
>
> Anyway, below is a patch that fixes this. Please apply.
>
> Signed-off-by: Hans Verkuil
Acked-by: Randy Dunlap
Thanks.
> Santiago, I've also fixed the g_register function: it never returned a
> register
> value in the original code.
>
> Regards,
>
> Hans
>
> diff --git a/drivers/media/video/tvp7002.c b/drivers/media/video/tvp7002.c
> index 0f0270b..5a878bc 100644
> --- a/drivers/media/video/tvp7002.c
> +++ b/drivers/media/video/tvp7002.c
> @@ -859,13 +859,17 @@ static int tvp7002_g_register(struct v4l2_subdev *sd,
> struct v4l2_dbg_register *reg)
> {
> struct i2c_client *client = v4l2_get_subdevdata(sd);
> + u8 val;
> + int ret;
>
> if (!v4l2_chip_match_i2c_client(client, ®->match))
> return -EINVAL;
> if (!capable(CAP_SYS_ADMIN))
> return -EPERM;
>
> - return reg->val < 0 ? -EINVAL : 0;
> + ret = tvp7002_read(sd, reg->reg & 0xff, &val);
> + reg->val = val;
> + return ret;
> }
>
> /*
> @@ -881,21 +885,13 @@ static int tvp7002_s_register(struct v4l2_subdev *sd,
> struct v4l2_dbg_register *reg)
> {
> struct i2c_client *client = v4l2_get_subdevdata(sd);
> - struct tvp7002 *device = to_tvp7002(sd);
> - int wres;
>
> if (!v4l2_chip_match_i2c_client(client, ®->match))
> return -EINVAL;
> if (!capable(CAP_SYS_ADMIN))
> return -EPERM;
>
> - wres = tvp7002_write(sd, reg->reg & 0xff, reg->val & 0xff);
> -
> - /* Update the register value in device's table */
> - if (!wres)
> - device->registers[reg->reg].value = reg->val;
> -
> - return wres < 0 ? -EINVAL : 0;
> + return tvp7002_write(sd, reg->reg & 0xff, reg->val & 0xff);
> }
> #endif
>
>
>
--
~Randy
--
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-next: Tree for February 22 (media/video/tvp7002)
On Thursday 25 February 2010 17:52:05 Randy Dunlap wrote:
> On Mon, 22 Feb 2010 08:21:44 -0800 Randy Dunlap wrote:
>
> > On 02/21/10 22:22, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Changes since 20100219:
> >
> >
> > drivers/media/video/tvp7002.c:896: error: 'struct tvp7002' has no member
> > named 'registers'
>
> same problem in linux-next-20100225.
>
> so where are these registers??
Hmm, that code is a remnant from older revisions of this driver. Unfortunately,
when I compiled this driver before creating my pull request I forgot to turn on
the CONFIG_VIDEO_ADV_DEBUG option and so I never saw it.
Anyway, below is a patch that fixes this. Please apply.
Signed-off-by: Hans Verkuil
Santiago, I've also fixed the g_register function: it never returned a register
value in the original code.
Regards,
Hans
diff --git a/drivers/media/video/tvp7002.c b/drivers/media/video/tvp7002.c
index 0f0270b..5a878bc 100644
--- a/drivers/media/video/tvp7002.c
+++ b/drivers/media/video/tvp7002.c
@@ -859,13 +859,17 @@ static int tvp7002_g_register(struct v4l2_subdev *sd,
struct v4l2_dbg_register *reg)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
+ u8 val;
+ int ret;
if (!v4l2_chip_match_i2c_client(client, ®->match))
return -EINVAL;
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
- return reg->val < 0 ? -EINVAL : 0;
+ ret = tvp7002_read(sd, reg->reg & 0xff, &val);
+ reg->val = val;
+ return ret;
}
/*
@@ -881,21 +885,13 @@ static int tvp7002_s_register(struct v4l2_subdev *sd,
struct v4l2_dbg_register *reg)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
- struct tvp7002 *device = to_tvp7002(sd);
- int wres;
if (!v4l2_chip_match_i2c_client(client, ®->match))
return -EINVAL;
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
- wres = tvp7002_write(sd, reg->reg & 0xff, reg->val & 0xff);
-
- /* Update the register value in device's table */
- if (!wres)
- device->registers[reg->reg].value = reg->val;
-
- return wres < 0 ? -EINVAL : 0;
+ return tvp7002_write(sd, reg->reg & 0xff, reg->val & 0xff);
}
#endif
>
> thanks,
> ---
> ~Randy
> --
> 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
>
>
--
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
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 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:Thu Feb 25 19:00:32 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14319:37581bb7e6f1 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.32.6-armv5-dm365: ERRORS linux-2.6.33-armv5-dm365: ERRORS linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-armv5-ixp: OK linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.17-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.20-i686: OK linux-2.6.26.8-i686: OK linux-2.6.27.44-i686: OK linux-2.6.28.10-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.22.19-x86_64: OK linux-2.6.23.17-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.20-x86_64: OK linux-2.6.26.8-x86_64: OK linux-2.6.27.44-x86_64: OK linux-2.6.28.10-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK spec: OK sparse (v4l-dvb-git): ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: OK linux-2.6.19.7-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: OK linux-2.6.19.7-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 2/4] DocBook: Add rules to auto-generate some media docbooks
On 02/25/10 09:33, Mauro Carvalho Chehab wrote: > There are some files that are automatically generated by the old > subsystem Makefile. Move those rules to kernel DocBook Makefile, in > order to autogenerate the media cross-reference files: > media-entities.tmpl > media-indices.tmpl > dvb/frontend.h.xml > v4l/videodev2.h.xml > > Signed-off-by: Mauro Carvalho Chehab > > Fix makefile > > Signed-off-by: Mauro Carvalho Chehab > > delete mode 100644 Documentation/DocBook/dvb/frontend.h.xml > delete mode 100644 Documentation/DocBook/media-entities.tmpl > delete mode 100644 Documentation/DocBook/media-indices.tmpl > delete mode 100644 Documentation/DocBook/v4l/videodev2.h.xml > > diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile > index 7c590ef..36068db 100644 > --- a/Documentation/DocBook/Makefile > +++ b/Documentation/DocBook/Makefile > @@ -6,6 +6,8 @@ > # To add a new book the only step required is to add the book to the > # list of DOCBOOKS. > > +TMPMEDIA=.tmpmedia > + > DOCBOOKS := z8530book.xml mcabook.xml device-drivers.xml \ > kernel-hacking.xml kernel-locking.xml deviceiobook.xml \ > writing_usb_driver.xml networking.xml \ > @@ -14,7 +16,7 @@ DOCBOOKS := z8530book.xml mcabook.xml device-drivers.xml \ > genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \ > mac80211.xml debugobjects.xml sh.xml regulator.xml \ > alsa-driver-api.xml writing-an-alsa-driver.xml \ > - tracepoint.xml media.xml > + tracepoint.xml $(TMPMEDIA)/media.xml > > ### > # The build process is as follows (targets): > @@ -32,10 +34,10 @@ PS_METHOD = $(prefer-db2x) > > ### > # The targets that may be used. > -PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs > cleandocs xmldoclinks > +PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs > cleandocs mediaprep > > BOOKS := $(addprefix $(obj)/,$(DOCBOOKS)) > -xmldocs: $(BOOKS) xmldoclinks > +xmldocs: $(BOOKS) > sgmldocs: xmldocs > > PS := $(patsubst %.xml, %.ps, $(BOOKS)) > @@ -47,24 +49,11 @@ pdfdocs: $(PDF) > HTML := $(sort $(patsubst %.xml, %.html, $(BOOKS))) > htmldocs: $(HTML) > @$($(quiet)cmd_build_main_index) > - @$($(call build_main_index)) > - @($(call build_images)) > + @($(call build_main_index)) > > MAN := $(patsubst %.xml, %.9, $(BOOKS)) > mandocs: $(MAN) > > -build_images = mkdir -p $(objtree)/Documentation/DocBook/media/ && \ > -cp $(srctree)/Documentation/DocBook/dvb/*.png > $(srctree)/Documentation/DocBook/v4l/*.gif > $(objtree)/Documentation/DocBook/media/ > - > -xmldoclinks: > -ifneq ($(objtree),$(srctree)) > - for dep in dvb media-entities.tmpl media-indices.tmpl v4l; do \ > - rm -f $(objtree)/Documentation/DocBook/$$dep \ > - && ln -s $(srctree)/Documentation/DocBook/$$dep > $(objtree)/Documentation/DocBook/ \ > - || exit; \ > - done > -endif > - > installmandocs: mandocs > mkdir -p /usr/local/man/man9/ > install Documentation/DocBook/man/*.9.gz /usr/local/man/man9/ > @@ -100,7 +89,7 @@ endef > $(call if_changed_rule,docproc) > > ### > -#Read in all saved dependency files > +#Read in all saved dependency files > cmd_files := $(wildcard $(foreach f,$(BOOKS),$(dir $(f)).$(notdir $(f)).cmd)) > > ifneq ($(cmd_files),) > @@ -151,7 +140,7 @@ quiet_cmd_build_main_index = echo ' BUILD $@' > > index = index.html > main_idx = Documentation/DocBook/$(index) > -build_main_index = rm -rf $(main_idx) && \ > +build_main_index = rm -rf $(main_idx); \ > echo 'Linux Kernel HTML Documentation' >> > $(main_idx) && \ > echo 'Kernel Version: $(KERNELVERSION)' >> > $(main_idx) && \ > cat $(HTML) >> $(main_idx) > @@ -241,7 +230,7 @@ clean-files := $(DOCBOOKS) \ > $(patsubst %.xml, %.9,$(DOCBOOKS)) \ > $(index) > > -clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man > +clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man $(MEDIADIR) > > cleandocs: > $(Q)rm -f $(call objectify, $(clean-files)) > @@ -251,3 +240,498 @@ cleandocs: > # information in a variable se we can use it in if_changed and friends. > > .PHONY: $(PHONY) > + > + > +# > +# Media build rules - Auto-generates media contents/indexes and *.h xml's > +# > + > +SHELL=/bin/bash > + > +MEDIA_DIR=$(objtree)/Documentation/DocBook/$(TMPMEDIA) 1/ The top-level html documentation index file now begins with "media". They are supposed to be in alphabetical order. (This is minor, won't hold up the merge.) Linux Kernel HTML Documentation Kernel Version: 2.6.33 media alsa-driver-api debugobjects device-drivers deviceiobook filesystems etc. 2/ Clicking on "media" in the index list above gets a "file not found" error, I think because TMPMEDIA=.tmpmedia and it's never copied to the correct output directory. Ah, there is a media/ dir under .tmpmedia an
[PATCHv2 3/4] DocBook/v4l/pixfmt.xml: Add missing formats for gspca cpia1 and sn9c2028 drivers
Signed-off-by: Mauro Carvalho Chehab diff --git a/Documentation/DocBook/v4l/pixfmt.xml b/Documentation/DocBook/v4l/pixfmt.xml index 885968d..6e38f50 100644 --- a/Documentation/DocBook/v4l/pixfmt.xml +++ b/Documentation/DocBook/v4l/pixfmt.xml @@ -685,6 +685,11 @@ http://www.ivtvdriver.org/The format is documented in the kernel sources in the file Documentation/video4linux/cx2341x/README.hm12 + + V4L2_PIX_FMT_CPIA1 + 'CPIA' + YUV format used by the gspca cpia1 driver. + V4L2_PIX_FMT_SPCA501 'S501' @@ -770,6 +775,11 @@ kernel sources in the file Documentation/video4linux/cx2341x/README.hm 'S920' YUV 4:2:0 format of the gspca sn9c20x driver. + + V4L2_PIX_FMT_SN9C2028 + 'SONX' + Compressed GBRG bayer format of the gspca sn9c2028 driver. + V4L2_PIX_FMT_STV0680 'S680' -- 1.6.6.1 -- 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-next: Tree for February 22 (media/video/tvp7002)
On Mon, 22 Feb 2010 08:21:44 -0800 Randy Dunlap wrote: > On 02/21/10 22:22, Stephen Rothwell wrote: > > Hi all, > > > > Changes since 20100219: > > > drivers/media/video/tvp7002.c:896: error: 'struct tvp7002' has no member > named 'registers' same problem in linux-next-20100225. so where are these registers?? thanks, --- ~Randy -- 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
sample using v4l2-subdev.h
Hello, I'm quite new to linux kernel driver. As a try, I would like to write a v4l-i2c driver for my radio, using . Is there a good example in the 2.6.32 tree that you can recommend to me ? Thanks, Fabien -- 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] saa7134: Fix IR support of some ASUS TV-FM 7135 variants
On Sat, 20 Feb 2010 04:07:05 +0100, hermann pitton wrote: > Are you still waiting for Daro's report? Yes, I am still waiting. Unfortunately neither Daro nor Roman reported any test result so far. Now, if we go for my second patch, I guess we might as well apply it right now. It only affects this one card (Asus P7131 analog), and it was broken so far, so I don't think my patch can do any bad. > As said, I would prefer to see all OEMs _not_ following Philips/NXP > eeprom rules running into their own trash on GNU/Linux too. > > Then we have facts. > > That is much better than to provide a golden cloud for them. At least I > won't help to debug such later ... > > If you did not manage to decipher all OEM eeprom content already, > just let's go with the per card solution for now. > > Are you aware, that my intention is _not_ to spread the use of random > and potentially invalid eeprom content for some sort of such auto > detection? > > The other solution is not lost and in mind, if we should need to come > back to it and are in details. Preferably the OEMs should take the > responsibility for such. > > We can see, that even those always doing best on it, can't provide the > missing informations for different LNA stuff after the > Hauppauge/Pinnacle merge until now. > > If you claim to know it better, please share with us. I'm not claiming anything, and to be honest, I have no idea what you're talking about. -- Jean Delvare -- 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: Requested feedback on V4L2 driver design
Laurent, Some additional information from the syslink team. Yes, the current Notify code is indeed going over the kernel mailbox code. You can find this code in drivers/dsp/syslink/notify_ducatidriver/notify_ducati.c. We have already pushed some mailbox patches specific to the new mailbox register set in OMAP4/Netra to kernel. These patches are available starting in 2.6.33. On our tree, we currently have some custom patches some of which were pushed to upstream and in the process of getting rolled into the upcoming 2.6.34 releases. Sincerely, Chase Maupin Software Applications Catalog DSP Products e-mail: chase.mau...@ti.com phone: (281) 274-3285 For support: Forums - http://community.ti.com/forums/ Wiki - http://wiki.davincidsp.com/ > -Original Message- > From: Kamoolkar, Mugdha > Sent: Wednesday, February 24, 2010 9:05 PM > To: Maupin, Chase; Laurent Pinchart > Cc: Hans Verkuil; sakari.ai...@maxwell.research.nokia.com; > mche...@infradead.org; vpss_driver_des...@list.ti.com - This list is to > discuss the VPSS driver design (May contain non-TIers); linux- > me...@vger.kernel.org; Kanigeri, Hari; Shah, Bhavin; Anna, Suman > Subject: RE: Requested feedback on V4L2 driver design > > Chase, Laurent, > > Sorry for the extreme delay in my response ... > From the code available currently on omapzoom, our plans are to eventually > have only the Notify module in kernel-space. All the other code in > multicore_ipc will actually move to user-side. The Notify module gives > additional functionality over the basic mailbox driver to abstract the > single physical event into multiple logical events. This enables multiple > clients (one of which is the DSS driver) to use the single physical > interrupt for multiple different purposes in a fully modular manner. We > will ensure that the kernel-side Notify module is fully integrated into > the kernel in the proper way and still meets our functionality > requirements, taking feedback from the community into account. > > We are also making several changes in the APIs for all modules to make > them much easier to use. A lot of the complexity as seen by the user will > vanish underneath. This is still under progress, so it's not out on > omapzoom yet, but will definitely be done. > > > As soon as this is done, we will work on moving most of the modules > (except Notify) fully from kernel->user space. Once our kernel->user work > has at least gone far enough ahead to allow us to make a design proposal, > we will push it out for review to get your valuable feedback. > > I have also looped in the TI engineers who have worked on and pushed out > the omapzoom SysLink code. > > Regards, > Mugdha > > -Original Message- > From: Maupin, Chase > Sent: Friday, February 12, 2010 10:17 PM > To: Laurent Pinchart > Cc: Hans Verkuil; sakari.ai...@maxwell.research.nokia.com; > mche...@infradead.org; vpss_driver_des...@list.ti.com - This list is to > discuss the VPSS driver design (May contain non-TIers); linux- > me...@vger.kernel.org; Kamoolkar, Mugdha > Subject: RE: Requested feedback on V4L2 driver design > > Laurent, > > First let me thank you for taking time to review this. I have made > comments below to address your concerns. > > Sincerely, > Chase Maupin > Software Applications > Catalog DSP Products > e-mail: chase.mau...@ti.com > phone: (281) 274-3285 > > For support: > Forums - http://community.ti.com/forums/ > Wiki - http://wiki.davincidsp.com/ > > > -Original Message- > > From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] > > Sent: Thursday, February 11, 2010 7:23 PM > > To: Maupin, Chase > > Cc: Hans Verkuil; sakari.ai...@maxwell.research.nokia.com; > > mche...@infradead.org; vpss_driver_des...@list.ti.com - This list is to > > discuss the VPSS driver design (May contain non-TIers); linux- > > me...@vger.kernel.org > > Subject: Re: Requested feedback on V4L2 driver design > > > > Hi Chase, > > > > On Monday 08 February 2010 16:08:37 Maupin, Chase wrote: > > > All, > > > > > > Texas Instruments (TI) is working on the design for the V4L2 capture > and > > > display drivers for our next generation system-on-chip (SoC) processor > > and > > > would like to solicit your feedback. > > > > Thank you very much for requesting feedback on the system design. I > > personally > > appreciate this, and I'm pretty sure that the feeling is shared by most > of > > the > > Linux kernel developers. > > > > > If you have additional questions or need more information please feel > > free > > > to contact us (we have setup a mailing list at > > > vpss_driver_des...@list.ti.com) so we can answer them. > > > > I'll answer here as the instructions provided in the wiki to subscribe > to > > the > > vpss_driver_design mailing list are incorrect (http://list.ti.com/ isn't > > accessible, the name has no A record associated to it). I've CC'ed the > > list in > > case subscription wouldn't be required to post. > > The page for subscribing to the list require
Re: You are now subscribed to linuxtv-dvb-apps
On 25/02/2010 11:08, ow...@packages.qa.debian.org wrote: Processing commands for p...@qa.debian.org: Subject: Re: CONFIRM f156db6194c056981f5711b7ef302743 linux-media@vger.kernel.org has been subscribed to linuxtv-dvb-a...@packages.qa.debian.org. -- 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 what is going on here? -- 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
Em28xx: vidioc_s_fmt_vid_cap queue busy
Hi all, I've compiled em28xx for openwrt, on an ixp4xx cpu (armeb, Linskys NSLU2). Kernel is 2.6.32.8, all went ok. The device is a generic em2860, on my x86 pc it works ok: Bus 001 Device 002: ID eb1a:2860 eMPIA Technology, Inc. Modules loaded successfully but when i start a grab (with simple hasciicam) I obtain an error: error in ioctl VIDIOCSYNC: : Device or resource busy (I'll attach the whol output to end of message) dmesg says: em28xx #0: vidioc_s_fmt_vid_cap queue busy then i load videobuf-core, videobuf-vmalloc with debug=1 and em28xx with core-debug=1 and dmesg says:: vbuf-vmalloc: __videobuf_mmap_free vbuf-vmalloc: __videobuf_mmap_free vbuf: reqbufs: bufs=8, size=0x9000 [72 pages total] vbuf-vmalloc: __videobuf_mmap_free vbuf-vmalloc: __videobuf_alloc: allocated at c1ef00e0(100+16) & c1ef0154(12) vbuf-vmalloc: __videobuf_alloc: allocated at c1ef0660(100+16) & c1ef06d4(12) vbuf-vmalloc: __videobuf_alloc: allocated at c1ef06e0(100+16) & c1ef0754(12) vbuf-vmalloc: __videobuf_alloc: allocated at c1ef0560(100+16) & c1ef05d4(12) vbuf-vmalloc: __videobuf_alloc: allocated at c1ef03e0(100+16) & c1ef0454(12) vbuf-vmalloc: __videobuf_alloc: allocated at c1ef0360(100+16) & c1ef03d4(12) vbuf-vmalloc: __videobuf_alloc: allocated at c1ef02e0(100+16) & c1ef0354(12) vbuf-vmalloc: __videobuf_alloc: allocated at c1ef0260(100+16) & c1ef02d4(12) vbuf: mmap setup: 8 buffers, 36864 bytes each em28xx #0 em28xx_accumulator_set :em28xx Scale: (1,1)-(179,255) em28xx #0 em28xx_capture_area_set :em28xx Area Set: (180,0) vbuf: qbuf: mmap requested but buffer addr is zero! vbuf-vmalloc: __videobuf_mmap_mapper vbuf-vmalloc: vmalloc is at addr c2bec000 (294912 pages) vbuf-vmalloc: mmap c1135a00: q=c1d3620c 400cf000-40117000 (9000) pgoff buf 0 vbuf: busy: buffer #0 mapped em28xx #0: vidioc_s_fmt_vid_cap queue busy vbuf-vmalloc: munmap c1135a00 q=c1d3620c vbuf-vmalloc: videobuf_vm_close: buf[0] freeing (c2bec000) vbuf-vmalloc: __videobuf_mmap_free vbuf-vmalloc: __videobuf_mmap_free This is output of hasciicam: r...@openwrt:/tmp# hasciicam -d /dev/video0 -m text HasciiCam 1.0 - (h)ascii 4 the masses! - http://ascii.dyne.org (c)2000-2006 Denis Roio < jaromil @ dyne.org > watch out for the (h)ASCII ROOTS Device detected is /dev/video0 EM2860/SAA711X Reference Design 2 channels detected max size w[720] h[576] - min size w[48] h[32] Video capabilities: VID_TYPE_CAPTURE can capture to memory VID_TYPE_TELETEXT has teletext capability memory map of 8 frames: 294912 bytes Offset of frame 0: 0 Offset of frame 1: 36864 Offset of frame 2: 73728 Offset of frame 3: 110592 Offset of frame 4: 147456 Offset of frame 5: 184320 Offset of frame 6: 221184 Offset of frame 7: 258048 error in ioctl VIDIOCMCAPTURE: Invalid argumenterror in ioctl VIDIOCMCAPTURE: Device or resource busy - (h)ascii size is 80x40 using TEXT mode dumping to file hasciicam.asc error in ioctl VIDIOCSYNC: : Device or resource busy error in ioctl VIDIOCSYNC: : Device or resource busy ^Cinterrupt caught, exiting. cya! - Anyone has some idea??? Thank you for help! -- Denis -- 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: CONFIRM f156db6194c056981f5711b7ef302743
-- 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
You are now subscribed to linuxtv-dvb-apps
Processing commands for p...@qa.debian.org: > Subject: Re: CONFIRM f156db6194c056981f5711b7ef302743 linux-media@vger.kernel.org has been subscribed to linuxtv-dvb-a...@packages.qa.debian.org. > -- 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: [ANNOUNCE] git tree repositories & libv4l
Hi,
On 02/24/2010 03:32 PM, Brandon Philips wrote:
On 13:55 Wed 24 Feb 2010, Hans de Goede wrote:
Where necessary libv4l currently has code snippets like:
#ifndef V4L2_PIX_FMT_SPCA501
#define V4L2_PIX_FMT_SPCA501 v4l2_fourcc('S','5','0','1') /* YUYV per line */
#endif
I don't think this is less work than copying the header file from the
Kernel. Test building under all versions of the Kernel headers that
exist to make sure something isn't missed isn't possible. It really is
easier just to sync the header file up.
The reason for this is that I want to avoid carrying a copy of a dir
from some other tree, with all getting stale and needing sync all
the time issues that come with that, not to mention chicken and egg
problems in the case of new formats which simultaneously need to be
added to both libv4l and the kernel.
Worst case is that if it is stale then it won't build since it depends
on fancy new feature XYZ. But, at least it won't build on all systems
instead of randomly breaking based on installed kernel headers
version.
For example often I add support for V4L2_PIX_FMT_NEW_FOO to libv4l, before it
hits any official v4l-dvb kernel tree, with the:
Please don't add features to releases before they are merged with
Linus. It would suck to ship a copy of libv4l that has a different
idea of structs or constants then the upstream Kernel.
Note the only thing added is a V4L2_PIX_FMT_xxx define, IOW this makes libv4l
recognize (and convert from) a new video format, which is to be generated
by a going upstream soon driver. With older kernels this won't make any
difference as those don't generate that format.
Approach this works fine, if I were to carry an include tree copy, that would
now need to become a patched include tree copy, and with the next sync I then
need to ensure that any needed patches are either already in the sync source,
or applied again.
Or just fix it upstream with #ifdef __KERNEL__ tags once and for all,
right?
I wasn't even talking about #ifdef __KERNEL__ issues, although yes those
exist too.
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
CONFIRM f156db6194c056981f5711b7ef302743
Hello, you asked to be subscribed to the "mailing list"[1] for the Debian source package called linuxtv-dvb-apps. To complete this process, you have to reply to this mail by including this command : CONFIRM f156db6194c056981f5711b7ef302743 On any modern mailer, you just have to hit reply and send the mail. If you don't understand why you got this mail, please ignore it, you won't be subscribed to anything unless you confirm it. If you have any problem with this service, please contact ow...@packages.qa.debian.org. Thanks, [1] This list receives all the bug reports (and the corresponding logs) for the package "linuxtv-dvb-apps" that are sent to the Debian Bug Tracking System. http://packages.qa.debian.org/linuxtv-dvb-apps -- 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
Fwd: Bug#566336: dvb-apps: be-Schoten and be-Antwerp run on 506MHz
-- Forwarded Message -- Subject: Bug#566336: dvb-apps: be-Schoten and be-Antwerp run on 506MHz Date: Saturday 23 January 2010 From: Danai SAE-HAN (=E9=9F=93=E9=81=94=E8=80=90) To: sub...@bugs.debian.org Package: dvb-apps Version: 1.1.1+rev1273-1 Severity: minor Hi The file be-Schoten currently has a frequency of 778MHz, but it should be 506MHz. Also, there is another broadcaster in Antwerp, so could you also add a file called be-Antwerp with frequency 506MHz? Source (in Dutch): http://nl.wikipedia.org/wiki/DVB-T-frequenties Cheers -- Danai -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686-bigmem (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dvb-apps depends on: ii libc6 2.10.2-5 Embedded GNU C Library: Shared lib ii makedev 2.3.1-89 creates device files in /dev ii udev 150-2 /dev/ and hotplug management daemo dvb-apps recommends no packages. dvb-apps suggests no packages. -- no debconf information --- signature.asc Description: This is a digitally signed message part.
Re: Web subscription for linuxtv-dvb-apps package
Processing commands for p...@qa.debian.org: > Subject: Web subscription for linuxtv-dvb-apps package > subscribe linuxtv-dvb-apps linux-media@vger.kernel.org A confirmation mail has been sent to linux-me...@vger.kernel.org. > -- 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
Fwd: Bug#540660: dvb-apps: Missing muxes
-- Forwarded Message -- Subject: Bug#540660: dvb-apps: Missing muxes Date: Sunday 09 August 2009 From: Hakan Ardo To: Debian Bug Tracking System Package: dvb-apps Version: 1.1.1+rev1207-3 Severity: normal Hi, there are two muxes missing in dvb-t/se-Horby_Sallerup. Please add: T 65000 8MHz 3/4 NONE QAM64 8k 1/4 NONE T 57000 8MHz 3/4 NONE QAM64 8k 1/4 NONE Tahnx # diff -c /usr/share/dvb/dvb-t/se-Horby_Sallerup se-Horby_Sallerup *** /usr/share/dvb/dvb-t/se-Horby_Sallerup 2008-09-05 11:52:04.0 +0200 --- se-Horby_Sallerup 2009-08-09 15:18:16.0 +0200 *** *** 1,5 --- 1,7 # Sweden - Hörby/Sallerup # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy + T 65000 8MHz 3/4 NONE QAM64 8k 1/4 NONE + T 57000 8MHz 3/4 NONE QAM64 8k 1/4 NONE T 48200 8MHz 3/4 NONE QAM64 8k 1/4 NONE T 50600 8MHz 3/4 NONE QAM64 8k 1/4 NONE T 63400 8MHz 3/4 NONE QAM64 8k 1/4 NONE -- System Information: Debian Release: 3.1 APT prefers stable APT policy: (990, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages dvb-apps depends on: ii libc6 2.7-14 GNU C Library: Shared libraries ii makedev 2.3.1-82 creates device files in /dev ii udev 0.093-1/dev/ and hotplug management daemo dvb-apps recommends no packages. -- no debconf information --- signature.asc Description: This is a digitally signed message part.
Re: Status of the patches under review (29 patches)
On Wed, 24 Feb 2010 10:10:16 -0300, Mauro Carvalho Chehab wrote: > Hi Jean, > > Jean Delvare wrote: > > > I have 3 patches pending which aren't in your list. I can see them in > > patchwork: > > > > http://patchwork.kernel.org/patch/79755/ > > http://patchwork.kernel.org/patch/79754/ > > http://patchwork.kernel.org/patch/77349/ > > > > The former two are in "Accepted" state, and actually I received an > > e-mail telling me they had been accepted, however I can't see them in > > the hg repository. So where are they? > > They are already on the git tree: > > commit 2887117b31b77ebe5fb42f95ea8d77a3716b405b > Author: Jean Delvare > Date: Tue Feb 16 14:22:37 2010 -0300 > > V4L/DVB: bttv: Let the user disable IR support > > Add a new module parameter "disable_ir" to disable IR support. Several > other drivers do that already, and this can be very handy for > debugging purposes. > > Signed-off-by: Jean Delvare > Signed-off-by: Mauro Carvalho Chehab > > commit e151340a2a9e7147eb48114af0381122130266b0 > Author: Jean Delvare > Date: Fri Feb 19 00:18:41 2010 -0300 > > V4L/DVB: bttv: Move I2C IR initialization > > Move I2C IR initialization from just after I2C bus setup to right > before non-I2C IR initialization. This avoids the case where an I2C IR > device is blocking audio support (at least the PV951 suffers from > this). It is also more logical to group IR support together, > regardless of the connectivity. > > This fixes bug #15184: > http://bugzilla.kernel.org/show_bug.cgi?id=15184 > > Signed-off-by: Jean Delvare > CC: sta...@kernel.org > Signed-off-by: Mauro Carvalho Chehab > > As patches in -hg are manually backported, maybe Douglas > haven't backported it yet or he simply missed. > > Douglas, could you please check this? Ah, my bad. I totally missed that you had moved from hg to git for the main development tree. I was still pulling from hg and basing my patches on it. I will clone the git tree now, sorry for the confusion. > > The latter is in "Not Applicable" state, and I have no idea what it > > means. The patch is really simple and I see no formatting issue. Should > > I just resend it? > > This means that this patch is not applicable on -git. There's no versions.txt > upstream. All patches that don't have upstream code are marked as such on > patchwork. I generally ping Douglas on such cases, for him to double check on > -hg. > > Anyway, the better is to c/c to Douglas on all patches that are meant only > to the building system. > > Douglas, could you please check if you've applied this patch? Thanks Douglas. -- Jean Delvare -- 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
Problem with v4l tree and kernel 2.6.33
Kernel 2.6.33 just went stable. I compiled, installed, reboot. Grabbed a fresh v4l tree, menuconfig'ed, compiled and installed. Upon loading I got "Invalid module format" for each file. For example: WARNING: Error inserting dvb_ttpci (/lib/modules/2.6.33.amd64-x2.022410.1/kernel/drivers/media/dvb/ttpci/dvb-ttpci.ko): Invalid module format I then did a distclean, make, make install: Updating/Creating .config Preparing to compile for kernel version 2.6.33 VIDEO_TVP7002: Requires at least kernel 2.6.34 RADIO_SAA7706H: Requires at least kernel 2.6.34 Created default (all yes) .config file Again, "Invalid module format". I then confirmed that .version matched my 2.6.33 kernel: test:/v4l-dvb$ cat v4l/.version VERSION=2 PATCHLEVEL:=6 SUBLEVEL:=33 KERNELRELEASE:=2.6.33.amd64-x2.022410.1 test:/v4l-dvb$ uname -r 2.6.33.amd64-x2.022410.1 So... I'm at a loss why this is happening. Any ideas? kernel 2.6.33 gcc (Debian 4.4.2-9) 4.4.3 20100108 (prerelease) v4l tree 37581bb7e6f1 tip Thanks in advance. -- 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
