v4l-utils : qv4l2: symbol lookup error: qv4l2: undefined symbol: libv4l2_default_dev_ops

[Lalitanand Dandge]

Hi,
I compiled and installed v4l-utils on Ubuntu 11.04 machine.
After this installation while running qv4l2 I am getting following
error.

qv4l2: symbol lookup error: qv4l2: undefined symbol:
libv4l2_default_dev_ops 

Kindly help getting to the roots of this problem,

Note:
I am using following repository to get the source
git clone git://git.linuxtv.org/v4l-utils.git
and following is the snippet of the uname -a command
2.6.38-10-generic-pae #46-Ubuntu SMP Tue Jun 28 16:54:49 UTC 2011 i686
i686 i386 GNU/Linux

Thanks and regards,

Lalitanand

--
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: USB mini-summit at LinuxCon Vancouver

[Theodore Kilgore]

On Thu, 4 Aug 2011, Greg KH wrote:

> On Thu, Aug 04, 2011 at 07:21:47PM -0300, Mauro Carvalho Chehab wrote:
> > I know that this problem were somewhat solved for 3G modems, with the usage
> > of the userspace problem usb_modeswitch, and with some quirks for the USB
> > storage driver, but I'm not sure if such tricks will scale forever, as more
> > functions are seen on some USB devices.
> 
> Well, no matter how it "scales" it needs to be done in userspace, like
> usb_modeswitch does.  We made that decision a while ago, and it is
> working out very well.  I see no reason why you can't do it in userspace
> as well as that is the easiest place to control this type of thing.
> 
> I thought we had a long discussion about this topic a while ago and came
> to this very conclusion.  Or am I mistaken?
> 
> thanks,
> 
> greg k-h
> 

Greg,

A little bit more of precision would help me a lot, here. Precisely what 
is one supposed to do in userspace? I would naturally assume that the user 
will control the device by announcing what the user wants to do with the 
device. Such control would therefore have to start in userspace. But this 
is such an obvious truism that you must mean something else. What, then?

To say to do things "like usb_modeswitch" is rather vague. For one thing, 
usb_modeswitch, being something out there in userspace, does _not_ affect 
what is in the kernel. However, what is (or is not) in the kernel might 
make it possible (or, in the alternative, impossible) to facilitate the 
action of some kind of userspace function-switching program similar to 
usb_modeswitch, not so? 

As to the "long discussion about this topic a while ago" that may have 
been a discussion in which I was also involved. For, I do remember a 
discussion about this topic a few months ago. In one respect my memory 
differs from yours, however: It was not my impression that any definite 
conclusions were reached, certainly not a consensus. BTW, I did try to lay 
out what I remembered as three alternatives that came up, along with 
arguments for and against each of them, in my message which kicked off 
this thread today. 

It is of course a real possibility that you have seen the perfect solution 
in your mind to these problems, which have vexed a lot of people for 
years, and others have not. If that is the way it is, then perhaps you 
just wish that we would all shut up, implement what is obvious, and we 
could all be happy. This could certainly be the case. You have written a 
lot more code than I have, and you obviously must have started doing that 
when you were at least 30 years younger, perhaps even 40 years younger, 
than I was when I started. So I would be the first to say that you are 
much better at it than I am. But there are others here, too, who seem 
actively to have been sucked into this discussion, and they are similarly 
younger and more clever than I am, too. 

Giving due consideration to this, it would probably get the job done a lot 
faster if you just take the time to describe what grand vision you 
yourself have in mind for the solution of the problem, with a sufficient 
accounting of the details that people can all see what it is and exactly 
how and why it would work absolutely perfectly, and then we can just get 
busy and do it.

Theodore Kilgore
--
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: USB mini-summit at LinuxCon Vancouver

[Mauro Carvalho Chehab]

Em 04-08-2011 20:22, Matthew Dharm escreveu:
> On Thu, Aug 4, 2011 at 3:56 PM, Greg KH  > wrote:
> 
> On Thu, Aug 04, 2011 at 07:21:47PM -0300, Mauro Carvalho Chehab wrote:
> > I know that this problem were somewhat solved for 3G modems, with the 
> usage
> > of the userspace problem usb_modeswitch, and with some quirks for the 
> USB
> > storage driver, but I'm not sure if such tricks will scale forever, as 
> more
> > functions are seen on some USB devices.
> 
> Well, no matter how it "scales" it needs to be done in userspace, like
> usb_modeswitch does.  We made that decision a while ago, and it is
> working out very well.  I see no reason why you can't do it in userspace
> as well as that is the easiest place to control this type of thing.
> 
> I thought we had a long discussion about this topic a while ago and came
> to this very conclusion.  Or am I mistaken?
> 
>  
> We keep having the discussion over and over again.  But, you are correct: the 
> conclusion was that this all needs to live in userspace.

In the case of 3G modem x USB storage only, it is possible to handle it on 
userspace.

However, when there are more functions added, an they're not (completely) 
mutually exclusive,
then I don't see an easy way (if is there a way) for doing it at userspace.

Several devices offer more than one function at the same time, but some
resources are mutually exclusive. A TV stick with just one tuner, and
both analog and digital demods offer both analog and digital TV at the
same time. So, both analog and digital parts of the driver will offer
the device to userspace. However, unpredictable results will happen if
userspace tries to use both at the same time.

The Digital camera devices that offer PTP transfers and V4L support also
fall at the same type of trouble. Some of those devices just delete
all pictures from the memory, if streaming is started. So, receiving
an automatic Skype video call may delete all pictures you took.

Worse than that, currently, the PTP protocol is handled via libusb, while
streaming is done via V4L2 API.

The best technical approach, IMO, is to implement the PTP protocol in
kernelspace, and do some sort of inter-subsystem locking to prevent such
troubles.

Regards,
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: [Workshop-2011] Media Subsystem Workshop 2011

[Theodore Kilgore]

On Fri, 5 Aug 2011, Adam Baker wrote:

> On Thursday 04 August 2011, Theodore Kilgore wrote:
> > On Thu, 4 Aug 2011, Adam Baker wrote:
> > > On Thursday 04 August 2011, Theodore Kilgore wrote:
> > > > As far as I know, /dev/sdx signifies a device which is accessible by
> > > > something like the USB mass storage protocols, at the very least. So,
> > > > if that fits the camera, fine. But most of the cameras in question are
> > > > Class Proprietary. Thus, not in any way standard mass storage devices.
> > > > Then it is probably better not to call the new device by that name
> > > > unless that name really fits. Probably, it would be better to have
> > > > /dev/cam or /dev/stillcam, or something like that.
> > > 
> > > Correct and that is why this idea doesn't work - /dev/sdx needs to be a
> > > block device that can have a file system on it. These cameras don't have
> > > a traditional file system and there is a lot of code in gphoto to
> > > support all the different types of camera.
> > > 
> > > There does exist the possibility of a relatively simple fix - If libusb
> > > include a usb_reattach_kernel_driver_np call to go with the
> > > usb_detach_kernel_driver_np then once gphoto had finished with the device
> > > it could restore the kernel driver and webcam mode would work.
> > > Unfortunately the libusb devs don't want to support it in the 0.1
> > > version of libusb that everyone uses and the reattach function needs
> > > knowledge of libusb internals to work reliably.
> > > 
> > > I did come up with a hack that sort of worked but I never worked out how
> > > to clean it up to be acceptable to go upstream.
> > > 
> > > http://old.nabble.com/Re-attaching-USB-kernel-drivers-detached-by-libgpho
> > > to2- td22978838.html
> > > 
> > > http://libusb.6.n5.nabble.com/re-attaching-after-usb-detach-kernel-driver
> > > -np- td6068.html
> > > 
> > > Adam Baker
> > 
> > Adam,
> > 
> > (without looking at the details of your code) I agree that something like
> > fixing libusb to reattach a kernel driver would partially alleviate the
> > immediate problem of dual-mode cameras.
> > 
> > 1. It would provide immediate relief to those people who are afflicted
> > with the shortsightedness of some of the "user friendly" distros,
> > which have set up a "rule" that every camera supported by Gphoto will be
> > opened for download of photos as soon as it ls plugged in and the result
> > is that no dual-mode camera can be used in webcam mode -- unless the user
> > knows how to go and fix the mess.
> > 
> > 2. It would solve a lot of existing problems for lots of other people.
> > 
> > Therefore, I have favored this approach myself, sometimes in the past. The
> > problems, as I see it (partly after some education from people like Hans
> > de Goede), are the following:
> > 
> > 1. No locking, and no error-handling.
> > -- What if the user is downloading photos and gets a
> > videoconference telephone call? What if the user, just for fun, starts up
> > a webcam app, at the same time? Well, you might say, it can't start up
> > because the /dev/video is disabled so we are home free on that one. But
> > then
> > -- What if it is the other way around, and the webcam interface is
> > active, and the user (or some idiot automated software like what I
> > mentioned above!) decides to start up the stillcam apps? What then? Does
> > libusb just cut off the /dev/videoX device in the middle of things?
> > 
> 
> It does look as though there might be an issue here - the IOCTL that libusb 
> uses calls usb_driver_release_interface in drivers/core/usb/devio.c, the 
> definition of that function says "Callers must own the device lock" but as 
> far 
> as I can see it won't and a quick test running gphoto2 -L while streaming 
> video does indicate it is making a severe mess of things.

I haven't tried it myself. It is one of those things that all by myself 
I would never have thought of testing. But I am certainly not surprised at 
the result. 

> 
> > 2. This adaptation to libusb solves the specific problem of handling
> > dual-mode hardware for which one of the modes is handled by the kernel and
> > the other mode is handled in userspace, through libusb. The further
> > refinement of libusb addresses only this problem, not the general problem
> > of dual-mode or triple-mode hardware, in the case that all functionality
> > of the hardware is addressed through the kernel. Therefore, your solution
> > ends up being a partial cure to a general problem, not a general cure for
> > a general problem. Further, it is much easier to solve the locking issues
> > which arise if the basic access to the hardware is through the kernel for
> > all of its functionality.
> 
> If you can solve the locking problem between devices in the kernel then it 
> shouldn't matter if one of the kernel devices is the generic device that is 
> used to support libusb. 

Hmmm. Perhaps not. While we are on the topic, what exactly do you mean by 
"the generic devic

Re: RTL2831U driver updates

[Antti Palosaari]

Hello,
I have done some updates. MXL5005S based RTL2831U devices didn't worked
due to bug. That's main visible change. Secondly I added basic support
for RTL2832U to rtl28xx driver. And implemented I2C as I see it really
is, I think it is almost perfect now. It works fine my RTL2832U device
with stubbed demod and tuner drivers.

Next weeks I will hack most likely Anysee, but when I feel bored of
Anysee, I will switch back to rtl28xx driver :p

regards
Antti


On 07/09/2011 06:27 AM, Antti Palosaari wrote:
> Hello
> RTL2831U driver is now available here "realtek" branch:
> http://git.linuxtv.org/anttip/media_tree.git
> 
> From my side it is ready for merge.
> 
> RTL2830 DVB-T demod
> ===
> Driver is very limited, it basically just works, no any statistics.
> That's written totally from the scratch.
> 
> RTL28XXU DVB USB
> 
> I think it is also almost fully written from the scratch, but not sure
> since it have been so lng under the development. At least register
> definitions are from Realtek driver. Jan could you now find out
> copyrights, SOBs, etc. are correct? And how that should be merge...
> 
> I wonder Maxim can add support for RTL2832U to RTL28XXU DVB USB. It
> should not be much work. I tested it with my RTL2832U device and some
> minor changes were needed. Remote controller seems to be only which is
> totally different between RTL2831U and RTL2832U (and later).
> 
> 
> regards
> Antti
> 


-- 
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Workshop-2011] Media Subsystem Workshop 2011

[Adam Baker]

On Thursday 04 August 2011, Theodore Kilgore wrote:
> On Thu, 4 Aug 2011, Adam Baker wrote:
> > On Thursday 04 August 2011, Theodore Kilgore wrote:
> > > As far as I know, /dev/sdx signifies a device which is accessible by
> > > something like the USB mass storage protocols, at the very least. So,
> > > if that fits the camera, fine. But most of the cameras in question are
> > > Class Proprietary. Thus, not in any way standard mass storage devices.
> > > Then it is probably better not to call the new device by that name
> > > unless that name really fits. Probably, it would be better to have
> > > /dev/cam or /dev/stillcam, or something like that.
> > 
> > Correct and that is why this idea doesn't work - /dev/sdx needs to be a
> > block device that can have a file system on it. These cameras don't have
> > a traditional file system and there is a lot of code in gphoto to
> > support all the different types of camera.
> > 
> > There does exist the possibility of a relatively simple fix - If libusb
> > include a usb_reattach_kernel_driver_np call to go with the
> > usb_detach_kernel_driver_np then once gphoto had finished with the device
> > it could restore the kernel driver and webcam mode would work.
> > Unfortunately the libusb devs don't want to support it in the 0.1
> > version of libusb that everyone uses and the reattach function needs
> > knowledge of libusb internals to work reliably.
> > 
> > I did come up with a hack that sort of worked but I never worked out how
> > to clean it up to be acceptable to go upstream.
> > 
> > http://old.nabble.com/Re-attaching-USB-kernel-drivers-detached-by-libgpho
> > to2- td22978838.html
> > 
> > http://libusb.6.n5.nabble.com/re-attaching-after-usb-detach-kernel-driver
> > -np- td6068.html
> > 
> > Adam Baker
> 
> Adam,
> 
> (without looking at the details of your code) I agree that something like
> fixing libusb to reattach a kernel driver would partially alleviate the
> immediate problem of dual-mode cameras.
> 
> 1. It would provide immediate relief to those people who are afflicted
> with the shortsightedness of some of the "user friendly" distros,
> which have set up a "rule" that every camera supported by Gphoto will be
> opened for download of photos as soon as it ls plugged in and the result
> is that no dual-mode camera can be used in webcam mode -- unless the user
> knows how to go and fix the mess.
> 
> 2. It would solve a lot of existing problems for lots of other people.
> 
> Therefore, I have favored this approach myself, sometimes in the past. The
> problems, as I see it (partly after some education from people like Hans
> de Goede), are the following:
> 
> 1. No locking, and no error-handling.
>   -- What if the user is downloading photos and gets a
> videoconference telephone call? What if the user, just for fun, starts up
> a webcam app, at the same time? Well, you might say, it can't start up
> because the /dev/video is disabled so we are home free on that one. But
> then
>   -- What if it is the other way around, and the webcam interface is
> active, and the user (or some idiot automated software like what I
> mentioned above!) decides to start up the stillcam apps? What then? Does
> libusb just cut off the /dev/videoX device in the middle of things?
> 

It does look as though there might be an issue here - the IOCTL that libusb 
uses calls usb_driver_release_interface in drivers/core/usb/devio.c, the 
definition of that function says "Callers must own the device lock" but as far 
as I can see it won't and a quick test running gphoto2 -L while streaming 
video does indicate it is making a severe mess of things.

> 2. This adaptation to libusb solves the specific problem of handling
> dual-mode hardware for which one of the modes is handled by the kernel and
> the other mode is handled in userspace, through libusb. The further
> refinement of libusb addresses only this problem, not the general problem
> of dual-mode or triple-mode hardware, in the case that all functionality
> of the hardware is addressed through the kernel. Therefore, your solution
> ends up being a partial cure to a general problem, not a general cure for
> a general problem. Further, it is much easier to solve the locking issues
> which arise if the basic access to the hardware is through the kernel for
> all of its functionality.

If you can solve the locking problem between devices in the kernel then it 
shouldn't matter if one of the kernel devices is the generic device that is 
used to support libusb. 

> 
> Thus, while originally favoring your approach, my position is at this
> point more in the direction that something needs to be done about this at
> the level of the kernel. As I said, others have convinced me of this,
> mainly Hans, because at first I thought your way of doing it was plenty
> good enough.
> 
> Thanks for joining the debate, Adam, even though I just gave an opinion
> that you don't have the most optimal solution. I think that this problem
> has

Re: USB mini-summit at LinuxCon Vancouver

[Greg KH]

On Thu, Aug 04, 2011 at 07:21:47PM -0300, Mauro Carvalho Chehab wrote:
> I know that this problem were somewhat solved for 3G modems, with the usage
> of the userspace problem usb_modeswitch, and with some quirks for the USB
> storage driver, but I'm not sure if such tricks will scale forever, as more
> functions are seen on some USB devices.

Well, no matter how it "scales" it needs to be done in userspace, like
usb_modeswitch does.  We made that decision a while ago, and it is
working out very well.  I see no reason why you can't do it in userspace
as well as that is the easiest place to control this type of thing.

I thought we had a long discussion about this topic a while ago and came
to this very conclusion.  Or am I mistaken?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Media Subsystem Workshop 2011

[Theodore Kilgore]

On Thu, 4 Aug 2011, Mauro Carvalho Chehab wrote:

> Em 04-08-2011 18:16, Theodore Kilgore escreveu:
> 
>  This sounds to be a good theme for the Workshop, or even to KS/2011.
> >>>
> >>> Thanks. Do you recall when and where is KS/2011 going to take place?
> >>
> >> The media workshop happens together with the KS/2011. Sunday is an
> >> exclusive day for the workshops, Monday is an exclusive day for KS/2011,
> >> and Tuesday is a joint day for both KS and the KS workshops.
> > 
> > So, as I understand, these are all about to take place in Vancouver, 
> > sometime in the next two weeks? It really is the wrong time, but I really 
> > wish now that I were going. I would at the very minimum try to get the 
> > people together that I know of, who have wrestled with the issue.
> 
> Hmm... it seems that you didn't read the sites I've pointed on my original
> email, 

Not really, no. I had resigned myself to being unable to attend anything 
like this, so why torture myself with looking in the shop window at what I 
cannot buy?

> or that I was not clear enough. 

Without looking again, I expect that you were quite clear. 

> 
> The Media Subsystem Workshop and the Kernel Summit won't happen in Vancouver.
> What will happen there is the LinuxCon North-America, plus the USB 
> mini-summit. 
> I should be there, btw. I think I should add an additional topic there to
> discuss about multi-featured devices.

A very good idea. 

> 
> The KS/2011 and the Media Workshop will happen in Prague, on Oct 23-25,
> just before the LinuxCon Europe.

Hmmm. That is still not good because classes are in session. But it is not 
nearly so bad in the middle of a semester as it is at the beginning. It is 
even conceivable that I might be able to shake loose some money -- if I 
were either giving a presentation or would (for example) lead a panel 
discussion on this topic. I believe that I would find it easier to be a 
moderator or discussion "leader" than actually to present about a thing 
like this. Namely, I can see the issues but not always the solutions.

Probably, it is not good to apply to my university for money if I merely 
were going to attend; mere intent to attend would probably not get me 
funding for a mathematics conference, either. I also would need enough 
lead time to be able to get things through the bureaucratic system. There 
is some kind of very unreasonable deadline now in effect in the university 
about how soon one needs to apply for foreign travel.

So if you think my presence would have some value, I need something to get 
the application started, over here. Invitation, or something similar. If 
it is too much trouble or would interfere with already-existing plans, 
then never mind. I would hardly be upset if I don't go to something which 
I was not expecting to go to in the first place.

Theodore Kilgore
--
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: [Workshop-2011] Media Subsystem Workshop 2011

[Theodore Kilgore]

On Thu, 4 Aug 2011, Adam Baker wrote:

> On Thursday 04 August 2011, Mauro Carvalho Chehab wrote:
> > > That'd also be my understanding. There are already several standard ways 
> > > to access data on still cameras: mass-storage, PTP, MTP, why invent Yet 
> > > Another One? "Just" learn to share a device between several existing 
> > > drivers.
> > 
> > For those that can export data into some fs-like way, this may be the
> > better way. It seems that gvfs does something like that. I've no idea how
> > easy or difficult would be to write Kernel driver for it.
> 
> As I understand it gvfs uses libgphoto2 and fuse and it is the interface 
> libghoto2 that is the problem. 

This is correct. Except that the problem is not in libgphoto2 per se, but 
is at an even lower level. It could be said that the problem is in libusb, 
because libghoto2 uses libusb. So maybe the solution is to fix up libusb. 
Or, as I have come recently to think, maybe not. In any event, neither use 
nor avoidance of gvfs has much of anything to do with the problem at hand. 
But the problem exists with it or without it.


libgphoto2 contains lots of the same sort of 
> code to handle strange data formats from the camera as libv4l so I don't 
> think 
> we want to be moving that code back into the kernel.(The old out of kernel 
> driver for sq905 before Theodore and I rewrote it contained code to do Bayer 
> decoding and gamma correction that was copied from libgphoto2).

