[linux-dvb] au0828: experimental support for Syntek Teledongle [05e1:0400]

[linux-dvb] au0828: experimental support for Syntek Teledongle [05e1:0400]

[Malcolm Lewis]

Hi
I've been using the patches from
http://linuxtv.org/hg/~mkrufky/teledongle/rev/676e2f4475ed
on a Sabrent device in openSuSE and SLED, during testing with the
milestone 5 release of
11.2 and kernel version 2.6.31-rc5-git3-2-desktop there needs to be
some changes to the
au0828-cards.c patch to enable building a kmp module;

--- au0828-cards.c    2009-08-12 18:16:39.435886920 -0500
+++ au0828-cards.c.orig    2009-08-12 18:28:22.176126368 -0500
@@ -116,6 +116,12 @@
         .tuner_addr = ADDR_UNSET,
         .i2c_clk_divider = AU0828_I2C_CLK_250KHZ,
     },
+    [AU0828_BOARD_SYNTEK_TELEDONGLE] = {
+        .name = "Syntek Teledongle [EXPERIMENTAL]",
+         .tuner_type = UNSET,
+        .tuner_addr = ADDR_UNSET,
+        .i2c_clk_divider = AU0828_I2C_CLK_250KHZ,
+    },
 };

 /* Tuner callback function for au0828 boards. Currently only needed
@@ -248,6 +254,7 @@
     case AU0828_BOARD_HAUPPAUGE_HVR950Q:
     case AU0828_BOARD_HAUPPAUGE_HVR950Q_MXL:
     case AU0828_BOARD_HAUPPAUGE_WOODBURY:
+    case AU0828_BOARD_SYNTEK_TELEDONGLE: /* FIXME */
         /* GPIO's
          * 4 - CS5340
          * 5 - AU8522 Demodulator
@@ -325,6 +332,8 @@
         .driver_info = AU0828_BOARD_HAUPPAUGE_HVR950Q_MXL },
     { USB_DEVICE(0x2040, 0x8200),
         .driver_info = AU0828_BOARD_HAUPPAUGE_WOODBURY },
+    { USB_DEVICE(0x05e1, 0x0400),
+                .driver_info = AU0828_BOARD_SYNTEK_TELEDONGLE },
     { },
 };


There are two versions I'm building and src for both can be found here;
http://download.opensuse.org/repositories/home:/malcolmlewis/

--
Cheers
Malcolm

_______________________________________________
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] au0828: experimental support for Syntek Teledongle [05e1:0400]

[Michael Krufky]

On Mon, Aug 17, 2009 at 4:25 PM, Malcolm Lewis<coyoteuser@gmail.com> wrote:
> Hi
> I've been using the patches from
> http://linuxtv.org/hg/~mkrufky/teledongle/rev/676e2f4475ed
> on a Sabrent device in openSuSE and SLED, during testing with the
> milestone 5 release of
> 11.2 and kernel version 2.6.31-rc5-git3-2-desktop there needs to be
> some changes to the
> au0828-cards.c patch to enable building a kmp module;
>
> --- au0828-cards.c    2009-08-12 18:16:39.435886920 -0500
> +++ au0828-cards.c.orig    2009-08-12 18:28:22.176126368 -0500
> @@ -116,6 +116,12 @@
>          .tuner_addr = ADDR_UNSET,
>          .i2c_clk_divider = AU0828_I2C_CLK_250KHZ,
>      },
> +    [AU0828_BOARD_SYNTEK_TELEDONGLE] = {
> +        .name = "Syntek Teledongle [EXPERIMENTAL]",
> +         .tuner_type = UNSET,
> +        .tuner_addr = ADDR_UNSET,
> +        .i2c_clk_divider = AU0828_I2C_CLK_250KHZ,
> +    },
>  };
>
>  /* Tuner callback function for au0828 boards. Currently only needed
> @@ -248,6 +254,7 @@
>      case AU0828_BOARD_HAUPPAUGE_HVR950Q:
>      case AU0828_BOARD_HAUPPAUGE_HVR950Q_MXL:
>      case AU0828_BOARD_HAUPPAUGE_WOODBURY:
> +    case AU0828_BOARD_SYNTEK_TELEDONGLE: /* FIXME */
>          /* GPIO's
>           * 4 - CS5340
>           * 5 - AU8522 Demodulator
> @@ -325,6 +332,8 @@
>          .driver_info = AU0828_BOARD_HAUPPAUGE_HVR950Q_MXL },
>      { USB_DEVICE(0x2040, 0x8200),
>          .driver_info = AU0828_BOARD_HAUPPAUGE_WOODBURY },
> +    { USB_DEVICE(0x05e1, 0x0400),
> +                .driver_info = AU0828_BOARD_SYNTEK_TELEDONGLE },
>      { },
>  };
>
>
> There are two versions I'm building and src for both can be found here;
> http://download.opensuse.org/repositories/home:/malcolmlewis/


Malcolm,

I would strongly advise against distributing packages based on these
patches... This code was never merged into the master branch because
it has potential to break devices at the hardware level, and it will
create a support nightmare, based on the fact that there are multiple
UNLIKE devices that use the same USB ID but actually contain different
hardware components.  As the patch may enable support for ONE of the
variations, nobody has ever verified that the GPIO programming is safe
to use, and there is no way to prevent the potentially harmful code
from running on the wrong device.

I, personally, do not want the responsibility of explaining to users
that their usb sticks may be damaged because of code that got merged
into the kernel -- that's why the code is in a separate repository
until the issues can be dealt with.  In general, users know that if
they have to manually apply patches themselves, that they are doing so
at their own risk.

If you succeed in getting your device to work, please let me know -- I
will be very interested to hear about it.

Good Luck,

Mike

Re: [linux-dvb] au0828: experimental support for Syntek Teledongle [05e1:0400]

[Malcolm Lewis]

On Mon, Aug 17, 2009 at 3:59 PM, Michael Krufky<mkrufky@kernellabs.com> wrote:
> On Mon, Aug 17, 2009 at 4:25 PM, Malcolm Lewis<coyoteuser@gmail.com> wrote:
>> Hi
>> I've been using the patches from
>> http://linuxtv.org/hg/~mkrufky/teledongle/rev/676e2f4475ed
>> on a Sabrent device in openSuSE and SLED, during testing with the
>> milestone 5 release of
>> 11.2 and kernel version 2.6.31-rc5-git3-2-desktop there needs to be
>> some changes to the
>> au0828-cards.c patch to enable building a kmp module;
>>
>> --- au0828-cards.c    2009-08-12 18:16:39.435886920 -0500
>> +++ au0828-cards.c.orig    2009-08-12 18:28:22.176126368 -0500
>> @@ -116,6 +116,12 @@
>>          .tuner_addr = ADDR_UNSET,
>>          .i2c_clk_divider = AU0828_I2C_CLK_250KHZ,
>>      },
>> +    [AU0828_BOARD_SYNTEK_TELEDONGLE] = {
>> +        .name = "Syntek Teledongle [EXPERIMENTAL]",
>> +         .tuner_type = UNSET,
>> +        .tuner_addr = ADDR_UNSET,
>> +        .i2c_clk_divider = AU0828_I2C_CLK_250KHZ,
>> +    },
>>  };
>>
>>  /* Tuner callback function for au0828 boards. Currently only needed
>> @@ -248,6 +254,7 @@
>>      case AU0828_BOARD_HAUPPAUGE_HVR950Q:
>>      case AU0828_BOARD_HAUPPAUGE_HVR950Q_MXL:
>>      case AU0828_BOARD_HAUPPAUGE_WOODBURY:
>> +    case AU0828_BOARD_SYNTEK_TELEDONGLE: /* FIXME */
>>          /* GPIO's
>>           * 4 - CS5340
>>           * 5 - AU8522 Demodulator
>> @@ -325,6 +332,8 @@
>>          .driver_info = AU0828_BOARD_HAUPPAUGE_HVR950Q_MXL },
>>      { USB_DEVICE(0x2040, 0x8200),
>>          .driver_info = AU0828_BOARD_HAUPPAUGE_WOODBURY },
>> +    { USB_DEVICE(0x05e1, 0x0400),
>> +                .driver_info = AU0828_BOARD_SYNTEK_TELEDONGLE },
>>      { },
>>  };
>>
>>
>> There are two versions I'm building and src for both can be found here;
>> http://download.opensuse.org/repositories/home:/malcolmlewis/
>
>
> Malcolm,
>
> I would strongly advise against distributing packages based on these
> patches... This code was never merged into the master branch because
> it has potential to break devices at the hardware level, and it will
> create a support nightmare, based on the fact that there are multiple
> UNLIKE devices that use the same USB ID but actually contain different
> hardware components.  As the patch may enable support for ONE of the
> variations, nobody has ever verified that the GPIO programming is safe
> to use, and there is no way to prevent the potentially harmful code
> from running on the wrong device.
>
> I, personally, do not want the responsibility of explaining to users
> that their usb sticks may be damaged because of code that got merged
> into the kernel -- that's why the code is in a separate repository
> until the issues can be dealt with.  In general, users know that if
> they have to manually apply patches themselves, that they are doing so
> at their own risk.
>
> If you succeed in getting your device to work, please let me know -- I
> will be very interested to hear about it.
>
> Good Luck,
>
> Mike
>
> _______________________________________________
> 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
>
Hi Mike
Ahh, OK :) I can confirm I've had no issues using it with smplayer on
openSuSE 11.0, openSuSE 11.1 and openSuSE 11.2 M5 i586 (ViA Artigo and
ASUS 1000HE) and SLED 11 x86_64 (home build AMD 4400 X2 system).
System tunes into FTA HDTV great, have scan in different areas and all
scanned channels found have worked. (I'm in Mississippi)

I'm happy to do further testing if you can advise on what is required.

-- 
Cheers
Malcolm

Re: [linux-dvb] au0828: experimental support for Syntek Teledongle [05e1:0400]

[Johannes Stezenbach]

On Mon, Aug 17, 2009 at 04:59:42PM -0400, Michael Krufky wrote:
> 
> variations, nobody has ever verified that the GPIO programming is safe
> to use, and there is no way to prevent the potentially harmful code
> from running on the wrong device.
> 
> I, personally, do not want the responsibility of explaining to users
> that their usb sticks may be damaged because of code that got merged

I would be interested to know if someone _actually_ managed
to break their hardware by using buggy drivers.  IANAL but
I think that consumer electronics hardware which can be damaged by
software is broken by design.  A vendor selling such hardware is
stupid because people would return the broken hardware and get
a replacement.  I don't see how a vendor could proof that the device
was not damaged by an obscure bug in the Windows driver to get
around their responsibility to replace broken hardware within
the warranty period.


Johannes

Re: [linux-dvb] au0828: experimental support for Syntek Teledongle [05e1:0400]

[Devin Heitmueller]

On Tue, Aug 18, 2009 at 7:00 AM, Johannes Stezenbach<js@linuxtv.org> wrote:
> I would be interested to know if someone _actually_ managed
> to break their hardware by using buggy drivers.

The short answer is *absolutely*.

/me takes off "driver developer hat" and puts on "hardware developer hat"

In a world of flash, eeproms, and software programmable clocks, there
are all sorts of ways where a driver bug can damage the hardware.
Looking for some simple examples?

1.  Think of the "overclocking" community and what happens when they
reconfigure a GPU's software controlled clock to perform beyond its
maximum expected rating without extra cooling.

2.  Think of all the reports of corrupted eeproms you read about on
the mailing list.  Sure, in many cases a good developer can hack a way
to reprogram the eeprom in software, but in many cases the board won't
even come up, so you end up with an RMA.  It's not "damaged" in the
more traditional sense, but the net effect is the same - the board is
rendered inoperable and has to be sent back to the manufacturer.

3.  Try loading the xc3028 tuner firmware onto the low power version
of the chip (xc3028l).  It took me a minute before I realized the
smell of burning plastic was coming from my tuner.

Don't get me wrong, in many cases things can be designed into the
hardware to mitigate the effects of software bugs.  In any hardware
design, your goal is to minimize the return rate, so you build
failsafes for the most likely to occur problems.  However, in many
cases this adds additional cost to the BOM, and you make educated
decisions about the probability of certain classes of failure and
instead build the reliability into the driver instead (making sure
that the Windows driver can *never* put the hardware into a state).  A
random open source developer doesn't know what these sorts of
decisions were, and would not be able to replicate the corresponding
checks in a Linux driver.

4.  Ever see a user complaint of how a tuner runs "hot" under Linux
compared to the same device running under Windows?  Almost certainly
an improperly GPIO configuration which resulted in a condition such as
having the digital demod powered on at the same time as the analog
decoder.  Sure, it will work for a while but you're running the device
outside of the expected thermal profile and shortening the life of the
hardware.

The above are just a few *simple* examples.  The nastier ones are
often too difficult to explain in less than fifty words.

> IANAL but
> I think that consumer electronics hardware which can be damaged by
> software is broken by design.  A vendor selling such hardware is
> stupid because people would return the broken hardware and get
> a replacement.  I don't see how a vendor could proof that the device
> was not damaged by an obscure bug in the Windows driver to get
> around their responsibility to replace broken hardware within
> the warranty period.

Yeah, you're right.  Usually they cannot tell right away and will
perform an RMA.  And the board will end up on a lab bench with a
hardware engineering isolating which component failed, and then
working with the driver developer trying to figure out how the hell
their Windows driver put the board in such a state.  The risk of
trusting some random Linux developer's driver work is a reason why
some vendors don't want to support Linux.  If I were a vendor, and I
endorsed a Linux driver written by someone without the appropriate
knowledge of the hardware, I could end up with large number of product
returns, and I would incur the cost of those losses.

Also, in many cases the board doesn't burn out immediately.  But
because of crappy drivers it takes three or four months to burn out,
and the result is a board that is designed to run without problems for
tens of thousands of hours dies in a significantly shorter time.

Good device driver developers realize and accept this risk whenever
they attempt to write a reverse engineered driver.   I certainly don't
want to discourage people from learning how to write Linux drivers for
tuners, but caveat emptor - you can end up permanently damaging your
hardware.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: [linux-dvb] au0828: experimental support for Syntek Teledongle [05e1:0400]

[hermann pitton]

Am Dienstag, den 18.08.2009, 10:07 -0400 schrieb Devin Heitmueller:
> On Tue, Aug 18, 2009 at 7:00 AM, Johannes Stezenbach<js@linuxtv.org> wrote:
> > I would be interested to know if someone _actually_ managed
> > to break their hardware by using buggy drivers.
> 
> The short answer is *absolutely*.
> 
> /me takes off "driver developer hat" and puts on "hardware developer hat"
> 
> In a world of flash, eeproms, and software programmable clocks, there
> are all sorts of ways where a driver bug can damage the hardware.
> Looking for some simple examples?
> 
> 1.  Think of the "overclocking" community and what happens when they
> reconfigure a GPU's software controlled clock to perform beyond its
> maximum expected rating without extra cooling.
> 
> 2.  Think of all the reports of corrupted eeproms you read about on
> the mailing list.  Sure, in many cases a good developer can hack a way
> to reprogram the eeprom in software, but in many cases the board won't
> even come up, so you end up with an RMA.  It's not "damaged" in the
> more traditional sense, but the net effect is the same - the board is
> rendered inoperable and has to be sent back to the manufacturer.
> 
> 3.  Try loading the xc3028 tuner firmware onto the low power version
> of the chip (xc3028l).  It took me a minute before I realized the
> smell of burning plastic was coming from my tuner.
> 
> Don't get me wrong, in many cases things can be designed into the
> hardware to mitigate the effects of software bugs.  In any hardware
> design, your goal is to minimize the return rate, so you build
> failsafes for the most likely to occur problems.  However, in many
> cases this adds additional cost to the BOM, and you make educated
> decisions about the probability of certain classes of failure and
> instead build the reliability into the driver instead (making sure
> that the Windows driver can *never* put the hardware into a state).  A
> random open source developer doesn't know what these sorts of
> decisions were, and would not be able to replicate the corresponding
> checks in a Linux driver.
> 
> 4.  Ever see a user complaint of how a tuner runs "hot" under Linux
> compared to the same device running under Windows?  Almost certainly
> an improperly GPIO configuration which resulted in a condition such as
> having the digital demod powered on at the same time as the analog
> decoder.  Sure, it will work for a while but you're running the device
> outside of the expected thermal profile and shortening the life of the
> hardware.
> 
> The above are just a few *simple* examples.  The nastier ones are
> often too difficult to explain in less than fifty words.
> 
> > IANAL but
> > I think that consumer electronics hardware which can be damaged by
> > software is broken by design.  A vendor selling such hardware is
> > stupid because people would return the broken hardware and get
> > a replacement.  I don't see how a vendor could proof that the device
> > was not damaged by an obscure bug in the Windows driver to get
> > around their responsibility to replace broken hardware within
> > the warranty period.
> 
> Yeah, you're right.  Usually they cannot tell right away and will
> perform an RMA.  And the board will end up on a lab bench with a
> hardware engineering isolating which component failed, and then
> working with the driver developer trying to figure out how the hell
> their Windows driver put the board in such a state.  The risk of
> trusting some random Linux developer's driver work is a reason why
> some vendors don't want to support Linux.  If I were a vendor, and I
> endorsed a Linux driver written by someone without the appropriate
> knowledge of the hardware, I could end up with large number of product
> returns, and I would incur the cost of those losses.
> 
> Also, in many cases the board doesn't burn out immediately.  But
> because of crappy drivers it takes three or four months to burn out,
> and the result is a board that is designed to run without problems for
> tens of thousands of hours dies in a significantly shorter time.
> 
> Good device driver developers realize and accept this risk whenever
> they attempt to write a reverse engineered driver.   I certainly don't
> want to discourage people from learning how to write Linux drivers for
> tuners, but caveat emptor - you can end up permanently damaging your
> hardware.
> 
> Devin
> 

Hi,

again, both can be right.

I don't deny the smell you had, what a crap on the other hand.

But Johannes is right too. I did not manage to burn a single Philips
device during the last seven years.

And i did all the worst every single day ;)

So, there might be still a slight difference ...

Cheers,
Hermann

Re: [linux-dvb] au0828: experimental support for Syntek Teledongle [05e1:0400]

[Johannes Stezenbach]

On Tue, Aug 18, 2009 at 10:07:04AM -0400, Devin Heitmueller wrote:
>                                                      The risk of
> trusting some random Linux developer's driver work is a reason why
> some vendors don't want to support Linux.  If I were a vendor, and I
> endorsed a Linux driver written by someone without the appropriate
> knowledge of the hardware, I could end up with large number of product
> returns, and I would incur the cost of those losses.

This is an interesting statement.  Let me rephrase it:

If I were a vendor selling ill-designed hardware which can
be permanently damaged by buggy software, I'd make sure
as hell that I get the information about how to avoid the
damage out to every Open Source developer.  Otherwise
I would have to live with the risk of seeing an increased
rate of product returns.


BTW, there is a big difference of "after I plugged the device
in under Linux it was dead" and "it runs hot under Linux, that might
shorten the life span".  I hope there is no hardware of the first
kind.  For the second kind you can fairly safely experiment until
you solved the problem.


Thanks,
Johannes