Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function

Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function

[Grant Likely]

On Wed, Aug 6, 2008 at 4:21 AM, Paul Mackerras <paulus@samba.org> wrote:
> David Miller writes:
>
>> On sparc platforms this is obtained differently.  We obtain the 32-bit
>> instance value of "/chosen/stdout" and convert that into a prom device
>> node path using "instance-to-path".
>
> That's actually exactly what we do too, the linux,stdout-path property
> is just a cache of the result of that process.  The difference is that
> we have to do it early on while we still have OF around, while you can
> do it later.

It's not what we do with flattened device trees blobs though.  In the
flattened tree we're not using a /chosen/stdout property, just the
linux,stdout-path one.

The question that remains is; should there be?  Should the dt blobs
use /chosen/stdout also?  (I'm not familiar enough with real OF to
know the answer.  I'm assuming that an instance value is not the same
as a phandle).

g.

>
> Paul.
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function

[Segher Boessenkool]

> It's not what we do with flattened device trees blobs though.  In the
> flattened tree we're not using a /chosen/stdout property, just the
> linux,stdout-path one.
>
> The question that remains is; should there be?  Should the dt blobs
> use /chosen/stdout also?  (I'm not familiar enough with real OF to
> know the answer.  I'm assuming that an instance value is not the same
> as a phandle).

ihandles and phandles are not the same thing in OF.  Since in the
"flat world" we cannot have instances, we should use phandles instead
of ihandles for the things in /chosen.  I thought we agreed on that
already, perhaps I am wrong?


Segher

Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function

[Mitch Bradley]

Segher Boessenkool wrote:
>> It's not what we do with flattened device trees blobs though.  In the
>> flattened tree we're not using a /chosen/stdout property, just the
>> linux,stdout-path one.
>>
>> The question that remains is; should there be?  Should the dt blobs
>> use /chosen/stdout also?  (I'm not familiar enough with real OF to
>> know the answer.  I'm assuming that an instance value is not the same
>> as a phandle).

The difference between a phandle and an ihandle is similar to the 
difference between (the inode of) an executable files on disk and (the 
process id of) a running process.  A phandle refers to the static 
information that describes a device, while an ihandle refers to a 
particular (out of potentially several) active instantiation of the OFW 
driver for that devices.  An "instance value" is a data item that can 
have a different value for each of the running instances of a given 
driver.  In the analogy, an instance value is like a data segment variable.

Given an ihandle, you can get the corresponding phandle with 
ihandle>phandle.  You can't go from phandle to ihandle, because that 
direction is one-to-many.

Why you you ever need more than one running instance of a given driver?  
For leaf devices, it is pretty rare to have multiple instances.  
Multiple instances are more often used for intermediate nodes.  The same 
intermediate node - for example a usb node - is often the parent of 
several leaf nodes that are active simultaneously.  When you open a 
device, its device tree parents up to the root are implicitly opened.  
Each such instance can hold dynamic state on behalf of its children.

>
> ihandles and phandles are not the same thing in OF.  Since in the
> "flat world" we cannot have instances, we should use phandles instead
> of ihandles for the things in /chosen.  I thought we agreed on that
> already, perhaps I am wrong?
>
>
> Segher
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@ozlabs.org
> https://ozlabs.org/mailman/listinfo/devicetree-discuss
>

Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function

[David Gibson]

On Wed, Aug 06, 2008 at 06:25:48PM +0200, Segher Boessenkool wrote:
>> It's not what we do with flattened device trees blobs though.  In the
>> flattened tree we're not using a /chosen/stdout property, just the
>> linux,stdout-path one.
>>
>> The question that remains is; should there be?  Should the dt blobs
>> use /chosen/stdout also?  (I'm not familiar enough with real OF to
>> know the answer.  I'm assuming that an instance value is not the same
>> as a phandle).
>
> ihandles and phandles are not the same thing in OF.  Since in the
> "flat world" we cannot have instances, we should use phandles instead
> of ihandles for the things in /chosen.  I thought we agreed on that
> already, perhaps I am wrong?

Not that I recall.  In general we've been avoiding using anything that
traditionally contains an ihandle; hence the direct use of
linux,stdout-path when using a flat tree.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function

[Benjamin Herrenschmidt]