This is all very much true. Moreover, I do not think that anyone has the 
idea to put any of that kind of code back into the kernel.

But, just in case that anyone is thinking of possible "overlap" between 
what is done in libv4l and libgphoto2, someone should point out that 
things like Bayer demosaicing and gamma correction are not necessarily 
done the same way in the two libraries. Why is that? Well, it is true 
because one of the libraries supports streaming and the other one supports 
still cameras. Thus, the Bayer demosaicing functions in libv4l are 
optimized for speed, which will directly affect the frames per second 
rate. The Bayer demosaicing functions in libusb are intended to process 
image data from still cameras. For a still camera, frame rate is 
irrelevant and meaningless. Therefore the priority is, or ought to be, to 
get the best possible image out of the downloaded image data. 

Theodore Kilgore
--
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: USB mini-summit at LinuxCon Vancouver

[Mauro Carvalho Chehab]

Hi Sarah/Greg,

Em 09-06-2011 21:21, Sarah Sharp escreveu:
> I'm pleased to announce a USB mini-summit at LinuxCon Vancouver.
> 
> What: USB mini-summit
> When: Tuesday, August 16th, all day
> Where:At the conference venue, room TBD pending confirmation from
>   Angela Brown.
> 
> Proposed topics include USB virtualization, and improved bandwidth APIs
> between the USB core and drivers (especially webcam drivers).  See the
> detailed topic list below.  Anyone is also welcome to propose or show up
> with a USB related topic.  MUSB?  USB 3.0 gadget drivers?  USB-IP?
> 
> The USB mini-summit does overlap with the virtualization mini-summit by
> a day, but I'm hoping we can schedule talks so some of the
> virtualization folks can make it to the USB mini-summit.  The other
> option was on Friday during the conference which was not ideal.
> 
> Proposed topics:
> 
> Topic 1
> ---
> 
> The KVM folks suggested that it would be good to get USB and
> virtualization developers together to talk about how to virtualize the
> xHCI host controller.  The xHCI spec architect worked closely with
> VMWare to get some extra goodies in the spec to help virtualization, and
> I'd like to see the other virtualization developers take advantage of
> that.  I'd also like us to hash out any issues they have been finding in
> the USB core or xHCI driver during the virtualization effort.
> 
> 
> Topic 2
> ---
> 
> I'd also like to get the V4L and audio developers who work with USB
> devices together with the core USB folks to talk about bandwidth
> management under xHCI.
> 
> One of the issues is that since the xHCI hardware does bandwidth
> management, not the xHCI driver, a schedule that will take too much
> bandwidth will get rejected much sooner than any USB driver currently
> expects (during a call to usb_set_interface).  This poses issues, since
> most USB video drivers negotiate the video size and frame rate after
> they call usb_set_interface, so they don't know whether they can fall
> back to a less bandwidth-intensive setting.  Currently, they just submit
> URBs with less and less bandwidth until one interval setting gets
> accepted that won't work under xHCI.
> 
> A second issue is that that some drivers need less bandwidth than the
> device advertises, and the xHCI driver currently uses whatever periodic
> interval the device advertises in its descriptors.  This is not what the
> video/audio driver wants, especially in the case of buggy high speed
> devices that advertise the interval in frames, not microframes.  There
> needs to be some way for the drivers to communicate their bandwidth
> needs to the USB core.  We've known about this issue for a while, and I
> think it's time to get everyone in the same room and hash out an API.
> 
> (I will send out an API proposal later this month.)

While discussing the topics for the media workshop that will happen together
with this year's KS/2011, one issue related to the USB stack came on our
discussions: it is related to multi-function USB devices, as you can
see on this thread:
http://www.spinics.net/lists/linux-media/msg36195.html

We have several cases of multi-function devices at the media subsystem.
For example, most TV grabber devices provides Remote Controller, Video,
audio and MPEG streaming capabilities, either implementing the standard
USB API's, or the vendor class API's. There are even some devices that
support USB storage, 3G modem and Digital TV.

Some of those devices have some resources that are mutually exclusive.

For example, some Digital Cameras can provide either access to the stored
images, or can be used as webcams. Using them as webcams automatically
deletes all stored images from it. So, a properly implemented driver
should be returning -EBUSY (or -EPERM?) if someone tries to stream for
such devices if is there any pictures stored on it. Symmetrically,
accessing the stored pictures there should return -EBUSY if the device
is streaming.

Currently, the data access for Digital Cameras is implemented via libusb,
libgphoto and gvfs, while the streaming interface is implemented via
a gspca Kernel driver.

I know that this problem were somewhat solved for 3G modems, with the usage
of the userspace problem usb_modeswitch, and with some quirks for the USB
storage driver, but I'm not sure if such tricks will scale forever, as more
functions are seen on some USB devices.

So, if we have some time, maybe we could start some discussions about that
during the USB mini-summit.

It should be noticed that the media subsystem has currently similar problems 
on devices that provide both analog and digital TV, as some resources, like 
the tuner can't be used simultaneously by the two API's. This happens even
with PCI devices. So, maybe, in the end, we'll be writing some kernel library
for resource locking, but it would be good if we can have preliminary
discussions there, and let the final discussions to happen during KS/2011. 

What do you think?

Re: Media Subsystem Workshop 2011

[Mauro Carvalho Chehab]

Em 04-08-2011 18:16, Theodore Kilgore escreveu:

 This sounds to be a good theme for the Workshop, or even to KS/2011.
>>>
>>> Thanks. Do you recall when and where is KS/2011 going to take place?
>>
>> The media workshop happens together with the KS/2011. Sunday is an
>> exclusive day for the workshops, Monday is an exclusive day for KS/2011,
>> and Tuesday is a joint day for both KS and the KS workshops.
> 
> So, as I understand, these are all about to take place in Vancouver, 
> sometime in the next two weeks? It really is the wrong time, but I really 
> wish now that I were going. I would at the very minimum try to get the 
> people together that I know of, who have wrestled with the issue.

Hmm... it seems that you didn't read the sites I've pointed on my original
email, or that I was not clear enough. 

The Media Subsystem Workshop and the Kernel Summit won't happen in Vancouver.
What will happen there is the LinuxCon North-America, plus the USB mini-summit. 
I should be there, btw. I think I should add an additional topic there to
discuss about multi-featured devices.

The KS/2011 and the Media Workshop will happen in Prague, on Oct 23-25,
just before the LinuxCon Europe.

Regards,
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: [Workshop-2011] Media Subsystem Workshop 2011

[Theodore Kilgore]

On Thu, 4 Aug 2011, Adam Baker wrote:

> On Thursday 04 August 2011, Theodore Kilgore wrote:
> > As far as I know, /dev/sdx signifies a device which is accessible by 
> > something like the USB mass storage protocols, at the very least. So, if 
> > that fits the camera, fine. But most of the cameras in question are Class 
> > Proprietary. Thus, not in any way standard mass storage devices. Then it 
> > is probably better not to call the new device by that name unless that 
> > name really fits. Probably, it would be better to have /dev/cam or 
> > /dev/stillcam, or something like that.
> 
> Correct and that is why this idea doesn't work - /dev/sdx needs to be a block 
> device that can have a file system on it. These cameras don't have a 
> traditional file system and there is a lot of code in gphoto to support all 
> the different types of camera.
> 
> There does exist the possibility of a relatively simple fix - If libusb 
> include a usb_reattach_kernel_driver_np call to go with the 
> usb_detach_kernel_driver_np then once gphoto had finished with the device it 
> could restore the kernel driver and webcam mode would work. Unfortunately the 
> libusb devs don't want to support it in the 0.1 version of libusb that 
> everyone uses and the reattach function needs knowledge of libusb internals 
> to 
> work reliably. 
> 
> I did come up with a hack that sort of worked but I never worked out how to 
> clean it up to be acceptable to go upstream.
> 
> http://old.nabble.com/Re-attaching-USB-kernel-drivers-detached-by-libgphoto2-
> td22978838.html
> 
> http://libusb.6.n5.nabble.com/re-attaching-after-usb-detach-kernel-driver-np-
> td6068.html
> 
> Adam Baker
> 

Adam, 

(without looking at the details of your code) I agree that something like 
fixing libusb to reattach a kernel driver would partially alleviate the 
immediate problem of dual-mode cameras.

1. It would provide immediate relief to those people who are afflicted 
with the shortsightedness of some of the "user friendly" distros, 
which have set up a "rule" that every camera supported by Gphoto will be 
opened for download of photos as soon as it ls plugged in and the result 
is that no dual-mode camera can be used in webcam mode -- unless the user 
knows how to go and fix the mess.

2. It would solve a lot of existing problems for lots of other people.

Therefore, I have favored this approach myself, sometimes in the past. The 
problems, as I see it (partly after some education from people like Hans 
de Goede), are the following: 

1. No locking, and no error-handling.
-- What if the user is downloading photos and gets a 
videoconference telephone call? What if the user, just for fun, starts up 
a webcam app, at the same time? Well, you might say, it can't start up 
because the /dev/video is disabled so we are home free on that one. But 
then
-- What if it is the other way around, and the webcam interface is 
active, and the user (or some idiot automated software like what I 
mentioned above!) decides to start up the stillcam apps? What then? Does 
libusb just cut off the /dev/videoX device in the middle of things?

2. This adaptation to libusb solves the specific problem of handling 
dual-mode hardware for which one of the modes is handled by the kernel and 
the other mode is handled in userspace, through libusb. The further 
refinement of libusb addresses only this problem, not the general problem 
of dual-mode or triple-mode hardware, in the case that all functionality 
of the hardware is addressed through the kernel. Therefore, your solution 
ends up being a partial cure to a general problem, not a general cure for 
a general problem. Further, it is much easier to solve the locking issues 
which arise if the basic access to the hardware is through the kernel for 
all of its functionality.

Thus, while originally favoring your approach, my position is at this 
point more in the direction that something needs to be done about this at 
the level of the kernel. As I said, others have convinced me of this, 
mainly Hans, because at first I thought your way of doing it was plenty 
good enough.

Thanks for joining the debate, Adam, even though I just gave an opinion 
that you don't have the most optimal solution. I think that this problem 
has gone on long enough, and we all need to get together and fix it. 
Seriously.

Cheers,

Theodore Kilgore
--
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: [Workshop-2011] Media Subsystem Workshop 2011

[Mauro Carvalho Chehab]

Em 04-08-2011 18:38, Adam Baker escreveu:
> On Thursday 04 August 2011, Mauro Carvalho Chehab wrote:
>>> That'd also be my understanding. There are already several standard ways 
>>> to access data on still cameras: mass-storage, PTP, MTP, why invent Yet 
>>> Another One? "Just" learn to share a device between several existing 
>>> drivers.
>>
>> For those that can export data into some fs-like way, this may be the
>> better way. It seems that gvfs does something like that. I've no idea how
>> easy or difficult would be to write Kernel driver for it.
> 
> As I understand it gvfs uses libgphoto2 and fuse and it is the interface 
> libghoto2 that is the problem. libgphoto2 contains lots of the same sort of 
> code to handle strange data formats from the camera as libv4l so I don't 
> think 
> we want to be moving that code back into the kernel.(The old out of kernel 
> driver for sq905 before Theodore and I rewrote it contained code to do Bayer 
> decoding and gamma correction that was copied from libgphoto2).

I don't think we should move the entire libgphoto2 to kernel. For sure, format
conversions don't belong to Kernelspace. We just need to move the file handling
(e. g. PTP/MTP) to a kernel driver. Something might be needed for libgphoto2
to know what is the format of the images inside the filesystem, but this could
be just mapped as a file extension.
> 
> Regards
> 
> Adam Baker

--
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: [Workshop-2011] Media Subsystem Workshop 2011

[Adam Baker]

On Thursday 04 August 2011, Mauro Carvalho Chehab wrote:
> > That'd also be my understanding. There are already several standard ways 
> > to access data on still cameras: mass-storage, PTP, MTP, why invent Yet 
> > Another One? "Just" learn to share a device between several existing 
> > drivers.
> 
> For those that can export data into some fs-like way, this may be the
> better way. It seems that gvfs does something like that. I've no idea how
> easy or difficult would be to write Kernel driver for it.

As I understand it gvfs uses libgphoto2 and fuse and it is the interface 
libghoto2 that is the problem. libgphoto2 contains lots of the same sort of 
code to handle strange data formats from the camera as libv4l so I don't think 
we want to be moving that code back into the kernel.(The old out of kernel 
driver for sq905 before Theodore and I rewrote it contained code to do Bayer 
decoding and gamma correction that was copied from libgphoto2).

Regards

Adam Baker
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Media Subsystem Workshop 2011

[Theodore Kilgore]

On Thu, 4 Aug 2011, Mauro Carvalho Chehab wrote:

> Em 04-08-2011 15:37, Theodore Kilgore escreveu:
> >>> Yes, that kind of thing is an obvious problem. Actually, though, it may 
> >>> be 
> >>> that this had just better not happen. For some of the hardware that I 
> >>> know 
> >>> of, it could be a real problem no matter what approach would be taken. 
> >>> For 
> >>> example, certain specific dual-mode cameras will delete all data stored 
> >>> on 
> >>> the camera if the camera is fired up in webcam mode. To drop Gphoto 
> >>> suddenly in order to do the videoconf call would, on such cameras, result 
> >>> in the automatic deletion of all photos on the camera even if those 
> >>> photos 
> >>> had not yet been downloaded. Presumably, one would not want to do that. 
> >>
> > 
> > Some of the sq905 cameras in particular will do this. It depends upon the 
> > firmware version. Indeed, for those which do, the same USB command which 
> > starts streaming is exploited in the Gphoto driver for deletion of all 
> > photos stored on the camera. For the other firmware versions, there is in 
> > fact no way to delete all the photos, except to push buttons on the camera 
> > case. This is by the way a typical example of the very rudimentary, 
> > minimalist interface of some of these cheap cameras.
> > 
> >> So, in other words, the Kernel driver should return -EBUSY if on such
> >> cameras, if there are photos stored on them, and someone tries to stream.
> > 
> > Probably, this should work the other way around, too. If not, then there 
> > is the question of closing the streaming in some kind of orderly fashion.
> 
> Yes.
> 
>  IMO, the right solution is to work on a proper snapshot mode, in 
>  kernelspace,
>  and moving the drivers that have already a kernelspace out of Gphoto.
> >>>
> >>> Well, the problem with that is, a still camera and a webcam are entirely 
> >>> different beasts. Still photos stored in the memory of an external 
> >>> device, 
> >>> waiting to be downloaded, are not snapshots. Thus, access to those still 
> >>> photos is not access to snapshots. Things are not that simple.
> >>
> >> Yes, stored photos require a different API, as Hans pointed. 
> > 
> > Yes again. His observations seem to me to be saying exactly the same thing 
> > that I did.
> > 
> >> I think that some cameras
> >> just export them as a USB storage. For those, we may eventually need some 
> >> sort of locking
> >> between the USB storage and V4L.
> > 
> > I can imagine that this could be the case. Also, to be entirely logical, 
> > one might imagine that a PTP camera could be fired up in streaming mode, 
> > too. I myself do not know of any cameras which are both USB storage and 
> > streaming cameras. In fact, as I understand the USB classes, such a thing 
> > would be in principle forbidden.
> 
> It is possible to use a single USB ID, and having two (or more) interfaces
> there, each belonging to a different USB class. 

True. However, unfortunate exceptions are found in the set of sq905 
cameras and sq905c cameras, which have only Interface 0 (and, of course, 
use only Bulk Transport for all data regardless of its nature). 


Anyway, while abstracting
> the proper solution, it is safer to consider it as a possible scenario.
> 
> > However, the practical consequence could 
> > be that sooner or later someone is going to do just that and that deviant 
> > hardware is going to sell like hotcakes and we are going to get pestered. 
> 
> Yes.
> 
> >>
>  That's said, there is a proposed topic for snapshot buffer management. 
>  Maybe
>  it may cover the remaining needs for taking high quality pictures in 
>  Kernel.
> >>>
> >>> Again, when downloading photo images which are _stored_ on the camera one 
> >>> is not "taking high quality pictures." Different functionality is 
> >>> involved. This may involve, for example, a different Altsetting for the 
> >>> USB device and may also require the use of Bulk transport instead of 
> >>> Isochronous transport. 
> >>
> >> Ok. The gspca driver supports it already. All we need to do is to 
> >> implement a
> >> proper API for retrieving still photos.
> > 
> > Yes, I believe that Hans has some idea to do something like this:
> > 
> > 1. kernel module creates a stillcam device as well as a /dev/video, for 
> > those cameras for which it is appropriate
> > 
> > 2. libgphoto2 driver is modified so as to access /dev/camera through the 
> > kernel, instead of talking to the camera through libusb.
> > 
> > Hans has written some USB Mass Storage digital picture frame drivers for 
> > Gphoto, which do something similar. 
> 
> The above strategy seems OK for me.
> 
> >>
>  The hole idea is to allocate additional buffers for snapshots, imagining 
>  that
>  the camera may be streaming in low quality/low resolution, and, once 
>  snapshot
>  is requested, it will take one high quality/high resolution picture.
> >>>
> >>> The ability to "take" a pho

Re: [Workshop-2011] Media Subsystem Workshop 2011

[Adam Baker]

On Thursday 04 August 2011, Theodore Kilgore wrote:
> As far as I know, /dev/sdx signifies a device which is accessible by 
> something like the USB mass storage protocols, at the very least. So, if 
> that fits the camera, fine. But most of the cameras in question are Class 
> Proprietary. Thus, not in any way standard mass storage devices. Then it 
> is probably better not to call the new device by that name unless that 
> name really fits. Probably, it would be better to have /dev/cam or 
> /dev/stillcam, or something like that.

Correct and that is why this idea doesn't work - /dev/sdx needs to be a block 
device that can have a file system on it. These cameras don't have a 
traditional file system and there is a lot of code in gphoto to support all 
the different types of camera.

There does exist the possibility of a relatively simple fix - If libusb 
include a usb_reattach_kernel_driver_np call to go with the 
usb_detach_kernel_driver_np then once gphoto had finished with the device it 
could restore the kernel driver and webcam mode would work. Unfortunately the 
libusb devs don't want to support it in the 0.1 version of libusb that 
everyone uses and the reattach function needs knowledge of libusb internals to 
work reliably. 

I did come up with a hack that sort of worked but I never worked out how to 
clean it up to be acceptable to go upstream.

http://old.nabble.com/Re-attaching-USB-kernel-drivers-detached-by-libgphoto2-
td22978838.html

http://libusb.6.n5.nabble.com/re-attaching-after-usb-detach-kernel-driver-np-
td6068.html

Adam Baker
--
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: [Workshop-2011] Media Subsystem Workshop 2011

[Mauro Carvalho Chehab]

