All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: "Frank Schäfer" <fschaefer.oss@googlemail.com>
Cc: Devin Heitmueller <dheitmueller@kernellabs.com>,
	Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: [PATCH 0/3] em28xx: add support for two buses on em2874 and upper
Date: Mon, 1 Apr 2013 16:22:05 -0300	[thread overview]
Message-ID: <20130401162205.379bda4f@redhat.com> (raw)
In-Reply-To: <5159C05B.10902@googlemail.com>

Em Mon, 01 Apr 2013 19:14:03 +0200
Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:

> Am 18.03.2013 22:22, schrieb Mauro Carvalho Chehab:
> > Em Wed, 06 Mar 2013 18:44:07 +0100
> > Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:
> >
> >> Am 05.03.2013 16:43, schrieb Devin Heitmueller:
> >>> 2013/3/5 Mauro Carvalho Chehab <mchehab@redhat.com>:
> >>>> The em2874 chips and upper have 2 buses. On all known devices, bus 0 is
> >>>> currently used only by eeprom, and bus 1 for the rest. Add support to
> >>>> register both buses.
> >>> Did you add a mutex to ensure that both buses cannot be used at the
> >>> same time?  Because using the bus requires you to toggle a register
> >>> (thus you cannot be using both busses at the same time), you cannot
> >>> rely on the existing i2c adapter lock anymore.
> >>>
> >>> You don't want a situation where something is actively talking on bus
> >>> 0, and then something else tries to talk on bus 1, flips the register
> >>> bit and then the thread talking on bus 0 starts failing.
> >>>
> >>> Devin
> >> Hmm... there are several writes to EM28XX_R06_I2C_CLK in em28xx-dvb...
> >> See hauppauge_hvr930c_init(), terratec_h5_init() and
> >> terratec_htc_stick_init().
> >> These functions are called from em28xx_dvb_init() at module init.
> >> Module init is async, so yes, this is (or could at least become) a
> >> problem...
> >>
> >> I wonder if we can't simply remove all those writes to
> >> EM28XX_R06_I2C_CLK from em28xx-dvb.
> >> This is what the functions are doing:
> >>
> >> hauppauge_hvr930c_init()
> >>     ...
> >>     em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, 0x40);
> >>     msleep(10);
> >>     em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, 0x44);
> >>     msleep(10);
> >>     ... [init sequence for slave at address 0x82]
> >>     em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, 0x44);
> >>     msleep(30);
> >>     em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, 0x45);
> >>     msleep(10);
> >>
> >> terratec_h5_init():
> >>     ...
> >>     em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, 0x40);
> >>     msleep(10);
> >>     em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, 0x45);
> >>     msleep(10);
> >>     ...
> >>
> >> terratec_htc_stick_init()
> >>     ...
> >>     em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, 0x40);
> >>     msleep(10);
> >>     em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, 0x44);
> >>     msleep(10);
> >>     ...
> >>
> >> All three boards are using the following settings:
> >>         .i2c_speed    = EM2874_I2C_SECONDARY_BUS_SELECT |
> >> EM28XX_I2C_CLK_WAIT_ENABLE | EM28XX_I2C_FREQ_400_KHZ = 0x45
> >>
> >> So what these functions are doing is
> >> - switch to bus A and do nothing fo 10ms
> >> - overwrite board settings for reg 0x06 with a local value (clears
> >> EM28XX_I2C_FREQ_400_KHZ permanently for the HTC-Stick !).
> >>
> >> I can test the HVR-930C next week.
> 
> Ok, I finally had the chance to test with a HVR-930C, but it seems my
> device () is different.
> It has no slave device at i2c address 0x82, so I can't test this part.
> Btw, which slave device is this ?
> 
> Removing the temporary switches to bus A makes no difference (as expected).
> 
> > There are some things there on the init sequence that can be
> > cleaned/removed. Those sequences generally comes from observing
> > what the original driver does. While it produces a working driver,
> > in general, it is not optimized and part of the init sequence can
> > be removed.
> 
> Do you want me to send patches to remove these writes ?
> Which i2c speed settings do you suggest for the HVR-930C and the
> HTC-Stick (board settings:
> EM28XX_I2C_FREQ_400_KHZ, code overwrites it with EM28XX_I2C_FREQ_100_KHZ) ?

Sure. The better would be to even remove the hauppauge_hvr930c_init()
function, as this is just a hack, and use the setup via the em28xx-cards
commented entries:

		.tuner_type   = TUNER_XC5000,
		.tuner_addr   = 0x41,
		.dvb_gpio     = hauppauge_930c_digital,
		.tuner_gpio   = hauppauge_930c_gpio,

Regards,
Mauro

  reply	other threads:[~2013-04-01 19:22 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-05 10:55 [PATCH 0/3] em28xx: add support for two buses on em2874 and upper Mauro Carvalho Chehab
2013-03-05 10:55 ` [PATCH 1/3] em28xx: Prepare to support 2 different I2C buses Mauro Carvalho Chehab
2013-03-05 10:55 ` [PATCH 2/3] em28xx: Add a separate config dir for secondary bus Mauro Carvalho Chehab
2013-03-06 16:40   ` Frank Schäfer
2013-03-18 21:22     ` Mauro Carvalho Chehab
2013-03-05 10:55 ` [PATCH 3/3] em28xx: add support for registering multiple i2c buses Mauro Carvalho Chehab
2013-03-06 16:53   ` Frank Schäfer
2013-03-18 22:36     ` Mauro Carvalho Chehab
2013-03-05 15:43 ` [PATCH 0/3] em28xx: add support for two buses on em2874 and upper Devin Heitmueller
2013-03-06 17:44   ` Frank Schäfer
2013-03-18 21:22     ` Mauro Carvalho Chehab
2013-04-01 17:14       ` Frank Schäfer
2013-04-01 19:22         ` Mauro Carvalho Chehab [this message]
2013-04-01 20:39           ` Frank Schäfer
2013-04-01 22:12             ` Mauro Carvalho Chehab
2013-04-01 22:14               ` Mauro Carvalho Chehab
2013-04-02  0:48                 ` Devin Heitmueller
2013-04-02 19:06                   ` Frank Schäfer
2013-04-02 19:02               ` Frank Schäfer
2013-04-02 22:44                 ` Mauro Carvalho Chehab
2013-03-18 21:17   ` 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=20130401162205.379bda4f@redhat.com \
    --to=mchehab@redhat.com \
    --cc=dheitmueller@kernellabs.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.