From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-bk0-f46.google.com ([209.85.214.46]:47349 "EHLO mail-bk0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751555Ab2LJTYN (ORCPT ); Mon, 10 Dec 2012 14:24:13 -0500 Received: by mail-bk0-f46.google.com with SMTP id q16so1256793bkw.19 for ; Mon, 10 Dec 2012 11:24:12 -0800 (PST) Message-ID: <50C636E7.8060003@googlemail.com> Date: Mon, 10 Dec 2012 20:24:23 +0100 From: =?ISO-8859-1?Q?Frank_Sch=E4fer?= MIME-Version: 1.0 To: Antti Palosaari CC: Devin Heitmueller , Matthew Gyurgyik , Linux Media Mailing List Subject: Re: em28xx: msi Digivox ATSC board id [0db0:8810] References: <50B5779A.9090807@pyther.net> <50BE65F0.8020303@googlemail.com> <50BEC253.4080006@pyther.net> <50BF3F9A.3020803@iki.fi> <50BFBE39.90901@pyther.net> <50BFC445.6020305@iki.fi> <50BFCBBB.5090407@pyther.net> <50BFECEA.9060808@iki.fi> <50BFFFF6.1000204@pyther.net> <50C11301.10205@googlemail.com> <50C12302.80603@pyther.net> <50C34628.5030407@googlemail.com> <50C34A50.6000207@pyther.net> <50C35AD1.3040000@googlemail.com> <50C48891.2050903@googlemail.com> <50C4A520.6020908@pyther.net> <50C4BA20.8060003@googlemail.com> <50C4BAFB.60304@googlemail.com> <50C4C525.6020006@googlemail.com> <50C4D011.6010700@pyther.net> <50C60220.8050908@googlemail.com> <50C60772.2010904@googlemail.com> <50C6226C.8090302@iki.fi> In-Reply-To: <50C6226C.8090302@iki.fi> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: linux-media-owner@vger.kernel.org List-ID: Am 10.12.2012 18:57, schrieb Antti Palosaari: > On 12/10/2012 06:13 PM, Devin Heitmueller wrote: >> On Mon, Dec 10, 2012 at 11:01 AM, Frank Schäfer >>> Adding a new property to the RC profile certainly seems to be the >>> cleanest solution. >>> Do all protocols have paritiy checking ? Otherwise we could add a new >>> type RC_TYPE_NEC_NO_PARITY. >>> OTOH, introducing a new bitfield in struct rc_map might be usefull for >>> other flags, too, in the future... >> >> It's probably also worth mentioning that in that mode the device >> reports four bytes, not two. I guess perhaps if parity is ignored it >> reports the data in some other format? You will probably have to do >> some experimentation there. > > Uh, current em28xx NEC implementation is locked to traditional 16 bit > NEC, where is hw checksum used. > > Implementation should be changed to more general to support 24 and 32 > bit NEC too. There is multiple drivers doing already that, for example > AF9015. > Hmm... are there and documents (, links, books, ...) where I can learn more about all those RC protocols ? Regards Frank