[IR RC, REGRESSION] Didn't work IR RC

[IR RC, REGRESSION] Didn't work IR RC

[Dmitri Belimov]

Hi All

After rework of the IR subsystem, IR RC no more work in our TV cards.
As I see 
call saa7134_probe_i2c_ir,
  configure i2c
  call i2c_new_device

New i2c device not registred.

The module kbd-i2c-ir loaded after i2c_new_device.

I try to found what happens.

With my best regards, Dmitry.

Re: [IR RC, REGRESSION] Didn't work IR RC

[Andy Walls]

On Mon, 2010-03-01 at 15:36 +0900, Dmitri Belimov wrote:
> Hi All
> 
> After rework of the IR subsystem, IR RC no more work in our TV cards.
> As I see 
> call saa7134_probe_i2c_ir,
>   configure i2c
>   call i2c_new_device
> 
> New i2c device not registred.
> 
> The module kbd-i2c-ir loaded after i2c_new_device.

Jean,

There was also a problem reported with the cx23885 driver's I2C
connected IR by Timothy Lenz:

http://www.spinics.net/lists/linux-media/msg15122.html

The failure mode sounds similar to Dmitri's, but maybe they are
unrelated.

I worked a bit with Timothy on IRC and the remote device fails to be
detected whether ir-kbd-i2c is loaded before the cx23885 driver or after
the cx23885 driver.  I haven't found time to do any folow-up and I don't
have any of the hardware in question.

Do you have any thoughts or a suggested troubleshooting approach?

Regards,
Andy

> I try to found what happens.
> 
> With my best regards, Dmitry.

Re: [IR RC, REGRESSION] Didn't work IR RC

[Mauro Carvalho Chehab]

Andy Walls wrote:
> On Mon, 2010-03-01 at 15:36 +0900, Dmitri Belimov wrote:
>> Hi All
>>
>> After rework of the IR subsystem, IR RC no more work in our TV cards.
>> As I see 
>> call saa7134_probe_i2c_ir,
>>   configure i2c
>>   call i2c_new_device
>>
>> New i2c device not registred.
>>
>> The module kbd-i2c-ir loaded after i2c_new_device.
> 
> Jean,
> 
> There was also a problem reported with the cx23885 driver's I2C
> connected IR by Timothy Lenz:
> 
> http://www.spinics.net/lists/linux-media/msg15122.html
> 
> The failure mode sounds similar to Dmitri's, but maybe they are
> unrelated.
> 
> I worked a bit with Timothy on IRC and the remote device fails to be
> detected whether ir-kbd-i2c is loaded before the cx23885 driver or after
> the cx23885 driver.  I haven't found time to do any folow-up and I don't
> have any of the hardware in question.
> 
> Do you have any thoughts or a suggested troubleshooting approach?

Andy/Dmitri,

With the current i2c approach, the bridge driver is responsible for binding
an i2c device into the i2c adapter. In other words, the bridge driver should
have some logic to know what devices use ir-kbd-i2c, loading it at the right
i2c address(es). Manually loading IR shouldn't make any difference.

>From Andy's comment, I suspect that such logic is missing at cx23885 for the board
you're referring. Not sure if this is the same case of the boards Dmitri is
concerned about.

It should be noticed that the i2c redesign happened on 2.6.31 or 2.6.32, so,
if this is the case, a patch should be sent also to -stable.

In the case of saa7134, Jean worked on a fix for some boards:
	http://patchwork.kernel.org/patch/75883/

He is currently waiting for someone with the affected boards to test it and
give some return.

-- 

Cheers,
Mauro

Re: [IR RC, REGRESSION] Didn't work IR RC

[hermann pitton]

Hi,

Am Montag, den 01.03.2010, 10:37 -0300 schrieb Mauro Carvalho Chehab: 
> Andy Walls wrote:
> > On Mon, 2010-03-01 at 15:36 +0900, Dmitri Belimov wrote:
> >> Hi All
> >>
> >> After rework of the IR subsystem, IR RC no more work in our TV cards.
> >> As I see 
> >> call saa7134_probe_i2c_ir,
> >>   configure i2c
> >>   call i2c_new_device
> >>
> >> New i2c device not registred.
> >>
> >> The module kbd-i2c-ir loaded after i2c_new_device.
> > 
> > Jean,
> > 
> > There was also a problem reported with the cx23885 driver's I2C
> > connected IR by Timothy Lenz:
> > 
> > http://www.spinics.net/lists/linux-media/msg15122.html
> > 
> > The failure mode sounds similar to Dmitri's, but maybe they are
> > unrelated.
> > 
> > I worked a bit with Timothy on IRC and the remote device fails to be
> > detected whether ir-kbd-i2c is loaded before the cx23885 driver or after
> > the cx23885 driver.  I haven't found time to do any folow-up and I don't
> > have any of the hardware in question.
> > 
> > Do you have any thoughts or a suggested troubleshooting approach?
> 
> Andy/Dmitri,
> 
> With the current i2c approach, the bridge driver is responsible for binding
> an i2c device into the i2c adapter. In other words, the bridge driver should
> have some logic to know what devices use ir-kbd-i2c, loading it at the right
> i2c address(es). Manually loading IR shouldn't make any difference.

