Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp4795655pxk; Wed, 30 Sep 2020 11:53:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwc+8Vlv9F+bMEyCEMZedpuLQqvbErnJPU6PThsUaIRSbh6DGl9RMdrdALY9sLX64BO0pQn X-Received: by 2002:a05:6402:10c6:: with SMTP id p6mr4327142edu.76.1601492023193; Wed, 30 Sep 2020 11:53:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601492023; cv=none; d=google.com; s=arc-20160816; b=R2qc1iSA/izWgwbGZZQ9AZd6dF0C1Yzg45L+3rB5bMau1ldNDxUe2a2iGK629afJSn 4GASV+lhNxtOCwBDAGVuacZGGOXLcNqc2qofkjbVsKQ4m7CN4y8Po+i8HQe6Y0ELrcPT nT5VEgA4eelqtG/4CDlt3vNNILwkPQwvdysy1cOMyu6YhqWlUGkfe96Or+ZFlUQPQJdy en+tmjNnr9RyH+Bmds2NsQr5yItDkeqxGH06FfKALFqHYcg7NvJvhRJXJq5TQe4zUAXU gZt7vP5iKu/sbRygpFklTxk2RHK9IvAVc3SzUajeu6q1iYUTLOB6c+Jd98WEG7nbqiVR spog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=Sg3JdskTv/baC1RIHHUI9THUReq0qsRlNzLxJycYwpY=; b=tORE+ZZduYGqXH2pAJX05InYvZFo1pC3B4Z5aIHgM6jI60sFRoC+12zUZRFskV93/O TI65o7a+DG3hOhNVmK/WEdloj91bDHlrdvng+y4U/VbZcshZD22CJAKURa+l0c2fYXZd i15XVPT4Pdo1OTpZaijVNS1wMh08Wo55z0jjt+s/JQlYhse0evXzFg9WMQoGArBgMHY3 o/Z4gNZ9wwMGj4ikhozvfRBAziBByvgVdLcj1a2T+BT1jqara6+GAYDzu+Wdzlplgp0T lm8nnBiWcGEERPClwptjp18pR6NlTi/Cb7ihVX2mD7yDB3d3kQT1EHLWgQjWWZdEPlgL XlgA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=iAx2GEEt; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id gx3si946182ejb.749.2020.09.30.11.53.19; Wed, 30 Sep 2020 11:53:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=iAx2GEEt; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1729204AbgI3SuX (ORCPT + 99 others); Wed, 30 Sep 2020 14:50:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45224 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725771AbgI3SuW (ORCPT ); Wed, 30 Sep 2020 14:50:22 -0400 Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [IPv6:2a00:1450:4864:20::544]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5844BC061755; Wed, 30 Sep 2020 11:50:22 -0700 (PDT) Received: by mail-ed1-x544.google.com with SMTP id t16so2996676edw.7; Wed, 30 Sep 2020 11:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Sg3JdskTv/baC1RIHHUI9THUReq0qsRlNzLxJycYwpY=; b=iAx2GEEtJ4eZu+wgiOzIuHUkDDjjYQtWB9JgMtllCOLUZM+wluabzrKEe/ivOUx6yY kgsCdXTtEWLEivK0FGWvR4KXAgbP1bL6imaFIsLRm7RAoJIpVG0tK83kUAj02duPE5+C FUvSKv8SSLHKQ+rJ7EKpAAZMXxWTMcrh0JPWXskB6xF8v1Unq8iJEgrjuUB8Md5twErC 1k9NCBsjb/Sge1F+3mva4jSWHVgPAm0edgdwfmjGmTPwoA6GsMSwdS8wMHzjZmBJER+Y Ix0x1Be1RXa6Gn9P4pjnt9xPo046R6dYJ6U8gYafZ6gU4UqAD9Kw5KFZDxd7eNRuszJR wESw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Sg3JdskTv/baC1RIHHUI9THUReq0qsRlNzLxJycYwpY=; b=XPl0gp7ZS8taOauBLsjVyJTExh1cma8hbgs02Fjpsf8UoHUfyXfaueGz4BfqeRuuBi j7KmueRN+Yj47KR1icf/GV8/ED0+AS3H7gd5yGBdS+On78aV2VmiTHYHlHTAxGKRf25z ekQi/myK3w+Z2hcbFCns/w0wJvaz5KD1Za676/XcpE0kqhkIzlmgc6rNUhEZf9kn5axR 6L8jWaxJ7NZXVlc6BtY9vuPv3YT24OSwbEB3yZbxuMCCOeHjLDeEDW+imsiJLVXDFRQN o1ueR6tSUNoAyKEE5CI/S5y7lFu8oM3OHDdBH8ZPxvr4wqERuSINQCpsH2kPmT04EMe7 NOIA== X-Gm-Message-State: AOAM533B76s4JZ6VltGuRsWiWek1EuNvYdTrpd64R8EFj0IG4ewdaUK/ 7+Mg1ZDuzKo1+R3RgwsYed6vn2jEKtoEGLsGDofxNjPc89rTujGB X-Received: by 2002:aa7:c1d0:: with SMTP id d16mr4106617edp.209.1601491820999; Wed, 30 Sep 2020 11:50:20 -0700 (PDT) MIME-Version: 1.0 References: <20200924054324.GB9471@atomide.com> <20200924060645.GD9471@atomide.com> <20200924070443.GF9471@atomide.com> <20200930051521.GN9471@atomide.com> <20200930091526.GQ9471@atomide.com> <20200930094714.GR9471@atomide.com> In-Reply-To: <20200930094714.GR9471@atomide.com> From: Trent Piepho Date: Wed, 30 Sep 2020 11:50:10 -0700 Message-ID: Subject: Re: [PATCH] ARM: dts: document pinctrl-single,pins when #pinctrl-cells = 2 To: Tony Lindgren Cc: Drew Fustini , Rob Herring , Linus Walleij , Jason Kridner , Robert Nelson , linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-gpio , Christina Quast Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 30, 2020 at 2:47 AM Tony Lindgren wrote: > > * Trent Piepho [200930 09:34]: > > > > Where do these flags go? In pinctrl-single,pins? Like: > > > > pinctrl-single,pins =3D ; > > > > But PIN_INPUT_PULLUP is a generic flag? Which is translated into the > > proper value by?? > > Yes that's what I was thinking, something like this with generic flags: > > pinctrl-single,pins =3D ; It doesn't seem like these patches help achieve that, since they create device tree binaries with a property that has the same name and number of cells, but the cells have a different meaning than above, and must be handled differently by the driver. So you either drop compatibility or need to forever deal with supporting an interim format that is being created by these patches. The conf and max are already split in (all but one) of the device tree SOURCE files via the macro with multiple fields. That does seem like a good step if you wanted to transition into something like the above. But splitting it in the binary too doesn't help. Is there a way the dtb now being created can turn into the above via a driver change? Absolutely not. So what's the point of an interim binary format? All that matters is what the source looks like, and since that doesn't change, nothing is accomplished. I'll also point out that the current generic pinconf, done not via flags but with multiple properties for each configurable parameter, has a drive strength properties with strength in mA or =C2=B5A as a parameter. How would you do that with generic bit flags? I don't think you can fit everything in pinconf-generic.h into one 32 bit cell. > > Or are you talking about replacing the existing pinctrl-0, > > pinctrl-names properties with a totally different system that looks > > more like gpio and interrupt handles? > > That would be even better :) Might be just too much to deal with.. > > In any case the parser code could already be generic if we had generic > flags based on #pinctrl-cells. But the pinctrl-single,pins isn't parsed. It just uses the values as they are. You'd have to write something to parse the cells and add more data to the dts that told the parser how to turn them into device specific values. It seems like that could eventually achieve basically what is happening already with the dts preprocessor converting symbolic constants into device specific values.