All of lore.kernel.org
 help / color / mirror / Atom feed
From: Antti Palosaari <crope@iki.fi>
To: Devin Heitmueller <dheitmueller@kernellabs.com>,
	Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: Best way to add subdev that doesn't use I2C or SPI?
Date: Sat, 21 Jun 2014 05:50:18 +0300	[thread overview]
Message-ID: <53A4F2EA.6070600@iki.fi> (raw)
In-Reply-To: <CAGoCfiyeHbYYTSYY_VPEXJ4z8668w6LdjprW1+FbMJCOoCekwA@mail.gmail.com>

Moikka Devin

On 06/21/2014 04:58 AM, Devin Heitmueller wrote:
> Hello,
>
> I'm in the process of adding support for a new video decoder.  However
> in this case it's an IP block on a USB bridge as opposed to the
> typical case which is an I2C device.  Changing registers for the
> subdev is the same mechanism as changing registers in the rest of the
> bridge (a specific region of registers is allocated for the video
> decoder).
>
> Doing a subdev driver seems like the logical approach to keep the
> video decoder related routines separate from the rest of the bridge.
> It also allows the reuse of the code if we find other cases where the
> IP block is present in other devices.  However I'm not really sure
> what the mechanics are for creating a subdev that isn't really an I2C
> device.
>
> I think we've had similar cases with the Conexant parts where the Mako
> was actually a block on the main bridge (i.e. cx23885/7/8, cx231xx).
> But in that case the cx25840 subdev just issues I2C commands and
> leverages the fact that you can talk to the parts over I2C even though
> they're really on-chip.
>
> Are there any other cases today where we have a subdev that uses
> traditional register access routines provided by the bridge driver to
> read/write the video decoder registers?  In this case I would want to
> reuse the register read/write routines provided by the bridge, which
> ultimately are send as USB control messages.
>
> Any suggestions welcome (and in particular if you can point me to an
> example case where this is already being done).
>
> Thanks in advance,
>
> Devin

Abuse I2C bus. If your integrated IP block is later sold as a separate 
chip, there is likely I2C bus used then. If you now abuse I2C it could 
be even possible that no changes at all is then needed or only small fixes.

I have done that few times, not for V4L2 sub-device, but on DVB side. 
For example AF9015/AF9013 and AF9035/AF9033/IT913x.

regards
Antti

-- 
http://palosaari.fi/

  reply	other threads:[~2014-06-21  2:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-21  1:58 Best way to add subdev that doesn't use I2C or SPI? Devin Heitmueller
2014-06-21  2:50 ` Antti Palosaari [this message]
2014-06-22 21:31   ` Mauro Carvalho Chehab
2014-06-21 11:17 ` Andy Walls
2014-06-21 14:17   ` Andy Walls
2014-06-21 20:45   ` Steven Toth

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=53A4F2EA.6070600@iki.fi \
    --to=crope@iki.fi \
    --cc=dheitmueller@kernellabs.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.