Em 04-08-2011 16:02, Guennadi Liakhovetski escreveu:
> (re-adding all from the original CC-list, please, don't drop anyone)
> 
> On Thu, 4 Aug 2011, Jean-Francois Moine wrote:
> 
>> On Thu, 04 Aug 2011 09:40:18 -0300
>> Mauro Carvalho Chehab  wrote:
>>
 What we need for this is a simple API (new v4l ioctl's I guess) for the
 stillcam mode of these dual mode cameras (stillcam + webcam). So that the
 webcam drivers can grow code to also allow access to the stored pictures,
 which were taken in standalone (iow not connected to usb) stillcam mode.

 This API does not need to be terribly complex. AFAIK all of the currently
 supported dual cam cameras don't have filenames only picture numbers,
 so the API could consist of a simple, get highest picture nr, is picture
 X present (some slots may contain deleted pictures), get picture X,
 delete picture X, delete all API.  
>>>
>>> That sounds to work. I would map it on a way close to the controls API
>>> (or like the DVB FE_[GET|SET]_PROPERTY API), as this would make easier to 
>>> expand
>>> it in the future, if we start to see webcams with file names or other things
>>> like that.
>>
>> I did not follow all the thread, but I was wondering about an other
>> solution: what about offering both USB mass storage and webcam accesses?

Because not all devices export an USB mas storage.

>> When a dual-mode webcam is plugged in, the driver creates two devices,
>> the video device /dev/videox and the volume /dev/sdx. When the webcam is
>> opened, the volume cannot be mounted. When the volume is mounted, the
>> webcam cannot be opened. There is no need for a specific API. As Mauro
>> said:
>>
>>> For those, we may eventually need some sort of locking between
>>> the USB storage and V4L.
>>
>> That's all. By where am I wrong?
> 
> That'd also be my understanding. There are already several standard ways 
> to access data on still cameras: mass-storage, PTP, MTP, why invent Yet 
> Another One? "Just" learn to share a device between several existing 
> drivers.

For those that can export data into some fs-like way, this may be the better
way. It seems that gvfs does something like that. I've no idea how easy
or difficult would be to write Kernel driver for it.
> 
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Media Subsystem Workshop 2011

[Mauro Carvalho Chehab]

Em 04-08-2011 15:37, Theodore Kilgore escreveu:
>>> Yes, that kind of thing is an obvious problem. Actually, though, it may be 
>>> that this had just better not happen. For some of the hardware that I know 
>>> of, it could be a real problem no matter what approach would be taken. For 
>>> example, certain specific dual-mode cameras will delete all data stored on 
>>> the camera if the camera is fired up in webcam mode. To drop Gphoto 
>>> suddenly in order to do the videoconf call would, on such cameras, result 
>>> in the automatic deletion of all photos on the camera even if those photos 
>>> had not yet been downloaded. Presumably, one would not want to do that. 
>>
> 
> Some of the sq905 cameras in particular will do this. It depends upon the 
> firmware version. Indeed, for those which do, the same USB command which 
> starts streaming is exploited in the Gphoto driver for deletion of all 
> photos stored on the camera. For the other firmware versions, there is in 
> fact no way to delete all the photos, except to push buttons on the camera 
> case. This is by the way a typical example of the very rudimentary, 
> minimalist interface of some of these cheap cameras.
> 
>> So, in other words, the Kernel driver should return -EBUSY if on such
>> cameras, if there are photos stored on them, and someone tries to stream.
> 
> Probably, this should work the other way around, too. If not, then there 
> is the question of closing the streaming in some kind of orderly fashion.

Yes.

 IMO, the right solution is to work on a proper snapshot mode, in 
 kernelspace,
 and moving the drivers that have already a kernelspace out of Gphoto.
>>>
>>> Well, the problem with that is, a still camera and a webcam are entirely 
>>> different beasts. Still photos stored in the memory of an external device, 
>>> waiting to be downloaded, are not snapshots. Thus, access to those still 
>>> photos is not access to snapshots. Things are not that simple.
>>
>> Yes, stored photos require a different API, as Hans pointed. 
> 
> Yes again. His observations seem to me to be saying exactly the same thing 
> that I did.
> 
>> I think that some cameras
>> just export them as a USB storage. For those, we may eventually need some 
>> sort of locking
>> between the USB storage and V4L.
> 
> I can imagine that this could be the case. Also, to be entirely logical, 
> one might imagine that a PTP camera could be fired up in streaming mode, 
> too. I myself do not know of any cameras which are both USB storage and 
> streaming cameras. In fact, as I understand the USB classes, such a thing 
> would be in principle forbidden.

It is possible to use a single USB ID, and having two (or more) interfaces
there, each belonging to a different USB class. Anyway, while abstracting
the proper solution, it is safer to consider it as a possible scenario.

> However, the practical consequence could 
> be that sooner or later someone is going to do just that and that deviant 
> hardware is going to sell like hotcakes and we are going to get pestered. 

Yes.

>>
 That's said, there is a proposed topic for snapshot buffer management. 
 Maybe
 it may cover the remaining needs for taking high quality pictures in 
 Kernel.
>>>
>>> Again, when downloading photo images which are _stored_ on the camera one 
>>> is not "taking high quality pictures." Different functionality is 
>>> involved. This may involve, for example, a different Altsetting for the 
>>> USB device and may also require the use of Bulk transport instead of 
>>> Isochronous transport. 
>>
>> Ok. The gspca driver supports it already. All we need to do is to implement a
>> proper API for retrieving still photos.
> 
> Yes, I believe that Hans has some idea to do something like this:
> 
> 1. kernel module creates a stillcam device as well as a /dev/video, for 
> those cameras for which it is appropriate
> 
> 2. libgphoto2 driver is modified so as to access /dev/camera through the 
> kernel, instead of talking to the camera through libusb.
> 
> Hans has written some USB Mass Storage digital picture frame drivers for 
> Gphoto, which do something similar. 

The above strategy seems OK for me.

>>
 The hole idea is to allocate additional buffers for snapshots, imagining 
 that
 the camera may be streaming in low quality/low resolution, and, once 
 snapshot
 is requested, it will take one high quality/high resolution picture.
>>>
>>> The ability to "take" a photo is present on some still cameras and not on 
>>> others. "Some still cameras" includes some dual-mode cameras. For 
>>> dual-mode cameras which can be requested to "take" a photo while running 
>>> in webcam mode, the ability to do so is, generally speaking, present in 
>>> the kernel driver.
>>>
>>> To present the problem more simply, a webcam is, essentially, a device of 
>>> USB class Video (even if the device uses proprietary protocols, this is at 
>>> least conceptually true). This is true becau

Re: [Workshop-2011] Media Subsystem Workshop 2011

[Guennadi Liakhovetski]

(re-adding all from the original CC-list, please, don't drop anyone)

On Thu, 4 Aug 2011, Jean-Francois Moine wrote:

> On Thu, 04 Aug 2011 09:40:18 -0300
> Mauro Carvalho Chehab  wrote:
> 
> > > What we need for this is a simple API (new v4l ioctl's I guess) for the
> > > stillcam mode of these dual mode cameras (stillcam + webcam). So that the
> > > webcam drivers can grow code to also allow access to the stored pictures,
> > > which were taken in standalone (iow not connected to usb) stillcam mode.
> > > 
> > > This API does not need to be terribly complex. AFAIK all of the currently
> > > supported dual cam cameras don't have filenames only picture numbers,
> > > so the API could consist of a simple, get highest picture nr, is picture
> > > X present (some slots may contain deleted pictures), get picture X,
> > > delete picture X, delete all API.  
> > 
> > That sounds to work. I would map it on a way close to the controls API
> > (or like the DVB FE_[GET|SET]_PROPERTY API), as this would make easier to 
> > expand
> > it in the future, if we start to see webcams with file names or other things
> > like that.
> 
> I did not follow all the thread, but I was wondering about an other
> solution: what about offering both USB mass storage and webcam accesses?
> 
> When a dual-mode webcam is plugged in, the driver creates two devices,
> the video device /dev/videox and the volume /dev/sdx. When the webcam is
> opened, the volume cannot be mounted. When the volume is mounted, the
> webcam cannot be opened. There is no need for a specific API. As Mauro
> said:
> 
> > For those, we may eventually need some sort of locking between
> > the USB storage and V4L.
> 
> That's all. By where am I wrong?

That'd also be my understanding. There are already several standard ways 
to access data on still cameras: mass-storage, PTP, MTP, why invent Yet 
Another One? "Just" learn to share a device between several existing 
drivers.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Workshop-2011] Media Subsystem Workshop 2011

[Theodore Kilgore]

On Thu, 4 Aug 2011, Jean-Francois Moine wrote:

> On Thu, 04 Aug 2011 09:40:18 -0300
> Mauro Carvalho Chehab  wrote:
> 
> > > What we need for this is a simple API (new v4l ioctl's I guess) for the
> > > stillcam mode of these dual mode cameras (stillcam + webcam). So that the
> > > webcam drivers can grow code to also allow access to the stored pictures,
> > > which were taken in standalone (iow not connected to usb) stillcam mode.
> > > 
> > > This API does not need to be terribly complex. AFAIK all of the currently
> > > supported dual cam cameras don't have filenames only picture numbers,
> > > so the API could consist of a simple, get highest picture nr, is picture
> > > X present (some slots may contain deleted pictures), get picture X,
> > > delete picture X, delete all API.  
> > 
> > That sounds to work. I would map it on a way close to the controls API
> > (or like the DVB FE_[GET|SET]_PROPERTY API), as this would make easier to 
> > expand
> > it in the future, if we start to see webcams with file names or other things
> > like that.
> 
> I did not follow all the thread, but I was wondering about an other
> solution: what about offering both USB mass storage and webcam accesses?
> 
> When a dual-mode webcam is plugged in, the driver creates two devices,
> the video device /dev/videox and the volume /dev/sdx. When the webcam is
> opened, the volume cannot be mounted. When the volume is mounted, the
> webcam cannot be opened. There is no need for a specific API. As Mauro
> said:
> 
> > For those, we may eventually need some sort of locking between
> > the USB storage and V4L.
> 
> That's all. By where am I wrong?

Jean-Francois,

This idea seems to me basically on track. There is only one small problem 
with it, in the details:

As far as I know, /dev/sdx signifies a device which is accessible by 
something like the USB mass storage protocols, at the very least. So, if 
that fits the camera, fine. But most of the cameras in question are Class 
Proprietary. Thus, not in any way standard mass storage devices. Then it 
is probably better not to call the new device by that name unless that 
name really fits. Probably, it would be better to have /dev/cam or 
/dev/stillcam, or something like that.

Theodore Kilgore
--
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: [Workshop-2011] Media Subsystem Workshop 2011

[Theodore Kilgore]

On Thu, 4 Aug 2011, Mauro Carvalho Chehab wrote:

> Em 04-08-2011 08:39, Hans de Goede escreveu:
> > Hi,
> > 
> > On 08/03/2011 10:36 PM, Mauro Carvalho Chehab wrote:
> >> Em 03-08-2011 16:53, Theodore Kilgore escreveu:
> > 
> > 
> > 
> >>> Mauro,
> >>>
> >>> Not saying that you need to change the program for this session to deal
> >>> with this topic, but an old and vexing problem is dual-mode devices. It is
> >>> an issue which needs some kind of unified approach, and, in my opinion,
> >>> consensus about policy and methodology.
> >>>
> >>> As a very good example if this problem, several of the cameras that I have
> >>> supported as GSPCA devices in their webcam modality are also still cameras
> >>> and are supported, as still cameras, in Gphoto. This can cause a collision
> >>> between driver software in userspace which functions with libusb, and on
> >>> the other hand with a kernel driver which tries to grab the device.
> >>>
> >>> Recent attempts to deal with this problem involve the incorporation of
> >>> code in libusb which disables a kernel module that has already grabbed the
> >>> device, allowing the userspace driver to function. This has made life a
> >>> little bit easier for some people, but not for everybody. For, the device
> >>> needs to be re-plugged in order to re-activate the kernel support. But
> >>> some of the "user-friencly" desktop setups used by some distros will
> >>> automatically start up a dual-mode camera with a gphoto-based program,
> >>> thereby making it impossible for the camera to be used as a webcam unless
> >>> the user goes for a crash course in how to disable the "feature" which has
> >>> been so thoughtfully (thoughtlessly?) provided.
> >>>
> >>> As the problem is not confined to cameras but also affects some other
> >>> devices, such as DSL modems which have a partition on them and are thus
> >>> seen as Mass Storage devices, perhaps it is time to try to find a
> >>> systematic approach to problems like this.
> >>>
> >>> There are of course several possible approaches.
> >>>
> >>> 1. A kernel module should handle everything related to connecting up the
> >>> hardware. In that case, the existing userspace driver has to be modified
> >>> to use the kernel module instead of libusb. Those who support this option
> >>> would say that it gets everything under the control of the kernel, where
> >>> it belongs. OTOG, the possible result is to create a minor mess in
> >>> projects like Gphoto.
> >>>
> >>> 2. The kernel module should be abolished, and all of its functionality
> >>> moved to userspace. This would of course involve difficulties
> >>> approximately equivalent to item 1. An advantage, in the eyes of some,
> >>> would be to cut down on the
> >>> yet-another-driver-for-yet-another-piece-of-peculiar-hardware syndrome
> >>> which obviously contributes to an in principle unlimited increase in the
> >>> size of the kernel codebase. A disadvantage would be that it would create
> >>> some disruption in webcam support.
> >>>
> >>> 3. A further modification to libusb reactivates the kernel module
> >>> automatically, as soon as the userspace app which wanted to access the
> >>> device through a libusb-based driver library is closed. This seems
> >>> attractive, but it has certain deficiencies as well. One of them is that
> >>> it can not necessarily provide a smooth and informative user experience,
> >>> since circumstances can occur in which something appears to go wrong, but
> >>> the user gets no clear message saying what the problem is. In other words,
> >>> it is a patchwork solution which only slightly refines the current
> >>> patchwork solution in libusb, which is in itself only a slight improvement
> >>> on the original, unaddressed problem.
> >>>
> >>> 4. ???
> >>>
> >>> Several people are interested in this problem, but not much progress has
> >>> been made at this time. I think that the topic ought to be put somehow on
> >>> the front burner so that lots of people will try to think of the best way
> >>> to handle it. Many eyes, and all that.
> >>>
> >>> Not saying change your schedule, as I said. Have a nice conference. I wish
> >>> I could attend. But I do hope by this message to raise some general
> >>> concern about this problem.
> >>
> >> That's an interesting issue.
> >>
> >> A solution like (3) is a little bit out of scope, as it is a pure userspace
> >> (or a mixed userspace USB stack) solution.
> >>
> >> Technically speaking, letting the same device being handled by either an
> >> userspace or a kernelspace driver doesn't seem smart to me, due to:
> >> - Duplicated efforts to maintain both drivers;
> >> - It is hard to sync a kernel driver with an userspace driver,
> >> as you've pointed.
> >>
> >> So, we're between (1) or (2).
> >>
> >> Moving the solution entirely to userspace will have, additionally, the
> >> problem of having two applications trying to access the same hardware
> >> using two different userspace instances (for example, an

Re: Media Subsystem Workshop 2011

[Theodore Kilgore]

(Added Hans to the reply. I already knew that he shares my concerns about 
this issue, and I am glad he has joined the discussion.)

On Thu, 4 Aug 2011, Mauro Carvalho Chehab wrote:

> Em 03-08-2011 20:20, Theodore Kilgore escreveu:
> > 
> > 
> > On Wed, 3 Aug 2011, Mauro Carvalho Chehab wrote:
> > 
> >> Em 03-08-2011 16:53, Theodore Kilgore escreveu:
> >>>
> >>>
> >>> On Wed, 3 Aug 2011, Mauro Carvalho Chehab wrote:
> >>>
>  As already announced, we're continuing the planning for this year's 
>  media subsystem workshop.
> 
>  To avoid overriding the main ML with workshop-specifics, a new ML
>  was created:
>   workshop-2...@linuxtv.org
> 
>  I'll also be updating the event page at:
>   http://www.linuxtv.org/events.php
> 
>  Over the one-year period, we had 242 developers contributing to the
>  subsystem. Thank you all for that! Unfortunately, the space there is
>  limited, and we can't affort to have all developers there. 
> 
>  Due to that some criteria needed to be applied to create a short list
>  of people that were invited today to participate. 
> 
>  The main criteria were to select the developers that did significant 
>  contributions for the media subsystem over the last 1 year period, 
>  measured in terms of number of commits and changed lines to the kernel
>  drivers/media tree.
> 
>  As the used criteria were the number of kernel patches, userspace-only 
>  developers weren't included on the invitations. It would be great to 
>  have there open source application developers as well, in order to allow 
>  us to tune what's needed from applications point of view. 
> 
>  So, if you're leading the development of some V4L and/or DVB open-source 
>  application and wants to be there, or you think you can give good 
>  contributions for helping to improve the subsystem, please feel free 
>  to send us an email.
> 
>  With regards to the themes, we're received, up to now, the following 
>  proposals:
> 
>  -+--
>  THEME| Proposed-by:
>  -+--
>  Buffer management: snapshot mode | Guennadi
>  Rotation in webcams in tablets while streaming is active | Hans de Goede
>  V4L2 Spec ? ambiguities fix  | Hans Verkuil
>  V4L2 compliance test results | Hans Verkuil
>  Media Controller presentation (probably for Wed, 25) | Laurent 
>  Pinchart
>  Workshop summary presentation on Wed, 25 | Mauro 
>  Carvalho Chehab
>  -+--
> 
>  >From my side, I also have the following proposals:
> 
>  1) DVB API consistency - what to do with the audio and video DVB API's 
>  that conflict with V4L2 and (somewhat) with ALSA?
> 
>  2) Multi FE support - How should we handle a frontend with multiple 
>  delivery systems like DRX-K frontend?
> 
>  3) videobuf2 - migration plans for legacy drivers
> 
>  4) NEC IR decoding - how should we handle 32, 24, and 16 bit protocol
>  variations?
> 
>  Even if you won't be there, please feel free to propose themes for 
>  discussion, in order to help us to improve even more the subsystem.
> 
>  Thank you!
>  Mauro
> >>>
> >>> Mauro,
> >>>
> >>> Not saying that you need to change the program for this session to deal 
> >>> with this topic, but an old and vexing problem is dual-mode devices. It 
> >>> is 
> >>> an issue which needs some kind of unified approach, and, in my opinion, 
> >>> consensus about policy and methodology.
> >>>
> >>> As a very good example if this problem, several of the cameras that I 
> >>> have 
> >>> supported as GSPCA devices in their webcam modality are also still 
> >>> cameras 
> >>> and are supported, as still cameras, in Gphoto. This can cause a 
> >>> collision 
> >>> between driver software in userspace which functions with libusb, and on 
> >>> the other hand with a kernel driver which tries to grab the device.
> >>>
> >>> Recent attempts to deal with this problem involve the incorporation of 
> >>> code in libusb which disables a kernel module that has already grabbed 
> >>> the 
> >>> device, allowing the userspace driver to function. This has made life a 
> >>> little bit easier for some people, but not for everybody. For, the device 
> >>> needs to be re-plugged in order to re-activate the kernel support. But 
> >>> some of the "user-friencly" desktop setups used by some distros will 
> >>> automatically start up a dual-mode camera with a gphoto-based program, 
> >>> thereby making it impossible for the camera to be used a

[cron job] v4l-dvb daily build: ERRORS

[Hans Verkuil]

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 Aug  4 19:00:33 CEST 2011
git hash:46540f7ac646ada7f22912ea7ea9b761ff5c4718
gcc version:  i686-linux-gcc (GCC) 4.5.1
host hardware:x86_64
host os:  2.6.32.5

linux-git-armv5: WARNINGS
linux-git-armv5-davinci: WARNINGS
linux-git-armv5-ixp: WARNINGS
linux-git-armv5-omap2: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: OK
linux-git-mips: WARNINGS
linux-git-powerpc64: WARNINGS
linux-git-x86_64: WARNINGS
linux-2.6.31.12-i686: ERRORS
linux-2.6.32.6-i686: ERRORS
linux-2.6.33-i686: ERRORS
linux-2.6.34-i686: ERRORS
linux-2.6.35.3-i686: ERRORS
linux-2.6.36-i686: ERRORS
linux-2.6.37-i686: ERRORS
linux-2.6.38.2-i686: ERRORS
linux-2.6.39.1-i686: ERRORS
linux-2.6.31.12-x86_64: ERRORS
linux-2.6.32.6-x86_64: ERRORS
linux-2.6.33-x86_64: ERRORS
linux-2.6.34-x86_64: ERRORS
linux-2.6.35.3-x86_64: ERRORS
linux-2.6.36-x86_64: ERRORS
linux-2.6.37-x86_64: ERRORS
linux-2.6.38.2-x86_64: ERRORS
linux-2.6.39.1-x86_64: ERRORS
spec-git: ERRORS
sparse: ERRORS

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: [Workshop-2011] Media Subsystem Workshop 2011

[Jean-Francois Moine]

On Thu, 04 Aug 2011 09:40:18 -0300
Mauro Carvalho Chehab  wrote:

> > What we need for this is a simple API (new v4l ioctl's I guess) for the
> > stillcam mode of these dual mode cameras (stillcam + webcam). So that the
> > webcam drivers can grow code to also allow access to the stored pictures,
> > which were taken in standalone (iow not connected to usb) stillcam mode.
> > 
> > This API does not need to be terribly complex. AFAIK all of the currently
> > supported dual cam cameras don't have filenames only picture numbers,
> > so the API could consist of a simple, get highest picture nr, is picture
> > X present (some slots may contain deleted pictures), get picture X,
> > delete picture X, delete all API.  
> 
> That sounds to work. I would map it on a way close to the controls API
> (or like the DVB FE_[GET|SET]_PROPERTY API), as this would make easier to 
> expand
> it in the future, if we start to see webcams with file names or other things
> like that.

I did not follow all the thread, but I was wondering about an other
solution: what about offering both USB mass storage and webcam accesses?

When a dual-mode webcam is plugged in, the driver creates two devices,
the video device /dev/videox and the volume /dev/sdx. When the webcam is
opened, the volume cannot be mounted. When the volume is mounted, the
webcam cannot be opened. There is no need for a specific API. As Mauro
said:

> For those, we may eventually need some sort of locking between
> the USB storage and V4L.

That's all. By where am I wrong?

-- 
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: [Linaro-mm-sig] Buffer sharing proof-of-concept

[Clark, Rob]

On Thu, Aug 4, 2011 at 7:34 AM, Daniel Vetter  wrote:
> On Thu, Aug 4, 2011 at 13:14, Clark, Rob  wrote:
>> hmm, there would be a dmabuf->private ptr in struct dmabuf.  Normally
>> that should be for private data of the buffer allocator, but I guess
>> it could be (ab)used for under the hood communication between drivers
>> a platform specific way.  It does seem a bit hacky, but at least it
>> does not need to be exposed to userspace.
>
> An idea that just crossed my mind: I think we should seperate two
> kinds of meta-data about a shared piece of data (dmabuf):
> - logical metadata about it's contents, like strides, number of
> dimensions, pixel format/vbo layout, ... Imo that stuff doesn't belong
> into the buffer sharing simply because it's an a) awful mess and b)
> gem doesn't know it. To recap: only userspace knows this stuff and has
> to make sense of the data in the buffer by either setting up correct
> gpu command streams or telling kms what format this thing it needs to
> scan out has.


for sure, I think we've ruled out putting this sort of stuff in
'struct dmabuf'.. (notwithstanding any data stuffed away in a 'void *
priv' on some platform or another)

> - metadata about the physical layout: tiling layout, memory bank
> interleaving, page size for the iommu/contiguous buffer. As far as I
> can tell (i.e. please correct) for embedded systems this just depends
> on the (in)saneness of to iommu/bus/memory controller sitting between
> the ic block and it's data. So it would be great if we could
> completely hide this from drivers (and userspace) an shovel it into
> the dma subsystem (as private data). Unfortunately at least on Intel
> tiling needs to be known by the iommu code, the core gem kernel driver
> code and the userspace drivers. Otoh using tiled buffers for sharing
> is maybe a bit ambitious for the first cut. So maybe we can just
> ignore tiling which largely just leaves handling iommus restrictions
> (or their complete lack) which looks doable.

btw, on intel (or desktop platforms in general), could another device
(say a USB webcam) DMA directly to a tiled buffer via the GART... ie.
assuming you had some way to pre-fault some pages into the GART before
the DMA happened.

I was sort of expecting 'struct dmabuf' to basically just be a
scatterlist and some fxn ptrs, nothing about TILING.. not sure if we
need an fxn ptr to ask the buffer allocator to generate some
pages/addresses that some other DMA engine could write to (so you
could do something like pre-faulting the buffer into some sort of
GART) and again release the pages/addresses when DMA completes.

BR,
-R

>> (Or maybe a better option is just 'rm -rf omx' ;-))
>
> Yeah ;-)
> -Daniel
> --
> Daniel Vetter
> daniel.vet...@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
--
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] omap3isp: queue: fail QBUF if buffer is too small

