Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758259AbXINVQ3 (ORCPT ); Fri, 14 Sep 2007 17:16:29 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758048AbXINVQU (ORCPT ); Fri, 14 Sep 2007 17:16:20 -0400 Received: from pentafluge.infradead.org ([213.146.154.40]:52136 "EHLO pentafluge.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757536AbXINVQT (ORCPT ); Fri, 14 Sep 2007 17:16:19 -0400 Subject: Re: [linux-dvb] [PATCH] Userspace tuner From: Mauro Carvalho Chehab To: Aidan Thornton Cc: Michael Krufky , Manu Abraham , "video4linux-list@redhat.com" , "linux-kernel@vger.kernel.org" , "akpm@linux-foundation.org" , "linux-dvb@linuxtv.org" In-Reply-To: References: <46E9DDC7.4000403@hauppauge.com> <20070914113838.GA29962@linuxtv.org> <1189791161.2363.8.camel@gaivota> <1189794551.2363.36.camel@gaivota> <37219a840709141220p543b0da9x53f48eabc1cfe8c9@mail.gmail.com> Content-Type: text/plain Date: Fri, 14 Sep 2007 18:16:09 -0300 Message-Id: <1189804569.2363.93.camel@gaivota> Mime-Version: 1.0 X-Mailer: Evolution 2.11.92-2mdv2008.0 Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1321 Lines: 31 > > There is no reason why the Xceive driver cannot be merged into the > > current development tree using the hybrid tuner framework as it stands > > today. > > I'm not convinced this is entirely true. In order to avoid unnecessary > reinitialisation of the device, the driver needs to know whether the > device is in analog or digital mode, and I can't see a way of doing it > with the current API. (I think existing drivers, such as the xc2028 > driver in one branch, use the older analog API and make the digital > driver a wrapper around it.) Again, I may be missing something. For sure there are some ways. One dirty way would be to add an static lock at xc3028 driver. You can rise the lock when firmware is being uploaded, removing it at the end. This would prevent the troubles you've mentioned. A cleaner way would be to create a tasklet for firmware upload. This will also prevent the driver for a long load time, due to firmware initialization (a similar change were recently added at ivtv driver). For sure there are other ways of doing this. Cheers, Mauro - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/