linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Mark Brown <broonie@kernel.org>,
	Linux Input <linux-input@vger.kernel.org>,
	Henrik Rydberg <rydberg@bitmath.org>
Subject: Re: [PATCH 2/2 v1] Input: cy8ctma140 - add driver
Date: Sun, 15 Mar 2020 15:22:48 -0700	[thread overview]
Message-ID: <20200315222248.GE192640@dtor-ws> (raw)
In-Reply-To: <CACRpkdZYU0zvjRC-2L-Ra=td0iUSPLhP3BFQKUTkh4POYHTNNg@mail.gmail.com>

On Sun, Mar 15, 2020 at 05:12:29PM +0100, Linus Walleij wrote:
> Hi Dmitry,
> 
> thanks for the quick review!
> 
> I fixed most stuff, just one minor comment:
> 
> On Tue, Mar 10, 2020 at 6:08 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> 
> > > +     /* According to datasheet this should be in the 2.7-3.6 V range */
> > > +     ret = regulator_set_voltage(ts->vcpin, 2700000, 3600000);
> > > +     if (ret) {
> > > +             dev_err(dev, "failed to set VCPIN voltage\n");
> > > +             return ret;
> > > +     }
> >
> > Shouldn't this already be in DT? We typically do not configure voltage
> > on various rail unless in very specific circumstances.
> 
> Certainly the DT defines the voltage range on the regulator
> on the producer side.
> 
> This is the consumer range, and DT has no facility to put
> restrictions on the consumer voltage window.
> 
> I think it is pretty natural to do in the code.

That means we will have essentially a boilerplate code in many many
drivers.

If we indeed want to do this (although I am not sure if practically this
makes much sense - nobody creates a rail delivering 24 volts by default
and saying "oh well, when driver loads it will request us to lower the
voltage down to 1.5V that components attached to the rail require") can
we consider adding consumer side constraints to the DT so that
regulator_get() can set the voltage right there and driver does not have
to? I am just trying to limit the amount of custom code in the drivers.

> 
> The typical usecase is when two components share the
> same line, and in this case two voltage consumer inputs
> *may* be connected to the same producer regulator.
> 
> The regulator framework will the infer that the producer
> can produce a voltage that fulfil the constraints on all the
> consumers.
> 
> The fact that few devices issue regulator_set_voltage()
> is a combination of "good enough" and general sloppiness,
> I think it should reflect the operation voltages of the component
> and stop people from shooting themselves in the foot.
> 
> But I CC Mark on this and see what he says. (I might be wrong.)

Thanks.

-- 
Dmitry

  reply	other threads:[~2020-03-15 22:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-10 14:28 [PATCH 1/2 v1] dt-bindings: touchscreen: Add CY8CTMA140 bindings Linus Walleij
2020-03-10 14:28 ` [PATCH 2/2 v1] Input: cy8ctma140 - add driver Linus Walleij
2020-03-10 17:08   ` Dmitry Torokhov
2020-03-10 17:09     ` Dmitry Torokhov
2020-03-15 16:12     ` Linus Walleij
2020-03-15 22:22       ` Dmitry Torokhov [this message]
2020-03-16 11:41         ` Mark Brown
2020-03-23 21:32 ` [PATCH 1/2 v1] dt-bindings: touchscreen: Add CY8CTMA140 bindings Rob Herring

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=20200315222248.GE192640@dtor-ws \
    --to=dmitry.torokhov@gmail.com \
    --cc=broonie@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-input@vger.kernel.org \
    --cc=rydberg@bitmath.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).