Re: [RFC] subdevice PM: .s_power() deprecation?
Hi Sylwester, Sylwester Nawrocki wrote: ... I understand what you're saying, but can you give us a specific example, when a subdev driver (your SoC internal subdev, that is) doesn't have a way to react to an event itself and only the bridge driver gets called into at that time? Something like an interrupt or an internal timer or some other internal event? 1. The S5P SoC video output subsystem (http://lwn.net/Articles/449661) comprises of multiple logical blocks, like Video Processor, Mixer, HDMI, HDMI PHY, SD TV Out. For instance the master video clock is during normal operation derived from (synchronized to, with PLL,) the HDMI-PHY output clock. The host driver can switch to this clock only when the HDMI-PHY (subdev) power and clocks are enabled. And it should be done before .s_stream(), to do some H/W configuration earlier in the pipeline, before streaming is enabled. Perhaps Tomasz could give some further explanation of what the s_power() op does and why in the driver. 2. In some of our camera pipeline setups - Sensor - MIPI-CSI receiver - host/DMA, the sensor won't boot properly if all MIPI-CSI regulators aren't enabled. So the MIPI-CSI receiver must always be powered on before the sensor. With the subdevs doing their own magic wrt to power control the situation is getting slightly out of control. How about this: CSI-2 receiver implements a few new regulators which the sensor driver then requests to be enabled. Would that work for you? I guess we all agree the power requirements of external subdevs are generally unknown to the hosts. For these it might make lot of sense to let the subdev driver handle the device power supplies on basis of requests like, s_ctrl, s_stream, etc. Yes, right, so, most external (sensor, decoder,...) subdev drivers should never need to implement .s_power(), regardless of whether we decide to keep it or not. Well, ok, no, put it differently - in those drivers .s_power() should only really be called during system-wide suspend / resume. Yes, I agree with that. But before we attempt to remove .s_power() or deprecate it on external subdevs, I'd like to get solved the issue with sensor master clock provided by the bridge. As these two are closely related - the sensor controller won't boot if the clock is disabled. And there are always advantages of not keeping the clock always enabled. I guess we'll need to wait awhile before the clock framework would support this. I don't know what's the status of this; probably worth checking. Regards, -- Sakari Ailus sakari.ai...@iki.fi -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix to qt1010 tuner frequency selection (media/dvb)
On Thursday 20 Oct 2011 07:45:45 Jyrki Kuoppala wrote: I think my problem frequency has also been at the later spot. It is possible there is something more complicated going on at 474 MHz - so based on your testing, it's best to apply just the latter change, at least for now. Jyrki +else if (freq 54600) rd[15].val = 0xd6; /* 546 MHz */ +else if (freq 54600) rd[15].val = 0xd6; /* 546 MHz */ Are you going to resubmit the patch with just these changes (you can add my Tested-by to that), or if you want, I can take care of resubmitting it? -Carlos -- 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] subdevice PM: .s_power() deprecation?
Hi Sakari, On 10/23/2011 10:07 AM, Sakari Ailus wrote: Sylwester Nawrocki wrote: ... I understand what you're saying, but can you give us a specific example, when a subdev driver (your SoC internal subdev, that is) doesn't have a way to react to an event itself and only the bridge driver gets called into at that time? Something like an interrupt or an internal timer or some other internal event? 1. The S5P SoC video output subsystem (http://lwn.net/Articles/449661) comprises of multiple logical blocks, like Video Processor, Mixer, HDMI, HDMI PHY, SD TV Out. For instance the master video clock is during normal operation derived from (synchronized to, with PLL,) the HDMI-PHY output clock. The host driver can switch to this clock only when the HDMI-PHY (subdev) power and clocks are enabled. And it should be done before .s_stream(), to do some H/W configuration earlier in the pipeline, before streaming is enabled. Perhaps Tomasz could give some further explanation of what the s_power() op does and why in the driver. 2. In some of our camera pipeline setups - Sensor - MIPI-CSI receiver - host/DMA, the sensor won't boot properly if all MIPI-CSI regulators aren't enabled. So the MIPI-CSI receiver must always be powered on before the sensor. With the subdevs doing their own magic wrt to power control the situation is getting slightly out of control. How about this: CSI-2 receiver implements a few new regulators which the sensor driver then requests to be enabled. Would that work for you? No, I don't like that... :) We would have to standardize the regulator supply names, etc. Such approach would be more difficult to align with runtime/system suspend/resume. Also the sensor drivers should be independent on other drivers. The MIPI-CSI receiver is more specific to the host, rather than a sensor. Not all sensors need MIPI-CSI, some just use parallel video bus. I guess we all agree the power requirements of external subdevs are generally unknown to the hosts. For these it might make lot of sense to let the subdev driver handle the device power supplies on basis of requests like, s_ctrl, s_stream, etc. Yes, right, so, most external (sensor, decoder,...) subdev drivers should never need to implement .s_power(), regardless of whether we decide to keep it or not. Well, ok, no, put it differently - in those drivers .s_power() should only really be called during system-wide suspend / resume. Yes, I agree with that. But before we attempt to remove .s_power() or deprecate it on external subdevs, I'd like to get solved the issue with sensor master clock provided by the bridge. As these two are closely related - the sensor controller won't boot if the clock is disabled. And there are always advantages of not keeping the clock always enabled. I guess we'll need to wait awhile before the clock framework would support this. I don't know what's the status of this; probably worth checking. Last time I checked, a reference platform migration to common clk struct was being prepared for OMAP. So hopefully we are close to the agreement. I think there is a speech about this during ELCE. -- Regards, Sylwester -- 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] subdevice PM: .s_power() deprecation?
Sylwester Nawrocki wrote: Hi Sakari, On 10/23/2011 10:07 AM, Sakari Ailus wrote: Sylwester Nawrocki wrote: ... I understand what you're saying, but can you give us a specific example, when a subdev driver (your SoC internal subdev, that is) doesn't have a way to react to an event itself and only the bridge driver gets called into at that time? Something like an interrupt or an internal timer or some other internal event? 1. The S5P SoC video output subsystem (http://lwn.net/Articles/449661) comprises of multiple logical blocks, like Video Processor, Mixer, HDMI, HDMI PHY, SD TV Out. For instance the master video clock is during normal operation derived from (synchronized to, with PLL,) the HDMI-PHY output clock. The host driver can switch to this clock only when the HDMI-PHY (subdev) power and clocks are enabled. And it should be done before .s_stream(), to do some H/W configuration earlier in the pipeline, before streaming is enabled. Perhaps Tomasz could give some further explanation of what the s_power() op does and why in the driver. 2. In some of our camera pipeline setups - Sensor - MIPI-CSI receiver - host/DMA, the sensor won't boot properly if all MIPI-CSI regulators aren't enabled. So the MIPI-CSI receiver must always be powered on before the sensor. With the subdevs doing their own magic wrt to power control the situation is getting slightly out of control. How about this: CSI-2 receiver implements a few new regulators which the sensor driver then requests to be enabled. Would that work for you? No, I don't like that... :) We would have to standardize the regulator supply names, etc. Such approach would be more difficult to align with runtime/system suspend/resume. Also the sensor drivers should be independent on other drivers. The MIPI-CSI receiver is more specific to the host, rather than a sensor. Not all sensors need MIPI-CSI, some just use parallel video bus. The sensor drivers are responsible for the regulators they want to use, right? If they need no CSI-2 related regulators then they just ignore them as any other regulators the sensor doesn't need. The names of the regulators could come from the platform data, they're board specific anyway. I can't see another way to do this without having platform code to do this which is not quite compatible with the idea of the device tree. -- Sakari Ailus sakari.ai...@iki.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: [RFC] subdevice PM: .s_power() deprecation?
On 10/23/2011 10:44 AM, Sakari Ailus wrote: Sylwester Nawrocki wrote: ... 2. In some of our camera pipeline setups - Sensor - MIPI-CSI receiver - host/DMA, the sensor won't boot properly if all MIPI-CSI regulators aren't enabled. So the MIPI-CSI receiver must always be powered on before the sensor. With the subdevs doing their own magic wrt to power control the situation is getting slightly out of control. How about this: CSI-2 receiver implements a few new regulators which the sensor driver then requests to be enabled. Would that work for you? No, I don't like that... :) We would have to standardize the regulator supply names, etc. Such approach would be more difficult to align with runtime/system suspend/resume. Also the sensor drivers should be independent on other drivers. The MIPI-CSI receiver is more specific to the host, rather than a sensor. Not all sensors need MIPI-CSI, some just use parallel video bus. The sensor drivers are responsible for the regulators they want to use, right? If they need no CSI-2 related regulators then they just ignore Only for the regulator supplies for their device. In this case the sensor driver would have to touch MIPI-CSI device regulator supplies. them as any other regulators the sensor doesn't need. The names of the regulators could come from the platform data, they're board specific anyway. I can't see another way to do this without having No, you don't want regulator supply names in any platform data struct. The platform code binds regulator supplies to the devices, whether it is DT based or not. platform code to do this which is not quite compatible with the idea of the device tree. Now I just use s_power callback in our drivers and it all works well. -- Regards, Sylwester -- 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] subdevice PM: .s_power() deprecation?
Hi Sylwester, On Sunday 23 October 2011 11:01:15 Sylwester Nawrocki wrote: On 10/23/2011 10:44 AM, Sakari Ailus wrote: Sylwester Nawrocki wrote: ... 2. In some of our camera pipeline setups - Sensor - MIPI-CSI receiver - host/DMA, the sensor won't boot properly if all MIPI-CSI regulators aren't enabled. So the MIPI-CSI receiver must always be powered on before the sensor. With the subdevs doing their own magic wrt to power control the situation is getting slightly out of control. How about this: CSI-2 receiver implements a few new regulators which the sensor driver then requests to be enabled. Would that work for you? No, I don't like that... :) We would have to standardize the regulator supply names, etc. Such approach would be more difficult to align with runtime/system suspend/resume. Also the sensor drivers should be independent on other drivers. The MIPI-CSI receiver is more specific to the host, rather than a sensor. Not all sensors need MIPI-CSI, some just use parallel video bus. The sensor drivers are responsible for the regulators they want to use, right? If they need no CSI-2 related regulators then they just ignore Only for the regulator supplies for their device. In this case the sensor driver would have to touch MIPI-CSI device regulator supplies. them as any other regulators the sensor doesn't need. The names of the regulators could come from the platform data, they're board specific anyway. I can't see another way to do this without having No, you don't want regulator supply names in any platform data struct. The platform code binds regulator supplies to the devices, whether it is DT based or not. You can still add a regulator name field to the sensor platform data, or a link to the regulator in the device tree, and use that in the sensor driver if present. I'm not telling it's a good solution, but it's technically doable. platform code to do this which is not quite compatible with the idea of the device tree. Now I just use s_power callback in our drivers and it all works well. Having the sensor driver calling the CSI-2 receiver s_power callback directly sounds a bit hackish to me. If we really want to call subdev operations from another subdev driver we'll need to specify that, as the current mode of operation (at least in my understanding) is that subdev operations are only called by host drivers. -- 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] subdevice PM: .s_power() deprecation?
Hi Laurent, On 10/23/2011 11:26 AM, Laurent Pinchart wrote: On Sunday 23 October 2011 11:01:15 Sylwester Nawrocki wrote: On 10/23/2011 10:44 AM, Sakari Ailus wrote: Sylwester Nawrocki wrote: 2. In some of our camera pipeline setups - Sensor - MIPI-CSI receiver - host/DMA, the sensor won't boot properly if all MIPI-CSI regulators aren't enabled. So the MIPI-CSI receiver must always be powered on before the sensor. With the subdevs doing their own magic wrt to power control the situation is getting slightly out of control. How about this: CSI-2 receiver implements a few new regulators which the sensor driver then requests to be enabled. Would that work for you? No, I don't like that... :) We would have to standardize the regulator supply names, etc. Such approach would be more difficult to align with runtime/system suspend/resume. Also the sensor drivers should be independent on other drivers. The MIPI-CSI receiver is more specific to the host, rather than a sensor. Not all sensors need MIPI-CSI, some just use parallel video bus. The sensor drivers are responsible for the regulators they want to use, right? If they need no CSI-2 related regulators then they just ignore Only for the regulator supplies for their device. In this case the sensor driver would have to touch MIPI-CSI device regulator supplies. them as any other regulators the sensor doesn't need. The names of the regulators could come from the platform data, they're board specific anyway. I can't see another way to do this without having No, you don't want regulator supply names in any platform data struct. The platform code binds regulator supplies to the devices, whether it is DT based or not. You can still add a regulator name field to the sensor platform data, or a link to the regulator in the device tree, and use that in the sensor driver if present. I'm not telling it's a good solution, but it's technically doable. Yes, that would be also possible. platform code to do this which is not quite compatible with the idea of the device tree. Now I just use s_power callback in our drivers and it all works well. Having the sensor driver calling the CSI-2 receiver s_power callback directly sounds a bit hackish to me. If we really want to call subdev operations from another subdev driver we'll need to specify that, as the current mode of operation (at least in my understanding) is that subdev operations are only called by host drivers. I meant s_power() is only used by the host. Every device in the pipeline is powered up by the host at video device open() in right order. Maybe we could ad some kind of notifier to v4l core so the host gets notified when any of subdevs registered to it gets it's video node opened ? -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Sun Oct 23 19:00:17 CEST 2011 git hash:35a912455ff5640dc410e91279b03e04045265b2 gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.0-4.slh.7-amd64 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: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
new mbus formats
Hi, I need a few mbus formats to be defined loosely for following. Please tell me if anyone has already thought of taking care of them already. These are supported for Texas Instruments DM365 and DM355 SoCs. 1. RGB 888 parallel: 2. YUV420 color separate: 3. C plane 420: ( On the lines of Y plane: V4L2_MBUS_FMT_Y8_1X8) 4. C plane 422 5. 10 bit bayer with ALAW compression. If not, could you please suggest/discuss on the possible MBUS formats for the above? Thanks and Regards, -Manju -- 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: omap3isp: BT.656 support
On Thu, Oct 20, 2011 at 5:36 PM, Stefan Herbrechtsmeier sherb...@cit-ec.uni-bielefeld.de wrote: Am 20.10.2011 14:14, schrieb Boris Todorov: On Thu, Oct 20, 2011 at 12:03 PM, Stefan Herbrechtsmeier sherb...@cit-ec.uni-bielefeld.de wrote: Am 20.10.2011 08:56, schrieb Boris Todorov: On Wed, Oct 19, 2011 at 7:26 PM, Stefan Herbrechtsmeier sherb...@cit-ec.uni-bielefeld.de wrote: Am 18.10.2011 15:33, schrieb Boris Todorov: Hi I'm trying to run OMAP + TVP5151 in BT656 mode. I'm using omap3isp-omap3isp-yuv (git.linuxtv.org/pinchartl/media.git). Plus the following patches: TVP5151: https://github.com/ebutera/meta-igep/tree/testing-v2/recipes-kernel/linux/linux-3.0+3.1rc/tvp5150 The latest RFC patches for BT656 support: Enrico Butera (2): omap3isp: ispvideo: export isp_video_mbus_to_pix omap3isp: ispccdc: configure CCDC registers and add BT656 support Javier Martinez Canillas (1): omap3isp: ccdc: Add interlaced field mode to platform data I'm able to configure with media-ctl: media-ctl -v -r -l 'tvp5150 3-005c:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl -v --set-format 'tvp5150 3-005c:0 [UYVY2X8 720x525]' media-ctl -v --set-format 'OMAP3 ISP CCDC:0 [UYVY2X8 720x525]' media-ctl -v --set-format 'OMAP3 ISP CCDC:1 [UYVY2X8 720x525]' But ./yavta -f UYVY -s 720x525 -n 4 --capture=4 -F /dev/video4 sleeps after ... Buffer 1 mapped at address 0x4021d000. length: 756000 offset: 1515520 Buffer 2 mapped at address 0x402d6000. length: 756000 offset: 2273280 Buffer 3 mapped at address 0x4038f000. Anyone with the same issue??? This happens with every other v4l test app I used. I had the same issue. Make sure that you disable the xclk when you remove your sensor driver. isp-platform_cb.set_xclk(isp, 0, ISP_XCLK_A) How exactly did you solved your problem? I don't see how XCLK in _remove will help. Pls explain. Sorry, I mean deactive / power off your sensor. Btw I'm feeding TVP with external clock (not from xtal pins) - omap.cam_xclk - tvp.clk_in I mean the cam_xclk. And I'm using kind of hack to get it: isp_probe() + isp_set_xclk(isp, 2700, 1); This is your problem. You should control the clock via board / platform callback from your driver. Example: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg56627.html It is important that you set the clock to zero when your driver is not in use. The problem is connected to the use count of the ISP and some initialisation which only happen when the counter change between zero and one. tvp_probe() needs clock for i2c detected/config. tvp5150_s_power call happens when video starts streaming and if tvp is not configured - kernel panic. I use an other sensor and driver and this config the sensor during start stream. And what about the case when TVP is used with OSC on XTAL pins and CLK_IN is not used at all? Then your system will work, as you never call isp_set_xclk. The problem is not the clock, but how the isp driver works. It expects, that the sensor driver disable the cam_xclk, if the sensor is not used. Maybe I don't fully understand what is happening... or isp_set_xclk() use is messing up with ISP On my system I have the same issues as you if I don't set the cam_xclk to zero during stop streaming. I haven't investigate in the real cause for the issue. I only released, that this issue stick together with an always enabled cam_xclk. Regards, Stefan Thanks Stefan. Now I have IRQs and I'm able to get some image from TVP. -- 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
[GIT PULL] ivtv, cx18: FM radio fixes
Mauro, Please pull two changes that fix FM radio in ivtv and cx18. Thanks go to Ian Armstrong for finding and fixing the ivtv problem. Regards, Andy The following changes since commit 35a912455ff5640dc410e91279b03e04045265b2: Merge branch 'v4l_for_linus' into staging/for_v3.2 (2011-10-19 12:41:18 -0200) are available in the git repository at: ssh://linuxtv.org/git/awalls/media_tree.git fm_radio Andy Walls (1): cx18: Fix FM radio Ian Armstrong (1): ivtv: Fix radio support drivers/media/video/cx18/cx18-driver.c |2 ++ drivers/media/video/ivtv/ivtv-driver.c |2 ++ 2 files changed, 4 insertions(+), 0 deletions(-) -- 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 2/9] mm: alloc_contig_freed_pages() added
On Fri, 21 Oct 2011 03:06:24 -0700, Mel Gorman m...@csn.ul.ie wrote: On Tue, Oct 18, 2011 at 10:26:37AM -0700, Michal Nazarewicz wrote: On Tue, 18 Oct 2011 05:21:09 -0700, Mel Gorman m...@csn.ul.ie wrote: At this point, I'm going to apologise for not reviewing this a long long time ago. On Thu, Oct 06, 2011 at 03:54:42PM +0200, Marek Szyprowski wrote: From: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com This commit introduces alloc_contig_freed_pages() function which allocates (ie. removes from buddy system) free pages in range. Caller has to guarantee that all pages in range are in buddy system. Straight away, I'm wondering why you didn't use mm/compaction.c#isolate_freepages() It knows how to isolate pages within ranges. All its control information is passed via struct compact_control() which I recognise may be awkward for CMA but compaction.c know how to manage all the isolated pages and pass them to migrate.c appropriately. It is something to consider. At first glance, I see that isolate_freepages seem to operate on pageblocks which is not desired for CMA. isolate_freepages_block operates on a range of pages that happens to be hard-coded to be a pageblock because that was the requirements. It calculates end_pfn and it is possible to make that a function parameter. Yes, this seems doable. I'll try and rewrite the patches to use it. The biggest difference is in how CMA and compaction treat pages which are not free. CMA treat it as an error and compaction just skips those. This is solvable by an argument though. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo-- -- 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
Reqbufs(0) need to release queued_list
Hi, As I have used videobuf2+soc_camera architecture on my camera driver. I find a problem when I use Reqbuf(0), which only release buffer, but not clear queued_list. Problem description: That is if upper layer uses qbuf then reqbuf0 directly, not having stream on/dqbuf/off, then next time when streamon, videobuf2 could still have the buffer from queued_list which having the buffer released in privious reqbuf0, and the camera driver could access the buffer already freed. The steps that could cause problem for USERPTR: Qbuf Qbuf Reqbuf 0 Reqbuf 20 Qbuf Qbuf Streamon (queued_list still has the buffer already freed in the previous reqbuf0) .buf_queue (from camera driver, could access the buffer already freed) My question is if we could use __vb2_queue_release which calls __vb2_queue_cancle(clear queue_list) and __vb2_queue_free(release buffer) in Reqbuf(0), while not only use __vb2_queue_free. Thank you Angela Wan Best Regards -- 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