yes, we have info.addr at saa7134-input and Dmitri did add the Beholder
IR address there recently.

> >From Andy's comment, I suspect that such logic is missing at cx23885 for the board
> you're referring. Not sure if this is the same case of the boards Dmitri is
> concerned about.

On a first look, Andy seems not to provide the IR addr from the bridge
and without probing it can't work anymore.

> It should be noticed that the i2c redesign happened on 2.6.31 or 2.6.32, so,
> if this is the case, a patch should be sent also to -stable.
> 
> In the case of saa7134, Jean worked on a fix for some boards:
> 	http://patchwork.kernel.org/patch/75883/
> 
> He is currently waiting for someone with the affected boards to test it and
> give some return.

That fix should be unrelated and both variants of the patch are not
anywhere yet.

We can fake this single board in question on a P7131 Dual, but my
receiver is broken, else all looked O.K., and it seems not worth yet to
ask Mauro to lose time on faking it, assuming his IR receiver does still
work.

Here we can simply wait for Daro coming back from skiing, or can even
apply already Jean's solution per this card without any risk.

Else, do we not check for kernels < 2.6.30 on hg v4l-dvb not using auto
probing anymore? I tested only on two machines with some 2.6.30 and one
with 2.6.29 and recent hg v4l-dvb. There at least all was fine, also
with the patch moving IR init1 to saa7134_input_init2 and also for
ir-kbd-ic2 for a early Pinnacle 310i under all conditions.

Dmitri, on what kernel and/or SCM version of v4l-dvb you discover that
flaw? Maybe I can reproduce it then.

Andy has reports, that ir-kbd-i2c is still fine on 2.6.31, but breaks on
2.6.32. Do we already run out of sync?

Cheers,
Hermann

Re: [IR RC, REGRESSION] Didn't work IR RC

[Dmitri Belimov]

Hi

Not work I2C IR RC. GPIO RC I think works well.

This patch remove addr of our RC from switch-case

http://linuxtv.org/hg/v4l-dvb/rev/f700bce82813

When I set debug for ir-kbd-i2c I get 

ir-kbd-i2c: :Unsupported device at address 0x2d

People with broken IR RC what addr has your I2C IR RC?

With my best regards, Dmitry.

> Hi,
> 
> Am Montag, den 01.03.2010, 10:37 -0300 schrieb Mauro Carvalho Chehab: 
> > Andy Walls wrote:
> > > On Mon, 2010-03-01 at 15:36 +0900, Dmitri Belimov wrote:
> > >> Hi All
> > >>
> > >> After rework of the IR subsystem, IR RC no more work in our TV
> > >> cards. As I see 
> > >> call saa7134_probe_i2c_ir,
> > >>   configure i2c
> > >>   call i2c_new_device
> > >>
> > >> New i2c device not registred.
> > >>
> > >> The module kbd-i2c-ir loaded after i2c_new_device.
> > > 
> > > Jean,
> > > 
> > > There was also a problem reported with the cx23885 driver's I2C
> > > connected IR by Timothy Lenz:
> > > 
> > > http://www.spinics.net/lists/linux-media/msg15122.html
> > > 
> > > The failure mode sounds similar to Dmitri's, but maybe they are
> > > unrelated.
> > > 
> > > I worked a bit with Timothy on IRC and the remote device fails to
> > > be detected whether ir-kbd-i2c is loaded before the cx23885
> > > driver or after the cx23885 driver.  I haven't found time to do
> > > any folow-up and I don't have any of the hardware in question.
> > > 
> > > Do you have any thoughts or a suggested troubleshooting approach?
> > 
> > Andy/Dmitri,
> > 
> > With the current i2c approach, the bridge driver is responsible for
> > binding an i2c device into the i2c adapter. In other words, the
> > bridge driver should have some logic to know what devices use
> > ir-kbd-i2c, loading it at the right i2c address(es). Manually
> > loading IR shouldn't make any difference.
> 
> yes, we have info.addr at saa7134-input and Dmitri did add the
> Beholder IR address there recently.
> 
> > >From Andy's comment, I suspect that such logic is missing at
> > >cx23885 for the board
> > you're referring. Not sure if this is the same case of the boards
> > Dmitri is concerned about.
> 
> On a first look, Andy seems not to provide the IR addr from the bridge
> and without probing it can't work anymore.
> 
> > It should be noticed that the i2c redesign happened on 2.6.31 or
> > 2.6.32, so, if this is the case, a patch should be sent also to
> > -stable.
> > 
> > In the case of saa7134, Jean worked on a fix for some boards:
> > 	http://patchwork.kernel.org/patch/75883/
> > 
> > He is currently waiting for someone with the affected boards to
> > test it and give some return.
> 
> That fix should be unrelated and both variants of the patch are not
> anywhere yet.
> 
> We can fake this single board in question on a P7131 Dual, but my
> receiver is broken, else all looked O.K., and it seems not worth yet
> to ask Mauro to lose time on faking it, assuming his IR receiver does
> still work.
> 
> Here we can simply wait for Daro coming back from skiing, or can even
> apply already Jean's solution per this card without any risk.
> 
> Else, do we not check for kernels < 2.6.30 on hg v4l-dvb not using
> auto probing anymore? I tested only on two machines with some 2.6.30
> and one with 2.6.29 and recent hg v4l-dvb. There at least all was
> fine, also with the patch moving IR init1 to saa7134_input_init2 and
> also for ir-kbd-ic2 for a early Pinnacle 310i under all conditions.
> 
> Dmitri, on what kernel and/or SCM version of v4l-dvb you discover that
> flaw? Maybe I can reproduce it then.
> 
> Andy has reports, that ir-kbd-i2c is still fine on 2.6.31, but breaks
> on 2.6.32. Do we already run out of sync?
> 
> Cheers,
> Hermann
> 
> 

