Hi Andy,
On Mon, 06 Apr 2009 21:20:37 -0400, Andy Walls wrote:
> On Mon, 2009-04-06 at 17:44 +0200, Jean Delvare wrote:
> > The bottom line is that we have to instantiate I2C devices for IR
> > components regardless of the driver which will handle them (ir-kbd-i2c,
> > lirc_i2c or another one). I can think of two different strategies here:
> >
> > 1* Instantiate driver-neutral I2C devices, named for example
> > "ir_video". Let both ir-kbd-i2c and lirc_i2c (and possibly others)
> > bind to them. The first loaded driver gets to bind to the device.
> > This isn't so different from the current situation, the only
> > difference being that the choice of addresses to probe is moved to
> > the bridge drivers. We can even go with separate names for some
> > devices (for example "ir_zilog"), as each I2C driver can list which
> > devices it supports.
> >
> > 2* Let the bridge drivers decide whether ir-kbd-i2c or lirc_i2c
> > should drive any given device, by instantiating I2C devices with
> > different names, for example "ir_kbd" for ir-kbd-i2c and "lirc" for
> > lirc_i2c. This might give better out-of-the-box results for some
> > devices and would make it possible to let the device drivers auto-load.
> > There's a problem though for IR devices which are supported by both
> > ir-kbd-i2c and lirc_i2c: not every user installs lirc, so it's not
> > clear what devices should be created. We could default to "ir_kbd"
> > and switch to "lirc" using a module parameter, as Mike Isely
> > proposed for pvrusb2.
> >
> > I have a clear preference for the first strategy. I feel that creating
> > devices for a specific driver is the wrong way to go, as we will
> > certainly want to merge ir-kbd-i2c and lirc_i2c into a single driver in
> > the future. However, I am not familiar enough with IR receivers to know
> > for sure if the first strategy will work. I would welcome comments on
> > this. Does anyone see a problem with strategy #1? Does anyone see
> > notable advantages in strategy #2?
>
> I have a preference for #1.
>
> Strategy #1 gives flexibility and control for *every* user.
>
> Strategy #2 has better turn-key operation for *most* users.
Note that strategy #1 is also what we have at the moment, incidentally.
> > If we go with strategy #1 then my original patch set is probably very
> > similar to the solution. The only differences would be the name of the
> > I2C devices being created ("ir_video" instead of "ir-kbd") and the list
> > of addresses being probed (we'd need to add the addresses lirc_i2c
> > supports but ir-kbd-i2c does not.)
>
> May I ask, why the virtual chip names like "ir_video"? Almost every I2C
> IR chip should have a unique part number on it. Maybe just use the name
> of the chip as - well - the name of the I2C chip at the address:
> "KS003", "Z8F0811", "PIC64xx", "CX2584x IR", etc. That way it is almost
> unambiguous what the IR chip part is at the I2C address, and also what
> the IR chip driver module needs to support.
>
> I suppose this is a bit problematic for micrcontroller chips with
> different controller code images, but slight additions to the name can
> take care of that: "Z8F0811 Hauppauge", "Z8F0811 Acme".
> ^^^^
> +-- ficticious company
>
> It seems obvious to me. (So there must be something wrong with it. ;] )
No, in theory you are perfectly right, it would be much better to name
devices by their actual name. I decided to go with a virtual name
merely because of the current structure of the ir-kbd-i2c code. I
wanted to make the conversion as direct as possible. But in the future,
adding separate names for specific IR devices would be nice.
As you found out though, this becomes a little bit more complex when
the IR device in question is a generic micro-controller. Not only the
same chip can be used differently as different IR devices, but
virtually the same chip can also be used somewhere else in the kernel
for completely different function. In this case I think it is better to
either suffix the I2C device name to distinguish between
implementations, or go with a plain virtual name right ahead.
Keep in mind that we are relatively free as to what I2C device names we
use. All that matters is uniqueness and relevance. And to stick to the
convention to use only lowercase letters, digits and underscores in the
names.
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
