linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: "Zhang Wei-r63237" <Wei.Zhang@freescale.com>
Cc: linuxppc-dev@ozlabs.org, paulus@samba.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/5 v2] Add the explanation and a sample of RapidIO DTS sector to the document of booting-without-of.txt file.
Date: Fri, 29 Jun 2007 11:05:56 +0200	[thread overview]
Message-ID: <8ee77b5f79ee0c0c5ead1f0acbe95bda@kernel.crashing.org> (raw)
In-Reply-To: <46B96294322F7D458F9648B60E15112C6F3281@zch01exm26.fsl.freescale.net>

>>> +    - #address-cells : Address representation for
>> "rapidio" devices.
>>> +      This field represents the number of cells needed to represent
>>> +      the RapidIO address of the registers.  For
>> supporting more than
>>> +      32-bits RapidIO address, this field should be <2>.
>>> +      See 1) above for more details on defining #address-cells.
>>
>> What does the RapidIO standard say about number of address
>> bits?  You want to follow that, so all RapidIO devices can
>> use the same #address-cells, not just the FSL ones.  Also,
>> are there different kinds of address spaces on the bus, or
>> is it just one big memory-like space?
>
> I've checked the specification of RapidIO. The supporting of RapidIO
> extended address modes are 66, 50 and 34 bit.

These three are all two bits more than some "regular" size --
do those two extra bits have some special meaning perhaps,
like an address space identifier or something?

> The Freescale's silicons is only support 34 bit address now.
> Do you mean I should not use words -- 'should be <2>'?
> The #address-cells should be assigned according the address mode
> supported by silicon.

No.  The #address-cells is determined by the bus binding,
so that all RapidIO busses on the planet can be represented
in a similar way in the OF device tree.  Take for example
the PCI binding, which gives you three address cells -- one
to distinguish between different address spaces (configuration
space, legacy I/O space, memory mapped space) and to contain
some flags (prefetchable vs. non-prefetchable, etc.); the
other two 32-bit cells contain a 64-bit address, although
config and legacy I/O never are more than 32 bit, and many
PCI devices can't do 64-bit addressing at all.

Now, there is no OF binding for RapidIO yet of course, but
it would be good to start thinking about one while doing
the binding for your specific controller -- it will make
life easier down the line for everyone, including yourself.


Segher

  reply	other threads:[~2007-06-29  9:06 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-27  8:35 [PATCH 0/5 v2] Porting RapidIO driver from ppc to powerpc architecture and adding memory mapped RapidIO driver Zhang Wei
2007-06-27  8:35 ` [PATCH 1/5 v2] Add the explanation and a sample of RapidIO DTS sector to the document of booting-without-of.txt file Zhang Wei
2007-06-27  8:35   ` [PATCH 2/5 v2] Add RapidIO sector to the MPC8641HPCN board dts file Zhang Wei
2007-06-27  8:35     ` [PATCH 3/5 v2] Add the platform device support with RapidIO to MPC8641HPCN platform Zhang Wei
2007-06-27  8:35       ` [PATCH 4/5 v2] Add RapidIO support to powerpc architecture Zhang Wei
2007-06-27  8:35         ` [PATCH 5/5 v2] Add the memory management driver to RapidIO Zhang Wei
2007-06-27 20:56       ` [PATCH 3/5 v2] Add the platform device support with RapidIO to MPC8641HPCN platform Arnd Bergmann
2007-06-28  6:42         ` Zhang Wei-r63237
2007-06-28 14:47           ` Arnd Bergmann
2007-06-28 18:26             ` Segher Boessenkool
2007-06-28  0:24   ` [PATCH 1/5 v2] Add the explanation and a sample of RapidIO DTS sector to the document of booting-without-of.txt file David Gibson
2007-06-28  9:23     ` Segher Boessenkool
2007-06-28  9:22   ` Segher Boessenkool
2007-06-29  4:01     ` Zhang Wei-r63237
2007-06-29  9:05       ` Segher Boessenkool [this message]
2007-06-29  9:20         ` Zhang Wei-r63237
2007-06-29  9:49           ` Segher Boessenkool

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=8ee77b5f79ee0c0c5ead1f0acbe95bda@kernel.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=Wei.Zhang@freescale.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=paulus@samba.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).