All of lore.kernel.org
 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:49:42 +0200	[thread overview]
Message-ID: <e463944d2ab9266347361f7cd3b61b09@kernel.crashing.org> (raw)
In-Reply-To: <46B96294322F7D458F9648B60E15112C6F3312@zch01exm26.fsl.freescale.net>

>> 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.
>>
> How about I add more words here for more clear expression?
> Such as "<2> for 34 and 50 bit address, <3> for 66 bit address".

You should more explicitly define the address format, i.e.
what every bit means -- just saying it is 64 or 96 bits isn't
enough.  While you're doing that, think of a way that can
represent _every possible_ RapidIO address, not just the ones
supported by this particular controller.


Segher

WARNING: multiple messages have this Message-ID (diff)
From: Segher Boessenkool <segher@kernel.crashing.org>
To: "Zhang Wei-r63237" <Wei.Zhang@freescale.com>
Cc: <linux-kernel@vger.kernel.org>, <mporter@kernel.crashing.org>,
	<paulus@samba.org>, <linuxppc-dev@ozlabs.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:49:42 +0200	[thread overview]
Message-ID: <e463944d2ab9266347361f7cd3b61b09@kernel.crashing.org> (raw)
In-Reply-To: <46B96294322F7D458F9648B60E15112C6F3312@zch01exm26.fsl.freescale.net>

>> 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.
>>
> How about I add more words here for more clear expression?
> Such as "<2> for 34 and 50 bit address, <3> for 66 bit address".

You should more explicitly define the address format, i.e.
what every bit means -- just saying it is 64 or 96 bits isn't
enough.  While you're doing that, think of a way that can
represent _every possible_ RapidIO address, not just the ones
supported by this particular controller.


Segher


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

Thread overview: 34+ 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 ` 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   ` 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     ` 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       ` Zhang Wei
2007-06-27  8:35       ` [PATCH 4/5 v2] Add RapidIO support to powerpc architecture Zhang Wei
2007-06-27  8:35         ` Zhang Wei
2007-06-27  8:35         ` [PATCH 5/5 v2] Add the memory management driver to RapidIO Zhang Wei
2007-06-27  8:35           ` 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-27 20:56         ` Arnd Bergmann
2007-06-28  6:42         ` Zhang Wei-r63237
2007-06-28  6:42           ` Zhang Wei-r63237
2007-06-28 14:47           ` Arnd Bergmann
2007-06-28 14:47             ` Arnd Bergmann
2007-06-28 18:26             ` Segher Boessenkool
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  0:24     ` David Gibson
2007-06-28  9:23     ` Segher Boessenkool
2007-06-28  9:23       ` Segher Boessenkool
2007-06-28  9:22   ` Segher Boessenkool
2007-06-28  9:22     ` Segher Boessenkool
2007-06-29  4:01     ` Zhang Wei-r63237
2007-06-29  4:01       ` Zhang Wei-r63237
2007-06-29  9:05       ` Segher Boessenkool
2007-06-29  9:05         ` Segher Boessenkool
2007-06-29  9:20         ` Zhang Wei-r63237
2007-06-29  9:20           ` Zhang Wei-r63237
2007-06-29  9:49           ` Segher Boessenkool [this message]
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=e463944d2ab9266347361f7cd3b61b09@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 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.