Linux Media Controller development
 help / color / mirror / Atom feed
From: Andy Walls <awalls@md.metrocast.net>
To: Mike Isely <isely@isely.net>
Cc: Jarod Wilson <jarod@wilsonet.com>,
	linux-media@vger.kernel.org, Jarod Wilson <jarod@redhat.com>,
	Jean Delvare <khali@linux-fr.org>, Janne Grunau <j@jannau.net>,
	Mauro Carvalho Chehab <mchehab@redhat.com>
Subject: Re: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes
Date: Wed, 19 Jan 2011 08:38:02 -0500	[thread overview]
Message-ID: <1295444282.4317.20.camel@morgan.silverblock.net> (raw)
In-Reply-To: <alpine.DEB.1.10.1101190714570.5396@ivanova.isely.net>

On Wed, 2011-01-19 at 07:20 -0600, Mike Isely wrote:
> On Wed, 19 Jan 2011, Andy Walls wrote:
> 
> > On Wed, 2011-01-19 at 00:20 -0500, Jarod Wilson wrote:
> > 
> > 
> > >  Not working with
> > > lirc_zilog yet, it fails to load, due to an -EIO ret to one of the
> > > i2c_master_send() calls in lirc_zilog during probe of the TX side. Haven't
> > > looked into it any more than that yet.
> > 
> > Well technically lirc_zilog doesn't "probe" anymore.  It relies on the
> > bridge driver telling it the truth.
> 
> The bridge driver (pvrusb2) still does one probe if it's a 24xxx device: 
> It probes 0x71 in order to determine if it is dealing with an MCE 
> variant device.  Hauppauge did not change the USB ID when they released 
> the 24xxx MCE variant (which has the IR blaster, thus the zilog device).  
> The only way to tell the two devices apart is by discovering the 
> existence of the zilog device - and the bridge driver needs to do this 
> in order to properly disable its "emulated" I2C IR receiver which would 
> otherwise be needed for the non-MCE device.
> 
> Based on the discussion here, could that probe be a source of trouble on 
> the 24XXX MCE device?

IMO, No. I think it is needed and just fine.

As I understand it, the rules/guidelines for I2C probing are now
something like this:

1. I2C device driver modules (ir-kbd-i2c, lirc_zilog, etc.) should not
do hardware probes at all.  They are to assume the bridge or platform
drivers verified the I2C slave hardware's existence somehow.

2. Bridge drivers (pvrusb, hdpvr, cx18, ivtv, etc.) should not ask the
I2C subsystem to probe hardware that it knows for sure exists, or knows
for sure does not exist.  Just add the I2C device or not.

3. Bridge drivers should generally ask the I2C subsystem to probe for
hardware that _may_ exist.

4. If the default I2C subsystem hardware probe method doesn't work on a
particular hardware unit, the bridge driver may perform its own hardware
probe or provide a custom hardware probe method to the I2C subsystem.
hdpvr and pvrusb2 currently do the former.


> This probing behavior does not happen for HVR-1950 (or HVR-1900) since 
> there's only one possible IR configuration there.

So the HVR-1950 only has Z8's capable of both Tx and Rx?  No HVR-1950
has an Rx only Z8 unit?

Regards,
Andy




  reply	other threads:[~2011-01-19 13:37 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-16 19:20 [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes Andy Walls
2011-01-17  3:29 ` Andy Walls
2011-01-19  5:20   ` Jarod Wilson
2011-01-19 12:21     ` Andy Walls
2011-01-19 12:40       ` Jean Delvare
2011-01-19 13:24         ` Andy Walls
2011-01-19 13:28           ` Mike Isely
2011-01-19 13:20       ` Mike Isely
2011-01-19 13:38         ` Andy Walls [this message]
2011-01-19 13:50           ` Jean Delvare
2011-01-19 17:12             ` Jarod Wilson
2011-01-19 17:39               ` Jarod Wilson
2011-01-19 17:43               ` Jean Delvare
2011-01-19 20:08                 ` Jarod Wilson
2011-01-20  4:45                   ` Jarod Wilson
2011-01-20  4:52                     ` Jarod Wilson
2011-01-20 13:22                     ` Andy Walls
2011-01-20 21:49                       ` Jarod Wilson
2011-01-21  1:10                         ` Andy Walls
2011-01-21  3:58                           ` Jarod Wilson
2011-01-19 14:17           ` Mike Isely
2011-01-19 16:42         ` Jarod Wilson
2011-01-19 16:57           ` Mike Isely
2011-01-19 17:07             ` Jarod Wilson
2011-01-19 16:08       ` Jarod Wilson
2011-01-19 16:10         ` Devin Heitmueller
2011-01-19 14:59 ` Jean Delvare
2011-01-19 15:09   ` Mike Isely
2011-01-19 15:18     ` Jean Delvare
  -- strict thread matches above, loose matches on Subject: below --
2011-01-19 16:46 Andy Walls

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=1295444282.4317.20.camel@morgan.silverblock.net \
    --to=awalls@md.metrocast.net \
    --cc=isely@isely.net \
    --cc=j@jannau.net \
    --cc=jarod@redhat.com \
    --cc=jarod@wilsonet.com \
    --cc=khali@linux-fr.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox