From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 49719C433EF for ; Tue, 12 Oct 2021 15:08:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2B6AC61076 for ; Tue, 12 Oct 2021 15:08:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232568AbhJLPKh (ORCPT ); Tue, 12 Oct 2021 11:10:37 -0400 Received: from mail-ua1-f52.google.com ([209.85.222.52]:34553 "EHLO mail-ua1-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229565AbhJLPKh (ORCPT ); Tue, 12 Oct 2021 11:10:37 -0400 Received: by mail-ua1-f52.google.com with SMTP id h4so19148134uaw.1; Tue, 12 Oct 2021 08:08:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/XLXN3xuVJOPHw5HRsxgIv5QkrLOCu749y9xpxhKV0I=; b=vhwsS8t3myfqtctpmEr/kYoGwR9fXtd4/EeW662Zm8QuRRx/KpifzFbmMPIU9Dqoga 8GJ4W6uE+cx3EGruvWA3gT1pII1ZJOiOmtFpaqBtZR/nLpCU5VMVzrQQkt088m1fsCzA c2mNoPC6+vufjPZp1CkA6MFAPNKjDcPmCxVNYxg/E2/mqaYDysPI/d3BOXI/a6w4UFsp oA4YJGHmTqSWt5TAPZ/c7Qx7gmgG33J8UOEXBXfackVxyO13Ihg/dMCVYmNBeVLsOwop E8C0o1wXNYQC3QXNDDfXvOR/DEPpclMSgLICHzc2A/20BIt8I/HdmGwyjZ2Hxdr9ivKu lzrQ== X-Gm-Message-State: AOAM5338ryK7zpD3fCwBT3pYf0o0Wi9V9z/2p2oksBFw1wON4ewCug/Q HW3xVZI5UCGgusLznFBX5eWeNaSIGhxJOG7h0yw= X-Google-Smtp-Source: ABdhPJx2RXQoSzE3pVGjeyVKDiENolt+HF3oWRJaUKqTdpAr/yDbBfb7YrzLDlKtQtHEEvyxafjPhHIcAcktEVDfYpE= X-Received: by 2002:a67:cb0a:: with SMTP id b10mr31833215vsl.9.1634051314899; Tue, 12 Oct 2021 08:08:34 -0700 (PDT) MIME-Version: 1.0 References: <20210914143835.511051-1-geert@linux-m68k.org> <20210914143835.511051-20-geert@linux-m68k.org> <4602a8e681db4d0ebc43e4dafee8c28e@protonic.nl> In-Reply-To: From: Geert Uytterhoeven Date: Tue, 12 Oct 2021 17:08:23 +0200 Message-ID: Subject: Re: [PATCH v6 19/19] auxdisplay: ht16k33: Add LED support To: Robin van der Gracht Cc: Miguel Ojeda , Rob Herring , Paul Burton , Greg Kroah-Hartman , Pavel Machek , Marek Behun , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , linux-leds , "open list:BROADCOM NVRAM DRIVER" , Linux Kernel Mailing List , =?UTF-8?B?TWFyZWsgQmVow7pu?= Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org Hoi Robin, On Mon, Oct 4, 2021 at 10:26 AM Robin van der Gracht wrote: > On 2021-10-01 17:51, Geert Uytterhoeven wrote: > > On Thu, Sep 30, 2021 at 12:57 PM Robin van der Gracht > > wrote: > >> On 2021-09-14 16:38, Geert Uytterhoeven wrote: > >> > Instantiate a single LED based on the "led" subnode in DT. > >> > This allows the user to control display brightness and blinking (backed > >> > by hardware support) through the LED class API and triggers, and exposes > >> > the display color. The LED will be named > >> > "auxdisplay::". > >> > > >> > When running in dot-matrix mode and if no "led" subnode is found, the > >> > driver falls back to the traditional backlight mode, to preserve > >> > backwards compatibility. > >> > > >> > Signed-off-by: Geert Uytterhoeven > >> > + > >> > + err = devm_led_classdev_register_ext(dev, led, &init_data); > >> > + if (err) > >> > + dev_err(dev, "Failed to register LED\n"); > >> > >> You might want to call ht16k33_brightness_set(priv, brightness) here to get > >> a > >> know value into the display setup register (0x80). > >> > >> Right now if I enable hardware blinking and (soft)reboot my board it keeps > >> on > >> blinking even after a re-probe. > > > > I don't have that issue. > > Aha, ht16k33_seg_probe() calls ht16k33_brightness_set(), but > > ht16k33_fbdev_probe() doesn't. The latter should do that, too, > > when not using backwards compatibility mode. > > Ack. I have hardware which uses the ht16k33 in dot matrix mode and I tested > both the backlight and led setup. I ran into this with the fbdev + led setup. > > I noticed ht16k33_bl_update_status() is called in ht16k33_fbdev_probe() > before the fbdev device is registered. Which is fine right now, but in theory > the fbdev blank state can influence the backlight setting (nitpick since > the fbdev device is unblanked by default). > > The point: Maybe ht16k33_brightness_set() (or ht16k33_bl_update_status() for > backlight device) should be called in one central place (i.e at the end of > the > main probe function). That would mean the main function need to know more about which mode is being used, so I think it's better to leave it to the individual display sub-drivers. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds