linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
To: Mark Brown <broonie@kernel.org>
Cc: Yuvaraj Cd <yuvaraj.lkml@gmail.com>,
	Doug Anderson <dianders@chromium.org>,
	Olof Johansson <olof@lixom.net>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Abhilash Kesavan <a.kesavan@samsung.com>,
	Prashanth G <prashanth.g@samsung.com>,
	Alim Akhtar <alim.akhtar@samsung.com>,
	sunil joshi <joshi@samsung.com>
Subject: Re: [PATCH v9 1/2] regulator: Add driver for max77802 PMIC PMIC regulators
Date: Fri, 22 Aug 2014 19:53:19 +0200	[thread overview]
Message-ID: <53F7838F.8060906@collabora.co.uk> (raw)
In-Reply-To: <20140822144531.GV24407@sirena.org.uk>

Hello Mark,

On 08/22/2014 04:45 PM, Mark Brown wrote:
> On Fri, Aug 22, 2014 at 02:15:46PM +0200, Javier Martinez Canillas wrote:
> 
>> Mark, any opinions on how this should be solved will be highly appreciated.
> 
> If someone could tell me what "this" is that'd help...
> 

Sorry for not being clear on that regard. By "this" I meant the problem
reported by Yuvaraj.

The regulators operating mode is read from the hardware registers on probe
as you suggested but that means that if the regulator is disabled and the
machine rebooted (warm reset) the opmode reported by the hardware is
MAX77802_OPMODE_OFF.

The problem is that one of these regulators is used as the vqmmc-supply
(VCCQ/VDD_IO) so the mmc host controller driver disables it on
MMC_POWER_OFF. Now AFAIK (Yuvaraj can correct me what I got wrong) this
shouldn't be an issue since on card detection, the vqmmc supply should be
enabled again but on Exynos the built-in card detect line is on the same
power rail as vqmmc. That means that disabling the regulator prevents card
insertions to be detected.

This does not happen on the downstream Chrome OS kernel because the
max77802 regulator driver has some ad-hoc DT bindings were you can define
the operating mode to be set on probe. For this particular regulator is
MAX77802_OPMODE_STANDBY.

Yuvaraj solution was to set the operating mode to MAX77802_OPMODE_NORMAL
on probe() which was what I did on a previous version of the driver but
you explained to me that it was not safe to do that.

That's why I'm asking for suggestions.

Thanks a lot and best regards,
Javier


  reply	other threads:[~2014-08-22 17:53 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-18  8:32 [PATCH v9 0/2] Add Maxim 77802 regulator support Javier Martinez Canillas
2014-08-18  8:32 ` [PATCH v9 1/2] regulator: Add driver for max77802 PMIC PMIC regulators Javier Martinez Canillas
2014-08-18 15:23   ` Mark Brown
2014-08-22  6:01   ` Yuvaraj Cd
2014-08-22 12:15     ` Javier Martinez Canillas
2014-08-22 14:45       ` Mark Brown
2014-08-22 17:53         ` Javier Martinez Canillas [this message]
2014-08-22 18:30           ` Mark Brown
2014-08-22 22:02             ` Javier Martinez Canillas
2014-08-22 22:15               ` Doug Anderson
2014-08-25  8:22                 ` Yuvaraj Cd
2014-08-25  9:07                   ` Javier Martinez Canillas
2014-08-25 10:46                     ` Yuvaraj Cd
2014-08-25 15:40                     ` Doug Anderson
2014-08-25 17:20                       ` Javier Martinez Canillas
2014-08-26  7:17                       ` Mark Brown
2014-08-26  9:08                         ` Javier Martinez Canillas
2014-08-26  9:12                           ` Mark Brown
2014-08-18  8:32 ` [PATCH v9 2/2] regulator: Add DT bindings for max77802 " Javier Martinez Canillas
2014-08-18 15:23   ` 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=53F7838F.8060906@collabora.co.uk \
    --to=javier.martinez@collabora.co.uk \
    --cc=a.kesavan@samsung.com \
    --cc=alim.akhtar@samsung.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=joshi@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=prashanth.g@samsung.com \
    --cc=yuvaraj.lkml@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 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).