All of lore.kernel.org
 help / color / mirror / Atom feed
From: Akihiro TSUKADA <tskd08@gmail.com>
To: Antti Palosaari <crope@iki.fi>, linux-media@vger.kernel.org
Cc: mchehab@s-opensource.com
Subject: Re: [PATCH v4] dvb-usb/friio, dvb-usb-v2/gl861: decompose friio and merge with gl861
Date: Wed, 28 Mar 2018 21:37:26 +0900	[thread overview]
Message-ID: <e861a533-5517-2089-52af-ce720174e3ae@gmail.com> (raw)
In-Reply-To: <f1ce1268-e918-a12f-959e-98644cafb2fe@iki.fi>

Hi,
thanks for the comment.

> You should implement i2c adapter to demod driver and not add such glue
> to that USB-bridge. I mean that "relayed" stuff, i2c communication to
> tuner via demod. I2C-mux may not work I think as there is no gate-style
> multiplexing so you probably need plain i2c adapter. There is few
> examples already on some demod drivers.

I am afraid that the glue is actually necessary.

host - USB -> gl861 - I2C(1) -> tc90522 (addr:X)
                                  \- I2C(2) -> tua6034 (addr:Y)

To send an i2c read message to tua6034,
one has to issue two transactions:
 1. write via I2C(1) to addr:X, [ reg:0xfe, val: Y ]
 2. read via I2C(1) from addr:X, [ out_data0, out_data1, ....]

The problem is that the transaction 1 is (somehow) implemented with
the different USB request than the other i2c transactions on I2C(1).
(this is confirmed by a packet capture on Windows box).

Although tc90522 already creats the i2c adapter for I2C(2),
tc90522 cannot know/control the USB implementation of I2C(1),
only the bridge driver can do this.

regards,
Akihiro

  reply	other threads:[~2018-03-28 12:37 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-27 17:47 [PATCH v4] dvb-usb/friio, dvb-usb-v2/gl861: decompose friio and merge with gl861 tskd08
2018-03-27 23:46 ` Antti Palosaari
2018-03-28 12:37   ` Akihiro TSUKADA [this message]
2018-03-28 20:44     ` Antti Palosaari
2018-03-30 13:21       ` Akihiro TSUKADA
2018-03-30 17:59         ` Antti Palosaari
2018-03-31 15:30           ` Akihiro TSUKADA
2018-03-28 16:45 ` kbuild test robot

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=e861a533-5517-2089-52af-ce720174e3ae@gmail.com \
    --to=tskd08@gmail.com \
    --cc=crope@iki.fi \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@s-opensource.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.