[linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz

[linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz

[jerremy]

Hi,

This issue has come up at least once a bit more then a month ago and is
still present in the current release of the V4L-DVB drivers. The
Technotrend C-1501 drivers are unable to get a lock on 388Mhz (and a couple
of other frequencies, like 682Mhz and 322Mhz, but I can only test 388Mhz). 

The dmesg will mention an I2C timeout when this occurs, I'm not sure if its
related (as it'll randomly give those timeouts when viewing working
channels too).

I have two seperate installs of Linux (Ubuntu 8.04 64-Bit with 1 received
and Ubuntu 8.04 32-Bit with 2 receivers) which both suffer the same
inability to lock onto that frequency. So its unlikely to be a hardware
problem, also the Windows drivers do not seem to have any issues.

Is anyone looking into this issue? If not, what would be the place to
experiment?

Gr,

Jerremy Koot



_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz

[klaas de waal]

[-- Attachment #1.1: Type: text/plain, Size: 4924 bytes --]

Hi Jeremy,

I have the Technotrend C-1501 now locking at 388MHz.
The table tda827xa_dvbt contains the settings for each frequency segment.
The frequency values (first column) are for  the frequency plus the IF, so
for 388MHz
this is 388+5 gives 393 MHz. The table starts a new segment at 390MHz, it
then
starts to use VCO2 instead of VCO1.
I have now (hack, hack) changed the segment start from 390 to 395MHz so
that the 388MHz is still tuned with VCO1, and this works OK!!
Like this:

static const struct tda827xa_data tda827xa_dvbt[] = {
    { .lomax =  56875000, .svco = 3, .spd = 4, .scr = 0, .sbs = 0, .gc3 =
1},
    { .lomax =  67250000, .svco = 0, .spd = 3, .scr = 0, .sbs = 0, .gc3 =
1},
    { .lomax =  81250000, .svco = 1, .spd = 3, .scr = 0, .sbs = 0, .gc3 =
1},
    { .lomax =  97500000, .svco = 2, .spd = 3, .scr = 0, .sbs = 0, .gc3 =
1},
    { .lomax = 113750000, .svco = 3, .spd = 3, .scr = 0, .sbs = 1, .gc3 =
1},
    { .lomax = 134500000, .svco = 0, .spd = 2, .scr = 0, .sbs = 1, .gc3 =
1},
    { .lomax = 154000000, .svco = 1, .spd = 2, .scr = 0, .sbs = 1, .gc3 =
1},
    { .lomax = 162500000, .svco = 1, .spd = 2, .scr = 0, .sbs = 1, .gc3 =
1},
    { .lomax = 183000000, .svco = 2, .spd = 2, .scr = 0, .sbs = 1, .gc3 =
1},
    { .lomax = 195000000, .svco = 2, .spd = 2, .scr = 0, .sbs = 2, .gc3 =
1},
    { .lomax = 227500000, .svco = 3, .spd = 2, .scr = 0, .sbs = 2, .gc3 =
1},
    { .lomax = 269000000, .svco = 0, .spd = 1, .scr = 0, .sbs = 2, .gc3 =
1},
    { .lomax = 290000000, .svco = 1, .spd = 1, .scr = 0, .sbs = 2, .gc3 =
1},
    { .lomax = 325000000, .svco = 1, .spd = 1, .scr = 0, .sbs = 3, .gc3 =
1},
#ifdef ORIGINAL // KdW test
    { .lomax = 390000000, .svco = 2, .spd = 1, .scr = 0, .sbs = 3, .gc3 =
1},
#else
    { .lomax = 395000000, .svco = 2, .spd = 1, .scr = 0, .sbs = 3, .gc3 =
1},
#endif
    { .lomax = 455000000, .svco = 3, .spd = 1, .scr = 0, .sbs = 3, .gc3 =
1},
etc etc

I plan to do a test on the all frequencies in the near future, at
least on all the Dutch Ziggo frequencies.
Because I cannot test what will happen if the driver is used for DVB-T (what
the name of the table suggests) it might be best to make a separate
tda827xa_dvbc table.

About the timeout messages, they come from the SAA7134 and they happen
fairly random. I have looked at debug traces and everytime it happens it
does a retry and then succeeds, so I think this can be ignored for the time
being.
Maybe you can check if the fix/hack also works for you?
If there is an official maintainer of this driver, maybe he can comment?

Groetjes,
Klaas



On Tue, Sep 30, 2008 at 11:18 AM, <jerremy@wordtgek.nl> wrote:

> Hi Klaas,
>
> Perhaps its an idea to post this on the linux-dvb mailing list, if anything
> it keeps the subject alive.
>
> I've spent an hour or so playing with several of the parameters of the
> demodulator (the tda10023), mostly because this was suggest in one of the
> older posts about this issue. However none of my efforts gave any desired
> result and quickly got tired of unloading / reloading my drivers (which
> every so often required a hard reset as well).
>
> But if you find anything, that would be great ;)
>
> Gr. Jerremy
>
> On Mon, 29 Sep 2008 11:35:03 +0200, "klaas de waal"
> <klaas.de.waal@gmail.com> wrote:
> > Hallo Jeremy,
> > I have exactly the same problem with my C-1501 card: tuning problems on
> > 388
> > MHz but OK on most other frequencies.
> > It works OK with WIndowsXP on all frequencies including the 388MHz, so
> the
> > hardware is OK and it must be a software issue.
> > I have over the weekend put in a lot of printk for debugging but have not
> > found it yet.
> > I will keep you updated.
> >
> > Groetjes,
> > Klaas
> >
> >
> > On Thu, Sep 11, 2008 at 5:50 PM, <jerremy@wordtgek.nl> wrote:
> >
> >> Hi,
> >>
> >> This issue has come up at least once a bit more then a month ago and is
> >> still present in the current release of the V4L-DVB drivers. The
> >> Technotrend C-1501 drivers are unable to get a lock on 388Mhz (and a
> > couple
> >> of other frequencies, like 682Mhz and 322Mhz, but I can only test
> > 388Mhz).
> >>
> >> The dmesg will mention an I2C timeout when this occurs, I'm not sure if
> > its
> >> related (as it'll randomly give those timeouts when viewing working
> >> channels too).
> >>
> >> I have two seperate installs of Linux (Ubuntu 8.04 64-Bit with 1
> > received
> >> and Ubuntu 8.04 32-Bit with 2 receivers) which both suffer the same
> >> inability to lock onto that frequency. So its unlikely to be a hardware
> >> problem, also the Windows drivers do not seem to have any issues.
> >>
> >> Is anyone looking into this issue? If not, what would be the place to
> >> experiment?
> >>
> >> Gr,
> >>
> >> Jerremy Koot
> >>
> >>
> >>
> >> _______________________________________________
> >> linux-dvb mailing list
> >> linux-dvb@linuxtv.org
> >> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
> >>
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 6321 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz

[hermann pitton]

Hi,

Am Donnerstag, den 09.10.2008, 22:15 +0200 schrieb klaas de waal:
> Hi Jeremy,
> 
> I have the Technotrend C-1501 now locking at 388MHz.
> The table tda827xa_dvbt contains the settings for each frequency
> segment.
> The frequency values (first column) are for  the frequency plus the
> IF, so for 388MHz
> this is 388+5 gives 393 MHz. The table starts a new segment at 390MHz,
> it then
> starts to use VCO2 instead of VCO1.
> I have now (hack, hack) changed the segment start from 390 to 395MHz
> so
> that the 388MHz is still tuned with VCO1, and this works OK!!
> Like this:
> 
> static const struct tda827xa_data tda827xa_dvbt[] = {
>     { .lomax =  56875000, .svco = 3, .spd = 4, .scr = 0, .sbs =
> 0, .gc3 = 1},
>     { .lomax =  67250000, .svco = 0, .spd = 3, .scr = 0, .sbs =
> 0, .gc3 = 1},
>     { .lomax =  81250000, .svco = 1, .spd = 3, .scr = 0, .sbs =
> 0, .gc3 = 1},
>     { .lomax =  97500000, .svco = 2, .spd = 3, .scr = 0, .sbs =
> 0, .gc3 = 1},
>     { .lomax = 113750000, .svco = 3, .spd = 3, .scr = 0, .sbs =
> 1, .gc3 = 1},
>     { .lomax = 134500000, .svco = 0, .spd = 2, .scr = 0, .sbs =
> 1, .gc3 = 1},
>     { .lomax = 154000000, .svco = 1, .spd = 2, .scr = 0, .sbs =
> 1, .gc3 = 1},
>     { .lomax = 162500000, .svco = 1, .spd = 2, .scr = 0, .sbs =
> 1, .gc3 = 1},
>     { .lomax = 183000000, .svco = 2, .spd = 2, .scr = 0, .sbs =
> 1, .gc3 = 1},
>     { .lomax = 195000000, .svco = 2, .spd = 2, .scr = 0, .sbs =
> 2, .gc3 = 1},
>     { .lomax = 227500000, .svco = 3, .spd = 2, .scr = 0, .sbs =
> 2, .gc3 = 1},
>     { .lomax = 269000000, .svco = 0, .spd = 1, .scr = 0, .sbs =
> 2, .gc3 = 1},
>     { .lomax = 290000000, .svco = 1, .spd = 1, .scr = 0, .sbs =
> 2, .gc3 = 1},
>     { .lomax = 325000000, .svco = 1, .spd = 1, .scr = 0, .sbs =
> 3, .gc3 = 1},
> #ifdef ORIGINAL // KdW test
>     { .lomax = 390000000, .svco = 2, .spd = 1, .scr = 0, .sbs =
> 3, .gc3 = 1},
> #else
>     { .lomax = 395000000, .svco = 2, .spd = 1, .scr = 0, .sbs =
> 3, .gc3 = 1},
> #endif
>     { .lomax = 455000000, .svco = 3, .spd = 1, .scr = 0, .sbs =
> 3, .gc3 = 1},
> etc etc
> 
> I plan to do a test on the all frequencies in the near future, at
> least on all the Dutch Ziggo frequencies.
> Because I cannot test what will happen if the driver is used for DVB-T
> (what
> the name of the table suggests) it might be best to make a separate
> tda827xa_dvbc table.
> 
> About the timeout messages, they come from the SAA7134 and they happen
> fairly random. I have looked at debug traces and everytime it happens
> it
> does a retry and then succeeds, so I think this can be ignored for the
> time being.
> Maybe you can check if the fix/hack also works for you?
> If there is an official maintainer of this driver, maybe he can
> comment?
> 
> Groetjes,
> Klaas
> 

just scrolling through mails and did not look it up yet.

But you likely mean tda8274a DVB-C, tda10023 and saa7146.

Are we still here?
http://www.linuxtv.org/pipermail/linux-dvb/2008-April/025634.html

Please don't top post, you get more readers.

Cheers,
Hermann


> 
> On Tue, Sep 30, 2008 at 11:18 AM, <jerremy@wordtgek.nl> wrote:
>         Hi Klaas,
>         
>         Perhaps its an idea to post this on the linux-dvb mailing
>         list, if anything
>         it keeps the subject alive.
>         
>         I've spent an hour or so playing with several of the
>         parameters of the
>         demodulator (the tda10023), mostly because this was suggest in
>         one of the
>         older posts about this issue. However none of my efforts gave
>         any desired
>         result and quickly got tired of unloading / reloading my
>         drivers (which
>         every so often required a hard reset as well).
>         
>         But if you find anything, that would be great ;)
>         
>         Gr. Jerremy
>         
>         
>         On Mon, 29 Sep 2008 11:35:03 +0200, "klaas de waal"
>         <klaas.de.waal@gmail.com> wrote:
>         > Hallo Jeremy,
>         > I have exactly the same problem with my C-1501 card: tuning
>         problems on
>         > 388
>         > MHz but OK on most other frequencies.
>         > It works OK with WIndowsXP on all frequencies including the
>         388MHz, so
>         the
>         > hardware is OK and it must be a software issue.
>         > I have over the weekend put in a lot of printk for debugging
>         but have not
>         > found it yet.
>         > I will keep you updated.
>         >
>         > Groetjes,
>         > Klaas
>         >
>         >
>         > On Thu, Sep 11, 2008 at 5:50 PM, <jerremy@wordtgek.nl>
>         wrote:
>         >
>         >> Hi,
>         >>
>         >> This issue has come up at least once a bit more then a
>         month ago and is
>         >> still present in the current release of the V4L-DVB
>         drivers. The
>         >> Technotrend C-1501 drivers are unable to get a lock on
>         388Mhz (and a
>         > couple
>         >> of other frequencies, like 682Mhz and 322Mhz, but I can
>         only test
>         > 388Mhz).
>         >>
>         >> The dmesg will mention an I2C timeout when this occurs, I'm
>         not sure if
>         > its
>         >> related (as it'll randomly give those timeouts when viewing
>         working
>         >> channels too).
>         >>
>         >> I have two seperate installs of Linux (Ubuntu 8.04 64-Bit
>         with 1
>         > received
>         >> and Ubuntu 8.04 32-Bit with 2 receivers) which both suffer
>         the same
>         >> inability to lock onto that frequency. So its unlikely to
>         be a hardware
>         >> problem, also the Windows drivers do not seem to have any
>         issues.
>         >>
>         >> Is anyone looking into this issue? If not, what would be
>         the place to
>         >> experiment?
>         >>
>         >> Gr,
>         >>
>         >> Jerremy Koot
>         >>
>         >>




_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz

[Arthur Konovalov]

klaas de waal wrote:
> I have the Technotrend C-1501 now locking at 388MHz.
> The table tda827xa_dvbt contains the settings for each frequency segment.
> The frequency values (first column) are for  the frequency plus the IF, 
> so for 388MHz
> this is 388+5 gives 393 MHz. The table starts a new segment at 390MHz, 
> it then
> starts to use VCO2 instead of VCO1.
> I have now (hack, hack) changed the segment start from 390 to 395MHz so
> that the 388MHz is still tuned with VCO1, and this works OK!!
> Like this:
> 
> static const struct tda827xa_data tda827xa_dvbt[] = {
>     { .lomax =  56875000, .svco = 3, .spd = 4, .scr = 0, .sbs = 0, .gc3 
> = 1},
>     { .lomax =  67250000, .svco = 0, .spd = 3, .scr = 0, .sbs = 0, .gc3 
> = 1},
>     { .lomax =  81250000, .svco = 1, .spd = 3, .scr = 0, .sbs = 0, .gc3 
> = 1},
>     { .lomax =  97500000, .svco = 2, .spd = 3, .scr = 0, .sbs = 0, .gc3 
> = 1},
>     { .lomax = 113750000, .svco = 3, .spd = 3, .scr = 0, .sbs = 1, .gc3 
> = 1},
>     { .lomax = 134500000, .svco = 0, .spd = 2, .scr = 0, .sbs = 1, .gc3 
> = 1},
>     { .lomax = 154000000, .svco = 1, .spd = 2, .scr = 0, .sbs = 1, .gc3 
> = 1},
>     { .lomax = 162500000, .svco = 1, .spd = 2, .scr = 0, .sbs = 1, .gc3 
> = 1},
>     { .lomax = 183000000, .svco = 2, .spd = 2, .scr = 0, .sbs = 1, .gc3 
> = 1},
>     { .lomax = 195000000, .svco = 2, .spd = 2, .scr = 0, .sbs = 2, .gc3 
> = 1},
>     { .lomax = 227500000, .svco = 3, .spd = 2, .scr = 0, .sbs = 2, .gc3 
> = 1},
>     { .lomax = 269000000, .svco = 0, .spd = 1, .scr = 0, .sbs = 2, .gc3 
> = 1},
>     { .lomax = 290000000, .svco = 1, .spd = 1, .scr = 0, .sbs = 2, .gc3 
> = 1},
>     { .lomax = 325000000, .svco = 1, .spd = 1, .scr = 0, .sbs = 3, .gc3 
> = 1},
> #ifdef ORIGINAL // KdW test
>     { .lomax = 390000000, .svco = 2, .spd = 1, .scr = 0, .sbs = 3, .gc3 
> = 1},
> #else
>     { .lomax = 395000000, .svco = 2, .spd = 1, .scr = 0, .sbs = 3, .gc3 
> = 1},
> #endif
>     { .lomax = 455000000, .svco = 3, .spd = 1, .scr = 0, .sbs = 3, .gc3 
> = 1},
> etc etc

Is it patched only in this place or somewhere else?

I tried it to solve 386MHz tuning problem, but it doesn't help.
Got LOCK, but no picture.

Arthur


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz

[klaas de waal]

[-- Attachment #1.1: Type: text/plain, Size: 8366 bytes --]

On Fri, Oct 10, 2008 at 2:36 AM, hermann pitton <hermann-pitton@arcor.de>wrote:

> Hi,
>
> Am Donnerstag, den 09.10.2008, 22:15 +0200 schrieb klaas de waal:
> > Hi Jeremy,
> >
> > I have the Technotrend C-1501 now locking at 388MHz.
> > The table tda827xa_dvbt contains the settings for each frequency
> > segment.
> > The frequency values (first column) are for  the frequency plus the
> > IF, so for 388MHz
> > this is 388+5 gives 393 MHz. The table starts a new segment at 390MHz,
> > it then
> > starts to use VCO2 instead of VCO1.
> > I have now (hack, hack) changed the segment start from 390 to 395MHz
> > so
> > that the 388MHz is still tuned with VCO1, and this works OK!!
> > Like this:
> >
> > static const struct tda827xa_data tda827xa_dvbt[] = {
> >     { .lomax =  56875000, .svco = 3, .spd = 4, .scr = 0, .sbs =
> > 0, .gc3 = 1},
> >     { .lomax =  67250000, .svco = 0, .spd = 3, .scr = 0, .sbs =
> > 0, .gc3 = 1},
> >     { .lomax =  81250000, .svco = 1, .spd = 3, .scr = 0, .sbs =
> > 0, .gc3 = 1},
> >     { .lomax =  97500000, .svco = 2, .spd = 3, .scr = 0, .sbs =
> > 0, .gc3 = 1},
> >     { .lomax = 113750000, .svco = 3, .spd = 3, .scr = 0, .sbs =
> > 1, .gc3 = 1},
> >     { .lomax = 134500000, .svco = 0, .spd = 2, .scr = 0, .sbs =
> > 1, .gc3 = 1},
> >     { .lomax = 154000000, .svco = 1, .spd = 2, .scr = 0, .sbs =
> > 1, .gc3 = 1},
> >     { .lomax = 162500000, .svco = 1, .spd = 2, .scr = 0, .sbs =
> > 1, .gc3 = 1},
> >     { .lomax = 183000000, .svco = 2, .spd = 2, .scr = 0, .sbs =
> > 1, .gc3 = 1},
> >     { .lomax = 195000000, .svco = 2, .spd = 2, .scr = 0, .sbs =
> > 2, .gc3 = 1},
> >     { .lomax = 227500000, .svco = 3, .spd = 2, .scr = 0, .sbs =
> > 2, .gc3 = 1},
> >     { .lomax = 269000000, .svco = 0, .spd = 1, .scr = 0, .sbs =
> > 2, .gc3 = 1},
> >     { .lomax = 290000000, .svco = 1, .spd = 1, .scr = 0, .sbs =
> > 2, .gc3 = 1},
> >     { .lomax = 325000000, .svco = 1, .spd = 1, .scr = 0, .sbs =
> > 3, .gc3 = 1},
> > #ifdef ORIGINAL // KdW test
> >     { .lomax = 390000000, .svco = 2, .spd = 1, .scr = 0, .sbs =
> > 3, .gc3 = 1},
> > #else
> >     { .lomax = 395000000, .svco = 2, .spd = 1, .scr = 0, .sbs =
> > 3, .gc3 = 1},
> > #endif
> >     { .lomax = 455000000, .svco = 3, .spd = 1, .scr = 0, .sbs =
> > 3, .gc3 = 1},
> > etc etc
> >
> > I plan to do a test on the all frequencies in the near future, at
> > least on all the Dutch Ziggo frequencies.
> > Because I cannot test what will happen if the driver is used for DVB-T
> > (what
> > the name of the table suggests) it might be best to make a separate
> > tda827xa_dvbc table.
> >
> > About the timeout messages, they come from the SAA7134 and they happen
> > fairly random. I have looked at debug traces and everytime it happens
> > it
> > does a retry and then succeeds, so I think this can be ignored for the
> > time being.
> > Maybe you can check if the fix/hack also works for you?
> > If there is an official maintainer of this driver, maybe he can
> > comment?
> >
> > Groetjes,
> > Klaas
> >
>
> just scrolling through mails and did not look it up yet.
>
> But you likely mean tda8274a DVB-C, tda10023 and saa7146.
>
> Are we still here?
> http://www.linuxtv.org/pipermail/linux-dvb/2008-April/025634.html
>
> Please don't top post, you get more readers.
>
> Cheers,
> Hermann
>
>
> >
> > On Tue, Sep 30, 2008 at 11:18 AM, <jerremy@wordtgek.nl> wrote:
> >         Hi Klaas,
> >
> >         Perhaps its an idea to post this on the linux-dvb mailing
> >         list, if anything
> >         it keeps the subject alive.
> >
> >         I've spent an hour or so playing with several of the
> >         parameters of the
> >         demodulator (the tda10023), mostly because this was suggest in
> >         one of the
> >         older posts about this issue. However none of my efforts gave
> >         any desired
> >         result and quickly got tired of unloading / reloading my
> >         drivers (which
> >         every so often required a hard reset as well).
> >
> >         But if you find anything, that would be great ;)
> >
> >         Gr. Jerremy
> >
> >
> >         On Mon, 29 Sep 2008 11:35:03 +0200, "klaas de waal"
> >         <klaas.de.waal@gmail.com> wrote:
> >         > Hallo Jeremy,
> >         > I have exactly the same problem with my C-1501 card: tuning
> >         problems on
> >         > 388
> >         > MHz but OK on most other frequencies.
> >         > It works OK with WIndowsXP on all frequencies including the
> >         388MHz, so
> >         the
> >         > hardware is OK and it must be a software issue.
> >         > I have over the weekend put in a lot of printk for debugging
> >         but have not
> >         > found it yet.
> >         > I will keep you updated.
> >         >
> >         > Groetjes,
> >         > Klaas
> >         >
> >         >
> >         > On Thu, Sep 11, 2008 at 5:50 PM, <jerremy@wordtgek.nl>
> >         wrote:
> >         >
> >         >> Hi,
> >         >>
> >         >> This issue has come up at least once a bit more then a
> >         month ago and is
> >         >> still present in the current release of the V4L-DVB
> >         drivers. The
> >         >> Technotrend C-1501 drivers are unable to get a lock on
> >         388Mhz (and a
> >         > couple
> >         >> of other frequencies, like 682Mhz and 322Mhz, but I can
> >         only test
> >         > 388Mhz).
> >         >>
> >         >> The dmesg will mention an I2C timeout when this occurs, I'm
> >         not sure if
> >         > its
> >         >> related (as it'll randomly give those timeouts when viewing
> >         working
> >         >> channels too).
> >         >>
> >         >> I have two seperate installs of Linux (Ubuntu 8.04 64-Bit
> >         with 1
> >         > received
> >         >> and Ubuntu 8.04 32-Bit with 2 receivers) which both suffer
> >         the same
> >         >> inability to lock onto that frequency. So its unlikely to
> >         be a hardware
> >         >> problem, also the Windows drivers do not seem to have any
> >         issues.
> >         >>
> >         >> Is anyone looking into this issue? If not, what would be
> >         the place to
> >         >> experiment?
> >         >>
> >         >> Gr,
> >         >>
> >         >> Jerremy Koot
> >         >>
> >         >>
>

Hello Herman,


Thanks for your post. I had not seen this message
http://www.linuxtv.org/pipermail/linux-dvb/2008-April/025634.html
before. Probably a lot of work has been done since because the card worked
quite OK, only on the 388MHz it failed on me.

As mentioned in an earlier post, first I got my tuner working by modifying
the frequency map table tda827x_dvbt to use a different setting at 388MHz. I
have now put in a frequency map table tda827x_dvbc for DVB-C tuners only.
This works OK for me and it should not modify the behaviour with other
non-DVB-C demodulators.
With the dvb-apps/util/zap utility I get a lock on all Ziggo (Dutch cable TV
provider) frequencies. With MythTV-0.21 I can receive all the channels that
I am entitled to.

Remaining (non-fatal) issues are:

Error message:
*saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer*
This message comes once in a while and it happens at random places, it
cannot be correlated to a single place in the tda827x code. It really seems
random. I have read though a lot of traces and when this error happens it
does a retry and the retry succeeds.

Error message:
*tda827x: tda827x_config not defined, cannot set LNA gain!*
This message comes on every tuning action. I think that the TT-C1501 board
does not have a separate LNA outside the tuner so this is not really an
error. It shoudl be possible to fill in a tda827x_config struct so that it
does not give this error message. I could change the code to achieve this
but I do not want to change everything at once.

Minor issue:
*Signal strength not the same across the band.*
On the frequencies I can receive (from 252MHz to 826,75MHz) there is quite a
lot of signal strength variation; on MythTV display ranging from 60+ to 80+
percent, on zap output from 90 to d0 or so. On a KNC-One DVB-C card (cu1216
with tda10023 plus saa7146) the signal strength is practically constant.

I have attached my version of the tda827x.c driver, both as complete source
and as a diff against the hg version of 10 october.

Groetjes,
Klaas

[-- Attachment #1.2: Type: text/html, Size: 12114 bytes --]

[-- Attachment #2: tda827x.c.gz --]
[-- Type: application/x-gzip, Size: 4946 bytes --]

[-- Attachment #3: tda827x.c.patch.gz --]
[-- Type: application/x-gzip, Size: 1214 bytes --]

[-- Attachment #4: Type: text/plain, Size: 150 bytes --]

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz

[Arthur Konovalov]

klaas de waal wrote:
> I have now put in a frequency map table tda827x_dvbc 
> for DVB-C tuners only. This works OK for me and it should not modify the 
> behaviour with other non-DVB-C demodulators.

Unfortunately still does not works with 386MHz, at least in my case.
No lock, no picture...
Is it possible that 386MHz and 388MHz are in different frequency 
segments? Which values I should tune? Any hint, please.

AK


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz

[klaas de waal]

[-- Attachment #1.1: Type: text/plain, Size: 1361 bytes --]

On Mon, Oct 13, 2008 at 9:27 PM, Arthur Konovalov <artlov@gmail.com> wrote:

> klaas de waal wrote:
> > I have now put in a frequency map table tda827x_dvbc
> > for DVB-C tuners only. This works OK for me and it should not modify the
> > behaviour with other non-DVB-C demodulators.
>
> Unfortunately still does not works with 386MHz, at least in my case.
> No lock, no picture...
> Is it possible that 386MHz and 388MHz are in different frequency
> segments? Which values I should tune? Any hint, please.
>
> AK
>
>
Hi Arthur,

My first patch extended the frequency segment to above 388MHz so the 386MHz
is in the same segment.
It is of course possible that 386MHz does not work but this is difficult to
test for me.

Question: which provider do you have?

Assuming you use "zap" to tune, you have a configuration file like this
(valid for some Dutch UPC regio's):
Ned1:386750000:INVERSION_AUTO:6900000:FEC_AUTO:QAM_64:2001:2012:12141
Ned2:386750000:INVERSION_AUTO:6900000:FEC_AUTO:QAM_64:2301:2312:12142
Ned3:386750000:INVERSION_AUTO:6900000:FEC_AUTO:QAM_64:2601:2612:12143

Hints:
- use the exact frequency. if it is 386.75 use that and not 386
- fill in the correct symbol rate: 6900000 for UPC, 6875000 for Ziggo
  if this number is wrong you will not receive anything
- fill in the modulation exact, for both UPC and Ziggo this is QAM_64

Groetjes,
Klaas

[-- Attachment #1.2: Type: text/html, Size: 1878 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz

[Arthur Konovalov]

klaas de waal wrote:
> Question: which provider do you have?
I have local cable provider Starman.

> 
> Assuming you use "zap" to tune, you have a configuration file like this 
> (valid for some Dutch UPC regio's):
> Ned1:386750000:INVERSION_AUTO:6900000:FEC_AUTO:QAM_64:2001:2012:12141
> Ned2:386750000:INVERSION_AUTO:6900000:FEC_AUTO:QAM_64:2301:2312:12142
> Ned3:386750000:INVERSION_AUTO:6900000:FEC_AUTO:QAM_64:2601:2612:12143

Sample of my channels.conf:
TV3:386000000:INVERSION_AUTO:6875000:FEC_NONE:QAM_64:703:803:1003
ETV:386000000:INVERSION_AUTO:6875000:FEC_NONE:QAM_64:704:804:1001
Kanal11:386000000:INVERSION_AUTO:6875000:FEC_NONE:QAM_64:58:769:1006

I have 2 dvb-c cards KNC1 and Technotrend C-1501. KNC1 works flawlessly on all 
frequency's  with same channels.conf

It strange that at some time czap has lock, but picture missing.

C-1501:
~/szap# czap -a3 -c /root/szap/Starman TV3
using '/dev/dvb/adapter3/frontend0' and '/dev/dvb/adapter3/demux0'
reading channels from file '/root/szap/Starman'
   1 TV3:386000000:INVERSION_AUTO:6875000:FEC_AUTO:QAM_64:703:803:1003
   1 TV3: f 386000000, s 6875000, i 2, fec 9, qam 3, v 0x2bf, a 0x323
status 00 | signal 8f8f | snr b8b8 | ber 000fffff | unc 00000027 |
status 00 | signal 8f8f | snr b6b6 | ber 000fffff | unc 00000027 |
status 00 | signal 8f8f | snr b5b5 | ber 000fffff | unc 00000028 |
status 00 | signal 8f8f | snr b7b7 | ber 000fffff | unc 00000027 |
status 00 | signal 8f8f | snr b8b8 | ber 000fffff | unc 00000027 |
status 00 | signal 8f8f | snr b6b6 | ber 000fffff | unc 00000027 |
status 1f | signal e7e7 | snr e4e4 | ber 000fffff | unc 0000022e | FE_HAS_LOCK
status 1f | signal e7e7 | snr ecec | ber 0000000c | unc 00000000 | FE_HAS_LOCK
status 1f | signal e7e7 | snr eaea | ber 00000009 | unc 000009f3 | FE_HAS_LOCK
status 1f | signal e7e7 | snr eded | ber 00000009 | unc 00000000 | FE_HAS_LOCK
status 1f | signal e7e7 | snr f2f2 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal e7e7 | snr eded | ber 00000000 | unc 00000000 | FE_HAS_LOCK

KNC1:
~/szap# czap -a2 -c /root/szap/Starman TV3
using '/dev/dvb/adapter2/frontend0' and '/dev/dvb/adapter2/demux0'
reading channels from file '/root/szap/Starman'
   1 TV3:386000000:INVERSION_AUTO:6875000:FEC_AUTO:QAM_64:703:803:1003
   1 TV3: f 386000000, s 6875000, i 2, fec 9, qam 3, v 0x2bf, a 0x323
status 1f | signal 7d7d | snr f6f6 | ber 00000000 | unc 0000003b | FE_HAS_LOCK
status 1f | signal 7d7d | snr f6f6 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 7d7d | snr f6f6 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 7d7d | snr f5f5 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 7d7d | snr f6f6 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 7d7d | snr f6f6 | ber 00000000 | unc 00000000 | FE_HAS_LOCK



Thank You for response.

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz

[Arthur Konovalov]

Hi!

Your patch works at 386MHz too!

Problem was in my dvb drivers startup script: tda827x module left unloaded :(
My bad and sorry about false alarm.

Regards,
AK

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz

[erik]

klaas de waal <klaas.de.waal <at> gmail.com> writes:
> 
> On Fri, Oct 10, 2008 at 2:36 AM, hermann pitton <hermann-pitton <at> arcor.de>
wrote:
> Hi,
> Am Donnerstag, den 09.10.2008, 22:15 +0200 schrieb klaas de waal:
>  The table starts a new segment at 390MHz,
> > it then starts to use VCO2 instead of VCO1.
> > I have now (hack, hack) changed the segment start from 390 to 395MHz
> > so that the 388MHz is still tuned with VCO1, and this works OK!!
> > Like this:
> >
> > static const struct tda827xa_data tda827xa_dvbt[] = {
> >     { .lomax =  56875000, .svco = 3, .spd = 4, .scr = 0, .sbs =
> > 0, .gc3 = 1},
> > #else
> >     { .lomax = 395000000, .svco = 2, .spd = 1, .scr = 0, .sbs =
> > 3, .gc3 = 1},
> > #endif
> >     { .lomax = 455000000, .svco = 3, .spd = 1, .scr = 0, .sbs =
> > 3, .gc3 = 1},
> > etc etc
> >

Hi Klaas/Hermann

Your fix works perfectly for me as well. Prior I could not get the channels in
the 386750000 freq. With Fix appied my Ziggo locking issues disappeared.

Is there any chance to get it into the official version?

Erik



_______________________________________________
linux-dvb users mailing list
For V4L/DVB development, please use instead linux-media@vger.kernel.org
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz

[hermann pitton]

Hi,

Am Mittwoch, den 25.02.2009, 20:42 +0000 schrieb erik:
> klaas de waal <klaas.de.waal <at> gmail.com> writes:
> > 
> > On Fri, Oct 10, 2008 at 2:36 AM, hermann pitton <hermann-pitton <at> arcor.de>
> wrote:
> > Hi,
> > Am Donnerstag, den 09.10.2008, 22:15 +0200 schrieb klaas de waal:
> >  The table starts a new segment at 390MHz,
> > > it then starts to use VCO2 instead of VCO1.
> > > I have now (hack, hack) changed the segment start from 390 to 395MHz
> > > so that the 388MHz is still tuned with VCO1, and this works OK!!
> > > Like this:
> > >
> > > static const struct tda827xa_data tda827xa_dvbt[] = {
> > >     { .lomax =  56875000, .svco = 3, .spd = 4, .scr = 0, .sbs =
> > > 0, .gc3 = 1},
> > > #else
> > >     { .lomax = 395000000, .svco = 2, .spd = 1, .scr = 0, .sbs =
> > > 3, .gc3 = 1},
> > > #endif
> > >     { .lomax = 455000000, .svco = 3, .spd = 1, .scr = 0, .sbs =
> > > 3, .gc3 = 1},
> > > etc etc
> > >
> 
> Hi Klaas/Hermann
> 
> Your fix works perfectly for me as well. Prior I could not get the channels in
> the 386750000 freq. With Fix appied my Ziggo locking issues disappeared.
> 
> Is there any chance to get it into the official version?
> 
> Erik
> 

yes, there should be one for the later patch with the separate tuning
table for tda8274a DVB-C I think.

Patch for a review must be against recent mercurial v4l-dvb, needs to be
in form of a unified diff, with mercurial installed and v4l-dvb cloned
"hg diff > tda827x_dvb-c_improved-tuning-table.patch" something does
create it most simple.

Needs to go to linux-media@vger.kernel.org , please try README.patches
in the v4l-dvb Documentation. Needs a Signed-off-by line.

Also testers like you should provide a Tested-by line to promote it.

Don't know if somebody has the tuning table for that specific tuner,
tda8274a IIRC, or if this will only rely on the reports of the testers.

Some equivalent of lna config = 0 needs to be introduced too to keep it
quiet was said as well.

Cheers,
Hermann

Re: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz

[klaas de waal]

[-- Attachment #1.1: Type: text/plain, Size: 3703 bytes --]

On Fri, Feb 27, 2009 at 6:35 AM, hermann pitton <hermann-pitton@arcor.de>wrote:

> Hi,
>
> Am Mittwoch, den 25.02.2009, 20:42 +0000 schrieb erik:
> > klaas de waal <klaas.de.waal <at> gmail.com> writes:
> > >
> > > On Fri, Oct 10, 2008 at 2:36 AM, hermann pitton <hermann-pitton <at>
> arcor.de>
> > wrote:
> > > Hi,
> > > Am Donnerstag, den 09.10.2008, 22:15 +0200 schrieb klaas de waal:
> > >  The table starts a new segment at 390MHz,
> > > > it then starts to use VCO2 instead of VCO1.
> > > > I have now (hack, hack) changed the segment start from 390 to 395MHz
> > > > so that the 388MHz is still tuned with VCO1, and this works OK!!
> > > > Like this:
> > > >
> > > > static const struct tda827xa_data tda827xa_dvbt[] = {
> > > >     { .lomax =  56875000, .svco = 3, .spd = 4, .scr = 0, .sbs =
> > > > 0, .gc3 = 1},
> > > > #else
> > > >     { .lomax = 395000000, .svco = 2, .spd = 1, .scr = 0, .sbs =
> > > > 3, .gc3 = 1},
> > > > #endif
> > > >     { .lomax = 455000000, .svco = 3, .spd = 1, .scr = 0, .sbs =
> > > > 3, .gc3 = 1},
> > > > etc etc
> > > >
> >
> > Hi Klaas/Hermann
> >
> > Your fix works perfectly for me as well. Prior I could not get the
> channels in
> > the 386750000 freq. With Fix appied my Ziggo locking issues disappeared.
> >
> > Is there any chance to get it into the official version?
> >
> > Erik
> >
>
> yes, there should be one for the later patch with the separate tuning
> table for tda8274a DVB-C I think.
>
> Patch for a review must be against recent mercurial v4l-dvb, needs to be
> in form of a unified diff, with mercurial installed and v4l-dvb cloned
> "hg diff > tda827x_dvb-c_improved-tuning-table.patch" something does
> create it most simple.
>
> Needs to go to linux-media@vger.kernel.org , please try README.patches
> in the v4l-dvb Documentation. Needs a Signed-off-by line.
>
> Also testers like you should provide a Tested-by line to promote it.
>
> Don't know if somebody has the tuning table for that specific tuner,
> tda8274a IIRC, or if this will only rely on the reports of the testers.
>
> Some equivalent of lna config = 0 needs to be introduced too to keep it
> quiet was said as well.
>
> Cheers,
> Hermann
>
>
>
> Hi Hermann,

Thanks for your "howto" on making a proper patch.
After a "make commit" in my local v4l-dvb tree, and filling in the template
I got the following output. I confess I do not know if this has now ended up
somewhere in linuxtv.org or that it is just local.
However, here it is:

changeset:   11143:f10e05176a88
tag:         tip
user:        Klaas de Waal <klaas.de.waal@gmail.com>
date:        Tue Mar 24 22:59:44 2009 +0100
files:       linux/drivers/media/common/tuners/tda827x.c
linux/drivers/media/dvb/ttpci/budget-ci.c
description:
Separate tuning table for DVB-C solves tuning problem at 388MHz.

From: Klaas de Waal <klaas.de.waal@gmail.com>

TechnoTrend C-1501 DVB-C card does not lock on 388MHz.
I assume that existing frequency table is valid for DVB-T. This is suggested
by the name of the table: tda827xa_dvbt.
Added a table for DVB-C with the name tda827xa_dvbc.
Added runtime selection of the DVB-C table when the tuner is type FE_QAM.
This should leave the behaviour of this driver with with DVB_T tuners
unchanged.
This modification is in file tda827x.c

The tda827x.c gives the following warning message when debug=1 :
tda827x: tda827x_config not defined, cannot set LNA gain!
Added a tda827x_config struct in budget-ci.c to get rid of this message.

Priority: normal

Signed-off-by: Klaas de Waal <klaas.de.waal@gmail.com>


I have attached the result of "hg diff > tda827x_dvb-c_tuning_table.patch.
Patch is with the "hg clone" done 23 march.
Tested with Linux kernel 2.6.28.9.

Cheers,
Klaas.

[-- Attachment #1.2: Type: text/html, Size: 5002 bytes --]

[-- Attachment #2: tda827x_dvb-c_tuning_table.patch --]
[-- Type: text/x-patch, Size: 5793 bytes --]

diff -r e7d22285a9eb linux/drivers/media/common/tuners/tda827x.c
--- a/linux/drivers/media/common/tuners/tda827x.c	Sun Mar 22 22:42:26 2009 -0400
+++ b/linux/drivers/media/common/tuners/tda827x.c	Tue Mar 24 22:44:16 2009 +0100
@@ -352,7 +352,7 @@
 	u8  gc3;
 };
 
-static const struct tda827xa_data tda827xa_dvbt[] = {
+static struct tda827xa_data tda827xa_dvbt[] = {
 	{ .lomax =  56875000, .svco = 3, .spd = 4, .scr = 0, .sbs = 0, .gc3 = 1},
 	{ .lomax =  67250000, .svco = 0, .spd = 3, .scr = 0, .sbs = 0, .gc3 = 1},
 	{ .lomax =  81250000, .svco = 1, .spd = 3, .scr = 0, .sbs = 0, .gc3 = 1},
@@ -382,6 +382,36 @@
 	{ .lomax =         0, .svco = 0, .spd = 0, .scr = 0, .sbs = 0, .gc3 = 0}
 };
 
+static struct tda827xa_data tda827xa_dvbc[] = {
+	{ .lomax =  50125000, .svco = 2, .spd = 4, .scr = 2, .sbs = 0, .gc3 = 3},
+	{ .lomax =  58500000, .svco = 3, .spd = 4, .scr = 2, .sbs = 0, .gc3 = 3},
+	{ .lomax =  69250000, .svco = 0, .spd = 3, .scr = 2, .sbs = 0, .gc3 = 3},
+	{ .lomax =  83625000, .svco = 1, .spd = 3, .scr = 2, .sbs = 0, .gc3 = 3},
+	{ .lomax =  97500000, .svco = 2, .spd = 3, .scr = 2, .sbs = 0, .gc3 = 3},
+	{ .lomax = 100250000, .svco = 2, .spd = 3, .scr = 2, .sbs = 1, .gc3 = 1},
+	{ .lomax = 117000000, .svco = 3, .spd = 3, .scr = 2, .sbs = 1, .gc3 = 1},
+	{ .lomax = 138500000, .svco = 0, .spd = 2, .scr = 2, .sbs = 1, .gc3 = 1},
+	{ .lomax = 167250000, .svco = 1, .spd = 2, .scr = 2, .sbs = 1, .gc3 = 1},
+	{ .lomax = 187000000, .svco = 2, .spd = 2, .scr = 2, .sbs = 1, .gc3 = 1},
+	{ .lomax = 200500000, .svco = 2, .spd = 2, .scr = 2, .sbs = 2, .gc3 = 1},
+	{ .lomax = 234000000, .svco = 3, .spd = 2, .scr = 2, .sbs = 2, .gc3 = 3},
+	{ .lomax = 277000000, .svco = 0, .spd = 1, .scr = 2, .sbs = 2, .gc3 = 3},
+	{ .lomax = 325000000, .svco = 1, .spd = 1, .scr = 2, .sbs = 2, .gc3 = 1},
+	{ .lomax = 334500000, .svco = 1, .spd = 1, .scr = 2, .sbs = 3, .gc3 = 3},
+	{ .lomax = 401000000, .svco = 2, .spd = 1, .scr = 2, .sbs = 3, .gc3 = 3},
+	{ .lomax = 468000000, .svco = 3, .spd = 1, .scr = 2, .sbs = 3, .gc3 = 1},
+	{ .lomax = 535000000, .svco = 0, .spd = 0, .scr = 1, .sbs = 3, .gc3 = 1},
+	{ .lomax = 554000000, .svco = 0, .spd = 0, .scr = 2, .sbs = 3, .gc3 = 1},
+	{ .lomax = 638000000, .svco = 1, .spd = 0, .scr = 1, .sbs = 4, .gc3 = 1},
+	{ .lomax = 669000000, .svco = 1, .spd = 0, .scr = 2, .sbs = 4, .gc3 = 1},
+	{ .lomax = 720000000, .svco = 2, .spd = 0, .scr = 1, .sbs = 4, .gc3 = 1},
+	{ .lomax = 802000000, .svco = 2, .spd = 0, .scr = 2, .sbs = 4, .gc3 = 1},
+	{ .lomax = 835000000, .svco = 3, .spd = 0, .scr = 1, .sbs = 4, .gc3 = 1},
+	{ .lomax = 885000000, .svco = 3, .spd = 0, .scr = 1, .sbs = 4, .gc3 = 1},
+	{ .lomax = 911000000, .svco = 3, .spd = 0, .scr = 2, .sbs = 4, .gc3 = 1},
+	{ .lomax =         0, .svco = 0, .spd = 0, .scr = 0, .sbs = 0, .gc3 = 0}
+};
+
 static struct tda827xa_data tda827xa_analog[] = {
 	{ .lomax =  56875000, .svco = 3, .spd = 4, .scr = 0, .sbs = 0, .gc3 = 3},
 	{ .lomax =  67250000, .svco = 0, .spd = 3, .scr = 0, .sbs = 0, .gc3 = 3},
@@ -485,6 +515,7 @@
 			       struct dvb_frontend_parameters *params)
 {
 	struct tda827x_priv *priv = fe->tuner_priv;
+	struct tda827xa_data *frequency_map = tda827xa_dvbt;
 	u8 buf[11];
 
 	struct i2c_msg msg = { .addr = priv->i2c_addr, .flags = 0,
@@ -511,22 +542,27 @@
 	}
 	tuner_freq = params->frequency + if_freq;
 
+	if (fe->ops.info.type == FE_QAM) {
+		dprintk("%s select tda827xa_dvbc\n", __func__);
+		frequency_map = tda827xa_dvbc;
+	}
+
 	i = 0;
-	while (tda827xa_dvbt[i].lomax < tuner_freq) {
-		if(tda827xa_dvbt[i + 1].lomax == 0)
+	while (frequency_map[i].lomax < tuner_freq) {
+		if (frequency_map[i + 1].lomax == 0)
 			break;
 		i++;
 	}
 
-	N = ((tuner_freq + 31250) / 62500) << tda827xa_dvbt[i].spd;
+	N = ((tuner_freq + 31250) / 62500) << frequency_map[i].spd;
 	buf[0] = 0;            // subaddress
 	buf[1] = N >> 8;
 	buf[2] = N & 0xff;
 	buf[3] = 0;
 	buf[4] = 0x16;
-	buf[5] = (tda827xa_dvbt[i].spd << 5) + (tda827xa_dvbt[i].svco << 3) +
-			tda827xa_dvbt[i].sbs;
-	buf[6] = 0x4b + (tda827xa_dvbt[i].gc3 << 4);
+	buf[5] = (frequency_map[i].spd << 5) + (frequency_map[i].svco << 3) +
+			frequency_map[i].sbs;
+	buf[6] = 0x4b + (frequency_map[i].gc3 << 4);
 	buf[7] = 0x1c;
 	buf[8] = 0x06;
 	buf[9] = 0x24;
@@ -585,7 +621,7 @@
 
 	/* correct CP value */
 	buf[0] = 0x30;
-	buf[1] = 0x10 + tda827xa_dvbt[i].scr;
+	buf[1] = 0x10 + frequency_map[i].scr;
 	rc = tuner_transfer(fe, &msg, 1);
 	if (rc < 0)
 		goto err;
@@ -600,7 +636,7 @@
 	msleep(3);
 	/* freeze AGC1 */
 	buf[0] = 0x50;
-	buf[1] = 0x4f + (tda827xa_dvbt[i].gc3 << 4);
+	buf[1] = 0x4f + (frequency_map[i].gc3 << 4);
 	rc = tuner_transfer(fe, &msg, 1);
 	if (rc < 0)
 		goto err;
diff -r e7d22285a9eb linux/drivers/media/dvb/ttpci/budget-ci.c
--- a/linux/drivers/media/dvb/ttpci/budget-ci.c	Sun Mar 22 22:42:26 2009 -0400
+++ b/linux/drivers/media/dvb/ttpci/budget-ci.c	Tue Mar 24 22:44:16 2009 +0100
@@ -1084,6 +1084,10 @@
 	.deltaf = 0xa511,
 };
 
+static struct tda827x_config tda827x_config = {
+	.config = 0,
+};
+
 /* TT S2-3200 DVB-S (STB0899) Inittab */
 static const struct stb0899_s1_reg tt3200_stb0899_s1_init_1[] = {
 
@@ -1422,7 +1426,7 @@
 	case 0x101a: /* TT Budget-C-1501 (philips tda10023/philips tda8274A) */
 		budget_ci->budget.dvb_frontend = dvb_attach(tda10023_attach, &tda10023_config, &budget_ci->budget.i2c_adap, 0x48);
 		if (budget_ci->budget.dvb_frontend) {
-			if (dvb_attach(tda827x_attach, budget_ci->budget.dvb_frontend, 0x61, &budget_ci->budget.i2c_adap, NULL) == NULL) {
+			if (dvb_attach(tda827x_attach, budget_ci->budget.dvb_frontend, 0x61, &budget_ci->budget.i2c_adap, &tda827x_config) == NULL) {
 				printk(KERN_ERR "%s: No tda827x found!\n", __func__);
 				dvb_frontend_detach(budget_ci->budget.dvb_frontend);
 				budget_ci->budget.dvb_frontend = NULL;

[-- Attachment #3: Type: text/plain, Size: 228 bytes --]

_______________________________________________
linux-dvb users mailing list
For V4L/DVB development, please use instead linux-media@vger.kernel.org
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz

[Christian Lyra]

Hi
>> > > Hi,
>> > > Am Donnerstag, den 09.10.2008, 22:15 +0200 schrieb klaas de waal:
>> > >  The table starts a new segment at 390MHz,
>> > > > it then starts to use VCO2 instead of VCO1.
>> > > > I have now (hack, hack) changed the segment start from 390 to 395MHz
>> > > > so that the 388MHz is still tuned with VCO1, and this works OK!!
>
> TechnoTrend C-1501 DVB-C card does not lock on 388MHz.
> I assume that existing frequency table is valid for DVB-T. This is suggested
> by the name of the table: tda827xa_dvbt.
> Added a table for DVB-C with the name tda827xa_dvbc.
> Added runtime selection of the DVB-C table when the tuner is type FE_QAM.
> This should leave the behaviour of this driver with with DVB_T tuners
> unchanged.
> This modification is in file tda827x.c

I imagine if there´s something similar to my card, as it doesnt seem
to use the same tuner. dmesg only says this:

[    3.611107] Linux video capture interface: v2.00
[    3.621431] saa7146: register extension 'budget_av'.
[    3.621513] budget_av 0000:00:00.0: enabling device (0000 -> 0002)
[    3.621757] saa7146: found saa7146 @ mem ffffc20000024000 (revision
1, irq 16) (0x1894,0x0022).
[    3.621768] saa7146 (0): dma buffer size 192512
[    3.621773] DVB: registering new adapter (KNC1 DVB-C MK3)
[    3.655279] adapter failed MAC signature check
[    3.655292] 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
[    3.858310] budget_av: saa7113_init(): saa7113 not found on KNC card
[    3.918489] KNC1-0: MAC addr = 00:09:d6:6d:9f:db
[    4.112763] DVB: registering adapter 0 frontend 0 (Philips TDA10023 DVB-C)...
[    4.112896] budget-av: ci interface initialised.

What tunner this card use?

-- 
Christian Lyra
PoP-PR/RNP

_______________________________________________
linux-dvb users mailing list
For V4L/DVB development, please use instead linux-media@vger.kernel.org
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz

[klaas de waal]

[-- Attachment #1: Type: text/plain, Size: 1594 bytes --]

(2nd try, this should be now  in "plain text" instead of HTML)

Hi Hermann,

Thanks for your "howto" on making a proper patch.
After a "make commit" in my local v4l-dvb tree, and filling in the
template I got the following output.
I confess I do not know if this has now ended up somewhere in
linuxtv.org or that it is just local.
However, here it is:

changeset:   11143:f10e05176a88
tag:         tip
user:        Klaas de Waal <klaas.de.waal@gmail.com>
date:        Tue Mar 24 22:59:44 2009 +0100
files:       linux/drivers/media/common/tuners/tda827x.c
linux/drivers/media/dvb/ttpci/budget-ci.c
description:
Separate tuning table for DVB-C solves tuning problem at 388MHz.

From: Klaas de Waal <klaas.de.waal@gmail.com>

TechnoTrend C-1501 DVB-C card does not lock on 388MHz.
I assume that existing frequency table is valid for DVB-T. This is suggested
by the name of the table: tda827xa_dvbt.
Added a table for DVB-C with the name tda827xa_dvbc.
Added runtime selection of the DVB-C table when the tuner is type FE_QAM.
This should leave the behaviour of this driver with with DVB_T tuners unchanged.
This modification is in file tda827x.c

The tda827x.c gives the following warning message when debug=1 :

tda827x: tda827x_config not defined, cannot set LNA gain!

Solved this by adding a tda827x_config struct in budget-ci.c.

Priority: normal

Signed-off-by: Klaas de Waal <klaas.de.waal@gmail.com>


I have attached the result of "hg diff > tda827x_dvb-c_tuning_table.patch.

Patch is based on the "hg clone" done 23 march.
Tested again, now with Linux kernel 2.6.28.9.

Cheers,
Klaas.

[-- Attachment #2: tda827x_dvb-c_tuning_table.patch --]
[-- Type: text/x-patch, Size: 5793 bytes --]

diff -r e7d22285a9eb linux/drivers/media/common/tuners/tda827x.c
--- a/linux/drivers/media/common/tuners/tda827x.c	Sun Mar 22 22:42:26 2009 -0400
+++ b/linux/drivers/media/common/tuners/tda827x.c	Tue Mar 24 22:44:16 2009 +0100
@@ -352,7 +352,7 @@
 	u8  gc3;
 };
 
-static const struct tda827xa_data tda827xa_dvbt[] = {
+static struct tda827xa_data tda827xa_dvbt[] = {
 	{ .lomax =  56875000, .svco = 3, .spd = 4, .scr = 0, .sbs = 0, .gc3 = 1},
 	{ .lomax =  67250000, .svco = 0, .spd = 3, .scr = 0, .sbs = 0, .gc3 = 1},
 	{ .lomax =  81250000, .svco = 1, .spd = 3, .scr = 0, .sbs = 0, .gc3 = 1},
@@ -382,6 +382,36 @@
 	{ .lomax =         0, .svco = 0, .spd = 0, .scr = 0, .sbs = 0, .gc3 = 0}
 };
 
+static struct tda827xa_data tda827xa_dvbc[] = {
+	{ .lomax =  50125000, .svco = 2, .spd = 4, .scr = 2, .sbs = 0, .gc3 = 3},
+	{ .lomax =  58500000, .svco = 3, .spd = 4, .scr = 2, .sbs = 0, .gc3 = 3},
+	{ .lomax =  69250000, .svco = 0, .spd = 3, .scr = 2, .sbs = 0, .gc3 = 3},
+	{ .lomax =  83625000, .svco = 1, .spd = 3, .scr = 2, .sbs = 0, .gc3 = 3},
+	{ .lomax =  97500000, .svco = 2, .spd = 3, .scr = 2, .sbs = 0, .gc3 = 3},
+	{ .lomax = 100250000, .svco = 2, .spd = 3, .scr = 2, .sbs = 1, .gc3 = 1},
+	{ .lomax = 117000000, .svco = 3, .spd = 3, .scr = 2, .sbs = 1, .gc3 = 1},
+	{ .lomax = 138500000, .svco = 0, .spd = 2, .scr = 2, .sbs = 1, .gc3 = 1},
+	{ .lomax = 167250000, .svco = 1, .spd = 2, .scr = 2, .sbs = 1, .gc3 = 1},
+	{ .lomax = 187000000, .svco = 2, .spd = 2, .scr = 2, .sbs = 1, .gc3 = 1},
+	{ .lomax = 200500000, .svco = 2, .spd = 2, .scr = 2, .sbs = 2, .gc3 = 1},
+	{ .lomax = 234000000, .svco = 3, .spd = 2, .scr = 2, .sbs = 2, .gc3 = 3},
+	{ .lomax = 277000000, .svco = 0, .spd = 1, .scr = 2, .sbs = 2, .gc3 = 3},
+	{ .lomax = 325000000, .svco = 1, .spd = 1, .scr = 2, .sbs = 2, .gc3 = 1},
+	{ .lomax = 334500000, .svco = 1, .spd = 1, .scr = 2, .sbs = 3, .gc3 = 3},
+	{ .lomax = 401000000, .svco = 2, .spd = 1, .scr = 2, .sbs = 3, .gc3 = 3},
+	{ .lomax = 468000000, .svco = 3, .spd = 1, .scr = 2, .sbs = 3, .gc3 = 1},
+	{ .lomax = 535000000, .svco = 0, .spd = 0, .scr = 1, .sbs = 3, .gc3 = 1},
+	{ .lomax = 554000000, .svco = 0, .spd = 0, .scr = 2, .sbs = 3, .gc3 = 1},
+	{ .lomax = 638000000, .svco = 1, .spd = 0, .scr = 1, .sbs = 4, .gc3 = 1},
+	{ .lomax = 669000000, .svco = 1, .spd = 0, .scr = 2, .sbs = 4, .gc3 = 1},
+	{ .lomax = 720000000, .svco = 2, .spd = 0, .scr = 1, .sbs = 4, .gc3 = 1},
+	{ .lomax = 802000000, .svco = 2, .spd = 0, .scr = 2, .sbs = 4, .gc3 = 1},
+	{ .lomax = 835000000, .svco = 3, .spd = 0, .scr = 1, .sbs = 4, .gc3 = 1},
+	{ .lomax = 885000000, .svco = 3, .spd = 0, .scr = 1, .sbs = 4, .gc3 = 1},
+	{ .lomax = 911000000, .svco = 3, .spd = 0, .scr = 2, .sbs = 4, .gc3 = 1},
+	{ .lomax =         0, .svco = 0, .spd = 0, .scr = 0, .sbs = 0, .gc3 = 0}
+};
+
 static struct tda827xa_data tda827xa_analog[] = {
 	{ .lomax =  56875000, .svco = 3, .spd = 4, .scr = 0, .sbs = 0, .gc3 = 3},
 	{ .lomax =  67250000, .svco = 0, .spd = 3, .scr = 0, .sbs = 0, .gc3 = 3},
@@ -485,6 +515,7 @@
 			       struct dvb_frontend_parameters *params)
 {
 	struct tda827x_priv *priv = fe->tuner_priv;
+	struct tda827xa_data *frequency_map = tda827xa_dvbt;
 	u8 buf[11];
 
 	struct i2c_msg msg = { .addr = priv->i2c_addr, .flags = 0,
@@ -511,22 +542,27 @@
 	}
 	tuner_freq = params->frequency + if_freq;
 
+	if (fe->ops.info.type == FE_QAM) {
+		dprintk("%s select tda827xa_dvbc\n", __func__);
+		frequency_map = tda827xa_dvbc;
+	}
+
 	i = 0;
-	while (tda827xa_dvbt[i].lomax < tuner_freq) {
-		if(tda827xa_dvbt[i + 1].lomax == 0)
+	while (frequency_map[i].lomax < tuner_freq) {
+		if (frequency_map[i + 1].lomax == 0)
 			break;
 		i++;
 	}
 
-	N = ((tuner_freq + 31250) / 62500) << tda827xa_dvbt[i].spd;
+	N = ((tuner_freq + 31250) / 62500) << frequency_map[i].spd;
 	buf[0] = 0;            // subaddress
 	buf[1] = N >> 8;
 	buf[2] = N & 0xff;
 	buf[3] = 0;
 	buf[4] = 0x16;
-	buf[5] = (tda827xa_dvbt[i].spd << 5) + (tda827xa_dvbt[i].svco << 3) +
-			tda827xa_dvbt[i].sbs;
-	buf[6] = 0x4b + (tda827xa_dvbt[i].gc3 << 4);
+	buf[5] = (frequency_map[i].spd << 5) + (frequency_map[i].svco << 3) +
+			frequency_map[i].sbs;
+	buf[6] = 0x4b + (frequency_map[i].gc3 << 4);
 	buf[7] = 0x1c;
 	buf[8] = 0x06;
 	buf[9] = 0x24;
@@ -585,7 +621,7 @@
 
 	/* correct CP value */
 	buf[0] = 0x30;
-	buf[1] = 0x10 + tda827xa_dvbt[i].scr;
+	buf[1] = 0x10 + frequency_map[i].scr;
 	rc = tuner_transfer(fe, &msg, 1);
 	if (rc < 0)
 		goto err;
@@ -600,7 +636,7 @@
 	msleep(3);
 	/* freeze AGC1 */
 	buf[0] = 0x50;
-	buf[1] = 0x4f + (tda827xa_dvbt[i].gc3 << 4);
+	buf[1] = 0x4f + (frequency_map[i].gc3 << 4);
 	rc = tuner_transfer(fe, &msg, 1);
 	if (rc < 0)
 		goto err;
diff -r e7d22285a9eb linux/drivers/media/dvb/ttpci/budget-ci.c
--- a/linux/drivers/media/dvb/ttpci/budget-ci.c	Sun Mar 22 22:42:26 2009 -0400
+++ b/linux/drivers/media/dvb/ttpci/budget-ci.c	Tue Mar 24 22:44:16 2009 +0100
@@ -1084,6 +1084,10 @@
 	.deltaf = 0xa511,
 };
 
+static struct tda827x_config tda827x_config = {
+	.config = 0,
+};
+
 /* TT S2-3200 DVB-S (STB0899) Inittab */
 static const struct stb0899_s1_reg tt3200_stb0899_s1_init_1[] = {
 
@@ -1422,7 +1426,7 @@
 	case 0x101a: /* TT Budget-C-1501 (philips tda10023/philips tda8274A) */
 		budget_ci->budget.dvb_frontend = dvb_attach(tda10023_attach, &tda10023_config, &budget_ci->budget.i2c_adap, 0x48);
 		if (budget_ci->budget.dvb_frontend) {
-			if (dvb_attach(tda827x_attach, budget_ci->budget.dvb_frontend, 0x61, &budget_ci->budget.i2c_adap, NULL) == NULL) {
+			if (dvb_attach(tda827x_attach, budget_ci->budget.dvb_frontend, 0x61, &budget_ci->budget.i2c_adap, &tda827x_config) == NULL) {
 				printk(KERN_ERR "%s: No tda827x found!\n", __func__);
 				dvb_frontend_detach(budget_ci->budget.dvb_frontend);
 				budget_ci->budget.dvb_frontend = NULL;

Re: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz

[klaas de waal]

On Wed, Mar 25, 2009 at 2:38 AM, Christian Lyra <lyra@pop-pr.rnp.br> wrote:
> Hi
>>> > > Hi,
>>> > > Am Donnerstag, den 09.10.2008, 22:15 +0200 schrieb klaas de waal:
>>> > >  The table starts a new segment at 390MHz,
>>> > > > it then starts to use VCO2 instead of VCO1.
>>> > > > I have now (hack, hack) changed the segment start from 390 to 395MHz
>>> > > > so that the 388MHz is still tuned with VCO1, and this works OK!!
>>
>> TechnoTrend C-1501 DVB-C card does not lock on 388MHz.
>> I assume that existing frequency table is valid for DVB-T. This is suggested
>> by the name of the table: tda827xa_dvbt.
>> Added a table for DVB-C with the name tda827xa_dvbc.
>> Added runtime selection of the DVB-C table when the tuner is type FE_QAM.
>> This should leave the behaviour of this driver with with DVB_T tuners
>> unchanged.
>> This modification is in file tda827x.c
>
> I imagine if there´s something similar to my card, as it doesnt seem
> to use the same tuner. dmesg only says this:
>
> [    3.611107] Linux video capture interface: v2.00
> [    3.621431] saa7146: register extension 'budget_av'.
> [    3.621513] budget_av 0000:00:00.0: enabling device (0000 -> 0002)
> [    3.621757] saa7146: found saa7146 @ mem ffffc20000024000 (revision
> 1, irq 16) (0x1894,0x0022).
> [    3.621768] saa7146 (0): dma buffer size 192512
> [    3.621773] DVB: registering new adapter (KNC1 DVB-C MK3)
> [    3.655279] adapter failed MAC signature check
> [    3.655292] 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
> [    3.858310] budget_av: saa7113_init(): saa7113 not found on KNC card
> [    3.918489] KNC1-0: MAC addr = 00:09:d6:6d:9f:db
> [    4.112763] DVB: registering adapter 0 frontend 0 (Philips TDA10023 DVB-C)...
> [    4.112896] budget-av: ci interface initialised.
>
> What tunner this card use?
>
> --
> Christian Lyra
> PoP-PR/RNP
>
Hi Christian,

The TechnoTrend C-1501 card uses a "silicon tuner" and that is a
fairly new device of which the driver needed a bit of improvement.
The KNC1 DVB-C cards use a conventional "tin can" tuner, the CU1216.
See the http://linuxtv.org/wiki/index.php/DVB-C_PCI_Cards for details.
The SAA7113 that is mentioned in your log is a chip that digitizes
analog TV input..
The cards that are sold as "DVB-C Plus"  have an S-Video analog TV
input in addition to being a DVB-C tuner card, so I expect that the
Plus cards have a SAA7113 for this.
You have probably the standard card, without the S-Video input.
DVB-C reception should work OK, also with the standard Linux kernel driver.

Cheers,
Klaas

Re: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz

[hermann pitton]

Hi Klaas,

Am Mittwoch, den 25.03.2009, 21:53 +0100 schrieb klaas de waal:
> (2nd try, this should be now  in "plain text" instead of HTML)
> 
> Hi Hermann,
> 
> Thanks for your "howto" on making a proper patch.
> After a "make commit" in my local v4l-dvb tree, and filling in the
> template I got the following output.
> I confess I do not know if this has now ended up somewhere in
> linuxtv.org or that it is just local.
> However, here it is:

your patches are still local, but they are at least on the proper list
now. Without starting with [PATCH] in the subject Mauro's scripts to add
them to patchwork automatically likely will still not find them.

As said before, as long nobody has the documentation for that tuner and
knows better somehow, your attempt to improve it is valid in my eyes and
was usual practice in such cases previously.

It would of course be fine if Oliver and/or Michael could review it and
eventually give an ACK or NACK with some reasons.

I came to it, because you initially reported the problem erroneously on
the saa7134 driver, but I'm not sure how I can help further with it now,
except for eventually remaining checkpatch.pl stuff and such.

Cheers,
Hermann

> changeset:   11143:f10e05176a88
> tag:         tip
> user:        Klaas de Waal <klaas.de.waal@gmail.com>
> date:        Tue Mar 24 22:59:44 2009 +0100
> files:       linux/drivers/media/common/tuners/tda827x.c
> linux/drivers/media/dvb/ttpci/budget-ci.c
> description:
> Separate tuning table for DVB-C solves tuning problem at 388MHz.
> 
> From: Klaas de Waal <klaas.de.waal@gmail.com>
> 
> TechnoTrend C-1501 DVB-C card does not lock on 388MHz.
> I assume that existing frequency table is valid for DVB-T. This is suggested
> by the name of the table: tda827xa_dvbt.
> Added a table for DVB-C with the name tda827xa_dvbc.
> Added runtime selection of the DVB-C table when the tuner is type FE_QAM.
> This should leave the behaviour of this driver with with DVB_T tuners unchanged.
> This modification is in file tda827x.c
> 
> The tda827x.c gives the following warning message when debug=1 :
> 
> tda827x: tda827x_config not defined, cannot set LNA gain!
> 
> Solved this by adding a tda827x_config struct in budget-ci.c.
> 
> Priority: normal
> 
> Signed-off-by: Klaas de Waal <klaas.de.waal@gmail.com>
> 
> 
> I have attached the result of "hg diff > tda827x_dvb-c_tuning_table.patch.
> 
> Patch is based on the "hg clone" done 23 march.
> Tested again, now with Linux kernel 2.6.28.9.
> 
> Cheers,
> Klaas.

Re: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz

[Mauro Carvalho Chehab]

On Fri, 27 Mar 2009 00:51:43 +0100
hermann pitton <hermann-pitton@arcor.de> wrote:

> Hi Klaas,
> 
> Am Mittwoch, den 25.03.2009, 21:53 +0100 schrieb klaas de waal:
> > (2nd try, this should be now  in "plain text" instead of HTML)
> > 
> > Hi Hermann,
> > 
> > Thanks for your "howto" on making a proper patch.
> > After a "make commit" in my local v4l-dvb tree, and filling in the
> > template I got the following output.
> > I confess I do not know if this has now ended up somewhere in
> > linuxtv.org or that it is just local.
> > However, here it is:
> 
> your patches are still local, but they are at least on the proper list
> now. Without starting with [PATCH] in the subject Mauro's scripts to add
> them to patchwork automatically likely will still not find them.

The patchwork scripts are the ones that came with the product. They are not
developed by me ;)

Anyway, if patchwork didn't catch is because the inlined patch is broken, or it is
not inlined and were attached with a wrong mime type.


Cheers,
Mauro

Re: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz

[hermann pitton]

Am Donnerstag, den 26.03.2009, 21:09 -0300 schrieb Mauro Carvalho
Chehab:
> On Fri, 27 Mar 2009 00:51:43 +0100
> hermann pitton <hermann-pitton@arcor.de> wrote:
> 
> > Hi Klaas,
> > 
> > Am Mittwoch, den 25.03.2009, 21:53 +0100 schrieb klaas de waal:
> > > (2nd try, this should be now  in "plain text" instead of HTML)
> > > 
> > > Hi Hermann,
> > > 
> > > Thanks for your "howto" on making a proper patch.
> > > After a "make commit" in my local v4l-dvb tree, and filling in the
> > > template I got the following output.
> > > I confess I do not know if this has now ended up somewhere in
> > > linuxtv.org or that it is just local.
> > > However, here it is:
> > 
> > your patches are still local, but they are at least on the proper list
> > now. Without starting with [PATCH] in the subject Mauro's scripts to add
> > them to patchwork automatically likely will still not find them.
> 
> The patchwork scripts are the ones that came with the product. They are not
> developed by me ;)
> 
> Anyway, if patchwork didn't catch is because the inlined patch is broken, or it is
> not inlined and were attached with a wrong mime type.
> 

Oh well, I still would prefer to have comments from such closest to that
driver and related tuners, instead serving that "product".

There is more drifting around and it can be prepared to fit in to such
rules. My concern is that it will arrive there then without much
problems, but outstanding discussions are only postponed.

If I'm wrong, even better.

Cheers,
Hermann

Re: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz

[Mauro Carvalho Chehab]

On Fri, 27 Mar 2009 01:46:50 +0100
hermann pitton <hermann-pitton@arcor.de> wrote:

> 
> Am Donnerstag, den 26.03.2009, 21:09 -0300 schrieb Mauro Carvalho
> Chehab:
> > On Fri, 27 Mar 2009 00:51:43 +0100
> > hermann pitton <hermann-pitton@arcor.de> wrote:
> > 
> > > Hi Klaas,
> > > 
> > > Am Mittwoch, den 25.03.2009, 21:53 +0100 schrieb klaas de waal:
> > > > (2nd try, this should be now  in "plain text" instead of HTML)
> > > > 
> > > > Hi Hermann,
> > > > 
> > > > Thanks for your "howto" on making a proper patch.
> > > > After a "make commit" in my local v4l-dvb tree, and filling in the
> > > > template I got the following output.
> > > > I confess I do not know if this has now ended up somewhere in
> > > > linuxtv.org or that it is just local.
> > > > However, here it is:
> > > 
> > > your patches are still local, but they are at least on the proper list
> > > now. Without starting with [PATCH] in the subject Mauro's scripts to add
> > > them to patchwork automatically likely will still not find them.
> > 
> > The patchwork scripts are the ones that came with the product. They are not
> > developed by me ;)
> > 
> > Anyway, if patchwork didn't catch is because the inlined patch is broken, or it is
> > not inlined and were attached with a wrong mime type.
> > 
> 
> Oh well, I still would prefer to have comments from such closest to that
> driver and related tuners, instead serving that "product".
> 
> There is more drifting around and it can be prepared to fit in to such
> rules. My concern is that it will arrive there then without much
> problems, but outstanding discussions are only postponed.
> 
> If I'm wrong, even better.

The point is that sending a broken patch won't work, anyway, since they can't
be applied. The advantage of the tool is that it is clear to everyone that the
patch is ok (so, patchwork picked), or if it is line-wrapped or is not inlined,
creating troubles for people to review and apply.


Cheers,
Mauro

Re: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz

[hermann pitton]

Am Donnerstag, den 26.03.2009, 22:02 -0300 schrieb Mauro Carvalho
Chehab:
> On Fri, 27 Mar 2009 01:46:50 +0100
> hermann pitton <hermann-pitton@arcor.de> wrote:
> 
> > 
> > Am Donnerstag, den 26.03.2009, 21:09 -0300 schrieb Mauro Carvalho
> > Chehab:
> > > On Fri, 27 Mar 2009 00:51:43 +0100
> > > hermann pitton <hermann-pitton@arcor.de> wrote:
> > > 
> > > > Hi Klaas,
> > > > 
> > > > Am Mittwoch, den 25.03.2009, 21:53 +0100 schrieb klaas de waal:
> > > > > (2nd try, this should be now  in "plain text" instead of HTML)
> > > > > 
> > > > > Hi Hermann,
> > > > > 
> > > > > Thanks for your "howto" on making a proper patch.
> > > > > After a "make commit" in my local v4l-dvb tree, and filling in the
> > > > > template I got the following output.
> > > > > I confess I do not know if this has now ended up somewhere in
> > > > > linuxtv.org or that it is just local.
> > > > > However, here it is:
> > > > 
> > > > your patches are still local, but they are at least on the proper list
> > > > now. Without starting with [PATCH] in the subject Mauro's scripts to add
> > > > them to patchwork automatically likely will still not find them.
> > > 
> > > The patchwork scripts are the ones that came with the product. They are not
> > > developed by me ;)
> > > 
> > > Anyway, if patchwork didn't catch is because the inlined patch is broken, or it is
> > > not inlined and were attached with a wrong mime type.
> > > 
> > 
> > Oh well, I still would prefer to have comments from such closest to that
> > driver and related tuners, instead serving that "product".
> > 
> > There is more drifting around and it can be prepared to fit in to such
> > rules. My concern is that it will arrive there then without much
> > problems, but outstanding discussions are only postponed.
> > 
> > If I'm wrong, even better.
> 
> The point is that sending a broken patch won't work, anyway, since they can't
> be applied. The advantage of the tool is that it is clear to everyone that the
> patch is ok (so, patchwork picked), or if it is line-wrapped or is not inlined,
> creating troubles for people to review and apply.

Mauro, that is acceptable for me.

It loads work off from you and others and within the flood of patches we
see that is OK. To talk others to that to follow such rules is a great
annoyance and I ended up several times without further replies.

But my main concern is, if it once arrived at patchwork formally, it is
out of sight for most of us and might miss proper review, except you are
sure you can always guarantee that. I don't want to start to argue about
all what happened in the past.

So, at least, if some patch arrived there mysteriously ;), the
linux-media list should be informed that it is there now and last time
to speak off, in case anything is not fully clear, before vanishing into
some black hole until you find it in the next kernel release ...

Cheers,
Hermann

Re: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz

[Mauro Carvalho Chehab]

On Fri, 27 Mar 2009 02:39:07 +0100
hermann pitton <hermann-pitton@arcor.de> wrote:

> But my main concern is, if it once arrived at patchwork formally, it is
> out of sight for most of us and might miss proper review, except you are
> sure you can always guarantee that. I don't want to start to argue about
> all what happened in the past.
> 
> So, at least, if some patch arrived there mysteriously ;), the
> linux-media list should be informed that it is there now and last time
> to speak off, in case anything is not fully clear, before vanishing into
> some black hole until you find it in the next kernel release ...

The only way to send patches to patchwork is to submit it via linux-media list.
There's no other way. So, all patch discussions and reviews should happen at
the ML, by replying at the patch email (or by replying another reply).
Patchwork will keep track of such replies as well.

Cheers,
Mauro

Re: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz

[hermann pitton]

Hi,

Am Freitag, den 27.03.2009, 07:38 -0300 schrieb Mauro Carvalho Chehab:
> On Fri, 27 Mar 2009 02:39:07 +0100
> hermann pitton <hermann-pitton@arcor.de> wrote:
> 
> > But my main concern is, if it once arrived at patchwork formally, it is
> > out of sight for most of us and might miss proper review, except you are
> > sure you can always guarantee that. I don't want to start to argue about
> > all what happened in the past.
> > 
> > So, at least, if some patch arrived there mysteriously ;), the
> > linux-media list should be informed that it is there now and last time
> > to speak off, in case anything is not fully clear, before vanishing into
> > some black hole until you find it in the next kernel release ...
> 
> The only way to send patches to patchwork is to submit it via linux-media list.
> There's no other way. So, all patch discussions and reviews should happen at
> the ML, by replying at the patch email (or by replying another reply).
> Patchwork will keep track of such replies as well.
> 

What happened so far with this patches is quite funny,
for me some black hole seems to be involved.

Klaas did send them the first time, also directly to me, on Tue, 24 Mar
2009 23:14:11 +0100.

Now I can see you have pulled them in already on Wednesday.
http://linuxtv.org/hg/v4l-dvb/rev/5efa9fbc8a88

There is no trace anymore on patchwork visible to me.
http://patchwork.kernel.org/project/linux-media/list
So I don't know how you processed them.

Most confusing is, that Klaas obviously did not receive a mail
notification from linuxtv-commits that his patch came in.

Last message date: Fri Feb 15 19:45:02 CET 2008
Archived on: Fri Feb 15 19:45:04 CET 2008 

Is it broken or only the archive not up to date?

Why else he would have posted a second time on
Wed, 25 Mar 2009 21:53:02 +0100 not knowing anything about the status of
his patches, which made me believe I should try to help him?

The timestamp on your mercurial commit of them is
Wed Mar 25 20:53:02 2009 +0000 (2 days ago)
That is the time when his second email arrived converted to Greenwich
time? Or how could you commit within the same second that mail arrived?

This is the time the patches have on both of his original mails.
--- a/linux/drivers/media/common/tuners/tda827x.c Tue Mar 24 21:12:47 2009 +0000
--- a/linux/drivers/media/common/tuners/tda827x.c Tue Mar 24 21:12:47 2009 +0000

How can I ever know when they were really added and if they went through
patchwork :)

I was just about to suggest Klaas should try again with [PATCH] in the
subject until they are listed at patchwork.

Cheers,
Hermann

Re: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz

[hermann pitton]

[snip]
> This is the time the patches have on both of his original mails.
> --- a/linux/drivers/media/common/tuners/tda827x.c Tue Mar 24 21:12:47 2009 +0000
> --- a/linux/drivers/media/common/tuners/tda827x.c Tue Mar 24 21:12:47 2009 +0000

Hmm, how this could ever happen?

I'm not able to copy and paste this from evolution with even the
recommended preformatted option enabled. How I could ever submit any
further patches?

> How can I ever know when they were really added and if they went through
> patchwork :)

So I tried several editors and did still provide such BS.

The last time I remember to have seen such was in 2005 with SECAM L' and
it was going on over half a year.

Cheers,
Hermann

Re: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz

[Mauro Carvalho Chehab]

On Sat, 28 Mar 2009 00:23:55 +0100
hermann pitton <hermann-pitton@arcor.de> wrote:

> Hi,
> 
> Am Freitag, den 27.03.2009, 07:38 -0300 schrieb Mauro Carvalho Chehab:
> > On Fri, 27 Mar 2009 02:39:07 +0100
> > hermann pitton <hermann-pitton@arcor.de> wrote:
> > 
> > > But my main concern is, if it once arrived at patchwork formally, it is
> > > out of sight for most of us and might miss proper review, except you are
> > > sure you can always guarantee that. I don't want to start to argue about
> > > all what happened in the past.
> > > 
> > > So, at least, if some patch arrived there mysteriously ;), the
> > > linux-media list should be informed that it is there now and last time
> > > to speak off, in case anything is not fully clear, before vanishing into
> > > some black hole until you find it in the next kernel release ...
> > 
> > The only way to send patches to patchwork is to submit it via linux-media list.
> > There's no other way. So, all patch discussions and reviews should happen at
> > the ML, by replying at the patch email (or by replying another reply).
> > Patchwork will keep track of such replies as well.
> > 
> 
> What happened so far with this patches is quite funny,
> for me some black hole seems to be involved.
> 
> Klaas did send them the first time, also directly to me, on Tue, 24 Mar
> 2009 23:14:11 +0100.
> 
> Now I can see you have pulled them in already on Wednesday.
> http://linuxtv.org/hg/v4l-dvb/rev/5efa9fbc8a88
> 
> There is no trace anymore on patchwork visible to me.
> http://patchwork.kernel.org/project/linux-media/list
> So I don't know how you processed them.

The above link uses the default patchwork filtering. By default it shows only
patches where there's an action required (e. g. New or Under Review patches).

To view a full list of the patches, you need to click at filters and select any.

You'll see all patches:
	http://patchwork.kernel.org/project/linux-media/list/?state=*

In the specific case od Klaas, this is his patch:

http://patchwork.kernel.org/patch/14405/

> Most confusing is, that Klaas obviously did not receive a mail
> notification from linuxtv-commits that his patch came in.

> 
> Last message date: Fri Feb 15 19:45:02 CET 2008
> Archived on: Fri Feb 15 19:45:04 CET 2008 
> 
> Is it broken or only the archive not up to date?
> 

I've received the notification here:

From: Patch from klaas de waal  <hg-commit@linuxtv.org>
To: linuxtv-commits@linuxtv.org
Cc: , Mauro Carvalho Chehab <mchehab@redhat.com>, klaas de waal <klaas.de.waal@gmail.com>
Subject: [linuxtv-commits] [hg:v4l-dvb] tda827x: fix locking issues with DVB-C
Date: Fri, 27 Mar 2009 18:05:01 +0100
Reply-To: klaas de waal via Mercurial <klaas.de.waal@gmail.com>
Sender: linuxtv-commits-bounces@linuxtv.org

The patch number 11236 was added via Mauro Carvalho Chehab <mchehab@redhat.com>
to http://linuxtv.org/hg/v4l-dvb master development tree.

Klaas should be received this also. Maybe some anti-spam filtering on his side?

You'll probably see this also at the linuxtv-commits archives.

> Why else he would have posted a second time on
> Wed, 25 Mar 2009 21:53:02 +0100 not knowing anything about the status of
> his patches, which made me believe I should try to help him?
> 
> The timestamp on your mercurial commit of them is
> Wed Mar 25 20:53:02 2009 +0000 (2 days ago)
> That is the time when his second email arrived converted to Greenwich
> time? Or how could you commit within the same second that mail arrived?

> This is the time the patches have on both of his original mails.
> --- a/linux/drivers/media/common/tuners/tda827x.c Tue Mar 24 21:12:47 2009 +0000
> --- a/linux/drivers/media/common/tuners/tda827x.c Tue Mar 24 21:12:47 2009 +0000

The import scripts will try to preserve the original date of the sent email.

So, the date there is when the code were presented to public.

> How can I ever know when they were really added and if they went through
> patchwork :)
> 
> I was just about to suggest Klaas should try again with [PATCH] in the
> subject until they are listed at patchwork.

If the patch was received by patchwork, and "disappeared", all you need to do
is to click on filter and select a proper filter, like:

http://patchwork.kernel.org/project/linux-media/list/?submitter=klaas&state=*

This will present all patches authored by "klaas", and their state. Ah, if you
click on the patch, you'll see all the patch history, including the
sent/received emails. Even this email should be added there by patchwork ;)

Cheers,
Mauro

Re: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz

[hermann pitton]

Am Samstag, den 28.03.2009, 00:58 -0300 schrieb Mauro Carvalho Chehab:
> On Sat, 28 Mar 2009 00:23:55 +0100
> hermann pitton <hermann-pitton@arcor.de> wrote:
> 
> > Hi,
> > 
> > Am Freitag, den 27.03.2009, 07:38 -0300 schrieb Mauro Carvalho Chehab:
> > > On Fri, 27 Mar 2009 02:39:07 +0100
> > > hermann pitton <hermann-pitton@arcor.de> wrote:
> > > 
> > > > But my main concern is, if it once arrived at patchwork formally, it is
> > > > out of sight for most of us and might miss proper review, except you are
> > > > sure you can always guarantee that. I don't want to start to argue about
> > > > all what happened in the past.
> > > > 
> > > > So, at least, if some patch arrived there mysteriously ;), the
> > > > linux-media list should be informed that it is there now and last time
> > > > to speak off, in case anything is not fully clear, before vanishing into
> > > > some black hole until you find it in the next kernel release ...
> > > 
> > > The only way to send patches to patchwork is to submit it via linux-media list.
> > > There's no other way. So, all patch discussions and reviews should happen at
> > > the ML, by replying at the patch email (or by replying another reply).
> > > Patchwork will keep track of such replies as well.
> > > 
> > 
> > What happened so far with this patches is quite funny,
> > for me some black hole seems to be involved.
> > 
> > Klaas did send them the first time, also directly to me, on Tue, 24 Mar
> > 2009 23:14:11 +0100.
> > 
> > Now I can see you have pulled them in already on Wednesday.
> > http://linuxtv.org/hg/v4l-dvb/rev/5efa9fbc8a88
> > 
> > There is no trace anymore on patchwork visible to me.
> > http://patchwork.kernel.org/project/linux-media/list
> > So I don't know how you processed them.
> 
> The above link uses the default patchwork filtering. By default it shows only
> patches where there's an action required (e. g. New or Under Review patches).
> 
> To view a full list of the patches, you need to click at filters and select any.
> 
> You'll see all patches:
> 	http://patchwork.kernel.org/project/linux-media/list/?state=*
> 
> In the specific case od Klaas, this is his patch:
> 
> http://patchwork.kernel.org/patch/14405/
> 
> > Most confusing is, that Klaas obviously did not receive a mail
> > notification from linuxtv-commits that his patch came in.
> 
> > 
> > Last message date: Fri Feb 15 19:45:02 CET 2008
> > Archived on: Fri Feb 15 19:45:04 CET 2008 
> > 
> > Is it broken or only the archive not up to date?
> > 
> 
> I've received the notification here:
> 
> From: Patch from klaas de waal  <hg-commit@linuxtv.org>
> To: linuxtv-commits@linuxtv.org
> Cc: , Mauro Carvalho Chehab <mchehab@redhat.com>, klaas de waal <klaas.de.waal@gmail.com>
> Subject: [linuxtv-commits] [hg:v4l-dvb] tda827x: fix locking issues with DVB-C
> Date: Fri, 27 Mar 2009 18:05:01 +0100
> Reply-To: klaas de waal via Mercurial <klaas.de.waal@gmail.com>
> Sender: linuxtv-commits-bounces@linuxtv.org
> 
> The patch number 11236 was added via Mauro Carvalho Chehab <mchehab@redhat.com>
> to http://linuxtv.org/hg/v4l-dvb master development tree.
> 
> Klaas should be received this also. Maybe some anti-spam filtering on his side?
> 
> You'll probably see this also at the linuxtv-commits archives.
> 
> > Why else he would have posted a second time on
> > Wed, 25 Mar 2009 21:53:02 +0100 not knowing anything about the status of
> > his patches, which made me believe I should try to help him?
> > 
> > The timestamp on your mercurial commit of them is
> > Wed Mar 25 20:53:02 2009 +0000 (2 days ago)
> > That is the time when his second email arrived converted to Greenwich
> > time? Or how could you commit within the same second that mail arrived?
> 
> > This is the time the patches have on both of his original mails.
> > --- a/linux/drivers/media/common/tuners/tda827x.c Tue Mar 24 21:12:47 2009 +0000
> > --- a/linux/drivers/media/common/tuners/tda827x.c Tue Mar 24 21:12:47 2009 +0000
> 
> The import scripts will try to preserve the original date of the sent email.
> 
> So, the date there is when the code were presented to public.
> 
> > How can I ever know when they were really added and if they went through
> > patchwork :)
> > 
> > I was just about to suggest Klaas should try again with [PATCH] in the
> > subject until they are listed at patchwork.
> 
> If the patch was received by patchwork, and "disappeared", all you need to do
> is to click on filter and select a proper filter, like:
> 
> http://patchwork.kernel.org/project/linux-media/list/?submitter=klaas&state=*
> 
> This will present all patches authored by "klaas", and their state. Ah, if you
> click on the patch, you'll see all the patch history, including the
> sent/received emails. Even this email should be added there by patchwork ;)
> 
> Cheers,
> Mauro

Mauro, you are joking.

How I ever could come to that from here?
http://patchwork.kernel.org/project/linux-media/list

I'm forced to read the source code.

There seems to be some serious utf8 bug too.

Cheers,
Hermann

Re: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz

[hermann pitton]

Am Samstag, den 28.03.2009, 05:32 +0100 schrieb hermann pitton:
> Am Samstag, den 28.03.2009, 00:58 -0300 schrieb Mauro Carvalho Chehab:
> > On Sat, 28 Mar 2009 00:23:55 +0100
> > hermann pitton <hermann-pitton@arcor.de> wrote:
> > 
> > > Hi,
> > > 
> > > Am Freitag, den 27.03.2009, 07:38 -0300 schrieb Mauro Carvalho Chehab:
> > > > On Fri, 27 Mar 2009 02:39:07 +0100
> > > > hermann pitton <hermann-pitton@arcor.de> wrote:
> > > > 
> > > > > But my main concern is, if it once arrived at patchwork formally, it is
> > > > > out of sight for most of us and might miss proper review, except you are
> > > > > sure you can always guarantee that. I don't want to start to argue about
> > > > > all what happened in the past.
> > > > > 
> > > > > So, at least, if some patch arrived there mysteriously ;), the
> > > > > linux-media list should be informed that it is there now and last time
> > > > > to speak off, in case anything is not fully clear, before vanishing into
> > > > > some black hole until you find it in the next kernel release ...
> > > > 
> > > > The only way to send patches to patchwork is to submit it via linux-media list.
> > > > There's no other way. So, all patch discussions and reviews should happen at
> > > > the ML, by replying at the patch email (or by replying another reply).
> > > > Patchwork will keep track of such replies as well.
> > > > 
> > > 
> > > What happened so far with this patches is quite funny,
> > > for me some black hole seems to be involved.
> > > 
> > > Klaas did send them the first time, also directly to me, on Tue, 24 Mar
> > > 2009 23:14:11 +0100.
> > > 
> > > Now I can see you have pulled them in already on Wednesday.
> > > http://linuxtv.org/hg/v4l-dvb/rev/5efa9fbc8a88
> > > 
> > > There is no trace anymore on patchwork visible to me.
> > > http://patchwork.kernel.org/project/linux-media/list
> > > So I don't know how you processed them.
> > 
> > The above link uses the default patchwork filtering. By default it shows only
> > patches where there's an action required (e. g. New or Under Review patches).
> > 
> > To view a full list of the patches, you need to click at filters and select any.
> > 
> > You'll see all patches:
> > 	http://patchwork.kernel.org/project/linux-media/list/?state=*
> > 
> > In the specific case od Klaas, this is his patch:
> > 
> > http://patchwork.kernel.org/patch/14405/
> > 
> > > Most confusing is, that Klaas obviously did not receive a mail
> > > notification from linuxtv-commits that his patch came in.
> > 
> > > 
> > > Last message date: Fri Feb 15 19:45:02 CET 2008
> > > Archived on: Fri Feb 15 19:45:04 CET 2008 
> > > 
> > > Is it broken or only the archive not up to date?
> > > 
> > 
> > I've received the notification here:
> > 
> > From: Patch from klaas de waal  <hg-commit@linuxtv.org>
> > To: linuxtv-commits@linuxtv.org
> > Cc: , Mauro Carvalho Chehab <mchehab@redhat.com>, klaas de waal <klaas.de.waal@gmail.com>
> > Subject: [linuxtv-commits] [hg:v4l-dvb] tda827x: fix locking issues with DVB-C
> > Date: Fri, 27 Mar 2009 18:05:01 +0100
> > Reply-To: klaas de waal via Mercurial <klaas.de.waal@gmail.com>
> > Sender: linuxtv-commits-bounces@linuxtv.org
> > 
> > The patch number 11236 was added via Mauro Carvalho Chehab <mchehab@redhat.com>
> > to http://linuxtv.org/hg/v4l-dvb master development tree.
> > 
> > Klaas should be received this also. Maybe some anti-spam filtering on his side?
> > 
> > You'll probably see this also at the linuxtv-commits archives.
> > 
> > > Why else he would have posted a second time on
> > > Wed, 25 Mar 2009 21:53:02 +0100 not knowing anything about the status of
> > > his patches, which made me believe I should try to help him?
> > > 
> > > The timestamp on your mercurial commit of them is
> > > Wed Mar 25 20:53:02 2009 +0000 (2 days ago)
> > > That is the time when his second email arrived converted to Greenwich
> > > time? Or how could you commit within the same second that mail arrived?
> > 
> > > This is the time the patches have on both of his original mails.
> > > --- a/linux/drivers/media/common/tuners/tda827x.c Tue Mar 24 21:12:47 2009 +0000
> > > --- a/linux/drivers/media/common/tuners/tda827x.c Tue Mar 24 21:12:47 2009 +0000
> > 
> > The import scripts will try to preserve the original date of the sent email.
> > 
> > So, the date there is when the code were presented to public.
> > 
> > > How can I ever know when they were really added and if they went through
> > > patchwork :)
> > > 
> > > I was just about to suggest Klaas should try again with [PATCH] in the
> > > subject until they are listed at patchwork.
> > 
> > If the patch was received by patchwork, and "disappeared", all you need to do
> > is to click on filter and select a proper filter, like:
> > 
> > http://patchwork.kernel.org/project/linux-media/list/?submitter=klaas&state=*
> > 
> > This will present all patches authored by "klaas", and their state. Ah, if you
> > click on the patch, you'll see all the patch history, including the
> > sent/received emails. Even this email should be added there by patchwork ;)
> > 
> > Cheers,
> > Mauro
> 
> Mauro, you are joking.
> 
> How I ever could come to that from here?
> http://patchwork.kernel.org/project/linux-media/list
> 
> I'm forced to read the source code.
> 
> There seems to be some serious utf8 bug too.

Ok, I can see now you can click at least one of the 2mm buttons, of
course all self explaining :)

Cheers,
Hermann

Re: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz

[hermann pitton]

Am Samstag, den 28.03.2009, 05:48 +0100 schrieb hermann pitton:
> Am Samstag, den 28.03.2009, 05:32 +0100 schrieb hermann pitton:
> > Am Samstag, den 28.03.2009, 00:58 -0300 schrieb Mauro Carvalho Chehab:
> > > On Sat, 28 Mar 2009 00:23:55 +0100
> > > hermann pitton <hermann-pitton@arcor.de> wrote:
> > > 
> > > > Hi,
> > > > 
> > > > Am Freitag, den 27.03.2009, 07:38 -0300 schrieb Mauro Carvalho Chehab:
> > > > > On Fri, 27 Mar 2009 02:39:07 +0100
> > > > > hermann pitton <hermann-pitton@arcor.de> wrote:
> > > > > 
> > > > > > But my main concern is, if it once arrived at patchwork formally, it is
> > > > > > out of sight for most of us and might miss proper review, except you are
> > > > > > sure you can always guarantee that. I don't want to start to argue about
> > > > > > all what happened in the past.
> > > > > > 
> > > > > > So, at least, if some patch arrived there mysteriously ;), the
> > > > > > linux-media list should be informed that it is there now and last time
> > > > > > to speak off, in case anything is not fully clear, before vanishing into
> > > > > > some black hole until you find it in the next kernel release ...
> > > > > 
> > > > > The only way to send patches to patchwork is to submit it via linux-media list.
> > > > > There's no other way. So, all patch discussions and reviews should happen at
> > > > > the ML, by replying at the patch email (or by replying another reply).
> > > > > Patchwork will keep track of such replies as well.
> > > > > 
> > > > 
> > > > What happened so far with this patches is quite funny,
> > > > for me some black hole seems to be involved.
> > > > 
> > > > Klaas did send them the first time, also directly to me, on Tue, 24 Mar
> > > > 2009 23:14:11 +0100.
> > > > 
> > > > Now I can see you have pulled them in already on Wednesday.
> > > > http://linuxtv.org/hg/v4l-dvb/rev/5efa9fbc8a88
> > > > 
> > > > There is no trace anymore on patchwork visible to me.
> > > > http://patchwork.kernel.org/project/linux-media/list
> > > > So I don't know how you processed them.
> > > 
> > > The above link uses the default patchwork filtering. By default it shows only
> > > patches where there's an action required (e. g. New or Under Review patches).
> > > 
> > > To view a full list of the patches, you need to click at filters and select any.
> > > 
> > > You'll see all patches:
> > > 	http://patchwork.kernel.org/project/linux-media/list/?state=*
> > > 
> > > In the specific case od Klaas, this is his patch:
> > > 
> > > http://patchwork.kernel.org/patch/14405/
> > > 
> > > > Most confusing is, that Klaas obviously did not receive a mail
> > > > notification from linuxtv-commits that his patch came in.
> > > 
> > > > 
> > > > Last message date: Fri Feb 15 19:45:02 CET 2008
> > > > Archived on: Fri Feb 15 19:45:04 CET 2008 
> > > > 
> > > > Is it broken or only the archive not up to date?
> > > > 
> > > 
> > > I've received the notification here:
> > > 
> > > From: Patch from klaas de waal  <hg-commit@linuxtv.org>
> > > To: linuxtv-commits@linuxtv.org
> > > Cc: , Mauro Carvalho Chehab <mchehab@redhat.com>, klaas de waal <klaas.de.waal@gmail.com>
> > > Subject: [linuxtv-commits] [hg:v4l-dvb] tda827x: fix locking issues with DVB-C
> > > Date: Fri, 27 Mar 2009 18:05:01 +0100
> > > Reply-To: klaas de waal via Mercurial <klaas.de.waal@gmail.com>
> > > Sender: linuxtv-commits-bounces@linuxtv.org
> > > 
> > > The patch number 11236 was added via Mauro Carvalho Chehab <mchehab@redhat.com>
> > > to http://linuxtv.org/hg/v4l-dvb master development tree.
> > > 
> > > Klaas should be received this also. Maybe some anti-spam filtering on his side?
> > > 
> > > You'll probably see this also at the linuxtv-commits archives.
> > > 
> > > > Why else he would have posted a second time on
> > > > Wed, 25 Mar 2009 21:53:02 +0100 not knowing anything about the status of
> > > > his patches, which made me believe I should try to help him?
> > > > 
> > > > The timestamp on your mercurial commit of them is
> > > > Wed Mar 25 20:53:02 2009 +0000 (2 days ago)
> > > > That is the time when his second email arrived converted to Greenwich
> > > > time? Or how could you commit within the same second that mail arrived?
> > > 
> > > > This is the time the patches have on both of his original mails.
> > > > --- a/linux/drivers/media/common/tuners/tda827x.c Tue Mar 24 21:12:47 2009 +0000
> > > > --- a/linux/drivers/media/common/tuners/tda827x.c Tue Mar 24 21:12:47 2009 +0000
> > > 
> > > The import scripts will try to preserve the original date of the sent email.
> > > 
> > > So, the date there is when the code were presented to public.
> > > 
> > > > How can I ever know when they were really added and if they went through
> > > > patchwork :)
> > > > 
> > > > I was just about to suggest Klaas should try again with [PATCH] in the
> > > > subject until they are listed at patchwork.
> > > 
> > > If the patch was received by patchwork, and "disappeared", all you need to do
> > > is to click on filter and select a proper filter, like:
> > > 
> > > http://patchwork.kernel.org/project/linux-media/list/?submitter=klaas&state=*
> > > 
> > > This will present all patches authored by "klaas", and their state. Ah, if you
> > > click on the patch, you'll see all the patch history, including the
> > > sent/received emails. Even this email should be added there by patchwork ;)
> > > 
> > > Cheers,
> > > Mauro
> > 
> > Mauro, you are joking.
> > 
> > How I ever could come to that from here?
> > http://patchwork.kernel.org/project/linux-media/list
> > 
> > I'm forced to read the source code.
> > 
> > There seems to be some serious utf8 bug too.
> 
> Ok, I can see now you can click at least one of the 2mm buttons, of
> course all self explaining :)

One last comment on it, hopefully all goes well, but it did not go like
I would have preferred it.

It was not waited for, if somebody has eventually already the detailed
programming instructions for that one. It likely is the case after all
these years.

The patch was never tested by those eventually affected on the other
side, since at least I would have await that this direction is confirmed
to still be right previously :)

The driver maintainer, who has also high credits for moderating within
unrelated conflicting stuff he did not cause at all over years, did not
give a statement yet. My, wait at least a week after the patches are
around since ever anyway, except for getting the LNA config quiet.

Cheers,
Hermann