All of lore.kernel.org
 help / color / mirror / Atom feed
From: maxime.ripard@free-electrons.com (Maxime Ripard)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/5] regulator: axp20x: Update the bindings to use a local parent regulator
Date: Fri, 6 Jun 2014 18:05:52 +0200	[thread overview]
Message-ID: <20140606160552.GC9791@lukather> (raw)
In-Reply-To: <20140605154931.GY2520@sirena.org.uk>

On Thu, Jun 05, 2014 at 04:49:31PM +0100, Mark Brown wrote:
> On Thu, Jun 05, 2014 at 04:27:29PM +0200, Maxime Ripard wrote:
> 
> > You already list the regulators available and their supply in the
> > regulator driver, why do you need to set the regulator parents in the
> > mfd driver as well?
> 
> Unless they're being used by the MFD directly there should be no need
> for the MFD to know anything about the supplies.

Ok.

> > My guess is that it's to work around the fact that
> > regulator_dev_lookup only looks for the regulator's device of_node (so
> > not the PMIC one, but one of its child), which doesn't have the supply
> > properties, and then just falls back on the regulator alias
> > list. Would it make some sense to add a lookup in the parent device
> > of_node (which would be the "main" PMIC node in our case)?
> 
> This sounds like you are passing the MFD child device into the regulator
> API when you should be passing the parent device in.

We're passing the device coming from the platform_device that is
passed in probe, that has been created by mfd_add_device, which is
indeed the child device from the MFD device. So we should always use
the platform device parent's instead?

> > Also, there's also the fact that all the supply properties seems to
> > also be mandatory in the DT, even though the regulator itself might
> > not be used at all on the board, and the input voltage not wired to
> > anything.
> 
> For electrical engineering reasons it's unlikely that the supplies are
> actually floating but yes, they are mandatory.  This is an issue with
> registering one device for the entire regulator subsystem on the PMIC,
> it interacts somewhat poorly with deferred probe.  However for systems
> with full constraints like DT and ACPI ones it should be mostly
> sidestepped since the if there is no supply mapped a dummy supply will
> be substituted.

Yes, they are actually tied to the ground, but it's still something
meaningless, that I guess shouldn't be expressed in the DT?

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140606/cebe4eac/attachment.sig>

WARNING: multiple messages have this Message-ID (diff)
From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: Mark Brown <broonie@kernel.org>
Cc: carlo@caione.org, Boris Brezillon <boris@free-electrons.com>,
	lgirdwood@gmail.com, lee.jones@linaro.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, kevin.z.m.zh@gmail.com,
	sunny@allwinnertech.com, shuge@allwinnertech.com,
	zhuzhenhua@allwinnertech.com
Subject: Re: [PATCH 3/5] regulator: axp20x: Update the bindings to use a local parent regulator
Date: Fri, 6 Jun 2014 18:05:52 +0200	[thread overview]
Message-ID: <20140606160552.GC9791@lukather> (raw)
In-Reply-To: <20140605154931.GY2520@sirena.org.uk>

[-- Attachment #1: Type: text/plain, Size: 2171 bytes --]

On Thu, Jun 05, 2014 at 04:49:31PM +0100, Mark Brown wrote:
> On Thu, Jun 05, 2014 at 04:27:29PM +0200, Maxime Ripard wrote:
> 
> > You already list the regulators available and their supply in the
> > regulator driver, why do you need to set the regulator parents in the
> > mfd driver as well?
> 
> Unless they're being used by the MFD directly there should be no need
> for the MFD to know anything about the supplies.

Ok.

> > My guess is that it's to work around the fact that
> > regulator_dev_lookup only looks for the regulator's device of_node (so
> > not the PMIC one, but one of its child), which doesn't have the supply
> > properties, and then just falls back on the regulator alias
> > list. Would it make some sense to add a lookup in the parent device
> > of_node (which would be the "main" PMIC node in our case)?
> 
> This sounds like you are passing the MFD child device into the regulator
> API when you should be passing the parent device in.

We're passing the device coming from the platform_device that is
passed in probe, that has been created by mfd_add_device, which is
indeed the child device from the MFD device. So we should always use
the platform device parent's instead?

> > Also, there's also the fact that all the supply properties seems to
> > also be mandatory in the DT, even though the regulator itself might
> > not be used at all on the board, and the input voltage not wired to
> > anything.
> 
> For electrical engineering reasons it's unlikely that the supplies are
> actually floating but yes, they are mandatory.  This is an issue with
> registering one device for the entire regulator subsystem on the PMIC,
> it interacts somewhat poorly with deferred probe.  However for systems
> with full constraints like DT and ACPI ones it should be mostly
> sidestepped since the if there is no supply mapped a dummy supply will
> be substituted.

Yes, they are actually tied to the ground, but it's still something
meaningless, that I guess shouldn't be expressed in the DT?

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2014-06-06 16:05 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-28 17:11 [PATCH 0/5] regulator: Enhance AXP209 DT support Maxime Ripard
2014-05-28 17:11 ` Maxime Ripard
2014-05-28 17:11 ` [PATCH 1/5] regulator: Allow to pass the device node to regulator_dev_lookup Maxime Ripard
2014-05-28 17:11   ` Maxime Ripard
2014-05-28 17:11 ` [PATCH 2/5] regulator: Pass the config " Maxime Ripard
2014-05-28 17:11   ` Maxime Ripard
2014-05-28 17:11 ` [PATCH 3/5] regulator: axp20x: Update the bindings to use a local parent regulator Maxime Ripard
2014-05-28 17:11   ` Maxime Ripard
2014-05-28 18:50   ` Mark Brown
2014-05-28 18:50     ` Mark Brown
2014-06-03 13:12     ` Maxime Ripard
2014-06-03 13:12       ` Maxime Ripard
2014-06-03 14:43       ` Mark Brown
2014-06-03 14:43         ` Mark Brown
2014-06-05 14:27         ` Maxime Ripard
2014-06-05 14:27           ` Maxime Ripard
2014-06-05 15:49           ` Mark Brown
2014-06-05 15:49             ` Mark Brown
2014-06-06 16:05             ` Maxime Ripard [this message]
2014-06-06 16:05               ` Maxime Ripard
2014-08-16 13:58               ` Mark Brown
2014-08-16 13:58                 ` Mark Brown
2014-05-28 17:11 ` [PATCH 4/5] mfd: axp209x: Drop the parent supplies field Maxime Ripard
2014-05-28 17:11   ` Maxime Ripard
2014-05-29  7:37   ` Lee Jones
2014-05-29  7:37     ` Lee Jones
2014-05-28 17:11 ` [PATCH 5/5] ARM: sun7i: cubieboard2: Enable the AXP209 Maxime Ripard
2014-05-28 17:11   ` Maxime Ripard
2014-05-28 18:47 ` [PATCH 0/5] regulator: Enhance AXP209 DT support Mark Brown
2014-05-28 18:47   ` Mark Brown
2014-06-03 13:09   ` Maxime Ripard
2014-06-03 13:09     ` Maxime Ripard
2014-06-03 13:56     ` Mark Brown
2014-06-03 13:56       ` Mark Brown

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=20140606160552.GC9791@lukather \
    --to=maxime.ripard@free-electrons.com \
    --cc=linux-arm-kernel@lists.infradead.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 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.