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] Add the explanation and sample of RapidIO DTS sector to the document of booting-without-of.txt file.
Date: Wed, 13 Jun 2007 10:28:12 +0200	[thread overview]
Message-ID: <59453d80f2f111b72e8f24e7b489c23e@kernel.crashing.org> (raw)
In-Reply-To: <46B96294322F7D458F9648B60E15112C526DD9@zch01exm26.fsl.freescale.net>

>>> +    - device_type : Should be "rapidio"
>>
>> There is no OF binding, so no.
>
> So, we need to define it.

If you want to.  Until that has been done, don't use
a "device_type".  Linux won't use it, anyway.

>>> +    - compatible : Should be "fsl,rapidio-v0.0" or
>> "fsl,rapidio-v1.0"
>>> +      and so on. The version number is got from IP Block Revision
>>> +      Register of RapidIO controller.
>>
>> It's better to use real device names, just like everyone
>> else.
>
> Some silicons of Freescale processor are the same RapidIO controller,
> such as mpc8540/mpc8560 are the same (v0.0), mpc8548/mpc8641 are the
> same (v1.0). For v1.0 RapidIO controller, should we use mpc8548 or
> mpc8641? Those will make people confused.

Not at all.  On an 8641 it could be

	compatible = "fsl,mpc8641-rapidio" "fsl,mpc8548-rapidio";

which states "this is the 8641 thing and it is compatible
to the 8548 thing".  Perfectly clear.

> Using IP Block Revision is a
> clear choice.

I don't think so.  For one thing, it describes a version of
a cell design, not a version of an actual device.  For another
thing, if I hear "8641" I know what you're talking about (sort
of, anyway), but I draw a blank stare if you say "v1.0".  I'm
sure I'm not the only one.  Concrete names are good.

>>> +    - #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
>>> +      36-bits RapidIO address, this field should be <2>.
>>
>> More than 32 bit?
>
> Yes, RapidIO bus address width is 34 bits.

You said "more than 36 bit", I tried to ask if that is a typo
perhaps.

>> No.  The format of an "interrupts" entry is defined by
>> the interrupt domain this device sits in, not by the
>> device itself.
>>
> Do you misunderstand the meaning of 'interrupts'?

Hahaha.  No, I don't misunderstand what the "interrupts" property
means.  Perhaps you do?

> These interrupts is
> issued from the RapidIO controller to the pic controller for tx, rx,
> err, doorbell and message.

But the rapidio node doesn't know or care what the interrupts
are connected to, and neither should it.  That's what the
interrupt mapping recommended practice is for.

>>> For this sector, interrupts order should be
>>> +      <err_irq bell_outb_irq bell_inb_irq msg1_tx_irq msg1_rx_irq
>>> +      msg2_tx_irq msg2_rx_irq ... msgN_tx_irq msgN_rx_irq>.
>>
>> That's to be defined in the binding for your specific device,
>> not in a more generic rapidio binding.
>
> These description is just for compatible="fsl,rapidio-v*.*" rapidio
> controller.

Okay, good.  Please make that way more obvious then :-)

>>> +		#address-cells = <2>;
>>
>> You want a #size-cells as well.
>
> The size is not used in this sector, so no defined.

The size _is_ used; in the "ranges" property in this node,
for example.  It is also needed to describe the "reg" for
any child node of this node.

A non-existant "#size-cells" means 1, and "#address-cells"
means 2, so in principle you could do without these
properties; but Linux doesn't parse the tree correctly in
that case (which reminds me, I have some more patches to
send).

> Thanks!

My pleasure,


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] Add the explanation and sample of RapidIO DTS sector to the document of booting-without-of.txt file.
Date: Wed, 13 Jun 2007 10:28:12 +0200	[thread overview]
Message-ID: <59453d80f2f111b72e8f24e7b489c23e@kernel.crashing.org> (raw)
In-Reply-To: <46B96294322F7D458F9648B60E15112C526DD9@zch01exm26.fsl.freescale.net>

>>> +    - device_type : Should be "rapidio"
>>
>> There is no OF binding, so no.
>
> So, we need to define it.

If you want to.  Until that has been done, don't use
a "device_type".  Linux won't use it, anyway.

>>> +    - compatible : Should be "fsl,rapidio-v0.0" or
>> "fsl,rapidio-v1.0"
>>> +      and so on. The version number is got from IP Block Revision
>>> +      Register of RapidIO controller.
>>
>> It's better to use real device names, just like everyone
>> else.
>
> Some silicons of Freescale processor are the same RapidIO controller,
> such as mpc8540/mpc8560 are the same (v0.0), mpc8548/mpc8641 are the
> same (v1.0). For v1.0 RapidIO controller, should we use mpc8548 or
> mpc8641? Those will make people confused.

Not at all.  On an 8641 it could be

	compatible = "fsl,mpc8641-rapidio" "fsl,mpc8548-rapidio";

