Re: [GIT PULL FOR 2.6.39] Media controller and OMAP3 ISP driver
Hi Laurent, Many thanks for the pull req! On Thu, Feb 17, 2011 at 04:06:58PM +0100, Laurent Pinchart wrote: ... drivers/media/video/omap3-isp/ispresizer.c | 1693 ++ drivers/media/video/omap3-isp/ispresizer.h | 147 ++ drivers/media/video/omap3-isp/ispstat.c| 1092 + drivers/media/video/omap3-isp/ispstat.h| 169 ++ drivers/media/video/omap3-isp/ispvideo.c | 1264 ++ drivers/media/video/omap3-isp/ispvideo.h | 202 ++ drivers/media/video/omap3-isp/luma_enhance_table.h | 42 + drivers/media/video/omap3-isp/noise_filter_table.h | 30 + ... include/linux/Kbuild |4 + include/linux/media.h | 132 ++ include/linux/omap3isp.h | 646 + What about renaming the directory omap3isp for the sake of consistency? The header file is called omap3isp.h and omap3isp is the prefix used in the driver for exported symbols. My apologies for not bringing this up earlier. Regards, -- Sakari Ailus sakari dot ailus at retiisi dot org dot uk -- 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] snapshot mode, flash capabilities and control
Guennadi Liakhovetski wrote: On Fri, 25 Feb 2011, Sakari Ailus wrote: On Fri, Feb 25, 2011 at 06:08:07PM +0100, Guennadi Liakhovetski wrote: Hi Sakari Hi Guennadi, On Fri, 25 Feb 2011, Sakari Ailus wrote: I agree with that. Flash synchronisation is just one of the many parameters that would benefit from frame level synchronisation. Exposure time, gain etc. are also such. The sensors provide varying level of hardware support for all these. Well, that's true, but... From what I've seen so far, many sensors synchronise such sensitive configuration changes with their frame readout automatically, i.e., you configure some new parameter in a sensor register, but it will only become valid with the next frame. On other sensors you can issue a hold command, perform any needed changed, then issue a commit and all your changes will be applied atomically. At that level it's automatic, but what I meant is synchronising the application of the settings to the exposure start of a given frame. This is very similar to flash synchronisation. Right... But I don't think we can do more, than what the sensor supports about this, can we? Only stop the sensor, apply parameters, start the sensor... It's possible to calculate on what frame the parameters should take effect and apply them to the sensor at the right time. But this is highly timing dependent and I'm not certain it's best to implement this in the driver at all in the case there is no hardware support. Also, we already _can_ configure gain, exposure and many other parameters, but we have no way to use sensor snapshot and flash-synchronisation capabilities. There is a way to configure them but the interface doesn't allow to specify when they should take effect. ??? There are V4L ioctl()s to control the flash?... No flash, but gain, exposure and many others. There is just no way to tell when they should take effect. FCam type applications requires this sort of functionality. URL:http://fcam.garage.maemo.org/ What we could also do, we could add an optional callback to subdev (core?) operations, which, if activated, the host would call on each frame completion. It's not quite that simple. The exposure of the next frame has started long time before that. This requires much more thought probably --- in the case of lack of hardware support, when the parameters need to be actually given to the sensor depend somewhat on sensors, I suppose. Yes, that's right. I seem to remember, there was a case, for which such a callback would have been useful... Don't remember what that was though. Flash and indicator power setting can be included to the list of controls above. As I replied to Laurent, not sure we need to control the power indicator from V4L2, unless there are sensors, that have support for that. Um, flash controllers, that is. Yes, there are; the ADP1653, which is just one example. No, not flash controllers, just an indicator, that a capture is running (normally a small red LED). That led is often controlled by the flash controller. And its power can be adjusted, too... The power management of the camera is preferrably optimised for speed so that the camera related devices need not to be power cycled when using it. If the flash interface is available on a subdev separately the flash can also be easily powered separately without making this a special case --- the rest of the camera related devices (ISP, lens and sensor) should stay powered off. configure the sensor to react on an external trigger provided by the flash controller is needed, and that could be a control on the flash sub-device. What we would probably miss is a way to issue a STREAMON with a number of frames to capture. A new ioctl is probably needed there. Maybe that would be an opportunity to create a new stream-control ioctl that could replace STREAMON and STREAMOFF in the long term (we could extend the subdev s_stream operation, and easily map STREAMON and STREAMOFF to the new ioctl in video_ioctl2 internally). How would this be different from queueing n frames (in total; count dequeueing, too) and issuing streamon? --- Except that when the last frame is processed the pipeline could be stopped already before issuing STREAMOFF. That does indeed have some benefits. Something else? Well, you usually see in your host driver, that the videobuffer queue is empty (no more free buffers are available), so, you stop streaming immediately too. That's right. Disabling streaming does save some power but even more is saved when switching the devices off completely. This is important in embedded systems that are often battery powered. The hardware could be switched off when no streaming takes place. However, this introduces extra delays to power-up at times they are unwanted --- for example, when switching from viewfinder to still capture. The alternative to this is to add a timer to the driver: power off if no streaming has taken place for n seconds, for
Re: [GIT PULL FOR 2.6.39] Media controller and OMAP3 ISP driver
Hi Sakari, On Sunday 06 March 2011 09:34:50 Sakari Ailus wrote: Hi Laurent, Many thanks for the pull req! On Thu, Feb 17, 2011 at 04:06:58PM +0100, Laurent Pinchart wrote: ... drivers/media/video/omap3-isp/ispresizer.c | 1693 ++ drivers/media/video/omap3-isp/ispresizer.h | 147 ++ drivers/media/video/omap3-isp/ispstat.c| 1092 + drivers/media/video/omap3-isp/ispstat.h| 169 ++ drivers/media/video/omap3-isp/ispvideo.c | 1264 ++ drivers/media/video/omap3-isp/ispvideo.h | 202 ++ drivers/media/video/omap3-isp/luma_enhance_table.h | 42 + drivers/media/video/omap3-isp/noise_filter_table.h | 30 + ... include/linux/Kbuild |4 + include/linux/media.h | 132 ++ include/linux/omap3isp.h | 646 + What about renaming the directory omap3isp for the sake of consistency? The header file is called omap3isp.h and omap3isp is the prefix used in the driver for exported symbols. I'm fine with both. If Mauro prefers omap3-isp, I can update the patches. My apologies for not bringing this up earlier. -- 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: [GIT PULL FOR 2.6.39] Media controller and OMAP3 ISP driver
Em 05-03-2011 20:23, Sylwester Nawrocki escreveu: Hi Mauro, On 03/05/2011 07:14 PM, Mauro Carvalho Chehab wrote: Em 05-03-2011 11:29, Sylwester Nawrocki escreveu: Hi David, On 03/05/2011 02:04 PM, David Cohen wrote: Hi Hans, On Sat, Mar 5, 2011 at 1:52 PM, Hans Verkuilhverk...@xs4all.nl wrote: On Friday, March 04, 2011 21:10:05 Mauro Carvalho Chehab wrote: Em 03-03-2011 07:25, Laurent Pinchart escreveu: ... v4l: Group media bus pixel codes by types and sort them alphabetically The presence of those mediabus names against the traditional fourcc codes at the API adds some mess to the media controller. Not sure how to solve, but maybe the best way is to add a table at the V4L2 API associating each media bus format to the corresponding V4L2 fourcc codes. You can't do that in general. Only for specific hardware platforms. If you could do it, then we would have never bothered creating these mediabus fourccs. How a mediabus fourcc translates to a pixelcode (== memory format) depends entirely on the hardware capabilities (mostly that of the DMA engine). May I ask you one question here? (not entirely related to this patch set). Why pixelcode != mediabus fourcc? e.g. OMAP2 camera driver talks to sensor through subdev interface and sets its own output pixelformat depending on sensor's mediabus fourcc. So it needs a translation table mbus_pixelcode - pixelformat. Why can't it be pixelformat - pixelformat ? Let me try to explain, struct v4l2_mbus_framefmt::code (pixelcode) describes how data is transfered/sampled on the camera parallel or serial bus. It defines bus width, data alignment and how many data samples form a single pixel. struct v4l2_pix_format::pixelformat (fourcc) on the other hand describes how the image data is stored in memory. As Hans pointed out there is not always a 1:1 correspondence, e.g. The relation may not be 1:1 but they are related. It should be documented somehow how those are related, otherwise, the API will be obscure. Yeah, I agree this is a good point now when the media bus formats have become public. Perhaps by a misunderstanding I just thought it is all more about some utility functions in the v4l core rather than the documentation. Yes, now you got my point. Of course, the output format may be different than the internal formats, since some bridges have format converters. 1. Both V4L2_MBUS_FMT_YUYV8_1x16 and V4L2_MBUS_FMT_YUYV8_2x8 may being translating to V4L2_PIX_FMT_YUYV fourcc, Ok, so there is a relationship between them. 2. Or the DMA engine in the camera host interface might be capable of converting single V4L2_MBUS_FMT_RGB555 pixelcode to V4L2_PIX_FMT_RGB555 and V4L2_PIX_FMT_RGB565 fourcc's. So the user can choose any of them they seem most suitable and the hardware takes care of the conversion. No. You can't create an additional bit. if V4L2_MBUS_FMT_RGB555 provides 5 bits for all color channels, the only corresponding format is V4L2_PIX_FMT_RGB555, as there's no way to get 6 bits for green, if the hardware sampled it with 5 bits. Ok, some bridge may fill with 0 an extra bit for green, but this is the bridge doing a format conversion. In general, for all RGB formats, a mapping between MBUS_FMT_RGBxxx and the corresponding fourcc formats could be mapped on two formats only: V4L2_PIX_FMT_RGBxxx or V4L2_PIX_FMT_BGRxxx. OK, that might not have been a good example, of one mbus pixel code to many fourccs relationship. There will be always conversion between media bus pixelcode and fourccs as they are in completely different domains. And the method of conversion from media bus formats may be an intrinsic property of a bridge, changing across various bridges, e.g. different endianness may be used. So I think in general it is good to clearly specify the relationships in the API but we need to be aware of varying correlation ratio across the formats and that we should perhaps operate on ranges rather than single formats. Perhaps the API should provide guidelines of which formats should be used when to obtain best results. It makes sense to operate in ranges are you're proposing. A somewhat unrelated question that occurred to me today: what happens when a format change happens while streaming? Considering that some formats need more bits than others, this could lead into buffer overflows, either internally at the device or externally, on bridges that just forward whatever it receives to the DMA buffers (there are some that just does that). I didn't see anything inside the mc code preventing such condition to happen, and probably implementing it won't be an easy job. So, one alternative would be to require some special CAPS if userspace tries to set the mbus format directly, or to recommend userspace to create media controller nodes with 0600 permission. Comments? Thanks, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the
NCT 677x lirc driver for Asrock 330HT and others
Hi ! Note sure where exactly to put it. Here is an lirc driver provided by Nuovoton as it seems, which can be downloaded from the vendors site: http://www.asrock.com/Nettop/download.asp?Model=ION%20330HTo=Linux It adds an lirc driver for the receiver as used in the Asrock 330HT and newer models from Asrock. Can this go into lirc, or better, can something be done to integrate it somehow ? Kind Regards Steffen -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] dib0700: get rid of on-stack dma buffers
This should fix warnings seen by some:
WARNING: at lib/dma-debug.c:866 check_for_stack
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=15977.
Reported-by: Zdenek Kabelac zdenek.kabe...@gmail.com
Signed-off-by: Florian Mickler flor...@mickler.org
CC: Mauro Carvalho Chehab mche...@infradead.org
CC: linux-media@vger.kernel.org
CC: linux-ker...@vger.kernel.org
CC: Greg Kroah-Hartman g...@kroah.com
CC: Rafael J. Wysocki r...@sisk.pl
CC: Maciej Rutecki maciej.rute...@gmail.com
---
Please take a look at it, as I do not do that much kernel hacking
and don't wanna brake anybodys computer... :)
From my point of view this should _not_ go to stable even though it would
be applicable. But if someone feels strongly about that and can
take responsibility for that change...
drivers/media/dvb/dvb-usb/dib0700_core.c | 121 +++---
1 files changed, 94 insertions(+), 27 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c
b/drivers/media/dvb/dvb-usb/dib0700_core.c
index 98ffb40..1a12182 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_core.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_core.c
@@ -27,11 +27,17 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
int dib0700_get_version(struct dvb_usb_device *d, u32 *hwversion,
u32 *romversion, u32 *ramversion, u32 *fwtype)
{
- u8 b[16];
- int ret = usb_control_msg(d-udev, usb_rcvctrlpipe(d-udev, 0),
+ int ret;
+ u8 *b;
+
+ b = kmalloc(16, GFP_KERNEL);
+ if (!b)
+ return -ENOMEM;
+
+ ret = usb_control_msg(d-udev, usb_rcvctrlpipe(d-udev, 0),
REQUEST_GET_VERSION,
USB_TYPE_VENDOR | USB_DIR_IN, 0, 0,
- b, sizeof(b), USB_CTRL_GET_TIMEOUT);
+ b, 16, USB_CTRL_GET_TIMEOUT);
if (hwversion != NULL)
*hwversion = (b[0] 24) | (b[1] 16) | (b[2] 8) |
b[3];
if (romversion != NULL)
@@ -40,6 +46,8 @@ int dib0700_get_version(struct dvb_usb_device *d, u32
*hwversion,
*ramversion = (b[8] 24) | (b[9] 16) | (b[10] 8) |
b[11];
if (fwtype != NULL)
*fwtype = (b[12] 24) | (b[13] 16) | (b[14] 8) |
b[15];
+
+ kfree(b);
return ret;
}
@@ -101,8 +109,19 @@ int dib0700_ctrl_rd(struct dvb_usb_device *d, u8 *tx, u8
txlen, u8 *rx, u8 rxlen
int dib0700_set_gpio(struct dvb_usb_device *d, enum dib07x0_gpios gpio, u8
gpio_dir, u8 gpio_val)
{
- u8 buf[3] = { REQUEST_SET_GPIO, gpio, ((gpio_dir 0x01) 7) |
((gpio_val 0x01) 6) };
- return dib0700_ctrl_wr(d, buf, sizeof(buf));
+ s16 ret;
+ u8 *buf = kmalloc(3, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ buf[0] = REQUEST_SET_GPIO;
+ buf[1] = gpio;
+ buf[2] = ((gpio_dir 0x01) 7) | ((gpio_val 0x01) 6);
+
+ ret = dib0700_ctrl_wr(d, buf, sizeof(buf));
+
+ kfree(buf);
+ return ret;
}
static int dib0700_set_usb_xfer_len(struct dvb_usb_device *d, u16
nb_ts_packets)
@@ -141,13 +160,20 @@ static int dib0700_i2c_xfer_new(struct i2c_adapter *adap,
struct i2c_msg *msg,
uint8_t gen_mode = 0; /* 0=master i2c, 1=gpio i2c */
uint8_t en_start = 0;
uint8_t en_stop = 0;
- uint8_t buf[255]; /* TBV: malloc ? */
+ uint8_t *buf;
int result, i;
+ buf = kmalloc(255, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
/* Ensure nobody else hits the i2c bus while we're sending our
sequence of messages, (such as the remote control thread) */
- if (mutex_lock_interruptible(d-i2c_mutex) 0)
- return -EAGAIN;
+ if (mutex_lock_interruptible(d-i2c_mutex) 0) {
+ result = -EAGAIN;
+ goto out;
+ }
+
for (i = 0; i num; i++) {
if (i == 0) {
@@ -220,8 +246,12 @@ static int dib0700_i2c_xfer_new(struct i2c_adapter *adap,
struct i2c_msg *msg,
}
}
}
+ result = i;
mutex_unlock(d-i2c_mutex);
- return i;
+
+out:
+ kfree(buf);
+ return result;
}
/*
@@ -232,10 +262,17 @@ static int dib0700_i2c_xfer_legacy(struct i2c_adapter
*adap,
{
struct dvb_usb_device *d = i2c_get_adapdata(adap);
int i,len;
- u8 buf[255];
+ s16 ret;
+ u8 *buf;
- if (mutex_lock_interruptible(d-i2c_mutex) 0)
- return -EAGAIN;
+ buf = kmalloc(255, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ if (mutex_lock_interruptible(d-i2c_mutex) 0) {
+ ret = -EAGAIN;
+ goto out;
+ }
for (i = 0; i num; i++) {
/* fill in the address */
@@ -264,9 +301,11 @@ static int dib0700_i2c_xfer_legacy(struct i2c_adapter
*adap,
break;
}
}
-
+ ret = i;
Re: [GIT PULL FOR 2.6.39] Media controller and OMAP3 ISP driver
Hi Mauro, On Sunday 06 March 2011 11:56:04 Mauro Carvalho Chehab wrote: Em 05-03-2011 20:23, Sylwester Nawrocki escreveu: A somewhat unrelated question that occurred to me today: what happens when a format change happens while streaming? Considering that some formats need more bits than others, this could lead into buffer overflows, either internally at the device or externally, on bridges that just forward whatever it receives to the DMA buffers (there are some that just does that). I didn't see anything inside the mc code preventing such condition to happen, and probably implementing it won't be an easy job. So, one alternative would be to require some special CAPS if userspace tries to set the mbus format directly, or to recommend userspace to create media controller nodes with 0600 permission. That's not really a media controller issue. Whether formats can be changed during streaming is a driver decision. The OMAP3 ISP driver won't allow formats to be changed during streaming. If the hardware allows for such format changes, drivers can implement support for that and make sure that no buffer overflow will occur. -- 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: Patches an media build tree
Hi Steffen, On Sat, Mar 5, 2011 at 9:13 PM, Steffen Barszus steffenbpu...@googlemail.com wrote: On Sun, 16 Jan 2011 16:37:38 -0200 Mauro Carvalho Chehab mche...@redhat.com wrote: Em 15-01-2011 11:46, Helmut Auer escreveu: Hello List How long does it usually take til patches are integrated into the media build tree ( after posting these here ) ? I'm just wondering because I miss some patches posted here. It takes as much it needs for the driver maintainer to look into it, and for me to have time to handle them. The pending patches are always at: https://patchwork.kernel.org/project/linux-media/list/ Please note that, by default, Patchwork filters the patches to display only the ones marked as New or Under Review. If you want to see all patches, you need to change the state filter to show all patches: https://patchwork.kernel.org/project/linux-media/list/?state=* If the patch you're waiting are marked as Under Review, you should ping the driver maintainer, as I'm waiting for his review. If it is new, that means that I didn't have time yet to dig into it. Can you please check these patches ? What is missing ? Something to be corrected ? What happens to orphaned drivers ? Manu are you still working on this ? Manu , Mauro please comment ! Thanks ! Avoid unnecessary data copying inside dvb_dmx_swfilter_204() function 2010-08-07 Marko Ristola Under Review Refactor Mantis DMA transfer to deliver 16Kb TS data per interrupt 2010-08-07 Marko Ristola Under Review I had tried this patch a while back, but due to some reason it was causing a complete freeze at my side: it could have been due to a different version of the bridge or so, But it wasn't really easy on my side to ascertain that. That time looking at the patch it wasn't easy to identify the reason as well. I need to retry the same again, with a cooler head as to see what happens. [v2] V4L/DVB: faster DVB-S lock for mantis cards using stb0899 demod 2010-10-10 Tuxoholic Under Review I was under the assumption that this issue was fixed in the right way, with the fix being applied to the stb6100 driver sometime back. Was your test with that fix in ? Best Regards, Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] Fix AF9015 Dual tuner i2c write failures
2011/3/5 adq a...@lidskialf.net: 2011/3/5 Juan Jesús García de Soria Lucena skanda...@gmail.com: Hi, Andrew. This is what happens to me with both the KWorld dual tuner (when using only one tuner) and the Avermedia Volar Black (single tuner), both based on AF9015. I also got corrupted streams with the KWorld when capturing via both tuners (the video our the audio would show artifacts in mythtv each several seconds). As far as the loss of tuning ability goes, I think it's a problem related to tuning itself, since it wouldn't happen when you just left a channel tuned and streaming in a simple client, but would trigger after a random time when you left mythtv scanning the channels for EIT data. I don't think it's a problem with a specific HW implementation, since I got it with both AF9015-based cards. It could be either a chipset quirk our a bug in the driver. My informal and quick tests with Windows Media Center and these cards did not reproduce the problem, when trying to change channels as quickly as possible, admittedly for not so long a time. Correct. I have two af9015 cards from different manufacturers as well, and they both exhibit the same problem. However, on a hunch last night, I went back to my original (-v1) patch with the total i2c bus lock and left it running with my tuning scripts for 10 hours. Both tuners are still working fine. That isn't conclusive, but it is encouraging. I'm just swapping back to a completely unpatched state to see how long it takes to break and to check if its easily reproducible (on my live system, it usually does it within a few hours of normal usage). Hi, right, I can reproduce it when completely unpatched, but it takes a while. I left HTS tvheadend running at the same time as dvbsnoop monitoring each frontend's status (so I had lots of i2c traffic going on), and it happened sometime overnight. I turned on all the idle scanning and frontend monitoring features tvheadend has. Now trying running the same with the -v1 patch. -- 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] [media] dib0700: get rid of on-stack dma buffers
Am Sonntag, 6. März 2011, 12:16:52 schrieb Florian Mickler: This should fix warnings seen by some: WARNING: at lib/dma-debug.c:866 check_for_stack Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=15977. Reported-by: Zdenek Kabelac zdenek.kabe...@gmail.com Signed-off-by: Florian Mickler flor...@mickler.org CC: Mauro Carvalho Chehab mche...@infradead.org CC: linux-media@vger.kernel.org CC: linux-ker...@vger.kernel.org CC: Greg Kroah-Hartman g...@kroah.com CC: Rafael J. Wysocki r...@sisk.pl CC: Maciej Rutecki maciej.rute...@gmail.com --- Please take a look at it, as I do not do that much kernel hacking and don't wanna brake anybodys computer... :) From my point of view this should _not_ go to stable even though it would be applicable. But if someone feels strongly about that and can take responsibility for that change... The patch looks good and is needed in stable. It could be improved by using a buffer allocated once in the places you hold a mutex anyway. Regards Oliver -- 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 AF9015 Dual tuner i2c write failures
2011/3/6 adq a...@lidskialf.net: 2011/3/5 adq a...@lidskialf.net: 2011/3/5 Juan Jesús García de Soria Lucena skanda...@gmail.com: Hi, Andrew. This is what happens to me with both the KWorld dual tuner (when using only one tuner) and the Avermedia Volar Black (single tuner), both based on AF9015. I also got corrupted streams with the KWorld when capturing via both tuners (the video our the audio would show artifacts in mythtv each several seconds). As far as the loss of tuning ability goes, I think it's a problem related to tuning itself, since it wouldn't happen when you just left a channel tuned and streaming in a simple client, but would trigger after a random time when you left mythtv scanning the channels for EIT data. I don't think it's a problem with a specific HW implementation, since I got it with both AF9015-based cards. It could be either a chipset quirk our a bug in the driver. My informal and quick tests with Windows Media Center and these cards did not reproduce the problem, when trying to change channels as quickly as possible, admittedly for not so long a time. Correct. I have two af9015 cards from different manufacturers as well, and they both exhibit the same problem. However, on a hunch last night, I went back to my original (-v1) patch with the total i2c bus lock and left it running with my tuning scripts for 10 hours. Both tuners are still working fine. That isn't conclusive, but it is encouraging. I'm just swapping back to a completely unpatched state to see how long it takes to break and to check if its easily reproducible (on my live system, it usually does it within a few hours of normal usage). Hi, right, I can reproduce it when completely unpatched, but it takes a while. I left HTS tvheadend running at the same time as dvbsnoop monitoring each frontend's status (so I had lots of i2c traffic going on), and it happened sometime overnight. I turned on all the idle scanning and frontend monitoring features tvheadend has. Now trying running the same with the -v1 patch. Another issue I've noticed just now: The UCBLOCKS measure isn't reset: it seems to be an accumulative counter, which isn't correct from the DVB API (if I remember correctly). This explains why tvheadend's quallity measure gradually tends to 0, since it is assuming UCBLOCKS is non-accumulative. -- 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 PATCHES FOR 2.6.39] Fix compile error/warnings
A bunch of trivial compile fixes for 2.6.39. Regards, Hans The following changes since commit 88a763df226facb74fdb254563e30e9efb64275c: [media] dw2102: prof 1100 corrected (2011-03-02 16:56:54 -0300) are available in the git repository at: ssh://linuxtv.org/git/hverkuil/media_tree.git fixes Hans Verkuil (6): tuner-xc2028.c: fix compile warning stv0367.c: fix compiler warning altera-ci.c: fix compiler warnings fmdrv_common.c: fix compiler warning cx88-alsa: fix compiler warning mantis_pci.c: fix ARM compile error. drivers/media/common/tuners/tuner-xc2028.c |4 ++-- drivers/media/dvb/frontends/stv0367.c |2 +- drivers/media/dvb/mantis/mantis_pci.c |1 + drivers/media/radio/wl128x/fmdrv_common.c |4 ++-- drivers/media/video/cx23885/altera-ci.c|8 drivers/media/video/cx88/cx88-alsa.c |2 +- 6 files changed, 11 insertions(+), 10 deletions(-) -- 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
Re: [GIT PATCHES FOR 2.6.39] Fix compile error/warnings
On Sunday, March 06, 2011 13:43:32 Hans Verkuil wrote: A bunch of trivial compile fixes for 2.6.39. Regards, Hans Added one more: altera-ci.h: add missing inline Regards, Hans The following changes since commit 88a763df226facb74fdb254563e30e9efb64275c: [media] dw2102: prof 1100 corrected (2011-03-02 16:56:54 -0300) are available in the git repository at: ssh://linuxtv.org/git/hverkuil/media_tree.git fixes Hans Verkuil (6): tuner-xc2028.c: fix compile warning stv0367.c: fix compiler warning altera-ci.c: fix compiler warnings fmdrv_common.c: fix compiler warning cx88-alsa: fix compiler warning mantis_pci.c: fix ARM compile error. drivers/media/common/tuners/tuner-xc2028.c |4 ++-- drivers/media/dvb/frontends/stv0367.c |2 +- drivers/media/dvb/mantis/mantis_pci.c |1 + drivers/media/radio/wl128x/fmdrv_common.c |4 ++-- drivers/media/video/cx23885/altera-ci.c|8 drivers/media/video/cx88/cx88-alsa.c |2 +- 6 files changed, 11 insertions(+), 10 deletions(-) -- 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
Re: Patches an media build tree
On Sun, 6 Mar 2011 17:23:11 +0530 Manu Abraham abraham.m...@gmail.com wrote: Hi Steffen, Hi Manu , thx for the reply :) On Sat, Mar 5, 2011 at 9:13 PM, Steffen Barszus Manu , Mauro please comment ! Thanks ! Avoid unnecessary data copying inside dvb_dmx_swfilter_204() function 2010-08-07 Marko Ristola Under Review Refactor Mantis DMA transfer to deliver 16Kb TS data per interrupt 2010-08-07 Marko Ristola Under Review I had tried this patch a while back, but due to some reason it was causing a complete freeze at my side: it could have been due to a different version of the bridge or so, But it wasn't really easy on my side to ascertain that. That time looking at the patch it wasn't easy to identify the reason as well. I need to retry the same again, with a cooler head as to see what happens. That would be good, as far as i remember - the issue is, without these patches the driver crashes after a while caused by vdr's excessive use by EIT scanner. So it can only be used without EPG scan enabled. With that it was running stable. There have been a few different patches floating around to address this issue. [v2] V4L/DVB: faster DVB-S lock for mantis cards using stb0899 demod 2010-10-10 Tuxoholic Under Review I was under the assumption that this issue was fixed in the right way, with the fix being applied to the stb6100 driver sometime back. Was your test with that fix in ? Think i did not put it into relation. Let me get to the users of the cards, to test the current dkms [1] w/o any patches and confirm back to you whats current situation It was this one: commit f14bfe94e459cb070a489e1786f26d54e9e7b5de Author: Manu Abraham abraham.m...@gmail.com Date: Sun Nov 14 15:52:10 2010 -0300 [media] stb6100: Improve tuner performance right ? Kind Regards Steffen [1] Test version of the dkms, need to remove above named patches tomorrow. Will remove the above patches again for testing, then its except for a small fix for more then on TT S2 1600 plain media_tree. https://launchpad.net/~yavdr/+archive/testing-vdr/+packages?field.name_filter=v4l-dvb-dkmsfield.status_filter=publishedfield.series_filter= -- 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 AF9015 Dual tuner i2c write failures
On 03/06/2011 02:24 PM, adq wrote: Another issue I've noticed just now: The UCBLOCKS measure isn't reset: it seems to be an accumulative counter, which isn't correct from the DVB API (if I remember correctly). This explains why tvheadend's quallity measure gradually tends to 0, since it is assuming UCBLOCKS is non-accumulative. 2.2.7 FE READ UNCORRECTED BLOCKS DESCRIPTION This ioctl call returns the number of uncorrected blocks detected by the device driver during its lifetime. For meaningful measurements, the incrementin block count during a specific time interval should be calculated. For this command, read-only access to the device is sufficient. Note that the counter will wrap to zero after its maximum count has been reached. Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] Fix AF9015 Dual tuner i2c write failures
2011/3/6 Antti Palosaari cr...@iki.fi: On 03/06/2011 02:24 PM, adq wrote: Another issue I've noticed just now: The UCBLOCKS measure isn't reset: it seems to be an accumulative counter, which isn't correct from the DVB API (if I remember correctly). This explains why tvheadend's quallity measure gradually tends to 0, since it is assuming UCBLOCKS is non-accumulative. 2.2.7 FE READ UNCORRECTED BLOCKS DESCRIPTION This ioctl call returns the number of uncorrected blocks detected by the device driver during its lifetime. For meaningful measurements, the incrementin block count during a specific time interval should be calculated. For this command, read-only access to the device is sufficient. Note that the counter will wrap to zero after its maximum count has been reached. (this time to the list as well) Hah! Sorry, its been a while :) In that case, I need to look at the tvheadend source. -- 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
patches missing in git ? - TT S2 1600
I have one patch lying around which will fix a kernel oops if more than
one TT S2 1600 is build into the same computer.
It still applies and compiles - does someone know if this has been
obsoleted by another patch or if that means it is still missing ?
Thanks !
Kind Regards
Steffen
diff -r 7c0b887911cf linux/drivers/media/dvb/frontends/stv090x.c
--- a/linux/drivers/media/dvb/frontends/stv090x.c Mon Apr 05 22:56:43
2010 -0400
+++ b/linux/drivers/media/dvb/frontends/stv090x.c Sun Apr 11 13:46:43
2010 +0200
@@ -4664,7 +4664,7 @@
if (stv090x_i2c_gate_ctrl(state, 1) 0)
goto err;
- if (state-config-tuner_sleep) {
+ if (fe-tuner_priv state-config-tuner_sleep) {
if (state-config-tuner_sleep(fe) 0)
goto err_gateoff;
}
--
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: [GIT PULL FOR 2.6.39] Media controller and OMAP3 ISP driver
Em 06-03-2011 08:38, Laurent Pinchart escreveu:
Hi Mauro,
On Sunday 06 March 2011 11:56:04 Mauro Carvalho Chehab wrote:
Em 05-03-2011 20:23, Sylwester Nawrocki escreveu:
A somewhat unrelated question that occurred to me today: what happens when
a format change happens while streaming?
Considering that some formats need more bits than others, this could lead
into buffer overflows, either internally at the device or externally, on
bridges that just forward whatever it receives to the DMA buffers (there
are some that just does that). I didn't see anything inside the mc code
preventing such condition to happen, and probably implementing it won't be
an easy job. So, one alternative would be to require some special CAPS if
userspace tries to set the mbus format directly, or to recommend userspace
to create media controller nodes with 0600 permission.
That's not really a media controller issue. Whether formats can be changed
during streaming is a driver decision. The OMAP3 ISP driver won't allow
formats to be changed during streaming. If the hardware allows for such
format
changes, drivers can implement support for that and make sure that no buffer
overflow will occur.
Such issues is caused by having two API's that allow format changes, one that
does it device-based, and another one doing it subdev-based.
Ok, drivers can implementing locks to prevent such troubles, but, without
the core providing a reliable mechanism, it is hard to implement a
correct lock.
For example, let's suppose that some driver is using mt9m111 subdev (I just
picked
one random sensor that supports lots of MBUS formats). There's nothing
there preventing a subdev call for it to change mbus format while streaming.
Worse than that, the sensor driver has no way to block it, as it doesn't
know that the bridge driver is streaming or not.
The code at subdev_do_ioctl() is just:
case VIDIOC_SUBDEV_S_FMT: {
struct v4l2_subdev_format *format = arg;
if (format-which != V4L2_SUBDEV_FORMAT_TRY
format-which != V4L2_SUBDEV_FORMAT_ACTIVE)
return -EINVAL;
if (format-pad = sd-entity.num_pads)
return -EINVAL;
return v4l2_subdev_call(sd, pad, set_fmt, subdev_fh, format);
}
So, mc core won't be preventing it.
So, I can't see how such subdev request would be implementing a logic to
return -EBUSY on those cases.
Mauro.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 1/2] [media] stv0367: signedness bug in stv0367_get_tuner_freq()
We use err to store negative error codes so it should be signed. And if we return an error from stv0367_get_tuner_freq() that needs to be handled properly as well. (param-frequency is a u32). Signed-off-by: Dan Carpenter erro...@gmail.com diff --git a/drivers/media/dvb/frontends/stv0367.c b/drivers/media/dvb/frontends/stv0367.c index eecdf23..7117ce9 100644 --- a/drivers/media/dvb/frontends/stv0367.c +++ b/drivers/media/dvb/frontends/stv0367.c @@ -913,7 +913,7 @@ static u32 stv0367_get_tuner_freq(struct dvb_frontend *fe) struct dvb_frontend_ops *frontend_ops = NULL; struct dvb_tuner_ops*tuner_ops = NULL; u32 freq = 0; - u32 err = 0; + int err = 0; dprintk(%s:\n, __func__); diff --git a/drivers/media/dvb/frontends/stv0367.c b/drivers/media/dvb/frontends/stv0367.c index ec9de40..1304618 100644 --- a/drivers/media/dvb/frontends/stv0367.c +++ b/drivers/media/dvb/frontends/stv0367.c @@ -1940,7 +1940,7 @@ static int stv0367ter_get_frontend(struct dvb_frontend *fe, int constell = 0,/* snr = 0,*/ Data = 0; param-frequency = stv0367_get_tuner_freq(fe); - if (param-frequency 0) + if ((int)param-frequency 0) param-frequency = c-frequency; constell = stv0367_readbits(state, F367TER_TPS_CONST); -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2/2] [media] stv0367: typo in function parameter
The CellsCoeffs arrays are [3][6][5] not [2][6][5].
Signed-off-by: Dan Carpenter erro...@gmail.com
diff --git a/drivers/media/dvb/frontends/stv0367.c
b/drivers/media/dvb/frontends/stv0367.c
index 7117ce9..ec9de40 100644
--- a/drivers/media/dvb/frontends/stv0367.c
+++ b/drivers/media/dvb/frontends/stv0367.c
@@ -1046,7 +1046,7 @@ static u32 stv0367ter_get_mclk(struct stv0367_state
*state, u32 ExtClk_Hz)
}
static int stv0367ter_filt_coeff_init(struct stv0367_state *state,
- u16 CellsCoeffs[2][6][5], u32 DemodXtal)
+ u16 CellsCoeffs[3][6][5], u32 DemodXtal)
{
int i, j, k, freq;
--
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] [media] dib0700: get rid of on-stack dma buffers
On 06/03/2011 11:16, Florian Mickler wrote:
This should fix warnings seen by some:
WARNING: at lib/dma-debug.c:866 check_for_stack
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=15977.
Reported-by: Zdenek Kabelac zdenek.kabe...@gmail.com
Signed-off-by: Florian Mickler flor...@mickler.org
CC: Mauro Carvalho Chehab mche...@infradead.org
CC: linux-media@vger.kernel.org
CC: linux-ker...@vger.kernel.org
CC: Greg Kroah-Hartman g...@kroah.com
CC: Rafael J. Wysocki r...@sisk.pl
CC: Maciej Rutecki maciej.rute...@gmail.com
---
@@ -101,8 +109,19 @@ int dib0700_ctrl_rd(struct dvb_usb_device *d, u8 *tx, u8
txlen, u8 *rx, u8 rxlen
int dib0700_set_gpio(struct dvb_usb_device *d, enum dib07x0_gpios gpio, u8
gpio_dir, u8 gpio_val)
{
- u8 buf[3] = { REQUEST_SET_GPIO, gpio, ((gpio_dir 0x01) 7) |
((gpio_val 0x01) 6) };
- return dib0700_ctrl_wr(d, buf, sizeof(buf));
+ s16 ret;
+ u8 *buf = kmalloc(3, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ buf[0] = REQUEST_SET_GPIO;
+ buf[1] = gpio;
+ buf[2] = ((gpio_dir 0x01) 7) | ((gpio_val 0x01) 6);
+
+ ret = dib0700_ctrl_wr(d, buf, sizeof(buf));
Shouldn't this sizeof be changed as well?
Thanks,
Jack
--
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] [media] dib0700: get rid of on-stack dma buffers
On Sun, 06 Mar 2011 13:49:56 +
Jack Stone jwjst...@fastmail.fm wrote:
On 06/03/2011 11:16, Florian Mickler wrote:
This should fix warnings seen by some:
WARNING: at lib/dma-debug.c:866 check_for_stack
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=15977.
Reported-by: Zdenek Kabelac zdenek.kabe...@gmail.com
Signed-off-by: Florian Mickler flor...@mickler.org
CC: Mauro Carvalho Chehab mche...@infradead.org
CC: linux-media@vger.kernel.org
CC: linux-ker...@vger.kernel.org
CC: Greg Kroah-Hartman g...@kroah.com
CC: Rafael J. Wysocki r...@sisk.pl
CC: Maciej Rutecki maciej.rute...@gmail.com
---
@@ -101,8 +109,19 @@ int dib0700_ctrl_rd(struct dvb_usb_device *d, u8 *tx,
u8 txlen, u8 *rx, u8 rxlen
int dib0700_set_gpio(struct dvb_usb_device *d, enum dib07x0_gpios gpio, u8
gpio_dir, u8 gpio_val)
{
- u8 buf[3] = { REQUEST_SET_GPIO, gpio, ((gpio_dir 0x01) 7) |
((gpio_val 0x01) 6) };
- return dib0700_ctrl_wr(d, buf, sizeof(buf));
+ s16 ret;
+ u8 *buf = kmalloc(3, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ buf[0] = REQUEST_SET_GPIO;
+ buf[1] = gpio;
+ buf[2] = ((gpio_dir 0x01) 7) | ((gpio_val 0x01) 6);
+
+ ret = dib0700_ctrl_wr(d, buf, sizeof(buf));
Shouldn't this sizeof be changed as well?
Thanks,
Jack
argh... indeed.
--
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
analog sound on Mygica X8506
Hi all First of all, please if I'm on the wrong list tell me which is correct. I bought a new TV-card MyGica X8507 if I set it up as DMB-TH Mygica X8506 card 22 analog TV I can see but not hear. Can you help me to configure this card so I can listen? I hope that soon this support and can also see digital television. Thanks in advance http://www.linuxtv.org/wiki/index.php/Geniatech/MyGica_X8507_PCI-Express_Hybrid_Card dmesg [8.769368] Linux video capture interface: v2.00 [8.782879] cx23885 driver version 0.0.2 loaded [8.784037] cx23885 :02:00.0: PCI INT A - GSI 19 (level, low) - IRQ 19 [8.784041] cx23885[0]/0: cx23885_dev_setup() Memory configured for PCIe bridge type 885 [8.784043] cx23885[0]/0: cx23885_init_tsport(portno=1) [8.784223] CORE cx23885[0]: subsystem: 14f1:8502, board: Mygica X8506 DMB-TH [card=22,insmod option] [8.784226] cx23885[0]/0: cx23885_pci_quirks() [8.784230] cx23885[0]/0: cx23885_dev_setup() tuner_type = 0x4c tuner_addr = 0x61 [8.784233] cx23885[0]/0: cx23885_dev_setup() radio_type = 0x0 radio_addr = 0x0 [8.784235] cx23885[0]/0: cx23885_reset() [8.892926] cx23885[0]/0: cx23885_sram_channel_setup() Configuring channel [VID A] [8.892930] cx23885[0]/0: cx23885_sram_channel_setup() Erasing channel [ch2] [8.892932] cx23885[0]/0: cx23885_sram_channel_setup() Configuring channel [TS1 B] [8.892935] cx23885[0]/0: cx23885_sram_channel_setup() Erasing channel [ch4] [8.892937] cx23885[0]/0: cx23885_sram_channel_setup() Erasing channel [ch5] [8.892939] cx23885[0]/0: cx23885_sram_channel_setup() Configuring channel [TS2 C] [8.892953] cx23885[0]/0: cx23885_sram_channel_setup() Erasing channel [ch7] [8.892955] cx23885[0]/0: cx23885_sram_channel_setup() Erasing channel [ch8] [8.892957] cx23885[0]/0: cx23885_sram_channel_setup() Erasing channel [ch9] [9.131075] cx23885[0]: scan bus 0: [9.133467] cx23885[0]: i2c scan: found device @ 0x20 [???] [9.138377] cx23885[0]: i2c scan: found device @ 0x66 [???] [9.144733] cx23885[0]: i2c scan: found device @ 0xa0 [eeprom] [9.144876] cx23885[0]: i2c scan: found device @ 0xa2 [???] [9.146071] cx23885[0]: i2c scan: found device @ 0xa4 [???] [9.146214] cx23885[0]: i2c scan: found device @ 0xa6 [???] [9.146355] cx23885[0]: i2c scan: found device @ 0xa8 [???] [9.146496] cx23885[0]: i2c scan: found device @ 0xaa [???] [9.146637] cx23885[0]: i2c scan: found device @ 0xac [???] [9.146778] cx23885[0]: i2c scan: found device @ 0xae [???] [9.152627] cx23885[0]: scan bus 1: [9.168325] cx23885[0]: i2c scan: found device @ 0xc2 [tuner/mt2131/tda8275/xc5000/xc3028] [9.173738] cx23885[0]: scan bus 2: [9.184143] cx23885[0]: i2c scan: found device @ 0x66 [???] [9.184795] cx23885[0]: i2c scan: found device @ 0x88 [cx25837] [9.185099] cx23885[0]: i2c scan: found device @ 0x98 [???] [9.292405] cx25840 5-0044: cx23885 A/V decoder found @ 0x88 (cx23885[0]) [9.302242] cx25840 5-0044: firmware: requesting v4l-cx23885-avcore-01.fw [ 10.374232] cx25840 5-0044: loaded v4l-cx23885-avcore-01.fw firmware (16382 bytes) [ 10.380657] cx23885[0]/0: cx23885_video_register() [ 10.382438] tuner 4-0061: chip found @ 0xc2 (cx23885[0]) [ 10.553069] xc5000 4-0061: creating new instance [ 10.553766] xc5000: Successfully identified at address 0x61 [ 10.553768] xc5000: Firmware has not been loaded previously [ 10.553770] cx23885[0]/0: cx23885_vdev_init() [ 10.553828] cx23885[0]/0: registered device video1 [v4l2] [ 10.553831] cx23885[0]/0: cx23885_set_tvnorm(norm = 0x1000) name: [NTSC-M] [ 10.559271] xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... [ 10.559274] cx23885 :02:00.0: firmware: requesting dvb-fe-xc5000-1.6.114.fw [ 10.692589] xc5000: firmware read 12401 bytes. [ 10.692591] xc5000: firmware uploading... [ 12.066004] xc5000: firmware upload complete... [ 12.707015] cx23885[0]/0: cx23885_set_control() calling cx25840(VIDIOC_S_CTRL) (disabled - no action) [ 12.707017] cx23885[0]/0: cx23885_set_control() calling cx25840(VIDIOC_S_CTRL) (disabled - no action) [ 12.707019] cx23885[0]/0: cx23885_set_control() calling cx25840(VIDIOC_S_CTRL) (disabled - no action) [ 12.707022] cx23885[0]/0: cx23885_set_control() calling cx25840(VIDIOC_S_CTRL) (disabled - no action) [ 12.707024] cx23885[0]/0: cx23885_set_control() calling cx25840(VIDIOC_S_CTRL) (disabled - no action) [ 12.707026] cx23885[0]/0: cx23885_set_control() calling cx25840(VIDIOC_S_CTRL) (disabled - no action) [ 12.707029] cx23885[0]/0: cx23885_video_mux() video_mux: 0 [vmux=2, gpio=0x0,0x0,0x0,0x0] [ 12.711091] cx23885_dvb_register() allocating 1 frontend(s) [ 12.711094] cx23885[0]: cx23885 based dvb card [ 12.750805] xc5000 4-0061: attaching existing instance [
Re: [PATCH] [media] dib0700: get rid of on-stack dma buffers
On Sun, 6 Mar 2011 13:06:09 +0100 Oliver Neukum oli...@neukum.org wrote: Am Sonntag, 6. März 2011, 12:16:52 schrieb Florian Mickler: This should fix warnings seen by some: WARNING: at lib/dma-debug.c:866 check_for_stack Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=15977. Reported-by: Zdenek Kabelac zdenek.kabe...@gmail.com Signed-off-by: Florian Mickler flor...@mickler.org CC: Mauro Carvalho Chehab mche...@infradead.org CC: linux-media@vger.kernel.org CC: linux-ker...@vger.kernel.org CC: Greg Kroah-Hartman g...@kroah.com CC: Rafael J. Wysocki r...@sisk.pl CC: Maciej Rutecki maciej.rute...@gmail.com --- Please take a look at it, as I do not do that much kernel hacking and don't wanna brake anybodys computer... :) From my point of view this should _not_ go to stable even though it would be applicable. But if someone feels strongly about that and can take responsibility for that change... The patch looks good and is needed in stable. It could be improved by using a buffer allocated once in the places you hold a mutex anyway. Regards Oliver Ok, I now put a buffer member in the priv dib0700_state which gets allocated on the heap. My patch introduces a new error condition in the dib0700_identify_state callback which gets not checked for in dvb_usb_find_device... Should we worry? Same for dib0700_get_version in the probe callback... But there, there was already the possibility of usb_control_msg returning an error... Regards, Flo -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3 v2] [media] dib0700: get rid of on-stack dma buffers
This should fix warnings seen by some:
WARNING: at lib/dma-debug.c:866 check_for_stack
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=15977.
Reported-by: Zdenek Kabelac zdenek.kabe...@gmail.com
Signed-off-by: Florian Mickler flor...@mickler.org
CC: Mauro Carvalho Chehab mche...@infradead.org
CC: linux-media@vger.kernel.org
CC: linux-ker...@vger.kernel.org
CC: Greg Kroah-Hartman g...@kroah.com
CC: Rafael J. Wysocki r...@sisk.pl
CC: Maciej Rutecki maciej.rute...@gmail.com
CC: Oliver Neukum oli...@neukum.org
CC: Jack Stone jwjst...@fastmail.fm
[v2: use preallocated buffer where the mutex is held; fix sizeof in one case]
---
drivers/media/dvb/dvb-usb/dib0700.h |5 +-
drivers/media/dvb/dvb-usb/dib0700_core.c | 92 +++---
2 files changed, 74 insertions(+), 23 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dib0700.h
b/drivers/media/dvb/dvb-usb/dib0700.h
index 3537d65..1401e7d 100644
--- a/drivers/media/dvb/dvb-usb/dib0700.h
+++ b/drivers/media/dvb/dvb-usb/dib0700.h
@@ -45,8 +45,9 @@ struct dib0700_state {
u8 is_dib7000pc;
u8 fw_use_new_i2c_api;
u8 disable_streaming_master_mode;
-u32 fw_version;
-u32 nb_packet_buffer_size;
+ u32 fw_version;
+ u32 nb_packet_buffer_size;
+ u8 buf[255];
};
extern int dib0700_get_version(struct dvb_usb_device *d, u32 *hwversion,
diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c
b/drivers/media/dvb/dvb-usb/dib0700_core.c
index 98ffb40..028ed87 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_core.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_core.c
@@ -27,11 +27,17 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
int dib0700_get_version(struct dvb_usb_device *d, u32 *hwversion,
u32 *romversion, u32 *ramversion, u32 *fwtype)
{
- u8 b[16];
- int ret = usb_control_msg(d-udev, usb_rcvctrlpipe(d-udev, 0),
+ int ret;
+ u8 *b;
+
+ b = kmalloc(16, GFP_KERNEL);
+ if (!b)
+ return -ENOMEM;
+
+ ret = usb_control_msg(d-udev, usb_rcvctrlpipe(d-udev, 0),
REQUEST_GET_VERSION,
USB_TYPE_VENDOR | USB_DIR_IN, 0, 0,
- b, sizeof(b), USB_CTRL_GET_TIMEOUT);
+ b, 16, USB_CTRL_GET_TIMEOUT);
if (hwversion != NULL)
*hwversion = (b[0] 24) | (b[1] 16) | (b[2] 8) |
b[3];
if (romversion != NULL)
@@ -40,6 +46,8 @@ int dib0700_get_version(struct dvb_usb_device *d, u32
*hwversion,
*ramversion = (b[8] 24) | (b[9] 16) | (b[10] 8) |
b[11];
if (fwtype != NULL)
*fwtype = (b[12] 24) | (b[13] 16) | (b[14] 8) |
b[15];
+
+ kfree(b);
return ret;
}
@@ -101,8 +109,19 @@ int dib0700_ctrl_rd(struct dvb_usb_device *d, u8 *tx, u8
txlen, u8 *rx, u8 rxlen
int dib0700_set_gpio(struct dvb_usb_device *d, enum dib07x0_gpios gpio, u8
gpio_dir, u8 gpio_val)
{
- u8 buf[3] = { REQUEST_SET_GPIO, gpio, ((gpio_dir 0x01) 7) |
((gpio_val 0x01) 6) };
- return dib0700_ctrl_wr(d, buf, sizeof(buf));
+ s16 ret;
+ u8 *buf = kmalloc(3, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ buf[0] = REQUEST_SET_GPIO;
+ buf[1] = gpio;
+ buf[2] = ((gpio_dir 0x01) 7) | ((gpio_val 0x01) 6);
+
+ ret = dib0700_ctrl_wr(d, buf, 3);
+
+ kfree(buf);
+ return ret;
}
static int dib0700_set_usb_xfer_len(struct dvb_usb_device *d, u16
nb_ts_packets)
@@ -137,11 +156,12 @@ static int dib0700_i2c_xfer_new(struct i2c_adapter *adap,
struct i2c_msg *msg,
properly support i2c read calls not preceded by a write */
struct dvb_usb_device *d = i2c_get_adapdata(adap);
+ struct dib0700_state *st = d-priv;
uint8_t bus_mode = 1; /* 0=eeprom bus, 1=frontend bus */
uint8_t gen_mode = 0; /* 0=master i2c, 1=gpio i2c */
uint8_t en_start = 0;
uint8_t en_stop = 0;
- uint8_t buf[255]; /* TBV: malloc ? */
+ uint8_t *buf = st-buf;
int result, i;
/* Ensure nobody else hits the i2c bus while we're sending our
@@ -221,6 +241,7 @@ static int dib0700_i2c_xfer_new(struct i2c_adapter *adap,
struct i2c_msg *msg,
}
}
mutex_unlock(d-i2c_mutex);
+
return i;
}
@@ -231,8 +252,9 @@ static int dib0700_i2c_xfer_legacy(struct i2c_adapter *adap,
struct i2c_msg *msg, int num)
{
struct dvb_usb_device *d = i2c_get_adapdata(adap);
+ struct dib0700_state *st = d-priv;
int i,len;
- u8 buf[255];
+ u8 *buf = st-buf;
if (mutex_lock_interruptible(d-i2c_mutex) 0)
return -EAGAIN;
@@ -264,8 +286,8 @@ static int dib0700_i2c_xfer_legacy(struct i2c_adapter *adap,
break;
}
}
-
mutex_unlock(d-i2c_mutex);
+
return i;
[PATCH 2/3] [media] dib0700: remove unused variable
Signed-off-by: Florian Mickler flor...@mickler.org
CC: Mauro Carvalho Chehab mche...@infradead.org
CC: linux-media@vger.kernel.org
CC: linux-ker...@vger.kernel.org
CC: Greg Kroah-Hartman g...@kroah.com
CC: Rafael J. Wysocki r...@sisk.pl
CC: Maciej Rutecki maciej.rute...@gmail.com
CC: Oliver Neukum oli...@neukum.org
CC: Jack Stone jwjst...@fastmail.fm
---
drivers/media/dvb/dvb-usb/dib0700_core.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c
b/drivers/media/dvb/dvb-usb/dib0700_core.c
index 028ed87..77a3060 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_core.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_core.c
@@ -576,7 +576,6 @@ struct dib0700_rc_response {
static void dib0700_rc_urb_completion(struct urb *purb)
{
struct dvb_usb_device *d = purb-context;
- struct dib0700_state *st;
struct dib0700_rc_response *poll_reply;
u32 uninitialized_var(keycode);
u8 toggle;
@@ -591,7 +590,6 @@ static void dib0700_rc_urb_completion(struct urb *purb)
return;
}
- st = d-priv;
poll_reply = purb-transfer_buffer;
if (purb-status 0) {
--
1.7.4.rc3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] [media] dib0700: don't ignore errors in driver probe
Signed-off-by: Florian Mickler flor...@mickler.org
CC: Mauro Carvalho Chehab mche...@infradead.org
CC: linux-media@vger.kernel.org
CC: linux-ker...@vger.kernel.org
CC: Greg Kroah-Hartman g...@kroah.com
CC: Rafael J. Wysocki r...@sisk.pl
CC: Maciej Rutecki maciej.rute...@gmail.com
CC: Oliver Neukum oli...@neukum.org
CC: Jack Stone jwjst...@fastmail.fm
---
drivers/media/dvb/dvb-usb/dib0700_core.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c
b/drivers/media/dvb/dvb-usb/dib0700_core.c
index 77a3060..3ad18ce 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_core.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_core.c
@@ -698,6 +698,7 @@ static int dib0700_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
int i;
+ int ret;
struct dvb_usb_device *dev;
for (i = 0; i dib0700_device_count; i++)
@@ -706,8 +707,10 @@ static int dib0700_probe(struct usb_interface *intf,
struct dib0700_state *st = dev-priv;
u32 hwversion, romversion, fw_version, fwtype;
- dib0700_get_version(dev, hwversion, romversion,
+ ret = dib0700_get_version(dev, hwversion, romversion,
fw_version, fwtype);
+ if (ret 0)
+ goto out;
deb_info(Firmware version: %x, %d, 0x%x, %d\n,
hwversion, romversion, fw_version, fwtype);
@@ -721,11 +724,15 @@ static int dib0700_probe(struct usb_interface *intf,
else
dev-props.rc.core.bulk_mode = false;
- dib0700_rc_setup(dev);
+ ret = dib0700_rc_setup(dev);
+ if (ret)
+ goto out;
return 0;
+out:
+ dvb_usb_device_exit();
+ return ret;
}
-
return -ENODEV;
}
--
1.7.4.rc3
--
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
[RFC] davinci: vpfe: mdia controller implementation for capture
Introduction This is the proposal of the initial version of design and implementation of the Davinci family (dm644x,dm355,dm365)VPFE (Video Port Front End) drivers using Media Controloler , the initial version which supports the following: 1) dm365 vpfe 2) ccdc,previewer,resizer,h3a,af blocks 3) supports only continuous mode and not on-the-fly 4) supports user pointer exchange and memory mapped modes for buffer allocation This driver bases its design on Laurent Pinchart's Media Controller Design whose patches for Media Controller and subdev enhancements form the base. The driver also takes copious elements taken from Laurent Pinchart and others' OMAP ISP driver based on Media Controller. So thank you all the people who are responsible for the Media Controller and the OMAP ISP driver. Also, the core functionality of the driver comes from the arago vpfe capture driver of which the CCDC capture was based on V4L2, with other drivers like Previwer, Resizer and other being individual character drivers. The current driver caters to dm6446,dm355 and dm365 of which the current implementation works for dm365. The three VPFE IPs have some common elements in terms of some highe level functionality but there are differences in terms of register definitions and some core blocks. The individual specifications for each of these can be found here: dm6446 vpfe: http://www.ti.com/litv/pdf/sprue38h dm355 vpfe: http://www.ti.com/litv/pdf/spruf71a dm365 vpfe: http://www.ti.com/litv/pdf/sprufg8c The initial version of the driver implementation can be found here: http://git.linuxtv.org/mhadli/v4l-dvb-davinci_devices.git?a=shortlog;h=refs/heads/mc_release Driver Design: Main entities The hardware modules for dm355,dm365 are mainly ipipe, ipipeif,isif. These hardware modules are generically exposed to the user level in the for of dm6446 style modules. Mainly - ccdc, previewer, resizer in addition to the other histogram and auto color/white balance correction and auto focus modules. 1)MT9P031 sensor module for RAW capture 2)TVP7002 decoder module for HD inputs 3)TVP514x decoder module for SD inputs 4)CCDC capture module 5)Previewer Module for Bayer to YUV conversion 6)Resizer Module for scaling Connection for on-the-fly capture - Mt9P031 --CCDC---Previewer(optional)---Resizer(optional)---Video | TVP7002 --- | TV514x --- File Organisation - main driver files drivers/media/video/davinci/vpfe_capture.c include/media/davinci/vpfe_capture.h Instantiatiation of the v4l2 device, media device and all subdevs from here. video Interface files - drivers/media/video/davinci/vpfe_video.c include/media/davinci/vpfe_video.h Implements all the v4l2 video operations with a generic implementation for continuous and one shot mode. subdev interface files -- These file implement the subdev interface functionality for each of the subdev entities - mainly the entry points and their implementations in a IP generic way. drivers/media/video/davinci/vpfe_ccdc.c drivers/media/video/davinci/vpfe_previewer.c drivers/media/video/davinci/vpfe_resizer.c drivers/media/video/davinci/vpfe_af.c drivers/media/video/davinci/vpfe_aew.c drivers/media/video/tvp514x.c drivers/media/video/tvp7002.c drivers/media/video/ths7353.c include/media/davinci/vpfe_ccdc.h include/media/davinci/vpfe_previewer.h include/media/davinci/vpfe_resizer.h include/media/davinci/vpfe_af.h include/media/davinci/vpfe_aew.h include/media/tvp514x.h drivers/media/video/tvp514x_regs.h include/media/tvp7002.h drivers/media/video/tvp7002_reg.h core implementation files - These provide a core implementation routines for ccdc, ipipeif, ipipe,aew, af, resizer hardware modules. drivers/char/imp_common.c drivers/media/video/davinci/dm365_ccdc.c drivers/media/video/davinci/dm355_ccdc.c drivers/media/video/davinci/dm644x_ccdc.c drivers/char/dm355_ipipe.c drivers/char/dm355_ipipe_hw.c drivers/char/dm355_def_para.c drivers/char/dm365_ipipe.c drivers/char/dm365_def_para.c drivers/char/dm365_ipipe_hw.c drivers/char/dm6446_imp.c drivers/char/davinci_resizer_hw.c drivers/char/dm3xx_ipipe.c drivers/media/video/davinci/dm365_aew.c drivers/media/video/davinci/dm365_af.c drivers/media/video/davinci/dm365_a3_hw.c drivers/media/video/davinci/dm355_aew.c drivers/media/video/davinci/dm355_af.c drivers/media/video/davinci/dm355_aew_hw.c drivers/media/video/davinci/dm355_af_hw.c include/media/davinci/imp_common.h include/media/davinci/dm365_ccdc.h include/media/davinci/dm355_ccdc.h include/media/davinci/dm644x_ccdc.h include/media/davinci/dm355_ipipe.h include/media/davinci/dm365_ipipe.h include/media/davinci/imp_hw_if.h include/media/davinci/dm3xx_ipipe.h include/media/davinci/dm365_aew.h include/media/davinci/dm365_af.h include/media/davinci/dm365_a3_hw.h include/media/davinci/dm355_aew.h
Re: [PATCH] [media] dib0700: get rid of on-stack dma buffers
On Sun, 6 Mar 2011 16:06:38 +0100 Oliver Neukum oli...@neukum.org wrote: Am Sonntag, 6. März 2011, 15:38:05 schrieb Florian Mickler: On Sun, 6 Mar 2011 13:06:09 +0100 Oliver Neukum oli...@neukum.org wrote: Am Sonntag, 6. März 2011, 12:16:52 schrieb Florian Mickler: Please take a look at it, as I do not do that much kernel hacking and don't wanna brake anybodys computer... :) From my point of view this should _not_ go to stable even though it would be applicable. But if someone feels strongly about that and can take responsibility for that change... The patch looks good and is needed in stable. It could be improved by using a buffer allocated once in the places you hold a mutex anyway. Regards Oliver Ok, I now put a buffer member in the priv dib0700_state which gets allocated on the heap. This however is wrong. Just like DMA on the stack this breaks coherency rules. You may do DMA to the heap in the sense that you can do DMA to buffers allocated on the heap, but you cannot do DMA to a part of another structure allocated on the heap. You need a separate kmalloc for each buffer. You can reuse the buffer with proper locking, but you must allocate it seperately once. Regards Oliver Hm.. allocating the buffer in the probe routine and deallocating it in the usb_driver disconnect callback should work? How come that it must be a seperate kmalloc buffer? Is it some aligning that kmalloc garantees? Regards, Flo -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] saa7134-input: key up events not sent after suspend/resume
On my AverMedia AverTV Studio 507, key up events are no longer sent after
a suspend-to-disk/resume cycle, resulting in stuck keys.
Apparently, for key up events to be generated, a certain GPIO pin must be set.
Currently it's set in saa7134_input_init1(), but that function is not called
on device resume. I suggest that code be moved to __saa7134_ir_start(), which
is called both on init and resume.
Signed-off-by: Vadim Solomin vadic...@gmail.com
diff -r abd3aac6644e linux/drivers/media/video/saa7134/saa7134-input.c
--- a/linux/drivers/media/video/saa7134/saa7134-input.c Fri Jul 02 00:38:54
2010 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-input.c Sun Mar 06 02:57:43
2011 +0300
@@ -511,6 +511,41 @@
if (ir-running)
return 0;
+ /* Moved here from saa7134_input_init1() because the latter
+* is not called on device resume */
+ switch (dev-board) {
+ case SAA7134_BOARD_MD2819:
+ case SAA7134_BOARD_KWORLD_VSTREAM_XPERT:
+ case SAA7134_BOARD_AVERMEDIA_305:
+ case SAA7134_BOARD_AVERMEDIA_307:
+ case SAA7134_BOARD_AVERMEDIA_STUDIO_305:
+ case SAA7134_BOARD_AVERMEDIA_STUDIO_505:
+ case SAA7134_BOARD_AVERMEDIA_STUDIO_307:
+ case SAA7134_BOARD_AVERMEDIA_STUDIO_507:
+ case SAA7134_BOARD_AVERMEDIA_STUDIO_507UA:
+ case SAA7134_BOARD_AVERMEDIA_GO_007_FM:
+ case SAA7134_BOARD_AVERMEDIA_M102:
+ case SAA7134_BOARD_AVERMEDIA_GO_007_FM_PLUS:
+ /* Without this we won't receive key up events */
+ saa_setb(SAA7134_GPIO_GPMODE0, 0x4);
+ saa_setb(SAA7134_GPIO_GPSTATUS0, 0x4);
+ break;
+ case SAA7134_BOARD_AVERMEDIA_777:
+ case SAA7134_BOARD_AVERMEDIA_A16AR:
+ /* Without this we won't receive key up events */
+ saa_setb(SAA7134_GPIO_GPMODE1, 0x1);
+ saa_setb(SAA7134_GPIO_GPSTATUS1, 0x1);
+ break;
+ case SAA7134_BOARD_AVERMEDIA_A16D:
+ /* Without this we won't receive key up events */
+ saa_setb(SAA7134_GPIO_GPMODE1, 0x1);
+ saa_setb(SAA7134_GPIO_GPSTATUS1, 0x1);
+ break;
+ case SAA7134_BOARD_GOTVIEW_7135:
+ saa_setb(SAA7134_GPIO_GPMODE1, 0x80);
+ break;
+ }
+
ir-running = 1;
if (ir-polling) {
setup_timer(ir-timer, saa7134_input_timer,
@@ -709,9 +744,7 @@
mask_keycode = 0x0007C8;
mask_keydown = 0x10;
polling = 50; // ms
- /* Set GPIO pin2 to high to enable the IR controller */
- saa_setb(SAA7134_GPIO_GPMODE0, 0x4);
- saa_setb(SAA7134_GPIO_GPSTATUS0, 0x4);
+ /* GPIO stuff moved to __saa7134_ir_start() */
break;
case SAA7134_BOARD_AVERMEDIA_M135A:
ir_codes = RC_MAP_AVERMEDIA_M135A;
@@ -733,18 +766,14 @@
mask_keycode = 0x02F200;
mask_keydown = 0x000400;
polling = 50; // ms
- /* Without this we won't receive key up events */
- saa_setb(SAA7134_GPIO_GPMODE1, 0x1);
- saa_setb(SAA7134_GPIO_GPSTATUS1, 0x1);
+ /* GPIO stuff moved to __saa7134_ir_start() */
break;
case SAA7134_BOARD_AVERMEDIA_A16D:
ir_codes = RC_MAP_AVERMEDIA_A16D;
mask_keycode = 0x02F200;
mask_keydown = 0x000400;
polling = 50; /* ms */
- /* Without this we won't receive key up events */
- saa_setb(SAA7134_GPIO_GPMODE1, 0x1);
- saa_setb(SAA7134_GPIO_GPSTATUS1, 0x1);
+ /* GPIO stuff moved to __saa7134_ir_start() */
break;
case SAA7134_BOARD_KWORLD_TERMINATOR:
ir_codes = RC_MAP_PIXELVIEW;
@@ -796,7 +825,7 @@
mask_keycode = 0x0003CC;
mask_keydown = 0x10;
polling = 5; /* ms */
- saa_setb(SAA7134_GPIO_GPMODE1, 0x80);
+ /* GPIO stuff moved to __saa7134_ir_start() */
break;
case SAA7134_BOARD_VIDEOMATE_TV_PVR:
case SAA7134_BOARD_VIDEOMATE_GOLD_PLUS:
--
Vadim Solomin
--
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] STV0288 added full frontend status
status now returns
FE_HAS_CARRIER
FE_HAS_SIGNAL
FE_HAS_VITERBI
Signed-off-by: Malcolm Priestley tvbox...@gmail.com
---
drivers/media/dvb/frontends/stv0288.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/frontends/stv0288.c
b/drivers/media/dvb/frontends/stv0288.c
index 63db8fd..5e8c7fd 100644
--- a/drivers/media/dvb/frontends/stv0288.c
+++ b/drivers/media/dvb/frontends/stv0288.c
@@ -367,8 +367,11 @@ static int stv0288_read_status(struct dvb_frontend *fe,
fe_status_t *status)
dprintk(%s : FE_READ_STATUS : VSTATUS: 0x%02x\n, __func__, sync);
*status = 0;
-
- if ((sync 0x08) == 0x08) {
+ if (sync 0x80)
+ *status |= FE_HAS_CARRIER | FE_HAS_SIGNAL;
+ if (sync 0x10)
+ *status |= FE_HAS_VITERBI;
+ if (sync 0x08) {
*status |= FE_HAS_LOCK;
dprintk(stv0288 has locked\n);
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] dib0700: get rid of on-stack dma buffers
Am Sonntag, 6. März 2011, 16:45:21 schrieb Florian Mickler: Hm.. allocating the buffer in the probe routine and deallocating it in the usb_driver disconnect callback should work? Yes. How come that it must be a seperate kmalloc buffer? Is it some aligning that kmalloc garantees? On some CPUs DMA affects on main CPU, not the CPU caches. You need to synchronize the cache before you start DMA and must not touch the buffer until DMA is finished. This applies with a certain granularity that kmalloc respects. The ugly details are in Documentation. Regards Oliver -- 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: [GIT PULL FOR 2.6.39] Media controller and OMAP3 ISP driver
Hi Mauro,
On Sunday 06 March 2011 14:32:44 Mauro Carvalho Chehab wrote:
Em 06-03-2011 08:38, Laurent Pinchart escreveu:
On Sunday 06 March 2011 11:56:04 Mauro Carvalho Chehab wrote:
Em 05-03-2011 20:23, Sylwester Nawrocki escreveu:
A somewhat unrelated question that occurred to me today: what happens
when a format change happens while streaming?
Considering that some formats need more bits than others, this could
lead into buffer overflows, either internally at the device or
externally, on bridges that just forward whatever it receives to the
DMA buffers (there are some that just does that). I didn't see anything
inside the mc code preventing such condition to happen, and probably
implementing it won't be an easy job. So, one alternative would be to
require some special CAPS if userspace tries to set the mbus format
directly, or to recommend userspace to create media controller nodes
with 0600 permission.
That's not really a media controller issue. Whether formats can be
changed during streaming is a driver decision. The OMAP3 ISP driver
won't allow formats to be changed during streaming. If the hardware
allows for such format changes, drivers can implement support for that
and make sure that no buffer overflow will occur.
Such issues is caused by having two API's that allow format changes, one
that does it device-based, and another one doing it subdev-based.
Ok, drivers can implementing locks to prevent such troubles, but, without
the core providing a reliable mechanism, it is hard to implement a
correct lock.
For example, let's suppose that some driver is using mt9m111 subdev (I just
picked one random sensor that supports lots of MBUS formats). There's
nothing there preventing a subdev call for it to change mbus format while
streaming. Worse than that, the sensor driver has no way to block it, as
it doesn't know that the bridge driver is streaming or not.
The code at subdev_do_ioctl() is just:
case VIDIOC_SUBDEV_S_FMT: {
struct v4l2_subdev_format *format = arg;
if (format-which != V4L2_SUBDEV_FORMAT_TRY
format-which != V4L2_SUBDEV_FORMAT_ACTIVE)
return -EINVAL;
if (format-pad = sd-entity.num_pads)
return -EINVAL;
return v4l2_subdev_call(sd, pad, set_fmt, subdev_fh, format);
}
So, mc core won't be preventing it.
So, I can't see how such subdev request would be implementing a logic to
return -EBUSY on those cases.
Drivers can use the media_device graph_mutex to serialize format and stream
management calls. A finer grain locking mechanism implemented in the core
might be better, but we're not stuck without a solution at the moment.
--
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] davinci: vpfe: mdia controller implementation for capture
Hi Manjunath, On Sunday 06 March 2011 16:36:05 Manjunath Hadli wrote: Introduction This is the proposal of the initial version of design and implementation of the Davinci family (dm644x,dm355,dm365)VPFE (Video Port Front End) drivers using Media Controloler , the initial version which supports the following: 1) dm365 vpfe 2) ccdc,previewer,resizer,h3a,af blocks 3) supports only continuous mode and not on-the-fly 4) supports user pointer exchange and memory mapped modes for buffer allocation This driver bases its design on Laurent Pinchart's Media Controller Design whose patches for Media Controller and subdev enhancements form the base. The driver also takes copious elements taken from Laurent Pinchart and others' OMAP ISP driver based on Media Controller. So thank you all the people who are responsible for the Media Controller and the OMAP ISP driver. You're welcome :-) Also, the core functionality of the driver comes from the arago vpfe capture driver of which the CCDC capture was based on V4L2, with other drivers like Previwer, Resizer and other being individual character drivers. The CCDC, preview and resizer modules look very similar to their OMAP3 counterparts. I think we should aim at sharing code between the drivers. It's hard enough to develop, review and maintain one driver, let's not duplicate the effort. The current driver caters to dm6446,dm355 and dm365 of which the current implementation works for dm365. The three VPFE IPs have some common elements in terms of some highe level functionality but there are differences in terms of register definitions and some core blocks. The individual specifications for each of these can be found here: dm6446 vpfe: http://www.ti.com/litv/pdf/sprue38h dm355 vpfe: http://www.ti.com/litv/pdf/spruf71a dm365 vpfe: http://www.ti.com/litv/pdf/sprufg8c The initial version of the driver implementation can be found here: http://git.linuxtv.org/mhadli/v4l-dvb-davinci_devices.git?a=shortlog;h=refs /heads/mc_release Driver Design: Main entities The hardware modules for dm355,dm365 are mainly ipipe, ipipeif,isif. These hardware modules are generically exposed to the user level in the for of dm6446 style modules. Mainly - ccdc, previewer, resizer in addition to the other histogram and auto color/white balance correction and auto focus modules. 1)MT9P031 sensor module for RAW capture 2)TVP7002 decoder module for HD inputs 3)TVP514x decoder module for SD inputs 4)CCDC capture module 5)Previewer Module for Bayer to YUV conversion 6)Resizer Module for scaling Connection for on-the-fly capture - Mt9P031 --CCDC---Previewer(optional)---Resizer(optional)---Video TVP7002 --- TV514x --- File Organisation - main driver files drivers/media/video/davinci/vpfe_capture.c include/media/davinci/vpfe_capture.h Instantiatiation of the v4l2 device, media device and all subdevs from here. video Interface files - drivers/media/video/davinci/vpfe_video.c include/media/davinci/vpfe_video.h Implements all the v4l2 video operations with a generic implementation for continuous and one shot mode. subdev interface files -- These file implement the subdev interface functionality for each of the subdev entities - mainly the entry points and their implementations in a IP generic way. drivers/media/video/davinci/vpfe_ccdc.c drivers/media/video/davinci/vpfe_previewer.c drivers/media/video/davinci/vpfe_resizer.c drivers/media/video/davinci/vpfe_af.c drivers/media/video/davinci/vpfe_aew.c drivers/media/video/tvp514x.c drivers/media/video/tvp7002.c drivers/media/video/ths7353.c include/media/davinci/vpfe_ccdc.h include/media/davinci/vpfe_previewer.h include/media/davinci/vpfe_resizer.h include/media/davinci/vpfe_af.h include/media/davinci/vpfe_aew.h include/media/tvp514x.h drivers/media/video/tvp514x_regs.h include/media/tvp7002.h drivers/media/video/tvp7002_reg.h core implementation files - These provide a core implementation routines for ccdc, ipipeif, ipipe,aew, af, resizer hardware modules. drivers/char/imp_common.c drivers/media/video/davinci/dm365_ccdc.c drivers/media/video/davinci/dm355_ccdc.c drivers/media/video/davinci/dm644x_ccdc.c drivers/char/dm355_ipipe.c drivers/char/dm355_ipipe_hw.c drivers/char/dm355_def_para.c drivers/char/dm365_ipipe.c drivers/char/dm365_def_para.c drivers/char/dm365_ipipe_hw.c drivers/char/dm6446_imp.c drivers/char/davinci_resizer_hw.c drivers/char/dm3xx_ipipe.c drivers/media/video/davinci/dm365_aew.c drivers/media/video/davinci/dm365_af.c drivers/media/video/davinci/dm365_a3_hw.c drivers/media/video/davinci/dm355_aew.c drivers/media/video/davinci/dm355_af.c drivers/media/video/davinci/dm355_aew_hw.c
[PATCH 1/2 v3] [media] dib0700: get rid of on-stack dma buffers
This should fix warnings seen by some:
WARNING: at lib/dma-debug.c:866 check_for_stack
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=15977.
Reported-by: Zdenek Kabelac zdenek.kabe...@gmail.com
Signed-off-by: Florian Mickler flor...@mickler.org
CC: Mauro Carvalho Chehab mche...@infradead.org
CC: linux-media@vger.kernel.org
CC: linux-ker...@vger.kernel.org
CC: Greg Kroah-Hartman g...@kroah.com
CC: Rafael J. Wysocki r...@sisk.pl
CC: Maciej Rutecki maciej.rute...@gmail.com
CC: Oliver Neukum oli...@neukum.org
CC: Jack Stone jwjst...@fastmail.fm
---
[v2: use preallocated buffer; fix sizeof in one case]
[v3: use seperate kmalloc mapping for the preallocation,
dont ignore errors in probe codepaths ]
drivers/media/dvb/dvb-usb/dib0700.h |5 +-
drivers/media/dvb/dvb-usb/dib0700_core.c | 119 --
2 files changed, 98 insertions(+), 26 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dib0700.h
b/drivers/media/dvb/dvb-usb/dib0700.h
index 3537d65..99a1485 100644
--- a/drivers/media/dvb/dvb-usb/dib0700.h
+++ b/drivers/media/dvb/dvb-usb/dib0700.h
@@ -45,8 +45,9 @@ struct dib0700_state {
u8 is_dib7000pc;
u8 fw_use_new_i2c_api;
u8 disable_streaming_master_mode;
-u32 fw_version;
-u32 nb_packet_buffer_size;
+ u32 fw_version;
+ u32 nb_packet_buffer_size;
+ u8 *buf;
};
extern int dib0700_get_version(struct dvb_usb_device *d, u32 *hwversion,
diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c
b/drivers/media/dvb/dvb-usb/dib0700_core.c
index 98ffb40..0b04cb6 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_core.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_core.c
@@ -27,11 +27,17 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
int dib0700_get_version(struct dvb_usb_device *d, u32 *hwversion,
u32 *romversion, u32 *ramversion, u32 *fwtype)
{
- u8 b[16];
- int ret = usb_control_msg(d-udev, usb_rcvctrlpipe(d-udev, 0),
+ int ret;
+ u8 *b;
+
+ b = kmalloc(16, GFP_KERNEL);
+ if (!b)
+ return -ENOMEM;
+
+ ret = usb_control_msg(d-udev, usb_rcvctrlpipe(d-udev, 0),
REQUEST_GET_VERSION,
USB_TYPE_VENDOR | USB_DIR_IN, 0, 0,
- b, sizeof(b), USB_CTRL_GET_TIMEOUT);
+ b, 16, USB_CTRL_GET_TIMEOUT);
if (hwversion != NULL)
*hwversion = (b[0] 24) | (b[1] 16) | (b[2] 8) |
b[3];
if (romversion != NULL)
@@ -40,6 +46,8 @@ int dib0700_get_version(struct dvb_usb_device *d, u32
*hwversion,
*ramversion = (b[8] 24) | (b[9] 16) | (b[10] 8) |
b[11];
if (fwtype != NULL)
*fwtype = (b[12] 24) | (b[13] 16) | (b[14] 8) |
b[15];
+
+ kfree(b);
return ret;
}
@@ -101,8 +109,19 @@ int dib0700_ctrl_rd(struct dvb_usb_device *d, u8 *tx, u8
txlen, u8 *rx, u8 rxlen
int dib0700_set_gpio(struct dvb_usb_device *d, enum dib07x0_gpios gpio, u8
gpio_dir, u8 gpio_val)
{
- u8 buf[3] = { REQUEST_SET_GPIO, gpio, ((gpio_dir 0x01) 7) |
((gpio_val 0x01) 6) };
- return dib0700_ctrl_wr(d, buf, sizeof(buf));
+ s16 ret;
+ u8 *buf = kmalloc(3, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ buf[0] = REQUEST_SET_GPIO;
+ buf[1] = gpio;
+ buf[2] = ((gpio_dir 0x01) 7) | ((gpio_val 0x01) 6);
+
+ ret = dib0700_ctrl_wr(d, buf, 3);
+
+ kfree(buf);
+ return ret;
}
static int dib0700_set_usb_xfer_len(struct dvb_usb_device *d, u16
nb_ts_packets)
@@ -137,11 +156,12 @@ static int dib0700_i2c_xfer_new(struct i2c_adapter *adap,
struct i2c_msg *msg,
properly support i2c read calls not preceded by a write */
struct dvb_usb_device *d = i2c_get_adapdata(adap);
+ struct dib0700_state *st = d-priv;
uint8_t bus_mode = 1; /* 0=eeprom bus, 1=frontend bus */
uint8_t gen_mode = 0; /* 0=master i2c, 1=gpio i2c */
uint8_t en_start = 0;
uint8_t en_stop = 0;
- uint8_t buf[255]; /* TBV: malloc ? */
+ uint8_t *buf = st-buf;
int result, i;
/* Ensure nobody else hits the i2c bus while we're sending our
@@ -221,6 +241,7 @@ static int dib0700_i2c_xfer_new(struct i2c_adapter *adap,
struct i2c_msg *msg,
}
}
mutex_unlock(d-i2c_mutex);
+
return i;
}
@@ -231,8 +252,9 @@ static int dib0700_i2c_xfer_legacy(struct i2c_adapter *adap,
struct i2c_msg *msg, int num)
{
struct dvb_usb_device *d = i2c_get_adapdata(adap);
+ struct dib0700_state *st = d-priv;
int i,len;
- u8 buf[255];
+ u8 *buf = st-buf;
if (mutex_lock_interruptible(d-i2c_mutex) 0)
return -EAGAIN;
@@ -264,8 +286,8 @@ static int dib0700_i2c_xfer_legacy(struct i2c_adapter *adap,
break;
[PATCH 2/2] [media] dib0700: remove unused variable
Signed-off-by: Florian Mickler flor...@mickler.org
CC: linux-media@vger.kernel.org
CC: linux-ker...@vger.kernel.org
CC: Greg Kroah-Hartman g...@kroah.com
CC: Rafael J. Wysocki r...@sisk.pl
CC: Maciej Rutecki maciej.rute...@gmail.com
CC: Oliver Neukum oli...@neukum.org
---
drivers/media/dvb/dvb-usb/dib0700_core.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c
b/drivers/media/dvb/dvb-usb/dib0700_core.c
index 0b04cb6..5770265 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_core.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_core.c
@@ -576,7 +576,6 @@ struct dib0700_rc_response {
static void dib0700_rc_urb_completion(struct urb *purb)
{
struct dvb_usb_device *d = purb-context;
- struct dib0700_state *st;
struct dib0700_rc_response *poll_reply;
u32 uninitialized_var(keycode);
u8 toggle;
@@ -591,7 +590,6 @@ static void dib0700_rc_urb_completion(struct urb *purb)
return;
}
- st = d-priv;
poll_reply = purb-transfer_buffer;
if (purb-status 0) {
--
1.7.4.rc3
--
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: [Query] What is the best way to handle V4L2_PIX_FMT_NV12 buffers?
On Sat, 2011-03-05 at 22:49 -0600, Aguirre, Sergio wrote:
Hi,
I was curious in how to handle properly buffers of pixelformat
V4L2_PIX_FMT_NV12.
I see that the standard convention for determining a bytesize of an image
buffer is:
bytesperline * height
However, for NV12 case, the bytes per line is equal to the width, _but_ the
actual buffer size is:
For the Y buffer: width * height
For the UV buffer: width * (height / 2)
Total size = width * (height + height / 2)
Which I think renders the bytesperline * height formula not valid for this
case.
Any ideas how this should be properly handled?
For the HM12 macroblock format:
http://git.linuxtv.org/media_tree.git?a=blob;f=Documentation/video4linux/cx2341x/README.hm12;h=b36148ea07501bdac37ae74b31cc258150f75a81;hb=staging/for_v2.6.39
ivtv and cx18 do this in cx18-ioctl.c and ivtv-ioctl.c:
...
if (id-type == _ENC_STREAM_TYPE_YUV) {
pixfmt-pixelformat = V4L2_PIX_FMT_HM12;
/* YUV size is (Y=(h*720) + UV=(h*(720/2))) */
pixfmt-sizeimage = pixfmt-height * 720 * 3 / 2;
pixfmt-bytesperline = 720;
}
...
Note that the wdith is fixed at 720 because the CX2341x chips always
build HM12 planes assuming a width of 720, even though it isn't going to
actually fill in the off-sceen pixels for widths less than 720.
Note that pixfmt-height * 3 / 2 is just (height + height / 2).
It's not a definitive answer; only an example of what two drivers do for
a very uncommon macroblock format.
Regards,
Andy
NOTE: See here for more details: http://www.fourcc.org/yuv.php#NV12
Regards,
Sergio--
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 v3] [media] dib0700: get rid of on-stack dma buffers
On Sun, 6 Mar 2011 18:47:56 +0100
Florian Mickler flor...@mickler.org wrote:
+static void dib0700_disconnect(struct usb_interface *intf) {
That { should go on its own line... sorry ;-)
If that patch is acceptable, I can resend with that fixed.
Regards,
Flo
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG at mm/mmap.c:2309 when cx18.ko and cx18-alsa.ko loaded
On Sat, Mar 5, 2011 at 6:03 PM, Andy Walls awa...@md.metrocast.net wrote:
On Sat, 2011-03-05 at 16:59 -0500, Andy Walls wrote:
On Thu, 2011-03-03 at 21:06 -0500, Andy Walls wrote:
Hi,
I got a BUG when loading the cx18.ko module (which in turn requests the
cx18-alsa.ko module) on a kernel built from this repository
http://git.linuxtv.org/media_tree.git staging/for_v2.6.39
which I beleive is based on 2.6.38-rc2.
[snip]
So here is my transcription of a fuzzy digital photo of the screen:
kernel BUG at /home/andy/cx18dev/git/media_tree/mm/mmap.c:2309!
invalid opcode: [#1] SMP
last sysfs file: /sys/module/snd_pcm/initstate
Modules linked in: tda9887 tda8290 mxl5005s s5h1409 tuner_simple ...
...
Pid: 2580, comm: udevd Not tainted 2.6.38-rc2-cx18-vb2-proto+
RIP: 0010:[810eb50b] [810eb50b] exit_mmap+0x10f/0x11e
RAX: RBX: RCX: 0020
RDX: 00160011 RSI: eac42___ RDI: 0202
RBP: 18c1f_58 R08: R09: 0004
R10: ___bb_38 R11: R12: 344a6680
R13: 7fff22__ R14: R15: 0001
...
CR2: ...
Process udevd (pid: 25__, threadinfo , ...
Stack:
015e 3bc0e1d0 0246
.
Call Trace:
... mmput+0x63/0xcf
... exit_mm+0x132/0x13f
... do_exit+0x238/0x749
... ? __dequeue_signal+0xfa/0x12f
... do_group_exit+0x7d/0xa5
... get_signal_to_deliver+0x371/0x395
... do_signal+0x72/0x692
... ? do_page_fault+0x24a/0x391
... ? printk+0x41/0x47
... ? sigprocmask+0xa3/0xcd
... do_notify_resume+0x2c/0x64
... retint_signal+0x48/0x8c
Code: ff ff 48 8b 7d d8 4c 89 ea 31 f6 e8 3e fe ff ff 48 89 df e8 78 fe
ff ff 48 85 c0 48 89 c3 75 f0 49 83 bc 24 e0 00 00 00 00 74 04 0f 0b
eb fe 48 83 c4 18 5b 41 5c 41 5d c9 c3 55 48 89 e5 41 57
RIP [810eb50b] exit_mmap+0x10f/0x11e
RSP 880018c1fc28
general protection fault: [#2] SMP
last sysfs file: /sys/devices/virtual/sound/card2/uevent
CPU 1
Modules linked in: cx18-alsa tda9887 tda8290 mxl5005s s5h1409
tuner_simple tuner_types cs5345 tuner cx18 dvb_core cx2341x v4l2_common
videodev v4l2_compat_ioctl32
I'm dumping all my previous assumtpions about this BUG. After a bit of
reading, all I can say is that it's a page table deallocation problem at
process exit. After all the page table deallocations on exit,
mm-nr_ptes is still 0, and that's a bad thing.
It apparently happened in a child udevd exiting shortly after cx18.ko
loaded. The cx18 driver allocating large amounts kernel memory for DMA
buffers upon load may be related to triggering the problem, but I doubt
it is a root cause of the BUG.
This monsterous thread from 5 years ago is somewhat enlightening:
http://lkml.indiana.edu/hypermail/linux/kernel/0503.2/1680.html
http://lkml.indiana.edu/hypermail/linux/kernel/0503.2/1787.html
so it gives me a place to start looking for the problem.
Any advice on what data to collect is appreciated.
When attemtping to reproduce this BUG, I got another bug related to
memory management:
(Details handtyped from a photo):
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [010f22fa] remove_vm_area+0x42/0x77
PGD 37cdd067 PUD 336c__67 PMD 0
Oops: [#1] SMP
last sysfs file:
/sys/devices/pci:00/:00:14.4/:03:00.0/firmware/:03:00.0/loading
CPU 0
Modules linked in: tda9887 tda8290 mxl5005s s5h1409 tuner_simple tuner_types
cx5345 tuner cx18(+) dvb_core cx2341x ...
Pid: 2470, comm: work_for_cpu Tainted: G W 2.6.28-rc2-cx18-vb2-proto+
RIP: 0010:[010f22fa] [010f22fa] remove_vm_area+0x42/0x77
...
RAX: RBX: 35e7c540 RCX: 1000
RDX:
...
CR2:
Stack:
__0011485968 001 1147dc9_ _1_f23__
Call Trace:
... __vunmap+0x3e/0xbd
... vfree+0x2e/0x30
... dvb_dmx_init+0x7e/0x253 [dvb_core]
... cx18_dvb_register+0xd2/0x75c [cx18]
... cx18_streams_resgister+0x6a/0x26a [cx18]
... cx18_streams_setup+0x3cc/0x486 [cx18]
... cx18_probe+0x11cc/0x12fb [cx18]
..
The code appears to be failing here:
/home/andy/cx18dev/git/media_tree/mm/vmalloc.c:1352
161d: eb 06 jmp 1625 remove_vm_area+0x45
161f: 48 89 c2 mov %rax,%rdx
1622: 48 8b 00 mov (%rax),%rax --- Oops p =
tmp-next) (tmp = *p)
1625: 48 39 d8 cmp %rbx,%rax (tmp =
*p) != vm;
1628: 75 f5 jne 161f remove_vm_area+0x3f
/home/andy/cx18dev/git/media_tree/mm/vmalloc.c:1354
Corresponding to this code in mm/vmalloc.c:
struct vm_struct *remove_vm_area(const void *addr)
{
struct vmap_area
Re: [Query] What is the best way to handle V4L2_PIX_FMT_NV12 buffers?
On Sun, 6 Mar 2011, Andy Walls wrote:
On Sat, 2011-03-05 at 22:49 -0600, Aguirre, Sergio wrote:
Hi,
I was curious in how to handle properly buffers of pixelformat
V4L2_PIX_FMT_NV12.
I see that the standard convention for determining a bytesize of an image
buffer is:
bytesperline * height
However, for NV12 case, the bytes per line is equal to the width, _but_ the
actual buffer size is:
For the Y buffer: width * height
For the UV buffer: width * (height / 2)
Total size = width * (height + height / 2)
Which I think renders the bytesperline * height formula not valid for this
case.
Any ideas how this should be properly handled?
For the HM12 macroblock format:
http://git.linuxtv.org/media_tree.git?a=blob;f=Documentation/video4linux/cx2341x/README.hm12;h=b36148ea07501bdac37ae74b31cc258150f75a81;hb=staging/for_v2.6.39
ivtv and cx18 do this in cx18-ioctl.c and ivtv-ioctl.c:
...
if (id-type == _ENC_STREAM_TYPE_YUV) {
pixfmt-pixelformat = V4L2_PIX_FMT_HM12;
/* YUV size is (Y=(h*720) + UV=(h*(720/2))) */
pixfmt-sizeimage = pixfmt-height * 720 * 3 / 2;
pixfmt-bytesperline = 720;
}
...
Yep, the height * width formula is in no way standard or compulsory -
that's exactly the reason why this calculation is left to the individual
drivers. You can also look at sh_mobile_ceu_camera.c, which also supports
this format, and effectively also calculates height * width * 3 / 2.
Thanks
Guennadi
Note that the wdith is fixed at 720 because the CX2341x chips always
build HM12 planes assuming a width of 720, even though it isn't going to
actually fill in the off-sceen pixels for widths less than 720.
Note that pixfmt-height * 3 / 2 is just (height + height / 2).
It's not a definitive answer; only an example of what two drivers do for
a very uncommon macroblock format.
Regards,
Andy
NOTE: See here for more details: http://www.fourcc.org/yuv.php#NV12
Regards,
Sergio--
--
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
---
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
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sun Mar 6 19:00:33 CET 2011 git hash:88a763df226facb74fdb254563e30e9efb64275c 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 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.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 spec-git: ERRORS 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 failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG at mm/mmap.c:2309 when cx18.ko and cx18-alsa.ko loaded
On Sun, 2011-03-06 at 10:37 -0800, Hugh Dickins wrote: On Sat, Mar 5, 2011 at 6:03 PM, Andy Walls awa...@md.metrocast.net wrote: On Sat, 2011-03-05 at 16:59 -0500, Andy Walls wrote: On Thu, 2011-03-03 at 21:06 -0500, Andy Walls wrote: Hi, I got a BUG when loading the cx18.ko module (which in turn requests the cx18-alsa.ko module) on a kernel built from this repository http://git.linuxtv.org/media_tree.git staging/for_v2.6.39 which I beleive is based on 2.6.38-rc2. [snip] So here is my transcription of a fuzzy digital photo of the screen: kernel BUG at /home/andy/cx18dev/git/media_tree/mm/mmap.c:2309! invalid opcode: [#1] SMP last sysfs file: /sys/module/snd_pcm/initstate Modules linked in: tda9887 tda8290 mxl5005s s5h1409 tuner_simple ... ... Pid: 2580, comm: udevd Not tainted 2.6.38-rc2-cx18-vb2-proto+ RIP: 0010:[810eb50b] [810eb50b] exit_mmap+0x10f/0x11e RAX: RBX: RCX: 0020 RDX: 00160011 RSI: eac42___ RDI: 0202 RBP: 18c1f_58 R08: R09: 0004 R10: ___bb_38 R11: R12: 344a6680 R13: 7fff22__ R14: R15: 0001 ... CR2: ... Process udevd (pid: 25__, threadinfo , ... Stack: 015e 3bc0e1d0 0246 . Call Trace: ... mmput+0x63/0xcf ... exit_mm+0x132/0x13f ... do_exit+0x238/0x749 ... ? __dequeue_signal+0xfa/0x12f ... do_group_exit+0x7d/0xa5 ... get_signal_to_deliver+0x371/0x395 ... do_signal+0x72/0x692 ... ? do_page_fault+0x24a/0x391 ... ? printk+0x41/0x47 ... ? sigprocmask+0xa3/0xcd ... do_notify_resume+0x2c/0x64 ... retint_signal+0x48/0x8c Code: ff ff 48 8b 7d d8 4c 89 ea 31 f6 e8 3e fe ff ff 48 89 df e8 78 fe ff ff 48 85 c0 48 89 c3 75 f0 49 83 bc 24 e0 00 00 00 00 74 04 0f 0b eb fe 48 83 c4 18 5b 41 5c 41 5d c9 c3 55 48 89 e5 41 57 RIP [810eb50b] exit_mmap+0x10f/0x11e RSP 880018c1fc28 general protection fault: [#2] SMP last sysfs file: /sys/devices/virtual/sound/card2/uevent CPU 1 Modules linked in: cx18-alsa tda9887 tda8290 mxl5005s s5h1409 tuner_simple tuner_types cs5345 tuner cx18 dvb_core cx2341x v4l2_common videodev v4l2_compat_ioctl32 I'm dumping all my previous assumtpions about this BUG. After a bit of reading, all I can say is that it's a page table deallocation problem at process exit. After all the page table deallocations on exit, mm-nr_ptes is still 0, and that's a bad thing. It apparently happened in a child udevd exiting shortly after cx18.ko loaded. The cx18 driver allocating large amounts kernel memory for DMA buffers upon load may be related to triggering the problem, but I doubt it is a root cause of the BUG. This monsterous thread from 5 years ago is somewhat enlightening: http://lkml.indiana.edu/hypermail/linux/kernel/0503.2/1680.html http://lkml.indiana.edu/hypermail/linux/kernel/0503.2/1787.html so it gives me a place to start looking for the problem. Any advice on what data to collect is appreciated. When attemtping to reproduce this BUG, I got another bug related to memory management: (Details handtyped from a photo): BUG: unable to handle kernel NULL pointer dereference at (null) IP: [010f22fa] remove_vm_area+0x42/0x77 PGD 37cdd067 PUD 336c__67 PMD 0 Oops: [#1] SMP last sysfs file: /sys/devices/pci:00/:00:14.4/:03:00.0/firmware/:03:00.0/loading CPU 0 Modules linked in: tda9887 tda8290 mxl5005s s5h1409 tuner_simple tuner_types cx5345 tuner cx18(+) dvb_core cx2341x ... Pid: 2470, comm: work_for_cpu Tainted: GW 2.6.28-rc2-cx18-vb2-proto+ RIP: 0010:[010f22fa] [010f22fa] remove_vm_area+0x42/0x77 ... RAX: RBX: 35e7c540 RCX: 1000 RDX: ... CR2: Stack: __0011485968 001 1147dc9_ _1_f23__ Call Trace: ... __vunmap+0x3e/0xbd ... vfree+0x2e/0x30 ... dvb_dmx_init+0x7e/0x253 [dvb_core] ... cx18_dvb_register+0xd2/0x75c [cx18] ... cx18_streams_resgister+0x6a/0x26a [cx18] ... cx18_streams_setup+0x3cc/0x486 [cx18] ... cx18_probe+0x11cc/0x12fb [cx18] .. The code appears to be failing here: /home/andy/cx18dev/git/media_tree/mm/vmalloc.c:1352 161d: eb 06 jmp1625 remove_vm_area+0x45 161f: 48 89 c2mov%rax,%rdx 1622: 48 8b 00mov(%rax),%rax--- Oops p = tmp-next) (tmp = *p) 1625: 48 39 d8cmp%rbx,%rax(tmp = *p) != vm; 1628: 75 f5 jne161f
[PATCH 1/2] v4l-utils: remove conflicting definitions in keymap for imon_mce
v4l-utils: Trivial patch that removes doublicate and conflicting definitions of keys. The patch is checked against a git pull of today. Signed-off-by: Hans-Frieder Vogt hfv...@gmx.net imon_mce |2 -- 1 file changed, 2 deletions(-) --- a/utils/keytable/rc_keymaps/imon_mce2011-02-19 19:04:44.974793906 +0100 +++ b/utils/keytable/rc_keymaps/imon_mce2011-03-06 21:47:10.527674607 +0100 @@ -16,7 +16,6 @@ 0x800ff420 KEY_LEFT 0x800ff421 KEY_RIGHT 0x800ff40b KEY_ENTER -0x0228 KEY_ENTER 0x0228 KEY_OK 0x800ff422 KEY_OK 0x022a KEY_EXIT @@ -67,7 +66,6 @@ 0x800ff45d KEY_YELLOW 0x800ff45e KEY_BLUE 0x800ff466 KEY_RED -0x800ff425 KEY_GREEN 0x800ff468 KEY_YELLOW 0x800ff41d KEY_BLUE 0x800ff40f KEY_INFO Hans-Frieder Vogt e-mail: hfvogt at gmx .dot. net -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] v4l-utils: change keymap to better reflect key names on imon_mce remote
v4l-utils: the key definitions in the imon_mce keymap do not currently reflect well the names printed on the remote: key on remote is named back, but keymap uses exit, key on remote is named Teletext, but keymap uses subtitle In addition, I think that menu is rather representative to the key named DVD menu than just DVD Please change the keymap as proposed in my patch. It applies on top of my patch 1/2 as of today which removes doublicates in the imon_mce keymap. Signed-off-by: Hans-Frieder Vogt hfv...@gmx.net imon_mce |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/utils/keytable/rc_keymaps/imon_mce2011-03-06 21:47:10.527674607 +0100 +++ b/utils/keytable/rc_keymaps/imon_mce2011-03-06 19:26:06.263297972 +0100 @@ -18,7 +18,7 @@ 0x800ff40b KEY_ENTER 0x0228 KEY_OK 0x800ff422 KEY_OK -0x022a KEY_EXIT +0x022a KEY_BACK 0x800ff423 KEY_EXIT 0x0229 KEY_DELETE 0x800ff40a KEY_DELETE @@ -56,7 +56,7 @@ 0x800ff448 KEY_PVR 0x800ff449 KEY_CAMERA 0x800ff44a KEY_VIDEO -0x800ff424 KEY_DVD +0x800ff424 KEY_MENU 0x800ff425 KEY_TUNER 0x800ff450 KEY_RADIO 0x800ff44c KEY_LANGUAGE @@ -70,7 +70,7 @@ 0x800ff41d KEY_BLUE 0x800ff40f KEY_INFO 0x800ff426 KEY_EPG -0x800ff45a KEY_SUBTITLE +0x800ff45a KEY_TEXT 0x800ff44d KEY_TITLE 0x800ff40c KEY_POWER 0x800ff40d KEY_LEFTMETA Hans-Frieder Vogt e-mail: hfvogt at gmx .dot. net -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/2] v4l: videobuf2: Handle buf_queue errors
Hi Laurent,
On Tue, Mar 1, 2011 at 02:54, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi Pawel,
On Monday 28 February 2011 16:44:38 Pawel Osciak wrote:
Hi Laurent,
A few questions from me below. I feel we need to talk about this
change a bit more, it introduces some recovery and consistency
problems, unless I'm missing something.
On Sun, Feb 27, 2011 at 10:12, Laurent Pinchart wrote:
videobuf2 expects drivers to check buffer in the buf_prepare operation
and to return success only if the buffer can queued without any issue.
For hot-pluggable devices, disconnection events need to be handled at
buf_queue time. Checking the disconnected flag and adding the buffer to
the driver queue need to be performed without releasing the driver
spinlock, otherwise race conditions can occur in which the driver could
still allow a buffer to be queued after the disconnected flag has been
set, resulting in a hang during the next DQBUF operation.
This problem can be solved either in the videobuf2 core or in the device
drivers. To avoid adding a spinlock to videobuf2, make buf_queue return
an int and handle buf_queue failures in videobuf2. Drivers must not
return an error in buf_queue if the condition leading to the error can
be caught in buf_prepare.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/videobuf2-core.c | 32
++-- include/media/videobuf2-core.h |
2 +-
2 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c index cc7ab0a..1d81536 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -798,13 +798,22 @@ static int __qbuf_mmap(struct vb2_buffer *vb,
struct v4l2_buffer *b) /**
* __enqueue_in_driver() - enqueue a vb2_buffer in driver for processing
*/
-static void __enqueue_in_driver(struct vb2_buffer *vb)
+static int __enqueue_in_driver(struct vb2_buffer *vb)
{
struct vb2_queue *q = vb-vb2_queue;
+ int ret;
vb-state = VB2_BUF_STATE_ACTIVE;
atomic_inc(q-queued_count);
- q-ops-buf_queue(vb);
+ ret = q-ops-buf_queue(vb);
+ if (ret == 0)
+ return 0;
+
+ vb-state = VB2_BUF_STATE_ERROR;
+ atomic_dec(q-queued_count);
+ wake_up_all(q-done_wq);
+
+ return ret;
Unless I am missing something, when this happens for an n-th buffer,
we wake up all, but only one buffer will have the ERROR state, all the
other will be in QUEUED state. This will mess up return values from
dqbuf (if this happens on streamon) for other buffers, they will have
their V4L2_BUF_FLAG_QUEUED set after dqbuf. Also, returning 0 from
DQBUF and the V4L2_BUF_FLAG_ERROR for the failed buffer suggests that
streaming may continue.
Actually not quite, as the driver is expected to mark all buffers as erroneous
and wake up userspace when the disconnection event is received. Subsequent
calls to VIDIOC_QBUF (or VIDIOC_STREAMON) need to return an error. I'm not
sure if we need to wake up userspace then, as applications shouldn't sleep on
VIDIOC_DQBUF or select() after VIDIOC_QBUF or VIDIOC_STREAMON returned an
error.
Ok, but what do you mean by driver marking them as erroneous? By
issuing vb2_buffer_done with *_ERROR as parameter? Also, you meant
that vb2 should be waking userspace, right? I believe we should aim
for a solution that would require the driver to do as little as
possible and move everything to vb2.
vb2_dqbuf will return EINVAL and poll()/select() should fail because
they check for streaming state. As long as the disconnection event
(e.g. failed qbuf) disables streaming flag in vb2, we should be ok.
So how do we recover from this disconnection event? What is the
general idea? If buf_queue fails, can we restart from some point (i.e.
reuse the buffers later) or do we have to clean up completely (i.e.
deallocate, etc.)? Right now we are staying in an undefined state.
If we cannot recover, we shouldn't be setting V4L2_BUF_FLAG_ERROR, but
returning a stronger error instead and maybe clean up the rest, which
is not waited for somehow. If we can recover on the other hand, we
shouldn't be probably waking up all sleepers or at least giving them
meaningful errors.
I think a disconnection is pretty fatal. If the user unplugs the webcam,
there's not much that can be done anymore. Userspace needs to be woken up with
all buffers marked as erroneous, and the next QBUF call needs to return an
error without queuing any buffer. We need to define the expected behaviour in
the V4L2 spec, so that applications can rely on it and implement it properly.
I would also like to handle this inside videobuf2 if possible (something like
vb2_disconnect() ?) to ensure that all drivers behave correctly, but I'm not
sure if that will be possible without
Re: [RFC/PATCH 1/2] v4l: videobuf2: Handle buf_queue errors
On Sun, 2011-03-06 at 15:20 -0800, Pawel Osciak wrote: Hi Laurent, On Tue, Mar 1, 2011 at 02:54, Laurent Pinchart I think a disconnection is pretty fatal. If the user unplugs the webcam, there's not much that can be done anymore. Userspace needs to be woken up with all buffers marked as erroneous, and the next QBUF call needs to return an error without queuing any buffer. We need to define the expected behaviour in the V4L2 spec, so that applications can rely on it and implement it properly. I would also like to handle this inside videobuf2 if possible (something like vb2_disconnect() ?) to ensure that all drivers behave correctly, but I'm not sure if that will be possible without messing locking up. I definitely agree that videbuf2 should handle as much as possible and it shouldn't be left up to drivers. Although I'm not an expert in USB, shouldn't a disconnection event cause a removal of the device node? Hi Pawel, I would think it should cause the device node to be unlink()-ed from the filesystem. However, even though the device node has been unlink()-ed from the filesystem, all the currently open file descriptors still exist and need to be intelligently handled by the driver until they are closed. Could you explain how does that work for USB devices in general? If not, we may need a more general state in vb2, something like device inoperable. Not only qbuf should fail then, but almost everything should. And memory should be freed. I feel there will be the locking problems as well. The USB layer or cdev should take a reference on the driver module so it can't be unloaded until all the open file descriptors are closed. The driver itself (and maybe videobuf2?) will need to reference count structures that must not be kfree()-ed if a file descriptor is still open. . I definitely agree that we need to add this to the V4L2 spec. So could we start from that point? Could we maybe start with a general flow and expected behavior for a disconnection event? I guess we both have some ideas in mind, but first I'd like to establish what will happen in linux driver/USB core when a device is disconnected. My understanding is that the driver is removed and module is unloaded, but how does that happen if we are in the middle of something? Could you give an example of what happens after a disconnect a camera? A module cannot be unloaded, as long as anything has a reference to the module text using get_module(). If a file descriptor for the driver is still open, something should be holding a reference to the driver module text, so that it cannot be unloaded. In the case of an underlying device being disconnected, the driver has to do something sensible as long as file descriptors for that disconnected device remain open. In fixing up lirc_zilog, an IR device driver, I used locked reference counters to get() and put() pointers to objetcs for the underlying devices. I then had to modify all the driver code to sensibly handle the case when a get() of an object pointer to an underlying device came back as NULL. I suspect Laurent probably had to deal with similar issues already in his changes for v4l2_subdev's. Because it is all still fresh in my mind, what follow are (lengthy) details about how lirc_zilog handles the problem with a disconnect of an IR device. Hopefully it provides something useful for you... lirc_zilog can have the bridge driver (ivtv, cx18, pvrusb2, or hdpvr) removed out from under it, or have the underlying USB device disconnected (pvrusb2, hdpvr), while /dev/lircN device nodes are still open. Here is the sum of my rework to support that gracefully: http://git.linuxtv.org/awalls/media_tree.git?a=blob;f=drivers/staging/lirc/lirc_zilog.c;h=40195ef55e6dcfb4b10c8ff132eb81d551a253a8;hb=8a1f6484fd16ef990d588cc3b979416b2dca23bd It was more work than I expected. Pointers to instances of the following items in that driver are reference counted: struct IR // a Z8 IR device instance struct IR_tx// the Tx function instance of a Z8 instance struct IR_rx// the Rx function instance of a Z8 instance and the structres themselves maintain pointers to each other (which are not exempt from the reference counting) ++ v| struct IR ---+ | | | | | | + struct IR_rx --+ | | | +-- struct IR_tx -+ The pointers to object instances are handed out like this on device probe; each reference given out is counted: a struct IRpointer is given to the struct IR_rx instance a struct IR_rx pointer is given to the struct IRinstance a struct IR_rx pointer is given to the RX i2c_client instance a struct IRpointer is given to the struct IR_tx instance a struct IR_tx pointer is given to the
Re: BUG at mm/mmap.c:2309 when cx18.ko and cx18-alsa.ko loaded
On Sun, 6 Mar 2011, Andy Walls wrote: On Sun, 2011-03-06 at 10:37 -0800, Hugh Dickins wrote: There was a horrid list corruption bug in early 2.6.38-rc, fixed in -rc6; but although I guess it could cause all kinds of havoc, its particular signature was not like this, so I don't really believe that one was to blame here. Sounds like it may be worth me reviewing the commits that introduced the failure and the commit that fixed it. Do you happen to know what they are? Here are the several fixes, which reference LKML threads and culprits: it seems to have been a danger since 2.6.33, made much worse recently. commit ceaaec98ad99859ac90ac6863ad0a6cd075d8e0e Author: Eric Dumazet eric.duma...@gmail.com Date: Thu Feb 17 22:59:19 2011 + net: deinit automatic LIST_HEAD commit 9b5e383c11b08784 (net: Introduce unregister_netdevice_many()) left an active LIST_HEAD() in rollback_registered(), with possible memory corruption. Even if device is freed without touching its unreg_list (and therefore touching the previous memory location holding LISTE_HEAD(single), better close the bug for good, since its really subtle. (Same fix for default_device_exit_batch() for completeness) Reported-by: Michal Hocko mho...@suse.cz Tested-by: Michal Hocko mho...@suse.cz Reported-by: Eric W. Biderman ebider...@xmission.com Tested-by: Eric W. Biderman ebider...@xmission.com Signed-off-by: Linus Torvalds torva...@linux-foundation.org Signed-off-by: Eric Dumazet eric.duma...@gmail.com CC: Ingo Molnar mi...@elte.hu CC: Octavian Purdila opurd...@ixiacom.com CC: stable sta...@kernel.org [.33+] Signed-off-by: David S. Miller da...@davemloft.net commit f87e6f47933e3ebeced9bb12615e830a72cedce4 Author: Linus Torvalds torva...@linux-foundation.org Date: Thu Feb 17 22:54:38 2011 + net: dont leave active on stack LIST_HEAD Eric W. Biderman and Michal Hocko reported various memory corruptions that we suspected to be related to a LIST head located on stack, that was manipulated after thread left function frame (and eventually exited, so its stack was freed and reused). Eric Dumazet suggested the problem was probably coming from commit 443457242beb (net: factorize sync-rcu call in unregister_netdevice_many) This patch fixes __dev_close() and dev_close() to properly deinit their respective LIST_HEAD(single) before exiting. References: https://lkml.org/lkml/2011/2/16/304 References: https://lkml.org/lkml/2011/2/14/223 Reported-by: Michal Hocko mho...@suse.cz Tested-by: Michal Hocko mho...@suse.cz Reported-by: Eric W. Biderman ebider...@xmission.com Tested-by: Eric W. Biderman ebider...@xmission.com Signed-off-by: Linus Torvalds torva...@linux-foundation.org Signed-off-by: Eric Dumazet eric.duma...@gmail.com CC: Ingo Molnar mi...@elte.hu CC: Octavian Purdila opurd...@ixiacom.com Signed-off-by: David S. Miller da...@davemloft.net commit 3c18d4de86e4a7f93815c081e50e0543fa27200f Author: Linus Torvalds torva...@linux-foundation.org Date: Fri Feb 18 11:32:28 2011 -0800 Expand CONFIG_DEBUG_LIST to several other list operations When list debugging is enabled, we aim to readably show list corruption errors, and the basic list_add/list_del operations end up having extra debugging code in them to do some basic validation of the list entries. However, list_del_init() and list_move[_tail]() ended up avoiding the debug code due to how they were written. This fixes that. So the _next_ time we have list_move() problems with stale list entries, we'll hopefully have an easier time finding them.. Signed-off-by: Linus Torvalds torva...@linux-foundation.org -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
