Re: em28xx: msi Digivox ATSC board id [0db0:8810]

On Thu, Dec 6, 2012 at 8:40 PM, Matthew Gyurgyik wrote: > I was able to do a bit of testing tonight and this is what I found. > > A channel scan was unsuccessful: > http://pyther.net/a/digivox_atsc/dec06/scan.txt (no errors in dmesg) > > Changing channels by pressing "h" in "mplayer dvb://" caused

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

On 12/06/2012 05:58 PM, Matthew Gyurgyik wrote: On 12/06/2012 04:49 PM, Frank Schäfer wrote: Did you switch back to .mpeg_mode = LGDT3305_MPEG_SERIAL, .tpclk_edge = LGDT3305_TPCLK_FALLING_EDGE, in struct lgdt3305_config em2874_lgdt3305_dev (em28xx-dvb.c) before testing

Unsere Referenz: G20/CT/GA12

Unsere Referenz: G20/CT/GA12 Wir freuen uns, Ihnen mitzuteilen, dass Sie von der G-20 wurden ausgewahlt, um ein Preisgeld von $ 861,937.00 USD Preis zu erhalten. Weitere Informationen zu den Bedingungen der Zahlung wird in seiner Antwort veroffentlicht werden. Wir erwarten empfangt eine schnelle A

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

On 12/06/2012 04:49 PM, Frank Schäfer wrote: Did you switch back to .mpeg_mode = LGDT3305_MPEG_SERIAL, .tpclk_edge = LGDT3305_TPCLK_FALLING_EDGE, in struct lgdt3305_config em2874_lgdt3305_dev (em28xx-dvb.c) before testing this ? You could also play with the other gpio

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

On 12/06/2012 04:49 PM, Frank Schäfer wrote: Did you switch back to .mpeg_mode = LGDT3305_MPEG_SERIAL, .tpclk_edge = LGDT3305_TPCLK_FALLING_EDGE, in struct lgdt3305_config em2874_lgdt3305_dev (em28xx-dvb.c) before testing this ? I did not, but switching back doesn't hel

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

Am 06.12.2012 23:03, schrieb Devin Heitmueller: > On Thu, Dec 6, 2012 at 5:01 PM, Frank Schäfer > wrote: >> That's possible, because Matthews log doesn't show any access to this >> register. >> If it is not used, the question is if writing 0x07 to this register can >> cause any trouble... > Histor

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

On Thu, Dec 6, 2012 at 5:01 PM, Frank Schäfer wrote: > That's possible, because Matthews log doesn't show any access to this > register. > If it is not used, the question is if writing 0x07 to this register can > cause any trouble... Historically speaking, on that family of devices registers that

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

Am 06.12.2012 22:57, schrieb Devin Heitmueller: > On Thu, Dec 6, 2012 at 4:49 PM, Frank Schäfer > wrote: >> Am 06.12.2012 03:16, schrieb Matthew Gyurgyik: >>> On 12/05/2012 07:55 PM, Antti Palosaari wrote: It was good snoop. I didn't saw nothing very interesting. But, I think I found the

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

On Thu, Dec 6, 2012 at 4:49 PM, Frank Schäfer wrote: > > Am 06.12.2012 03:16, schrieb Matthew Gyurgyik: > > On 12/05/2012 07:55 PM, Antti Palosaari wrote: > >> > >> It was good snoop. I didn't saw nothing very interesting. But, I > >> think I found the reason. Just add that one line writing 0x42 t

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

Am 06.12.2012 03:32, schrieb Matthew Gyurgyik: > On 12/04/2012 04:06 PM, Frank Schäfer wrote: >> >> I double-checked the log and it is indeed set to LGDT3305_MPEG_SERIAL, >> but LGDT3305_TPCLK_FALLING_EDGE is used instead of >> LGDT3305_TPCLK_RISING_EDGE. >> OTOH, the KWorld A340 bord sets this to

Re: em28xx: msi Digivox ATSC board id [0db0:8810]

Am 06.12.2012 03:16, schrieb Matthew Gyurgyik: > On 12/05/2012 07:55 PM, Antti Palosaari wrote: >> >> It was good snoop. I didn't saw nothing very interesting. But, I >> think I found the reason. Just add that one line writing 0x42 to >> register 0x0d. IIRC I saw earlier it caused that kind of bug.

cron job: media_tree daily build: ERRORS

This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Thu Dec 6 19:00:20 CET 2012 git hash:16427faf28674451a7a0485ab0a929402f355ffd gcc version: i686-linux-gcc (GCC

[PATCH v3 3/4] sta2x11_vip: convert to videobuf2 and control framework

This patch re-write the driver and use the videobuf2 interface instead of the old videobuf. Moreover, it uses also the control framework which allows the driver to inherit controls from its subdevice (ADV7180) Signed-off-by: Federico Vaga Acked-by: Giancarlo Asnaghi --- drivers/media/pci/sta2x1

Re: [PATCH v3] media: V4L2: add temporary clock helpers

Hi Guennadi, On Thursday 06 December 2012 08:41:41 Guennadi Liakhovetski wrote: > On Thu, 6 Dec 2012, Laurent Pinchart wrote: > > On Tuesday 04 December 2012 11:42:15 Guennadi Liakhovetski wrote: > > > Typical video devices like camera sensors require an external clock > > > source. Many such devi

Re: [PATCHv15 2/7] video: add display_timing and videomode

On Mon, 26 Nov 2012 16:39:58 +0100, Steffen Trumtrar wrote: > On Mon, Nov 26, 2012 at 02:37:26PM +0200, Tomi Valkeinen wrote: > > On 2012-11-26 11:07, Steffen Trumtrar wrote: > > > > > +/* > > > + * Subsystem independent description of a videomode. > > > + * Can be generated from struct display_

Re: [PATCH RFC v2] media: v4l2-ctrl: Add gain controls

Hi Prabhakar and Hans, On Thu, Dec 06, 2012 at 10:24:18AM +0530, Prabhakar Lad wrote: > Hi Hans, > > On Wed, Dec 5, 2012 at 5:38 PM, Hans Verkuil wrote: > > (resend without HTML formatting) > > > > On Wed 5 December 2012 12:49:29 Prabhakar Lad wrote: > >> From: Lad, Prabhakar > >> > >> add supp

dvb-tools: scan_data/cz-all: 4th multiplex has FEC 3/4

-- js # HG changeset patch # User Jiri Slaby # Date 1354786687 -3600 # Node ID c72238053530a0ad8e446af2cce0cb8d14c9640a # Parent 96025655e6e844af2bc69bd368f8d04a4e5bc58b scan_data/cz-all: 4th multiplex has FEC 3/4 Not 2/3. This I inappropriatelly got from the website. But it is wrong. 3/4 is d