On Thu, Sep 14, 2017 at 03:54:56PM +0200, Linus Walleij wrote: > On Fri, Sep 1, 2017 at 8:57 PM, Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > > > here's the latest series of patches that implement the tighter IRQ chip > > integration as well as the banked GPIO infrastructure that we had > > discussed a couple of weeks/months back. > > Yes it has become really tasty now, don't you think :) > > I really like the series. > > Banks are handled in the core, exactly as I wanted. > > I will likely go in and change some things I don't like, like switching > num_pins in the bank to num_lines. I have preferred that terminology > to avoid confusion with pin control. So GPIO chips have lines, not pins. > But it's so minor that I can fix it up if you don't want to. I rebased this on today's linux-next and noticed that there was a small conflict. I can rebase and work in the changes that you requested. I'm travelling this week and next, so it may take until after -rc2 that I can send out a new version that's properly build-tested. > We also need to go in and patch Documentation/gpio/driver.txt > to represent the current best practice. But that can be later, > separate patch. > > > The first couple of patches are mostly preparatory work in order to > > consolidate all IRQ chip related fields in a new structure and create > > the base functionality for adding IRQ chips. > > > > After that, I've added the Tegra186 GPIO support patch that makes use of > > the new tight integration. > > > > To round things off the new banked GPIO infrastructure is added (along > > with some more preparatory work), followed by the conversion of the two > > Tegra GPIO drivers to the new infrastructure. > > I have put all on a branch for pushing to the test builders to begin with. > > Then I plan to make one branch with all infrastructure patches > (patches 1-10, 12-14) and pull that into devel, then apply patch > 11 and 15-16 directly on devel. > > That way other subsystems (pinctrl ...) can pull in the infrastructure > for people adding new gpiochips this cycle. Sounds good. > > Any thoughts on this? I'd like to target 4.15 with this, > > Me, too. > > > unless you'd be > > willing to take this into 4.14, which I doubt at this point. The absence > > of a GPIO driver has been hampering Tegra186 support upstream for a > > while now, so it'd be good to make progress on this. > > Sorry about that. Let's move ahead with this now, it is neat and > clean. > > What I want (as maintainer) is a bit of fingerpointing at the drivers > that need to be converted to use the new banking infrastructure > so they don't stay with their old crappy design pattern. OMAP is > a clear candidate right? (Added Tony to CC...) OMAP should be able to use this infrastructure, but it may not want to because the semantics would change slightly. Currently OMAP registers a GPIO chip for each bank, whereas this infrastructure exposes multiple banks via a single chip. There might be some userspace that relies on the existence of multiple chips, but Tony can probably knows that better than I. > Who else? gpio-intel-mid.c and gpio-merrifield.c look like they could use this new infrastructure. So do gpio-pca953x.c, gpio-stmpe.c and gpio-tc3589x.c. gpio-ws16c48.c is another one that uses a similar pattern. Thierry
Attachment:
signature.asc
Description: PGP signature
