Re: [linux-dvb] MC44S803 frontend (it works)

Re: [linux-dvb] MC44S803 frontend (it works)

[Roberto Ragusa]

(to both linux-dvb and linux-media)

Jochen Friedrich wrote:
> Hi Roberto,
> 
>> Is there any plan to include this frontend in mainline kernels?
>> I used to run this driver months ago and it was working well.
> 
> The reason is the huge memory footprint due to the included frequency table.
> I worked a bit on the driver to get rid of this table. Could you try this version:
> 
> 1. Patch for AF9015:
> 
> http://git.bocc.de/cgi-bin/gitweb.cgi?p=dbox2.git;a=commitdiff;h=e5d7398a4b2d3c520d949e53bbf7667a481e9690
> 
> 2. MC44S80x tuner driver:
> 
> http://git.bocc.de/cgi-bin/gitweb.cgi?p=dbox2.git;a=blob;f=drivers/media/common/tuners/mc44s80x.c;h=b8dd335e64b03b8544b4c95e2d7f3dbd968078a0;hb=4bde668b4eca90f8bdcc5916dfc88c115a3dfd20
> http://git.bocc.de/cgi-bin/gitweb.cgi?p=dbox2.git;a=blob;f=drivers/media/common/tuners/mc44s80x.h;h=c6e76da6bf51163c90f0ead259c0e54d4f637671;hb=4bde668b4eca90f8bdcc5916dfc88c115a3dfd20
> http://git.bocc.de/cgi-bin/gitweb.cgi?p=dbox2.git;a=blob;f=drivers/media/common/tuners/mc44s80x_reg.h;h=299c1be9a80a3777fb46f65d6070965de9754787;hb=4bde668b4eca90f8bdcc5916dfc88c115a3dfd20

Finally managed to try your version. It works, with no apparent issue.

Scanning is OK, tuning is OK.
I can't test signals below 600MHz at the moment, but I will try (possibly VHF too)
in a couple of days, just to be sure about the frequency handling code.
Also tried removing the USB stick while playing a stream; the devices
were correctly removed when the user space apps closed them.

In my (user) opinion this driver is ready to be merged.

I actually fixed some trivial compilation issues in the driver.

--- a/linux/drivers/media/common/tuners/mc44s80x.c    2009-01-05 12:38:11.000000000 +0100
+++ b/linux/drivers/media/common/tuners/mc44s80x.c 2009-01-05 16:12:59.000000000 +0100
@@ -470,12 +470,12 @@

        mc44s80x_set_power(state, 0); /* disable powerdown */
        printk(KERN_WARNING "mc44s80x: MC44S80x get Device ID\n");
-       err = i2c_transfer(state->i2c, &msg, 1);
+       err = i2c_transfer(state->i2c, msg1, 1);
        if (err != 1) {
                printk(KERN_WARNING "mc44s80x: Write error\n");
                goto exit;
        }
-       err = i2c_transfer(state->i2c, &msg, 1);
+       err = i2c_transfer(state->i2c, msg2, 1);
        if (err != 1) {
                printk(KERN_WARNING "mc44s80x: Read error, Reg=[0x%02x]\n",
                       TUNER_ADDR + 1);
@@ -495,7 +495,7 @@
        return 0;
 unk:
        printk(KERN_WARNING "mc44s80x: Chip with unknown Revision ID "
-              "(0x%02x)\n", __func__, id);
+              "(0x%02x)\n", id);
        goto out;
 exit:
        if (fe->ops.i2c_gate_ctrl)
@@ -512,7 +512,7 @@
        int err = 0;

        printk(KERN_WARNING "mc44s80x: Trying to attach to Bus @ 0x%p\n", i2c);