[Michael Jones]

Add buffer length to sanity checks for QBUF.

Signed-off-by: Michael Jones 
---
 drivers/media/video/omap3isp/ispqueue.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/omap3isp/ispqueue.c 
b/drivers/media/video/omap3isp/ispqueue.c
index 9c31714..4f6876f 100644
--- a/drivers/media/video/omap3isp/ispqueue.c
+++ b/drivers/media/video/omap3isp/ispqueue.c
@@ -867,6 +867,9 @@ int omap3isp_video_queue_qbuf(struct isp_video_queue *queue,
if (buf->state != ISP_BUF_STATE_IDLE)
goto done;
 
+   if (vbuf->length < buf->vbuf.length)
+   goto done;
+
if (vbuf->memory == V4L2_MEMORY_USERPTR &&
vbuf->m.userptr != buf->vbuf.m.userptr) {
isp_video_buffer_cleanup(buf);
-- 
1.7.6


MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/4] DVB: dvb_frontend: update locking in dvb_frontend_{add,get_event}

[Andreas Oberritter]

- dvb_frontend_add_event:
  - fepriv->parameters_out isn't protected by events->mtx, so
move the call to fe->ops.get_frontend out of the locked area.
  - move the assignment of e->status into the locked area.

- dvb_frontend_get_event:
  - use direct assignment instead of memcpy.

- dvb_frontend_add_event and dvb_frontend_get_event:
  - use mutex_lock instead of mutex_lock_interruptible, because
all code paths protected by this mutex won't block.

Signed-off-by: Andreas Oberritter 
---
 drivers/media/dvb/dvb-core/dvb_frontend.c |   24 +++-
 1 files changed, 7 insertions(+), 17 deletions(-)

diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 4102311..d02c32e 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -149,30 +149,25 @@ static void dvb_frontend_add_event(struct dvb_frontend 
*fe, fe_status_t status)
 
dprintk ("%s\n", __func__);
 
-   if (mutex_lock_interruptible (&events->mtx))
-   return;
+   if ((status & FE_HAS_LOCK) && fe->ops.get_frontend)
+   fe->ops.get_frontend(fe, &fepriv->parameters_out);
 
-   wp = (events->eventw + 1) % MAX_EVENT;
+   mutex_lock(&events->mtx);
 
+   wp = (events->eventw + 1) % MAX_EVENT;
if (wp == events->eventr) {
events->overflow = 1;
events->eventr = (events->eventr + 1) % MAX_EVENT;
}
 
e = &events->events[events->eventw];
-
-   if (status & FE_HAS_LOCK)
-   if (fe->ops.get_frontend)
-   fe->ops.get_frontend(fe, &fepriv->parameters_out);
-
+   e->status = status;
e->parameters = fepriv->parameters_out;
 
events->eventw = wp;
 
mutex_unlock(&events->mtx);
 
-   e->status = status;
-
wake_up_interruptible (&events->wait_queue);
 }
 
@@ -207,14 +202,9 @@ static int dvb_frontend_get_event(struct dvb_frontend *fe,
return ret;
}
 
-   if (mutex_lock_interruptible (&events->mtx))
-   return -ERESTARTSYS;
-
-   memcpy (event, &events->events[events->eventr],
-   sizeof(struct dvb_frontend_event));
-
+   mutex_lock(&events->mtx);
+   *event = events->events[events->eventr];
events->eventr = (events->eventr + 1) % MAX_EVENT;
-
mutex_unlock(&events->mtx);
 
return 0;
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/4] DVB: dvb_frontend: clear stale events on FE_SET_FRONTEND

[Andreas Oberritter]

- Old events aren't very useful, so clear them before adding
  the first event after an attempt to tune.

Signed-off-by: Andreas Oberritter 
---
 drivers/media/dvb/dvb-core/dvb_frontend.c |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 45ea843..4102311 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -220,6 +220,16 @@ static int dvb_frontend_get_event(struct dvb_frontend *fe,
return 0;
 }
 
+static void dvb_frontend_clear_events(struct dvb_frontend *fe)
+{
+   struct dvb_frontend_private *fepriv = fe->frontend_priv;
+   struct dvb_fe_events *events = &fepriv->events;
+
+   mutex_lock(&events->mtx);
+   events->eventr = events->eventw;
+   mutex_unlock(&events->mtx);
+}
+
 static void dvb_frontend_init(struct dvb_frontend *fe)
 {
dprintk ("DVB: initialising adapter %i frontend %i (%s)...\n",
@@ -1891,6 +1901,7 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
/* Request the search algorithm to search */
fepriv->algo_status |= DVBFE_ALGO_SEARCH_AGAIN;
 
+   dvb_frontend_clear_events(fe);
dvb_frontend_add_event(fe, 0);
dvb_frontend_wakeup(fe);
fepriv->status = 0;
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/4] DVB: dvb_frontend: fix stale parameters on initial frontend event

[Andreas Oberritter]

- FE_SET_FRONTEND triggers a frontend event, which uses stale data.
  Modify it to use the data given by the user.

- Fixes a regression caused by a5959dbea37973a2440eeba39fba32c79d862ec2.

Signed-off-by: Andreas Oberritter 
---
 drivers/media/dvb/dvb-core/dvb_frontend.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index efe9c30..23d79d0 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -1827,6 +1827,13 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
dtv_property_cache_sync(fe, c, &fepriv->parameters_in);
}
 
+   /*
+* Initialize output parameters to match the values given by
+* the user. FE_SET_FRONTEND triggers an initial frontend event
+* with status = 0, which copies output parameters to userspace.
+*/
+   fepriv->parameters_out = fepriv->parameters_in;
+
memset(&fetunesettings, 0, sizeof(struct 
dvb_frontend_tune_settings));
memcpy(&fetunesettings.parameters, parg,
   sizeof (struct dvb_frontend_parameters));
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/4] DVB: dvb_frontend: avoid possible race condition on first event

[Andreas Oberritter]

- Make sure the initial frontend event on FE_SET_FRONTEND gets
  enqueued before the frontend thread wakes up.

Signed-off-by: Andreas Oberritter 
---
 drivers/media/dvb/dvb-core/dvb_frontend.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 23d79d0..45ea843 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -1891,8 +1891,8 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
/* Request the search algorithm to search */
fepriv->algo_status |= DVBFE_ALGO_SEARCH_AGAIN;
 
-   dvb_frontend_wakeup(fe);
dvb_frontend_add_event(fe, 0);
+   dvb_frontend_wakeup(fe);
fepriv->status = 0;
err = 0;
break;
-- 
1.7.2.5

--
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: Betr: [linux-dvb] dib0700 hangs when usb receiver is unplugged while watching TV

[Florian Mickler]

To the best of my knowledge, you did. I cc'd Patrick and Olivier who are 
involved
with dib ... 


On Sun, 10 Jul 2011 09:22:05 +0200
cedric.dew...@telfort.nl wrote:

> 
> >-- Oorspronkelijk bericht --
> >Date: Fri, 24 Jun 2011 11:01:37 +0200
> >From: cedric.dew...@telfort.nl
> >To: linux-...@linuxtv.org
> >Subject: [linux-dvb] dib0700 hangs when usb receiver is unplugged while
> > watching TV
> >Reply-To: linux-media@vger.kernel.org
> >
> >
> >Hi All,
> >
> >I have the PCTV nanostick solo. This works perfectly, but when I pull out
> >the stick while i'm watching TV, the driver crashes. When I replug the stick,
> >there's no reaction in dmesg.
> >
> >To reproduce:
> >1)plugin the stick
> >1a)scan channels with scan, see also 
> >https://wiki.archlinux.org/index.php/Digitenne#Configure_Sasc-ng
> >2)use tzap, cat and mplayer to watch TV
> >3)unplug the stick
> >4)watch the fireworks in /var/log/everything.log (dmesg)
> 
> Hi All,
> 
> Did I post the above message in the correct mailing list?
> 
> Best regards,
> Cedric


--
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: mx2_camera driver on mx27ipcam: dma_alloc_coherent size failed

[Uwe Kleine-König]

Hello Jan,

On Thu, Aug 04, 2011 at 03:11:11PM +0200, Jan Pohanka wrote:
> Dear Uwe,
> could you please give me some advice once more? It seems I'm not
> able to make mx2_camera working by myself.
> I have tried dma memory allocation in my board file in several ways,
> but nothing seems to work. I use Video capture example for v4l2 for
> testing.
> 
> regards
> Jan
> 
> mx27ipcam_camera_power: 1
> mx27ipcam_camera_reset
> mx2-camera mx2-camera.0: Camera driver attached to camera 0
> mx2-camera mx2-camera.0: dma_alloc_coherent size 614400 failed
> mmap error 12, Cannot allocate memory
> mx2-camera mx2-camera.0: Camera driver detached from camera 0
> mx27ipcam_camera_power: 0
Cannot say offhand. I'd instrument dma_alloc_from_coherent to check
where it fails.
 
The patch looks OK from a first glance.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mx2_camera driver on mx27ipcam: dma_alloc_coherent size failed

[Jan Pohanka]

Dear Uwe,
could you please give me some advice once more? It seems I'm not able to  
make mx2_camera working by myself.
I have tried dma memory allocation in my board file in several ways, but  
nothing seems to work. I use Video capture example for v4l2 for testing.


regards
Jan

mx27ipcam_camera_power: 1
mx27ipcam_camera_reset
mx2-camera mx2-camera.0: Camera driver attached to camera 0
mx2-camera mx2-camera.0: dma_alloc_coherent size 614400 failed
mmap error 12, Cannot allocate memory
mx2-camera mx2-camera.0: Camera driver detached from camera 0
mx27ipcam_camera_power: 0

...
static phys_addr_t mx2_camera_base __initdata;
#define MX2_CAMERA_BUF_SIZE SZ_4M

static int __init mx27ipcam_init_camera(void)
{
int dma, ret = -ENOMEM;
struct platform_device *pdev = 
imx27_alloc_mx2_camera(&mx27ipcam_camera);


if (IS_ERR(pdev))
return PTR_ERR(pdev);

dma = dma_declare_coherent_memory(&pdev->dev,
mx2_camera_base, mx2_camera_base,
MX2_CAMERA_BUF_SIZE,
DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE);
if (!(dma & DMA_MEMORY_MAP))
goto err;

ret = platform_device_add(pdev);
if (ret)
err:
platform_device_put(pdev);

return ret;
}

static void __init mx27ipcam_init(void)
{
imx27_soc_init();

mxc_gpio_setup_multiple_pins(mx27ipcam_pins, ARRAY_SIZE(mx27ipcam_pins),
"mx27ipcam");

platform_add_devices(platform_devices, ARRAY_SIZE(platform_devices));
/*imx27_add_mxc_nand(&mx27ipcam_nand_board_info);*/

imx27_add_imx_uart0(NULL);
imx27_add_fec(NULL);
imx27_add_imx2_wdt(NULL);
imx27_add_imx_i2c(0, &mx27ipcam_i2c1_data);

mx27ipcam_init_camera();
}

static void __init mx27ipcam_reserve(void)
{
/* reserve 4 MiB for mx3-camera */
mx2_camera_base = memblock_alloc(MX2_CAMERA_BUF_SIZE,
MX2_CAMERA_BUF_SIZE);
memblock_free(mx2_camera_base, MX2_CAMERA_BUF_SIZE);
memblock_remove(mx2_camera_base, MX2_CAMERA_BUF_SIZE);
}

MACHINE_START(IMX27IPCAM, "Freescale IMX27IPCAM")
/* maintainer: Freescale Semiconductor, Inc. */
.boot_params = MX27_PHYS_OFFSET + 0x100,
.reserve = mx27ipcam_reserve,
.map_io = mx27_map_io,
.init_early = imx27_init_early,
.init_irq = mx27_init_irq,
.timer = &mx27ipcam_timer,
.init_machine = mx27ipcam_init,
MACHINE_END



struct platform_device *__init imx_add_mx2_camera(
const struct imx_mx2_camera_data *data,
const struct mx2_camera_platform_data *pdata)
{
struct resource res[] = {
{
.start = data->iobasecsi,
.end = data->iobasecsi + data->iosizecsi - 1,
.flags = IORESOURCE_MEM,
}, {
.start = data->irqcsi,
.end = data->irqcsi,
.flags = IORESOURCE_IRQ,
}, {
.start = data->iobaseemmaprp,
.end = data->iobaseemmaprp + data->iosizeemmaprp - 1,
.flags = IORESOURCE_MEM,
}, {
.start = data->irqemmaprp,
.end = data->irqemmaprp,
.flags = IORESOURCE_IRQ,
},
};
return imx_add_platform_device_dmamask("mx2-camera", 0,
res, data->iobaseemmaprp ? 4 : 2,
pdata, sizeof(*pdata), DMA_BIT_MASK(32));
}