> It's not what we do with flattened device trees blobs though.  In the
> flattened tree we're not using a /chosen/stdout property, just the
> linux,stdout-path one.
> 
> The question that remains is; should there be?  Should the dt blobs
> use /chosen/stdout also?  (I'm not familiar enough with real OF to
> know the answer.  I'm assuming that an instance value is not the same
> as a phandle).

Yup, there are two issues there:

 - The instance value would have to be converted to a phandle while
OF is still alive. I initially did that and added a stdout-node or so
property, but that still hit the next issue.

 - IBM machines has this weird distinction between the real phandle
and the ibm,phandle, the later being the same except for things
that get hotplugged ... and some of the vdevices. We got really
confused trying to sort that out with the output device.

So in the end, I decided to just convert the ihandle to a path and
stick that path in the device-tree.

Cheers,
Ben.

RE: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function

[Yoder Stuart]

 

> -----Original Message-----
> From: linuxppc-dev-bounces+b08248=freescale.com@ozlabs.org 
> [mailto:linuxppc-dev-bounces+b08248=freescale.com@ozlabs.org] 
> On Behalf Of David Gibson
> Sent: Thursday, August 07, 2008 1:13 AM
> To: Tabi Timur
> Cc: linuxppc-dev@ozlabs.org; paulus@samba.org; miltonm@bga.com
> Subject: Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() 
> utility function
> 
> On Wed, Aug 06, 2008 at 11:46:47AM -0500, Timur Tabi wrote:
> > On Wed, Aug 6, 2008 at 1:02 AM, Grant Likely 
> <grant.likely@secretlab.ca> wrote:
> > > From: Grant Likely <grant.likely@secretlab.ca>
> > >
> > > of_lookup_stdout() is useful for figuring out what device 
> to use as output
> > > for early boot progress messages.  It returns the node 
> pointed to by the
> > > linux,stdout-path property in the chosen node.
> > 
> > I thought linux,stdout-path is deprecated are we're supposed to be
> > using the aliases node instead?
> 
> During the ePAPR process this idea came up - standardising a 'stdout'
> alias that would replace linux,stdout-path in chosen.  However that
> was done in ignorance of the history of the linux,stdout-path property
> and its connection to the stdout ihandle in chosen.  In any case, the
> proposed 'stdout' alias didn't make the final cut for ePAPR, so how to
> address this for flat-tree systems is still an open question.

In the ePAPR discussion I think we generally agreed that
an alias was better than a property under /chosen.  There
were 2 things that caused us to delete the /aliases/stdout.

One was discussions around whether we needed to support
multiple consoles somehow.

The second was the idea that we may need a /aliases/stdin as well.
You could conceptually have stdout be a monitor and a stdin
be a keyboard.

Stuart

Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function

[Timur Tabi]

Yoder Stuart wrote:

> The second was the idea that we may need a /aliases/stdin as well.
> You could conceptually have stdout be a monitor and a stdin
> be a keyboard.

I don't think the hypervisor console subsystem supports this.  I don't see any
way of registering separate clients for input vs. output.

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function

[Milton Miller]

TimurTabi wrote:
> Yoder Stuart wrote:
> 
> > The second was the idea that we may need a
> > /aliases/stdin as well. You could conceptually have
> > stdout be a monitor and a stdin be a keyboard.
> 
> I don't think the hypervisor console subsystem supports
> this.  I don't see any way of registering separate clients
> for input vs. output.

Why should what the hvc driver support have any effect on
what the binding should be?

And anyways, both the boot wrapper and udbg (and hence early
debug console) have totally indepenedent functions for
reading and writing.  

And for that matter, we also support output on monitor and
input on keyboard for linear frame buffer on 6xx via the
btext output (but only adb input).

milton

Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function

[Timur Tabi]

Milton Miller wrote:

> Why should what the hvc driver support have any effect on
> what the binding should be?

Because my hypervisor console driver uses the hypervisor console/tty subsystem.
 If the subsystem assumes one stdout/stdin device, then I must abide by that.

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function

[Scott Wood]

Timur Tabi wrote:
> Milton Miller wrote:
> 
>> Why should what the hvc driver support have any effect on
>> what the binding should be?
> 
> Because my hypervisor console driver uses the hypervisor console/tty subsystem.
>  If the subsystem assumes one stdout/stdin device, then I must abide by that.

So fix the subsystem, don't use the subsystem, or live with the fact 
that you support a subset of what the device tree can express.  Don't 
cripple the device tree because of that.

-Scott