Hi Bastian,
On Thursday 28 April 2011 13:04:15 Bastian Hecht wrote:
> 2011/4/27 Laurent Pinchart :
> > On Wednesday 27 April 2011 12:55:24 Bastian Hecht wrote:
> >> 2011/4/27 Bastian Hecht :
> >> > 2011/4/26 Laurent Pinchart :
> >> >> On Tuesday 26 April 2011 17:39:41 Bastian Hecht wrote:
> >> >>>
2011/4/27 Laurent Pinchart :
> Hi Bastian,
>
> On Wednesday 27 April 2011 12:55:24 Bastian Hecht wrote:
>> 2011/4/27 Bastian Hecht :
>> > 2011/4/26 Laurent Pinchart :
>> >> On Tuesday 26 April 2011 17:39:41 Bastian Hecht wrote:
>> >>> 2011/4/21 Laurent Pinchart :
>> >>> > On Tuesday 19 April 2011 0
Hi Bastian,
On Wednesday 27 April 2011 12:55:24 Bastian Hecht wrote:
> 2011/4/27 Bastian Hecht :
> > 2011/4/26 Laurent Pinchart :
> >> On Tuesday 26 April 2011 17:39:41 Bastian Hecht wrote:
> >>> 2011/4/21 Laurent Pinchart :
> >>> > On Tuesday 19 April 2011 09:31:05 Sakari Ailus wrote:
> >>> >> La
2011/4/27 Bastian Hecht :
> 2011/4/26 Laurent Pinchart :
>> Hi Bastian,
>>
>> On Tuesday 26 April 2011 17:39:41 Bastian Hecht wrote:
>>> 2011/4/21 Laurent Pinchart :
>>> > On Tuesday 19 April 2011 09:31:05 Sakari Ailus wrote:
>>> >> Laurent Pinchart wrote:
>>> >> ...
>>> >>
>>> >> > That's the idea
2011/4/26 Laurent Pinchart :
> Hi Bastian,
>
> On Tuesday 26 April 2011 17:39:41 Bastian Hecht wrote:
>> 2011/4/21 Laurent Pinchart :
>> > On Tuesday 19 April 2011 09:31:05 Sakari Ailus wrote:
>> >> Laurent Pinchart wrote:
>> >> ...
>> >>
>> >> > That's the ideal situation: sensors should not produ
Hi Bastian,
On Tuesday 26 April 2011 17:39:41 Bastian Hecht wrote:
> 2011/4/21 Laurent Pinchart :
> > On Tuesday 19 April 2011 09:31:05 Sakari Ailus wrote:
> >> Laurent Pinchart wrote:
> >> ...
> >>
> >> > That's the ideal situation: sensors should not produce any data (or
> >> > rather any trans
2011/4/21 Laurent Pinchart :
> Hi Sakari,
>
> On Tuesday 19 April 2011 09:31:05 Sakari Ailus wrote:
>> Laurent Pinchart wrote:
>> ...
>>
>> > That's the ideal situation: sensors should not produce any data (or
>> > rather any transition on the VS/HS signals) when they're supposed to be
>> > stopped
Hi Sakari,
On Tuesday 19 April 2011 09:31:05 Sakari Ailus wrote:
> Laurent Pinchart wrote:
> ...
>
> > That's the ideal situation: sensors should not produce any data (or
> > rather any transition on the VS/HS signals) when they're supposed to be
> > stopped. Unfortunately that's not always easy,
Laurent Pinchart wrote:
...
> That's the ideal situation: sensors should not produce any data (or rather
> any
> transition on the VS/HS signals) when they're supposed to be stopped.
> Unfortunately that's not always easy, as some dumb sensors (or sensor-like
> hardware) can't be stopped. The I
On Monday 18 April 2011 16:17:15 David Cohen wrote:
> On Mon, Apr 18, 2011 at 1:43 PM, Bastian Hecht wrote:
> > 2011/4/16 David Cohen:
> >> On Thu, Apr 14, 2011 at 1:36 PM, Bastian Hecht wrote:
> >>> Yeah!
> >>>
> >>> S... when I initialized the the camera (loading a 108 bytes
> >>> register l
On Mon, Apr 18, 2011 at 1:43 PM, Bastian Hecht wrote:
> 2011/4/16 David Cohen :
>> Hi Bastian,
>>
>> On Thu, Apr 14, 2011 at 1:36 PM, Bastian Hecht wrote:
>>> Yeah!
>>>
>>> S... when I initialized the the camera (loading a 108 bytes
>>> register listing) I just let run the camera and sent ima
2011/4/16 David Cohen :
> Hi Bastian,
>
> On Thu, Apr 14, 2011 at 1:36 PM, Bastian Hecht wrote:
>> 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++ > 1
Hi Bastian,
On Thu, Apr 14, 2011 at 1:36 PM, Bastian Hecht wrote:
> 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
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 af
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
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 t
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
Hello,
I attached the output without extra kernel lock info, here is the debug output:
[ 375.811157] BUG: soft lockup - CPU#0 stuck for 61s! [yavta:2226]
[ 375.817474] Kernel panic - not syncing: softlockup: hung tasks
[ 375.823364] [] (unwind_backtrace+0x0/0xe4) from
[] (panic+0x50/0xd4)
[
Hello people,
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.
All extra locking debug output is enabled in the kernel .config.
I am unsure if this is
19 matches
Mail list logo
