Received: by 10.223.185.116 with SMTP id b49csp3988853wrg; Mon, 26 Feb 2018 09:17:49 -0800 (PST) X-Google-Smtp-Source: AH8x224WABzOSGKwmJsP0A+ophzSpu2ZVSfV0xM6yci8OROWQkADVlYM9x2wD5foIX1CNTbNZO9O X-Received: by 2002:a17:902:27:: with SMTP id 36-v6mr11264482pla.128.1519665469485; Mon, 26 Feb 2018 09:17:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519665469; cv=none; d=google.com; s=arc-20160816; b=lH7nFpcewlEOKj4FgQbqQZf7ikACIbKWjtpQwFIr6cgCnO1VjD2MXvxvNX4FvddS/A EZoFuubJz1EFGGr8qaNArHK8kL6B4rgQmJD7EmZLOEIC8cdPeKWB6dmDfMKjjjtPqMDz gF3sD9Q56ZweffU1qApA72rw5KqFIlPqsy155XyWX4OiYnUBRuOl9rSFyrEDzarAJgxh OcqOEx0+heIsN4ge8B2PriiNwgm+bRhGPhfz5YjVkOldtfEKHxhsqZpkPhoAsXE570Rh CA9M7eM3camC9MPOFD/VAEOAfc7bWd8egznzXJtG57eKqWnMiTf0VTviobUmLRG3whDt w1Sw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=UAKxtUoXjMivLDoeJEJvXPCzxSQ3CZgzVgZiAjD8bIE=; b=PIfjheV60uIX4kOHw1KlCAs2eUfTidTUNcbEKo0WMudBph78HO1ryX00YXigEBG4hO 48THyeIThcSZeRh5E7ReIzucrg8uSoWbQkXwdWc9RFCiHVoGJSzQ7g5m56QlnsI5dtLV eY7LjYG75YKu+TeBQDTzVTUgUrTVKCzwHmwAFtbmwL187L4VzlVMy5Y0Pq+dtmqafGGT SB4yVqKLgDQnwtVi8Sv3kSHe5OgTmcrxvGJ0bNXuwMSwHzGx9V4bXGc+tap9AAxAA23v ADUJMQ3L5NstvB1WwubdIaTScJVP7/OquHa2gMOSb7ezaJAw3Maca6Z32MIRYrK6aMIS pm2A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=rxB562lC; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m26si5758651pgc.438.2018.02.26.09.17.34; Mon, 26 Feb 2018 09:17:49 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=rxB562lC; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751737AbeBZRQ4 (ORCPT + 99 others); Mon, 26 Feb 2018 12:16:56 -0500 Received: from mail-qk0-f194.google.com ([209.85.220.194]:36759 "EHLO mail-qk0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751634AbeBZRQy (ORCPT ); Mon, 26 Feb 2018 12:16:54 -0500 Received: by mail-qk0-f194.google.com with SMTP id d206so19956588qkb.3 for ; Mon, 26 Feb 2018 09:16:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UAKxtUoXjMivLDoeJEJvXPCzxSQ3CZgzVgZiAjD8bIE=; b=rxB562lC18G15R+k3ynPBSiQqzwt4l/rAP5obToCgnvOSt40SixL+2oeEw/Li0rIeY JTJv5ZAolfisEA3kR4VlJuDNhVelem/qo6ZSEFRMF4Rm2sgaVPxn04a3gZJk/pqIm3c3 IiIkZyp8iavAzZ7WcmN7yEa2U1lWtoEThKExdAgxwsNDR9885dq8JGcuIYQ30EoDYP0m Z43xKmrtd7gCs6XEoLtSEDnjMePqyTVsR6MPItTKX4OyVWxD3JFEsOqV8PGW4+bTgIQQ rjZcwyaI2QsNZ/oc6zzKAMAmgbeu/0jNNuu4P9OGias02ZCTJ+KZPPcfIForWALcNz+9 WcMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UAKxtUoXjMivLDoeJEJvXPCzxSQ3CZgzVgZiAjD8bIE=; b=d+78MMzXhx94bmiFRRTHJTuJGJPfW8AZ2JO8FAN5zXLCmmm9a4eg65vYMv2s9m9JnX d6YwpzpY5zu+zVXSIR79IAZcYME8YwoQsyaF8ylOQgLL+oowlIN0mVuUoBwn83CA5Qs4 bm0fwn7z7P7vvwvffzxxFbsjn8UpWHULg1oEVDMrJxkCi2yAXjvHo5g62f5SJSzfCya5 mvn0bDODf9t4Jcb89zt40ssvyX14vhmXfECEn4yHdnLN8JCiZbBdYWI6CNKV+cCTu3pl J2A4LpBQxpmLpHip1zKbjmB/mkpwWzhAAVZSMwtoeH3ShlZUBfMc264XI7r7K/7t0W2V lUag== X-Gm-Message-State: APf1xPAfQb85VgCDI9LQxVROXyNQEkNBcUTvgK8aKa3+0AIhFZdLH9w2 s93WWDXk+pijKiQyQ1Ve4KNcUoKJZGpuArEpQOA= X-Received: by 10.55.88.7 with SMTP id m7mr18556809qkb.133.1519665414239; Mon, 26 Feb 2018 09:16:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.52.247 with HTTP; Mon, 26 Feb 2018 09:16:33 -0800 (PST) In-Reply-To: <20180225235432.31209-5-rabel@robertabel.eu> References: <9ec3c54c-f8fe-22d7-783e-8cf9862405bb@robertabel.eu> <20180225235432.31209-1-rabel@robertabel.eu> <20180225235432.31209-2-rabel@robertabel.eu> <20180225235432.31209-3-rabel@robertabel.eu> <20180225235432.31209-4-rabel@robertabel.eu> <20180225235432.31209-5-rabel@robertabel.eu> From: Miguel Ojeda Date: Mon, 26 Feb 2018 18:16:33 +0100 Message-ID: Subject: Re: [PATCH 4/4] auxdisplay: charlcd: make home command unshift display To: Robert Abel Cc: linux-kernel , Willy Tarreau , Geert Uytterhoeven , Andy Shevchenko Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 26, 2018 at 12:54 AM, Robert Abel wrote: > A user has no way of unshifting the display programmatically once shifted. > Users cannot rely on ^[[H (home) to result in their message being seen either. > Use the actual HOME command 0x02 instead of only returning to x0/y0. > Users can still do ^[[Lx0y0; (go to x/y) if they wish to use the 'old' home > function. > Implement fast clearing of LCD by going to x0/y0 first, clearing display and > then calling home to possibly unshift display possibly avoiding artifacts by > not unshifting before clearing display. Thanks for the patch! It seems reasonable. However, like in the previous patch, I feel that these commit messages describe -- usefully -- the current code and some of the decisions for its design, and as such they should be part of the code. Could you please put some of that reasoning in the actual code? i.e. as comments for the charlcd_clear_fast() and charlcd_home() functions, explaining why each of them is implemented the way it is. That would be great. Also hinting that the users can also use the "old" home functionality (or maybe implementing it as another third alternative). Then you can leave the commit message explaining only why the change was done, i.e. why it improves the previous situation, referring to the new functions. Cheers, Miguel > > Signed-off-by: Robert Abel > --- > drivers/auxdisplay/charlcd.c | 10 ++++++++-- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/drivers/auxdisplay/charlcd.c b/drivers/auxdisplay/charlcd.c > index 24cabe88c7f0..41f9aa4a73d4 100644 > --- a/drivers/auxdisplay/charlcd.c > +++ b/drivers/auxdisplay/charlcd.c > @@ -43,6 +43,8 @@ > /* LCD commands */ > #define LCD_CMD_DISPLAY_CLEAR 0x01 /* Clear entire display */ > > +#define LCD_CMD_HOME 0x02 /* Set DDRAM address to 0 and unshift display */ > + > #define LCD_CMD_ENTRY_MODE 0x04 /* Set entry mode */ > #define LCD_CMD_CURSOR_INC 0x02 /* Increment cursor */ > > @@ -182,7 +184,8 @@ static void charlcd_home(struct charlcd *lcd) > > priv->addr.x = 0; > priv->addr.y = 0; > - charlcd_gotoxy(lcd); > + lcd->ops->write_cmd(lcd, LCD_CMD_HOME); > + long_sleep(2); > } > > static void charlcd_print(struct charlcd *lcd, char c) > @@ -202,9 +205,12 @@ static void charlcd_print(struct charlcd *lcd, char c) > > static void charlcd_clear_fast(struct charlcd *lcd) > { > + struct charlcd_priv *priv = to_priv(lcd); > int pos; > > - charlcd_home(lcd); > + priv->addr.x = 0; > + priv->addr.y = 0; > + charlcd_gotoxy(lcd); > > if (lcd->ops->clear_fast) > lcd->ops->clear_fast(lcd); > -- > 2.11.0 >