From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161245AbdD1OxH (ORCPT ); Fri, 28 Apr 2017 10:53:07 -0400 Received: from mail-qt0-f178.google.com ([209.85.216.178]:34440 "EHLO mail-qt0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S969498AbdD1OxC (ORCPT ); Fri, 28 Apr 2017 10:53:02 -0400 MIME-Version: 1.0 In-Reply-To: References: <1493281194-5200-1-git-send-email-jacopo+renesas@jmondi.org> <1493281194-5200-2-git-send-email-jacopo+renesas@jmondi.org> From: Andy Shevchenko Date: Fri, 28 Apr 2017 17:53:00 +0300 Message-ID: Subject: Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable To: Chris Brandt Cc: Linus Walleij , Jacopo Mondi , Geert Uytterhoeven , Laurent Pinchart , Rob Herring , Mark Rutland , Russell King - ARM Linux , Linux-Renesas , "linux-gpio@vger.kernel.org" , devicetree , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v3SErWKl001766 On Fri, Apr 28, 2017 at 4:18 PM, Chris Brandt wrote: > On Friday, April 28, 2017, Andy Shevchenko wrote: >> > In the RZ/A1 HW manual you can kind of see that in 54.18 Port Control >> Logical Diagram (but that wasn't obvious to me at first). >> >> Please, post a link to it or copy essential parts. > The schematic is included in the "User's manual" > https://www.renesas.com/en-us/doc/products/tool/doc/003/r20ut2596ej_r7s72100evum.pdf Not that one I would like to see... > The RZ/A1H Hardware manual is here: > https://www.renesas.com/en-us/document/hw-manual?hwLayerShowFlg=true&prdLayerId=186374&layerName=RZ%252FA1H&coronrService=document-prd-search&hwDocUrl=%2Fen-us%2Fdoc%2Fproducts%2Fmpumcu%2Fdoc%2Frz%2Fr01uh0403ej0300_rz_a1h.pdf&hashKey=54f335753742b5add524d4725b7242e6 > > Chapter 54 is the port/pin controller. > > "54.18 Port Control Logical Diagram" is the diagram I was talking about. Note that is says "Note: This figure shows the logic for reference, not the circuit." > > "54.3.13 Port Bidirection Control Register (PBDCn)" is the magic register needed to get some pins to work. This is useful. Thanks. >> I'm quite skeptical that cheap hardware can implement something more >> costable than simplest open-source / open-drain + bias > > I don't think this is an open-source / open-drain + bias issue. It's a "the internal signal paths are not getting hooked up correctly" issue. Had you read the following, esp. Note there? * @PIN_CONFIG_INPUT_ENABLE: enable the pin's input. Note that this does not * affect the pin's ability to drive output. 1 enables input, 0 disables * input. For me manual is clearly tells about this settings: "This register enables or disables the input buffer while the output buffer is enabled." > Regardless, on this part, we needed a way to flag that some pins when put in some function modes needed 'an extra register setting'. At first we tried to sneak that info in with a simple #define in the pin/pinmux DT node properties. But, Linus didn't want it there so we had to make up a new generic property called "bi-directional". > > What is your end goal here? Get "bi-directional" changed to something else? My goal is to reduce amount of (useless) entities. See Occam's razor for details. Linus, for me it looks like better to revert that change, until we will have clear picture why existing configuration parameters can't work. -- With Best Regards, Andy Shevchenko