struct platform_device *__init imx_alloc_mx2_camera(
const struct imx_mx2_camera_data *data,
const struct mx2_camera_platform_data *pdata)
{
struct resource res[] = {
{
.start = data->iobasecsi,
.end = data->iobasecsi + 
data->iosizecsi - 1,
.flags = IORESOURCE_MEM,
}, {
.start = data->irqcsi,
.end = data->irqcsi,
.flags = IORESOURCE_IRQ,
}, {
.start = data->iobaseemmaprp,
.end = data->iobaseemmaprp + 
data->iosizeemmaprp - 1,
.flags = IORESOURCE_MEM,
}, {
.start = data->irqemmaprp,
.end = data->irqemmaprp,
.flags = IORESOURCE_IRQ,
},
};
int ret = -ENOMEM;
struct platform_device *pdev;

pdev 

Re: Problems with Hauppauge Nova-TD (dib0070/dib7000PC)

[Florian Mickler]

On Mon, 11 Jul 2011 12:23:28 +0100
David Waring  wrote:

> I'm currently using 3 of these USB sticks on a PC with the videolan.org
> dvblast program to multicast the UK Freeview DVB-T muxes on our local
> network. I'm also using a PCTV nanostick 290e to multicast the DVB-T2
> mux too.
> 
> I'm having a problem with the Nova-TD sticks (52009) using recent builds
> from the media_build git repository (to get the 290e drivers) on Debian
> squeeze using 2.6.38-bpo.2-686. The problem is that only one half of
> each Nova-TD stick will tune and give data. Which half seems to be
> random and changes with each reboot. Occasionally I'll get a whole stick
> working or one of the sticks will not work at all. If I try to use a
> non-working half of a stick it will knock out the working half until I
> stop using trying to use the non-working half. So I'm seeing
> interference of one logical dvb adapter from another that are both on
> the same physical hardware.
> 
> Also after a few days the sticks stop working completely and need to be
> powered down before they work again, but this may be a different issue.
> 
> I'm getting a few "dib0700: tx buffer length is larger than 4. Not
> supported." in dmesg during first tune. Maybe coincidence, but I've
> noticed that on the last reboot 4 tuners (out of the 6 total Nova-TD
> tuners) are not working and I have 4 of the above message in dmesg, so
> there could be a link.
> 
> I've tried turning on the debugging for both the dvb_usb_dib0700 and
> dvb_usb modules but there was no indication of the problem.
> 
> Any suggestions for what I could try next to find the cause and fix this?
> 
> David

Hi,
maybe the fixes Patrick posted[1] fix your issue ?

http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/36393

Regards,
Flo


--
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: DiBxxxx: fixes for 3.1/3.0

[David Waring]

On 03/08/11 16:33, Patrick Boettcher wrote:
> Hi Mauro,
> 
> Would you please pull from
> 
> git://linuxtv.org/pb/media_tree.git for_v3.0
> 
> for the following to changesets:
> 
> [media] dib0700: protect the dib0700 buffer access
> [media] DiBcom: protect the I2C bufer access
> 
These patches seem to fix the issue I was having with Hauppauge Nova-TD
USB sticks where only half the stick would work (random half each boot).
These may also fix tuning issues others were having with DiBcom based
cards/sticks. I've also noticed I'm no longer getting the "dib0700: tx
buffer length is larger than 4. Not
supported." errors in dmesg either.

I did have a bit of trouble compiling the patches, I had to modify the
dprintk(...) calls in the dib0700 patch to
dprintk(dvb_usb_dib0700_debug, 0x01, ...), although these should
probably be deb_info(...) calls.

Regards,
David

-- 
David Waring, Software Engineer, BBC Research & Development
5th Floor, Dock House, MediaCity:UK, Salford, M50 2LH, United Kingdom
Tel. +44(0)30 3040 9517
--
This e-mail, and any attachment, is confidential. If you have received
it in error, please delete it from your system, do not use or disclose
the information in any way, and notify me immediately. The contents of
this message may contain personal views which are not the views of the
BBC, unless specifically stated.
--
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: [Workshop-2011] Media Subsystem Workshop 2011

[Mauro Carvalho Chehab]

Em 04-08-2011 08:39, Hans de Goede escreveu:
> Hi,
> 
> On 08/03/2011 10:36 PM, Mauro Carvalho Chehab wrote:
>> Em 03-08-2011 16:53, Theodore Kilgore escreveu:
> 
> 
> 
>>> Mauro,
>>>
>>> Not saying that you need to change the program for this session to deal
>>> with this topic, but an old and vexing problem is dual-mode devices. It is
>>> an issue which needs some kind of unified approach, and, in my opinion,
>>> consensus about policy and methodology.
>>>
>>> As a very good example if this problem, several of the cameras that I have
>>> supported as GSPCA devices in their webcam modality are also still cameras
>>> and are supported, as still cameras, in Gphoto. This can cause a collision
>>> between driver software in userspace which functions with libusb, and on
>>> the other hand with a kernel driver which tries to grab the device.
>>>
>>> Recent attempts to deal with this problem involve the incorporation of
>>> code in libusb which disables a kernel module that has already grabbed the
>>> device, allowing the userspace driver to function. This has made life a
>>> little bit easier for some people, but not for everybody. For, the device
>>> needs to be re-plugged in order to re-activate the kernel support. But
>>> some of the "user-friencly" desktop setups used by some distros will
>>> automatically start up a dual-mode camera with a gphoto-based program,
>>> thereby making it impossible for the camera to be used as a webcam unless
>>> the user goes for a crash course in how to disable the "feature" which has
>>> been so thoughtfully (thoughtlessly?) provided.
>>>
>>> As the problem is not confined to cameras but also affects some other
>>> devices, such as DSL modems which have a partition on them and are thus
>>> seen as Mass Storage devices, perhaps it is time to try to find a
>>> systematic approach to problems like this.
>>>
>>> There are of course several possible approaches.
>>>
>>> 1. A kernel module should handle everything related to connecting up the
>>> hardware. In that case, the existing userspace driver has to be modified
>>> to use the kernel module instead of libusb. Those who support this option
>>> would say that it gets everything under the control of the kernel, where
>>> it belongs. OTOG, the possible result is to create a minor mess in
>>> projects like Gphoto.
>>>
>>> 2. The kernel module should be abolished, and all of its functionality
>>> moved to userspace. This would of course involve difficulties
>>> approximately equivalent to item 1. An advantage, in the eyes of some,
>>> would be to cut down on the
>>> yet-another-driver-for-yet-another-piece-of-peculiar-hardware syndrome
>>> which obviously contributes to an in principle unlimited increase in the
>>> size of the kernel codebase. A disadvantage would be that it would create
>>> some disruption in webcam support.
>>>
>>> 3. A further modification to libusb reactivates the kernel module
>>> automatically, as soon as the userspace app which wanted to access the
>>> device through a libusb-based driver library is closed. This seems
>>> attractive, but it has certain deficiencies as well. One of them is that
>>> it can not necessarily provide a smooth and informative user experience,
>>> since circumstances can occur in which something appears to go wrong, but
>>> the user gets no clear message saying what the problem is. In other words,
>>> it is a patchwork solution which only slightly refines the current
>>> patchwork solution in libusb, which is in itself only a slight improvement
>>> on the original, unaddressed problem.
>>>
>>> 4. ???
>>>
>>> Several people are interested in this problem, but not much progress has
>>> been made at this time. I think that the topic ought to be put somehow on
>>> the front burner so that lots of people will try to think of the best way
>>> to handle it. Many eyes, and all that.
>>>
>>> Not saying change your schedule, as I said. Have a nice conference. I wish
>>> I could attend. But I do hope by this message to raise some general
>>> concern about this problem.
>>
>> That's an interesting issue.
>>
>> A solution like (3) is a little bit out of scope, as it is a pure userspace
>> (or a mixed userspace USB stack) solution.
>>
>> Technically speaking, letting the same device being handled by either an
>> userspace or a kernelspace driver doesn't seem smart to me, due to:
>> - Duplicated efforts to maintain both drivers;
>> - It is hard to sync a kernel driver with an userspace driver,
>> as you've pointed.
>>
>> So, we're between (1) or (2).
>>
>> Moving the solution entirely to userspace will have, additionally, the
>> problem of having two applications trying to access the same hardware
>> using two different userspace instances (for example, an incoming videoconf
>> call while Gphoto is opened, assuming that such videoconf call would also
>> have an userspace driver).
>>
>> IMO, the right solution is to work on a proper snapshot mode, in kernelspace,
>> and moving the drivers t

Re: Media Subsystem Workshop 2011

[Mauro Carvalho Chehab]

Em 03-08-2011 20:20, Theodore Kilgore escreveu:
> 
> 
> On Wed, 3 Aug 2011, Mauro Carvalho Chehab wrote:
> 
>> Em 03-08-2011 16:53, Theodore Kilgore escreveu:
>>>
>>>
>>> On Wed, 3 Aug 2011, Mauro Carvalho Chehab wrote:
>>>
 As already announced, we're continuing the planning for this year's 
 media subsystem workshop.

 To avoid overriding the main ML with workshop-specifics, a new ML
 was created:
workshop-2...@linuxtv.org

 I'll also be updating the event page at:
http://www.linuxtv.org/events.php

 Over the one-year period, we had 242 developers contributing to the
 subsystem. Thank you all for that! Unfortunately, the space there is
 limited, and we can't affort to have all developers there. 

 Due to that some criteria needed to be applied to create a short list
 of people that were invited today to participate. 

 The main criteria were to select the developers that did significant 
 contributions for the media subsystem over the last 1 year period, 
 measured in terms of number of commits and changed lines to the kernel
 drivers/media tree.

 As the used criteria were the number of kernel patches, userspace-only 
 developers weren't included on the invitations. It would be great to 
 have there open source application developers as well, in order to allow 
 us to tune what's needed from applications point of view. 

 So, if you're leading the development of some V4L and/or DVB open-source 
 application and wants to be there, or you think you can give good 
 contributions for helping to improve the subsystem, please feel free 
 to send us an email.

 With regards to the themes, we're received, up to now, the following 
 proposals:

 -+--
 THEME| Proposed-by:
 -+--
 Buffer management: snapshot mode | Guennadi
 Rotation in webcams in tablets while streaming is active | Hans de Goede
 V4L2 Spec ? ambiguities fix  | Hans Verkuil
 V4L2 compliance test results | Hans Verkuil
 Media Controller presentation (probably for Wed, 25) | Laurent Pinchart
 Workshop summary presentation on Wed, 25 | Mauro Carvalho 
 Chehab
 -+--

 >From my side, I also have the following proposals:

 1) DVB API consistency - what to do with the audio and video DVB API's 
 that conflict with V4L2 and (somewhat) with ALSA?

 2) Multi FE support - How should we handle a frontend with multiple 
 delivery systems like DRX-K frontend?

 3) videobuf2 - migration plans for legacy drivers

 4) NEC IR decoding - how should we handle 32, 24, and 16 bit protocol
 variations?

 Even if you won't be there, please feel free to propose themes for 
 discussion, in order to help us to improve even more the subsystem.

 Thank you!
 Mauro
>>>
>>> Mauro,
>>>
>>> Not saying that you need to change the program for this session to deal 
>>> with this topic, but an old and vexing problem is dual-mode devices. It is 
>>> an issue which needs some kind of unified approach, and, in my opinion, 
>>> consensus about policy and methodology.
>>>
>>> As a very good example if this problem, several of the cameras that I have 
>>> supported as GSPCA devices in their webcam modality are also still cameras 
>>> and are supported, as still cameras, in Gphoto. This can cause a collision 
>>> between driver software in userspace which functions with libusb, and on 
>>> the other hand with a kernel driver which tries to grab the device.
>>>
>>> Recent attempts to deal with this problem involve the incorporation of 
>>> code in libusb which disables a kernel module that has already grabbed the 
>>> device, allowing the userspace driver to function. This has made life a 
>>> little bit easier for some people, but not for everybody. For, the device 
>>> needs to be re-plugged in order to re-activate the kernel support. But 
>>> some of the "user-friencly" desktop setups used by some distros will 
>>> automatically start up a dual-mode camera with a gphoto-based program, 
>>> thereby making it impossible for the camera to be used as a webcam unless 
>>> the user goes for a crash course in how to disable the "feature" which has 
>>> been so thoughtfully (thoughtlessly?) provided. 
>>>
>>> As the problem is not confined to cameras but also affects some other 
>>> devices, such as DSL modems which have a partition on them and are thus 
>>> seen as Mass Storage devices, perhaps it is time to try to find a 
>>> systematic approach to problems li

Re: [Linaro-mm-sig] Buffer sharing proof-of-concept

[Daniel Vetter]

On Thu, Aug 4, 2011 at 13:14, Clark, Rob  wrote:
> hmm, there would be a dmabuf->private ptr in struct dmabuf.  Normally
> that should be for private data of the buffer allocator, but I guess
> it could be (ab)used for under the hood communication between drivers
> a platform specific way.  It does seem a bit hacky, but at least it
> does not need to be exposed to userspace.

An idea that just crossed my mind: I think we should seperate two
kinds of meta-data about a shared piece of data (dmabuf):
- logical metadata about it's contents, like strides, number of
dimensions, pixel format/vbo layout, ... Imo that stuff doesn't belong
into the buffer sharing simply because it's an a) awful mess and b)
gem doesn't know it. To recap: only userspace knows this stuff and has
to make sense of the data in the buffer by either setting up correct
gpu command streams or telling kms what format this thing it needs to
scan out has.
- metadata about the physical layout: tiling layout, memory bank
interleaving, page size for the iommu/contiguous buffer. As far as I
can tell (i.e. please correct) for embedded systems this just depends
on the (in)saneness of to iommu/bus/memory controller sitting between
the ic block and it's data. So it would be great if we could
completely hide this from drivers (and userspace) an shovel it into
the dma subsystem (as private data). Unfortunately at least on Intel
tiling needs to be known by the iommu code, the core gem kernel driver
code and the userspace drivers. Otoh using tiled buffers for sharing
is maybe a bit ambitious for the first cut. So maybe we can just
ignore tiling which largely just leaves handling iommus restrictions
(or their complete lack) which looks doable.

> (Or maybe a better option is just 'rm -rf omx' ;-))

Yeah ;-)
-Daniel
-- 
Daniel Vetter
daniel.vet...@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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: [Workshop-2011] Media Subsystem Workshop 2011

[Hans de Goede]

Hi,

On 08/03/2011 10:36 PM, Mauro Carvalho Chehab wrote:

Em 03-08-2011 16:53, Theodore Kilgore escreveu:





Mauro,

Not saying that you need to change the program for this session to deal
with this topic, but an old and vexing problem is dual-mode devices. It is
an issue which needs some kind of unified approach, and, in my opinion,
consensus about policy and methodology.

As a very good example if this problem, several of the cameras that I have
supported as GSPCA devices in their webcam modality are also still cameras
and are supported, as still cameras, in Gphoto. This can cause a collision
between driver software in userspace which functions with libusb, and on
the other hand with a kernel driver which tries to grab the device.

Recent attempts to deal with this problem involve the incorporation of
code in libusb which disables a kernel module that has already grabbed the
device, allowing the userspace driver to function. This has made life a
little bit easier for some people, but not for everybody. For, the device
needs to be re-plugged in order to re-activate the kernel support. But
some of the "user-friencly" desktop setups used by some distros will
automatically start up a dual-mode camera with a gphoto-based program,
thereby making it impossible for the camera to be used as a webcam unless
the user goes for a crash course in how to disable the "feature" which has
been so thoughtfully (thoughtlessly?) provided.

As the problem is not confined to cameras but also affects some other
devices, such as DSL modems which have a partition on them and are thus
seen as Mass Storage devices, perhaps it is time to try to find a
systematic approach to problems like this.

There are of course several possible approaches.

1. A kernel module should handle everything related to connecting up the
hardware. In that case, the existing userspace driver has to be modified
to use the kernel module instead of libusb. Those who support this option
would say that it gets everything under the control of the kernel, where
it belongs. OTOG, the possible result is to create a minor mess in
projects like Gphoto.

2. The kernel module should be abolished, and all of its functionality
moved to userspace. This would of course involve difficulties
approximately equivalent to item 1. An advantage, in the eyes of some,
would be to cut down on the
yet-another-driver-for-yet-another-piece-of-peculiar-hardware syndrome
which obviously contributes to an in principle unlimited increase in the
size of the kernel codebase. A disadvantage would be that it would create
some disruption in webcam support.

3. A further modification to libusb reactivates the kernel module
automatically, as soon as the userspace app which wanted to access the
device through a libusb-based driver library is closed. This seems
attractive, but it has certain deficiencies as well. One of them is that
it can not necessarily provide a smooth and informative user experience,
since circumstances can occur in which something appears to go wrong, but
the user gets no clear message saying what the problem is. In other words,
it is a patchwork solution which only slightly refines the current
patchwork solution in libusb, which is in itself only a slight improvement
on the original, unaddressed problem.

4. ???

Several people are interested in this problem, but not much progress has
been made at this time. I think that the topic ought to be put somehow on
the front burner so that lots of people will try to think of the best way
to handle it. Many eyes, and all that.

Not saying change your schedule, as I said. Have a nice conference. I wish
I could attend. But I do hope by this message to raise some general
concern about this problem.


That's an interesting issue.

A solution like (3) is a little bit out of scope, as it is a pure userspace
(or a mixed userspace USB stack) solution.

Technically speaking, letting the same device being handled by either an
userspace or a kernelspace driver doesn't seem smart to me, due to:
- Duplicated efforts to maintain both drivers;
- It is hard to sync a kernel driver with an userspace driver,
as you've pointed.

So, we're between (1) or (2).

Moving the solution entirely to userspace will have, additionally, the
problem of having two applications trying to access the same hardware
using two different userspace instances (for example, an incoming videoconf
call while Gphoto is opened, assuming that such videoconf call would also
have an userspace driver).

IMO, the right solution is to work on a proper snapshot mode, in kernelspace,
and moving the drivers that have already a kernelspace out of Gphoto.



I agree that solution 1) so all the driver bits in kernelspace is the right
solution. This is unrelated to snapshot mode though, snapshot mode is all
about taking live snapshots. Where as in this case we are downloading
pictures which have already been taken (perhaps days ago) from device memory.

What we need for thi

Re: [Linaro-mm-sig] Buffer sharing proof-of-concept

[Clark, Rob]

On Thu, Aug 4, 2011 at 3:58 AM, Daniel Vetter  wrote:
> On Wed, Aug 3, 2011 at 17:12, Jordan Crouse  wrote:
>> On 08/03/2011 03:33 AM, Tom Cooksey wrote:
>>> Passing buffer meta-data around was also discussed yesterday. Again, the
>>> general consensus seemed to be that this data should be kept out of the
>>> kernel. The userspace application should know what the buffer format
>>> etc. is and can provide that information to the relevant device APIs
>>> when is passes in the buffer.
>>
>> True, but APIs change slowly. Some APIs *cough* OpenMAX *cough* are damn
>> near immutable over the life time of a average software release. A blob of
>> data attached to a buffer can evolve far more rapidly and be far more
>> extensible and much more vendor specific. This isn't an new idea, I think
>> the DRM/GEM guys have tossed it around too.
>
> Erh, no. For sharing gem buffers between process (i.e. between direct
> rendering clients and the compositor, whatever that is) we just hand
> around the gem id in the kernel. Some more stuff gets passed around in
> userspace in a generic way (e.g. DRI2 passes the buffer type (depth,
> stencil, color, ...) and the stride), but that's it.
>
> Everything else is driver specific and mostly not even passed around
> explicitly and just agreed upon implicitly. E.g. running the wrong
> XvMC decoder lib for your Xorg Intel driver will result in garbage on
> the screen. There's a bit more leeway between Mesa and the Xorg driver
> because they're released independantly, but it's very ad-hoc (i.e.
> oops, that buffer doesn't fit the requirements of the new code, must
> be an old Xorg driver, so switch to the compat paths in Mesa).
>
> But my main fear with the "blob attached to the buffer" idea is that
> sooner or later it'll be part of the kernel/userspace interface of the
> buffer sharing api ("hey, it's there, why not use it?"). And the
> timeframe for deprecating the kernel abi is 5-10 years and yes I've
> tried to dodge that and got shot at.

hmm, there would be a dmabuf->private ptr in struct dmabuf.  Normally
that should be for private data of the buffer allocator, but I guess
it could be (ab)used for under the hood communication between drivers
a platform specific way.  It does seem a bit hacky, but at least it
does not need to be exposed to userspace.

(Or maybe a better option is just 'rm -rf omx' ;-))

BR,
-R

> Imo a better approach is to spec
> (_after_ the kernel buffer sharing works) a low-level userspace api
> that drivers need to implement (like the EGL Mesa extensions used to
> make Wayland work on gem drivers).
> -Daniel
> --
> Daniel Vetter
> daniel.vet...@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
> ___
> Linaro-mm-sig mailing list
> linaro-mm-...@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
>
--
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: vp702x

[Florian Mickler]

On Thu, 4 Aug 2011 13:29:42 +0300
Dan Carpenter  wrote:

> On Thu, Aug 04, 2011 at 12:21:29PM +0200, Florian Mickler wrote:
> > Mauro, what to do?
> 
> Apply the fix which Tino tested, perhaps?  :P  (obviously).
> 
> The bug is present in 3.0 so it should be tagged for stable as well.
> 
> regards,
> dan carpenter

Two different drivers ;) I fear the fix Tino tested does not apply to
vp702x.. (it's for vp7045)

Regards,
Flo
--
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: vp702x

[Dan Carpenter]

On Thu, Aug 04, 2011 at 12:21:29PM +0200, Florian Mickler wrote:
> Mauro, what to do?

Apply the fix which Tino tested, perhaps?  :P  (obviously).

The bug is present in 3.0 so it should be tagged for stable as well.

regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/4] drivers/media/video/hexium_gemini.c: delete useless initialization

[Julia Lawall]

From: Julia Lawall 

Delete nontrivial initialization that is immediately overwritten by the
result of an allocation function.

The semantic match that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
type T;
identifier i;
expression e;
@@

(
T i = \(0\|NULL\|ERR_PTR(...)\);
|
-T i = e;
+T i;
)
... when != i
i = \(kzalloc\|kcalloc\|kmalloc\)(...);

// 

Signed-off-by: Julia Lawall 

---
 drivers/media/video/hexium_gemini.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -u -p a/drivers/media/video/hexium_gemini.c 
b/drivers/media/video/hexium_gemini.c
--- a/drivers/media/video/hexium_gemini.c
+++ b/drivers/media/video/hexium_gemini.c
@@ -352,7 +352,7 @@ static struct saa7146_ext_vv vv_data;
 /* this function only gets called when the probing was successful */
 static int hexium_attach(struct saa7146_dev *dev, struct 
saa7146_pci_extension_data *info)
 {
-   struct hexium *hexium = (struct hexium *) dev->ext_priv;
+   struct hexium *hexium;
int ret;
 
DEB_EE((".\n"));

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: vp702x

[Florian Mickler]

Hi,

On Wed, 3 Aug 2011 09:39:46 +0200 (CEST)
Patrick Boettcher  wrote:

> Hi Florian,
> 
> 
> I'm not sure whether I still have exactly this box. There were two 
> versions and I got rid of at least one of them.
> 
> I moved recently into a new house and right now a lot of things are hidden 
> in some boxes somewhere... I'll try to find some time to check it. Don't 
> ask me when that will be :).
> 

ok, thanks for the heads up nonetheless. 

Mauro, what to do? Currently it will bug on
driver probe like the vp7045 (which Tino confirmed works now again
with my recent patch).

Before the patchseries it would use on-stack dma buffers (don't know
about the actual harm of these, at least a WARN from libdma, but
rumours are that they may format your disk if the moon aligns with
the sun and a special unspecified planet). 

Regards,
Flo


> regards,
> --
> 
> Patrick Boettcher - 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: [Linaro-mm-sig] Buffer sharing proof-of-concept

[Daniel Vetter]

On Wed, Aug 3, 2011 at 17:12, Jordan Crouse  wrote:
> On 08/03/2011 03:33 AM, Tom Cooksey wrote:
>> Passing buffer meta-data around was also discussed yesterday. Again, the
>> general consensus seemed to be that this data should be kept out of the
>> kernel. The userspace application should know what the buffer format
>> etc. is and can provide that information to the relevant device APIs
>> when is passes in the buffer.
>
> True, but APIs change slowly. Some APIs *cough* OpenMAX *cough* are damn
> near immutable over the life time of a average software release. A blob of
> data attached to a buffer can evolve far more rapidly and be far more
> extensible and much more vendor specific. This isn't an new idea, I think
> the DRM/GEM guys have tossed it around too.

Erh, no. For sharing gem buffers between process (i.e. between direct
rendering clients and the compositor, whatever that is) we just hand
around the gem id in the kernel. Some more stuff gets passed around in
userspace in a generic way (e.g. DRI2 passes the buffer type (depth,
stencil, color, ...) and the stride), but that's it.

Everything else is driver specific and mostly not even passed around
explicitly and just agreed upon implicitly. E.g. running the wrong
XvMC decoder lib for your Xorg Intel driver will result in garbage on
the screen. There's a bit more leeway between Mesa and the Xorg driver
because they're released independantly, but it's very ad-hoc (i.e.
oops, that buffer doesn't fit the requirements of the new code, must
be an old Xorg driver, so switch to the compat paths in Mesa).

But my main fear with the "blob attached to the buffer" idea is that
sooner or later it'll be part of the kernel/userspace interface of the
buffer sharing api ("hey, it's there, why not use it?"). And the
timeframe for deprecating the kernel abi is 5-10 years and yes I've
tried to dodge that and got shot at. Imo a better approach is to spec
(_after_ the kernel buffer sharing works) a low-level userspace api
that drivers need to implement (like the EGL Mesa extensions used to
make Wayland work on gem drivers).
-Daniel
-- 
Daniel Vetter
daniel.vet...@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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] V4L: add two new ioctl()s for multi-size videobuffer management

