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;
Date:   Fri, 11 Jun 2021 10:29:41 +0200 (CEST)
From:   Dario Binacchi <dariobin@libero.it>
To:     Tony Lindgren <tony@atomide.com>,
        Linus Walleij <linus.walleij@linaro.org>
Cc:     Vladimir Zapolskiy <vz@mleia.com>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Drew Fustini <drew@beagleboard.org>,
        Andy Shevchenko <andy.shevchenko@gmail.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>
Message-ID: <1397253066.299778.1623400182022@mail1.libero.it>
In-Reply-To: <YLcRN0KSCpvCS4ET@atomide.com>
References: <20210520202730.4444-1-dariobin@libero.it>
 <20210520202730.4444-3-dariobin@libero.it>
 <87ea9971-9e15-c595-95cc-14c68b0b68d8@mleia.com>
 <1972814783.387983.1621877304255@mail1.libero.it>
 <414c9176-7922-929f-e82e-f80f07e91b2c@mleia.com>
 <106030092.519428.1622143415836@mail1.libero.it>
 <b25a0e33-d7e8-322a-2a73-bda6e88c8f8b@mleia.com>
 <2062056721.520514.1622147634190@mail1.libero.it>
 <CACRpkdZb4WZS8cd=nFz_J0GrBc5HJ8SMYtniB2W_Jpq_vtPTYQ@mail.gmail.com>
 <YLcRN0KSCpvCS4ET@atomide.com>
Subject: Re: [PATCH v3 2/3] pinctrl: core: configure pinmux from pins debug
 file
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Importance: Normal
Precedence: bulk

Hi,

> Il 02/06/2021 07:03 Tony Lindgren <tony@atomide.com> ha scritto:
> 
>  
> * Linus Walleij <linus.walleij@linaro.org> [210528 09:08]:
> > On Thu, May 27, 2021 at 10:33 PM Dario Binacchi <dariobin@libero.it> wrote:
> > > > Il 27/05/2021 21:57 Vladimir Zapolskiy <vz@mleia.com> ha scritto:
> > 
> > > > Unfortunately you continue to cling to the broken interface, while I see no
> > > > comments from you about asked to consider pin groups and pin group functions.
> > >
> > > Could you kindly explain to me, with some practical examples, what kind of interface
> > > would you implement ?
> > 
> > I am not fully understanding this discussion.
> > 
> > I get the feeling that this is caused by the early architectural decisions with
> > pinctrl-single to put all configuration of pin groups and functions per pin into
> > the device tree.
> >
> > Tony specifically wanted this because what he gets from TI are some raw
> > ASIC data dumps from the designers, that he could make a script to process
> > into device tree rather than into .h files, and get this out of the kernel.
> > (As I remember it, Tony correct me if I'm wrong.)
> 
> Yeah the idea was to avoid stuffing even more SoC specific data into the
> kernel and rather use devicetree data only for the booted SoC.
>  
> > This makes it hard to align some concepts of the pin control subsystem such
> > as functions and groups because pinctrl-single assume a 1-to-1 mapping
> > between one pin and one group, which in turn has a 1-to-many mapping
> > to functions.
> > 
> > Is the patch trying to debugfs around this somehow?
> > 
> > If this hack is only needed for pinctrl-single.c then it should be placed in
> > that driver, so Tony can review it and maintain it as applicable in that
> > driver's context only, not in the pinctrl core as it appears the general
> > applicability for other drivers is not there.
> > 
> > Would this really be useful for other drivers than pinctrl-single.c?
> 
> I'd rather go with a generic interface. I think it should work if we only
> allow enabling and disabling of unclaimed pingroups from sysfs. And then
> we can also allow creating new pingroups for unclaimed pins if needed.
> 

Could you kindly explain to me, with some practical examples, what kind of interface
would you implement ? Or something similar to start from that is already in the Kernel?

Thanks and regards,
Dario

> Regards,
> 
> Tony