From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: "Ezequiel García" <elezegarcia@gmail.com>
Cc: Hans de Goede <hdegoede@redhat.com>,
linux-media@vger.kernel.org, devel@driverdev.osuosl.org
Subject: Re: A second easycap driver implementation
Date: Mon, 19 Mar 2012 19:34:11 -0300 [thread overview]
Message-ID: <4F67B463.5080009@redhat.com> (raw)
In-Reply-To: <CALF0-+VovM_ykpyosETH5oBG-iEfxCZpg7yqF4Y4LRH0JW7=Gw@mail.gmail.com>
Em 19-03-2012 19:05, Ezequiel García escreveu:
> Hi Mauro,
>
> On 3/7/12, Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
>>
>> 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 };
>>
>
> I made my easycap driver use saa7115 driver to detect its saa7113 chip.
> It wasn't so hard after some head scratching.
Good!
> The problem is now modprobe is taking too long, mainly because saa7115 does
> some probing.
> I was thinking (since we already discussed deferring stuff to a workqueue):
>
> Would it be problematic (in any fashion) to do add the i2c sub device
>
> v4l2_i2c_new_subdev(&dev->v4l2_dev, &dev->i2c_adap,
> "saa7115_auto", 0, saa711x_addrs);
>
> in a workqueue, (in the same way modules are loaded in workqueues)?
>
> I think not, since we won't call i2c directly, but rather through
> v4l2_device_call_all(), right?
It would likely work. I would add some locking maybe at open or at ioctl
level, to prevent calling the device while the init doesn't finish.
Regards,
Mauro
>
> Thanks,
> Ezequiel.
prev parent reply other threads:[~2012-03-19 22:34 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
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 [this message]
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=4F67B463.5080009@redhat.com \
--to=mchehab@redhat.com \
--cc=devel@driverdev.osuosl.org \
--cc=elezegarcia@gmail.com \
--cc=hdegoede@redhat.com \
--cc=linux-media@vger.kernel.org \
/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.