Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model

[CityK <cityk@rogers.com>]

Mauro Carvalho Chehab wrote:
> On Tue, 07 Apr 2009 23:02:43 -0400
> CityK <cityk@rogers.com> wrote:
>
>   
>> Regarding the KS003 (& KS007; the other "mystery" chip):
>>
>> Upon further investigation of some info from a post from last year
>> (http://www.linuxtv.org/pipermail/linux-dvb/2008-January/022634.html),
>> it appears that these (assuming that they are the same IC across the
>> various MSI, Leadtek & KWorld cards; and I believe that to be true) are
>> the "AT8PS54/S56" chip from "Feeling Technology" ... the datasheet for
>> that part is available through a google search .... probing further (as
>> I had never heard of FT before and so I looked them up), it looks like
>> FT renamed and/or upgraded the chip to the "FM8PS54/S56" ... the near
>> identical datasheet for that second version is also available:
>> http://www.feeling-tech.com.tw/km-master/front/bin/ptdetail.phtml?Part=M1-05&Category=100018
>>     
>
> From what I've investigated, several of those IR chips are micro-controllers like
> the one you pointed. I've seen a few boards whose IR chip is not masked. On
> those, I always went into some micro-controller datasheet.
>
> Those IR's with a micro-controller have some software inside it to decode one IR
> protocol and generate scan-code sequences that can be received via GPIO or via
> I2C, depending on the firmware content.
>
> The datasheet of those chips are useless, since the behaviour of the
> device is programmed inside their ROM/EEPROM [1]. So, even being the same chip,
> you could have two "K007" devices with different firmwares, listening on
> different i2c addresses and eventually generating different scan-codes for the
> same IR.
>
> On the other hand, for USB devices and for bttv, saa7134 and cx88, there are
> some easy ways to monitor what i2c messages or GPIO pins are involved with IR.
> In general, the IR received messages generated by the firmware are some header,
> a scan code, a repeat key bit and a trailer. So, it is not hard to generate a
> get-key routine to get the scan code and the repeat bit from the protocol.
>
> That's why the modern ir-kbd-i2c approach is to select the proper IR parameters
> after binding the module, at the bridge driver. The bridge driver is the one
> who knows what's the IR scan code of the original IR (to set it as the
> default), and the proper get-key function. With the new i2c behaviour, the
> bridge driver can also specify the proper i2c address for each device.
>
> Cheers,
> Mauro
>
> [1] It doesn't seem to be practical for me to get their internal software.In
> general, such micro-controllers block EEPROM/ROM read of the software inside.
> If this is the case of this chip, the only remaining option to get the internal
> software would be to cut the plastic and try to see the state of each eeprom
> bit with the help of a good microscope. 
> Anyway, assuming that there are some way to read the ROM content, in order to
> see the device behavior, one should remove the chip from the board, get the
> ROM/EEPROM content, write a disassembler for this processor, disassemble the
> code and analyse the results. This would be a real hard work, would take a lot
> of time, and I doubt that this would help to improve the driver, since we
> already know how to read scan codes from those devices.

Thanks for the detailed response Mauro. I've actually been wondering
about whether the specific "KS00x" designation/label might refer to the
embedded firmware or to a dataline, so that thought is certainly
consistent with your description.