All of lore.kernel.org
 help / color / mirror / Atom feed
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
To: Mark Brown <broonie@kernel.org>
Cc: Peter Griffin <peter.griffin@linaro.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <lgirdwood@gmail.com>,
	<srinivas.kandagatla@gmail.com>, <maxime.coquelin@st.com>,
	<patrice.chotard@st.com>, <lee.jones@linaro.org>,
	<devicetree@vger.kernel.org>,
	Youssef TRIKI <youssef.triki@st.com>
Subject: Re: [PATCH 2/5] regulator: st-flashss: Add a regulator driver for flashss vsense.
Date: Thu, 14 Apr 2016 16:15:34 +0200	[thread overview]
Message-ID: <570FA606.4070908@st.com> (raw)
In-Reply-To: <20160413172318.GC29471@sirena.org.uk>

Hello Mark

On 4/13/2016 7:23 PM, Mark Brown wrote:
> On Wed, Apr 13, 2016 at 09:59:00AM +0200, Giuseppe CAVALLARO wrote:
>> On 4/13/2016 8:15 AM, Mark Brown wrote:
>>>>> +static void st_get_satinize_powerup_voltage(struct st_vsense *vsense)
>>>>> +{
>
>>> or am I missing something?  Why do we need to do this anyway, it's very
>>> surprsing?
>
>> This functions is to sanitize the vsense voltages when the regulator
>> is probed and in some circumstances the reset value of this register
>> does not reflect the hw status/config. For example, by default, after
>> the reset, the bit 0 is set so the EMMC, inside the flash subsystem,
>> is supposed to operate at 3v3. But the latched bit 24 can be 0 on
>> a platform where it is actually set at 1v8.
>> So the bit 0 must be reset to keep this coherent and to allow MMC
>> framework to properly setup the Vdd when the framework starts.
>
> I'm afraid I can't follow that explanation, perhaps because I don't know
> anything about the content of this register except for these three bits.
> I think we do need a comment in the driver explaining what's going on,

yes you are right

> and probably a simplification of the code too if my understanding of the
> effect of all those operations is correct.

Maybe we can simplify the function as:

static void st_get_satinize_powerup_voltage(struct st_vsense *vsense)
{
	void __iomem *ioaddr = vsense->ioaddr;
	u32 value = readl_relaxed(ioaddr);

	/*
	 * After resetting, the CONFIG_REG_PSW_<xxx> are set, this
	 * means 3v3 operating voltage.
	 * The CONFIG_LATCHED_PSW_<xxx> must be used to fix the previous
	 * bits so operating at 1v8 if this is the real HW configuration
	 * at boot time.
	 */
	if (!(value & TOP_VSENSE_CONFIG_LATCHED_PSW_EMMC))
		value &= ~TOP_VSENSE_CONFIG_REG_PSW_EMMC;

	if (!(value & TOP_VSENSE_CONFIG_LATCHED_PSW_NAND))
		value &= ~TOP_VSENSE_CONFIG_REG_PSW_NAND;

	if (!(value & TOP_VSENSE_CONFIG_LATCHED_PSW_SPI))
		value &= ~TOP_VSENSE_CONFIG_REG_PSW_SPI;

	writel_relaxed(value, ioaddr);
}

Le me know if this looks a bit more clear.

Peppe

WARNING: multiple messages have this Message-ID (diff)
From: Giuseppe CAVALLARO <peppe.cavallaro-qxv4g6HH51o@public.gmane.org>
To: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Peter Griffin
	<peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	lgirdwood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	srinivas.kandagatla-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	maxime.coquelin-qxv4g6HH51o@public.gmane.org,
	patrice.chotard-qxv4g6HH51o@public.gmane.org,
	lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Youssef TRIKI <youssef.triki-qxv4g6HH51o@public.gmane.org>
Subject: Re: [PATCH 2/5] regulator: st-flashss: Add a regulator driver for flashss vsense.
Date: Thu, 14 Apr 2016 16:15:34 +0200	[thread overview]
Message-ID: <570FA606.4070908@st.com> (raw)
In-Reply-To: <20160413172318.GC29471-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>

Hello Mark

On 4/13/2016 7:23 PM, Mark Brown wrote:
> On Wed, Apr 13, 2016 at 09:59:00AM +0200, Giuseppe CAVALLARO wrote:
>> On 4/13/2016 8:15 AM, Mark Brown wrote:
>>>>> +static void st_get_satinize_powerup_voltage(struct st_vsense *vsense)
>>>>> +{
>
>>> or am I missing something?  Why do we need to do this anyway, it's very
>>> surprsing?
>
>> This functions is to sanitize the vsense voltages when the regulator
>> is probed and in some circumstances the reset value of this register
>> does not reflect the hw status/config. For example, by default, after
>> the reset, the bit 0 is set so the EMMC, inside the flash subsystem,
>> is supposed to operate at 3v3. But the latched bit 24 can be 0 on
>> a platform where it is actually set at 1v8.
>> So the bit 0 must be reset to keep this coherent and to allow MMC
>> framework to properly setup the Vdd when the framework starts.
>
> I'm afraid I can't follow that explanation, perhaps because I don't know
> anything about the content of this register except for these three bits.
> I think we do need a comment in the driver explaining what's going on,

yes you are right

> and probably a simplification of the code too if my understanding of the
> effect of all those operations is correct.

Maybe we can simplify the function as:

static void st_get_satinize_powerup_voltage(struct st_vsense *vsense)
{
	void __iomem *ioaddr = vsense->ioaddr;
	u32 value = readl_relaxed(ioaddr);

	/*
	 * After resetting, the CONFIG_REG_PSW_<xxx> are set, this
	 * means 3v3 operating voltage.
	 * The CONFIG_LATCHED_PSW_<xxx> must be used to fix the previous
	 * bits so operating at 1v8 if this is the real HW configuration
	 * at boot time.
	 */
	if (!(value & TOP_VSENSE_CONFIG_LATCHED_PSW_EMMC))
		value &= ~TOP_VSENSE_CONFIG_REG_PSW_EMMC;

	if (!(value & TOP_VSENSE_CONFIG_LATCHED_PSW_NAND))
		value &= ~TOP_VSENSE_CONFIG_REG_PSW_NAND;

	if (!(value & TOP_VSENSE_CONFIG_LATCHED_PSW_SPI))
		value &= ~TOP_VSENSE_CONFIG_REG_PSW_SPI;

	writel_relaxed(value, ioaddr);
}

Le me know if this looks a bit more clear.

Peppe
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: peppe.cavallaro@st.com (Giuseppe CAVALLARO)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/5] regulator: st-flashss: Add a regulator driver for flashss vsense.
Date: Thu, 14 Apr 2016 16:15:34 +0200	[thread overview]
Message-ID: <570FA606.4070908@st.com> (raw)
In-Reply-To: <20160413172318.GC29471@sirena.org.uk>

Hello Mark

On 4/13/2016 7:23 PM, Mark Brown wrote:
> On Wed, Apr 13, 2016 at 09:59:00AM +0200, Giuseppe CAVALLARO wrote:
>> On 4/13/2016 8:15 AM, Mark Brown wrote:
>>>>> +static void st_get_satinize_powerup_voltage(struct st_vsense *vsense)
>>>>> +{
>
>>> or am I missing something?  Why do we need to do this anyway, it's very
>>> surprsing?
>
>> This functions is to sanitize the vsense voltages when the regulator
>> is probed and in some circumstances the reset value of this register
>> does not reflect the hw status/config. For example, by default, after
>> the reset, the bit 0 is set so the EMMC, inside the flash subsystem,
>> is supposed to operate at 3v3. But the latched bit 24 can be 0 on
>> a platform where it is actually set at 1v8.
>> So the bit 0 must be reset to keep this coherent and to allow MMC
>> framework to properly setup the Vdd when the framework starts.
>
> I'm afraid I can't follow that explanation, perhaps because I don't know
> anything about the content of this register except for these three bits.
> I think we do need a comment in the driver explaining what's going on,

yes you are right

> and probably a simplification of the code too if my understanding of the
> effect of all those operations is correct.

Maybe we can simplify the function as:

static void st_get_satinize_powerup_voltage(struct st_vsense *vsense)
{
	void __iomem *ioaddr = vsense->ioaddr;
	u32 value = readl_relaxed(ioaddr);

	/*
	 * After resetting, the CONFIG_REG_PSW_<xxx> are set, this
	 * means 3v3 operating voltage.
	 * The CONFIG_LATCHED_PSW_<xxx> must be used to fix the previous
	 * bits so operating at 1v8 if this is the real HW configuration
	 * at boot time.
	 */
	if (!(value & TOP_VSENSE_CONFIG_LATCHED_PSW_EMMC))
		value &= ~TOP_VSENSE_CONFIG_REG_PSW_EMMC;

	if (!(value & TOP_VSENSE_CONFIG_LATCHED_PSW_NAND))
		value &= ~TOP_VSENSE_CONFIG_REG_PSW_NAND;

	if (!(value & TOP_VSENSE_CONFIG_LATCHED_PSW_SPI))
		value &= ~TOP_VSENSE_CONFIG_REG_PSW_SPI;

	writel_relaxed(value, ioaddr);
}

Le me know if this looks a bit more clear.

Peppe

  reply	other threads:[~2016-04-14 14:16 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-12 15:16 [PATCH 0/5] Add st-flashss vsense regulator driver Peter Griffin
2016-04-12 15:16 ` Peter Griffin
2016-04-12 15:16 ` [PATCH 1/5] regulator: st-flashss: Add DT binding documentation for flashss regulator Peter Griffin
2016-04-12 15:16   ` Peter Griffin
2016-04-12 15:16   ` Peter Griffin
2016-04-18 16:53   ` Rob Herring
2016-04-18 16:53     ` Rob Herring
2016-04-12 15:16 ` [PATCH 2/5] regulator: st-flashss: Add a regulator driver for flashss vsense Peter Griffin
2016-04-12 15:16   ` Peter Griffin
2016-04-13  6:15   ` Mark Brown
2016-04-13  6:15     ` Mark Brown
2016-04-13  6:15     ` Mark Brown
2016-04-13  7:59     ` Giuseppe CAVALLARO
2016-04-13  7:59       ` Giuseppe CAVALLARO
2016-04-13  7:59       ` Giuseppe CAVALLARO
2016-04-13 17:23       ` Mark Brown
2016-04-13 17:23         ` Mark Brown
2016-04-13 17:23         ` Mark Brown
2016-04-14 14:15         ` Giuseppe CAVALLARO [this message]
2016-04-14 14:15           ` Giuseppe CAVALLARO
2016-04-14 14:15           ` Giuseppe CAVALLARO
2016-04-14 15:25           ` Mark Brown
2016-04-14 15:25             ` Mark Brown
2016-04-14 15:25             ` Mark Brown
2016-04-12 15:16 ` [PATCH 3/5] MAINTAINERS: Add st-flashss driver to STi section Peter Griffin
2016-04-12 15:16   ` Peter Griffin
2016-04-12 15:16 ` [PATCH 4/5] ARM: multi_v7_defconfig: Enable flashss regulator driver Peter Griffin
2016-04-12 15:16   ` Peter Griffin
2016-04-12 15:16 ` [PATCH 5/5] ARM: STi: DT: STiH407: Add the flashss voltage regulator DT node Peter Griffin
2016-04-12 15:16   ` Peter Griffin

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=570FA606.4070908@st.com \
    --to=peppe.cavallaro@st.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=lee.jones@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maxime.coquelin@st.com \
    --cc=patrice.chotard@st.com \
    --cc=peter.griffin@linaro.org \
    --cc=srinivas.kandagatla@gmail.com \
    --cc=youssef.triki@st.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.