From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: "Frank Schäfer" <fschaefer.oss@googlemail.com>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: [PATCH v2 06/11] em28xx: make sure we are at i2c bus A when calling em28xx_i2c_register()
Date: Mon, 4 Mar 2013 23:31:43 -0300 [thread overview]
Message-ID: <20130304233143.688cdace@redhat.com> (raw)
In-Reply-To: <5135111B.4010102@googlemail.com>
Em Mon, 04 Mar 2013 22:24:43 +0100
Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:
> Am 04.03.2013 20:14, schrieb Mauro Carvalho Chehab:
> > 3) It doesn't properly address the real issue: a separate I2C
> > register is needed for bus B.
>
> Definitely. :(
> We talked about that at the beginning.
>
> I have spent several ours working on this, but finally gave it up (for
> now), because
> a) it is a very huge change. I started changing/fixing one thing, then I
> noticed that this requires fixing 2 other issues first, which again made
> it necessary to change others and so on...
> The main problem isn't the i2c adapter/bus changes, it's the subdevice
> handling/tracking...
> b) the resulting code has a big overhead and I'm not sure if it is
> justified as long as there is no device yet using both busses in parallel.
>
> Sure, we all like clean code and sooner or later we will likely be
> forced to do it properly.
> Maybe I will come back to it when the webcam stuff is finished.
> But for now (with regards to the eeprom reading), reordering the bus
> setup/configuration calls seems to be the easiest and appropriate
> solution to me.
Hmm... I found it easy to do it ;)
The fact that, currently, on all devices, The first bus has the eeprom[1]
and that all other devices are on the secondary bus makes easy to properly
implementing it with just a few changes. Ok, if/when we start to see
devices mixed, we'll need to add a more complex logic, but for now,
it can be simply done, and em28xx i2c scan can check both buses, with
may help future development.
I'll post some patches tomorrow after testing.
[1] That could be a hardware requirement, as it makes easier for the
device to seek for eeprom data.
Regards,
Mauro
next prev parent reply other threads:[~2013-03-05 2:31 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-03 19:37 [PATCH v2 00/11] em28xx: i2c debugging cleanups and support for newer eeproms Frank Schäfer
2013-03-03 19:37 ` [PATCH v2 01/11] em28xx-i2c: replace printk() with the corresponding em28xx macros Frank Schäfer
2013-03-04 18:09 ` Mauro Carvalho Chehab
2013-03-04 18:27 ` Frank Schäfer
2013-03-04 18:46 ` Mauro Carvalho Chehab
2013-03-03 19:37 ` [PATCH v2 02/11] em28xx-i2c: get rid of the dprintk2 macro Frank Schäfer
2013-03-03 19:37 ` [PATCH v2 03/11] em28xx-i2c: also print debug messages at debug level 1 Frank Schäfer
2013-03-03 19:37 ` [PATCH v2 04/11] em28xx: do not interpret eeprom content if eeprom key is invalid Frank Schäfer
2013-03-03 19:37 ` [PATCH v2 05/11] em28xx: fix eeprom data endianess Frank Schäfer
2013-03-03 19:37 ` [PATCH v2 06/11] em28xx: make sure we are at i2c bus A when calling em28xx_i2c_register() Frank Schäfer
2013-03-04 19:14 ` Mauro Carvalho Chehab
2013-03-04 21:24 ` Frank Schäfer
2013-03-05 2:31 ` Mauro Carvalho Chehab [this message]
2013-03-03 19:37 ` [PATCH v2 07/11] em28xx: add basic support for eeproms with 16 bit address width Frank Schäfer
2013-03-03 19:37 ` [PATCH v2 08/11] em28xx: add helper function for reading data blocks from i2c clients Frank Schäfer
2013-03-03 19:37 ` [PATCH v2 09/11] em28xx: do not store eeprom content permanently Frank Schäfer
2013-03-03 19:37 ` [PATCH v2 10/11] em28xx: extract the device configuration dataset from eeproms with 16 bit address width Frank Schäfer
2013-03-03 19:37 ` [PATCH v2 11/11] em28xx: enable tveeprom for device Hauppauge HVR-930C Frank Schäfer
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=20130304233143.688cdace@redhat.com \
--to=mchehab@redhat.com \
--cc=fschaefer.oss@googlemail.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.