linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: collinsd@codeaurora.org (David Collins)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 2/4] mfd: pm8xxx-spmi: document DT bindings for Qualcomm SPMI PMICs
Date: Thu, 31 Jul 2014 13:53:59 -0700	[thread overview]
Message-ID: <53DAACE7.70500@codeaurora.org> (raw)
In-Reply-To: <53DA054D.2050508@mm-sol.com>

On 07/31/2014 01:58 AM, Stanimir Varbanov wrote:
> On 07/30/2014 01:23 AM, David Collins wrote:
>> On 07/24/2014 05:45 AM, Stanimir Varbanov wrote:
>>> Document DT bindings used to describe the Qualcomm SPMI PMICs.
>>> Currently the SPMI PMICs supported are pm8941, pm8841 and pma8084.
>>>
>>> Signed-off-by: Stanimir Varbanov <svarbanov@mm-sol.com>
>>
>> (...)
>>> +Required properties for peripheral child nodes:
>>> +- compatible:      Should contain "qcom,pm8xxx-xxx", where "xxx" is
>>> +                   peripheral name. The "pm8xxx" can be any of supported PMICs,
>>> +                   see example below.
>>
>> I don't think that this binding document should be imposing any formatting
>> restrictions on the compatible strings for QPNP peripheral drivers.  The
>> QPNP peripheral drivers in the downstream msm-3.10 tree [1] do not specify
>> per-PMIC compatible strings.  This is because ideally, a given QPNP
>> peripheral represents a hardware block that is identical in interface and
>> operation between PMICs.
>>
> 
> Isn't "hardware block that is identical in interface and operation
> between PMICs" exactly the meaning of *compatible* property?
> 
> No *compatible* property, no platform device. We must have this property
> for every peripheral driver.

I am not suggesting that we remove the compatible property for peripheral
device nodes.  I agree that these nodes need to have a compatible
property.  My concern is that this binding document should not require the
peripheral nodes to have compatible property values that are PMIC specific.

For example, in the downstream msm-3.10 branch the power-on peripheral
uses the same compatible string regardless of what PMIC the peripheral is
found on: "qcom,qpnp-power-on" [1].  There is no reason for the driver to
care about what PMIC the peripheral is found on.  Therefore, it does not
make sense to force it to support compatible strings like
"qcom,pm8941-power-on", "qcom,pm8841-power-on", "qcom,pma8084-power-on", etc.

Every QPNP PMIC peripheral has its own set of type and version registers
that allow software to auto-detect its capabilities at runtime.

Take care,
David

[1]:
https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.10/tree/Documentation/devicetree/bindings/platform/msm/qpnp-power-on.txt?h=msm-3.10

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

  reply	other threads:[~2014-07-31 20:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-24 12:45 [PATCH v3 0/4] Support for Qualcomm QPNP PMIC's Stanimir Varbanov
2014-07-24 12:45 ` [PATCH v3 1/4] mfd: pm8xxx-spmi: add support for Qualcomm SPMI PMICs Stanimir Varbanov
2014-07-29 21:54   ` David Collins
2014-07-31  8:48     ` Stanimir Varbanov
2014-07-31 20:33       ` David Collins
2014-08-01  8:31       ` Stanimir Varbanov
2014-08-01 11:23         ` Lee Jones
2014-07-24 12:45 ` [PATCH v3 2/4] mfd: pm8xxx-spmi: document DT bindings " Stanimir Varbanov
2014-07-29 22:23   ` David Collins
2014-07-31  8:58     ` Stanimir Varbanov
2014-07-31 20:53       ` David Collins [this message]
2014-07-24 12:45 ` [PATCH v3 3/4] ARM: dts: qcom: add pm8941 and pm8841 PMICs device nodes Stanimir Varbanov
2014-07-24 12:45 ` [PATCH v3 4/4] mfd: pm8921: rename pm8921-core driver Stanimir Varbanov
2014-07-28 14:20 ` [PATCH v3 0/4] Support for Qualcomm QPNP PMIC's Stanimir Varbanov

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=53DAACE7.70500@codeaurora.org \
    --to=collinsd@codeaurora.org \
    --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 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).