Re: [IR RC, REGRESSION] Didn't work IR RC

[Dmitri Belimov]

Hi

When I add 

diff -r 37ff78330942 linux/drivers/media/video/ir-kbd-i2c.c
--- a/linux/drivers/media/video/ir-kbd-i2c.c	Sun Feb 28 16:59:57 2010 -0300
+++ b/linux/drivers/media/video/ir-kbd-i2c.c	Tue Mar 02 10:31:31 2010 +0900
@@ -465,6 +519,11 @@
 		ir_type     = IR_TYPE_OTHER;
 		ir_codes    = &ir_codes_avermedia_cardbus_table;
 		break;
+	case 0x2d:
+		/* Handled by saa7134-input */
+		name        = "SAA713x remote";
+		ir_type     = IR_TYPE_OTHER;
+		break;
 	}
 
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 30)

The IR subsystem register event device. But for get key code use ir_pool_key function.

For our IR RC need use our special function. How I can do it?

With my best regards, Dmitry.

> Hi
> 
> Not work I2C IR RC. GPIO RC I think works well.
> 
> This patch remove addr of our RC from switch-case
> 
> http://linuxtv.org/hg/v4l-dvb/rev/f700bce82813
> 
> When I set debug for ir-kbd-i2c I get 
> 
> ir-kbd-i2c: :Unsupported device at address 0x2d
> 
> People with broken IR RC what addr has your I2C IR RC?
> 
> With my best regards, Dmitry.
> 
> > Hi,
> > 
> > Am Montag, den 01.03.2010, 10:37 -0300 schrieb Mauro Carvalho
> > Chehab: 
> > > Andy Walls wrote:
> > > > On Mon, 2010-03-01 at 15:36 +0900, Dmitri Belimov wrote:
> > > >> Hi All
> > > >>
> > > >> After rework of the IR subsystem, IR RC no more work in our TV
> > > >> cards. As I see 
> > > >> call saa7134_probe_i2c_ir,
> > > >>   configure i2c
> > > >>   call i2c_new_device
> > > >>
> > > >> New i2c device not registred.
> > > >>
> > > >> The module kbd-i2c-ir loaded after i2c_new_device.
> > > > 
> > > > Jean,
> > > > 
> > > > There was also a problem reported with the cx23885 driver's I2C
> > > > connected IR by Timothy Lenz:
> > > > 
> > > > http://www.spinics.net/lists/linux-media/msg15122.html
> > > > 
> > > > The failure mode sounds similar to Dmitri's, but maybe they are
> > > > unrelated.
> > > > 
> > > > I worked a bit with Timothy on IRC and the remote device fails
> > > > to be detected whether ir-kbd-i2c is loaded before the cx23885
> > > > driver or after the cx23885 driver.  I haven't found time to do
> > > > any folow-up and I don't have any of the hardware in question.
> > > > 
> > > > Do you have any thoughts or a suggested troubleshooting
> > > > approach?
> > > 
> > > Andy/Dmitri,
> > > 
> > > With the current i2c approach, the bridge driver is responsible
> > > for binding an i2c device into the i2c adapter. In other words,
> > > the bridge driver should have some logic to know what devices use
> > > ir-kbd-i2c, loading it at the right i2c address(es). Manually
> > > loading IR shouldn't make any difference.
> > 
> > yes, we have info.addr at saa7134-input and Dmitri did add the
> > Beholder IR address there recently.
> > 
> > > >From Andy's comment, I suspect that such logic is missing at
> > > >cx23885 for the board
> > > you're referring. Not sure if this is the same case of the boards
> > > Dmitri is concerned about.
> > 
> > On a first look, Andy seems not to provide the IR addr from the
> > bridge and without probing it can't work anymore.
> > 
> > > It should be noticed that the i2c redesign happened on 2.6.31 or
> > > 2.6.32, so, if this is the case, a patch should be sent also to
> > > -stable.
> > > 
> > > In the case of saa7134, Jean worked on a fix for some boards:
> > > 	http://patchwork.kernel.org/patch/75883/
> > > 
> > > He is currently waiting for someone with the affected boards to
> > > test it and give some return.
> > 
> > That fix should be unrelated and both variants of the patch are not
> > anywhere yet.
> > 
> > We can fake this single board in question on a P7131 Dual, but my
> > receiver is broken, else all looked O.K., and it seems not worth yet
> > to ask Mauro to lose time on faking it, assuming his IR receiver
> > does still work.
> > 
> > Here we can simply wait for Daro coming back from skiing, or can
> > even apply already Jean's solution per this card without any risk.
> > 
> > Else, do we not check for kernels < 2.6.30 on hg v4l-dvb not using
> > auto probing anymore? I tested only on two machines with some 2.6.30
> > and one with 2.6.29 and recent hg v4l-dvb. There at least all was
> > fine, also with the patch moving IR init1 to saa7134_input_init2 and
> > also for ir-kbd-ic2 for a early Pinnacle 310i under all conditions.
> > 
> > Dmitri, on what kernel and/or SCM version of v4l-dvb you discover
> > that flaw? Maybe I can reproduce it then.
> > 
> > Andy has reports, that ir-kbd-i2c is still fine on 2.6.31, but
> > breaks on 2.6.32. Do we already run out of sync?
> > 
> > Cheers,
> > Hermann
> > 
> > 