which states "this is the 8641 thing and it is compatible
to the 8548 thing".  Perfectly clear.

> Using IP Block Revision is a
> clear choice.

I don't think so.  For one thing, it describes a version of
a cell design, not a version of an actual device.  For another
thing, if I hear "8641" I know what you're talking about (sort
of, anyway), but I draw a blank stare if you say "v1.0".  I'm
sure I'm not the only one.  Concrete names are good.

>>> +    - #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
>>> +      36-bits RapidIO address, this field should be <2>.
>>
>> More than 32 bit?
>
> Yes, RapidIO bus address width is 34 bits.

You said "more than 36 bit", I tried to ask if that is a typo
perhaps.

>> No.  The format of an "interrupts" entry is defined by
>> the interrupt domain this device sits in, not by the
>> device itself.
>>
> Do you misunderstand the meaning of 'interrupts'?

Hahaha.  No, I don't misunderstand what the "interrupts" property
means.  Perhaps you do?

> These interrupts is
> issued from the RapidIO controller to the pic controller for tx, rx,
> err, doorbell and message.

But the rapidio node doesn't know or care what the interrupts
are connected to, and neither should it.  That's what the
interrupt mapping recommended practice is for.

>>> For this sector, interrupts order should be
>>> +      <err_irq bell_outb_irq bell_inb_irq msg1_tx_irq msg1_rx_irq
>>> +      msg2_tx_irq msg2_rx_irq ... msgN_tx_irq msgN_rx_irq>.
>>
>> That's to be defined in the binding for your specific device,
>> not in a more generic rapidio binding.
>
> These description is just for compatible="fsl,rapidio-v*.*" rapidio
> controller.

Okay, good.  Please make that way more obvious then :-)

>>> +		#address-cells = <2>;
>>
>> You want a #size-cells as well.
>
> The size is not used in this sector, so no defined.

The size _is_ used; in the "ranges" property in this node,
for example.  It is also needed to describe the "reg" for
any child node of this node.

A non-existant "#size-cells" means 1, and "#address-cells"
means 2, so in principle you could do without these
properties; but Linux doesn't parse the tree correctly in
that case (which reminds me, I have some more patches to
send).

> Thanks!

My pleasure,


Segher


  reply	other threads:[~2007-06-13  8:28 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-12  9:02 [PATCH 0/5] Porting RapidIO driver from ppc to powerpc architecture and adding memory mapped RapidIO driver Zhang Wei
2007-06-12  9:02 ` Zhang Wei
2007-06-12  9:02 ` [PATCH 1/5] Add the explanation and sample of RapidIO DTS sector to the document of booting-without-of.txt file Zhang Wei
2007-06-12  9:02   ` Zhang Wei
2007-06-12  9:02   ` [PATCH 2/5] Add RapidIO sector to MPC8641HPCN board dts file Zhang Wei
2007-06-12  9:02     ` Zhang Wei
2007-06-12  9:02     ` [PATCH 3/5] Add the platform device support with RapidIO to MPC8641HPCN platform Zhang Wei
2007-06-12  9:02       ` Zhang Wei
2007-06-12  9:02       ` [PATCH 4/5] Add RapidIO support to powerpc architecture Zhang Wei
2007-06-12  9:02         ` Zhang Wei
2007-06-12 22:58     ` [PATCH 2/5] Add RapidIO sector to MPC8641HPCN board dts file Phil Terry
2007-06-12 22:58       ` Phil Terry
2007-06-13  2:49       ` Zhang Wei-r63237
2007-06-13  2:49         ` Zhang Wei-r63237
2007-06-13  5:02   ` [PATCH 1/5] Add the explanation and sample of RapidIO DTS sector to the document of booting-without-of.txt file Segher Boessenkool
2007-06-13  5:02     ` Segher Boessenkool
2007-06-13  8:14     ` Zhang Wei-r63237
2007-06-13  8:14       ` Zhang Wei-r63237
2007-06-13  8:28       ` Segher Boessenkool [this message]
2007-06-13  8:28         ` Segher Boessenkool
2007-06-13  9:37         ` Zhang Wei-r63237
2007-06-13  9:37           ` Zhang Wei-r63237
2007-06-13  9:48           ` Segher Boessenkool
2007-06-13  9:48             ` Segher Boessenkool
2007-06-14  5:53         ` Kumar Gala
2007-06-14  5:53           ` Kumar Gala
2007-06-14  7:52           ` Segher Boessenkool
2007-06-14  7:52             ` Segher Boessenkool
2007-06-18  3:27             ` Zhang Wei-r63237
2007-06-18  3:27               ` Zhang Wei-r63237
2007-06-18 12:43               ` Segher Boessenkool
2007-06-18 12:43                 ` 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=59453d80f2f111b72e8f24e7b489c23e@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.