Re: [RFC] Anticipating lirc breakage
On Thu, 9 Jul 2009 11:44:46 -0400, Jarod Wilson wrote: > On Tuesday 07 April 2009 08:36:17 Jean Delvare wrote: > > > So, let's just forget the workarounds and go straight to the point: focus > > > on > > > merging lirc-i2c drivers. > > > > Will this happen next week? I fear not. Which is why I can't wait for > > it. And anyway, in order to merge the lirc_i2c driver, it must be > > turned into a new-style I2C driver first, so bridge drivers must be > > prepared for this, which is exactly what my patches are doing. > > For what its worth, I fixed up lirc_i2c a few days ago, and now have > it working just fine with my pvr-250 under 2.6.31-rc2. Excellent. Apparently you did not hit any problem, but if you ever do need help for the i2c side of things, just ask and I'll be happy to help. > Real Soon Now (I swear), I'm hoping to get up another head of steam > for submitting lirc upstream. Multiple drivers have received a bunch > of love in the past few weeks, so I think we're in a pretty good state > to have another go at it... > -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Anticipating lirc breakage
On Thu, Jul 9, 2009 at 11:44 AM, Jarod Wilson wrote: > On Tuesday 07 April 2009 08:36:17 Jean Delvare wrote: >> > So, let's just forget the workarounds and go straight to the point: focus >> > on >> > merging lirc-i2c drivers. >> >> Will this happen next week? I fear not. Which is why I can't wait for >> it. And anyway, in order to merge the lirc_i2c driver, it must be >> turned into a new-style I2C driver first, so bridge drivers must be >> prepared for this, which is exactly what my patches are doing. > > For what its worth, I fixed up lirc_i2c a few days ago, and now have > it working just fine with my pvr-250 under 2.6.31-rc2. > > Real Soon Now (I swear), I'm hoping to get up another head of steam > for submitting lirc upstream. Multiple drivers have received a bunch > of love in the past few weeks, so I think we're in a pretty good state > to have another go at it... > > -- > Jarod Wilson > ja...@redhat.com Jarod, This is excellent news. Keep up the good work! Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Anticipating lirc breakage
On Tuesday 07 April 2009 08:36:17 Jean Delvare wrote: > > So, let's just forget the workarounds and go straight to the point: focus on > > merging lirc-i2c drivers. > > Will this happen next week? I fear not. Which is why I can't wait for > it. And anyway, in order to merge the lirc_i2c driver, it must be > turned into a new-style I2C driver first, so bridge drivers must be > prepared for this, which is exactly what my patches are doing. For what its worth, I fixed up lirc_i2c a few days ago, and now have it working just fine with my pvr-250 under 2.6.31-rc2. Real Soon Now (I swear), I'm hoping to get up another head of steam for submitting lirc upstream. Multiple drivers have received a bunch of love in the past few weeks, so I think we're in a pretty good state to have another go at it... -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Anticipating lirc breakage
On Tue, 7 Apr 2009, Jean Delvare wrote: > I'll rework my patch set to implement strategy #1 and post it when I'm > done. As far as I can see this should be very similar to my original > attempt, with just "ir_video" devices instead or "ir-kbd" devices, and > also fixes for the minor issues that have been reported. > > Do you want me to include pvrusb2 in my new patch set, or should I still > leave it to you? If you were to include pvrusb2, you would also need the changeset which expands the "IR scheme" handling to make it possible to correctly select when to bind the driver. But Mauro hasn't pulled that so you can't easily build on it right now. And as I understand it, the only real impact in the second changeset in the pending series is just the name of the module (i.e. change "ir-kbd" to "ir_video"). It's extra work for you to do this. So just let me deal with it. If my understanding above is correct, I'll just fix the second patch and the pvrusb2 driver should be ready to go for this. -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Anticipating lirc breakage
Hi Mauro, On Tue, 7 Apr 2009 07:50:29 -0300, Mauro Carvalho Chehab wrote: > On Tue, 7 Apr 2009 12:02:09 +0200 > Jean Delvare wrote: > > > Hi Mike, > > > > Glad to see we all mostly agree on what to do now. I'll still answer > > some of your questions below, to clarify things even more. > > I don't understand why you are preferring to do some workaround, spending > energy to add hooks at the kernel drivers to support out-of-tree drivers, > instead of working to provide the proper solution. What I am proposing isn't a workaround, it is a fundamental part of the solution, and it is even the approach which requires the minimum amount of changes. This is as straightforward a solution as you can hope for. > I'm against adding any hook on kernel to support an out-of-tree driver. I do not plan to add any hook. The plan is to instantiate all IR devices we know are present, and let ir-kbd-i2c bind to the ones it supports. The fact that another out-of-tree driver may optionally bind to these devices is a side effect. I would love to say "let's just ignore lirc altogether", however 1* I don't think it makes any sense to break user systems when it is trivial for us to not break them and 2* I don't think it is smart to be rude with lirc developers are the exact moment they decide to attempt to merge their drivers in the kernel tree. > From what I understood, lirc developers are interested on merging lirc > drivers. > We all agree that ir-kbd-i2c doesn't address all i2c IR's, and that lirc > drivers provide support for the remaining ones. Yes, this is my understanding as well. > So, let's just forget the workarounds and go straight to the point: focus on > merging lirc-i2c drivers. Will this happen next week? I fear not. Which is why I can't wait for it. And anyway, in order to merge the lirc_i2c driver, it must be turned into a new-style I2C driver first, so bridge drivers must be prepared for this, which is _exactly_ what my patches are doing. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Anticipating lirc breakage
On Tue, 7 Apr 2009 12:02:09 +0200 Jean Delvare wrote: > Hi Mike, > > Glad to see we all mostly agree on what to do now. I'll still answer > some of your questions below, to clarify things even more. I don't understand why you are preferring to do some workaround, spending energy to add hooks at the kernel drivers to support out-of-tree drivers, instead of working to provide the proper solution. I'm against adding any hook on kernel to support an out-of-tree driver. >From what I understood, lirc developers are interested on merging lirc drivers. We all agree that ir-kbd-i2c doesn't address all i2c IR's, and that lirc drivers provide support for the remaining ones. So, let's just forget the workarounds and go straight to the point: focus on merging lirc-i2c drivers. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Anticipating lirc breakage
Hi Mike,
Glad to see we all mostly agree on what to do now. I'll still answer
some of your questions below, to clarify things even more.
On Tue, 7 Apr 2009 01:19:02 -0500 (CDT), Mike Isely wrote:
> On Mon, 6 Apr 2009, 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 don't know if it will be possible or even make sense to merge
> ir-kbd-i2c and lirc_i2c. For example, if lirc_i2c is effectively a
> complete superset of ir-kbd-i2c, then what's there to merge? Seems to
> be in the end that ir-kbd-i2c will eventually go away, but certainly not
> until the question of merging lirc into the kernel is settled.
I consider "lirc_i2c replaces ir-kbd-i2c" a valid implementation of
"merge ir-kbd-i2c and lirc_i2c into a single driver" ;) I really don't
care about the implementation details, as long as the outcome is that
there is a single driver for every type of I2C-based IR receiver
device, because then we can let udev load these drivers and the user
experience will be much better.
> For now
> they must both continue to exist and so there must really be a way to
> ensure that the user can somehow control which is to be used - in cases
> where a legitimate choice exists.
I agree.
> > 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.) We would also need to ensure that
> > ir-kbd-i2c doesn't crash when it sees a device at an address it doesn't
> > support.
>
> I think #2 only makes sense if there is a clear defined convention for
> allowing the override of the desired name from userspace. For example,
> "modprobe pvrusb2 ir_driver=lirc_i2c". I *definitely* would not want
> the bridge driver to force the user to one alternative in cases where
> two legitimate choices exist (which is what I first saw from your patch
> to the pvrusb2 driver and is partly why I nacked it so quickly). If #2
> results in bridge drivers forcing the user to one IR driver, then I
> would not want to go that route.
I agree as well... which means that #2 would require extra work on
bridge drivers, which would all be reverted once lirc_i2c is merged.
> I think #1 is easier, but it does leave one with the situation again
> where loading ir_kbd_i2c again will cause it to bind to all bridge
> drivers looking for, say "ir_video" when perhaps that's not the right
> answer for a particular driver. (Right? I'm not sure if I totally
> understand that aspect yet.)
Yes, you are right.
> I only point this out because it was
> considered to be one of the flaws of the previous scheme. However with
> that said, #1 is certainly no worse than before.
#1 is indeed exactly the same functionally-wise as the current
situation. It has the same limitations, but is also the easiest to
implement. And the limitations will go away later when lirc_i2c is
merged.
> Rea
Re: [RFC] Anticipating lirc breakage
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Anticipating lirc breakage
On Mon, 6 Apr 2009, Jean Delvare wrote: > Hi all, > > In the light of recent discussions and planed changes to the i2c > subsystem and the ir-kbd-i2c driver, I will try to summarize the > situation and make some proposals. Note that I am really not sure what > we want to do, so this is a true request for opinions. > > First of all, the original reason for these changes is that I want to > get rid of the legacy i2c binding model. As far as IR support is > concerned, this means two things: > * The ir-kbd-i2c driver must be converted to the new i2c binding model. > I have been working on this already. > * The removal of the legacy model will break lirc_i2c and possibly > other lirc drivers. These will have to be converted to the new i2c > binding model as well. > > While discussing my changes to ir-kbd-i2c, I received objections that > these would adversely affect lirc users, and proposals were made to > work around this problem, either by the means of module parameters, or > by adding per-card logic in the bridge drivers. While this temporarily > addresses the conflict with lirc, I feel like it is wasted energy > because the second point is much more critical for lirc users. I'm > going to remove the legacy i2c model pretty soon now and lirc_i2c and > friends will have to be updated. This means two things: It wasn't really wasting that much energy for me. The change was simple and now that you made me look at this issue more closely, I realize I need to do something more serious in the pvrusb2 driver anyway to enable better control over which IR receiver(s) are to be enabled when the user has multiple devices. So in the end for me at least, it wasn't a waste. > * There is no point in refining the ir-kbd-i2c conversion for users of > the current lirc drivers, because the removal of the legacy i2c model > will break these drivers a lot more anyway. > * We need to come up with a strategy that makes it possible for lirc > modules to still work afterwards. This is not trivial because the new > i2c binding model makes life much harder for rogue/out-of-tree i2c > drivers (note, this is just a side effect, the new model was not > designed with this in mind.) > > The main technical problems I see as far as converting lirc to the new > i2c binding model is concerned are: > * Going the .detect() route is not as flexible as it was beforehand. In > particular, having per-board probed address lists is no longer > possible. It is possible to filter the addresses on a per-board basis > after the fact, but the probes will still be issued for all addresses. > I seem to remember that probing random addresses did cause trouble in > the past on some boards, so I doubt we want to go that route. This is > the reason why I decided to NOT go the .detect() route for ir-kbd-i2c > conversion. > * If we don't use .detect(), the bridge drivers must instantiate the > devices themselves. That's what my ir-kbd-i2c patches do. One > requirement is then that the bridge drivers and the chip drivers agree > on the i2c device name(s). This was true for ir-kbd-i2c, it is true for > lirc as well. Where it becomes difficult is that lirc lives outside of > the kernel, while bridge drivers live inside the kernel. This will make > the changes more difficult to synchronize. Probably a good incentive > for lirc developers to merge their drivers into the kernel tree. > > While I think we all agree that lirc drivers should be merged in the > kernel tree, it is pretty clear that it won't happen tomorrow. And, > more importantly, it won't happen before I get rid of the legacy i2c > binding model. So we need to come up with a design which makes it > possible to keep using out-of-tree lirc drivers. It doesn't need to be > perfect, but it has to somewhat work for now. Yup. Totally agree. > > My initial proposal made bridge drivers create "ir-kbd" [1] I2C devices > for the ir-kbd-i2c driver to use. Mike Isely changed this in the pvrusb2 > bridge driver to only instantiate the devices for boards on which > ir-kbd-i2c is known to work. While this makes sense for the current > situation (lirc_i2c is a legacy i2c driver) it will break as soon as > lirc_i2c is converted to a new-style i2c driver: the converted lirc_i2c > driver will need I2C devices to bind to, and the pvrusb2 driver won't > create them. Right, because we haven't addressed the question of still making possible the choice of which actual driver to load. The change I proposed and implemented (within the pvrusb2 driver) was just a simple low-risk attempt to allow for the status quo to still be possible within the pvrusb2 driver. That will work for _right this moment_, but once you've removed the legacy i2c binding mechanism, there's no longer any status quo to maintain. > > Same goes for cx18 boards, as Andy Walls and myself agreed to not > create I2C devices for the IR receivers, because we know that > ir-kbd-i2c doesn't sup
Re: [RFC] Anticipating lirc breakage
Hi,
Am Montag, den 06.04.2009, 21:20 -0400 schrieb Andy Walls:
> On Mon, 2009-04-06 at 17:44 +0200, Jean Delvare wrote:
> > Hi all,
> >
> > In the light of recent discussions and planed changes to the i2c
> > subsystem and the ir-kbd-i2c driver, I will try to summarize the
> > situation and make some proposals. Note that I am really not sure what
> > we want to do, so this is a true request for opinions.
>
>
>
> > 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.
>
> So strategy #1 gives better flexibility to the user to fix problems at
> the cost of some base complexity to get up and running (maybe). More
> problems, but hopefully all resolvable with moderate effort.
>
> So strategy #2 gives most users a no-brainer experience, but to fix
> problems, steps of dauting complexity or risk for the inexperienced user
> may be needed (maybe). Fewer problems, more effort to resolve the
> problem cases.
>
>
> I don't mind talking a user through a problem with strategy #1 in place.
> All the pieces are there, it's just a matter of troubleshooting the
> configuration: lsmod, dmesg, service lircd stop, modprobe -r lirc_i2c
> lirc_dev,
>
>
> I wouldn't want to talk a user through problems with strategy #2 in
> place:
>
> Me: "Ok, so download the latest v4l-dvb/lirc tarball, edit this string
> in this file, compile, install, unload, reload, and viola!"
>
> User: "I've done all that. It says something about unresolved symbol.
> What does that mean? I'm using
> $DISTRO_OTHER_THAN_ANDYS_PREFERRED_DISTRO..."
>
> Me: (begin attempting to remove the wall with my forehead...)
>
>
> > 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.
just to have mentioned it.
On such remote "systems" not having any chip for it on the receiver side
and generating IRQs on GPIOs good for that, they are at least connected
to the on board clock, even the printing on the chip of the transmitter
side might be washed out intentionally. (Asus PC-39)
Also they are 3.3Volts only on the receiver and you can't find a
replacement on the markets, at least last time I tried.
(if connected, that gpio goes high)
> I suppose this is a bit problematic for micrcontroller chips with
> different controller code images, but slight additions to the name can
> take
Re: [RFC] Anticipating lirc breakage
On Mon, 6 Apr 2009 17:44:48 +0200 Jean Delvare wrote: > Hi all, > > In the light of recent discussions and planed changes to the i2c > subsystem and the ir-kbd-i2c driver, I will try to summarize the > situation and make some proposals. Note that I am really not sure what > we want to do, so this is a true request for opinions. > > First of all, the original reason for these changes is that I want to > get rid of the legacy i2c binding model. As far as IR support is > concerned, this means two things: > * The ir-kbd-i2c driver must be converted to the new i2c binding model. > I have been working on this already. > * The removal of the legacy model will break lirc_i2c and possibly > other lirc drivers. These will have to be converted to the new i2c > binding model as well. > > While discussing my changes to ir-kbd-i2c, I received objections that > these would adversely affect lirc users, and proposals were made to > work around this problem, either by the means of module parameters, or > by adding per-card logic in the bridge drivers. While this temporarily > addresses the conflict with lirc, I feel like it is wasted energy > because the second point is much more critical for lirc users. I'm > going to remove the legacy i2c model pretty soon now and lirc_i2c and > friends will have to be updated. This means two things: > * There is no point in refining the ir-kbd-i2c conversion for users of > the current lirc drivers, because the removal of the legacy i2c model > will break these drivers a lot more anyway. > * We need to come up with a strategy that makes it possible for lirc > modules to still work afterwards. This is not trivial because the new > i2c binding model makes life much harder for rogue/out-of-tree i2c > drivers (note, this is just a side effect, the new model was not > designed with this in mind.) > > The main technical problems I see as far as converting lirc to the new > i2c binding model is concerned are: > * Going the .detect() route is not as flexible as it was beforehand. In > particular, having per-board probed address lists is no longer > possible. It is possible to filter the addresses on a per-board basis > after the fact, but the probes will still be issued for all addresses. > I seem to remember that probing random addresses did cause trouble in > the past on some boards, so I doubt we want to go that route. This is > the reason why I decided to NOT go the .detect() route for ir-kbd-i2c > conversion. > * If we don't use .detect(), the bridge drivers must instantiate the > devices themselves. That's what my ir-kbd-i2c patches do. One > requirement is then that the bridge drivers and the chip drivers agree > on the i2c device name(s). This was true for ir-kbd-i2c, it is true for > lirc as well. Where it becomes difficult is that lirc lives outside of > the kernel, while bridge drivers live inside the kernel. This will make > the changes more difficult to synchronize. Probably a good incentive > for lirc developers to merge their drivers into the kernel tree. > > While I think we all agree that lirc drivers should be merged in the > kernel tree, it is pretty clear that it won't happen tomorrow. And, > more importantly, it won't happen before I get rid of the legacy i2c > binding model. So we need to come up with a design which makes it > possible to keep using out-of-tree lirc drivers. It doesn't need to be > perfect, but it has to somewhat work for now. > > My initial proposal made bridge drivers create "ir-kbd" [1] I2C devices > for the ir-kbd-i2c driver to use. Mike Isely changed this in the pvrusb2 > bridge driver to only instantiate the devices for boards on which > ir-kbd-i2c is known to work. While this makes sense for the current > situation (lirc_i2c is a legacy i2c driver) it will break as soon as > lirc_i2c is converted to a new-style i2c driver: the converted lirc_i2c > driver will need I2C devices to bind to, and the pvrusb2 driver won't > create them. > > Same goes for cx18 boards, as Andy Walls and myself agreed to not > create I2C devices for the IR receivers, because we know that > ir-kbd-i2c doesn't support them. This made sense for the current > situation, but the lirc_i2c conversion will break on these boards. And > the same is also true for all board types where lirc_i2c (or other lirc > modules for I2C IR receivers) support more devices than ir-kbd-i2c > does: if the bridge drivers don't create the I2C devices, lirc_i2c > won't have anything to bind to. > > 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 cu
Re: [RFC] Anticipating lirc breakage
On Mon, 2009-04-06 at 17:44 +0200, Jean Delvare wrote:
> Hi all,
>
> In the light of recent discussions and planed changes to the i2c
> subsystem and the ir-kbd-i2c driver, I will try to summarize the
> situation and make some proposals. Note that I am really not sure what
> we want to do, so this is a true request for opinions.
> 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.
So strategy #1 gives better flexibility to the user to fix problems at
the cost of some base complexity to get up and running (maybe). More
problems, but hopefully all resolvable with moderate effort.
So strategy #2 gives most users a no-brainer experience, but to fix
problems, steps of dauting complexity or risk for the inexperienced user
may be needed (maybe). Fewer problems, more effort to resolve the
problem cases.
I don't mind talking a user through a problem with strategy #1 in place.
All the pieces are there, it's just a matter of troubleshooting the
configuration: lsmod, dmesg, service lircd stop, modprobe -r lirc_i2c
lirc_dev,
I wouldn't want to talk a user through problems with strategy #2 in
place:
Me: "Ok, so download the latest v4l-dvb/lirc tarball, edit this string
in this file, compile, install, unload, reload, and viola!"
User: "I've done all that. It says something about unresolved symbol.
What does that mean? I'm using
$DISTRO_OTHER_THAN_ANDYS_PREFERRED_DISTRO..."
Me: (begin attempting to remove the wall with my forehead...)
> 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. ;] )
> We would also need to ensure that
> ir-kbd-i2c doesn't crash when it sees a device at an address it doesn't
> support.
Yes, because when that module crashes, a short time later one's keyboard
will be unusable. I guess that's a consequence of oopsing in a module
hooked into the input event system.
Regards,
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
[RFC] Anticipating lirc breakage
Hi all, In the light of recent discussions and planed changes to the i2c subsystem and the ir-kbd-i2c driver, I will try to summarize the situation and make some proposals. Note that I am really not sure what we want to do, so this is a true request for opinions. First of all, the original reason for these changes is that I want to get rid of the legacy i2c binding model. As far as IR support is concerned, this means two things: * The ir-kbd-i2c driver must be converted to the new i2c binding model. I have been working on this already. * The removal of the legacy model will break lirc_i2c and possibly other lirc drivers. These will have to be converted to the new i2c binding model as well. While discussing my changes to ir-kbd-i2c, I received objections that these would adversely affect lirc users, and proposals were made to work around this problem, either by the means of module parameters, or by adding per-card logic in the bridge drivers. While this temporarily addresses the conflict with lirc, I feel like it is wasted energy because the second point is much more critical for lirc users. I'm going to remove the legacy i2c model pretty soon now and lirc_i2c and friends will have to be updated. This means two things: * There is no point in refining the ir-kbd-i2c conversion for users of the current lirc drivers, because the removal of the legacy i2c model will break these drivers a lot more anyway. * We need to come up with a strategy that makes it possible for lirc modules to still work afterwards. This is not trivial because the new i2c binding model makes life much harder for rogue/out-of-tree i2c drivers (note, this is just a side effect, the new model was not designed with this in mind.) The main technical problems I see as far as converting lirc to the new i2c binding model is concerned are: * Going the .detect() route is not as flexible as it was beforehand. In particular, having per-board probed address lists is no longer possible. It is possible to filter the addresses on a per-board basis after the fact, but the probes will still be issued for all addresses. I seem to remember that probing random addresses did cause trouble in the past on some boards, so I doubt we want to go that route. This is the reason why I decided to NOT go the .detect() route for ir-kbd-i2c conversion. * If we don't use .detect(), the bridge drivers must instantiate the devices themselves. That's what my ir-kbd-i2c patches do. One requirement is then that the bridge drivers and the chip drivers agree on the i2c device name(s). This was true for ir-kbd-i2c, it is true for lirc as well. Where it becomes difficult is that lirc lives outside of the kernel, while bridge drivers live inside the kernel. This will make the changes more difficult to synchronize. Probably a good incentive for lirc developers to merge their drivers into the kernel tree. While I think we all agree that lirc drivers should be merged in the kernel tree, it is pretty clear that it won't happen tomorrow. And, more importantly, it won't happen before I get rid of the legacy i2c binding model. So we need to come up with a design which makes it possible to keep using out-of-tree lirc drivers. It doesn't need to be perfect, but it has to somewhat work for now. My initial proposal made bridge drivers create "ir-kbd" [1] I2C devices for the ir-kbd-i2c driver to use. Mike Isely changed this in the pvrusb2 bridge driver to only instantiate the devices for boards on which ir-kbd-i2c is known to work. While this makes sense for the current situation (lirc_i2c is a legacy i2c driver) it will break as soon as lirc_i2c is converted to a new-style i2c driver: the converted lirc_i2c driver will need I2C devices to bind to, and the pvrusb2 driver won't create them. Same goes for cx18 boards, as Andy Walls and myself agreed to not create I2C devices for the IR receivers, because we know that ir-kbd-i2c doesn't support them. This made sense for the current situation, but the lirc_i2c conversion will break on these boards. And the same is also true for all board types where lirc_i2c (or other lirc modules for I2C IR receivers) support more devices than ir-kbd-i2c does: if the bridge drivers don't create the I2C devices, lirc_i2c won't have anything to bind to. 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 w
