All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>,
	Andy Shevchenko <andy@kernel.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	linux-gpio@vger.kernel.org
Subject: Re: [PATCH] pinctrl: baytrail: Pick first supported debounce value larger then the requested value
Date: Fri, 20 Aug 2021 16:11:56 +0300	[thread overview]
Message-ID: <YR+qHHVgALcpQ6k+@smile.fi.intel.com> (raw)
In-Reply-To: <20210819203952.785132-1-hdegoede@redhat.com>

On Thu, Aug 19, 2021 at 10:39:52PM +0200, Hans de Goede wrote:
> Bay Trail pin control only supports a couple of discrete debounce timeout
> values. Instead of returning -EINVAL for other values, pick the first
> supported debounce timeout value larger then the requested timeout.
> 
> E.g. on a HP ElitePad 1000 G2, where the ACPI tables specify a timeout of
> 20 ms for various _AIE ACPI event sources, this will result in a timeout
> of 24 ms instead of returning -EINVAL to the caller.

I would prefer to see case 1...375: case 376...750: It makes it more explicit
what we choose. Also it will be in align with debounce getter switch-case.
Nevertheless, there is the bigger problem here, which is that the debounce
setting is global per community and neither current nor new code addresses.

What we need is to have a bitmap of size 3-bit * N_pins (per community) to save
settings and each time we try to adjust them, we have to go through that bitmap
and check actual users and see if we have conflicting requests.

You may ask why we have to keep the actual debounce value and not the biggest
one. The reason why is simple, if the following flow of requests comes we will
have better setting at the end:

1) A asks for debounce of 1ms (we set to 1.5ms)
2) B asks for 10ms (we set likely to 12ms *)
3) B gone (we should return to 1.5ms)
4) C asks for 400us (*)

*) TBH I have no idea what to do with these cases, i.e. when better to satisfy
   the bigger, when issue warning, when just print a debug message. I admit
   that debounce on BYT has been not thought through on HW level.

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2021-08-20 13:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-19 20:39 [PATCH] pinctrl: baytrail: Pick first supported debounce value larger then the requested value Hans de Goede
2021-08-20 13:11 ` Andy Shevchenko [this message]
2021-08-23 10:32   ` Hans de Goede
2022-01-13 11:31     ` Andy Shevchenko
2022-01-13 11:56       ` Hans de Goede
2022-01-15 16:24         ` Hans de Goede
2022-01-18  9:12           ` Andy Shevchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YR+qHHVgALcpQ6k+@smile.fi.intel.com \
    --to=andriy.shevchenko@intel.com \
    --cc=andy@kernel.org \
    --cc=hdegoede@redhat.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.