Re: [IR RC, REGRESSION] Didn't work IR RC

[Mauro Carvalho Chehab]

Dmitri Belimov wrote:
> Hi
> 
> When I add 
> 
> diff -r 37ff78330942 linux/drivers/media/video/ir-kbd-i2c.c
> --- a/linux/drivers/media/video/ir-kbd-i2c.c	Sun Feb 28 16:59:57 2010 -0300
> +++ b/linux/drivers/media/video/ir-kbd-i2c.c	Tue Mar 02 10:31:31 2010 +0900
> @@ -465,6 +519,11 @@
>  		ir_type     = IR_TYPE_OTHER;
>  		ir_codes    = &ir_codes_avermedia_cardbus_table;
>  		break;
> +	case 0x2d:
> +		/* Handled by saa7134-input */
> +		name        = "SAA713x remote";
> +		ir_type     = IR_TYPE_OTHER;
> +		break;
>  	}
>  
>  #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 30)
> 
> The IR subsystem register event device. But for get key code use ir_pool_key function.
> 
> For our IR RC need use our special function. How I can do it?

Just add your get_key callback to "ir->get_key". If you want to do this from
saa7134-input, please take a look at the code at em28xx_register_i2c_ir(). 
It basically fills the platform_data.

While you're there, I suggest you to change your code to work with the
full scancode (e. g. address + command), instead of just getting the command.
Currently, em28xx-input has one I2C IR already changed to this mode (seek
for full_code for the differences).

You'll basically need to change the IR tables to contain address+command, and
inform the used protocol (RC5/NEC) on it. The getkey function will need to
return the full code as well.

> 
> With my best regards, Dmitry.
> 
>> Hi
>>
>> Not work I2C IR RC. GPIO RC I think works well.
>>
>> This patch remove addr of our RC from switch-case
>>
>> http://linuxtv.org/hg/v4l-dvb/rev/f700bce82813
>>
>> When I set debug for ir-kbd-i2c I get 
>>
>> ir-kbd-i2c: :Unsupported device at address 0x2d
>>
>> People with broken IR RC what addr has your I2C IR RC?
>>
>> With my best regards, Dmitry.
>>
>>> Hi,
>>>
>>> Am Montag, den 01.03.2010, 10:37 -0300 schrieb Mauro Carvalho
>>> Chehab: 
>>>> Andy Walls wrote:
>>>>> On Mon, 2010-03-01 at 15:36 +0900, Dmitri Belimov wrote:
>>>>>> Hi All
>>>>>>
>>>>>> After rework of the IR subsystem, IR RC no more work in our TV
>>>>>> cards. As I see 
>>>>>> call saa7134_probe_i2c_ir,
>>>>>>   configure i2c
>>>>>>   call i2c_new_device
>>>>>>
>>>>>> New i2c device not registred.
>>>>>>
>>>>>> The module kbd-i2c-ir loaded after i2c_new_device.
>>>>> Jean,
>>>>>
>>>>> There was also a problem reported with the cx23885 driver's I2C
>>>>> connected IR by Timothy Lenz:
>>>>>
>>>>> http://www.spinics.net/lists/linux-media/msg15122.html
>>>>>
>>>>> The failure mode sounds similar to Dmitri's, but maybe they are
>>>>> unrelated.
>>>>>
>>>>> I worked a bit with Timothy on IRC and the remote device fails
>>>>> to be detected whether ir-kbd-i2c is loaded before the cx23885
>>>>> driver or after the cx23885 driver.  I haven't found time to do
>>>>> any folow-up and I don't have any of the hardware in question.
>>>>>
>>>>> Do you have any thoughts or a suggested troubleshooting
>>>>> approach?
>>>> Andy/Dmitri,
>>>>
>>>> With the current i2c approach, the bridge driver is responsible
>>>> for binding an i2c device into the i2c adapter. In other words,
>>>> the bridge driver should have some logic to know what devices use
>>>> ir-kbd-i2c, loading it at the right i2c address(es). Manually
>>>> loading IR shouldn't make any difference.
>>> yes, we have info.addr at saa7134-input and Dmitri did add the
>>> Beholder IR address there recently.
>>>
>>>> >From Andy's comment, I suspect that such logic is missing at
>>>>> cx23885 for the board
>>>> you're referring. Not sure if this is the same case of the boards
>>>> Dmitri is concerned about.
>>> On a first look, Andy seems not to provide the IR addr from the
>>> bridge and without probing it can't work anymore.
>>>
>>>> It should be noticed that the i2c redesign happened on 2.6.31 or
>>>> 2.6.32, so, if this is the case, a patch should be sent also to
>>>> -stable.
>>>>
>>>> In the case of saa7134, Jean worked on a fix for some boards:
>>>> 	http://patchwork.kernel.org/patch/75883/
>>>>
>>>> He is currently waiting for someone with the affected boards to
>>>> test it and give some return.
>>> That fix should be unrelated and both variants of the patch are not
>>> anywhere yet.
>>>
>>> We can fake this single board in question on a P7131 Dual, but my
>>> receiver is broken, else all looked O.K., and it seems not worth yet
>>> to ask Mauro to lose time on faking it, assuming his IR receiver
>>> does still work.
>>>
>>> Here we can simply wait for Daro coming back from skiing, or can
>>> even apply already Jean's solution per this card without any risk.
>>>
>>> Else, do we not check for kernels < 2.6.30 on hg v4l-dvb not using
>>> auto probing anymore? I tested only on two machines with some 2.6.30
>>> and one with 2.6.29 and recent hg v4l-dvb. There at least all was
>>> fine, also with the patch moving IR init1 to saa7134_input_init2 and
>>> also for ir-kbd-ic2 for a early Pinnacle 310i under all conditions.
>>>
>>> Dmitri, on what kernel and/or SCM version of v4l-dvb you discover
>>> that flaw? Maybe I can reproduce it then.
>>>
>>> Andy has reports, that ir-kbd-i2c is still fine on 2.6.31, but
>>> breaks on 2.6.32. Do we already run out of sync?
>>>
>>> Cheers,
>>> Hermann
>>>
>>>