[Sakari Ailus]

Guennadi Liakhovetski wrote:
> On Wed, 3 Aug 2011, Hans Verkuil wrote:
> 
 On Thu, 28 Jul 2011, Hans Verkuil wrote:

> On Thursday, July 28, 2011 06:11:38 Pawel Osciak wrote:
>> Hi Guennadi,
>>
>> On Wed, Jul 20, 2011 at 01:43, Guennadi Liakhovetski
>>  wrote:
>>> A possibility to preallocate and initialise buffers of different
> sizes
>>> in V4L2 is required for an efficient implementation of asnapshot
> mode.
>>> This patch adds two new ioctl()s: VIDIOC_CREATE_BUFS and
>>> VIDIOC_PREPARE_BUF and defines respective data structures.
>>>
>>> Signed-off-by: Guennadi Liakhovetski 
>>> ---
>>>
>> 
>>
>> This looks nicer, I like how we got rid of destroy and gave up on
>> making holes, it would've given us a lot of headaches. I'm thinking
>> about some issues though and also have some comments/questions
> further
>> below.
>>
>> Already mentioned by others mixing of REQBUFS and CREATE_BUFS.
>> Personally I'd like to allow mixing, including REQBUFS for non-zero,
>> because I think it would be easy to do. I think it could work in the
>> same way as REQBUFS for !=0 works currently (at least in vb2), if we
>> already have some buffers allocated and they are not in use, we free
>> them and a new set is allocated. So I guess it could just stay this
>> way. REQBUFS(0) would of course free everything.
>>
>> Passing format to CREATE_BUFS will make vb2 a bit format-aware, as it
>> would have to pass it forward to the driver somehow. The obvious way
>> would be just vb2 calling the driver's s_fmt handler, but that won't
>> work, as you can't pass indexes to s_fmt. So we'd have to implement a
>> new driver callback for setting formats per index. I guess there is
> no
>> way around it, unless we actually take the format struct out of
>> CREATE_BUFS and somehow do it via S_FMT. The single-planar structure
>> is full already though, the only way would be to use
>> v4l2_pix_format_mplane instead with plane count = 1 (or more if
>> needed).
>
> I just got an idea for this: use TRY_FMT. That will do exactly what
> you want. In fact, perhaps we should remove the format struct from
> CREATE_BUFS and use __u32 sizes[VIDEO_MAX_PLANES] instead. Let the
> application call TRY_FMT and initialize the sizes array instead of
> putting that into vb2. We may need a num_planes field as well. If the
> sizes are all 0 (or num_planes is 0), then the driver can use the
> current
> format, just as it does with REQBUFS.
>
> Or am I missing something?

 ...After more thinking and looking at the vb2 code, this began to feel
 wrong to me. This introduces an asymmetry, which doesn't necessarily
 look
 good to me. At present we have the TRY_FMT and S_FMT ioctl()s, which
 among
 other tasks calculate sizeimage and bytesperline - either per plane or
 total.
>>>
>>> Correct.
>>>
 Besides we also have the REQBUFS call, that internally calls the
 .queue_setup() queue method. In that method the _driver_ has a chance to
 calculate for the _current format_ the number of planes (again?...) and
 buffer sizes for each plane.
>>>
>>> Correct. Usually the driver will update some internal datastructure
>>> whenever S_FMT is called to store the sizeimage/bytesperline etc. so
>>> queue_setup can refer to those values.
>>>
 This suggests, that the latter calculation
 can be different from the former.
>>>
>>> No, it can't (shouldn't). For USERPTR mode applications always need to
>>> rely on sizeimage anyway, so doing anything different in queue_setup is
>>> something I would consider a driver bug.
>>>
 Now you're suggesting to use TRY_FMT to calculate the number of planes
 and
 per-plane sizeofimage, and then use _only_ this information to set up
 the
 buffers from the CREATE_BUFS ioctl(). So, are we now claiming, that this
 information alone (per-plane-sizeofimage) should be dufficient to set up
 buffers?
>>>
>>> Yes. Again, if it is not sufficient, then USERPTR wouldn't work :-)
>>
>> Ouch. While this is correct with respect to the sizes, it is a different
>> matter when it comes to e.g. start addresses.
>>
>> The prime example is the Samsung hardware where some multiplanar formats
>> need to be allocated from specific memory banks. So trying to pass just
>> sizes to CREATE_BUFS would not carry enough information for the samsung
>> driver to decide whether or not to allocate from specific memory banks or
>> if any memory will do.
>>
>> So either we go back to using v4l2_format, or we add a fourcc describing
>> the pixelformat. I *think* this may be sufficient, but I do not know for
>> sure.
> 
> Nobody knows for sure, that's why we've got 19 * 4 reserved bytes in 
> there;-)
> 
> From my PoV, I would add a fourcc field. Having only sizes in struct 
> v4l2_create_buffers

[PATCH 21/21] [staging] tm6000: Remove unnecessary workaround.

[Thierry Reding]

Implicitly setting the tuner frequency each time the device is opened
seems no longer necessary, so it is removed. This speeds up opening the
device by about 120 ms.

It also avoids excessive firmware reloads because the default will load
the BASE and F8MHZ type firmwares independent of which device, video or
radio, is opened. Before this patch opening the radio device would
automatically trigger a BASE and F8MHZ firmware load only to immediately
replace them by the FM firmware.
---
 drivers/staging/tm6000/tm6000-core.c |   19 ---
 1 files changed, 0 insertions(+), 19 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000-core.c 
b/drivers/staging/tm6000/tm6000-core.c
index 58c1399..7bb1d37 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@ -264,8 +264,6 @@ static void tm6000_set_vbi(struct tm6000_core *dev)
 
 int tm6000_init_analog_mode(struct tm6000_core *dev)
 {
-   struct v4l2_frequency f;
-
if (dev->dev_type == TM6010) {
u8 active = TM6010_REQ07_RCC_ACTIVE_IF_AUDIO_ENABLE;
 
@@ -304,24 +302,7 @@ int tm6000_init_analog_mode(struct tm6000_core *dev)
/* Disables soft reset */
tm6000_set_reg(dev, TM6010_REQ07_R3F_RESET, 0x00);
}
-   msleep(20);
-
-   /* Tuner firmware can now be loaded */
-
-   /*
-* FIXME: This is a hack! xc3028 "sleeps" when no channel is detected
-* for more than a few seconds. Not sure why, as this behavior does
-* not happen on other devices with xc3028. So, I suspect that it
-* is yet another bug at tm6000. After start sleeping, decoding
-* doesn't start automatically. Instead, it requires some
-* I2C commands to wake it up. As we want to have image at the
-* beginning, we needed to add this hack. The better would be to
-* discover some way to make tm6000 to wake up without this hack.
-*/
-   f.frequency = dev->freq;
-   v4l2_device_call_all(&dev->v4l2_dev, 0, tuner, s_frequency, &f);
 
-   msleep(100);
tm6000_set_standard(dev);
tm6000_set_vbi(dev);
tm6000_set_audio_bitrate(dev, 48000);
-- 
1.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 20/21] [staging] tm6000: Enable radio mode for Cinergy Hybrid XE.

[Thierry Reding]

---
 drivers/staging/tm6000/tm6000-cards.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000-cards.c 
b/drivers/staging/tm6000/tm6000-cards.c
index 94fd138..ab3aa2c 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -469,6 +469,7 @@ static struct tm6000_board tm6000_boards[] = {
.has_zl10353  = 1,
.has_eeprom   = 1,
.has_remote   = 1,
+   .has_radio= 1,
},
.gpio = {
.tuner_reset= TM6010_GPIO_2,
@@ -494,6 +495,10 @@ static struct tm6000_board tm6000_boards[] = {
.amux   = TM6000_AMUX_ADC2,
},
},
+   .rinput = {
+   .type = TM6000_INPUT_RADIO,
+   .amux = TM6000_AMUX_SIF1,
+   },
},
[TM5600_BOARD_TERRATEC_GRABSTER] = {
.name = "Terratec Grabster AV 150/250 MX",
-- 
1.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 17/21] [staging] tm6000: Do not use video buffers in radio mode.

[Thierry Reding]

If the radio device is opened there is no need to initialize the video
buffer queue because it is not used.
---
 drivers/staging/tm6000/tm6000-video.c |   18 ++
 1 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000-video.c 
b/drivers/staging/tm6000/tm6000-video.c
index b59a0da..bb39c91 100644
--- a/drivers/staging/tm6000/tm6000-video.c
+++ b/drivers/staging/tm6000/tm6000-video.c
@@ -1539,13 +1539,13 @@ static int tm6000_open(struct file *file)
dev->mode = TM6000_MODE_ANALOG;
}
 
-   videobuf_queue_vmalloc_init(&fh->vb_vidq, &tm6000_video_qops,
-   NULL, &dev->slock,
-   fh->type,
-   V4L2_FIELD_INTERLACED,
-   sizeof(struct tm6000_buffer), fh, &dev->lock);
-
-   if (fh->radio) {
+   if (!fh->radio) {
+   videobuf_queue_vmalloc_init(&fh->vb_vidq, &tm6000_video_qops,
+   NULL, &dev->slock,
+   fh->type,
+   V4L2_FIELD_INTERLACED,
+   sizeof(struct tm6000_buffer), fh, &dev->lock);
+   } else {
dprintk(dev, V4L2_DEBUG_OPEN, "video_open: setting radio 
device\n");
dev->input = 5;
tm6000_set_audio_rinput(dev);
@@ -1617,7 +1617,9 @@ static int tm6000_release(struct file *file)
int err;
 
tm6000_uninit_isoc(dev);
-   videobuf_mmap_free(&fh->vb_vidq);
+
+   if (!fh->radio)
+   videobuf_mmap_free(&fh->vb_vidq);
 
err = tm6000_reset(dev);
if (err < 0)
-- 
1.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 18/21] [staging] tm6000: Plug memory leak on PCM free.

[Thierry Reding]

When releasing hardware resources, the DMA buffer allocated to the PCM
device needs to be freed to prevent a memory leak.
---
 drivers/staging/tm6000/tm6000-alsa.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000-alsa.c 
b/drivers/staging/tm6000/tm6000-alsa.c
index 35ad1f0..2bf21600 100644
--- a/drivers/staging/tm6000/tm6000-alsa.c
+++ b/drivers/staging/tm6000/tm6000-alsa.c
@@ -308,6 +308,7 @@ static int snd_tm6000_hw_free(struct snd_pcm_substream 
*substream)
schedule_work(&core->wq_trigger);
}
 
+   dsp_buffer_free(substream);
return 0;
 }
 
-- 
1.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 19/21] [staging] tm6000: Enable audio clock in radio mode.

[Thierry Reding]

---
 drivers/staging/tm6000/tm6000-stds.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000-stds.c 
b/drivers/staging/tm6000/tm6000-stds.c
index f44451b..9a4145d 100644
--- a/drivers/staging/tm6000/tm6000-stds.c
+++ b/drivers/staging/tm6000/tm6000-stds.c
@@ -357,6 +357,7 @@ static int tm6000_set_audio_std(struct tm6000_core *dev)
tm6000_set_reg(dev, TM6010_REQ08_RF1_AADC_POWER_DOWN, 0xfe);
tm6000_set_reg(dev, TM6010_REQ08_R1E_A_GAIN_DEEMPH_OUT, 0x13);
tm6000_set_reg(dev, TM6010_REQ08_R01_A_INIT, 0x80);
+   tm6000_set_reg(dev, TM6010_REQ07_RFE_POWER_DOWN, 0xff);
return 0;
}
 
-- 
1.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 15/21] [staging] tm6000: Execute lightweight reset on close.

[Thierry Reding]

When the last user closes the device, perform a lightweight reset of the
device to bring it into a well-known state.

Note that this is not always enough with the TM6010, which sometimes
needs a hard reset to get into a working state again.
---
 drivers/staging/tm6000/tm6000-core.c  |   43 +
 drivers/staging/tm6000/tm6000-video.c |8 +-
 drivers/staging/tm6000/tm6000.h   |1 +
 3 files changed, 51 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000-core.c 
b/drivers/staging/tm6000/tm6000-core.c
index 317ab7e..58c1399 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@ -597,6 +597,49 @@ int tm6000_init(struct tm6000_core *dev)
return rc;
 }
 
+int tm6000_reset(struct tm6000_core *dev)
+{
+   int pipe;
+   int err;
+
+   msleep(500);
+
+   err = usb_set_interface(dev->udev, dev->isoc_in.bInterfaceNumber, 0);
+   if (err < 0) {
+   tm6000_err("failed to select interface %d, alt. setting 0\n",
+   dev->isoc_in.bInterfaceNumber);
+   return err;
+   }
+
+   err = usb_reset_configuration(dev->udev);
+   if (err < 0) {
+   tm6000_err("failed to reset configuration\n");
+   return err;
+   }
+
+   msleep(5);
+
+   err = usb_set_interface(dev->udev, dev->isoc_in.bInterfaceNumber, 2);
+   if (err < 0) {
+   tm6000_err("failed to select interface %d, alt. setting 2\n",
+   dev->isoc_in.bInterfaceNumber);
+   return err;
+   }
+
+   msleep(5);
+
+   pipe = usb_rcvintpipe(dev->udev,
+   dev->int_in.endp->desc.bEndpointAddress & 
USB_ENDPOINT_NUMBER_MASK);
+
+   err = usb_clear_halt(dev->udev, pipe);
+   if (err < 0) {
+   tm6000_err("usb_clear_halt failed: %d\n", err);
+   return err;
+   }
+
+   return 0;
+}
+
 int tm6000_set_audio_bitrate(struct tm6000_core *dev, int bitrate)
 {
int val = 0;
diff --git a/drivers/staging/tm6000/tm6000-video.c 
b/drivers/staging/tm6000/tm6000-video.c
index 492ec73..70fc19e 100644
--- a/drivers/staging/tm6000/tm6000-video.c
+++ b/drivers/staging/tm6000/tm6000-video.c
@@ -1503,7 +1503,6 @@ static int tm6000_open(struct file *file)
tm6000_get_std_res(dev);
 
file->private_data = fh;
-   fh->vdev = vdev;
fh->dev = dev;
fh->radio = radio;
fh->type = type;
@@ -1606,9 +1605,16 @@ static int tm6000_release(struct file *file)
dev->users--;
 
res_free(dev, fh);
+
if (!dev->users) {
+   int err;
+
tm6000_uninit_isoc(dev);
videobuf_mmap_free(&fh->vb_vidq);
+
+   err = tm6000_reset(dev);
+   if (err < 0)
+   dev_err(&vdev->dev, "reset failed: %d\n", err);
}
 
kfree(fh);
diff --git a/drivers/staging/tm6000/tm6000.h b/drivers/staging/tm6000/tm6000.h
index cf57e1e..dac2063 100644
--- a/drivers/staging/tm6000/tm6000.h
+++ b/drivers/staging/tm6000/tm6000.h
@@ -311,6 +311,7 @@ int tm6000_set_reg_mask(struct tm6000_core *dev, u8 req, 
u16 value,
u16 index, u16 mask);
 int tm6000_i2c_reset(struct tm6000_core *dev, u16 tsleep);
 int tm6000_init(struct tm6000_core *dev);
+int tm6000_reset(struct tm6000_core *dev);
 
 int tm6000_init_analog_mode(struct tm6000_core *dev);
 int tm6000_init_digital_mode(struct tm6000_core *dev);
-- 
1.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 14/21] [staging] tm6000: Initialize isochronous transfers only once.

[Thierry Reding]

This fixes a memory leak where isochronous buffers would be set up for
each video buffer, while it is sufficient to set them up only once per
device.
---
 drivers/staging/tm6000/tm6000-video.c |8 ++--
 1 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000-video.c 
b/drivers/staging/tm6000/tm6000-video.c
index 4b50f6c..492ec73 100644
--- a/drivers/staging/tm6000/tm6000-video.c
+++ b/drivers/staging/tm6000/tm6000-video.c
@@ -758,7 +758,7 @@ buffer_prepare(struct videobuf_queue *vq, struct 
videobuf_buffer *vb,
struct tm6000_fh *fh  = vq->priv_data;
struct tm6000_buffer *buf = container_of(vb, struct tm6000_buffer, vb);
struct tm6000_core   *dev = fh->dev;
-   int rc = 0, urb_init = 0;
+   int rc = 0;
 
BUG_ON(NULL == fh->fmt);
 
@@ -784,13 +784,9 @@ buffer_prepare(struct videobuf_queue *vq, struct 
videobuf_buffer *vb,
rc = videobuf_iolock(vq, &buf->vb, NULL);
if (rc != 0)
goto fail;
-   urb_init = 1;
}
 
-   if (!dev->isoc_ctl.num_bufs)
-   urb_init = 1;
-
-   if (urb_init) {
+   if (!dev->isoc_ctl.num_bufs) {
rc = tm6000_prepare_isoc(dev);
if (rc < 0)
goto fail;
-- 
1.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 16/21] [staging] tm6000: Select interface on first open.

[Thierry Reding]

Instead of selecting the default interface setting when preparing
isochronous transfers, select it on the first call to open() to make
sure it is available earlier.
---
 drivers/staging/tm6000/tm6000-video.c |   17 -
 1 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000-video.c 
b/drivers/staging/tm6000/tm6000-video.c
index 70fc19e..b59a0da 100644
--- a/drivers/staging/tm6000/tm6000-video.c
+++ b/drivers/staging/tm6000/tm6000-video.c
@@ -595,11 +595,6 @@ static int tm6000_prepare_isoc(struct tm6000_core *dev)
tm6000_uninit_isoc(dev);
/* Stop interrupt USB pipe */
tm6000_ir_int_stop(dev);
-
-   usb_set_interface(dev->udev,
- dev->isoc_in.bInterfaceNumber,
- dev->isoc_in.bAlternateSetting);
-
/* Start interrupt USB pipe */
tm6000_ir_int_start(dev);
 
@@ -1484,6 +1479,18 @@ static int tm6000_open(struct file *file)
break;
}
 
+   if (dev->users == 0) {
+   int err = usb_set_interface(dev->udev,
+   dev->isoc_in.bInterfaceNumber,
+   dev->isoc_in.bAlternateSetting);
+   if (err < 0) {
+   dev_err(&vdev->dev, "failed to select interface %d, "
+   "alt. setting %d\n",
+   dev->isoc_in.bInterfaceNumber,
+   dev->isoc_in.bAlternateSetting);
+   }
+   }
+
/* If more than one user, mutex should be added */
dev->users++;
 
-- 
1.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 13/21] [staging] tm6000: Properly count device usage.

[Thierry Reding]

When the USB device is disconnected, the device usage bit is not cleared
properly. This leads to errors when a device is unplugged and replugged
several times until all TM6000_MAXBOARDS bits are used and keeps the
driver from binding to the device.
---
 drivers/staging/tm6000/tm6000-cards.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000-cards.c 
