linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: "Gerhard Pircher" <gerhard_pircher@gmx.net>
Cc: linuxppc-dev@ozlabs.org, David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [RFC] Device tree for new desktop platform in arch/powerpc
Date: Tue, 19 Jun 2007 11:14:44 +0200	[thread overview]
Message-ID: <73aafd0955b8ea695af9221b48aaa3f1@kernel.crashing.org> (raw)
In-Reply-To: <20070619084015.202120@gmx.net>

>>> 3. The dts files define the device_type of a serial port as
>>> "serial", whereas the OF spec says "pnpPNP,501". What's the
>>> difference between the two?
>>
>> Err... device_type == "pnpPNP,501", or compatible == "pnpPNP,501"?
> Sorry, I meant compatible = "ns16550" and compatible = "pnpPNP,501".

"pnpPNP,501" says that the device is a 16550A-compatible
UART compatible with how that is used in a PC (using the
same base clock, and some other minor things).

"ns16550" simply says the device is compatible with
the NS16550.  Also note the lack of "A".

>> This node has no children, so #address-cells and #size-cells values
>> are meaningless.
> Ah, I thought these properties are always necessary, if a ranges or reg
> property is defined.

They are necessary if one of the children has a "reg" or
"ranges" or similar, or if this node has a "ranges"
property.  "#xxx-cells" defines the number of cells for
the bus that this node is the controller for.  So, for
"reg", the relevant #xxx-cells entry is that in your parent;
for "ranges" you need both the "#address-cells" entry in
your parent and your own #xxx-cells values (since "ranges"
uses parent bus address, child bus address, child bus size).

>>>   	interrupt-controller {
>>> 		device_type = "interrupt-controller";
>>> 		compatible = "chrp,iic";
>>
>> Is there a device binding defined somewhere for "chrp,iic"?
> Dunno. :-) It's based on these document here:
> http://playground.sun.com/1275/bindings/devices/html/isa-pic-1_1d.html
> http://playground.sun.com/1275/bindings/pci/pci2_1.pdf

How does PCI come into the picture here?

>>> 	timer@40 {
>>> 		device_type = "timer";
>>
>> For flat device trees we're generally avoiding setting the device_type
>> property unless there is a clearly defined "class binding" which
>> applies.  There are a number of cases here where I'm not sure if
>> that's true.
> What about platforms that provide a real OF device tree? Do they define
> device nodes for timers?

Sure.  There typically is a device node for every
(addressable) device on the system.  There is no
defined binding for timer devices though, so there
shouldn't be a "device_type" in a timer node.

>>> 		clock-frequency = <0>;			// Not necessary?

Since this is an AT timer, you should use "compatible"
= "pnpPNP,100", and the clock frequency is implicit.

>>> 	fdc@3f0 {

>>> 		disk {
>>> 			device_type = "block";
>>> 			reg = <0>;
>>> 		};
>>>
>> Don't think you need this subnode.
> It's mentioned here (if I interpreted it correctly):
> http://playground.sun.com/1275/bindings/devices/html/fdc.html

"disk" subnodes describe the floppy disk _drives_ actually.
You should have a disk@0 and/or a disk@1, if you have any
floppy disk drives at all that is.

> Not sure, if the Linux kernel needs it.

The linux floppy driver will do its own probing, so no
it won't care.  Can't hurt to include it though.

In real OF these nodes are very necessary of course,
since without device node you cannot use it to read
files from.


Segher

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

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-18 18:57 [RFC] Device tree for new desktop platform in arch/powerpc Gerhard Pircher
2007-06-18 19:15 ` Mark A. Greer
2007-06-18 19:43   ` Gerhard Pircher
2007-06-18 20:25     ` Mark A. Greer
2007-06-19  5:08       ` David Gibson
2007-06-19  5:42 ` David Gibson
2007-06-19  6:16   ` Segher Boessenkool
2007-06-19  8:40   ` Gerhard Pircher
2007-06-19  9:14     ` Segher Boessenkool [this message]
2007-06-19  9:52       ` Gerhard Pircher
2007-06-19 10:08         ` Segher Boessenkool
2007-06-19 12:37           ` Gerhard Pircher
2007-06-19 13:15             ` Segher Boessenkool
2007-06-19 13:29               ` Gerhard Pircher
2007-06-21 12:42   ` Benjamin Herrenschmidt
2007-06-21 13:28     ` Gerhard Pircher
2007-06-21 14:59       ` Segher Boessenkool
2007-06-21 14:29     ` Segher Boessenkool
2007-06-21 23:25       ` Benjamin Herrenschmidt
2007-06-22  7:52         ` Segher Boessenkool
2007-06-22  8:16           ` Benjamin Herrenschmidt
2007-06-22  9:10             ` Segher Boessenkool
2007-06-19  6:08 ` Segher Boessenkool
2007-06-19  9:08   ` Gerhard Pircher
2007-06-19  9:28     ` Segher Boessenkool
2007-06-21 12:36 ` Benjamin Herrenschmidt
2007-06-21 13:20   ` Gerhard Pircher
2007-06-21 14:38     ` Segher Boessenkool
2007-06-21 16:27       ` Gerhard Pircher
2007-06-21 23:22     ` Benjamin Herrenschmidt
2007-06-22 13:12       ` Gerhard Pircher
2007-06-22 13:40         ` Benjamin Herrenschmidt
2007-06-21 14:24   ` Segher Boessenkool
2007-06-21 16:21     ` Gerhard Pircher

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=73aafd0955b8ea695af9221b48aaa3f1@kernel.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=david@gibson.dropbear.id.au \
    --cc=gerhard_pircher@gmx.net \
    --cc=linuxppc-dev@ozlabs.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).