Re: [RFC PATCH v2 0/3] gpio: Add gpio-delay support

[Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>]

On Thu, Dec 15, 2022 at 12:21:33PM -0600, Rob Herring wrote:
> On Thu, Dec 15, 2022 at 7:16 AM Linus Walleij wrote:
> > On Wed, Dec 14, 2022 at 10:53 AM Alexander Stein wrote:
> >
> > > thanks for the feedback I've received. This is the reworked RFC for
> > > adressing a platform specific ramp-up/ramp-down delay on GPIO outputs.
> > > Now the delays are neither specified as gpio-controller nor
> > > consumer-specific properties.
> > >
> > > v2 is a different approach than v1 in that it adds a new driver which will
> > > simply forward setting the GPIO output of specified GPIOs in OF node.
> > > The ramp-up/ramp-down delay can now be actually defined on consumer side,
> > > see Patch 1 or 3 for examples.
> >
> > I really like this approach, it looks better than I imagined.
> 
> It seems over-engineered to me. So far no comments on my 3 suggestions either...

I like the idea of handling this on the consumer's side, possibly with
standard foo-gpios-ramp-{up,down}-delay-us (name to be bikeshedded)
properties as you mentioned in the review of v1.

> One is to just use some GPIO flag bits. Say 4-bits of GPIO flags
> encoded as power of 2 ramp delay. We have to pick the units. For
> example, 100us*2^N, which gives you 200us-3.2s of delay.

This could probably work too.

> Anything less is short enough to just hard code in a driver.

In which driver though ? The whole point is that we should avoid
handling this in particular drivers.

-- 
Regards,

Laurent Pinchart