From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mailout3.w2.samsung.com ([211.189.100.13]:27116 "EHLO usmailout3.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751649AbaAVWBt convert rfc822-to-8bit (ORCPT ); Wed, 22 Jan 2014 17:01:49 -0500 Received: from uscpsbgm2.samsung.com (u115.gpu85.samsung.co.kr [203.254.195.115]) by usmailout3.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0MZT00ECSP6ZU090@usmailout3.samsung.com> for linux-media@vger.kernel.org; Wed, 22 Jan 2014 17:01:47 -0500 (EST) Date: Wed, 22 Jan 2014 20:01:42 -0200 From: Mauro Carvalho Chehab To: Sean Young Cc: Antti =?UTF-8?B?U2VwcMOkbMOk?= , linux-media@vger.kernel.org Subject: Re: [RFC PATCH 0/4] rc: Adding support for sysfs wakeup scancodes Message-id: <20140122200142.002a39c2@samsung.com> In-reply-to: <20140122210024.GA3223@pequod.mess.org> References: <20140115173559.7e53239a@samsung.com> <1390246787-15616-1-git-send-email-a.seppala@gmail.com> <20140121122826.GA25490@pequod.mess.org> <20140122162953.GA1665@pequod.mess.org> <20140122210024.GA3223@pequod.mess.org> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 8BIT Sender: linux-media-owner@vger.kernel.org List-ID: Em Wed, 22 Jan 2014 21:00:24 +0000 Sean Young escreveu: > On Wed, Jan 22, 2014 at 09:10:58PM +0200, Antti Seppälä wrote: > > On 22 January 2014 18:29, Sean Young wrote: > > > On Wed, Jan 22, 2014 at 05:46:28PM +0200, Antti Seppälä wrote: > > >> On 21 January 2014 14:28, Sean Young wrote: > > >> > On Mon, Jan 20, 2014 at 09:39:43PM +0200, Antti Seppälä wrote: > > >> >> This patch series introduces a simple sysfs file interface for reading > > >> >> and writing wakeup scancodes to rc drivers. > > >> >> > > >> >> This is an improved version of my previous patch for nuvoton-cir which > > >> >> did the same thing via module parameters. This is a more generic > > >> >> approach allowing other drivers to utilize the interface as well. > > >> >> > > >> >> I did not port winbond-cir to this method of wakeup scancode setting yet > > >> >> because I don't have the hardware to test it and I wanted first to get > > >> >> some comments about how the patch series looks. I did however write a > > >> >> simple support to read and write scancodes to rc-loopback module. > > >> > > > >> > Doesn't the nuvoton-cir driver need to know the IR protocol for wakeup? > > >> > > > >> > This is needed for winbond-cir; I guess this should be another sysfs > > >> > file, something like "wakeup_protocol". Even if the nuvoton can only > > >> > handle one IR protocol, maybe it should be exported (readonly) via > > >> > sysfs? > > >> > > > >> > I'm happy to help with a winbond-cir implementation; I have the hardware. > > >> > > > >> > > > >> > Sean > > >> > > >> Nuvoton-cir doesn't care about the IR protocol because the hardware > > >> compares raw IR pulse lengths and wakes the system if received pulse > > >> is within certain tolerance of the one pre-programmed to the HW. This > > >> approach is agnostic to the used IR protocol. > > > > > > Your patch talks about scancodes which is something entirely different. > > > This should be renamed to something better. > > > > > > > I agree that for the nuvoton my choice of wording (scancode) was a > > poor one. Perhaps wakeup_code would suit both drivers? > > > > > So with the nuvoton you program a set of pulses and spaces; with the > > > winbond you set the protocol and the scancode. I don't think there is > > > any shared code here. Maybe it's better to implement the wakeup > > > sysfs files in the drivers themselves rather than in rcdev, I guess that > > > depends on whether there are other devices that implement similar > > > functionality. > > > > > > > The code to be shared is the logic of creating, parsing and formatting > > the sysfs file. In the end the drivers are only interested in getting > > a bunch of values to write to the hardware. > > > > I was thinking about adding another file (wakeup_protocol sounds good) > > which would tell what semantics are used to interpret the contents of > > wakeup_code file (rc6, rc5, nec or raw). Would this be a decent > > solution? > > Good idea. I like it. Not sure if you saw it, but there's already another patchset proposing that, that got submitted before this changeset: https://patchwork.linuxtv.org/patch/21625/ > > Sean -- Cheers, Mauro