All of lore.kernel.org
 help / color / mirror / Atom feed
From: Antti Palosaari <crope@iki.fi>
To: Thomas Mair <thomas.mair86@googlemail.com>
Cc: gennarone@gmail.com, linux-media@vger.kernel.org
Subject: Re: RTL28XX driver
Date: Wed, 11 Apr 2012 22:12:07 +0300	[thread overview]
Message-ID: <4F85D787.2050403@iki.fi> (raw)
In-Reply-To: <CAKZ=SG_=7U2QShzq+2HE8SVZvyRpG3rNTsDzwUaso=CG8tXOsg@mail.gmail.com>

On 09.04.2012 15:02, Thomas Mair wrote:
> thanks for your information. I did get in touch with Realtek and they
> provided me with the datasheet for the RTL2832U. So what I will try to
> do is write a demodulator driver for the RTL2832 demod chip following
> the information of the datasheet and the Realtek driver. I will follow
> Antti's RTL2830 driver structure.
>
> For now there is only one question left regarding the testing of the
> drivers. What is the best way to test and debug the drivers. Sould I
> compile the 3.4 kernel and use it, or is it safer to set up a
> structure like the one I already have to test the driver with a stable
> kernel?

I vote for cloning Mauro's latest staging Kernel 3.5 and use it.
http://git.linuxtv.org/media_tree.git/shortlog/refs/heads/staging/for_v3.5


I have some old stubbed drivers that just works for one frequency using 
combination of RTL2832U + FC2580. Also I have rather well commented USB 
sniff from that device. I can sent those if you wish.

As general instruction try following. It is what I usually do and I 
think many other Linux developers too.

1) take USB sniffs. SniffUSB 2.0.
http://www.pcausa.com/Utilities/UsbSnoop/
2) parse those sniffs using parser.pl script
3) log is still too big due to video stream, remove it
sed -e 's/BULK\[00081\].*$/BULK\[00081\] MPEG2 TS packet data removed/g' 
log.org > log.new
4) now you should have small ~100kB sniff, open it in text editor
5) analyze sniff. find out tuner I2C messages, then demod messages, 
usb-controller messages, etc.
6) make python/perl script to generate C-code like write_regs(0xaa, 
0x12); copy paste that code to driver skeleton until it starts working
7) implement all correctly callback per callback until you are fine with 
code. Most important demod callbacks are .set_frontend() and 
.read_status(). Others are not required, I mean .read_snr(), 
.read_ber(), .read_ucblocks() and .read_signal_strength(). IIRC RTL2830 
.read_status() is similar as RTL2832 and it is already working.

You can copy directly from RTL2830 driver these functions as those are 
similar:
rtl2830_wr()
rtl2830_rd()
rtl2830_wr_regs()
rtl2830_rd_regs()
rtl2830_rd_regs() // oops wrong name
rtl2830_rd_reg()
rtl2830_wr_reg_mask()
rtl2830_rd_reg_mask()

Consider also making making routines for access those "virtual" 
registers as RTL2830/RTL2832 uses "virtual" bit based registers over 
real hardware registers. Some extra work but surely easy many things as 
you don't need to play with bits.
Representation can be made like that or make your own model:
#define REGISTER_NAME <reg page(bank)><physical reg><reg bit MSB><reg 
bit LSB>

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

  parent reply	other threads:[~2012-04-11 19:12 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-06  9:11 RTL28XX driver Thomas Mair
2012-04-06  9:36 ` Antti Palosaari
2012-04-07  7:25 ` poma
2012-04-07 14:19 ` Gianluca Gennari
2012-04-09 12:02   ` Thomas Mair
2012-04-09 15:09     ` Gianluca Gennari
2012-04-11 19:12     ` Antti Palosaari [this message]
2012-04-11 21:33       ` Oliver Schinagl
2012-04-11 21:57         ` Antti Palosaari
2012-04-12 12:11           ` Oliver Schinagl
2012-04-12 12:18             ` Thomas Mair
2012-04-12 12:43               ` Oliver Schinagl
2012-04-12 12:54                 ` Thomas Mair
2012-04-12 13:12                   ` Antti Palosaari
2012-04-18 17:18                     ` Thomas Mair
2012-04-18 17:44                       ` Antti Palosaari
2012-04-18 18:20                         ` Thomas Mair
2012-04-18 18:35                           ` Antti Palosaari
2012-04-18 20:00                             ` Antti Palosaari

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F85D787.2050403@iki.fi \
    --to=crope@iki.fi \
    --cc=gennarone@gmail.com \
    --cc=linux-media@vger.kernel.org \
    --cc=thomas.mair86@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.