From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Marc Dietrich <marvin24-Mmb7MZpHnFY@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Andrey Danin <danindrey-JGs/UdohzUI@public.gmane.org>,
Ian Campbell
<ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>,
"rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org"
<rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>,
Pawel Moll <Pawel.Moll-5wv7dgnIgG8@public.gmane.org>
Subject: Re: [RFC] binding for nvec mfd device
Date: Wed, 31 Jul 2013 15:03:14 -0600 [thread overview]
Message-ID: <51F97B92.1040707@wwwdotorg.org> (raw)
In-Reply-To: <2910047.nJ4yDntMXS@ax5200p>
On 07/31/2013 10:52 AM, Marc Dietrich wrote:
> On Wednesday 31 July 2013 16:33:22 Mark Rutland wrote:
>> On Wed, Jul 31, 2013 at 03:57:13PM +0100, Marc Dietrich wrote:
>>> Am Mittwoch, 31. Juli 2013, 15:13:14 schrieb Mark Rutland:
...
>>>> If you need to instantiate child nodes as Linux platform devices, this
>>>> should be done in the driver for the bus. Relying on simple-bus to do
>>>> this is a hack.
>>>
>>> ok, I'll rip this off from both nodes. I guess I should use
>>> of_platform_populate instead and keeping the compatible node in the childs
>>> - right?
>>
>> I believe that would be a correct way of handling this.
>
> Great. Thinking about a really generic dt representation of an i2c bus (with
> multi-slave, slave and master controllers can act in parallel), something like
> this came into my mind:
>
>
> i2c@xxxxxxx {
> compatible = "nvidia,tegra-i2c", "simple-bus"; /* This time it is
> truly a simple bus, because there is no higher control instance */
>
> ... common master/slave resources ...
>
> master {
> compatible = "nvidia,tegra-i2c-master";
> ... resources ??? ....
>
> client1@xx {
> ...
> };
>
> client2@xx {
> ...
> };
>
> ...
> }
>
> slave1@xxx {
> compatible = "nvidia,tegra-i2c-slave";
> ... resources ??? ...
>
> client1@xx {
> ...
> };
> };
>
> slave2@xxx {
> compatible = "nvidia,tegra-i2c-slave";
> ... resources ??? ...
>
> client1@xx {
> ...
> };
>
> };
>
> ....
> };
The generic I2C bindings already define that the other chips on the I2C
bus appear directly underneath the I2C controller's DT node. Perhaps it
isn't a big issue to change that, since each I2C controller can define
the layout of its own node?
Anyway, we can probably get away without introducing multiple levels by
adding some more bits or cells into the reg address for I2C child nodes:
i2c@xxxxxxxx {
compatible = "nvidia,tegra20-i2c";
... resources
#address-cells = <2>;
codec {
// 0 means external slave, 0x1c is slave's address
reg = <0 0x1c>;
...
};
tegraslave {
// 0 means internal slave, 0x80 is controller's address
reg = <1 0x80>;
...
};
};
... where each of those child nodes could be repeated N times. We could
also or in 0x80000000 to the reg values in the child nodes rather than
using a separate cell if we wanted.
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Warren <swarren@wwwdotorg.org>
To: Marc Dietrich <marvin24@gmx.de>
Cc: Mark Rutland <mark.rutland@arm.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
Andrey Danin <danindrey@mail.ru>,
Ian Campbell <ian.campbell@citrix.com>,
"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
Pawel Moll <Pawel.Moll@arm.com>
Subject: Re: [RFC] binding for nvec mfd device
Date: Wed, 31 Jul 2013 15:03:14 -0600 [thread overview]
Message-ID: <51F97B92.1040707@wwwdotorg.org> (raw)
In-Reply-To: <2910047.nJ4yDntMXS@ax5200p>
On 07/31/2013 10:52 AM, Marc Dietrich wrote:
> On Wednesday 31 July 2013 16:33:22 Mark Rutland wrote:
>> On Wed, Jul 31, 2013 at 03:57:13PM +0100, Marc Dietrich wrote:
>>> Am Mittwoch, 31. Juli 2013, 15:13:14 schrieb Mark Rutland:
...
>>>> If you need to instantiate child nodes as Linux platform devices, this
>>>> should be done in the driver for the bus. Relying on simple-bus to do
>>>> this is a hack.
>>>
>>> ok, I'll rip this off from both nodes. I guess I should use
>>> of_platform_populate instead and keeping the compatible node in the childs
>>> - right?
>>
>> I believe that would be a correct way of handling this.
>
> Great. Thinking about a really generic dt representation of an i2c bus (with
> multi-slave, slave and master controllers can act in parallel), something like
> this came into my mind:
>
>
> i2c@xxxxxxx {
> compatible = "nvidia,tegra-i2c", "simple-bus"; /* This time it is
> truly a simple bus, because there is no higher control instance */
>
> ... common master/slave resources ...
>
> master {
> compatible = "nvidia,tegra-i2c-master";
> ... resources ??? ....
>
> client1@xx {
> ...
> };
>
> client2@xx {
> ...
> };
>
> ...
> }
>
> slave1@xxx {
> compatible = "nvidia,tegra-i2c-slave";
> ... resources ??? ...
>
> client1@xx {
> ...
> };
> };
>
> slave2@xxx {
> compatible = "nvidia,tegra-i2c-slave";
> ... resources ??? ...
>
> client1@xx {
> ...
> };
>
> };
>
> ....
> };
The generic I2C bindings already define that the other chips on the I2C
bus appear directly underneath the I2C controller's DT node. Perhaps it
isn't a big issue to change that, since each I2C controller can define
the layout of its own node?
Anyway, we can probably get away without introducing multiple levels by
adding some more bits or cells into the reg address for I2C child nodes:
i2c@xxxxxxxx {
compatible = "nvidia,tegra20-i2c";
... resources
#address-cells = <2>;
codec {
// 0 means external slave, 0x1c is slave's address
reg = <0 0x1c>;
...
};
tegraslave {
// 0 means internal slave, 0x80 is controller's address
reg = <1 0x80>;
...
};
};
... where each of those child nodes could be repeated N times. We could
also or in 0x80000000 to the reg values in the child nodes rather than
using a separate cell if we wanted.
next prev parent reply other threads:[~2013-07-31 21:03 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-27 13:23 [RFC] binding for nvec mfd device Marc Dietrich
2013-07-27 13:23 ` Marc Dietrich
2013-07-29 21:59 ` Stephen Warren
2013-07-29 21:59 ` Stephen Warren
[not found] ` <51F6E5BE.3080400-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-07-31 14:13 ` Mark Rutland
2013-07-31 14:13 ` Mark Rutland
[not found] ` <20130731141314.GO29859-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
2013-07-31 14:57 ` Marc Dietrich
2013-07-31 14:57 ` Marc Dietrich
[not found] ` <6071437.eL7j9JF89s-D3pzGp0ZKuDWZbiwp4sFPyrtisivX6KghOMvlBiLbJSELgA04lAiVw@public.gmane.org>
2013-07-31 15:33 ` Mark Rutland
2013-07-31 15:33 ` Mark Rutland
[not found] ` <20130731153322.GQ29859-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
2013-07-31 16:52 ` Marc Dietrich
2013-07-31 16:52 ` Marc Dietrich
2013-07-31 21:03 ` Stephen Warren [this message]
2013-07-31 21:03 ` Stephen Warren
[not found] ` <51F97B92.1040707-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-09-17 7:53 ` Marc Dietrich
[not found] ` <17687182.lGWlO75r41-D3pzGp0ZKuDWZbiwp4sFPyrtisivX6KghOMvlBiLbJSELgA04lAiVw@public.gmane.org>
2013-09-17 21:48 ` Stephen Warren
[not found] ` <5238CE1C.3050107-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-09-23 14:52 ` Marc Dietrich
[not found] ` <2112732.zfJtNyCk0i-D3pzGp0ZKuDWZbiwp4sFPyrtisivX6KghOMvlBiLbJSELgA04lAiVw@public.gmane.org>
2013-09-23 16:36 ` Stephen Warren
[not found] ` <52406E1E.5040005-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-09-24 7:39 ` Andrey Danin
2013-09-24 9:33 ` Marc Dietrich
[not found] ` <1597574.dB5YEoR44o-D3pzGp0ZKuDWZbiwp4sFPyrtisivX6KghOMvlBiLbJSELgA04lAiVw@public.gmane.org>
2013-09-24 17:19 ` Stephen Warren
[not found] ` <CAMRQQz-ri99PcK5=-Rzw-fmLoyvzxbd1whUWdqASx1Pi+2GNnQ@mail.gmail.com>
[not found] ` <CAMRQQz-ri99PcK5=-Rzw-fmLoyvzxbd1whUWdqASx1Pi+2GNnQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-09-24 17:04 ` Stephen Warren
2013-09-18 17:28 ` Wolfram Sang
2013-07-31 20:57 ` Stephen Warren
2013-07-31 20:57 ` Stephen Warren
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=51F97B92.1040707@wwwdotorg.org \
--to=swarren-3lzwwm7+weoh9zmkesr00q@public.gmane.org \
--cc=Pawel.Moll-5wv7dgnIgG8@public.gmane.org \
--cc=danindrey-JGs/UdohzUI@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=marvin24-Mmb7MZpHnFY@public.gmane.org \
--cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.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 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.