Re: MIPI flag support updated
Hi On Fri, 15 Apr 2011, Kassey Lee wrote: > Hi, Guennadi , Hans: > > > I've updated the patch to support MIPI flag for camera sensor > and host controller as you suggested, would you please have time to > review ? It's queued for 2.6.40 > > http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/27609/focus=28195 > > thanks Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
MIPI flag support updated
Hi, Guennadi , Hans: I've updated the patch to support MIPI flag for camera sensor and host controller as you suggested, would you please have time to review ? http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/27609/focus=28195 thanks -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] V4L2 API for flash devices
Laurent Pinchart wrote: > Hi Sakari, Heippa, > On Wednesday 13 April 2011 14:16:38 Sakari Ailus wrote: >> Sung Hee Park wrote: >>> Here are two more use-cases for flash that might help inform the API >>> design. Sakari encouraged me to post these. The person writing this is >>> Andrew Adams, but I'm sending this from Sung Hee's account, because I >>> only just subscribed to linux-media and can't immediately figure out how >>> to reply to messages from before I subscribed. Sung Hee and I are both >>> grad students at Stanford who work on FCam >>> (http://fcam.garage.maemo.org/) >> >> Hi Andrew, >> >> Many thanks for the comments. >> >>> Second-curtain-sync: >>> >>> Sometimes you want to fire the flash at the end of a long exposure time. >>> It's usually a way to depict motion. Here's an example: >>> http://www.flickr.com/photos/latitudes/133206615/. >>> >>> This only really applies to xenon flashes because you can't get a crisp >>> image out of a longer duration LED flash. Even then it's somewhat >>> problematic on rolling-shutter sensors but still possible provided you >>> don't mind a slight shear to the crisp part of the image. From an API >>> perspective, it requires you to be able to specify a trigger time at >>> some number of microseconds into the exposure. On the N900 we did this >>> with a real-time thread. >>> >>> Triggering external hardware: >>> >>> This use-case is a little weirder, but it has the same API requirement. >>> Some photographic setups require you to synchronize some piece of >>> hardware with the exposure (e.g. an oscilloscope, or an external slave >>> flash). On embedded devices this is generally difficult. If you can at >>> least fire the flash at a precise delay into the exposure, you can >>> attach a photodiode to it, and use the flash+photodiode as an >>> opto-isolator to trigger your external hardware. >>> >>> So we're in favor of having user-settable flash duration, and also >>> user-settable trigger times (with reference to the start of the exposure >>> time). I'm guessing that in a SMIA++ driver the trigger time would >>> actually be a control on the sensor device, but it seemed relevant to >>> bring up while you guys were talking about the flash API. >> >> From this I reckon that in a general case the handling of the flash >> timing cannot be left for the drivers only. There must be a way to >> control it. >> >> So I'd think that also the level/edge trigger for the flash should be >> visible. On edge trigger, the only limiting factor for the flash >> duration on hardware would be the relatively coarse watchdog timer, and >> I'd think the user should be able to know that. > > I agree that the user should be able to query the limit. The limit value > should come from platform data. Agreed. >> The flash timing controls should be exposed by the sensor driver since >> the sensor is what actually performs the timing. >> >> Laurent; what do you think? > > As already discussed with you offline, I think we will need flash timing > controls on the sensor when the flash controller is configured with external > strobe in level triggered mode. I'm still not sure if the > edge/level-triggered > names are the best option. They confused me in the beginning, so I find them > confusing :-) If we keep them, they will need to be very precisely documented. I'm fine with other naming --- edge/level is from the AS3645 documentation. ADP1653 does not call it with a name as far as I remember. Other similar chips can be found here: http://www.austriamicrosystems.com/eng/Products/Lighting-Management/> I tried to download the datasheets but couldn't. The AS3645 datasheet, however, is also available here: http://www.cdiweb.com/datasheets/austriamicro/AS3645_Datasheet_v1-6.pdf> Regards, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] tm6000: fix vbuf may be used uninitialized
Hi I think it's good. No regression, all works well. With my best regards, Dmitry. > In commit 8aff8ba95155df, most of the manipulations to vbuf inside > copy_streams were gated on if !dev->radio, but one place that touches > vbuf lays outside those gates -- a memcpy of vbuf isn't NULL. If we > initialize vbuf to NULL, that memcpy will never happen in the case > where we do have dev->radio, and otherwise, in the !dev->radio case, > the code behaves exactly like it did prior to 8aff8ba95155df. > > While we're at it, also fix an incorrectly indented closing brace for > one of the sections touching vbuf that is conditional on !dev->radio. > > v2: add a detailed commit log and fix that brace > > CC: Dan Carpenter > CC: Dmitri Belimov > CC: de...@driverdev.osuosl.org > Signed-off-by: Jarod Wilson > --- > drivers/staging/tm6000/tm6000-video.c |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/tm6000/tm6000-video.c > b/drivers/staging/tm6000/tm6000-video.c index c80a316..8b971a0 100644 > --- a/drivers/staging/tm6000/tm6000-video.c > +++ b/drivers/staging/tm6000/tm6000-video.c > @@ -228,7 +228,7 @@ static int copy_streams(u8 *data, unsigned long > len, unsigned long header = 0; > int rc = 0; > unsigned int cmd, cpysize, pktsize, size, field, block, > line, pos = 0; > - struct tm6000_buffer *vbuf; > + struct tm6000_buffer *vbuf = NULL; > char *voutp = NULL; > unsigned int linewidth; > > @@ -318,7 +318,7 @@ static int copy_streams(u8 *data, unsigned long > len, if (pos + size > vbuf->vb.size) > cmd = > TM6000_URB_MSG_ERR; dev->isoc_ctl.vfield = field; > - } > + } > break; > case TM6000_URB_MSG_VBI: > break; > -- > 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: [RFC] V4L2 API for flash devices
Hi Sakari, On Wednesday 13 April 2011 14:16:38 Sakari Ailus wrote: > Sung Hee Park wrote: > > Here are two more use-cases for flash that might help inform the API > > design. Sakari encouraged me to post these. The person writing this is > > Andrew Adams, but I'm sending this from Sung Hee's account, because I > > only just subscribed to linux-media and can't immediately figure out how > > to reply to messages from before I subscribed. Sung Hee and I are both > > grad students at Stanford who work on FCam > > (http://fcam.garage.maemo.org/) > > Hi Andrew, > > Many thanks for the comments. > > > Second-curtain-sync: > > > > Sometimes you want to fire the flash at the end of a long exposure time. > > It's usually a way to depict motion. Here's an example: > > http://www.flickr.com/photos/latitudes/133206615/. > > > > This only really applies to xenon flashes because you can't get a crisp > > image out of a longer duration LED flash. Even then it's somewhat > > problematic on rolling-shutter sensors but still possible provided you > > don't mind a slight shear to the crisp part of the image. From an API > > perspective, it requires you to be able to specify a trigger time at > > some number of microseconds into the exposure. On the N900 we did this > > with a real-time thread. > > > > Triggering external hardware: > > > > This use-case is a little weirder, but it has the same API requirement. > > Some photographic setups require you to synchronize some piece of > > hardware with the exposure (e.g. an oscilloscope, or an external slave > > flash). On embedded devices this is generally difficult. If you can at > > least fire the flash at a precise delay into the exposure, you can > > attach a photodiode to it, and use the flash+photodiode as an > > opto-isolator to trigger your external hardware. > > > > So we're in favor of having user-settable flash duration, and also > > user-settable trigger times (with reference to the start of the exposure > > time). I'm guessing that in a SMIA++ driver the trigger time would > > actually be a control on the sensor device, but it seemed relevant to > > bring up while you guys were talking about the flash API. > > From this I reckon that in a general case the handling of the flash > timing cannot be left for the drivers only. There must be a way to > control it. > > So I'd think that also the level/edge trigger for the flash should be > visible. On edge trigger, the only limiting factor for the flash > duration on hardware would be the relatively coarse watchdog timer, and > I'd think the user should be able to know that. I agree that the user should be able to query the limit. The limit value should come from platform data. > The flash timing controls should be exposed by the sensor driver since > the sensor is what actually performs the timing. > > Laurent; what do you think? As already discussed with you offline, I think we will need flash timing controls on the sensor when the flash controller is configured with external strobe in level triggered mode. I'm still not sure if the edge/level-triggered names are the best option. They confused me in the beginning, so I find them confusing :-) If we keep them, they will need to be very precisely documented. -- 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
[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:Thu Apr 14 19:00:28 CEST 2011 git hash:d9954d8547181f9a6a23f835cc1413732700b785 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: OK linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS linux-2.6.36-i686: ERRORS linux-2.6.37-i686: ERRORS linux-2.6.38.2-i686: ERRORS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS linux-2.6.36-x86_64: ERRORS linux-2.6.37-x86_64: ERRORS linux-2.6.38.2-x86_64: ERRORS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
rc_maps.cfg default config for hauppauge
Hi! The default rc_maps.cfg doesn't work for hauppauge remotes, because there's no rc_keymaps/hauppauge, only rc_keymaps/haupp. Also, there's no config for rc-hauppauge-new table, so I made the following changes: $diff rc_maps.cfg_orig rc_maps.cfg 113c113 < * rc-rc5-hauppauge hauppauge --- > * rc-rc5-hauppauge haupp 118a119 > * rc-hauppauge-new haupp It works with my HVR-1100 and 45 button remote. Andris -- 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: KNC ONE DVB-C [1894:0022] can't find any channels, PAT/SDT/NIT filter timeout
On Thu, Apr 14, 2011 at 2:38 AM, Frantisek Augusztin wrote: > Tested using Arch Linux 2.6.37-ARCH and current 2.6.39-rc3 kernels, > same result. > > Signal level according to the set top box is ~57%, signal quality is > 97-99%, and as i mentoined, set top box works without problems, and > it works using this DVB-C card and same cable when using with Windows > (but true, on different PC). Small follow-up - moved the card to other PC (P67 board), installed a completely different distribution (MythDora), result is exactly the same - filter timeouts. Rebooting on same PC to Windows, leaving the card and cable connection as is, i have no problems searching for channels and watching them using the official Windows driver and application (GlobeTV Digital). I'm seriously out of ideas, the dmesg messages look right, even if i can't find the device listed by exactly the same name on the wiki (KNC1 DVB-C MK3), but i guess this is the TDA10023 revision mentioned on wiki page : Linux video capture interface: v2.00 saa7146: register extension 'budget_av'. budget_av :05:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 saa7146: found saa7146 @ mem f8036000 (revision 1, irq 16) (0x1894,0x0022). saa7146 (0): dma buffer size 192512 DVB: registering new adapter (KNC1 DVB-C MK3) adapter failed MAC signature check encoded MAC from EEPROM was ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff KNC1-0: MAC addr = 00:09:d6:6d:a5:f4 DVB: registering adapter 0 frontend 0 (Philips TDA10023 DVB-C)... budget-av: ci interface initialised. budget-av: cam inserted A dvb_ca adapter 0: DVB CAM detected and initialised successfully -- Frantisek Augusztin -- 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] mt9v022: fix pixel clock
The setup of the pixel clock is done wrong in the mt9v022 driver. The 'Invert Pixel Clock' bit has to be set to 1 for falling edge and not for rising. This is not clearly described in the data sheet. Tested on pcm037 and pcm027/pcm990. Signed-off-by: Teresa Gámez --- drivers/media/video/mt9v022.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c index 6a784c8..dec2a69 100644 --- a/drivers/media/video/mt9v022.c +++ b/drivers/media/video/mt9v022.c @@ -228,7 +228,7 @@ static int mt9v022_set_bus_param(struct soc_camera_device *icd, flags = soc_camera_apply_sensor_flags(icl, flags); - if (flags & SOCAM_PCLK_SAMPLE_RISING) + if (flags & SOCAM_PCLK_SAMPLE_FALLING) pixclk |= 0x10; if (!(flags & SOCAM_HSYNC_ACTIVE_HIGH)) -- 1.7.0.4 -- 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: Antwort: Re: [PATCH 1/2] mt9v022: fix pixel clock
Am Mittwoch, den 13.04.2011, 08:31 +0200 schrieb Guennadi Liakhovetski: > Hello Teresa > > Thanks very much for your extensive testing! I'm afraid, I don't have the > time right now to go through all those register settings, so, can we, > maybe, do the following: we currently have two platforms in the mainline, > that use mt9v022. We believe, that the driver itself implements the pixel > clock edge configuration wrongly. Could you please provide patches to > > 1. fix mt9v022 to match our new understanding > 2. if needed - additionally fix pcm037 by setting the >SOCAM_SENSOR_INVERT_PCLK flag > 3. same for pcm990 / pcm027 As I can see only the driver code has to be changed. Platformcode for pcm037 and pcm990 is ok. I will resend the patch. > I also noticed your "wrong colours" result - if colours are completely > swapped, maybe you just have to adjust your Bayer decoder? They are not completely swapped. There some areas where it looks fine and others where the colors are wrong or the pixels are noisy. > Once we get those patches, I'll try to test them, but I've a very tight > schedule atm, so, maybe I'll just believe you to get them on time for > 2.6.39. Thank you for testing this, too. Teresa > > Thanks > Guennadi > > On Tue, 12 Apr 2011, Teresa Gamez wrote: > > > Am Freitag, den 08.04.2011, 15:27 +0200 schrieb Teresa Gamez: > > > Hello Guennadi, > > > > > > Am Donnerstag, den 07.04.2011, 14:41 +0200 schrieb Guennadi > > > Liakhovetski: > > > > Hello Teresa > > > > > > > > On Thu, 7 Apr 2011, Teresa Gamez wrote: > > > > > > > > > Hello Guennadi, > > > > > > > > > > the datasheet also says (see table 3): > > > > > > > > > > > > > > > Pixel clock out. DOUT is valid on rising edge of this > > > > > clock. > > > > > > > > > > > > > > > There is a difference between DOUT beeing vaild and DOUT beeing set > > > > > up. > > > > > So does SOCAM_PCLK_SAMPLE_RISING mean that the data is valid at > > > > > rising > > > > > edge or > > > > > does it mean the data is set up at rising edge? > > > > > > > > Hm, yeah, looks like a typical example of a copy-paste datasheet to > > > > me:-( > > > > And now we don't know which of the two is actually supposed to be true. > > > > As > > > > for "set up" vs. "valid" - not sure, whether there is indeed a > > > > difference > > > > between them. To me "set up _TO_ the rising edge" is a short way to set > > > > "set up to be valid at the rising edge," however, I might be wrong. Can > > > > you tell me in more detail what and where (at the sensor board or on > > > > the > > > > baseboard) you measured and what it looked like? I think, Figure 7 and > > > > the > > > > description below it are interesting. From that diagram I would indeed > > > > say > > > > indeed the DOUT pins are valid and should be sampled at the rising edge > > > > by > > > > default - when bit 4 in 0x74 is not set. SOCAM_PCLK_SAMPLE_RISING > > > > means, > > > > that the data should be sampled at the rising of pclkm, i.e., it is > > > > valid > > > > there. > > > > > > I meassured the outgoing pins from the baseboard to the camera board and > > > checked the PCLK and D0 to see at which point the data is valid. I have > > > also checked the quality of the image. > > > All tests where made with sensor_type=color > > > > > > My results for pcm038 are with following register settings: > > > > > > mx2_camera > > > 0x0 CSICR1: 0x10020b92 > > > -> rising edge > > > > > > mt9v022 > > > 0x74 PIXCLK_FV_LV: 0x0010 > > > -> rising edge (which I think is falling edge) > > > > > > meassured: falling edge (ugly image, wrong colors) > > > > > > Now I set the SOCAM_SENSOR_INVERT_PCLK flag in the platformcode for the > > > mt9v022: > > > > > > mx2_camera > > > 0x0 CSICR1 0x10020b92 > > > -> rising edge > > > > > > mt9v022 > > > 0x74 PIXCLK_FV_LV 0x > > > -> falling edge (which I think is rising edge) > > > > > > meassured: rising edge (image is OK) > > > > > > Now changed the PCLK of the mx2_camera: > > > > > > mx2_camera > > > 0x0 CSICR1 0x10020b90 > > > -> falling edge > > > > > > mt9v022 > > > 0x74 PIXCLK_FV_LV0x0010 > > > -> rising edge (which I think is falling edge) > > > > > > meassured: falling edge (image is OK) > > > > > > > > > > > So, yes, if your measurements agree with figure 7 from the datasheet, > > > > we > > > > shall assume, that the driver implements the pclk polarity wrongly. But > > > > the fix should be more extensive, than what you've submitted: if we > > > > invert > > > > driver's behaviour, we should also invert board configuration of all > > > > driver users: pcm990 and pcm037. Or we have to test them and verify, > > > > that > > > > the inverted pclk polarity doesn't megatively affect the image quality, > > > > or > > > > maybe even improves it. > > > > > > > > Thanks > > > > Guennadi > > > > > > > > > I have tested this with a pcm038
Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
Hello. On 14-04-2011 1:01, Janusz Krzysztofik wrote: After switching from mem->dma_handle to virt_to_phys(mem->vaddr) used for obtaining page frame number passed to remap_pfn_range() (commit 35d9f510b67b10338161aba6229d4f55b4000f5b), videobuf-dma-contig Please specify the commit summary -- for the human readers. Hi, OK, I'll try to reword the summary using a more human friendly language as soon as I have signs that Mauro (who seemed to understand the message well enough) is willing to accept the code. I wasn't asking you to rework your summary but to specify the summary of the commit you've mentioned (in parens). Ah, I see. How about just reordered wording: After commit 35d9f510b67b10338161aba6229d4f55b4000f5b (switching from mem->dma_handle to virt_to_phys(mem->vaddr) used for obtaining page frame number passed to remap_pfn_range()), Do you think this would be clear enough? As I can see, the summary of that commit is "[media] V4L: videobuf, don't use dma addr as physical". That's what you should have inserted. Thanks, Janusz WBR, Sergei -- 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: OMAP3 ISP deadlocks on my new arm
Yeah!
S... when I initialized the the camera (loading a 108 bytes
register listing) I just let run the camera and sent images. So I
first realized a counter overflow if (count++ > 10) after a few
seconds. But this seemed to be handled correctly (ignore and delete
HS_VS_IRQ flag) while after 2 or more yavta calls it made the driver
hang.
I modified my register listing so that the chip gets "booted" silently.
In
static struct v4l2_subdev_video_ops framix_subdev_video_ops = {
.s_stream = framix_s_stream, <===
};
I correctly check the stream status now and enable/disable the camera signals.
I am unsure whether the isp should be able to handle an ongoing data
stream independently of ISP_PIPELINE_STREAM_STOPPED.
If you decide it should, I will gladly help you find out more, just
ask. It worked on an OMAP3530 before, but I do not know if it is the
hardware or isp software that changed. Unfortunately I can't get an
3530 anymore (I trashed mine...).
You helped me so much! Big thanks.
Bastian Hecht
2011/4/14 Laurent Pinchart :
> Hi Bastian,
>
> On Thursday 14 April 2011 10:33:12 Bastian Hecht wrote:
>> 2011/4/13 Sakari Ailus :
>> > Bastian Hecht wrote:
>> >> Hello people,
>> >
>> > Hi Bastian,
>> >
>> > I'm cc'ing Laurent.
>> >
>> >> I switched to the new DM3730 from IGEP and while it's supposed to be
>> >> (almost) the same as the 3530 Version the isp deadlocks
>> >> deterministically after I start capturing the second time with yavta.
>> >
>> > Does the capture work the first time w/o issues?
>>
>> Yes, I can always run yavta once capturing 4 frames (3 skipped, last
>> saved). It usually deadlocks when running yavta the second time but I had
>> 1 successful 2nd try (out of 20 maybe).
>>
>> >> All extra locking debug output is enabled in the kernel .config.
>> >
>> > I'm not fully certain on what this exactly is that you have below, but
>> > it looks like your system is staying in interrupt context all the time.
>> > My guess is that the ISP is producing interrupts that the driver is not
>> > handling properly, causing the interrupt handler to be called again
>> > immediately.
>>
>> Nice! OK, I'd like to fully understand the panic output, maybe you can
>> help there:
>> After
>> [ 376.016906] [] (_raw_spin_unlock_irqrestore+0x40/0x44)
>> from [] (omap3isp_video_queue_streamon+0x80/0x90
>> the IRQs get enabled again. Immediately our offending irq wants to get
>> served but noone is clearing it.
>> At some time, the timer interrupt triggers the watchdog for a kernel panic.
>> So the last exception block is the process context that is currently
>> active. But why are there 2 irq routines displayed? Is the middle one the
>> hardware handling that causes a software irq to be triggered (upper
>> block)?
>>
>> So my next step could be to find the unhandled irq number?
>
> If the problem is caused by an interrupt storm, the following patch will make
> your system responsive again after a couple of seconds (but will kill the ISP
> driver :-)). If it doesn't, the problem is likely caused by something else.
>
> diff --git a/drivers/media/video/omap3isp/isp.c
> b/drivers/media/video/omap3isp/isp.c
> index de2dec5..6497300 100644
> --- a/drivers/media/video/omap3isp/isp.c
> +++ b/drivers/media/video/omap3isp/isp.c
> @@ -462,6 +464,7 @@ static irqreturn_t isp_isr(int irq, void *_isp)
> IRQ0STATUS_CCDC_VD0_IRQ |
> IRQ0STATUS_CCDC_VD1_IRQ |
> IRQ0STATUS_HS_VS_IRQ;
> + static unsigned int count = 0;
> struct isp_device *isp = _isp;
> u32 irqstatus;
> int ret;
> @@ -469,6 +472,11 @@ static irqreturn_t isp_isr(int irq, void *_isp)
> irqstatus = isp_reg_readl(isp, OMAP3_ISP_IOMEM_MAIN, ISP_IRQ0STATUS);
> isp_reg_writel(isp, irqstatus, OMAP3_ISP_IOMEM_MAIN, ISP_IRQ0STATUS);
>
> + if (count++ > 10) {
> + isp_disable_interrupts(isp);
> + return IRQ_HANDLED;
> + }
> +
> isp_isr_sbl(isp);
>
> if (irqstatus & IRQ0STATUS_CSIA_IRQ) {
>
>
>> > Do you have the same sensor working on OMAP 3530?
>>
>> I never had this problem on an OMAP 3530, although I better test it
>> again with the current setup. I try to get my hands on an 3530 today.
>>
>> >> I am unsure if this is an ISP thing or a problem in the
>> >> interrupthandling software.
>> >
>> > This has probably something to do with the ISP driver. :-)
>> >
>> >> The first block is the watchdog that detects the deadlock. The last
>> >> block is in the isp-code but how can it hang when trying to UNlock a
>> >> spinlock? I am unsure about the 2nd block.
>> >> The assembler code of __irq_svc is located in
>> >> arch/arm/kernel/entry-armv.S Maybe I should try on
>> >> linux-...@lists.arm.linux.org.uk but I thought I give it a shot here
>> >> first.
>> >>
>> >> I use the omap3isp-2.6.35.3-omap3isp branch from Laurent.
>> >
>> > Why so old kernel
[PATCH] media: vb2: correct queue initialization order
q->memory entry is initialized to late, so if allocation of memory buffers fails, the buffers might not be freed correctly (q->memory is tested in __vb2_free_mem, which can be called before setting q->memory). Reported-by: Kamil Debski Signed-off-by: Marek Szyprowski Signed-off-by: Kyungmin Park CC: Pawel Osciak --- drivers/media/video/videobuf2-core.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/videobuf2-core.c b/drivers/media/video/videobuf2-core.c index 6698c77..25feda7 100644 --- a/drivers/media/video/videobuf2-core.c +++ b/drivers/media/video/videobuf2-core.c @@ -519,6 +519,7 @@ int vb2_reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req) num_buffers = min_t(unsigned int, req->count, VIDEO_MAX_FRAME); memset(plane_sizes, 0, sizeof(plane_sizes)); memset(q->alloc_ctx, 0, sizeof(q->alloc_ctx)); + q->memory = req->memory; /* * Ask the driver how many buffers and planes per buffer it requires. @@ -560,8 +561,6 @@ int vb2_reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req) ret = num_buffers; } - q->memory = req->memory; - /* * Return the number of successfully allocated buffers * to the userspace. -- 1.7.1.569.g6f426 -- 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: OMAP3 ISP deadlocks on my new arm
Hi Bastian,
On Thursday 14 April 2011 10:33:12 Bastian Hecht wrote:
> 2011/4/13 Sakari Ailus :
> > Bastian Hecht wrote:
> >> Hello people,
> >
> > Hi Bastian,
> >
> > I'm cc'ing Laurent.
> >
> >> I switched to the new DM3730 from IGEP and while it's supposed to be
> >> (almost) the same as the 3530 Version the isp deadlocks
> >> deterministically after I start capturing the second time with yavta.
> >
> > Does the capture work the first time w/o issues?
>
> Yes, I can always run yavta once capturing 4 frames (3 skipped, last
> saved). It usually deadlocks when running yavta the second time but I had
> 1 successful 2nd try (out of 20 maybe).
>
> >> All extra locking debug output is enabled in the kernel .config.
> >
> > I'm not fully certain on what this exactly is that you have below, but
> > it looks like your system is staying in interrupt context all the time.
> > My guess is that the ISP is producing interrupts that the driver is not
> > handling properly, causing the interrupt handler to be called again
> > immediately.
>
> Nice! OK, I'd like to fully understand the panic output, maybe you can
> help there:
> After
> [ 376.016906] [] (_raw_spin_unlock_irqrestore+0x40/0x44)
> from [] (omap3isp_video_queue_streamon+0x80/0x90
> the IRQs get enabled again. Immediately our offending irq wants to get
> served but noone is clearing it.
> At some time, the timer interrupt triggers the watchdog for a kernel panic.
> So the last exception block is the process context that is currently
> active. But why are there 2 irq routines displayed? Is the middle one the
> hardware handling that causes a software irq to be triggered (upper
> block)?
>
> So my next step could be to find the unhandled irq number?
If the problem is caused by an interrupt storm, the following patch will make
your system responsive again after a couple of seconds (but will kill the ISP
driver :-)). If it doesn't, the problem is likely caused by something else.
diff --git a/drivers/media/video/omap3isp/isp.c
b/drivers/media/video/omap3isp/isp.c
index de2dec5..6497300 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -462,6 +464,7 @@ static irqreturn_t isp_isr(int irq, void *_isp)
IRQ0STATUS_CCDC_VD0_IRQ |
IRQ0STATUS_CCDC_VD1_IRQ |
IRQ0STATUS_HS_VS_IRQ;
+ static unsigned int count = 0;
struct isp_device *isp = _isp;
u32 irqstatus;
int ret;
@@ -469,6 +472,11 @@ static irqreturn_t isp_isr(int irq, void *_isp)
irqstatus = isp_reg_readl(isp, OMAP3_ISP_IOMEM_MAIN, ISP_IRQ0STATUS);
isp_reg_writel(isp, irqstatus, OMAP3_ISP_IOMEM_MAIN, ISP_IRQ0STATUS);
+ if (count++ > 10) {
+ isp_disable_interrupts(isp);
+ return IRQ_HANDLED;
+ }
+
isp_isr_sbl(isp);
if (irqstatus & IRQ0STATUS_CSIA_IRQ) {
> > Do you have the same sensor working on OMAP 3530?
>
> I never had this problem on an OMAP 3530, although I better test it
> again with the current setup. I try to get my hands on an 3530 today.
>
> >> I am unsure if this is an ISP thing or a problem in the
> >> interrupthandling software.
> >
> > This has probably something to do with the ISP driver. :-)
> >
> >> The first block is the watchdog that detects the deadlock. The last
> >> block is in the isp-code but how can it hang when trying to UNlock a
> >> spinlock? I am unsure about the 2nd block.
> >> The assembler code of __irq_svc is located in
> >> arch/arm/kernel/entry-armv.S Maybe I should try on
> >> linux-...@lists.arm.linux.org.uk but I thought I give it a shot here
> >> first.
> >>
> >> I use the omap3isp-2.6.35.3-omap3isp branch from Laurent.
> >
> > Why so old kernel?
>
> I tried a newer version, but there I couldn't get it booting with my
> igep. The kernel unpacked and tried to boot but it froze.
> I decided to use a version that is officially is supported by the igep
> team.
The ttyS* OMAP serial devices have been renamed to ttyO* in 2.6.37. Replace
/dev/ttyS2 with /dev/ttyO2 on your kernel command line (either in the kernel
config file if you've activated CONFIG_CMDLINE_FORCE, or in the boot loader
environment variables) and you should be able to boot 2.6.38 without any
issue. Don't forget to modify /etc/inittab as well.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 ISP deadlocks on my new arm
Hello Sakari, 2011/4/13 Sakari Ailus : > Bastian Hecht wrote: >> Hello people, > > Hi Bastian, > > I'm cc'ing Laurent. > >> I switched to the new DM3730 from IGEP and while it's supposed to be >> (almost) the same as the 3530 Version the isp deadlocks >> deterministically after I start capturing the second time with yavta. > > Does the capture work the first time w/o issues? Yes, I can always run yavta once capturing 4 frames (3 skipped, last saved). It usually deadlocks when running yavta the second time but I had 1 successful 2nd try (out of 20 maybe). >> All extra locking debug output is enabled in the kernel .config. > > I'm not fully certain on what this exactly is that you have below, but > it looks like your system is staying in interrupt context all the time. > My guess is that the ISP is producing interrupts that the driver is not > handling properly, causing the interrupt handler to be called again > immediately. Nice! OK, I'd like to fully understand the panic output, maybe you can help there: After [ 376.016906] [] (_raw_spin_unlock_irqrestore+0x40/0x44) from [] (omap3isp_video_queue_streamon+0x80/0x90 the IRQs get enabled again. Immediately our offending irq wants to get served but noone is clearing it. At some time, the timer interrupt triggers the watchdog for a kernel panic. So the last exception block is the process context that is currently active. But why are there 2 irq routines displayed? Is the middle one the hardware handling that causes a software irq to be triggered (upper block)? So my next step could be to find the unhandled irq number? > Do you have the same sensor working on OMAP 3530? I never had this problem on an OMAP 3530, although I better test it again with the current setup. I try to get my hands on an 3530 today. >> I am unsure if this is an ISP thing or a problem in the >> interrupthandling software. > > This has probably something to do with the ISP driver. :-) > >> The first block is the watchdog that detects the deadlock. The last >> block is in the isp-code but how can it hang when trying to UNlock a >> spinlock? I am unsure about the 2nd block. >> The assembler code of __irq_svc is located in arch/arm/kernel/entry-armv.S >> Maybe I should try on linux-...@lists.arm.linux.org.uk but I thought I >> give it a shot here first. >> >> I use the omap3isp-2.6.35.3-omap3isp branch from Laurent. > > Why so old kernel? I tried a newer version, but there I couldn't get it booting with my igep. The kernel unpacked and tried to boot but it froze. I decided to use a version that is officially is supported by the igep team. Thanks so much for this valuable guess! Bastian Hecht > I think you'd be best off using this one: > > http://git.linuxtv.org/pinchartl/media.git?a=shortlog;h=refs/heads/omap3isp-next-omap3isp> > >> Any ideas? Thanks for any help, >> >> Bastian Hecht >> >> >> [ 190.059509] BUG: soft lockup - CPU#0 stuck for 61s! [yavta:2224] >> [ 190.065704] Kernel panic - not syncing: softlockup: hung tasks >> [ 190.071563] [] (unwind_backtrace+0x0/0xe4) from >> [] (panic+0x50/0xd0) >> [ 190.079711] [] (panic+0x50/0xd0) from [] >> (softlockup_tick+0x134/0x158) >> [ 190.088043] [] (softlockup_tick+0x134/0x158) from >> [] (update_process_times+0x28/0x48) >> [ 190.097656] [] (update_process_times+0x28/0x48) from >> [] (tick_sched_timer+0x88/0xbc) >> [ 190.107177] [] (tick_sched_timer+0x88/0xbc) from >> [] (__run_hrtimer+0x44/0x84) >> [ 190.116119] [] (__run_hrtimer+0x44/0x84) from >> [] (hrtimer_interrupt+0x114/0x2c8) >> [ 190.125305] [] (hrtimer_interrupt+0x114/0x2c8) from >> [] (omap2_gp_timer_interrupt+0x20/0x2c) >> [ 190.135437] [] (omap2_gp_timer_interrupt+0x20/0x2c) from >> [] (handle_IRQ_event+0x24/0xe0) >> [ 190.145324] [] (handle_IRQ_event+0x24/0xe0) from >> [] (handle_level_irq+0x90/0xfc) >> [ 190.154510] [] (handle_level_irq+0x90/0xfc) from >> [] (asm_do_IRQ+0x6c/0x8c) >> [ 190.163177] [] (asm_do_IRQ+0x6c/0x8c) from [] >> (__irq_svc+0x34/0x80) >> [ 190.171234] Exception stack(0xda413c98 to 0xda413ce0) >> [ 190.176300] 3c80: >> 0020 c03c20d0 >> [ 190.184509] 3ca0: c0417240 da412000 0002 >> ded72e84 000a dec54640 >> [ 190.192718] 3cc0: c0417240 0002 da413ce0 c0051bd4 >> c0051ad8 2113 >> [ 190.200958] [] (__irq_svc+0x34/0x80) from [] >> (__do_softirq+0x3c/0xf8) >> [ 190.209167] [] (__do_softirq+0x3c/0xf8) from [] >> (irq_exit+0x40/0x8c) >> [ 190.217315] [] (irq_exit+0x40/0x8c) from [] >> (asm_do_IRQ+0x70/0x8c) >> [ 190.225280] [] (asm_do_IRQ+0x70/0x8c) from [] >> (__irq_svc+0x34/0x80) >> [ 190.233306] Exception stack(0xda413d20 to 0xda413d68) >> [ 190.238403] 3d20: defc4938 defc48c0 defc4084 ded72e84 ded72e14 >> ded72e80 4013 ded72e84 >> [ 190.246612] 3d40: ded72e68 dec54640 dedc5a38 defc40f8 >> da413d68 bf01d4cc bf01d4ec >> [ 190.254821] 3d60: 6013 >> [ 190.258361] [] (__irq_svc+0x34/0x80) from [] >> (omap3isp_video_queue_streamon+0x6c/0x7c [om
[PATCH] media: vb2: fix incorrect v4l2_buffer->flags handling
Videobuf2 core assumes that driver doesn't set any buffer flags.
This is correct for buffer state flags that videobuf2 manages,
but the other flags like V4L2_BUF_FLAG_{KEY,P,B}FRAME,
V4L2_BUF_FLAG_TIMECODE and V4L2_BUF_FLAG_INPUT should be passed from or to
the driver.
Reported-by: Jonghun Han
Signed-off-by: Marek Szyprowski
Signed-off-by: Kyungmin Park
CC: Pawel Osciak
---
drivers/media/video/videobuf2-core.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 6698c77..3ceacea 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -37,6 +37,9 @@ module_param(debug, int, 0644);
#define call_qop(q, op, args...) \
(((q)->ops->op) ? ((q)->ops->op(args)) : 0)
+#define V4L2_BUFFER_STATE_FLAGS(V4L2_BUF_FLAG_MAPPED |
V4L2_BUF_FLAG_QUEUED | \
+V4L2_BUF_FLAG_DONE | V4L2_BUF_FLAG_ERROR)
+
/**
* __vb2_buf_mem_alloc() - allocate video memory for the given buffer
*/
@@ -284,7 +287,7 @@ static int __fill_v4l2_buffer(struct vb2_buffer *vb, struct
v4l2_buffer *b)
struct vb2_queue *q = vb->vb2_queue;
int ret = 0;
- /* Copy back data such as timestamp, input, etc. */
+ /* Copy back data such as timestamp, flags, input, etc. */
memcpy(b, &vb->v4l2_buf, offsetof(struct v4l2_buffer, m));
b->input = vb->v4l2_buf.input;
b->reserved = vb->v4l2_buf.reserved;
@@ -313,7 +316,10 @@ static int __fill_v4l2_buffer(struct vb2_buffer *vb,
struct v4l2_buffer *b)
b->m.userptr = vb->v4l2_planes[0].m.userptr;
}
- b->flags = 0;
+ /*
+* Clear any buffer state related flags.
+*/
+ b->flags &= ~V4L2_BUFFER_STATE_FLAGS;
switch (vb->state) {
case VB2_BUF_STATE_QUEUED:
@@ -715,6 +721,8 @@ static int __fill_vb2_buffer(struct vb2_buffer *vb, struct
v4l2_buffer *b,
vb->v4l2_buf.field = b->field;
vb->v4l2_buf.timestamp = b->timestamp;
+ vb->v4l2_buf.input = b->input;
+ vb->v4l2_buf.flags = b->flags & ~V4L2_BUFFER_STATE_FLAGS;
return 0;
}
--
1.7.1.569.g6f426
--
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
