From: Laxman Dewangan <ldewangan@nvidia.com>
To: Graeme Gregory <gg@slimlogic.co.uk>
Cc: Stephen Warren <swarren@wwwdotorg.org>,
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>
Subject: Re: [PATCH 1/4] documentation: add palmas dts definition
Date: Thu, 28 Feb 2013 15:57:36 +0530 [thread overview]
Message-ID: <512F3118.6030806@nvidia.com> (raw)
In-Reply-To: <512F2A29.8080708@slimlogic.co.uk>
On Thursday 28 February 2013 03:28 PM, Graeme Gregory wrote:
> On 28/02/13 08:52, Laxman Dewangan wrote:
>> 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.
>>
> I wonder why break good software principles of keeping data and code
> localised? Just because there is no current case where a block is
> re-used does not mean it shall not be so in the future. The original
> information I got from TI when designing this was blocks may be re-used
> in future products.
>
> This structure also makes it much neater when dealing with palmas
> varients with different IP blocks which already exist.
>
> I also do not see an issue with working like the internal MFD structure,
> I think it is a good design.
I did not get how the register access will be happen from IP driver.
suppose we have RTC driver which is common IP for device 1 and device2.
Device1 and device2 are registered as separate MFD driver which has
different set of chip structure and initialisation.
When I write the RTC register then how do I call register access?
Currently RTC driver is saying device1_reg_read() or device2_reg_read()
etc on which register address passed along with dev or chip structure.
next prev parent reply other threads:[~2013-02-28 10:29 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
2013-02-28 9:58 ` Graeme Gregory
2013-02-28 10:27 ` Laxman Dewangan [this message]
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
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
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=512F3118.6030806@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).