devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
To: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
Cc: devicetree-discuss
	<devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,
	Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
Subject: Re: #size-cells = <0> in a bus node, and kernel messages complaining about this
Date: Thu, 28 Jun 2012 08:21:06 -1000	[thread overview]
Message-ID: <4FECA092.60307@firmworks.com> (raw)
In-Reply-To: <4FEC994A.4030507-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>

On 6/28/2012 7:50 AM, Stephen Warren wrote:
> On 06/27/2012 06:57 PM, Mitch Bradley wrote:
>> On 6/27/2012 11:26 AM, Stephen Warren wrote:
>>> I believe I've seen the following construct bandied about as the correct
>>> way of representing a bunch of nodes that have the same name (since they
>>> represent the same type of object) within device-tree.
>>>
>>>      regulators {
>>>          compatible = "simple-bus";
>>>          #address-cells = <1>;
>>>          #size-cells = <0>;
>>>
>>>          regulator@0 {
>>>              compatible = "regulator-fixed";
>>>              reg = <0>;
>>> ...
>>>          };
>>>
>>>          regulator@1 {
>>>              compatible = "regulator-fixed";
>>>              reg = <1>;
>>> ...
>>>          };
>>>      };
>>>
>>> However, when the kernel parses that, it issues messages such as:
>>>
>>> prom_parse: Bad cell count for /regulators/regulator@0
>>> prom_parse: Bad cell count for /regulators/regulator@1
>>
>> The message comes from __of_translate_address(), which has the comment:
>>
>>   * Note: We consider that crossing any level with #size-cells == 0 to mean
>>   * that translation is impossible (that is we are not dealing with a value
>>   * that can be mapped to a cpu physical address). This is not really
>> specified
>>   * that way, but this is traditionally the way IBM at least do things
>>
>> So it seems that the problem only occurs if something tries to translate
>> the regulator's "reg" address to a CPU address.  Is that
>> possible/meaningful
>> in your case?
>
> That's quite likely.
>
> Note that the regulators node is compatible = "simple-bus", and I'm
> doing that so that the child regulator nodes are automatically recursed
> into, and a platform device created for each. Part of creating those
> platform devices is to convert the reg and interrupts properties to
> platform device resources, which is almost certainly what's calling
> __of_translate_address(). This is a compatibility thing on ARM; I guess
> pure OF-style drivers call something like of_get_address()/of_iomap()
> themselves in their probe() function if appropriate, rather than relying
> on calling platform_get_resource(), and hence forcing the DT parsing
> code to convert resources beforehand in all cases, even if not used.
>
> Perhaps simple-bus could be enhanced to detect when size-cells==0 and
> know that this means the bus is really just a container/grouping of
> non-addressed objects, and hence not provide the memory resources. Or,
> perhaps we should introduce a new compatible value that only triggers
> child instantiation but not resource setup, or something like that?

ISTM that if you want different semantics, a different compatible value 
is the best approach.  My mental model is that "simple-bus" has 
memory-mapped children. Perhaps something like "enumerated-bus" for 
non-memory-mapped ?

>

  parent reply	other threads:[~2012-06-28 18:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-27 21:26 #size-cells = <0> in a bus node, and kernel messages complaining about this Stephen Warren
     [not found] ` <4FEB7A8E.1090409-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-06-28  0:57   ` Mitch Bradley
     [not found]     ` <4FEBABE0.2050503-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2012-06-28 17:50       ` Stephen Warren
     [not found]         ` <4FEC994A.4030507-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-06-28 18:21           ` Mitch Bradley [this message]
     [not found]             ` <4FECA092.60307-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2012-06-28 18:49               ` Mitch Bradley
     [not found]                 ` <4FECA72F.9080601-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2012-06-28 20:28                   ` Mitch Bradley
     [not found]                     ` <4FECBE5B.1090300-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2012-06-28 20:51                       ` Stephen Warren
     [not found]                         ` <4FECC3D5.2030507-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-06-28 20:58                           ` Mitch Bradley
     [not found]                             ` <4FECC569.1000108-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2012-06-28 22:02                               ` Stephen Warren
     [not found]                                 ` <4FECD461.9030802-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-06-28 22:22                                   ` Mitch Bradley
2012-06-29  2:38           ` David Gibson

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=4FECA092.60307@firmworks.com \
    --to=wmb-d5eqfidgl7eakbo8gow8eq@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org \
    --cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@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 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).