From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
To: Mark Brown <broonie@kernel.org>
Cc: Kukjin Kim <kgene.kim@samsung.com>,
Doug Anderson <dianders@chromium.org>,
Olof Johansson <olof@lixom.net>,
Yuvaraj Kumar C D <yuvaraj.cd@gmail.com>,
linux-samsung-soc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 6/6] ARM: dts: Add tps65090 FETs constraints
Date: Wed, 13 Aug 2014 15:34:12 +0200 [thread overview]
Message-ID: <53EB6954.3040207@collabora.co.uk> (raw)
In-Reply-To: <20140813122910.GQ17528@sirena.org.uk>
On 08/13/2014 02:29 PM, Mark Brown wrote:
>
> Please fix your mailer to word wrap at less than 80 columns, it makes
> your mails very hard to read when replying.
>
Sorry I had my wrap length configured to 80 but just changed to 74 now.
>> On 08/12/2014 11:27 PM, Mark Brown wrote:
>
> No, that makes no sense. If the voltage isn't allowed to change why
> should the constraints be specifying a range of voltages for it to be
> set to, especially a range with more than one value in it?
>
> Please try to think about what you're doing in design terms rather than
> just bashing on things until you get something that works in your use
> case, it's important that things are understandable so that we avoid
> fragility and special casing.
>
>> For fixed regulators (like fet4), mmc_regulator_set_ocr() just skips >> varying the regulator voltage but still expects to be able to obtain
>> its voltage.
>
> Which can be done with regulator_get_voltage().
>
Indeed. I'll change mmc_regulator_get_ocrmask() in MMC core then to use
regulator_can_change_voltage() to detect if the regulator is a fixed one
and call regulator_get_voltage() instead of list_voltage() in that case.
Do you agree that this is the correct solution?
Best regards,
Javier
WARNING: multiple messages have this Message-ID (diff)
From: javier.martinez@collabora.co.uk (Javier Martinez Canillas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 6/6] ARM: dts: Add tps65090 FETs constraints
Date: Wed, 13 Aug 2014 15:34:12 +0200 [thread overview]
Message-ID: <53EB6954.3040207@collabora.co.uk> (raw)
In-Reply-To: <20140813122910.GQ17528@sirena.org.uk>
On 08/13/2014 02:29 PM, Mark Brown wrote:
>
> Please fix your mailer to word wrap at less than 80 columns, it makes
> your mails very hard to read when replying.
>
Sorry I had my wrap length configured to 80 but just changed to 74 now.
>> On 08/12/2014 11:27 PM, Mark Brown wrote:
>
> No, that makes no sense. If the voltage isn't allowed to change why
> should the constraints be specifying a range of voltages for it to be
> set to, especially a range with more than one value in it?
>
> Please try to think about what you're doing in design terms rather than
> just bashing on things until you get something that works in your use
> case, it's important that things are understandable so that we avoid
> fragility and special casing.
>
>> For fixed regulators (like fet4), mmc_regulator_set_ocr() just skips >> varying the regulator voltage but still expects to be able to obtain
>> its voltage.
>
> Which can be done with regulator_get_voltage().
>
Indeed. I'll change mmc_regulator_get_ocrmask() in MMC core then to use
regulator_can_change_voltage() to detect if the regulator is a fixed one
and call regulator_get_voltage() instead of list_voltage() in that case.
Do you agree that this is the correct solution?
Best regards,
Javier
next prev parent reply other threads:[~2014-08-13 13:34 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-12 16:44 [PATCH 0/6] tps65090 DTS refactoring and improvements Javier Martinez Canillas
2014-08-12 16:44 ` Javier Martinez Canillas
2014-08-12 16:44 ` [PATCH 1/6] ARM: dts: Create fragment for tps65090 PMU Javier Martinez Canillas
2014-08-12 16:44 ` Javier Martinez Canillas
2014-08-12 16:44 ` Javier Martinez Canillas
2014-08-12 16:58 ` Mark Brown
2014-08-12 16:58 ` Mark Brown
2014-08-12 17:21 ` Javier Martinez Canillas
2014-08-12 17:21 ` Javier Martinez Canillas
[not found] ` <53EA4D1F.2030406-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
2014-08-12 17:33 ` Mark Brown
2014-08-12 17:33 ` Mark Brown
2014-08-12 17:33 ` Mark Brown
2014-08-13 16:12 ` Stephen Warren
2014-08-13 16:12 ` Stephen Warren
2014-08-12 16:44 ` [PATCH 2/6] ARM: dts: Use tps65090 fragment in exynos5250-snow Javier Martinez Canillas
2014-08-12 16:44 ` Javier Martinez Canillas
2014-08-12 16:44 ` [PATCH 3/6] ARM: dts: Create cros-tps65090 fragment Javier Martinez Canillas
2014-08-12 16:44 ` Javier Martinez Canillas
2014-08-12 16:44 ` Javier Martinez Canillas
2014-08-12 17:26 ` Doug Anderson
2014-08-12 17:26 ` Doug Anderson
2014-08-12 18:58 ` Javier Martinez Canillas
2014-08-12 18:58 ` Javier Martinez Canillas
2014-08-12 16:44 ` [PATCH 4/6] ARM: dts: Use cros-tps65090 fragment in Peach boards Javier Martinez Canillas
2014-08-12 16:44 ` Javier Martinez Canillas
2014-08-12 16:44 ` [PATCH 5/6] ARM: dts: Improve cros-tps65090 power scheme Javier Martinez Canillas
2014-08-12 16:44 ` Javier Martinez Canillas
2014-08-12 16:44 ` [PATCH 6/6] ARM: dts: Add tps65090 FETs constraints Javier Martinez Canillas
2014-08-12 16:44 ` Javier Martinez Canillas
2014-08-12 17:25 ` Mark Brown
2014-08-12 17:25 ` Mark Brown
2014-08-12 18:49 ` Javier Martinez Canillas
2014-08-12 18:49 ` Javier Martinez Canillas
2014-08-12 21:27 ` Mark Brown
2014-08-12 21:27 ` Mark Brown
2014-08-13 11:31 ` Javier Martinez Canillas
2014-08-13 11:31 ` Javier Martinez Canillas
[not found] ` <53EB4CA0.3010006-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
2014-08-13 12:29 ` Mark Brown
2014-08-13 12:29 ` Mark Brown
2014-08-13 12:29 ` Mark Brown
2014-08-13 13:34 ` Javier Martinez Canillas [this message]
2014-08-13 13:34 ` Javier Martinez Canillas
2014-08-13 15:51 ` Mark Brown
2014-08-13 15:51 ` Mark Brown
2014-08-13 16:58 ` Javier Martinez Canillas
2014-08-13 16:58 ` Javier Martinez Canillas
2014-08-13 16:16 ` Stephen Warren
2014-08-13 16:16 ` Stephen Warren
2014-08-13 17:01 ` Javier Martinez Canillas
2014-08-13 17:01 ` Javier Martinez Canillas
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=53EB6954.3040207@collabora.co.uk \
--to=javier.martinez@collabora.co.uk \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=kgene.kim@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=olof@lixom.net \
--cc=yuvaraj.cd@gmail.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.