-- 

Cheers,
Mauro

Re: [IR RC, REGRESSION] Didn't work IR RC

[Jean Delvare]

Hi Mauro, Dmitri,

On Tue, 02 Mar 2010 05:49:17 -0300, Mauro Carvalho Chehab wrote:
> Dmitri Belimov wrote:
> > When I add 
> > 
> > diff -r 37ff78330942 linux/drivers/media/video/ir-kbd-i2c.c
> > --- a/linux/drivers/media/video/ir-kbd-i2c.c	Sun Feb 28 16:59:57 2010 -0300
> > +++ b/linux/drivers/media/video/ir-kbd-i2c.c	Tue Mar 02 10:31:31 2010 +0900
> > @@ -465,6 +519,11 @@
> >  		ir_type     = IR_TYPE_OTHER;
> >  		ir_codes    = &ir_codes_avermedia_cardbus_table;
> >  		break;
> > +	case 0x2d:
> > +		/* Handled by saa7134-input */
> > +		name        = "SAA713x remote";
> > +		ir_type     = IR_TYPE_OTHER;
> > +		break;
> >  	}
> >  
> >  #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 30)
> > 
> > The IR subsystem register event device. But for get key code use ir_pool_key function.
> > 
> > For our IR RC need use our special function. How I can do it?
> 
> Just add your get_key callback to "ir->get_key". If you want to do this from
> saa7134-input, please take a look at the code at em28xx_register_i2c_ir(). 
> It basically fills the platform_data.
> 
> While you're there, I suggest you to change your code to work with the
> full scancode (e. g. address + command), instead of just getting the command.
> Currently, em28xx-input has one I2C IR already changed to this mode (seek
> for full_code for the differences).
> 
> You'll basically need to change the IR tables to contain address+command, and
> inform the used protocol (RC5/NEC) on it. The getkey function will need to
> return the full code as well.

Sorry for the late reply. Is the problem solved by now, or is my help
still needed?

-- 
Jean Delvare

Re: [IR RC, REGRESSION] Didn't work IR RC

[Dmitri Belimov]

Hi Jean

