From: Laxman Dewangan <ldewangan@nvidia.com>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: J Keerthy <j-keerthy@ti.com>,
"grant.likely@secretlab.ca" <grant.likely@secretlab.ca>,
"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
"rob@landley.net" <rob@landley.net>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"b-cousson@ti.com" <b-cousson@ti.com>,
"gg@slimlogic.co.uk" <gg@slimlogic.co.uk>
Subject: Re: [PATCH 1/4] documentation: add palmas dts definition
Date: Thu, 28 Feb 2013 14:22:47 +0530 [thread overview]
Message-ID: <512F1ADF.90906@nvidia.com> (raw)
In-Reply-To: <512E5144.9020105@wwwdotorg.org>
On Thursday 28 February 2013 12:02 AM, Stephen Warren wrote:
> On 02/17/2013 10:11 PM, J Keerthy wrote:
> +- interrupt-parent : The parent interrupt controller.
> +
> +Optional node:
> +- Child nodes contain in the palmas. The palmas family is made of several
> + variants that support a different number of features.
> + The child nodes will thus depend of the capability of the variant.
> Are there DT bindings for those child nodes anywhere?
>
> Representing each internal component as a separate DT node feels a
> little like designing the DT bindings to model the Linux-internal MFD
> structure. DT bindings should be driven by the HW design and OS-agnostic.
>
> From a DT perspective, is there any need at all to create a separate DT
> node for each component? This would only be needed or useful if the
> child IP blocks (and hence DT bindings for those blocks) could be
> re-used in other top-level devices that aren't represented by this
> top-level ti,palmas DT binding. Are the HW IP blocks here re-used
> anywhere, or will they be?
I dont think that child IP block can be used outside of the palma
although other mfd device may have same IP.
The child driver very much used the palma's API for register access and
they can not be separated untill driver is write completely independent
of palmas API. Currently, child driver include the palma header, uses
palma mfd stcruture and plama's api for accessing registers.
>> + interrupt-controller;
>> + #interrupt-cells = <1>;
>> + interrupt-parent = <&gic>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + ti,mux-pad1 = <0x00>;
>> + ti,mux-pad2 = <0x00>;
>> + ti,power-ctrl = <0x03>;
>> +
>> + palmas_pmic {
> Just "pmic" seems simpler, although I dare say the node name isn't
> really used for anything.
Stephen,
Just curios, why do we require the palma_pmic node at all, We can start
with regulator node directly. Is it not too much nested here?
>
> +
> + palmas_rtc {
> + compatible = "ti,palmas_rtc";
> + interrupts = <8 9>;
> Are the interrupt outputs of the RTC fed directly to the GIC interrupt
> mentioned in the top-level Palmas node, or do these interrupts feed into
> a top-level IRQ controller in the Palmas device, which then feeds into
> the external IRQ controller?
The interrupt goes to the chip-internal irq, not to external of chip.
We have only one int line from chip which can be connected to processor/GIC.
yes, interrupt parent need to be define here to get the proper interrupt
number.
next prev parent reply other threads:[~2013-02-28 8:52 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-18 5:11 [PATCH 1/4] documentation: add palmas dts definition J Keerthy
2013-02-27 18:32 ` Stephen Warren
2013-02-28 8:52 ` Laxman Dewangan [this message]
2013-02-28 9:58 ` Graeme Gregory
2013-02-28 10:27 ` Laxman Dewangan
2013-02-28 10:57 ` Graeme Gregory
2013-02-28 11:21 ` Graeme Gregory
2013-02-28 19:01 ` Stephen Warren
2013-02-28 18:58 ` Stephen Warren
[not found] ` <512F1ADF.90906-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-02-28 18:51 ` Stephen Warren
2013-02-28 12:09 ` J, KEERTHY
2013-02-28 19:07 ` Stephen Warren
2013-03-01 2:24 ` J, KEERTHY
-- strict thread matches above, loose matches on Subject: below --
2013-02-20 4:00 J Keerthy
2013-02-20 11:26 ` Mark Brown
2013-02-20 13:49 ` J, KEERTHY
2013-02-27 18:16 ` Stephen Warren
2013-03-02 4:07 ` Mark Brown
2013-02-25 8:55 ` J, KEERTHY
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=512F1ADF.90906@nvidia.com \
--to=ldewangan@nvidia.com \
--cc=b-cousson@ti.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=gg@slimlogic.co.uk \
--cc=grant.likely@secretlab.ca \
--cc=j-keerthy@ti.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rob.herring@calxeda.com \
--cc=rob@landley.net \
--cc=swarren@wwwdotorg.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).