Message-ID: <20170626174239.GF26156@verge.net.au>
Date:   Mon, 26 Jun 2017 19:42:40 +0200
From:   Simon Horman <horms@...ge.net.au>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Jacopo Mondi <jacopo+renesas@...ndi.org>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Chris Brandt <chris.brandt@...esas.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Russell King <linux@...linux.org.uk>,
        Dong Aisheng <aisheng.dong@....com>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v6 00/8] Renesas RZ/A1 pin and gpio controller

On Mon, Jun 26, 2017 at 10:45:22AM +0200, Geert Uytterhoeven wrote:
> Hi Linus,
> 
> On Thu, Jun 22, 2017 at 4:54 PM, Jacopo Mondi <jacopo+renesas@...ndi.org> wrote:
> >    this is 6th round of RZ/A1 pin controller patch series.
> >
> > Where did we stop: discussion from pin controller driver shifted toward two
> > new generic pin configuration properties I added to the previous series
> > (bi-directional and output-enable).
> >
> > After a really long discussion, we decided to go for handling internally all
> > bi-directional use cases, making the generic property not a requirement for the
> > series. Interestingly, we recently found out the number of pins actually
> > requiring this flag is less (~half) than what reported by the processor manual,
> > so we could have handled these internally from day one :(
> >
> > We also now manage internally pins requiring IO direction specified in software
> > even when configured in alternate function mode (SWIO mode). Most of them are
> > handled by the driver, some of them have to come from DTS as the user can freely
> > select if they have to be inputs or outputs. For those pins, and after another
> > discussion involving NXP developers, we decided to use input-enable and
> > output-enable properties. I have just sent a patch to add output-enable to the
> > generic pin configuration properties, but it is currently under discussion.
> >
> > However, none of the pins currently configured by mainline DTS require those
> > properties to be specified, so I have dropped in this driver any dependency on
> > output-enable property, and I'm using instead the already in place
> > PIN_CONFIG_OUTPUT one. Once output-enable will eventually be accepted, we can
> > update the driver to make use of it, but since there are no use cases for that
> > at the moment, it makes not too much sense holding this series back for that.
> >
> > The total memory occupation we were so worried about of bi-directional and swio
> > pin tables is now around 100 bytes, because of how the number of pins actually
> > needing those flags has  reduced and because of how we have arranged the
> > tables using bitfield structures (credits to Geert here).
> >
> > Having cleared out dependencies on new pin configuration properties and having
> > made configuration flags a driver specific issue, I hope this version can be
> > accepted and land in forthcoming pull request for Renesas PFC updates from
> > Geert, pending some feedback from the linux-gpio community.
> 
> If this is OK for you, I'd like to include the first 3 patches (plus a small
> fix I received offline from Chris Brandt[*]) in my final pull request of
> sh-pfc for v4.13 (which I have been postponing in anticipation of this driver).
> 
> After v4.13-rc1, Simon can queue up the DTS patches in his tree for v4.14.

Fine by me.

I have marked the dts patches as Deferred.
Jacopo, please repost or ping me once the driver changes have shown
up in an rc release - v4.13-rc1 sounds likely.

Powered by blists - more mailing lists