Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752296AbdC0J2T (ORCPT ); Mon, 27 Mar 2017 05:28:19 -0400 Received: from bny206.haproxy.com ([37.58.153.206]:42060 "EHLO smtp.exceliance.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751394AbdC0J1h (ORCPT ); Mon, 27 Mar 2017 05:27:37 -0400 Date: Mon, 27 Mar 2017 11:01:53 +0200 From: Willy TARREAU To: Geert Uytterhoeven Cc: Andy Shevchenko , Miguel Ojeda Sandonis , Arnd Bergmann , Greg Kroah-Hartman , "linux-kernel@vger.kernel.org" , Linus Walleij Subject: Re: [PATCH v1 1/2] auxdisplay: Move panel.c to drivers/auxdisplay folder Message-ID: <20170327090153.GC28802@haproxy.com> References: <20170324140635.56565-1-andriy.shevchenko@linux.intel.com> <1490365775.21738.7.camel@linux.intel.com> <20170327081111.GA28802@haproxy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2368 Lines: 46 On Mon, Mar 27, 2017 at 10:26:07AM +0200, Geert Uytterhoeven wrote: > On Mon, Mar 27, 2017 at 10:11 AM, Willy TARREAU wrote: > > On Fri, Mar 24, 2017 at 04:19:43PM +0100, Geert Uytterhoeven wrote: > >> On Fri, Mar 24, 2017 at 3:29 PM, Andy Shevchenko > >> wrote: > >> > On Fri, 2017-03-24 at 15:19 +0100, Geert Uytterhoeven wrote: > >> >> On Fri, Mar 24, 2017 at 3:06 PM, Andy Shevchenko > >> >> wrote: > >> >> > It looks like panel.c belongs to auxdisplay subsystem. > >> >> > > >> >> > Move it to drivers/auxdisplay folder. > >> >> > No functional changes intended. > >> >> > >> >> I didn't move it to drivers/auxdisplay/ because it not only provides > >> >> auxdisplay functionality, but also keypad functionality. > >> > > >> > Yes, I have noticed this. But keypad functionality is optional while > >> > panel is main one. I think you would agree on this. > >> > >> I don't care that much, though. Willy? > > > > Well, as long as it continues to work, I don't really care either. The > > only thing to keep in mind is that it can be difficult to split the > > driver in two since in some cases it's possible to use the same lines > > for keypad and lcd. > > Ideally, it should be replaced by a glue driver using charlcd, matrix-keypad, > and (still to be written?) gpio-parport ;-) It would still not be enough because the same GPIO line may be used both for LCD and keypad, so there's a need for being able to share the same line. The typical use case is when you connect the buttons to the D0-D7 data lines of the parport and feed them back to one entry like ACK, BUSY or PE. When data are sent to the LCD, if a button is pressed, it will act on the input signal but we don't care because the keypad driver is not watching. And conversely, when the keypad driver scans the buttons, it will change the data lines state but the LCD doesn't care because its E line remains low. In fact here the output signals should be seen as a shared bus with multiple chip select signals. Note that in some designs it's even possible that pressing multiple buttons will cause crap to be sent to the LCD by short-circuiting the lines (if no diodes are used) but it might be acceptable for many designs, especially the DIY field where the principle is "don't do it". Cheers, Willy