All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ivan T. Ivanov" <iivanov@mm-sol.com>
To: Courtney Cavin <courtney.cavin@sonymobile.com>
Cc: Josh Cartwright <joshc@codeaurora.org>,
	Samuel Ortiz <sameo@linux.intel.com>,
	Lee Jones <lee.jones@linaro.org>,
	Grant Likely <grant.likely@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	David Collins <collinsd@codeaurora.org>
Subject: Re: [PATCH 1/2] mfd: pm8x41: add support for Qualcomm 8x41 PMICs
Date: Sat, 10 May 2014 11:06:49 +0300	[thread overview]
Message-ID: <1399709209.8165.44.camel@iivanov-dev> (raw)
In-Reply-To: <20140509203013.GA5568@sonymobile.com>


Hi Courtney,

On Fri, 2014-05-09 at 13:30 -0700, Courtney Cavin wrote:

> > > Requiring a specific PMIC listed before a generic one allows us an
> > > escape hatch in the future if for some reason we need to add a quirk for
> > > a specific PMIC.
> > 
> > Is there a conclusion on this issue? I am voting for generic name :-)
> > "qcom,pm-qpnp".
> 
> Josh and I have discussed this offline, and I think we have come to the
> conclusion that this should be a generic driver with only a generic
> binding.  The current proposed name is "spmi-ext", as there is specific
> functional relation to Qualcomm, PMICs or QPNP.
> 
> Further, the binding documentation should be specific to pm8[89]41 as
> 'mfd/pm8x41.txt', and should contain the compatibles:
> 	- "qcom,pm8941", "spmi-ext"
> 	- "qcom,pm8841", "spmi-ext"
> 
> This naming has been discussed to death, so a few more shed color
> suggestions can't possibly hurt.

I am fine with this. Thanks.

> 
> > Further complication is that several sub function drivers expect to
> > runtime detect the exact version of the controller ("qcom, qpnp-iadc",
> > "qcom, qpnp-vadc", "qcom, qpnp-linear-charger").  This is realized by the
> > exported function of the driver "qcom, qpnp-revid". Would it be good
> > idea to merge qpnp-revid and "qcom,pm-qpnp" driver?
> 
> Each block within the PMICs have--undocumented--version registers, so a
> global version number is not particularly useful.  A good example of
> this is the ADC code [1], as you mentioned.

Do you happen to know how to match local subdevices revisions to global 
PMIC revision? Earlier mentioned drivers are using global chip revision. 

I will not be surprised if local subdevice version is not changed, but
instead global version is changed, when only subdevice functionality is 
changed ;-)

Regards,
Ivan

  reply	other threads:[~2014-05-10  8:07 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-23  0:31 [PATCH 1/2] mfd: pm8x41: add support for Qualcomm 8x41 PMICs Courtney Cavin
2014-04-23  0:31 ` Courtney Cavin
2014-04-23  0:31 ` [PATCH 2/2] mfd: pm8x41: document device tree bindings Courtney Cavin
2014-04-23  0:31   ` Courtney Cavin
2014-04-23 10:50 ` [PATCH 1/2] mfd: pm8x41: add support for Qualcomm 8x41 PMICs Lee Jones
2014-04-23 17:38   ` Courtney Cavin
2014-04-23 13:19 ` Ivan T. Ivanov
2014-04-23 18:16   ` Courtney Cavin
2014-04-23 20:34     ` Ivan T. Ivanov
2014-04-23 22:12       ` Courtney Cavin
2014-04-24  2:45   ` Rob Herring
2014-04-26  0:28   ` Frank Rowand
2014-04-26  0:40     ` Courtney Cavin
2014-04-26  0:53       ` Frank Rowand
2014-04-28  7:11     ` Ivan T. Ivanov
2014-05-07 18:35   ` Rob Herring
2014-04-23 21:46 ` Josh Cartwright
2014-04-23 23:36   ` Courtney Cavin
2014-04-24 18:18     ` Josh Cartwright
2014-05-09 12:45       ` Ivan T. Ivanov
2014-05-09 20:30         ` Courtney Cavin
2014-05-10  8:06           ` Ivan T. Ivanov [this message]
2014-04-26  1:38     ` David Collins

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=1399709209.8165.44.camel@iivanov-dev \
    --to=iivanov@mm-sol.com \
    --cc=collinsd@codeaurora.org \
    --cc=courtney.cavin@sonymobile.com \
    --cc=devicetree@vger.kernel.org \
    --cc=grant.likely@linaro.org \
    --cc=joshc@codeaurora.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=sameo@linux.intel.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.