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 X-Spam-Level: X-Spam-Status: No, score=-12.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 18E25C4708C for ; Thu, 27 May 2021 10:41:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CD37D613BA for ; Thu, 27 May 2021 10:41:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236210AbhE0KnS (ORCPT ); Thu, 27 May 2021 06:43:18 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:60970 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236103AbhE0KnR (ORCPT ); Thu, 27 May 2021 06:43:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1622112104; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DyoTEweFTx1lpA7uX8L7ddsbfDTqub/v0D1/rQ9tIVc=; b=Vb8P/OR96c9bTPhyhSYrSfrAeMhva02sg+8pmFEzoQk5jpWAb09RNamJJA8FfZp+hsxr5D zLXKK0RdKp7L2J103iR7u//CKx3AM83AJoTHhbtdDRbKoCbVf0r4aSkCxhVMCJFREECRGL Kqlem7AEzXgjbufMG5GuqzxpniTjjJI= Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com [209.85.218.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-344-HzemN6OGMUi0-4kPagC7jQ-1; Thu, 27 May 2021 06:41:43 -0400 X-MC-Unique: HzemN6OGMUi0-4kPagC7jQ-1 Received: by mail-ej1-f69.google.com with SMTP id la2-20020a170906ad82b02903d4bcc8de3bso1496865ejb.4 for ; Thu, 27 May 2021 03:41:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=DyoTEweFTx1lpA7uX8L7ddsbfDTqub/v0D1/rQ9tIVc=; b=YXo4IBrZ9f0BSki/6LezfgSV2Q4QkN0MY1fr2DblwoPvae4kyWRcdaRH4I5+qlczFr TWSxs6UOoaqLhnynilOfxFWoQ0RifNa7q4FQuXFSfAZG5AH6Sfhx4/V1y8A7YKhUmEVX Sgp1S5mGuKQQKTDhQtJuRty8fqlo4sejfvmsyLIC186fgnyVlmyhtu/1CWa+n02hREAA WlA9MS1rRjtx6ee1ycECZk9nivrKbOYs2J8bF2TFgJy5swRVoldDQ4rteJkqX9XT5xwZ hbT+CzS6/LC0fZb8R3/f5leticDKfd4wojdeS57rAl9AsZgnNp0zDiGVGrcUz1UQRjeW 7Ydw== X-Gm-Message-State: AOAM532q2RA8WImkrCRLJTFbSjdu3kN9jB88bi27StVBi/LYEMWc2brE tI1ZlRsckEIWj2k9HNbEbdhRVdesY2mwF+G5MlCJ9R+71RpwCQJZcfjLqD1HYc4sc+lg2f6JhPm T+umrcfQcWRU0inT7zpDl/m4yHTLuPUvoVXeyk+l0eK9P/OVQVTXSyFlYuU/HPlLHOPuMyBbwqs Uy X-Received: by 2002:a17:906:6d43:: with SMTP id a3mr3104894ejt.142.1622112100975; Thu, 27 May 2021 03:41:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy/B6NLDpnHprnd+r3zEqXv6WFixw8qwba7jliY2CHxhFvNGGR2p5k490P1utig7Gjm74mdvA== X-Received: by 2002:a17:906:6d43:: with SMTP id a3mr3104861ejt.142.1622112100604; Thu, 27 May 2021 03:41:40 -0700 (PDT) Received: from x1.localdomain (2001-1c00-0c1e-bf00-1054-9d19-e0f0-8214.cable.dynamic.v6.ziggo.nl. [2001:1c00:c1e:bf00:1054:9d19:e0f0:8214]) by smtp.gmail.com with ESMTPSA id b9sm872604edt.71.2021.05.27.03.41.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 May 2021 03:41:40 -0700 (PDT) Subject: Re: [PATCH v3 0/6] RTL8231 GPIO expander support To: Andy Shevchenko , Sander Vanheule Cc: Andrew Lunn , Pavel Machek , Rob Herring , Lee Jones , Mark Brown , Greg Kroah-Hartman , "Rafael J . Wysocki" , Michael Walle , Linus Walleij , Bartosz Golaszewski , Linux LED Subsystem , devicetree , "open list:GPIO SUBSYSTEM" , Linux Kernel Mailing List References: <02bbf73ea8a14119247f07a677993aad2f45b088.camel@svanheule.net> <8f96b24d782e5bdeabf5370ccf3475794d0c2818.camel@svanheule.net> From: Hans de Goede Message-ID: <96026395-250a-e6ed-fc12-782c8bc54dc6@redhat.com> Date: Thu, 27 May 2021 12:41:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 5/27/21 12:38 PM, Andy Shevchenko wrote: > +Cc: Hans > > Hans, sorry for disturbing you later too much. Here we have "nice" > hardware which can't be used in a glitch-free mode (somehow it reminds > me lynxpoint, baytrail, cherryview designs). If you have any ideas to > share (no need to dive deep or look at it if you have no time), you're > welcome. I'm afraid I've no ideas how to solve this nicely. Documenting the issue might be the best we can do. Regards, Hans > > On Thu, May 27, 2021 at 12:02 AM Sander Vanheule wrote: >> >> On Tue, 2021-05-25 at 20:11 +0300, Andy Shevchenko wrote: >>> On Mon, May 24, 2021 at 7:30 PM Andy Shevchenko >>> wrote: >>>> On Mon, May 24, 2021 at 6:03 PM Sander Vanheule >>>> wrote: >>>>> On Mon, 2021-05-24 at 15:54 +0300, Andy Shevchenko wrote: >>> >>> ... >>> >>>>> Sadly, I don't. Most of the info we have comes from code archives of >>>>> switch >>>>> vendors (Zyxel, Cisco etc). Boards need to be reverse engineered, and the >>>>> few >>>>> leaked datasheets that can be found on the internet aren't exactly thick >>>>> in >>>>> information. >>>>> >>>>> The RTL8231 datasheet is actually quite useful, but makes no mention of >>>>> the >>>>> output value isse. Since this isn't an official resource, I don't think it >>>>> would >>>>> be appropriate to link it via a Datasheet: tag. >>>>> https://github.com/libc0607/Realtek_switch_hacking/blob/files/RTL8231_Datasheet_ >>>>> 1.2.pdf >>>>> >>>>> Looking at the datasheet again, I came up with a... terrible hack to work >>>>> around >>>>> the output value issue. >>>>> >>>>> The chip also has GPIO_INVERT registers that I hadn't used until now, >>>>> because >>>>> the logical inversion is handled in the kernel. However, these inversion >>>>> registers only apply to the output values. So, I could implement glitch- >>>>> free >>>>> output behaviour in the following way: >>>>> * After chip reset, and before enabling the output driver (MFD >>>>> initialisation): >>>>> - Mux all pins as GPIO >>>>> - Change all pins to outputs, >>>> >>>> No. no, no. This is much worse than the glitches. You never know what >>>> the hardware is connected there and it's potential breakage (on hw >>>> level) possible. >>>> >>>>> so the data registers (0x1c-0x1e) become writable >>>>> - Write value 0 to all pins >>>>> - Change all pins to GPI to change them into high-Z >>>>> * In the pinctrl/gpio driver: >>>>> - Use data registers as input-only >>>>> - Use inversion register to determine output value (can be written any >>>>> time) >>>>> >>>>> The above gives glitch-free outputs, but the values that are read back >>>>> (when >>>>> configured as output), come from the data registers. They should now be >>>>> coming >>>>> from the inversion (reg_set_base) registers, but the code prefers to use >>>>> the >>>>> data registers (reg_dat_base). >>>> >>>> Lemme read the datasheet and see if I find any clue for the hw behaviour. >>> >>> Thank you for your patience! >>> >>> Have you explored the possibility of using En_Sync_GPIO? >> >> Got around to testing things. >> >> If En_Sync_GPIO is enabled, it's still possible to change the pin direction >> without also writing the Sync_GPIO bit. So even with the latching, glitches are >> still produced. >> >> As long as Sync_GPIO is not set to latch the new values, it also appears that >> reads of the data registers result in the current output value, not the new one. >> >> As a different test, I've added a pull-down, to make the input level low. Now I >> see the opposite behaviour as before (with set-value-before-direction): >> * OUT-HIGH > IN (low) > OUT-LOW: results in a high level (i.e. old value) >> * OUT-HIGH > IN (low) > OUT-HIGH: results in a high level (new/old value) >> * OUT-LOW > IN (low) > OUT-HIGH: results in a high level (new value, or toggled >> old value?) >> * OUT-LOW > IN (low) > OUT-LOW: results in a low level (new/old value) >> >> For reference, with a pull-up: >> * OUT-HIGH > IN (high) > OUT-HIGH: high result >> * OUT-HIGH > IN (high) > OUT-LOW: low result >> * OUT-LOW > IN (high) > OUT-HIGH: low result >> * OUT-LOW > IN (high) > OUT-LOW: low result >> >> I've only tested this with the sysfs interface, so I don't know what the result >> would be on multiple writes to the data register (during input, but probably not >> very relevant). Nor have I tested direction changes if the input has changed >> between two output values. >> >> I may have some time tomorrow for more testing, but otherwise it'll have to wait >> until the weekend. Any other ideas in the meantime? > > No ideas so far. In x86 we used to have something similar (baytrail, > cherryview, lynxpoint), but it's firmware assisted. I think that this > hardware (realtek) is supposed either > - to be firmware / bootloader assisted, so in a way that platform is > preconfigured when Linux starts and any GPIO request won't be harmful > as long as it doesn't change direction on the pins (which is usually > guaranteed by DT and corresponding drivers to do the correct things) > - be used for glitch-tolerant hardware (LEDs, for example, where > nobody usually will noticed 1ms blink) > > That said, I have not been convinced we have to quirk gpio-regmap for > this one. Just describe the issues with hardware in the accompanying > documentation. > > But if maintainers or somebody comes with a better / different > approach I am all ears. >