-       state = kzalloc(sizeof(struct mc44s80x_state), GFP_KERNEL));
+       state = kzalloc(sizeof(struct mc44s80x_state), GFP_KERNEL);
        if (state == NULL) {
                err = -ENOMEM;
                goto exit;

> Thanks,
> Jochen

Thanks to you.

-- 
   Roberto Ragusa    mail at robertoragusa.it

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

Re: [linux-dvb] MC44S803 frontend (it works)

[Detlef Rohde]

Hi Roberto,
tnx for doing your test! As a Linux-newbie I better wait now until I can 
use a merged driver since I had bad experiences with former trys i.e. 
OS-crashes. Hopefully one Jochen or somebody else can soon do the rest. 
Meanwhile I am experimenting with a WXP-Pro VM running on  my Ubuntu 
Intrepid Installation. Will try the native Terratec-SW on this machine.
Best regards,
Detlef

Roberto Ragusa schrieb:
> (to both linux-dvb and linux-media)
>
> Jochen Friedrich wrote:
>   
>> Hi Roberto,
>>
>>     
>>> Is there any plan to include this frontend in mainline kernels?
>>> I used to run this driver months ago and it was working well.
>>>       
>> The reason is the huge memory footprint due to the included frequency table.
>> I worked a bit on the driver to get rid of this table. Could you try this version:
>>
>> 1. Patch for AF9015:
>>
>> http://git.bocc.de/cgi-bin/gitweb.cgi?p=dbox2.git;a=commitdiff;h=e5d7398a4b2d3c520d949e53bbf7667a481e9690
>>
>> 2. MC44S80x tuner driver:
>>
>> http://git.bocc.de/cgi-bin/gitweb.cgi?p=dbox2.git;a=blob;f=drivers/media/common/tuners/mc44s80x.c;h=b8dd335e64b03b8544b4c95e2d7f3dbd968078a0;hb=4bde668b4eca90f8bdcc5916dfc88c115a3dfd20
>> http://git.bocc.de/cgi-bin/gitweb.cgi?p=dbox2.git;a=blob;f=drivers/media/common/tuners/mc44s80x.h;h=c6e76da6bf51163c90f0ead259c0e54d4f637671;hb=4bde668b4eca90f8bdcc5916dfc88c115a3dfd20
>> http://git.bocc.de/cgi-bin/gitweb.cgi?p=dbox2.git;a=blob;f=drivers/media/common/tuners/mc44s80x_reg.h;h=299c1be9a80a3777fb46f65d6070965de9754787;hb=4bde668b4eca90f8bdcc5916dfc88c115a3dfd20
>>     
>
> Finally managed to try your version. It works, with no apparent issue.
>
> Scanning is OK, tuning is OK.
> I can't test signals below 600MHz at the moment, but I will try (possibly VHF too)
> in a couple of days, just to be sure about the frequency handling code.
> Also tried removing the USB stick while playing a stream; the devices
> were correctly removed when the user space apps closed them.
>
> In my (user) opinion this driver is ready to be merged.
>
> I actually fixed some trivial compilation issues in the driver.
>
> --- a/linux/drivers/media/common/tuners/mc44s80x.c    2009-01-05 12:38:11.000000000 +0100
> +++ b/linux/drivers/media/common/tuners/mc44s80x.c 2009-01-05 16:12:59.000000000 +0100
> @@ -470,12 +470,12 @@
>
>         mc44s80x_set_power(state, 0); /* disable powerdown */
>         printk(KERN_WARNING "mc44s80x: MC44S80x get Device ID\n");
> -       err = i2c_transfer(state->i2c, &msg, 1);
> +       err = i2c_transfer(state->i2c, msg1, 1);
>         if (err != 1) {
>                 printk(KERN_WARNING "mc44s80x: Write error\n");
>                 goto exit;
>         }
> -       err = i2c_transfer(state->i2c, &msg, 1);
> +       err = i2c_transfer(state->i2c, msg2, 1);
>         if (err != 1) {
>                 printk(KERN_WARNING "mc44s80x: Read error, Reg=[0x%02x]\n",
>                        TUNER_ADDR + 1);
> @@ -495,7 +495,7 @@
>         return 0;
>  unk:
>         printk(KERN_WARNING "mc44s80x: Chip with unknown Revision ID "
> -              "(0x%02x)\n", __func__, id);
> +              "(0x%02x)\n", id);
>         goto out;
>  exit:
>         if (fe->ops.i2c_gate_ctrl)
> @@ -512,7 +512,7 @@
>         int err = 0;
>
>         printk(KERN_WARNING "mc44s80x: Trying to attach to Bus @ 0x%p\n", i2c);
> -       state = kzalloc(sizeof(struct mc44s80x_state), GFP_KERNEL));
> +       state = kzalloc(sizeof(struct mc44s80x_state), GFP_KERNEL);
>         if (state == NULL) {
>                 err = -ENOMEM;
>                 goto exit;
>
>   
>> Thanks,
>> Jochen
>>     
>
> Thanks to you.
>
>   


-- 
Dipl.-Ing. Detlef Rohde
Titiseestr. 12
D-13469 Berlin
Phone: +4930 4021731
A.R.S.: DL7IY



Roberto Ragusa schrieb:
> (to both linux-dvb and linux-media)
>
> Jochen Friedrich wrote:
>   
>> Hi Roberto,
>>
>>     
>>> Is there any plan to include this frontend in mainline kernels?
>>> I used to run this driver months ago and it was working well.
>>>       
>> The reason is the huge memory footprint due to the included frequency table.
>> I worked a bit on the driver to get rid of this table. Could you try this version:
>>
>> 1. Patch for AF9015:
>>
>> http://git.bocc.de/cgi-bin/gitweb.cgi?p=dbox2.git;a=commitdiff;h=e5d7398a4b2d3c520d949e53bbf7667a481e9690
>>
>> 2. MC44S80x tuner driver:
>>
>> http://git.bocc.de/cgi-bin/gitweb.cgi?p=dbox2.git;a=blob;f=drivers/media/common/tuners/mc44s80x.c;h=b8dd335e64b03b8544b4c95e2d7f3dbd968078a0;hb=4bde668b4eca90f8bdcc5916dfc88c115a3dfd20
>> http://git.bocc.de/cgi-bin/gitweb.cgi?p=dbox2.git;a=blob;f=drivers/media/common/tuners/mc44s80x.h;h=c6e76da6bf51163c90f0ead259c0e54d4f637671;hb=4bde668b4eca90f8bdcc5916dfc88c115a3dfd20
>> http://git.bocc.de/cgi-bin/gitweb.cgi?p=dbox2.git;a=blob;f=drivers/media/common/tuners/mc44s80x_reg.h;h=299c1be9a80a3777fb46f65d6070965de9754787;hb=4bde668b4eca90f8bdcc5916dfc88c115a3dfd20
>>     
>
> Finally managed to try your version. It works, with no apparent issue.
>
> Scanning is OK, tuning is OK.
> I can't test signals below 600MHz at the moment, but I will try (possibly VHF too)
> in a couple of days, just to be sure about the frequency handling code.
> Also tried removing the USB stick while playing a stream; the devices
> were correctly removed when the user space apps closed them.
>
> In my (user) opinion this driver is ready to be merged.
>
> I actually fixed some trivial compilation issues in the driver.
>
> --- a/linux/drivers/media/common/tuners/mc44s80x.c    2009-01-05 12:38:11.000000000 +0100
> +++ b/linux/drivers/media/common/tuners/mc44s80x.c 2009-01-05 16:12:59.000000000 +0100
> @@ -470,12 +470,12 @@
>
>         mc44s80x_set_power(state, 0); /* disable powerdown */
>         printk(KERN_WARNING "mc44s80x: MC44S80x get Device ID\n");
> -       err = i2c_transfer(state->i2c, &msg, 1);
> +       err = i2c_transfer(state->i2c, msg1, 1);
>         if (err != 1) {
>                 printk(KERN_WARNING "mc44s80x: Write error\n");
>                 goto exit;
>         }
> -       err = i2c_transfer(state->i2c, &msg, 1);
> +       err = i2c_transfer(state->i2c, msg2, 1);
>         if (err != 1) {
>                 printk(KERN_WARNING "mc44s80x: Read error, Reg=[0x%02x]\n",
>                        TUNER_ADDR + 1);
> @@ -495,7 +495,7 @@
>         return 0;
>  unk:
>         printk(KERN_WARNING "mc44s80x: Chip with unknown Revision ID "
> -              "(0x%02x)\n", __func__, id);
> +              "(0x%02x)\n", id);
>         goto out;
>  exit:
>         if (fe->ops.i2c_gate_ctrl)
> @@ -512,7 +512,7 @@
>         int err = 0;
>
>         printk(KERN_WARNING "mc44s80x: Trying to attach to Bus @ 0x%p\n", i2c);
> -       state = kzalloc(sizeof(struct mc44s80x_state), GFP_KERNEL));
> +       state = kzalloc(sizeof(struct mc44s80x_state), GFP_KERNEL);
>         if (state == NULL) {
>                 err = -ENOMEM;
>                 goto exit;
>
>   
>> Thanks,
>> Jochen
>>     
>
> Thanks to you.
>
>   


-- 
Dipl.-Ing. Detlef Rohde
Titiseestr. 12
D-13469 Berlin
Phone: +4930 4021731
A.R.S.: DL7IY


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

Re: [linux-dvb] MC44S803 frontend (it works)

[Luís Silva]

Hi.
> Finally managed to try your version. It works, with no apparent issue.
Thank you all for this good work. Any ideas as to when will these files hit 
the mercurial repos at linuxtv.org?
-- 
Luís A. C. Silva
lacsilva@gmail.com

_______________________________________________
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] MC44S803 frontend (it works)

[Roberto Ragusa]

Luís Silva wrote:
> Hi.

>> Finally managed to try your version. It works, with no apparent issue.

> Thank you all for this good work. Any ideas as to when will these files hit 
> the mercurial repos at linuxtv.org?

That is not under my control.

I hope someone will route this driver into official trees.

I can also add that additional tests on VHF frequencies
have been successful too.

Best regards.

-- 
   Roberto Ragusa    mail at robertoragusa.it

Re: [linux-dvb] MC44S803 frontend (it works)

[Jochen Friedrich]

Hi Roberto,

>> Thank you all for this good work. Any ideas as to when will these files hit 
>> the mercurial repos at linuxtv.org?
> 
> That is not under my control.
> I hope someone will route this driver into official trees.

As the tuner driver currently is only used with AF9015 frontends, I hope Antti will pick this one up.
I can resubmit with a Signed-off-by if required.

> I can also add that additional tests on VHF frequencies
> have been successful too.

Cool.

Thanks,
Jochen

Re: [linux-dvb] MC44S803 frontend (it works)

[Antti Palosaari]

Jochen Friedrich wrote:
> Hi Roberto,
> 
>>> Thank you all for this good work. Any ideas as to when will these files hit 
>>> the mercurial repos at linuxtv.org?
>> That is not under my control.
>> I hope someone will route this driver into official trees.
> 
> As the tuner driver currently is only used with AF9015 frontends, I hope Antti will pick this one up.
> I can resubmit with a Signed-off-by if required.

