Broken ttusb-dec DVB support since, well, year(s) - Kernel

This is a discussion on Broken ttusb-dec DVB support since, well, year(s) - Kernel ; Moin moin! Sorry I'm posting this here rather than to the more specific linux-dvb@ mailing list where I'd rather this appear, but my attempts to surbscibe!@! to that list have been rejected, first as an invalid e-mail, then an insecure ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Broken ttusb-dec DVB support since, well, year(s)

  1. Broken ttusb-dec DVB support since, well, year(s)

    Moin moin!

    Sorry I'm posting this here rather than to the more specific
    linux-dvb@ mailing list where I'd rather this appear, but my
    attempts to surbscibe!@! to that list have been rejected, first
    as an invalid e-mail, then an insecure e-mail, and I've been
    unable to progress further from this throwaway account.

    Feel free to redirect/repost this message there if you're a
    qualified developer and feel it's more appropriate.


    There is a change that was introduced to the file
    drivers/media/dvb/ttusb-dec/ttusbdecfe.c
    sometime in the not-too-recent past and which resulted in breaking
    the support which early 2.6.1x kernels had for my Hauppauge
    DEC-3000s DVB-S device.

    The particular code (below) checks the value in a register to
    decide the tuning status -- hitherto one had to assume the device
    was properly tuned and receiving signal and everything.


    60 switch(result[3]) {
    61 case 1: /* not tuned yet */
    62 case 2: /* no signal/no lock*/
    63 break;
    64 case 3: /* signal found and locked*/
    65 *status = FE_HAS_SIGNAL | FE_HAS_VITERBI |
    66 FE_HAS_SYNC | FE_HAS_CARRIER | FE_HAS_LOCK;
    67 break;
    68 case 4:
    69 *status = FE_TIMEDOUT;
    70 break;
    71 default:
    72 pr_info("%s: returned unknown value: %d\n",
    73 __func__, result[3]);
    74 return -EIO;
    75 }


    Unfortunately, while this might work for the other flavours of
    card (DVB-T?) supported by this code, in the case of my particular
    device for DVB-S, the unknown value returned is 0 and does not
    change regardless of tuning status.

    I haven't checked whether a different register on my particular
    device contains a usable value for the above code.

    In any case, with my particular device, in order to use more
    recent kernels, I've had to add a ``case 0:'' line to the
    ``case 3:'' seen above in order to get the previous behaviour
    where no check was made.


    As I don't know the particular model for which the quoted code
    was added, I don't know if my device is unique, or whether the
    number of DVB-S users of this code is miniscule, as nobody else
    has complained that I've seen.

    Apologies for not reporting this long ago when first observed,
    but I've not had any meaningful Internet access in a long time
    to allow me more than just leeching the latest codes.


    thanks,
    BOUWSMA Barry




    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: Broken ttusb-dec DVB support since, well, year(s)

    On Sun, 22 Jun 2008 23:55:29 -0700 (PDT) barry bouwsma wrote:

    > Moin moin!
    >
    > Sorry I'm posting this here rather than to the more specific
    > linux-dvb@ mailing list where I'd rather this appear, but my
    > attempts to surbscibe!@! to that list have been rejected, first
    > as an invalid e-mail, then an insecure e-mail, and I've been
    > unable to progress further from this throwaway account.


    These closed lists are a pain.

    Lots of subprojects have moved their lists to vger.kernel.org in recent
    months. It gets close to zero spam. Hint.

    > Feel free to redirect/repost this message there if you're a
    > qualified developer and feel it's more appropriate.
    >
    >
    > There is a change that was introduced to the file
    > drivers/media/dvb/ttusb-dec/ttusbdecfe.c
    > sometime in the not-too-recent past and which resulted in breaking
    > the support which early 2.6.1x kernels had for my Hauppauge
    > DEC-3000s DVB-S device.
    >
    > The particular code (below) checks the value in a register to
    > decide the tuning status -- hitherto one had to assume the device
    > was properly tuned and receiving signal and everything.
    >
    >
    > 60 switch(result[3]) {
    > 61 case 1: /* not tuned yet */
    > 62 case 2: /* no signal/no lock*/
    > 63 break;
    > 64 case 3: /* signal found and locked*/
    > 65 *status = FE_HAS_SIGNAL | FE_HAS_VITERBI |
    > 66 FE_HAS_SYNC | FE_HAS_CARRIER | FE_HAS_LOCK;
    > 67 break;
    > 68 case 4:
    > 69 *status = FE_TIMEDOUT;
    > 70 break;
    > 71 default:
    > 72 pr_info("%s: returned unknown value: %d\n",
    > 73 __func__, result[3]);
    > 74 return -EIO;
    > 75 }
    >
    >
    > Unfortunately, while this might work for the other flavours of
    > card (DVB-T?) supported by this code, in the case of my particular
    > device for DVB-S, the unknown value returned is 0 and does not
    > change regardless of tuning status.
    >
    > I haven't checked whether a different register on my particular
    > device contains a usable value for the above code.
    >
    > In any case, with my particular device, in order to use more
    > recent kernels, I've had to add a ``case 0:'' line to the
    > ``case 3:'' seen above in order to get the previous behaviour
    > where no check was made.
    >
    >
    > As I don't know the particular model for which the quoted code
    > was added, I don't know if my device is unique, or whether the
    > number of DVB-S users of this code is miniscule, as nobody else
    > has complained that I've seen.
    >
    > Apologies for not reporting this long ago when first observed,
    > but I've not had any meaningful Internet access in a long time
    > to allow me more than just leeching the latest codes.
    >
    > thanks,
    > BOUWSMA Barry
    >


    Thanks. Cc's added.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: Broken ttusb-dec DVB support since, well, year(s)

    Andrew Morton schrieb:
    > On Sun, 22 Jun 2008 23:55:29 -0700 (PDT) barry bouwsma wrote:
    >
    >> Moin moin!
    >>
    >> Sorry I'm posting this here rather than to the more specific
    >> linux-dvb@ mailing list where I'd rather this appear, but my
    >> attempts to surbscibe!@! to that list have been rejected, first
    >> as an invalid e-mail, then an insecure e-mail, and I've been
    >> unable to progress further from this throwaway account.

    >
    > These closed lists are a pain.
    >
    > Lots of subprojects have moved their lists to vger.kernel.org in recent
    > months. It gets close to zero spam. Hint.
    >
    >> Feel free to redirect/repost this message there if you're a
    >> qualified developer and feel it's more appropriate.
    >>
    >>
    >> There is a change that was introduced to the file
    >> drivers/media/dvb/ttusb-dec/ttusbdecfe.c
    >> sometime in the not-too-recent past and which resulted in breaking
    >> the support which early 2.6.1x kernels had for my Hauppauge
    >> DEC-3000s DVB-S device.


    So only dvb-s support is broken. The DEC-2000t (hopefully) still works.
    If there is still somebody around using that thing
    Honestly, I wasn't aware that the DEC-3000s has ever really worked.

    >>
    >> The particular code (below) checks the value in a register to
    >> decide the tuning status -- hitherto one had to assume the device
    >> was properly tuned and receiving signal and everything.
    >>
    >>
    >> 60 switch(result[3]) {
    >> 61 case 1: /* not tuned yet */
    >> 62 case 2: /* no signal/no lock*/
    >> 63 break;
    >> 64 case 3: /* signal found and locked*/
    >> 65 *status = FE_HAS_SIGNAL | FE_HAS_VITERBI |
    >> 66 FE_HAS_SYNC | FE_HAS_CARRIER | FE_HAS_LOCK;
    >> 67 break;
    >> 68 case 4:
    >> 69 *status = FE_TIMEDOUT;
    >> 70 break;
    >> 71 default:
    >> 72 pr_info("%s: returned unknown value: %d\n",
    >> 73 __func__, result[3]);
    >> 74 return -EIO;
    >> 75 }
    >>
    >>
    >> Unfortunately, while this might work for the other flavours of
    >> card (DVB-T?) supported by this code, in the case of my particular
    >> device for DVB-S, the unknown value returned is 0 and does not
    >> change regardless of tuning status.
    >>
    >> I haven't checked whether a different register on my particular
    >> device contains a usable value for the above code.
    >>
    >> In any case, with my particular device, in order to use more
    >> recent kernels, I've had to add a ``case 0:'' line to the
    >> ``case 3:'' seen above in order to get the previous behaviour
    >> where no check was made.
    >>


    Indeed I added the above code only for the dec2000-t model. Since I have no
    idea how that stuff works on the dec3000, probably the best thing to do is to
    revert to the old behaviour for dec3000s models, i.e. just pretend we always have
    a signal. Something like the attached patch. Does that help?


    >>
    >> As I don't know the particular model for which the quoted code
    >> was added, I don't know if my device is unique, or whether the
    >> number of DVB-S users of this code is miniscule, as nobody else
    >> has complained that I've seen.
    >>


    well, i remember at least one report on the linux-dvb ml a long time ago
    and iirc I have posted the same patch there, but it didn't help.
    We never figured out how to make that particular dec3000s work.
    And without hw documentation this is more like a puzzle game.
    Which is rather demotivating.


+ Reply to Thread