On Thu, Dec 15, 2022 at 7:16 AM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > > On Wed, Dec 14, 2022 at 10:53 AM Alexander Stein > <alexander.stein@xxxxxxxxxxxxxxx> 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... 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. Anything less is short enough to just hard code in a driver. Rob
