On Wed, Jun 28, 2017 at 07:36:15PM +0200, Geert Uytterhoeven wrote: > Hi Linus, > > On Mon, Jun 26, 2017 at 10:45 AM, Geert Uytterhoeven > <ge...@linux-m68k.org> wrote: > > On Thu, Jun 22, 2017 at 4:54 PM, Jacopo Mondi <jacopo+rene...@jmondi.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). > > And so I did. Queued in sh-pfc-for-v4.13, pull request sent.
I have applied up the dts changes on top of v4.13-rc1.