> Hi Mauro, Dmitri,
> 
> On Tue, 02 Mar 2010 05:49:17 -0300, Mauro Carvalho Chehab wrote:
> > Dmitri Belimov wrote:
> > > When I add 
> > > 
> > > diff -r 37ff78330942 linux/drivers/media/video/ir-kbd-i2c.c
> > > --- a/linux/drivers/media/video/ir-kbd-i2c.c	Sun Feb 28
> > > 16:59:57 2010 -0300 +++
> > > b/linux/drivers/media/video/ir-kbd-i2c.c	Tue Mar 02
> > > 10:31:31 2010 +0900 @@ -465,6 +519,11 @@ ir_type     =
> > > IR_TYPE_OTHER; ir_codes    = &ir_codes_avermedia_cardbus_table;
> > >  		break;
> > > +	case 0x2d:
> > > +		/* Handled by saa7134-input */
> > > +		name        = "SAA713x remote";
> > > +		ir_type     = IR_TYPE_OTHER;
> > > +		break;
> > >  	}
> > >  
> > >  #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 30)
> > > 
> > > The IR subsystem register event device. But for get key code use
> > > ir_pool_key function.
> > > 
> > > For our IR RC need use our special function. How I can do it?
> > 
> > Just add your get_key callback to "ir->get_key". If you want to do
> > this from saa7134-input, please take a look at the code at
> > em28xx_register_i2c_ir(). It basically fills the platform_data.
> > 
> > While you're there, I suggest you to change your code to work with
> > the full scancode (e. g. address + command), instead of just
> > getting the command. Currently, em28xx-input has one I2C IR already
> > changed to this mode (seek for full_code for the differences).
> > 
> > You'll basically need to change the IR tables to contain
> > address+command, and inform the used protocol (RC5/NEC) on it. The
> > getkey function will need to return the full code as well.
> 
> Sorry for the late reply. Is the problem solved by now, or is my help
> still needed?

Yes. I found what happens and solve this regression. Patch already comitted.

diff -r 37ff78330942 linux/drivers/media/video/saa7134/saa7134-input.c
--- a/linux/drivers/media/video/saa7134/saa7134-input.c	Sun Feb 28 16:59:57 2010 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-input.c	Thu Mar 04 08:35:15 2010 +0900
@@ -947,6 +947,7 @@
 		dev->init_data.name = "BeholdTV";
 		dev->init_data.get_key = get_key_beholdm6xx;
 		dev->init_data.ir_codes = &ir_codes_behold_table;
+		dev->init_data.type = IR_TYPE_NEC;
 		info.addr = 0x2d;
 #endif
 		break;


With my best regards, Dmitry.

Re: [IR RC, REGRESSION] Didn't work IR RC

[Jean Delvare]

On Wed, 10 Mar 2010 13:02:25 +0900, Dmitri Belimov wrote:
> > Sorry for the late reply. Is the problem solved by now, or is my help
> > still needed?
> 
> Yes. I found what happens and solve this regression. Patch already comitted.
> 
> diff -r 37ff78330942 linux/drivers/media/video/saa7134/saa7134-input.c
> --- a/linux/drivers/media/video/saa7134/saa7134-input.c	Sun Feb 28 16:59:57 2010 -0300
> +++ b/linux/drivers/media/video/saa7134/saa7134-input.c	Thu Mar 04 08:35:15 2010 +0900
> @@ -947,6 +947,7 @@
>  		dev->init_data.name = "BeholdTV";
>  		dev->init_data.get_key = get_key_beholdm6xx;
>  		dev->init_data.ir_codes = &ir_codes_behold_table;
> +		dev->init_data.type = IR_TYPE_NEC;
>  		info.addr = 0x2d;
>  #endif
>  		break;
> 

None of my patches removed this statement, and IR_TYPE_NEC itself seems
to be new in kernel 2.6.33, so I admit I don't quite understand how I
my i2c changes could be responsible for the regression.

Anyway, glad that you managed to fix it.

-- 
Jean Delvare

Re: [IR RC, REGRESSION] Didn't work IR RC

[Jean Delvare]

Hi Andy, Timothy,

On Mon, 01 Mar 2010 06:28:39 -0500, Andy Walls wrote:
> There was also a problem reported with the cx23885 driver's I2C
> connected IR by Timothy Lenz:
> 
> http://www.spinics.net/lists/linux-media/msg15122.html
> 
> The failure mode sounds similar to Dmitri's, but maybe they are
> unrelated.
> 
> I worked a bit with Timothy on IRC and the remote device fails to be
> detected whether ir-kbd-i2c is loaded before the cx23885 driver or after
> the cx23885 driver.  I haven't found time to do any folow-up and I don't
> have any of the hardware in question.
> 
> Do you have any thoughts or a suggested troubleshooting approach?

Now that Dmitri's problem is fixed, let's move to Timothy's issue.

Executive summary (as I understand it): the card that no longer works
is a DViCO FusionHDTV7 Dual Express
(CX23885_BOARD_DVICO_FUSIONHDTV_7_DUAL_EXP), bridge driver cx23885. It
has 2 xc5000 chips at I2C address 0x64 (on 2 different I2C buses, of
course), and an IR chip at 0x6b (on the first of these 2 I2C buses.)
The latter is reported to be missing with recent dvb-v4l trees.

The first thing to check is whether an ir_video I2C device is created
or not. Look in /sys/bus/i2c/devices, list all the entries there. You
should see two *-0064 entries for the xc5000 chips. You should also
see, but you probably won't, one *-006b entry for the IR chip. The
following command should let us know right away what is there:

