Re: RFC: V4L2 driver for Qualcomm MSM camera.
Hi Shuzhen, On Tuesday 04 January 2011 03:37:10 Shuzhen Wang wrote: > On Tuesday, December 28, 2010 12:24 PM Laurent Pinchart wrote: > > > > I will strongly NAK any implementation that requires a daemon. > > We understand the motivation behind making the daemon optional. > However there are restrictions from legal perspective, which we > don't know how to get around. > > A simplest video streaming data flow with MSM ISP is like this: > > Sensor -> ISP Hardware pipeline -> videobuf > > The procedure to set up ISP pipeline is proprietary and cannot > be open sourced. Without proper pipeline configuration, streaming > won't work. And That's why we require the daemon. Then I'm afraid you simply won't be able to provide an open-source Linux driver. The purpose of a driver is to allow the system to access the hardware. Whether the code lives in the Linux kernel or in userspace is irrelevant here. If part of your driver is closed source, then it can't be called open-source and it can't be included in the mainline Linux kernel (there's a precedent on the same issue in the Direct Rendering Manager subsystem, open-source kernel code has been refused because it depended on closed-source userspace components). If you want your hardware supported in the mainline Linux kernel you have to play by the rules and provide a complete open-source driver. You need to sort it out with your legal department and get a green light on disclosing information on how to setup the ISP pipeline. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/32] v4l/cx18: update workqueue usage
Hello, On Mon, Jan 03, 2011 at 07:54:56PM -0500, Andy Walls wrote: > 2. To prevent work items being handled by keventd/n from being delayed > too long, as the deferred work in question can involve a bit of sleeping > due to contention, the workload of the CX23418's MPEG encoding engine, > and the number of CX23418 devices in the system. > > Will all the sleeping that can happen, is the move to a system wq, under > cmwq, going to have adverse affects on processing other work items in > the system? > > I get the feeling it won't be a problem with cmwq, but I haven't paid > enough attention to be sure. It won't be a problem. Now the system_wq supports parallel execution of multiple works and manages concurrency automatically. Work items can sleep as necessary without worrying about other work items. ... > It is not unusual for scheduled TV recording software to start nearly > simultaneous DTV TS, MPEG, and VBI or MPEG Index streams on multiple > cards. So 3 CX23418 cards with 3 streams each. Let's nominally > estimate the timing of the CX18_CPU_DE_SET_MDL commands per stream at > the PAL frame rate of 25 Hz; or 1 CX18_CPU_DE_SET_MDL mailbox command > per stream per 40 milliseconds. IIUC, if they spend any significant amount of time executing, they'll be doing so by waiting for events (mutex, IRQ...), right? If so, there's nothing to worry about. If it's gonna burn a lot of CPU cycles, we'll need to use a workqueue marked CPU_INTENSIVE but I don't think that's the case here. Thank you. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: V4L2 driver for Qualcomm MSM camera.
Hi Jeff, On Tuesday 04 January 2011 07:14:00 Haibo Zhong wrote: > On 1/3/2011 6:37 PM, Shuzhen Wang wrote: > > On Tuesday, December 28, 2010 12:24 PM Laurent Pinchart wrote: > >> > >> I will strongly NAK any implementation that requires a daemon. > > > > We understand the motivation behind making the daemon optional. > > However there are restrictions from legal perspective, which we > > don't know how to get around. > > > > A simplest video streaming data flow with MSM ISP is like this: > > > > Sensor -> ISP Hardware pipeline -> videobuf > > > > The procedure to set up ISP pipeline is proprietary and cannot > > be open sourced. Without proper pipeline configuration, streaming > > won't work. And That's why we require the daemon. > > Laurent/Hans/Mauro, > > We are working on and will provide more design information on Qualcomm > MSM ISP design and explain the legal concern of the daemon implementation. > > The underlined idea is to comply to V4L2 architecture with MSM solution. That's a good first step, but I'm afraid it's not enough. If you want your driver to be included in the mainline Linux kernel (and its derivative distribution kernels such as the MeeGo kernel for instance) all the code needed to access and use the hardware must be open-source. This of course doesn't preclude you from providing a closed-source userspace implementation of proprietary hardware-assisted image processing algorithms for instance (as a library or as a daemon). > In the meantime, Laurent, can you share with your major concern about the > Daemon? I have two concerns. - The daemon makes code required to use the hardware closed-source, making the driver closed-source (whether the kernel-side code is licensed under the GPL or not is irrelevant). I would have the exact same opinion if the required userspace proprietary code was provided as a library, so this concern is not specific to the implementation being in the form of a daemon. - The daemon makes the kernel-side driver architecture more complex for no reason. Assuming you can make all the driver open-source in the future and want to keep proprietary userspace image processing code closed-source, the driver architecture must not be designed solely to support that use case. The driver should be clean and lean, and the proprietary code must then come as a user of the driver, not the other way around. As a summary, having part of the driver closed-source is a no-go, and having part of the kernel driver API designed and used to support closed-source components only is a no-go as well. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: V4L2 driver for Qualcomm MSM camera.
> Hi Jeff, > > On Tuesday 04 January 2011 07:14:00 Haibo Zhong wrote: >> On 1/3/2011 6:37 PM, Shuzhen Wang wrote: >> > On Tuesday, December 28, 2010 12:24 PM Laurent Pinchart wrote: >> >> >> >> I will strongly NAK any implementation that requires a daemon. >> > >> > We understand the motivation behind making the daemon optional. >> > However there are restrictions from legal perspective, which we >> > don't know how to get around. >> > >> > A simplest video streaming data flow with MSM ISP is like this: >> > >> > Sensor -> ISP Hardware pipeline -> videobuf >> > >> > The procedure to set up ISP pipeline is proprietary and cannot >> > be open sourced. Without proper pipeline configuration, streaming >> > won't work. And That's why we require the daemon. >> >> Laurent/Hans/Mauro, >> >> We are working on and will provide more design information on Qualcomm >> MSM ISP design and explain the legal concern of the daemon >> implementation. >> >> The underlined idea is to comply to V4L2 architecture with MSM solution. > > That's a good first step, but I'm afraid it's not enough. If you want your > driver to be included in the mainline Linux kernel (and its derivative > distribution kernels such as the MeeGo kernel for instance) all the code > needed to access and use the hardware must be open-source. > > This of course doesn't preclude you from providing a closed-source > userspace > implementation of proprietary hardware-assisted image processing > algorithms > for instance (as a library or as a daemon). > >> In the meantime, Laurent, can you share with your major concern about >> the >> Daemon? > > I have two concerns. > > - The daemon makes code required to use the hardware closed-source, making > the > driver closed-source (whether the kernel-side code is licensed under the > GPL > or not is irrelevant). I would have the exact same opinion if the required > userspace proprietary code was provided as a library, so this concern is > not > specific to the implementation being in the form of a daemon. > > - The daemon makes the kernel-side driver architecture more complex for no > reason. Assuming you can make all the driver open-source in the future and > want to keep proprietary userspace image processing code closed-source, > the > driver architecture must not be designed solely to support that use case. > The > driver should be clean and lean, and the proprietary code must then come > as a > user of the driver, not the other way around. > > As a summary, having part of the driver closed-source is a no-go, and > having > part of the kernel driver API designed and used to support closed-source > components only is a no-go as well. I don't entirely understand the whole discussion: in Helsinki this was discussed extensively with Jeff Zhong and I thought we all agreed on how to implement the driver: using a libv4l plugin which communicates to a daemon for your proprietary ISP code. Also, the driver should work without any proprietary code (obviously with sub-optimal picture quality, but you should get something out of the hardware). The driver API should be well-documented when it comes to any custom ioctls/controls. This makes it possible for sufficiently motivated developers to write open source libv4l plugins. It was my understanding that the proprietary code was about determining the optimal ISP settings, not about getting the ISP hardware to work. Regards, Hans > > -- > Regards, > > Laurent Pinchart > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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] V4L2: WL1273 FM Radio: Replace ioctl with unlocked_ioctl.
Use unlocked_ioctl in v4l2_file_operations. The locking is
already in place.
Signed-off-by: Matti J. Aaltonen
---
drivers/media/radio/radio-wl1273.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/radio/radio-wl1273.c
b/drivers/media/radio/radio-wl1273.c
index 1813790..d6c2099 100644
--- a/drivers/media/radio/radio-wl1273.c
+++ b/drivers/media/radio/radio-wl1273.c
@@ -1408,7 +1408,7 @@ static const struct v4l2_file_operations wl1273_fops = {
.read = wl1273_fm_fops_read,
.write = wl1273_fm_fops_write,
.poll = wl1273_fm_fops_poll,
- .ioctl = video_ioctl2,
+ .unlocked_ioctl = video_ioctl2,
.open = wl1273_fm_fops_open,
.release= wl1273_fm_fops_release,
};
--
1.6.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: V4L2 driver for Qualcomm MSM camera.
Hello, Shuzhen Wang wrote: >> -Original Message- >> From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] >> Sent: Tuesday, December 28, 2010 12:24 PM >> To: Shuzhen Wang >> Cc: 'Mauro Carvalho Chehab'; 'Hans Verkuil'; linux- >> me...@vger.kernel.org; hzh...@codeaurora.org; Yan, Yupeng >> Subject: Re: RFC: V4L2 driver for Qualcomm MSM camera. >> >> I will strongly NAK any implementation that requires a daemon. >> > > We understand the motivation behind making the daemon optional. > However there are restrictions from legal perspective, which we > don't know how to get around. > > A simplest video streaming data flow with MSM ISP is like this: > > Sensor -> ISP Hardware pipeline -> videobuf > > The procedure to set up ISP pipeline is proprietary and cannot > be open sourced. Without proper pipeline configuration, streaming > won't work. And That's why we require the daemon. Why not? In my opinion the pipeline configuration is quite basic functionality present also in the OMAP3 ISP, for example. This should be available through the Media controller interface. In general, the driver should expose APIs best suited for configuring the ISP hardware. Existing APIs should be used as much as possible. There should be no untyped blob passing in its API. Regards, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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: [REGRESSION: wm8775, ivtv] Please revert commit fcb9757333df37cf4a7feccef7ef6f5300643864
On Tue, 2011-01-04 at 08:10 +0100, Hans Verkuil wrote: > On Monday, January 03, 2011 23:34:16 Andy Walls wrote: > > On Sun, 2011-01-02 at 23:00 -0500, Eric Sharkey wrote: > > > On Fri, Dec 31, 2010 at 7:55 PM, Andy Walls > > > wrote: > > > > Mauro, > > > > > > > > Please revert at least the wm8775.c portion of commit > > > > fcb9757333df37cf4a7feccef7ef6f5300643864: > > > > > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fcb9757333df37cf4a7feccef7ef6f5300643864 > > > > > > > > It completely trashes baseband line-in audio for PVR-150 cards, and > > > > likely does the same for any other ivtv card that has a WM8775 chip. > > > > > > Confirmed. I manually rolled back most of the changes in that commit > > > for wm8775.c, leaving all other files alone, and the audio is now > > > working correctly for me. I haven't yet narrowed it down to exactly > > > which changes in that file cause the problem. I'll try and do that > > > tomorrow if I have time. > > > > This might help then: > > > > http://dl.ivtvdriver.org/datasheets/audio/WM8775.pdf > > > > I don't have time to look, but I'm hoping it is just the initialization > > in wm8775_probe(). > > > > Without both a PVR-150 card and a Nova-S-plus DVB-S with which to test > > you are unlikely to get an initialization that works for both the Nova-S > > Plus and PVR-150. Even if you did, such a configuration would be > > "fragile" in that it will be hard to tweak in the future for one card > > without breaking the other. (Code reuse doesn't work out too well for > > setting up hardware parameters.) > > > > The fix will probably have to use some context sensitive initialization > > in wm8775_probe(): "Am I being called by ivtv for a PVR-150 or cx88 for > > a Nova-S plus?" > > > > Which probably means: > > > > 1. adding a ".s_config" method to the "wm8775_core_ops" > > See: > > http://git.linuxtv.org/media_tree.git?a=blob;f=Documentation/video4linux/v4l2-framework.txt;h=f22f35c271f38d34fda0c19d8942b536e2fc95d9;hb=staging/for_v2.6.38#l206 > > http://git.linuxtv.org/media_tree.git?a=blob;f=include/media/v4l2-subdev.h;h=b0316a7cf08d21f2ac68f1dc452894441948c155;hb=staging/for_v2.6.38#l109 > > http://git.linuxtv.org/media_tree.git?a=blob;f=include/media/v4l2-subdev.h;h=b0316a7cf08d21f2ac68f1dc452894441948c155;hb=staging/for_v2.6.38#l141 > > Don't use .s_config! That will be removed soon. > > Use platform_data and v4l2_i2c_new_subdev_board instead. Gah! Sorry. I knew that .init had been deprecated. The comments in v4l2_subdev.h indicate that .init is deprecated, but do not do the same for .s_config. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/32] v4l/cx18: update workqueue usage
On Tue, 2011-01-04 at 09:36 +0100, Tejun Heo wrote: > Hello, > > On Mon, Jan 03, 2011 at 07:54:56PM -0500, Andy Walls wrote: > > 2. To prevent work items being handled by keventd/n from being delayed > > too long, as the deferred work in question can involve a bit of sleeping > > due to contention, the workload of the CX23418's MPEG encoding engine, > > and the number of CX23418 devices in the system. > > > > Will all the sleeping that can happen, is the move to a system wq, under > > cmwq, going to have adverse affects on processing other work items in > > the system? > > > > I get the feeling it won't be a problem with cmwq, but I haven't paid > > enough attention to be sure. > > It won't be a problem. Now the system_wq supports parallel execution > of multiple works and manages concurrency automatically. Work items > can sleep as necessary without worrying about other work items. OK, that's what I thought. I just wanted to ensure that busy CX23418 chips are not going to delay the processing of other work-events in the rest the system down. > ... > > It is not unusual for scheduled TV recording software to start nearly > > simultaneous DTV TS, MPEG, and VBI or MPEG Index streams on multiple > > cards. So 3 CX23418 cards with 3 streams each. Let's nominally > > estimate the timing of the CX18_CPU_DE_SET_MDL commands per stream at > > the PAL frame rate of 25 Hz; or 1 CX18_CPU_DE_SET_MDL mailbox command > > per stream per 40 milliseconds. > > IIUC, if they spend any significant amount of time executing, they'll > be doing so by waiting for events (mutex, IRQ...), right? Right. As a CX23418 is expected to do more streaming by the host, the mailbox mutex contention goes up and the latency of the CX23418 responding to mailbox commands also goes up so there is more wait()ing. > If so, > there's nothing to worry about. If it's gonna burn a lot of CPU > cycles, we'll need to use a workqueue marked CPU_INTENSIVE but I don't > think that's the case here. Correct, CPU is not the concern here. > Thank you. Thanks. I'll do a proper inspection of the patch tonight. It looked OK on cursory review. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: Pinnacle PCTV USB2 working with PAL-Nc
Hi Gonzalo the other list is deprecated, I'm forwarding your mail. -- Forwarded message -- From: "Gonzalo A. de la Vega" Date: Tue, 4 Jan 2011 09:40:18 -0300 Subject: Pinnacle PCTV USB2 working with PAL-Nc To: video4linux-l...@redhat.com Hi all, I live in Argentina and I have a Pinnacle PCTV USB2. We use PAL-Nc (no other country does AFAIK) and I couldn't get the device to show a colored image. Actually there was no image when PAL-Nc was selected and BW only with PAL. It turns that this device uses (just to remind you) a TDA9887 tuner (IF-PLL demodulator), an SAA7113 input processor and a EM2820 capture device. The problem was that the TDA9887 is being set incorrectly. I'm not quiet sure what the justification is, but I started from the point that I should at least see the same B&W image I saw with PAL, so I just went with trial and error (two trials, one error). The whole diff would be: cut here-- 178c178 < cVideoIF_45_75 ), --- > cVideoIF_38_90 ), cut here-- I only have the Pinnalce PCTV, so probably someone else (from Argentina) could try with another device using the TDA9887 before submitting a patch. Cheers, Gonzalo -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-requ...@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list -- Adrian. http://ovejafm.com http://elesquinazotango.com.ar -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: V4L2 driver for Qualcomm MSM camera.
Em 04-01-2011 08:40, Hans Verkuil escreveu: >> Hi Jeff, >> >> On Tuesday 04 January 2011 07:14:00 Haibo Zhong wrote: >>> On 1/3/2011 6:37 PM, Shuzhen Wang wrote: On Tuesday, December 28, 2010 12:24 PM Laurent Pinchart wrote: > > I will strongly NAK any implementation that requires a daemon. We understand the motivation behind making the daemon optional. However there are restrictions from legal perspective, which we don't know how to get around. A simplest video streaming data flow with MSM ISP is like this: Sensor -> ISP Hardware pipeline -> videobuf The procedure to set up ISP pipeline is proprietary and cannot be open sourced. Without proper pipeline configuration, streaming won't work. And That's why we require the daemon. >>> >>> Laurent/Hans/Mauro, >>> >>> We are working on and will provide more design information on Qualcomm >>> MSM ISP design and explain the legal concern of the daemon >>> implementation. >>> >>> The underlined idea is to comply to V4L2 architecture with MSM solution. >> >> That's a good first step, but I'm afraid it's not enough. If you want your >> driver to be included in the mainline Linux kernel (and its derivative >> distribution kernels such as the MeeGo kernel for instance) all the code >> needed to access and use the hardware must be open-source. >> >> This of course doesn't preclude you from providing a closed-source >> userspace >> implementation of proprietary hardware-assisted image processing >> algorithms >> for instance (as a library or as a daemon). >> >>> In the meantime, Laurent, can you share with your major concern about >>> the >>> Daemon? >> >> I have two concerns. >> >> - The daemon makes code required to use the hardware closed-source, making >> the >> driver closed-source (whether the kernel-side code is licensed under the >> GPL >> or not is irrelevant). I would have the exact same opinion if the required >> userspace proprietary code was provided as a library, so this concern is >> not >> specific to the implementation being in the form of a daemon. >> >> - The daemon makes the kernel-side driver architecture more complex for no >> reason. Assuming you can make all the driver open-source in the future and >> want to keep proprietary userspace image processing code closed-source, >> the >> driver architecture must not be designed solely to support that use case. >> The >> driver should be clean and lean, and the proprietary code must then come >> as a >> user of the driver, not the other way around. >> >> As a summary, having part of the driver closed-source is a no-go, and >> having >> part of the kernel driver API designed and used to support closed-source >> components only is a no-go as well. > > I don't entirely understand the whole discussion: in Helsinki this was > discussed extensively with Jeff Zhong and I thought we all agreed on how > to implement the driver: using a libv4l plugin which communicates to a > daemon for your proprietary ISP code. I also had the same understanding from Helsinki's meeting. > Also, the driver should work without any proprietary code (obviously with > sub-optimal picture quality, but you should get something out of the > hardware). The driver API should be well-documented when it comes to any > custom ioctls/controls. This makes it possible for sufficiently motivated > developers to write open source libv4l plugins. It was my understanding > that the proprietary code was about determining the optimal ISP settings, > not about getting the ISP hardware to work. Look: we don't mind if you have some daemon/library/userspace utils with some picture enhancement algorithm that you may have developed and have legal concerns to protect them. The best way for doing that is probably via libv4l, as other userspace apps will use it, but you can do whatever you want. However, the driver should be open source for being accepted upstream. In other words, all access to the hardware should be done via the open source driver, and using a public, well documented, kernel<=>userspace API. That means that any application should be able to use it, without requiring any daemon. So, it is OK if your driver have some well-documented ways to expose image statistics and some way to adjust the device parameters to enhance image quality, and have some proprietary, closed source daemon/library that will use those statistics to enhance the image. Of course, such driver, to be open, should allow someone to write a different code to do similar enhancements, as Hans pointed. That's said, I can't understand why you're afraid of doing that. Hardware initialization is very specific to a given hardware, and I don't see how open the initialization sequence for your hardware would cause any legal damage, or benefit your competitors: It is just a sequence of reads/writes. All drivers do it. The IP that you likely want to protect is the way you design your hardware and the i
AverTV Volar HD Pro (A835)
Good evening, at first I want to say thanks for your work in linux tv. Why I disturb you... I am working on driver for AverTV Volar HD PRO (A835), USB card for DVB-TV. At least, I am trying to make it. But still with no success. I know the chip, demodulator and tuner, but thats all. Everything I did, didnt helped. So I only want to ask you, if you ever have anything to do with this card? Or are you worked with it? I just cant make it working, so I will be glad for any hint. Sorry for disturbing, and thanks for replying. Regards, Michal Bojda. -- 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: Problem with em28xx driver in Gumstix Overo
Am Montag 03 Januar 2011 schrieb Devin Heitmueller: > On Mon, Jan 3, 2011 at 3:13 PM, Linus Torvalds > > wrote: > >> // if (!dev->progressive) > >> // height >>= norm_maxh(dev); > > This would suggest that the device is providing progressive video > and there is a mismatch between the board profile and the actual > hardware, which is certainly possible but I know absolutely > nothing about the product in question. > > It would be helpful if we could get the output of dmesg for > starters, so we can see which board profile is being used. This main problem seems to be similare to the problem I reportet on 2011-01-01 to the ML, subject: Silver Crest VG2000 "USB 2.0 Video Grabber", USB-Id: eb1a:2863 - does not work In the meantime the figures of the partikular device, including dmesg output, is been included in the linuxtv wiki as http://www.linuxtv.org/wiki/index.php/SilverCrest_USB_2.0_Video_Grabber_VG_2000 Best regards Martin -- "Was ist der Unterschied zwischen Franken und Oberbayern?" - "Die Franken haben weniger Berge, aber dafür mehr Horizont." -- 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: [PATCHv8 00/12] Contiguous Memory Allocator
> Russell King wrote: >> Has anyone addressed my issue with it that this is wide-open for >> abuse by allocating large chunks of memory, and then remapping >> them in some way with different attributes, thereby violating the >> ARM architecture specification? 2011/1/4 Johan MOSSBERG : > Where in the specification (preferably ARMv7) can I find > information about this? Is the problem that it is simply > forbidden to map an address multiple times with different cache > setting and if this is done the hardware might start failing? Or > is the problem that having an address mapped cached means that > speculative pre-fetch can read it into the cache at any time, > possibly causing problems if an un-cached mapping exists? IIRC both apply. -- 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: [PATCHv8 00/12] Contiguous Memory Allocator
Russell King wrote: > Has anyone addressed my issue with it that this is wide-open for > abuse by allocating large chunks of memory, and then remapping > them in some way with different attributes, thereby violating the > ARM architecture specification? I seem to have missed the previous discussion about this issue. Where in the specification (preferably ARMv7) can I find information about this? Is the problem that it is simply forbidden to map an address multiple times with different cache setting and if this is done the hardware might start failing? Or is the problem that having an address mapped cached means that speculative pre-fetch can read it into the cache at any time, possibly causing problems if an un-cached mapping exists? In my opinion option number two can be handled and I've made an attempt at doing that in hwmem (posted on linux-mm a while ago), look in cache_handler.c. Hwmem currently does not use cma but the next version probably will. /Johan Mossberg -- 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: [PATCHv8 00/12] Contiguous Memory Allocator
On Tue, Jan 04, 2011 at 05:23:37PM +0100, Johan MOSSBERG wrote: > Russell King wrote: > > Has anyone addressed my issue with it that this is wide-open for > > abuse by allocating large chunks of memory, and then remapping > > them in some way with different attributes, thereby violating the > > ARM architecture specification? > > I seem to have missed the previous discussion about this issue. > Where in the specification (preferably ARMv7) can I find > information about this? Here's the extracts from the architecture reference manual: * If the same memory locations are marked as having different cacheability attributes, for example by the use of aliases in a virtual to physical address mapping, behavior is UNPREDICTABLE. A3.5.7 Memory access restrictions Behavior is UNPREDICTABLE if the same memory location: * is marked as Shareable Normal and Non-shareable Normal * is marked as having different memory types (Normal, Device, or Strongly-ordered) * is marked as having different cacheability attributes * is marked as being Shareable Device and Non-shareable Device memory. Such memory marking contradictions can occur, for example, by the use of aliases in a virtual to physical address mapping. Glossary: UNPREDICTABLE Means the behavior cannot be relied upon. UNPREDICTABLE behavior must not represent security holes. UNPREDICTABLE behavior must not halt or hang the processor, or any parts of the system. UNPREDICTABLE behavior must not be documented or promoted as having a defined effect. > Is the problem that it is simply > forbidden to map an address multiple times with different cache > setting and if this is done the hardware might start failing? Or > is the problem that having an address mapped cached means that > speculative pre-fetch can read it into the cache at any time, > possibly causing problems if an un-cached mapping exists? In my > opinion option number two can be handled and I've made an attempt > at doing that in hwmem (posted on linux-mm a while ago), look in > cache_handler.c. Hwmem currently does not use cma but the next > version probably will. Given the extract from the architecture reference manual, do you want to run a system where you can't predict what the behaviour will be if you have two mappings present, one which is cacheable and one which is non-cacheable, and you're relying on the non-cacheable mapping to never return data from the cache? What if during your testing, it appears to work correctly, but out in the field, someone's loaded a different application to your setup resulting in different memory access patterns, causing cache lines to appear in the non-cacheable mapping, and then the CPU hits them on subsequent accesses corrupting data... You can't say that will never happen if you're relying on this unpredictable behaviour. -- 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: [PATCHv8 00/12] Contiguous Memory Allocator
> -Original Message- > From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux- > arm-kernel-boun...@lists.infradead.org] On Behalf Of Russell King - > ARM Linux > Sent: Tuesday, January 04, 2011 10:49 PM > To: Johan MOSSBERG > Cc: Daniel Walker; Kyungmin Park; Mel Gorman; KAMEZAWA Hiroyuki; > Michal Nazarewicz; linux-ker...@vger.kernel.org; Michal Nazarewicz; > linux...@kvack.org; Ankita Garg; Andrew Morton; Marek Szyprowski; > linux-arm-ker...@lists.infradead.org; linux-media@vger.kernel.org > Subject: Re: [PATCHv8 00/12] Contiguous Memory Allocator > > On Tue, Jan 04, 2011 at 05:23:37PM +0100, Johan MOSSBERG wrote: > > Russell King wrote: > > > Has anyone addressed my issue with it that this is wide-open for > > > abuse by allocating large chunks of memory, and then remapping > > > them in some way with different attributes, thereby violating > the > > > ARM architecture specification? > > > > I seem to have missed the previous discussion about this issue. > > Where in the specification (preferably ARMv7) can I find > > information about this? > > Here's the extracts from the architecture reference manual: > > * If the same memory locations are marked as having different > cacheability attributes, for example by the use of aliases in a > virtual to physical address mapping, behavior is UNPREDICTABLE. > > A3.5.7 Memory access restrictions > > Behavior is UNPREDICTABLE if the same memory location: > * is marked as Shareable Normal and Non-shareable Normal > * is marked as having different memory types (Normal, Device, or > Strongly-ordered) > * is marked as having different cacheability attributes > * is marked as being Shareable Device and Non-shareable Device > memory. > > Such memory marking contradictions can occur, for example, by the > use of > aliases in a virtual to physical address mapping. > > Glossary: > UNPREDICTABLE > Means the behavior cannot be relied upon. UNPREDICTABLE behavior > must not > represent security holes. UNPREDICTABLE behavior must not halt or > hang > the processor, or any parts of the system. UNPREDICTABLE behavior > must not > be documented or promoted as having a defined effect. > > > Is the problem that it is simply > > forbidden to map an address multiple times with different cache > > setting and if this is done the hardware might start failing? Or > > is the problem that having an address mapped cached means that > > speculative pre-fetch can read it into the cache at any time, > > possibly causing problems if an un-cached mapping exists? In my > > opinion option number two can be handled and I've made an attempt > > at doing that in hwmem (posted on linux-mm a while ago), look in > > cache_handler.c. Hwmem currently does not use cma but the next > > version probably will. > > Given the extract from the architecture reference manual, do you > want > to run a system where you can't predict what the behaviour will be > if > you have two mappings present, one which is cacheable and one which > is > non-cacheable, and you're relying on the non-cacheable mapping to > never > return data from the cache? > > What if during your testing, it appears to work correctly, but out > in > the field, someone's loaded a different application to your setup > resulting in different memory access patterns, causing cache lines > to > appear in the non-cacheable mapping, and then the CPU hits them on > subsequent accesses corrupting data... > > You can't say that will never happen if you're relying on this > unpredictable behaviour. > Just to add to Russell's point, we did land up in un-traceable CPU deadlocks while running the kernel which was violating some of the rules set by ARM ARM. The usecase use to work ~98% of the time. Regards, Santosh -- 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 07/15]drivers:net:wireless:iwlwifi Typo change diable to disable.
On Thu, Dec 30, 2010 at 03:07:56PM -0800, Justin P. Mattock wrote: > The below patch fixes a typo "diable" to "disable". Please let me know if > this > is correct or not. > > Signed-off-by: Justin P. Mattock Acked-by: John W. Linville -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- 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: Summary of the pending patches up to Dec, 31 (26 patches)
Dear Developers, Happy New Year. I'll try to describe my patches so that they would be more understandable. First comment is for all dvb_dmx_swfilter() and dvb_dmx_swfilter_204() users: please test the performance improvement. The second comment is mostly to convince Manu Abraham, but the concept might be useful for others too. Please read. 31.12.2010 14:41, Mauro Carvalho Chehab wrote: > Dear Developers, > > == Need more tests/acks from DVB users == > > Aug, 7 2010: Avoid unnecessary data copying inside dvb_dmx_swfilter_204() > function http://patchwork.kernel.org/patch/118147 Marko Ristola > This patch affects equally for both dvb_dmx_swfilter() and dvb_dmx_swfilter_204(). The resulting performance and functionality is similar with dvb_dmx_swfilter_packets(). dvb_dmx_swfilter(_204)() have robustness checks. Devices without such need can still use dvb_dmx_swfilter_packets(). My performance patch helps especially with high volume 256-QAM TS streams containing for example HDTV content by removing one unnecessary stream copy. With "perf top", dvb_dmx_swfilter_204()'s CPU consumption reduced in the following way: Without the patch dvb_dmx_swfilter_204() and dvb_dmx_swfilter_packet() took about equal amounts of CPU. With the patch dvb_dmx_swfilter_204()'s CPU consumption went into 1/5 or 1/10 of the original (resulting minor CPU consumption). dvb_dmx_swfilter_packet()'s CPU time was about as before. Test environment was Fedora with VDR streaming HDTV into network. I have tested the patch thoroughly (see for example https://patchwork.kernel.org/patch/108274). The patch assumes that dvb_dmx_swfilter_packet() can eat data stream fast enough so that the DVB card's DMA engine will not replace buffer content underneath of dvb_dmx_swfilter_204(). It would be helpful if someone using dvb_dmx_swfilter() could try the patch too: maybe nobody has tried it. The benefit would be, that dvb_dmx_swfilter() is almost equally fast as the existing blatantly fast dvb_dmx_swfilter_packets() :) > > > * I want to see people testing the above patch, as it seems to improve * > * DVB performance by avoiding data copy. * > > > == mantis patches - Waiting for Manu Abraham > == > > Jun,20 2010: [2/2] DVB/V4L: mantis: remove unused files > http://patchwork.kernel.org/patch/107062 Bjørn Mork > Jul,19 2010: Twinhan DTV Ter-CI (3030 mantis) > http://patchwork.kernel.org/patch/112708 Niklas Claesson > > Aug, 7 2010: Refactor Mantis DMA transfer to deliver 16Kb TS data per > interrupt http://patchwork.kernel.org/patch/118173 Marko Ristola > 16Kb TS stream improvement: What do you think about this, Manu Abraham? If high volume TS stream (256-QAM) with 50Mbits/s generates one interrupt once per 4096 bytes, you have a problem. Mantis driver copies 4096 bytes with one interrupt, into dvb_core's 128K buffer. VDR reads data in big pieces (as much data as you get). Network layer receives data in about 100K - 300K pieces from VDR. So I think that it is unnecessary to interrupt other processes once per 4096 bytes, for 56Mbit/s streams. With 16K / interrupt you reduce the number of interrupts into one quarter, without affecting VDR at all, lessening unnecessary interrupts and giving CPU time to other processes. The CPU might have some other things to do without wanting to get interrupted once per (displaying HDTV, delivering HDTV stream to network). Mantis/Hopper kernel driver must process the whole high volume TS stream, although it might deliver only one radio channel forward. I saw glitches with HDTV (followed by stream halt) even though the Mantis DVB card only delivered the data into the local network via VDR. I don't have such single CPU computer anymore though. 16K comes from the fact that it is not good to try to overload dvb_core's 128K buffer. 3/4 of the interrupts are gone. DVB driver does at least twice the number of interrupts compared to VDR reading the stream: dvb_core's buffer is never empty when VDR asks more data. Best regards, Marko Ristola -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: V4L2 driver for Qualcomm MSM camera.
On Tue, Jan 4, 2011 at 3:29 PM, Mauro Carvalho Chehab wrote: > Em 04-01-2011 08:40, Hans Verkuil escreveu: >>> Hi Jeff, >>> >>> On Tuesday 04 January 2011 07:14:00 Haibo Zhong wrote: On 1/3/2011 6:37 PM, Shuzhen Wang wrote: > On Tuesday, December 28, 2010 12:24 PM Laurent Pinchart wrote: >> >> I will strongly NAK any implementation that requires a daemon. > > We understand the motivation behind making the daemon optional. > However there are restrictions from legal perspective, which we > don't know how to get around. > > A simplest video streaming data flow with MSM ISP is like this: > > Sensor -> ISP Hardware pipeline -> videobuf > > The procedure to set up ISP pipeline is proprietary and cannot > be open sourced. Without proper pipeline configuration, streaming > won't work. And That's why we require the daemon. Laurent/Hans/Mauro, We are working on and will provide more design information on Qualcomm MSM ISP design and explain the legal concern of the daemon implementation. The underlined idea is to comply to V4L2 architecture with MSM solution. >>> >>> That's a good first step, but I'm afraid it's not enough. If you want your >>> driver to be included in the mainline Linux kernel (and its derivative >>> distribution kernels such as the MeeGo kernel for instance) all the code >>> needed to access and use the hardware must be open-source. >>> >>> This of course doesn't preclude you from providing a closed-source >>> userspace >>> implementation of proprietary hardware-assisted image processing >>> algorithms >>> for instance (as a library or as a daemon). >>> In the meantime, Laurent, can you share with your major concern about the Daemon? >>> >>> I have two concerns. >>> >>> - The daemon makes code required to use the hardware closed-source, making >>> the >>> driver closed-source (whether the kernel-side code is licensed under the >>> GPL >>> or not is irrelevant). I would have the exact same opinion if the required >>> userspace proprietary code was provided as a library, so this concern is >>> not >>> specific to the implementation being in the form of a daemon. >>> >>> - The daemon makes the kernel-side driver architecture more complex for no >>> reason. Assuming you can make all the driver open-source in the future and >>> want to keep proprietary userspace image processing code closed-source, >>> the >>> driver architecture must not be designed solely to support that use case. >>> The >>> driver should be clean and lean, and the proprietary code must then come >>> as a >>> user of the driver, not the other way around. >>> >>> As a summary, having part of the driver closed-source is a no-go, and >>> having >>> part of the kernel driver API designed and used to support closed-source >>> components only is a no-go as well. >> >> I don't entirely understand the whole discussion: in Helsinki this was >> discussed extensively with Jeff Zhong and I thought we all agreed on how >> to implement the driver: using a libv4l plugin which communicates to a >> daemon for your proprietary ISP code. > > I also had the same understanding from Helsinki's meeting. > >> Also, the driver should work without any proprietary code (obviously with >> sub-optimal picture quality, but you should get something out of the >> hardware). The driver API should be well-documented when it comes to any >> custom ioctls/controls. This makes it possible for sufficiently motivated >> developers to write open source libv4l plugins. It was my understanding >> that the proprietary code was about determining the optimal ISP settings, >> not about getting the ISP hardware to work. > > Look: we don't mind if you have some daemon/library/userspace utils with some > picture enhancement algorithm that you may have developed and have legal > concerns to protect them. The best way for doing that is probably via libv4l, > as other userspace apps will use it, but you can do whatever you want. > > However, the driver should be open source for being accepted upstream. > In other words, all access to the hardware should be done via the open > source driver, and using a public, well documented, kernel<=>userspace API. > That means that any application should be able to use it, without requiring > any daemon. > > So, it is OK if your driver have some well-documented ways to expose image > statistics and some way to adjust the device parameters to enhance image > quality, and have some proprietary, closed source daemon/library that will > use those statistics to enhance the image. Of course, such driver, to be open, > should allow someone to write a different code to do similar enhancements, > as Hans pointed. > > That's said, I can't understand why you're afraid of doing that. Multiple reasons 1. They want to control their drivers and not have to take care about the kernel release cycles. 2. With a thin kernel layer (if needed) th
[cron job] v4l-dvb daily build: WARNINGS
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:Tue Jan 4 19:00:18 CET 2011 git master: 59365d136d205cc20fe666ca7f89b1c5001b0d5a git media-master: 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: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.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
Add Terratec Grabster support to tm6000
Hi,
the following patch adds support for a Terratec Grabster AV MX150 (and
maybe other devices in the Grabster series). This device is an analog
frame grabber device using a tm5600. This device doesn't have a tuner, so
I changed the code to skip the tuner reset if neither has_tuner nor
has_dvb is set.
Holger
diff -urpN --exclude='*~'
linux-2.6.37-rc8/drivers/staging/tm6000/tm6000-cards.c
linux-lts-backport-natty-2.6.37/drivers/staging/tm6000/tm6000-cards.c
--- linux-2.6.37-rc8/drivers/staging/tm6000/tm6000-cards.c 2010-12-29
02:05:48.0 +0100
+++ linux-lts-backport-natty-2.6.37/drivers/staging/tm6000/tm6000-cards.c
2011-01-04 10:46:40.582497722 +0100
@@ -50,6 +50,7 @@
#define TM6010_BOARD_BEHOLD_VOYAGER11
#define TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE12
#define TM6010_BOARD_TWINHAN_TU501 13
+#define TM5600_BOARD_TERRATEC_GRABSTER 14
#define TM6000_MAXBOARDS16
static unsigned int card[] = {[0 ... (TM6000_MAXBOARDS - 1)] = UNSET };
@@ -303,6 +304,19 @@ struct tm6000_board tm6000_boards[] = {
.dvb_led= TM6010_GPIO_5,
.ir = TM6010_GPIO_0,
},
+ },
+ [TM5600_BOARD_TERRATEC_GRABSTER] = {
+ .name = "Terratec Grabster Series",
+ .type = TM5600,
+ .caps = {
+ .has_tuner = 0,
+ .has_dvb= 0,
+ .has_zl10353= 0,
+ .has_eeprom = 0,
+ .has_remote = 0,
+ },
+ .gpio = {
+ },
}
};
@@ -325,6 +339,7 @@ struct usb_device_id tm6000_id_table[] =
{ USB_DEVICE(0x13d3, 0x3241), .driver_info = TM6010_BOARD_TWINHAN_TU501
},
{ USB_DEVICE(0x13d3, 0x3243), .driver_info = TM6010_BOARD_TWINHAN_TU501
},
{ USB_DEVICE(0x13d3, 0x3264), .driver_info = TM6010_BOARD_TWINHAN_TU501
},
+ { USB_DEVICE(0x0ccd, 0x0079), .driver_info =
TM5600_BOARD_TERRATEC_GRABSTER },
{ },
};
@@ -505,33 +520,35 @@ int tm6000_cards_setup(struct tm6000_cor
* reset, just add the code at the board-specific part
*/
- if (dev->gpio.tuner_reset) {
- for (i = 0; i < 2; i++) {
- rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
- dev->gpio.tuner_reset, 0x00);
- if (rc < 0) {
- printk(KERN_ERR "Error %i doing tuner reset\n",
rc);
- return rc;
- }
+ if (dev->caps.has_tuner||dev->caps.has_dvb) {
+ if (dev->gpio.tuner_reset) {
+ for (i = 0; i < 2; i++) {
+ rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+ dev->gpio.tuner_reset,
0x00);
+ if (rc < 0) {
+ printk(KERN_ERR "Error %i doing tuner
reset\n", rc);
+ return rc;
+ }
- msleep(10); /* Just to be conservative */
- rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
- dev->gpio.tuner_reset, 0x01);
- if (rc < 0) {
- printk(KERN_ERR "Error %i doing tuner reset\n",
rc);
- return rc;
- }
- msleep(10);
+ msleep(10); /* Just to be conservative */
+ rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+ dev->gpio.tuner_reset,
0x01);
+ if (rc < 0) {
+ printk(KERN_ERR "Error %i doing tuner
reset\n", rc);
+ return rc;
+ }
+ msleep(10);
- if (!i) {
- rc = tm6000_get_reg32(dev, REQ_40_GET_VERSION,
0, 0);
- if (rc >= 0)
- printk(KERN_DEBUG "board=0x%08x\n", rc);
+ if (!i) {
+ rc = tm6000_get_reg32(dev,
REQ_40_GET_VERSION, 0, 0);
+ if (rc >= 0)
+ printk(KERN_DEBUG
"board=0x%08x\n", rc);
+ }
}
+ } else {
+ printk(KERN_ERR "Tuner reset is not configured\n");
+ return -1;
}
- } else {
- printk(KERN_ERR "Tuner reset
RE: RFC: V4L2 driver for Qualcomm MSM camera.
We will exploring the usage of libv4l2...however we still have the difficulties to open-source hardware: our ISP and sensors, will need help on how to address such issues. -Original Message- From: Markus Rechberger [mailto:mrechber...@gmail.com] Sent: Tuesday, January 04, 2011 10:08 AM To: Mauro Carvalho Chehab Cc: Hans Verkuil; Laurent Pinchart; Haibo Zhong; Shuzhen Wang; linux-media@vger.kernel.org; Yan, Yupeng; Zhong, Jeff Subject: Re: RFC: V4L2 driver for Qualcomm MSM camera. On Tue, Jan 4, 2011 at 3:29 PM, Mauro Carvalho Chehab wrote: > Em 04-01-2011 08:40, Hans Verkuil escreveu: >>> Hi Jeff, >>> >>> On Tuesday 04 January 2011 07:14:00 Haibo Zhong wrote: On 1/3/2011 6:37 PM, Shuzhen Wang wrote: > On Tuesday, December 28, 2010 12:24 PM Laurent Pinchart wrote: >> >> I will strongly NAK any implementation that requires a daemon. > > We understand the motivation behind making the daemon optional. > However there are restrictions from legal perspective, which we > don't know how to get around. > > A simplest video streaming data flow with MSM ISP is like this: > > Sensor -> ISP Hardware pipeline -> videobuf > > The procedure to set up ISP pipeline is proprietary and cannot > be open sourced. Without proper pipeline configuration, streaming > won't work. And That's why we require the daemon. Laurent/Hans/Mauro, We are working on and will provide more design information on Qualcomm MSM ISP design and explain the legal concern of the daemon implementation. The underlined idea is to comply to V4L2 architecture with MSM solution. >>> >>> That's a good first step, but I'm afraid it's not enough. If you want your >>> driver to be included in the mainline Linux kernel (and its derivative >>> distribution kernels such as the MeeGo kernel for instance) all the code >>> needed to access and use the hardware must be open-source. >>> >>> This of course doesn't preclude you from providing a closed-source >>> userspace >>> implementation of proprietary hardware-assisted image processing >>> algorithms >>> for instance (as a library or as a daemon). >>> In the meantime, Laurent, can you share with your major concern about the Daemon? >>> >>> I have two concerns. >>> >>> - The daemon makes code required to use the hardware closed-source, making >>> the >>> driver closed-source (whether the kernel-side code is licensed under the >>> GPL >>> or not is irrelevant). I would have the exact same opinion if the required >>> userspace proprietary code was provided as a library, so this concern is >>> not >>> specific to the implementation being in the form of a daemon. >>> >>> - The daemon makes the kernel-side driver architecture more complex for no >>> reason. Assuming you can make all the driver open-source in the future and >>> want to keep proprietary userspace image processing code closed-source, >>> the >>> driver architecture must not be designed solely to support that use case. >>> The >>> driver should be clean and lean, and the proprietary code must then come >>> as a >>> user of the driver, not the other way around. >>> >>> As a summary, having part of the driver closed-source is a no-go, and >>> having >>> part of the kernel driver API designed and used to support closed-source >>> components only is a no-go as well. >> >> I don't entirely understand the whole discussion: in Helsinki this was >> discussed extensively with Jeff Zhong and I thought we all agreed on how >> to implement the driver: using a libv4l plugin which communicates to a >> daemon for your proprietary ISP code. > > I also had the same understanding from Helsinki's meeting. > >> Also, the driver should work without any proprietary code (obviously with >> sub-optimal picture quality, but you should get something out of the >> hardware). The driver API should be well-documented when it comes to any >> custom ioctls/controls. This makes it possible for sufficiently motivated >> developers to write open source libv4l plugins. It was my understanding >> that the proprietary code was about determining the optimal ISP settings, >> not about getting the ISP hardware to work. > > Look: we don't mind if you have some daemon/library/userspace utils with some > picture enhancement algorithm that you may have developed and have legal > concerns to protect them. The best way for doing that is probably via libv4l, > as other userspace apps will use it, but you can do whatever you want. > > However, the driver should be open source for being accepted upstream. > In other words, all access to the hardware should be done via the open > source driver, and using a public, well documented, kernel<=>userspace API. > That means that any application should be able to use it, without requiring > any daemon. > > So, it is OK if your driver have some well-documented ways to expose image > statistics and some way to adjust the device parameter
Re: Add Terratec Grabster support to tm6000
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 04.01.2011 20:12, schrieb Holger Nelson:
> Hi,
>
> the following patch adds support for a Terratec Grabster AV MX150
> (and maybe other devices in the Grabster series). This device is an
> analog frame grabber device using a tm5600. This device doesn't have
> a tuner, so I changed the code to skip the tuner reset if neither
> has_tuner nor has_dvb is set.
it skip, if you has no tuner gpio defined. You does'nt need more. Work
the driver with input select (tv (conposite0), composite, s-vhs)?
>
> Holger
>
> diff -urpN --exclude='*~'
> linux-2.6.37-rc8/drivers/staging/tm6000/tm6000-cards.c
> linux-lts-backport-natty-2.6.37/drivers/staging/tm6000/tm6000-cards.c
> --- linux-2.6.37-rc8/drivers/staging/tm6000/tm6000-cards.c
> 2010-12-29 02:05:48.0 +0100
> +++
> linux-lts-backport-natty-2.6.37/drivers/staging/tm6000/tm6000-cards.c
> 2011-01-04 10:46:40.582497722 +0100
please use the lastest development kernel from
git://linuxtv.org/media_tree.git (http://linuxtv.org/git/media_tree.git).
> @@ -50,6 +50,7 @@
> #define TM6010_BOARD_BEHOLD_VOYAGER 11
> #define TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE 12
> #define TM6010_BOARD_TWINHAN_TU501 13
> +#define TM5600_BOARD_TERRATEC_GRABSTER 14
>
> #define TM6000_MAXBOARDS 16
> static unsigned int card[] = {[0 ... (TM6000_MAXBOARDS - 1)] =
> UNSET };
> @@ -303,6 +304,19 @@ struct tm6000_board tm6000_boards[] = {
> .dvb_led = TM6010_GPIO_5,
> .ir = TM6010_GPIO_0,
> },
> + },
> + [TM5600_BOARD_TERRATEC_GRABSTER] = {
> + .name = "Terratec Grabster Series",
> + .type = TM5600,
> + .caps = {
> + .has_tuner = 0,
> + .has_dvb = 0,
> + .has_zl10353 = 0,
> + .has_eeprom = 0,
> + .has_remote = 0,
> + },
> + .gpio = {
> + },
> }
> };
>
> @@ -325,6 +339,7 @@ struct usb_device_id tm6000_id_table[] =
> { USB_DEVICE(0x13d3, 0x3241), .driver_info =
> TM6010_BOARD_TWINHAN_TU501 },
> { USB_DEVICE(0x13d3, 0x3243), .driver_info =
> TM6010_BOARD_TWINHAN_TU501 },
> { USB_DEVICE(0x13d3, 0x3264), .driver_info =
> TM6010_BOARD_TWINHAN_TU501 },
> + { USB_DEVICE(0x0ccd, 0x0079), .driver_info =
> TM5600_BOARD_TERRATEC_GRABSTER },
> { },
> };
>
> @@ -505,33 +520,35 @@ int tm6000_cards_setup(struct tm6000_cor
> * reset, just add the code at the board-specific part
> */
>
> - if (dev->gpio.tuner_reset) {
> - for (i = 0; i < 2; i++) {
> - rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> - dev->gpio.tuner_reset, 0x00);
> - if (rc < 0) {
> - printk(KERN_ERR "Error %i doing tuner reset\n", rc);
> - return rc;
> - }
> + if (dev->caps.has_tuner||dev->caps.has_dvb) {
this is bad, if you mean skip tuner reset. We use the line "if
(dev->gpio.tuner_reset)" to check the true tuner reset gpio - if no
gpio set, it skip reset - , and you has no defined a tuner gpio, so it
skip alone.
Why you added then this line?
> + if (dev->gpio.tuner_reset) {
> + for (i = 0; i < 2; i++) {
> + rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> + dev->gpio.tuner_reset, 0x00);
> + if (rc < 0) {
> + printk(KERN_ERR "Error %i doing tuner reset\n",
> rc);
> + return rc;
> + }
>
> - msleep(10); /* Just to be conservative */
> - rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> - dev->gpio.tuner_reset, 0x01);
> - if (rc < 0) {
> - printk(KERN_ERR "Error %i doing tuner reset\n", rc);
> - return rc;
> - }
> - msleep(10);
> + msleep(10); /* Just to be conservative */
> + rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> + dev->gpio.tuner_reset, 0x01);
> + if (rc < 0) {
> + printk(KERN_ERR "Error %i doing tuner reset\n",
> rc);
> + return rc;
> + }
> + msleep(10);
>
> - if (!i) {
> - rc = tm6000_get_reg32(dev, REQ_40_GET_VERSION, 0, 0);
> - if (rc >= 0)
> - printk(KERN_DEBUG "board=0x%08x\n", rc);
> + if (!i) {
> + rc = tm6000_get_reg32(dev, REQ_40_GET_VERSION,
> 0, 0);
> + if (rc >= 0)
> + printk(KERN_DEBUG "board=0x%08x\n", rc);
> + }
> }
> + } else {
> + printk(KERN_ERR "Tuner reset is not configured\n");
> + return -1;
> }
> - } else {
> - printk(KERN_ERR "Tuner reset is not configured\n");
> - return -1;
> }
>
> msleep(50);
> --
> 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
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJNI34QAAoJEAWtPFjxMvFGZwEH/R51EPEp2a/+DC34YkW+ywk6
aF6dJQLSq97hcvm2l6u7P7ku6XNAHqK/uqxXmM7trlyoK9RA1v4GWJV/aod+WmHo
jDocoiYG3ZWANco9aqdcutMCiVFlSKZRk2PsiJQwS+LAOabQGGe3pe6EIPQDmO5h
6TaVVLpzOyvGOHxYAy6PMI4ahJzkeJi1YORFN1a43UzV2GrViroT+BDWDKJk9QPk
Mg2diBj29gR0dwPTusqU0I6mwCqwV13incRlROMiKV1WIkaX1XW64qD0FKfMkSZA
edAljweR/S8ktqYGVrBFPvLUmFaX5zTruSgbRvskAKNO5CZO8isihSEJk9zEEbw=
=Z6bs
-END PGP SIGNATURE-
--
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: [PATCHv8 00/12] Contiguous Memory Allocator
Russell King - ARM Linux wrote: > I'll give you another solution to the problem - lobby ARM Ltd to have > this restriction lifted from the architecture specification, which > will probably result in the speculative prefetching also having to be > removed. I don't know if there was lobbying involved, but the way some barriers on x86 turned out to be unnecessary, on both Intel and AMD, after years of specs which abstractly implied they might be necessary I guess someone realised the relaxed specs weren't providing a benefit at the hardware level. Perhaps it is possible to draw this to ARM's attention as a rather serious performance-damaging thing, so they might tighten the rules in favour of common sense, at least for the majority of devices? Off the top of my head (and I really don't know much about the internals of an ARM), hardware that avoided speculation where there was no entry already in the TLB for the address... that would be workable, as page/range TLB flushes would be enough to protect pages from access. With regard to specific chips (i.e. current ones, while lobbying to tighten the rules for future ones). Is there a control register on the chips which are known to have this annoying issue, to turn off the problematic cache behaviour (permanently while Linux runs), or some set of memory attributes that produces that effect? (Obviously there is: Turn off all caching, but is there a weaker and equally effective one on current hardware with the problem?) It might be there simply _isn't_ any solution that satisfies the generality of ARM spec, while satisfying the engineering requirements of particular media player chips on which the CMA+DMA may be perfectly safe. That would be unpleasant but hardly the first time some feature was not usable on some chips and essential on some others. Take, for example, those (now old) ARMs that mishandle SWP so it can't be used. We still use SWP in kernels, and indeed userspace, which will break if run on those particular chips, but that's ok - it's an understood limitation. Russell, I think the repeated attempts to propose the same thing, which you keep rejecting (rightly), isn't because they're not listening, but because you haven't got a better solution - other than scrap the hardware :-) Their code might actually be 100% reliable with the chips they use in those products, and it might be the _only_ solution which works on those, thus solving a real problem. What's the right thing to do in that case? Maintain a fork out of tree, or some Kconfig animal that says you can't select this ARM subarch and that memory facility in the same kernel because they are technically incompatible - but at least everyone can see the code, and know which chip families to avoid for certain applications? Here is a hint of an idea for a way forward: - An API that everyone can use (in drivers etc.), that behaves the same for everyone, except that: - On some chips (ARMv7...) some functions requires a large up-front memory reservation at boot time, (but that's ok because you probably have gobs of RAM with it anyway). - On other chips (<= ARMv6?) it is safe to reduce the up-front reservation to less, maybe zero. (Better for smaller memories). - Maybe it even makes sense for drivers using the API to request, at boot time, "_if_ you need early reservation, then _this_ is how much I will need maximum". The values can potentially dynamic anti-fragmantation allocators too. (I've done a bit of research on this - a sort of "semi-reservation" where you don't keep it free up front, but you limit how its used and grouped in a precise way, to make sure other uses are sufficiently reclaimable to satisfy the call when it comes.) - Didn't reserve enough in advance for the architectural constraints - get NULL back. That's what allocators always do. That's what /proc/cmdline's options have a long history helping with - finding the setting which works on your kit. People are already used to a bit of fiddly tuning (and random crashes ;-) with these media application sorts of things. Presumably the problem will ease off with IOMMUs and/or sensible SG (and/or sensible architectural constraints) becoming ubiquitous eventually. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: V4L2 driver for Qualcomm MSM camera.
Hi, On Tuesday 04 January 2011 20:37:31 Yan, Yupeng wrote: > We will exploring the usage of libv4l2...however we still have the > difficulties to open-source hardware: our ISP and sensors, will need help > on how to address such issues. I suppose you mean open-sourcing hardware driver. There's no requirement to open-source the hardware at this point, although I would love to see that happening :-) Let's start with sensors, it's the easiest. Sensor drivers must not depend on the ISP driver, and the ISP driver must not depend on sensor drivers. They communicate together through the media controller and the V4L2 subdev APIs. You will obviously need to test your ISP driver with at least one sensor, but you're not required to submit the sensor driver along with the ISP driver (although it would be nice if you did so). Correct me if I'm wrong, but I don't think Qualcomm produces video sensors, so no Qualcomm confidential information would be disclosed in a sensor driver. If the sensor manufacturer hasn't released a sensor driver, or sensor specifications covered by a license that allows a GPL driver to be written, you will need to sort it out with the manufacturer. Note that public documentation is not strictly required to release an open-source driver (see the SMIA++ driver written by Nokia for instance), but that would be appreciated. For the ISP the problem is not that complex either. From what I understand Qualcomm is scared that publishing an open-source driver will backfire. I can see several reasons (I should probably say myths instead of reasons) for that fear: - "Competitors will steal my code". They can't. The code is highly hardware specific and doesn't contain much added value. It can't be reused as such. Even if code could be reused, it couldn't be "stolen" as it will be covered by the GPLv2. - "Competitors will get key information about my hardware". You need to ask yourself what you consider as key information. The fact that the output width is stored in register 0x12345678 is hardly key information (if it is, there's a more basic issue). The way statistics are computed might be. Based on my experience with ISPs key information isn't disclosed by the driver. The hardware algorithms (such as color conversion, faulty pixels correction, statistics gathering, ...) implementation are usually not disclosed by the code. - "Competitors will sue me for patent infringement". This goes along with the previous point. Patented ISP features are usually the ones you consider as key information, and details are thus not disclosed by the driver. Note that I don't care here about trivial patents with broad claims such as "a system to capture an image to memory". Even without any open-source driver infringement can still easily be proven (and the patent can easily be invalidated, although that costs money - Qualcomm should join the Open Invention Network :-)). None of those reasons are valid compared to the benefits you get from an open- source Linux driver. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Streaming on low resource
Hello,
I have an http stream in MPEG1/2 Video (mpgv)
Frame rate: 50 4000kb/s
It's basically the output of a satellite receiver with various resolutions.
480/576
544/576
720/576
704/576
Anyway, I have a P4 1.6GHZ with 512M RAM and 1024kb UL speed... I have
been trying to transcode and stream the signal to LAN, but my
principal intention is to stream to Internet. I'm using these options
in VLC which I found giving the best results.
Code:
:sout=#transcode{vcodec=mp4v,vb=650,fps=24,scale=0.5,acodec=mp3,ab=90,channels=1,samplerate=22050}:duplicate{dst=http{mux=ts,dst=:/},dst=display}
:no-sout-rtp-sap :no-sout-standard-sap :ttl=1 :sout-keep
I would like to ask you for any suggestion about any improvements...
I'm using Http because that's the only protocol I got running on
Internet... I got RTSP on LAN running but with no luck on Internet...
I'm doing NAT, so do you have any good experience with a particular
protocol.
I didn't see any difference with encapsulation methods, but I would be
pleased to hear your word.
Codecs: as you can see I'm using mp4 + mp3, the scale 0.5 is
sufficient but could you propose other parameters?
If I ever wanted to update the hardware what would be the priority,
CPU or RAM... I know both are needed...
Finally, I'm streaming from ubuntu 10.10 and any specific lightweight
distribution is welcome... as well as any other program similar to
VLC.
Thank you!
--
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
SOC-Camera VIDIOC_ENUM_FRAMESIZES interface?
Hi, We are now trying to adapt to soc-camera framework, though we have one question when reviewing the source code about V4L2_VIDIOC_ENUM_FRAMESIZE: We find that there is no vidioc_enum_framesizes implementation in soc-camera.c. Do you feel it's reasonable to add it into soc-camera about vidioc_enum_framesizes, so that the application knows how many frame-size is supported by camera driver, and then show all the size options in UI, then allow user to choose one size from the list. Any ideas will be appreciated! Thanks! Qing Xu Email: qi...@marvell.com Application Processor Systems Engineering Marvell Technology Group Ltd. -- 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: SOC-Camera VIDIOC_ENUM_FRAMESIZES interface?
Hi On Tue, 4 Jan 2011, Qing Xu wrote: > Hi, > > We are now trying to adapt to soc-camera framework, though we have one > question when reviewing the source code about > V4L2_VIDIOC_ENUM_FRAMESIZE: > > We find that there is no vidioc_enum_framesizes implementation in > soc-camera.c. > > Do you feel it's reasonable to add it into soc-camera about > vidioc_enum_framesizes, so that the application knows how many > frame-size is supported by camera driver, and then show all the size > options in UI, then allow user to choose one size from the list. So far this has been an optional ioctl() and no soc-camera set up had a need to support it. However, if you do need it for some reason, we certainly can look into adding it. Thanks Guennadi > Any ideas will be appreciated! > > Thanks! > Qing Xu --- 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