Could you explain for changes af9015_i2c_xfer() done? Is it for case I2C 
READ coming from MC44S803 but tuner does not implement read at all? Is 
it really needed?

Maybe I can move MC44S803 and needed AF9015 changes to my devel tree at 
linuxtv.org... But that does not change problem that tuner is not still 
in v4l-dvb-master nor coming for Kernel before Manu will pull it.

>> I can also add that additional tests on VHF frequencies
>> have been successful too.
> 
> Cool.
> 
> Thanks,
> Jochen

regards
Antti
-- 
http://palosaari.fi/

Re: [linux-dvb] MC44S803 frontend (it works)

[Antti Palosaari]

Manu,
looks like your MC44S803 driver is in very good shape with Jochen's 
changes. When you are planning to push it to the v4l-dvb or Kernel?

regards
Antti
-- 
http://palosaari.fi/

Re: [linux-dvb] MC44S803 frontend (it works)

[Jochen Friedrich]

Hi Antti,

> Could you explain for changes af9015_i2c_xfer() done? Is it for case I2C 
> READ coming from MC44S803 but tuner does not implement read at all? Is 
> it really needed?

Yes. Currently, MC44S803 uses a READ in mc44s80x_get_devid() to check the ID register.
According to the spec from freescale, a READ needs to be a seperate I2c transaction,
because the STOP bit is used to latch the address registers. That's the reason why a
dedicated READ support is needed (most other tuners use a WRITE / READ combined I2c
transaction instead).

> Maybe I can move MC44S803 and needed AF9015 changes to my devel tree at 
> linuxtv.org... But that does not change problem that tuner is not still 
> in v4l-dvb-master nor coming for Kernel before Manu will pull it.