$ grep . /sys/bus/i2c/devices/*/name

The ir_video device is supposed to be probed by cx23885_i2c_register().
If it is not created, it means that the probe failed. Maybe these chips
do not like the probe mechanism used by i2c-core (quick write) and only
reply to reads? In that case, we'd need to use reads to detect it. The
i2c core doesn't give us enough control to do this cleanly, but this
could be added if the need exists. In the meantime, we can do the probe
ourselves and instantiate the device unconditionally (by using
i2c_new_device instead of i2c_new_probed_device).

-- 
Jean Delvare

[PATCH] FusionHDTV: Use quick reads for I2C IR device probing

[Jean Delvare]

On Tue, 16 Mar 2010 12:05:02 +0100, Jean Delvare wrote:
> Executive summary (as I understand it): the card that no longer works
> is a DViCO FusionHDTV7 Dual Express
> (CX23885_BOARD_DVICO_FUSIONHDTV_7_DUAL_EXP), bridge driver cx23885. It
> has 2 xc5000 chips at I2C address 0x64 (on 2 different I2C buses, of
> course), and an IR chip at 0x6b (on the first of these 2 I2C buses.)
> The latter is reported to be missing with recent dvb-v4l trees.
> 
> The first thing to check is whether an ir_video I2C device is created
> or not. Look in /sys/bus/i2c/devices, list all the entries there. You
> should see two *-0064 entries for the xc5000 chips. You should also
> see, but you probably won't, one *-006b entry for the IR chip. The
> following command should let us know right away what is there:
> 
> $ grep . /sys/bus/i2c/devices/*/name
> 
> The ir_video device is supposed to be probed by cx23885_i2c_register().
> If it is not created, it means that the probe failed. Maybe these chips
> do not like the probe mechanism used by i2c-core (quick write) and only
> reply to reads? In that case, we'd need to use reads to detect it. The
> i2c core doesn't give us enough control to do this cleanly, but this
> could be added if the need exists. In the meantime, we can do the probe
> ourselves and instantiate the device unconditionally (by using
> i2c_new_device instead of i2c_new_probed_device).

We have been debugging over IRC with Timothy, and I have a fix which he
tested successfully. Basically, the problem is that the IR device on
his chip only replies to read commands, but when switching ir-kbd-i2c
to the standard device driver binding model in kernel 2.6.31, I changed
the probing method from quick read to quick write as a side effect.
This is why the IR device was no longer being detected. Using a quick
read again solves the issue. Here comes a fix, tested by Timothy for
the cx23885 part, untested for the cx88 part but I'd be very surprised
if cx88-based FusionHDTV did not need the exact same fix

* * * * *

IR support on FusionHDTV cards is broken since kernel 2.6.31. One side
effect of the switch to the standard binding model for IR I2C devices
was to let i2c-core do the probing instead of the ir-kbd-i2c driver.
There is a slight difference between the two probe methods: i2c-core
uses 0-byte writes, while the ir-kbd-i2c was using 0-byte reads. As
some IR I2C devices only support reads, the new probe method fails to
detect them.

For now, revert to letting the driver do the probe, using 0-byte
reads. In the future, i2c-core will be extended to let callers of
i2c_new_probed_device() provide a custom probing function.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Tested-by: "Timothy D. Lenz" <tlenz@vorgon.com>
---
This fix applies to kernels 2.6.31 to 2.6.34. Should be sent to Linus
quickly.

 drivers/media/video/cx23885/cx23885-i2c.c |   12 +++++++++++-
 drivers/media/video/cx88/cx88-i2c.c       |   16 +++++++++++++++-
 2 files changed, 26 insertions(+), 2 deletions(-)

--- linux-2.6.34-rc1.orig/drivers/media/video/cx23885/cx23885-i2c.c	2010-02-25 09:10:33.000000000 +0100
+++ linux-2.6.34-rc1/drivers/media/video/cx23885/cx23885-i2c.c	2010-03-18 13:33:05.000000000 +0100
@@ -365,7 +365,17 @@ int cx23885_i2c_register(struct cx23885_
 
 		memset(&info, 0, sizeof(struct i2c_board_info));
 		strlcpy(info.type, "ir_video", I2C_NAME_SIZE);
-		i2c_new_probed_device(&bus->i2c_adap, &info, addr_list);
+		/*
+		 * We can't call i2c_new_probed_device() because it uses
+		 * quick writes for probing and the IR receiver device only
+		 * replies to reads.
+		 */
+		if (i2c_smbus_xfer(&bus->i2c_adap, addr_list[0], 0,
+				   I2C_SMBUS_READ, 0, I2C_SMBUS_QUICK,
+				   NULL) >= 0) {
+			info.addr = addr_list[0];
+			i2c_new_device(&bus->i2c_adap, &info);
+		}
 	}
 
 	return bus->i2c_rc;
--- linux-2.6.34-rc1.orig/drivers/media/video/cx88/cx88-i2c.c	2010-02-25 09:08:40.000000000 +0100
+++ linux-2.6.34-rc1/drivers/media/video/cx88/cx88-i2c.c	2010-03-18 13:33:05.000000000 +0100
@@ -188,10 +188,24 @@ int cx88_i2c_init(struct cx88_core *core
 			0x18, 0x6b, 0x71,
 			I2C_CLIENT_END
 		};
