linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: svarbanov@mm-sol.com (Stanimir Varbanov)
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 11:58:53 +0300	[thread overview]
Message-ID: <53DA054D.2050508@mm-sol.com> (raw)
In-Reply-To: <53D81EE1.7040309@codeaurora.org>

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.

> These peripheral drivers determine the base address for a given device
> instance via device tree reg and reg-names properties.  In order for this
> to continue to work with the pm8xxx-spmi driver, some mechanism will need
> to be introduced which creates resource structs for the
> non-memory-mappable SPMI base addresses.  One possible solution is
> currently being discussed in another thread [2].  This document will need
> to be updated to show the child node reg property scheme once a solution
> is reached.
> 

That's correct. If we reach the "reg" solution this binding document
must be changed.

> (...)
>> +Example:
>> +
>> +	pm8941 at 0 {
>> +		compatible = "qcom,pm8941";
>> +		reg = <0x0 SPMI_USID>;
>> +
>> +		rtc {
>> +			compatible = "qcom,pm8941-rtc";
>> +			interrupts = <0x0 0x61 0x1 IRQ_TYPE_EDGE_RISING>;
>> +			interrupt-names = "alarm";
>> +		};
>> +	};
> 
> Can you please expand your example to include the second SID for the
> PM8941 chip?  That way, it will be clear that each PMIC needs two DT
> nodes; one for each SID.

Sure, will do.

-- 
regards,
Stan

  reply	other threads:[~2014-07-31  8:58 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 [this message]
2014-07-31 20:53       ` David Collins
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=53DA054D.2050508@mm-sol.com \
    --to=svarbanov@mm-sol.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 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).