All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: "Ezequiel García" <elezegarcia@gmail.com>
Cc: gregkh <gregkh@linuxfoundation.org>,
	Hans de Goede <hdegoede@redhat.com>,
	Tomas Winkler <tomasw@gmail.com>,
	Mauro Carvalho Chehab <mchehab@infradead.org>,
	linux-media@vger.kernel.org, devel@driverdev.osuosl.org
Subject: Re: A second easycap driver implementation
Date: Wed, 07 Mar 2012 14:17:09 -0300	[thread overview]
Message-ID: <4F579815.2060207@redhat.com> (raw)
In-Reply-To: <CALF0-+W5HwFFnp96sK=agjc07V_GuizrD6k+Eu9b7sQXOW=Ngw@mail.gmail.com>

Em 07-03-2012 13:45, Ezequiel García escreveu:
> On Wed, Mar 7, 2012 at 1:35 PM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
>>
>> Yes, the driver is weird, as it encapsulates the demod code
>> inside it , instead of using the saa7115 driver, that covers most
>> of saa711x devices, including saa7113.
>>
>> Btw, is this driver really needed? The em28xx driver has support
>> for the Easy Cap Capture DC-60 model (I had access to one of those
>> in the past, and I know that the driver works properly).
>>
>> What's the chipset using on your Easycap device?
> 
> Chipset is STK116. I'm not entirely sure but is seems that
> there are to models: DC60 and DC60+.

Hmmm... so there are two different chipsets for DC60.
> 
> Apparently, the former would be using STK1160.
> 
>>
>> If it is not an Empiatech em28xx USB bridge, then it makes sense
>> to have a separate driver for it. Otherwise, it is just easier
>> and better to add support for your device there.
> 
> Ok, I'll take a look at the em28xx driver and also at the saa711x
> to see how would it be possible to add support for this device.

em28xx is a good reference.

The usage of saa711x is simple. All you need to do is to implement
an I2C bus at your easycap driver, load the module, and then, redirect
any demod ioctl call to the I2C bus, like:

static int vidioc_querystd(struct file *file, void *priv, v4l2_std_id *norm)
{
	struct em28xx_fh   *fh  = priv;
	struct em28xx      *dev = fh->dev;
	int                rc;

	rc = check_dev(dev);
	if (rc < 0)
		return rc;

	v4l2_device_call_all(&dev->v4l2_dev, 0, video, querystd, norm);

	return 0;
}


An I2C device has an address that needs to be send through the I2C
bus.

The saa711x devices use one of the I2C addresses below:

static unsigned short saa711x_addrs[] = {
	0x4a >> 1, 0x48 >> 1,   /* SAA7111, SAA7111A and SAA7113 */
	0x42 >> 1, 0x40 >> 1,   /* SAA7114, SAA7115 and SAA7118 */
	I2C_CLIENT_END };

It is not clear, from the easycap code, where the I2C address
is stored:

int write_saa(struct usb_device *p, u16 reg0, u16 set0)
{
	if (!p)
		return -ENODEV;
	SET(p, 0x200, 0x00);
	SET(p, 0x204, reg0);
	SET(p, 0x205, set0);
	SET(p, 0x200, 0x01);
	return wait_i2c(p);
}

int read_saa(struct usb_device *p, u16 reg0)
{
	u8 igot;

	if (!p)
		return -ENODEV;
	SET(p, 0x208, reg0);
	SET(p, 0x200, 0x20);
	if (0 != wait_i2c(p))
		return -1;
	igot = 0;
	GET(p, 0x0209, &igot);
	return igot;
}

Maybe they're stored on some other register, or maybe this device
has the I2C hardcoded (with would be very ugly and unlikely, but
I won't doubt that some vendor might be doing that).

Anyway, if you take a look at cx231xx and tm6000, you'll see that
some I2C bad implementations require a per-address type of logic.

> Perhaps, we'll end up with a separate driver but based on
> some common code.

As it is not an em28xx, a separate implementation for the stk chipset
is required. You should not need to re-invent the wheel for saa711x.
> 
> Thanks,
> Ezequiel.


  reply	other threads:[~2012-03-07 17:17 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-06 21:04 A second easycap driver implementation Ezequiel García
2012-03-06 21:05 ` Ezequiel García
2012-03-07  9:10 ` Hans de Goede
2012-03-07 14:32   ` Ezequiel García
2012-03-07 15:43     ` gregkh
2012-03-07 16:35       ` Mauro Carvalho Chehab
2012-03-07 16:45         ` Ezequiel García
2012-03-07 17:17           ` Mauro Carvalho Chehab [this message]
2012-03-07 20:39             ` Ezequiel García
2012-03-07 20:53               ` Mauro Carvalho Chehab
2012-03-19 22:05             ` Ezequiel García
2012-03-19 22:34               ` Mauro Carvalho Chehab

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=4F579815.2060207@redhat.com \
    --to=mchehab@redhat.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=elezegarcia@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@infradead.org \
    --cc=tomasw@gmail.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.