+		const unsigned short *addrp;
 
 		memset(&info, 0, sizeof(struct i2c_board_info));
 		strlcpy(info.type, "ir_video", I2C_NAME_SIZE);
-		i2c_new_probed_device(&core->i2c_adap, &info, addr_list);
+		/*
+		 * We can't call i2c_new_probed_device() because it uses
+		 * quick writes for probing and at least some R receiver
+		 * devices only reply to reads.
+		 */
+		for (addrp = addr_list; *addrp != I2C_CLIENT_END; addrp++) {
+			if (i2c_smbus_xfer(&core->i2c_adap, *addrp, 0,
+					   I2C_SMBUS_READ, 0,
+					   I2C_SMBUS_QUICK, NULL) >= 0) {
+				info.addr = *addrp;
+				i2c_new_device(&core->i2c_adap, &info);
+				break;
+			}
+		}
 	}
 	return core->i2c_rc;
 }


-- 
Jean Delvare

Re: [PATCH] FusionHDTV: Use quick reads for I2C IR device probing

[Jean Delvare]

Can the fix below please be picked quickly? This is a regression, the
fix should go upstream ASAP. Thanks.

On Fri, 19 Mar 2010 14:42:50 +0100, Jean Delvare wrote:
> IR support on FusionHDTV cards is broken since kernel 2.6.31. One side
> effect of the switch to the standard binding model for IR I2C devices
> was to let i2c-core do the probing instead of the ir-kbd-i2c driver.
> There is a slight difference between the two probe methods: i2c-core
> uses 0-byte writes, while the ir-kbd-i2c was using 0-byte reads. As
> some IR I2C devices only support reads, the new probe method fails to
> detect them.
> 
> For now, revert to letting the driver do the probe, using 0-byte
> reads. In the future, i2c-core will be extended to let callers of
> i2c_new_probed_device() provide a custom probing function.
> 
> Signed-off-by: Jean Delvare <khali@linux-fr.org>
> Tested-by: "Timothy D. Lenz" <tlenz@vorgon.com>
> ---
> This fix applies to kernels 2.6.31 to 2.6.34. Should be sent to Linus
> quickly.
> 
>  drivers/media/video/cx23885/cx23885-i2c.c |   12 +++++++++++-
>  drivers/media/video/cx88/cx88-i2c.c       |   16 +++++++++++++++-
>  2 files changed, 26 insertions(+), 2 deletions(-)
> 
> --- linux-2.6.34-rc1.orig/drivers/media/video/cx23885/cx23885-i2c.c	2010-02-25 09:10:33.000000000 +0100
> +++ linux-2.6.34-rc1/drivers/media/video/cx23885/cx23885-i2c.c	2010-03-18 13:33:05.000000000 +0100
> @@ -365,7 +365,17 @@ int cx23885_i2c_register(struct cx23885_
>  
>  		memset(&info, 0, sizeof(struct i2c_board_info));
>  		strlcpy(info.type, "ir_video", I2C_NAME_SIZE);
> -		i2c_new_probed_device(&bus->i2c_adap, &info, addr_list);
> +		/*
> +		 * We can't call i2c_new_probed_device() because it uses
> +		 * quick writes for probing and the IR receiver device only
> +		 * replies to reads.
> +		 */
> +		if (i2c_smbus_xfer(&bus->i2c_adap, addr_list[0], 0,
> +				   I2C_SMBUS_READ, 0, I2C_SMBUS_QUICK,
> +				   NULL) >= 0) {
> +			info.addr = addr_list[0];
> +			i2c_new_device(&bus->i2c_adap, &info);
> +		}
>  	}
>  
>  	return bus->i2c_rc;
> --- linux-2.6.34-rc1.orig/drivers/media/video/cx88/cx88-i2c.c	2010-02-25 09:08:40.000000000 +0100
> +++ linux-2.6.34-rc1/drivers/media/video/cx88/cx88-i2c.c	2010-03-18 13:33:05.000000000 +0100
> @@ -188,10 +188,24 @@ int cx88_i2c_init(struct cx88_core *core
>  			0x18, 0x6b, 0x71,
>  			I2C_CLIENT_END
>  		};
> +		const unsigned short *addrp;
>  
>  		memset(&info, 0, sizeof(struct i2c_board_info));
>  		strlcpy(info.type, "ir_video", I2C_NAME_SIZE);
> -		i2c_new_probed_device(&core->i2c_adap, &info, addr_list);
> +		/*
> +		 * We can't call i2c_new_probed_device() because it uses
> +		 * quick writes for probing and at least some R receiver
> +		 * devices only reply to reads.
> +		 */
> +		for (addrp = addr_list; *addrp != I2C_CLIENT_END; addrp++) {
> +			if (i2c_smbus_xfer(&core->i2c_adap, *addrp, 0,
> +					   I2C_SMBUS_READ, 0,
> +					   I2C_SMBUS_QUICK, NULL) >= 0) {
> +				info.addr = *addrp;
> +				i2c_new_device(&core->i2c_adap, &info);
> +				break;
> +			}
> +		}
>  	}
>  	return core->i2c_rc;
>  }
> 
> 


-- 
Jean Delvare