Unfortunately, i didn't see any comments from Manu yet...

Thanks,
Jochen

Re: [linux-dvb] MC44S803 frontend (it works)

[Antti Palosaari]

Jochen Friedrich wrote:
> Hi Antti,
> 
>> Could you explain for changes af9015_i2c_xfer() done? Is it for case I2C 
>> READ coming from MC44S803 but tuner does not implement read at all? Is 
>> it really needed?
> 
> Yes. Currently, MC44S803 uses a READ in mc44s80x_get_devid() to check the ID register.
> According to the spec from freescale, a READ needs to be a seperate I2c transaction,
> because the STOP bit is used to latch the address registers. That's the reason why a
> dedicated READ support is needed (most other tuners use a WRITE / READ combined I2c
> transaction instead).

OK. Maybe comment to the code is required, but I can add it. I am 
willing to see, if you have, usb-sniffs for tuner read and write.

> 
>> Maybe I can move MC44S803 and needed AF9015 changes to my devel tree at 
>> linuxtv.org... But that does not change problem that tuner is not still 
>> in v4l-dvb-master nor coming for Kernel before Manu will pull it.
> 
> Unfortunately, i didn't see any comments from Manu yet...

we will waiting...

> 
> Thanks,
> Jochen

regards
Antti
-- 
http://palosaari.fi/

Re: [linux-dvb] MC44S803 frontend (it works)

[Jochen Friedrich]

Hi Antti,

>> Yes. Currently, MC44S803 uses a READ in mc44s80x_get_devid() to check the ID register.
>> According to the spec from freescale, a READ needs to be a seperate I2c transaction,
>> because the STOP bit is used to latch the address registers. That's the reason why a
>> dedicated READ support is needed (most other tuners use a WRITE / READ combined I2c
>> transaction instead).
> 
> OK. Maybe comment to the code is required, but I can add it. I am 
> willing to see, if you have, usb-sniffs for tuner read and write.

there is documentation for this tuner at the freescale web page:

http://www.freescale.com/files/rf_if/doc/data_sheet/MC44S803.pdf?pspll=1

>From page 8:

I2C OPERATION
The same 24-bit shift register is used to shift data in and
out of the part. The input data stream is clocked in on the
rising edge of SCLK into the shift register with the MSB first.
The IC Address and R/W bit are sent first. This allows the IC
to determine if it is the device that is being communicated
with. After that, 24 bits are clocked in to control the IC. If less
than 24 bits are required, then 16 or 8 bits could be used. In
other words, commands can be sent in 1, 2, or 3 byte
increments depending on the requirements for the particular
control register you are writing to. Data can be read back from
the IC in 1, 2, or 3 byte increments also. The Master controls
the clock line, whether writing to the part or reading from it.
After each byte that is sent, the device that receives it sends
an acknowledge bit. The output data stream is clocked out of
the shift register on the falling edge of SCLK and valid on the
rising edge, with the MSB first. The data stored in the shift
register is loaded into one of the appropriate registers after
the Stop Condition is sent. The 4 LSBs are the Control
Register Address Bits.

This means a READ needs to be implemented using 2 transactions.
One transaction to write the address and one to read the value back.

The read operations are specified on pages 22 and 23:

There are 16 Data Registers that can be read back from
the IC. The 1011 Control Register (Data Register Address)
controls which of these Data Registers will be read out of the
IC during the next read operation. To select the desired Data
Register this address register first needs to be set. Then on
the next read operation the desired data will be available.

Currently the driver only reads the ID bits to verify it's talking to a 
MC44S80x chip.

The READ operation was modeled after the "official" driver from TerraTec:

ftp://ftp.terratec.net/Receiver/Cinergy_T_USB_XE/Update/Cinergy_T_USB_XE_MKII_Drv_Linux.zip

>>> Maybe I can move MC44S803 and needed AF9015 changes to my devel tree at 
>>> linuxtv.org... But that does not change problem that tuner is not still 
>>> in v4l-dvb-master nor coming for Kernel before Manu will pull it.
>> Unfortunately, i didn't see any comments from Manu yet...
> 
> we will waiting...

OK, we'll do.

Thanks,
Jochen