b/drivers/staging/tm6000/tm6000-cards.c
index 68f7c7a..94fd138 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -1177,7 +1177,7 @@ static int tm6000_usb_probe(struct usb_interface 
*interface,
mutex_init(&dev->usb_lock);
 
/* Increment usage count */
-   tm6000_devused |= 1model = id->driver_info;
@@ -1293,7 +1293,7 @@ static int tm6000_usb_probe(struct usb_interface 
*interface,
 err:
printk(KERN_ERR "tm6000: Error %d while registering\n", rc);
 
-   tm6000_devused &= ~(1

[PATCH 11/21] [staging] tm6000: Rework standard register tables.

[Thierry Reding]

This commit uses sentinel entries to terminate the TV standard register
tables instead of hard-coding their size, allowing further entries to be
added more easily. It is also more space-efficient if the tables have a
varying number of entries.
---
 drivers/staging/tm6000/tm6000-stds.c |  610 --
 1 files changed, 294 insertions(+), 316 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000-stds.c 
b/drivers/staging/tm6000/tm6000-stds.c
index cd69626..f44451b 100644
--- a/drivers/staging/tm6000/tm6000-stds.c
+++ b/drivers/staging/tm6000/tm6000-stds.c
@@ -35,316 +35,303 @@ struct tm6000_reg_settings {
 
 struct tm6000_std_settings {
v4l2_std_id id;
-   struct tm6000_reg_settings common[27];
+   struct tm6000_reg_settings *common;
+};
+
+static struct tm6000_reg_settings composite_pal_m[] = {
+   { TM6010_REQ07_R3F_RESET, 0x01 },
+   { TM6010_REQ07_R00_VIDEO_CONTROL0, 0x04 },
+   { TM6010_REQ07_R01_VIDEO_CONTROL1, 0x0e },
+   { TM6010_REQ07_R02_VIDEO_CONTROL2, 0x5f },
+   { TM6010_REQ07_R03_YC_SEP_CONTROL, 0x00 },
+   { TM6010_REQ07_R07_OUTPUT_CONTROL, 0x31 },
+   { TM6010_REQ07_R18_CHROMA_DTO_INCREMENT3, 0x1e },
+   { TM6010_REQ07_R19_CHROMA_DTO_INCREMENT2, 0x83 },
+   { TM6010_REQ07_R1A_CHROMA_DTO_INCREMENT1, 0x0a },
+   { TM6010_REQ07_R1B_CHROMA_DTO_INCREMENT0, 0xe0 },
+   { TM6010_REQ07_R1C_HSYNC_DTO_INCREMENT3, 0x1c },
+   { TM6010_REQ07_R1D_HSYNC_DTO_INCREMENT2, 0xcc },
+   { TM6010_REQ07_R1E_HSYNC_DTO_INCREMENT1, 0xcc },
+   { TM6010_REQ07_R1F_HSYNC_DTO_INCREMENT0, 0xcd },
+   { TM6010_REQ07_R2E_ACTIVE_VIDEO_HSTART, 0x88 },
+   { TM6010_REQ07_R30_ACTIVE_VIDEO_VSTART, 0x20 },
+   { TM6010_REQ07_R31_ACTIVE_VIDEO_VHIGHT, 0x61 },
+   { TM6010_REQ07_R33_VSYNC_HLOCK_MAX, 0x0c },
+   { TM6010_REQ07_R35_VSYNC_AGC_MAX, 0x1c },
+   { TM6010_REQ07_R82_COMB_FILTER_CONFIG, 0x52 },
+   { TM6010_REQ07_R83_CHROMA_LOCK_CONFIG, 0x6f },
+   { TM6010_REQ07_R04_LUMA_HAGC_CONTROL, 0xdc },
+   { TM6010_REQ07_R0D_CHROMA_KILL_LEVEL, 0x07 },
+   { TM6010_REQ07_R3F_RESET, 0x00 },
+   { 0, 0, 0 }
+};
+
+static struct tm6000_reg_settings composite_pal_nc[] = {
+   { TM6010_REQ07_R3F_RESET, 0x01 },
+   { TM6010_REQ07_R00_VIDEO_CONTROL0, 0x36 },
+   { TM6010_REQ07_R01_VIDEO_CONTROL1, 0x0e },
+   { TM6010_REQ07_R02_VIDEO_CONTROL2, 0x5f },
+   { TM6010_REQ07_R03_YC_SEP_CONTROL, 0x02 },
+   { TM6010_REQ07_R07_OUTPUT_CONTROL, 0x31 },
+   { TM6010_REQ07_R18_CHROMA_DTO_INCREMENT3, 0x1e },
+   { TM6010_REQ07_R19_CHROMA_DTO_INCREMENT2, 0x91 },
+   { TM6010_REQ07_R1A_CHROMA_DTO_INCREMENT1, 0x1f },
+   { TM6010_REQ07_R1B_CHROMA_DTO_INCREMENT0, 0x0c },
+   { TM6010_REQ07_R1C_HSYNC_DTO_INCREMENT3, 0x1c },
+   { TM6010_REQ07_R1D_HSYNC_DTO_INCREMENT2, 0xcc },
+   { TM6010_REQ07_R1E_HSYNC_DTO_INCREMENT1, 0xcc },
+   { TM6010_REQ07_R1F_HSYNC_DTO_INCREMENT0, 0xcd },
+   { TM6010_REQ07_R2E_ACTIVE_VIDEO_HSTART, 0x8c },
+   { TM6010_REQ07_R30_ACTIVE_VIDEO_VSTART, 0x2c },
+   { TM6010_REQ07_R31_ACTIVE_VIDEO_VHIGHT, 0xc1 },
+   { TM6010_REQ07_R33_VSYNC_HLOCK_MAX, 0x0c },
+   { TM6010_REQ07_R35_VSYNC_AGC_MAX, 0x1c },
+   { TM6010_REQ07_R82_COMB_FILTER_CONFIG, 0x52 },
+   { TM6010_REQ07_R83_CHROMA_LOCK_CONFIG, 0x6f },
+   { TM6010_REQ07_R04_LUMA_HAGC_CONTROL, 0xdc },
+   { TM6010_REQ07_R0D_CHROMA_KILL_LEVEL, 0x07 },
+   { TM6010_REQ07_R3F_RESET, 0x00 },
+   { 0, 0, 0 }
+};
+
+static struct tm6000_reg_settings composite_pal[] = {
+   { TM6010_REQ07_R3F_RESET, 0x01 },
+   { TM6010_REQ07_R00_VIDEO_CONTROL0, 0x32 },
+   { TM6010_REQ07_R01_VIDEO_CONTROL1, 0x0e },
+   { TM6010_REQ07_R02_VIDEO_CONTROL2, 0x5f },
+   { TM6010_REQ07_R03_YC_SEP_CONTROL, 0x02 },
+   { TM6010_REQ07_R07_OUTPUT_CONTROL, 0x31 },
+   { TM6010_REQ07_R18_CHROMA_DTO_INCREMENT3, 0x25 },
+   { TM6010_REQ07_R19_CHROMA_DTO_INCREMENT2, 0xd5 },
+   { TM6010_REQ07_R1A_CHROMA_DTO_INCREMENT1, 0x63 },
+   { TM6010_REQ07_R1B_CHROMA_DTO_INCREMENT0, 0x50 },
+   { TM6010_REQ07_R1C_HSYNC_DTO_INCREMENT3, 0x1c },
+   { TM6010_REQ07_R1D_HSYNC_DTO_INCREMENT2, 0xcc },
+   { TM6010_REQ07_R1E_HSYNC_DTO_INCREMENT1, 0xcc },
+   { TM6010_REQ07_R1F_HSYNC_DTO_INCREMENT0, 0xcd },
+   { TM6010_REQ07_R2E_ACTIVE_VIDEO_HSTART, 0x8c },
+   { TM6010_REQ07_R30_ACTIVE_VIDEO_VSTART, 0x2c },
+   { TM6010_REQ07_R31_ACTIVE_VIDEO_VHIGHT, 0xc1 },
+   { TM6010_REQ07_R33_VSYNC_HLOCK_MAX, 0x0c },
+   { TM6010_REQ07_R35_VSYNC_AGC_MAX, 0x1c },
+   { TM6010_REQ07_R82_COMB_FILTER_CONFIG, 0x52 },
+   { TM6010_REQ07_R83_CHROMA_LOCK_CONFIG, 0x6f },
+   { TM6010_REQ07_R04_LUMA_HAGC_CONTROL, 0xdc },
+   { TM6010_REQ07_R0D_CHROMA_KILL_LEVEL, 0x07 },
+   { TM6010_REQ07_R3F_RESET, 0x00 },
+   { 0, 0, 0 }
+};
+
+static struct tm6000_reg_settings composite_secam[] = {
+   { TM6010_REQ07_R3F_RESET, 0x01 }

[PATCH 12/21] [staging] tm6000: Add locking for USB transfers.

[Thierry Reding]

This commit introduces the usb_lock mutex to ensure that a USB request
always gets the proper response. While this is currently not really
necessary it will become important as there are more users.
---
 drivers/staging/tm6000/tm6000-cards.c |1 +
 drivers/staging/tm6000/tm6000-core.c  |3 +++
 drivers/staging/tm6000/tm6000.h   |1 +
 3 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000-cards.c 
b/drivers/staging/tm6000/tm6000-cards.c
index a5d2a71..68f7c7a 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -1174,6 +1174,7 @@ static int tm6000_usb_probe(struct usb_interface 
*interface,
return -ENOMEM;
}
spin_lock_init(&dev->slock);
+   mutex_init(&dev->usb_lock);
 
/* Increment usage count */
tm6000_devused |= 1usb_lock);
return ret;
 }
 
diff --git a/drivers/staging/tm6000/tm6000.h b/drivers/staging/tm6000/tm6000.h
index 4323fc2..cf57e1e 100644
--- a/drivers/staging/tm6000/tm6000.h
+++ b/drivers/staging/tm6000/tm6000.h
@@ -245,6 +245,7 @@ struct tm6000_core {
 
/* locks */
struct mutexlock;
+   struct mutexusb_lock;
 
/* usb transfer */
struct usb_device   *udev;  /* the usb device */
-- 
1.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 10/21] [staging] tm6000: Disable video interface in radio mode.

[Thierry Reding]

Video data is useless in radio mode, so the corresponding interface can
be safely disabled. This should reduce the amount of isochronous traffic
noticeably.
---
 drivers/staging/tm6000/tm6000-core.c |7 ++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000-core.c 
b/drivers/staging/tm6000/tm6000-core.c
index 2117f8e..1f8abe3 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@ -264,9 +264,14 @@ int tm6000_init_analog_mode(struct tm6000_core *dev)
struct v4l2_frequency f;
 
if (dev->dev_type == TM6010) {
+   u8 active = TM6010_REQ07_RCC_ACTIVE_IF_AUDIO_ENABLE;
+
+   if (!dev->radio)
+   active |= TM6010_REQ07_RCC_ACTIVE_IF_VIDEO_ENABLE;
+
/* Enable video and audio */
tm6000_set_reg_mask(dev, TM6010_REQ07_RCC_ACTIVE_IF,
-   0x60, 0x60);
+   active, 0x60);
/* Disable TS input */
tm6000_set_reg_mask(dev, TM6010_REQ07_RC0_ACTIVE_VIDEO_SOURCE,
0x00, 0x40);
-- 
1.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 09/21] [staging] tm6000: Rename active interface register.

[Thierry Reding]

The register ACTIVE_VIDEO_IF register should be named ACTIVE_IF since it
controls more than just the video interface.
---
 drivers/staging/tm6000/tm6000-alsa.c |4 ++--
 drivers/staging/tm6000/tm6000-core.c |   12 ++--
 drivers/staging/tm6000/tm6000-regs.h |4 +++-
 3 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000-alsa.c 
b/drivers/staging/tm6000/tm6000-alsa.c
index 768d713..35ad1f0 100644
--- a/drivers/staging/tm6000/tm6000-alsa.c
+++ b/drivers/staging/tm6000/tm6000-alsa.c
@@ -80,7 +80,7 @@ static int _tm6000_start_audio_dma(struct snd_tm6000_card 
*chip)
dprintk(1, "Starting audio DMA\n");
 
/* Enables audio */
-   tm6000_set_reg_mask(core, TM6010_REQ07_RCC_ACTIVE_VIDEO_IF, 0x40, 0x40);
+   tm6000_set_reg_mask(core, TM6010_REQ07_RCC_ACTIVE_IF, 0x40, 0x40);
 
tm6000_set_audio_bitrate(core, 48000);
 
@@ -98,7 +98,7 @@ static int _tm6000_stop_audio_dma(struct snd_tm6000_card 
*chip)
dprintk(1, "Stopping audio DMA\n");
 
/* Disables audio */
-   tm6000_set_reg_mask(core, TM6010_REQ07_RCC_ACTIVE_VIDEO_IF, 0x00, 0x40);
+   tm6000_set_reg_mask(core, TM6010_REQ07_RCC_ACTIVE_IF, 0x00, 0x40);
 
return 0;
 }
diff --git a/drivers/staging/tm6000/tm6000-core.c 
b/drivers/staging/tm6000/tm6000-core.c
index 2c156dd..2117f8e 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@ -184,11 +184,11 @@ void tm6000_set_fourcc_format(struct tm6000_core *dev)
if (dev->dev_type == TM6010) {
int val;
 
-   val = tm6000_get_reg(dev, TM6010_REQ07_RCC_ACTIVE_VIDEO_IF, 0) 
& 0xfc;
+   val = tm6000_get_reg(dev, TM6010_REQ07_RCC_ACTIVE_IF, 0) & 0xfc;
if (dev->fourcc == V4L2_PIX_FMT_UYVY)
-   tm6000_set_reg(dev, TM6010_REQ07_RCC_ACTIVE_VIDEO_IF, 
val);
+   tm6000_set_reg(dev, TM6010_REQ07_RCC_ACTIVE_IF, val);
else
-   tm6000_set_reg(dev, TM6010_REQ07_RCC_ACTIVE_VIDEO_IF, 
val | 1);
+   tm6000_set_reg(dev, TM6010_REQ07_RCC_ACTIVE_IF, val | 
1);
} else {
if (dev->fourcc == V4L2_PIX_FMT_UYVY)
tm6000_set_reg(dev, TM6010_REQ07_RC1_TRESHOLD, 0xd0);
@@ -265,7 +265,7 @@ int tm6000_init_analog_mode(struct tm6000_core *dev)
 
if (dev->dev_type == TM6010) {
/* Enable video and audio */
-   tm6000_set_reg_mask(dev, TM6010_REQ07_RCC_ACTIVE_VIDEO_IF,
+   tm6000_set_reg_mask(dev, TM6010_REQ07_RCC_ACTIVE_IF,
0x60, 0x60);
/* Disable TS input */
tm6000_set_reg_mask(dev, TM6010_REQ07_RC0_ACTIVE_VIDEO_SOURCE,
@@ -331,7 +331,7 @@ int tm6000_init_digital_mode(struct tm6000_core *dev)
 {
if (dev->dev_type == TM6010) {
/* Disable video and audio */
-   tm6000_set_reg_mask(dev, TM6010_REQ07_RCC_ACTIVE_VIDEO_IF,
+   tm6000_set_reg_mask(dev, TM6010_REQ07_RCC_ACTIVE_IF,
0x00, 0x60);
/* Enable TS input */
tm6000_set_reg_mask(dev, TM6010_REQ07_RC0_ACTIVE_VIDEO_SOURCE,
@@ -459,7 +459,7 @@ static struct reg_init tm6010_init_tab[] = {
{ TM6010_REQ07_RC4_HSTART0, 0xa0 },
{ TM6010_REQ07_RC6_HEND0, 0x40 },
{ TM6010_REQ07_RCA_VEND0, 0x31 },
-   { TM6010_REQ07_RCC_ACTIVE_VIDEO_IF, 0xe1 },
+   { TM6010_REQ07_RCC_ACTIVE_IF, 0xe1 },
{ TM6010_REQ07_RE0_DVIDEO_SOURCE, 0x03 },
{ TM6010_REQ07_RFE_POWER_DOWN, 0x7f },
 
diff --git a/drivers/staging/tm6000/tm6000-regs.h 
b/drivers/staging/tm6000/tm6000-regs.h
index 5375a83..6e4ef95 100644
--- a/drivers/staging/tm6000/tm6000-regs.h
+++ b/drivers/staging/tm6000/tm6000-regs.h
@@ -270,7 +270,9 @@ enum {
 #define TM6010_REQ07_RCA_VEND0 0x07, 0xca
 #define TM6010_REQ07_RCB_DELAY 0x07, 0xcb
 /* ONLY for TM6010 */
-#define TM6010_REQ07_RCC_ACTIVE_VIDEO_IF   0x07, 0xcc
+#define TM6010_REQ07_RCC_ACTIVE_IF 0x07, 0xcc
+#define TM6010_REQ07_RCC_ACTIVE_IF_VIDEO_ENABLE (1 << 5)
+#define TM6010_REQ07_RCC_ACTIVE_IF_AUDIO_ENABLE (1 << 6)
 #define TM6010_REQ07_RD0_USB_PERIPHERY_CONTROL 0x07, 0xd0
 #define TM6010_REQ07_RD1_ADDR_FOR_REQ1 0x07, 0xd1
 #define TM6010_REQ07_RD2_ADDR_FOR_REQ2 0x07, 0xd2
-- 
1.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 06/21] [staging] tm6000: Increase maximum I2C packet size.

[Thierry Reding]

The TM6010 supports much larger I2C transfers than currently specified.
In fact the Windows driver seems to use 81 bytes per packet by default.
This commit improves the speed of firmware loading a bit.
---
 drivers/staging/tm6000/tm6000-cards.c |1 +
 drivers/staging/tm6000/tm6000-i2c.c   |2 +-
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000-cards.c 
b/drivers/staging/tm6000/tm6000-cards.c
index c3b84c9..a5d2a71 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -929,6 +929,7 @@ static void tm6000_config_tuner(struct tm6000_core *dev)
memset(&ctl, 0, sizeof(ctl));
 
ctl.demod = XC3028_FE_ZARLINK456;
+   ctl.max_len = 81;
 
xc2028_cfg.tuner = TUNER_XC2028;
xc2028_cfg.priv  = &ctl;
diff --git a/drivers/staging/tm6000/tm6000-i2c.c 
b/drivers/staging/tm6000/tm6000-i2c.c
index 21cd9f8..2cb7573 100644
--- a/drivers/staging/tm6000/tm6000-i2c.c
+++ b/drivers/staging/tm6000/tm6000-i2c.c
@@ -50,7 +50,7 @@ static int tm6000_i2c_send_regs(struct tm6000_core *dev, 
unsigned char addr,
unsigned int i2c_packet_limit = 16;
 
if (dev->dev_type == TM6010)
-   i2c_packet_limit = 64;
+   i2c_packet_limit = 256;
 
if (!buf)
return -1;
-- 
1.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 05/21] [staging] tm6000: Implement I2C flush callback.

[Thierry Reding]

---
 drivers/staging/tm6000/tm6000-cards.c |5 +
 drivers/staging/tm6000/tm6000-i2c.c   |5 -
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000-cards.c 
b/drivers/staging/tm6000/tm6000-cards.c
index 202f454..c3b84c9 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -781,6 +781,11 @@ int tm6000_tuner_callback(void *ptr, int component, int 
command, int arg)
rc = tm6000_i2c_reset(dev, 100);
break;
}
+   break;
+   case XC2028_I2C_FLUSH:
+   tm6000_set_reg(dev, REQ_50_SET_START, 0, 0);
+   tm6000_set_reg(dev, REQ_51_SET_STOP, 0, 0);
+   break;
}
return rc;
 }
diff --git a/drivers/staging/tm6000/tm6000-i2c.c 
b/drivers/staging/tm6000/tm6000-i2c.c
index 8828c12..21cd9f8 100644
--- a/drivers/staging/tm6000/tm6000-i2c.c
+++ b/drivers/staging/tm6000/tm6000-i2c.c
@@ -219,11 +219,6 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
printk(" %02x", msgs[i].buf[byte]);
rc = tm6000_i2c_send_regs(dev, addr, msgs[i].buf[0],
msgs[i].buf + 1, msgs[i].len - 1);
-
-   if (addr == dev->tuner_addr  << 1) {
-   tm6000_set_reg(dev, REQ_50_SET_START, 0, 0);
-   tm6000_set_reg(dev, REQ_51_SET_STOP, 0, 0);
-   }
}
if (i2c_debug >= 2)
printk("\n");
-- 
1.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 08/21] [staging] tm6000: Flesh out the IRQ callback.

[Thierry Reding]

This brings the IRQ callback implementation more in line with how other
drivers do it.
---
 drivers/staging/tm6000/tm6000-video.c |   14 +-
 1 files changed, 13 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000-video.c 
b/drivers/staging/tm6000/tm6000-video.c
index e0cd512..4b50f6c 100644
--- a/drivers/staging/tm6000/tm6000-video.c
+++ b/drivers/staging/tm6000/tm6000-video.c
@@ -517,9 +517,21 @@ static void tm6000_irq_callback(struct urb *urb)
struct tm6000_core *dev = container_of(dma_q, struct tm6000_core, vidq);
int i;
 
-   if (!dev)
+   switch (urb->status) {
+   case 0:
+   case -ETIMEDOUT:
+   break;
+
+   case -ECONNRESET:
+   case -ENOENT:
+   case -ESHUTDOWN:
return;
 
+   default:
+   tm6000_err("urb completion error %d.\n", urb->status);
+   break;
+   }
+
spin_lock(&dev->slock);
tm6000_isoc_copy(urb);
spin_unlock(&dev->slock);
-- 
1.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 07/21] [staging] tm6000: Remove artificial delay.

[Thierry Reding]

---
 drivers/staging/tm6000/tm6000-core.c |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000-core.c 
b/drivers/staging/tm6000/tm6000-core.c
index e14bd3d..2c156dd 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@ -86,9 +86,6 @@ int tm6000_read_write_usb(struct tm6000_core *dev, u8 
req_type, u8 req,
}
 
kfree(data);
-
-   msleep(5);
-
return ret;
 }
 
-- 
1.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 03/21] [staging] tm6000: Miscellaneous cleanups.

[Thierry Reding]

This commit fixes a number of coding style issues as well as some issues
reported by checkpatch and sparse.
---
 drivers/staging/tm6000/tm6000-alsa.c  |4 +-
 drivers/staging/tm6000/tm6000-cards.c |   18 ++---
 drivers/staging/tm6000/tm6000-core.c  |   17 ++---
 drivers/staging/tm6000/tm6000-dvb.c   |   14 ++--
 drivers/staging/tm6000/tm6000-input.c |2 +-
 drivers/staging/tm6000/tm6000-stds.c  |3 +-
 drivers/staging/tm6000/tm6000-video.c |  125 +++--
 drivers/staging/tm6000/tm6000.h   |4 -
 8 files changed, 83 insertions(+), 104 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000-alsa.c 
b/drivers/staging/tm6000/tm6000-alsa.c
index 2b96047..768d713 100644
--- a/drivers/staging/tm6000/tm6000-alsa.c
+++ b/drivers/staging/tm6000/tm6000-alsa.c
@@ -401,7 +401,7 @@ static struct snd_pcm_ops snd_tm6000_pcm_ops = {
 /*
  * Alsa Constructor - Component probe
  */
-int tm6000_audio_init(struct tm6000_core *dev)
+static int tm6000_audio_init(struct tm6000_core *dev)
 {
struct snd_card *card;
struct snd_tm6000_card  *chip;
@@ -494,7 +494,7 @@ static int tm6000_audio_fini(struct tm6000_core *dev)
return 0;
 }
 
-struct tm6000_ops audio_ops = {
+static struct tm6000_ops audio_ops = {
.type   = TM6000_AUDIO,
.name   = "TM6000 Audio Extension",
.init   = tm6000_audio_init,
diff --git a/drivers/staging/tm6000/tm6000-cards.c 
b/drivers/staging/tm6000/tm6000-cards.c
index a69c82e..202f454 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -88,7 +88,7 @@ struct tm6000_board {
char*ir_codes;
 };
 
-struct tm6000_board tm6000_boards[] = {
+static struct tm6000_board tm6000_boards[] = {
[TM6000_BOARD_UNKNOWN] = {
.name = "Unknown tm6000 video grabber",
.caps = {
@@ -395,7 +395,7 @@ struct tm6000_board tm6000_boards[] = {
.has_zl10353= 1,
.has_eeprom = 1,
.has_remote = 1,
-   .has_radio  = 1.
+   .has_radio  = 1,
},
.gpio = {
.tuner_reset= TM6010_GPIO_0,
@@ -612,7 +612,7 @@ struct tm6000_board tm6000_boards[] = {
 };
 
 /* table of devices that work with this driver */
-struct usb_device_id tm6000_id_table[] = {
+static struct usb_device_id tm6000_id_table[] = {
{ USB_DEVICE(0x6000, 0x0001), .driver_info = TM5600_BOARD_GENERIC },
{ USB_DEVICE(0x6000, 0x0002), .driver_info = TM6010_BOARD_GENERIC },
{ USB_DEVICE(0x06e1, 0xf332), .driver_info = 
TM6000_BOARD_ADSTECH_DUAL_TV },
@@ -633,7 +633,7 @@ struct usb_device_id tm6000_id_table[] = {
{ USB_DEVICE(0x13d3, 0x3264), .driver_info = TM6010_BOARD_TWINHAN_TU501 
},
{ USB_DEVICE(0x6000, 0xdec2), .driver_info = 
TM6010_BOARD_BEHOLD_WANDER_LITE },
{ USB_DEVICE(0x6000, 0xdec3), .driver_info = 
TM6010_BOARD_BEHOLD_VOYAGER_LITE },
-   { },
+   { }
 };
 
 /* Control power led for show some activity */
@@ -788,8 +788,6 @@ EXPORT_SYMBOL_GPL(tm6000_tuner_callback);
 
 int tm6000_cards_setup(struct tm6000_core *dev)
 {
-   int i, rc;
-
/*
 * Board-specific initialization sequence. Handles all GPIO
 * initialization sequences that are board-specific.
@@ -861,6 +859,9 @@ int tm6000_cards_setup(struct tm6000_core *dev)
 */
 
if (dev->gpio.tuner_reset) {
+   int rc;
+   int i;
+
for (i = 0; i < 2; i++) {
rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
dev->gpio.tuner_reset, 0x00);
@@ -1173,7 +1174,7 @@ static int tm6000_usb_probe(struct usb_interface 
*interface,
snprintf(dev->name, 29, "tm6000 #%d", nr);
 
dev->model = id->driver_info;
-   if ((card[nr] >= 0) && (card[nr] < ARRAY_SIZE(tm6000_boards)))
+   if (card[nr] < ARRAY_SIZE(tm6000_boards))
dev->model = card[nr];
 
dev->udev = usbdev;
@@ -1194,8 +1195,6 @@ static int tm6000_usb_probe(struct usb_interface 
*interface,
speed = "unknown";
}
 
-
-
/* Get endpoints */
for (i = 0; i < interface->num_altsetting; i++) {
int ep;
@@ -1279,7 +1278,6 @@ static int tm6000_usb_probe(struct usb_interface 
*interface,
printk(KERN_INFO "tm6000: Found %s\n", tm6000_boards[dev->model].name);
 
rc = tm6000_init_dev(dev);
-
if (rc < 0)
goto err;
 
diff --git a/drivers/staging/tm6000/tm6000-core.c 
b/drivers/staging/tm6000/tm6000-core.c
index d7eb2e2..e14bd3d 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@ -42,7 +42,6 @@ int tm6000_read_write_usb(struct tm6000_core *dev, u8 
req_type, u8 req,
if (len)
data = kzalloc(len, GFP_KERNEL);
 

[PATCH 04/21] [staging] tm6000: Use correct input in radio mode.

[Thierry Reding]

In radio mode, the correct input is rinput. The pseudo index 5 is used
but cannot be used to index the vinput array because that only has 3
elements.
---
 drivers/staging/tm6000/tm6000-stds.c |   28 +++-
 1 files changed, 15 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000-stds.c 
b/drivers/staging/tm6000/tm6000-stds.c
index bebf1f3..cd69626 100644
--- a/drivers/staging/tm6000/tm6000-stds.c
+++ b/drivers/staging/tm6000/tm6000-stds.c
@@ -525,6 +525,7 @@ static int tm6000_load_std(struct tm6000_core *dev,
 
 int tm6000_set_standard(struct tm6000_core *dev)
 {
+   struct tm6000_input *input;
int i, rc = 0;
u8 reg_07_fe = 0x8a;
u8 reg_08_f1 = 0xfc;
@@ -533,12 +534,13 @@ int tm6000_set_standard(struct tm6000_core *dev)
 
tm6000_get_std_res(dev);
 
-   if (dev->radio) {
-   /* todo */
-   }
+   if (!dev->radio)
+   input = &dev->vinput[dev->input];
+   else
+   input = &dev->rinput;
 
if (dev->dev_type == TM6010) {
-   switch (dev->vinput[dev->input].vmux) {
+   switch (input->vmux) {
case TM6000_VMUX_VIDEO_A:
tm6000_set_reg(dev, TM6010_REQ08_RE3_ADC_IN1_SEL, 0xf4);
tm6000_set_reg(dev, TM6010_REQ08_REA_BUFF_DRV_CTRL, 
0xf1);
@@ -567,7 +569,7 @@ int tm6000_set_standard(struct tm6000_core *dev)
default:
break;
}
-   switch (dev->vinput[dev->input].amux) {
+   switch (input->amux) {
case TM6000_AMUX_ADC1:
tm6000_set_reg_mask(dev, 
TM6010_REQ08_RF0_DAUDIO_INPUT_CONFIG,
0x00, 0x0f);
@@ -602,32 +604,32 @@ int tm6000_set_standard(struct tm6000_core *dev)
tm6000_set_reg(dev, TM6010_REQ08_RF1_AADC_POWER_DOWN, 
reg_08_f1);
tm6000_set_reg(dev, TM6010_REQ07_RFE_POWER_DOWN, reg_07_fe);
} else {
-   switch (dev->vinput[dev->input].vmux) {
+   switch (input->vmux) {
case TM6000_VMUX_VIDEO_A:
tm6000_set_reg(dev, TM6000_REQ07_RE3_VADC_INP_LPF_SEL1, 
0x10);
tm6000_set_reg(dev, TM6000_REQ07_RE5_VADC_INP_LPF_SEL2, 
0x00);
tm6000_set_reg(dev, TM6000_REQ07_RE8_VADC_PWDOWN_CTL, 
0x0f);
tm6000_set_reg(dev,
-   REQ_03_SET_GET_MCU_PIN, 
dev->vinput[dev->input].v_gpio, 0);
+   REQ_03_SET_GET_MCU_PIN, input->v_gpio, 0);
break;
case TM6000_VMUX_VIDEO_B:
tm6000_set_reg(dev, TM6000_REQ07_RE3_VADC_INP_LPF_SEL1, 
0x00);
tm6000_set_reg(dev, TM6000_REQ07_RE5_VADC_INP_LPF_SEL2, 
0x00);
tm6000_set_reg(dev, TM6000_REQ07_RE8_VADC_PWDOWN_CTL, 
0x0f);
tm6000_set_reg(dev,
-   REQ_03_SET_GET_MCU_PIN, 
dev->vinput[dev->input].v_gpio, 0);
+   REQ_03_SET_GET_MCU_PIN, input->v_gpio, 0);
break;
case TM6000_VMUX_VIDEO_AB:
tm6000_set_reg(dev, TM6000_REQ07_RE3_VADC_INP_LPF_SEL1, 
0x10);
tm6000_set_reg(dev, TM6000_REQ07_RE5_VADC_INP_LPF_SEL2, 
0x10);
tm6000_set_reg(dev, TM6000_REQ07_RE8_VADC_PWDOWN_CTL, 
0x00);
tm6000_set_reg(dev,
-   REQ_03_SET_GET_MCU_PIN, 
dev->vinput[dev->input].v_gpio, 1);
+   REQ_03_SET_GET_MCU_PIN, input->v_gpio, 1);
break;
default:
break;
}
-   switch (dev->vinput[dev->input].amux) {
+   switch (input->amux) {
case TM6000_AMUX_ADC1:
tm6000_set_reg_mask(dev,
TM6000_REQ07_REB_VADC_AADC_MODE, 0x00, 0x0f);
@@ -640,7 +642,7 @@ int tm6000_set_standard(struct tm6000_core *dev)
break;
}
}
-   if (dev->vinput[dev->input].type == TM6000_INPUT_SVIDEO) {
+   if (input->type == TM6000_INPUT_SVIDEO) {
for (i = 0; i < ARRAY_SIZE(svideo_stds); i++) {
if (dev->norm & svideo_stds[i].id) {
rc = tm6000_load_std(dev, svideo_stds[i].common,
@@ -668,8 +670,8 @@ ret:
return rc;
 
if ((dev->dev_type == TM6010) &&
-   ((dev->vinput[dev->input].amux == TM6000_AMUX_SIF1) ||
-   (dev->vinput[dev->input].amux == TM6000_AMUX_SIF2)))
+   ((input->amux == TM6000_AMUX_SIF1) ||
+   (input->amux == TM6000_AMUX_SIF2)))
tm6000_set_audio_std(dev);
 
msleep(40);
-- 
1.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-med

[PATCH 01/21] [media] tuner/xc2028: Add I2C flush callback.

[Thierry Reding]

When loading the firmware, complete each chunk by sending an I2C flush
command to the frontend. Some devices like the tm6000 seem to require
this to properly flush the I2C buffers.

The current code in tm6000 executes the flush command once after each
I2C transfer, which slows down the firmware loading especially when
loading large BASE type images.
---
 drivers/media/common/tuners/tuner-xc2028.c |7 +++
 drivers/media/common/tuners/tuner-xc2028.h |1 +
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/media/common/tuners/tuner-xc2028.c 
b/drivers/media/common/tuners/tuner-xc2028.c
index 16fba6b..b6b2868 100644
--- a/drivers/media/common/tuners/tuner-xc2028.c
+++ b/drivers/media/common/tuners/tuner-xc2028.c
@@ -614,6 +614,13 @@ static int load_firmware(struct dvb_frontend *fe, unsigned 
int type,
p += len;
size -= len;
}
+
+   /* silently fail if the frontend doesn't support I2C flush */
+   rc = do_tuner_callback(fe, XC2028_I2C_FLUSH, 0);
+   if ((rc < 0) && (rc != -EINVAL)) {
+   tuner_err("error executing flush: %d\n", rc);
+   return rc;
+   }
}
return 0;
 }
diff --git a/drivers/media/common/tuners/tuner-xc2028.h 
b/drivers/media/common/tuners/tuner-xc2028.h
index 9778c96..9ebfb2d 100644
--- a/drivers/media/common/tuners/tuner-xc2028.h
+++ b/drivers/media/common/tuners/tuner-xc2028.h
@@ -54,6 +54,7 @@ struct xc2028_config {
 /* xc2028 commands for callback */
 #define XC2028_TUNER_RESET 0
 #define XC2028_RESET_CLK   1
+#define XC2028_I2C_FLUSH   2
 
 #if defined(CONFIG_MEDIA_TUNER_XC2028) || 
(defined(CONFIG_MEDIA_TUNER_XC2028_MODULE) && defined(MODULE))
 extern struct dvb_frontend *xc2028_attach(struct dvb_frontend *fe,
-- 
1.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 02/21] [media] tuner/xc2028: Fix frequency offset for radio mode.

[Thierry Reding]

In radio mode, no frequency offset is needed. While at it, split off the
frequency offset computation for digital TV into a separate function.
---
 drivers/media/common/tuners/tuner-xc2028.c |  137 +++-
 1 files changed, 75 insertions(+), 62 deletions(-)

diff --git a/drivers/media/common/tuners/tuner-xc2028.c 
b/drivers/media/common/tuners/tuner-xc2028.c
index b6b2868..8e53e5e 100644
--- a/drivers/media/common/tuners/tuner-xc2028.c
+++ b/drivers/media/common/tuners/tuner-xc2028.c
@@ -913,6 +913,66 @@ ret:
 
 #define DIV 15625
 
+static u32 digital_freq_offset(struct xc2028_data *priv, u32 freq)
+{
+   u32 offset = 0;
+
+   /*
+* Adjust to the center frequency. This is calculated by the
+* formula: offset = 1.25MHz - BW/2
+* For DTV 7/8, the firmware uses BW = 8000, so it needs a
+* further adjustment to get the frequency center on VHF
+*/
+   if (priv->cur_fw.type & DTV6)
+   offset = 175;
+   else if (priv->cur_fw.type & DTV7)
+   offset = 225;
+   else /* DTV8 or DTV78 */
+   offset = 275;
+
+   if ((priv->cur_fw.type & DTV78) && freq < 47000)
+   offset -= 50;
+
+   /*
+* xc3028 additional "magic"
+* Depending on the firmware version, it needs some adjustments
+* to properly centralize the frequency. This seems to be
+* needed to compensate the SCODE table adjustments made by
+* newer firmwares
+*/
+
+#if 1
+   /*
+* The proper adjustment would be to do it at s-code table.
+* However, this didn't work, as reported by
+* Robert Lowery 
+*/
+
+   if (priv->cur_fw.type & DTV7)
+   offset += 50;
+
+#else
+   /*
+* Still need tests for XC3028L (firmware 3.2 or upper)
+* So, for now, let's just comment the per-firmware
+* version of this change. Reports with xc3028l working
+* with and without the lines bellow are welcome
+*/
+
+   if (priv->firm_version < 0x0302) {
+   if (priv->cur_fw.type & DTV7)
+   offset += 50;
+   } else {
+   if (priv->cur_fw.type & DTV7)
+   offset -= 30;
+   else if (type != ATSC) /* DVB @6MHz, DTV 8 and DTV 7/8 */
+   offset += 20;
+   }
+#endif
+
+   return offset;
+}
+
 static int generic_set_freq(struct dvb_frontend *fe, u32 freq /* in HZ */,
enum v4l2_tuner_type new_type,
unsigned int type,
@@ -933,75 +993,28 @@ static int generic_set_freq(struct dvb_frontend *fe, u32 
freq /* in HZ */,
if (check_firmware(fe, type, std, int_freq) < 0)
goto ret;
 
-   /* On some cases xc2028 can disable video output, if
-* very weak signals are received. By sending a soft
-* reset, this is re-enabled. So, it is better to always
-* send a soft reset before changing channels, to be sure
-* that xc2028 will be in a safe state.
-* Maybe this might also be needed for DTV.
-*/
-   if (new_type == V4L2_TUNER_ANALOG_TV) {
+   switch (new_type) {
+   case V4L2_TUNER_ANALOG_TV:
+   /* On some cases xc2028 can disable video output, if
+* very weak signals are received. By sending a soft
+* reset, this is re-enabled. So, it is better to always
+* send a soft reset before changing channels, to be sure
+* that xc2028 will be in a safe state.
+* Maybe this might also be needed for DTV.
+*/
rc = send_seq(priv, {0x00, 0x00});
-
+   /* fall through */
+   case V4L2_TUNER_RADIO:
/* Analog modes require offset = 0 */
-   } else {
+   break;
+   case V4L2_TUNER_DIGITAL_TV:
/*
 * Digital modes require an offset to adjust to the
 * proper frequency. The offset depends on what
 * firmware version is used.
 */
-
-   /*
-* Adjust to the center frequency. This is calculated by the
-* formula: offset = 1.25MHz - BW/2
-* For DTV 7/8, the firmware uses BW = 8000, so it needs a
-* further adjustment to get the frequency center on VHF
-*/
-   if (priv->cur_fw.type & DTV6)
-   offset = 175;
-   else if (priv->cur_fw.type & DTV7)
-   offset = 225;
-   else/* DTV8 or DTV78 */
-   offset = 275;
-   if ((priv->cur_fw.type & DTV78) && freq < 47000)
-   offset -= 50;
-
-   /*
-* xc3028 additional "magic"
-* Depending on the firmware v

[PATCH 00/21] [staging] tm6000: Assorted fixes and improvements.

[Thierry Reding]

This patch series fixes up some issues with the tm6000 driver. These
patches were tested with a Cinergy Hybrid XE which is the only one I
have access to, so it would be nice if someone with access to the other
supported devices could take this series for a test run.

Among the changes are several speed-ups for firmware loading, addition
of radio support for the Cinergy Hybrid XE and some memory leak fixes. I
was able to reproduce the behaviour documented in the README about the
device stopping to work for unknown reasons. Running tests with this
series applied no longer exposes the problem, so I have high hopes that
it's also fixed.

Thierry Reding (21):
  [media] tuner/xc2028: Add I2C flush callback.
  [media] tuner/xc2028: Fix frequency offset for radio mode.
  [staging] tm6000: Miscellaneous cleanups.
  [staging] tm6000: Use correct input in radio mode.
  [staging] tm6000: Implement I2C flush callback.
  [staging] tm6000: Increase maximum I2C packet size.
  [staging] tm6000: Remove artificial delay.
  [staging] tm6000: Flesh out the IRQ callback.
  [staging] tm6000: Rename active interface register.
  [staging] tm6000: Disable video interface in radio mode.
  [staging] tm6000: Rework standard register tables.
  [staging] tm6000: Add locking for USB transfers.
  [staging] tm6000: Properly count device usage.
  [staging] tm6000: Initialize isochronous transfers only once.
  [staging] tm6000: Execute lightweight reset on close.
  [staging] tm6000: Select interface on first open.
  [staging] tm6000: Do not use video buffers in radio mode.
  [staging] tm6000: Plug memory leak on PCM free.
  [staging] tm6000: Enable audio clock in radio mode.
  [staging] tm6000: Enable radio mode for Cinergy Hybrid XE.
  [staging] tm6000: Remove unnecessary workaround.

 drivers/media/common/tuners/tuner-xc2028.c |  144 ---
 drivers/media/common/tuners/tuner-xc2028.h |1 +
 drivers/staging/tm6000/tm6000-alsa.c   |9 +-
 drivers/staging/tm6000/tm6000-cards.c  |   35 +-
 drivers/staging/tm6000/tm6000-core.c   |  102 +++--
 drivers/staging/tm6000/tm6000-dvb.c|   14 +-
 drivers/staging/tm6000/tm6000-i2c.c|7 +-
 drivers/staging/tm6000/tm6000-input.c  |2 +-
 drivers/staging/tm6000/tm6000-regs.h   |4 +-
 drivers/staging/tm6000/tm6000-stds.c   |  642 ++--
 drivers/staging/tm6000/tm6000-video.c  |  188 +
 drivers/staging/tm6000/tm6000.h|6 +-
 12 files changed, 600 insertions(+), 554 deletions(-)

-- 
1.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html