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

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

[RFC/PATCH 0/3] Attempt at making 32bit BAT assignment more intelligent

[Grant Likely]

Here is my attempt to make BAT allocations dynamic instead of hard coded.
The first patch changes setbat() to dynamically assign BATs instead of requiring
the caller to select a BAT on its own.

A primary user of setbat is mmu_mapin_ram() which used to hard code BATs
2 and 3 for mapping as much of RAM as can fit in 2 BATs.  The first patch
changes the routine to try to use as many BATs as it needs to map all of RAM.
(Note: I've still got BAT0 reserved for mapping RAM, so even if lots of other
users of setbat() appear, RAM is guaranteed to be allocated at least 1 BAT).

The first patch also adds an ioremap_bat() function which works like
ioremap(), but uses BATs instead of page tables and can be called really
early (before MMU_init()).  ioremap_bat() mappings persist after MMU_init
is called too so it can be used to map all of an SoC's IMMR region, or
any other IO device for that matter.  I've seen about a 2.5% performance
improvement by using this on a simple network workload with SoC registers
BAT mapped.

The second patch is just a utility function required by the third patch.

The third patch is a new user of ioremap_bat() to implement early debug
support for the mpc5200 platform.

The first patch is the one I really want feedback on.  It shouldn't break
any 32 bit platforms, but I need testing to make sure.  Also, this is my
first attempt at messing with MMU code, so please let me know if I'm doing
anything foolish or dangerous.

Kumar, Josh; I'd appreciate testing to make sure patch 1 doesn't break stuff.

Thanks,
g.

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

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

[Grant Likely]

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.

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---

 drivers/of/base.c  |   24 ++++++++++++++++++++++++
 include/linux/of.h |    1 +
 2 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index ad8ac1a..10c6a46 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -473,3 +473,27 @@ int of_modalias_node(struct device_node *node, char *modalias, int len)
 }
 EXPORT_SYMBOL_GPL(of_modalias_node);
 
+/**
+ * of_lookup_stdout - find node pointed to by chosen linux,stdout-path property
+ *
+ * This routine returns a pointer to the stdout node or NULL on failure
+ */
+struct device_node __init *of_lookup_stdout(void)
+{
+	struct device_node *chosen, *stdout_node;
+	const char *stdout_path;
+
+	chosen = of_find_node_by_path("/chosen");
+	if (!chosen)
+		return NULL;
+
+	stdout_path = of_get_property(chosen, "linux,stdout-path", NULL);
+	if (!stdout_path) {
+		of_node_put(chosen);
+		return NULL;
+	}
+
+	stdout_node = of_find_node_by_path(stdout_path);
+	of_node_put(chosen);
+	return stdout_node;
+}
diff --git a/include/linux/of.h b/include/linux/of.h
index 79886ad..e8b215b 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -71,5 +71,6 @@ extern int of_n_size_cells(struct device_node *np);
 extern const struct of_device_id *of_match_node(
 	const struct of_device_id *matches, const struct device_node *node);
 extern int of_modalias_node(struct device_node *node, char *modalias, int len);
+struct device_node __init *of_lookup_stdout(void);
 
 #endif /* _LINUX_OF_H */

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

[Michael Ellerman]

[-- Attachment #1: Type: text/plain, Size: 682 bytes --]

On Wed, 2008-08-06 at 00:02 -0600, Grant Likely 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.

Nice. You don't feel like converting all the places that currently do it
by hand to use this do you :)

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Grant Likely]

On Wed, Aug 6, 2008 at 12:14 AM, Michael Ellerman
<michael@ellerman.id.au> wrote:
> On Wed, 2008-08-06 at 00:02 -0600, Grant Likely 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.
>
> Nice. You don't feel like converting all the places that currently do it
> by hand to use this do you :)

Yep, I'll do this.  :-)

g.

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 930 bytes --]

Hi Grant,

On Wed, 6 Aug 2008 00:34:04 -0600 "Grant Likely" <grant.likely@secretlab.ca> wrote:
>
> On Wed, Aug 6, 2008 at 12:14 AM, Michael Ellerman
> <michael@ellerman.id.au> wrote:
> > On Wed, 2008-08-06 at 00:02 -0600, Grant Likely 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.
> >
> > Nice. You don't feel like converting all the places that currently do it
> > by hand to use this do you :)
> 
> Yep, I'll do this.  :-)

Could you also send an email to Dave Miller to see if he has any objections
to this function being generic (since the Sparc guys share this code).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[David Miller]

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 6 Aug 2008 17:42:33 +1000

> Hi Grant,
> 
> On Wed, 6 Aug 2008 00:34:04 -0600 "Grant Likely" <grant.likely@secretlab.ca> wrote:
> >
> > On Wed, Aug 6, 2008 at 12:14 AM, Michael Ellerman
> > <michael@ellerman.id.au> wrote:
> > > On Wed, 2008-08-06 at 00:02 -0600, Grant Likely 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.
> > >
> > > Nice. You don't feel like converting all the places that currently do it
> > > by hand to use this do you :)
> > 
> > Yep, I'll do this.  :-)
> 
> Could you also send an email to Dave Miller to see if he has any objections
> to this function being generic (since the Sparc guys share this code).

I already voiced my concerns.

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 377 bytes --]

On Wed, 6 Aug 2008 17:42:33 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Could you also send an email to Dave Miller to see if he has any objections
> to this function being generic (since the Sparc guys share this code).

So I should read ahead :-)

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[David Miller]

From: Grant Likely <grant.likely@secretlab.ca>
Date: Wed, 06 Aug 2008 00:02:44 -0600

> 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.
> 
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

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".

If this of_lookup_stdout() is going into generic OF code, it should be
done in a way that works on all platforms.  All of these "linux,*"
properties and node names are powerpc platform specific.

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

[Grant Likely]

On Wed, Aug 6, 2008 at 12:32 AM, David Miller <davem@davemloft.net> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
> Date: Wed, 06 Aug 2008 00:02:44 -0600
>
>> 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.
>>
>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>
> 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".

How about if I modify it to try both methods?

g.

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

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

[David Miller]

From: "Grant Likely" <grant.likely@secretlab.ca>
Date: Wed, 6 Aug 2008 00:35:24 -0600

> On Wed, Aug 6, 2008 at 12:32 AM, David Miller <davem@davemloft.net> wrote:
> > From: Grant Likely <grant.likely@secretlab.ca>
> > Date: Wed, 06 Aug 2008 00:02:44 -0600
> >
> >> 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.
> >>
> >> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> >
> > 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".
> 
> How about if I modify it to try both methods?

Sure, that would be nice.

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

[Benjamin Herrenschmidt]

On Wed, 2008-08-06 at 00:35 -0600, Grant Likely wrote:
> On Wed, Aug 6, 2008 at 12:32 AM, David Miller <davem@davemloft.net> wrote:
> > From: Grant Likely <grant.likely@secretlab.ca>
> > Date: Wed, 06 Aug 2008 00:02:44 -0600
> >
> >> 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.
> >>
> >> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> >
> > 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".
> 
> How about if I modify it to try both methods?

The sparc method however cannot be used on powerpc because it requires
a call to OF to do the "live" conversion (ie, instance-to-path). In
fact, our /chosen/linux,stdout-path is just a cached result of that
conversion done during boot.

Ben.

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

[Paul Mackerras]

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.

Paul.

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

[David Miller]

From: Paul Mackerras <paulus@samba.org>
Date: Wed, 6 Aug 2008 20:21:04 +1000

> 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.

I do it right when I build the in-kernel OBP tree.  Then I cache
these results in:

extern struct device_node *of_console_device;
extern char *of_console_path;
extern char *of_console_options;

which are declared in asm/prom.h

I could compute it even earlier and just store a phandle instead
of a device_node pointer.

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

[Timur Tabi]

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?

-- 
Timur Tabi
Linux kernel developer at Freescale

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

[David Gibson]

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.

-- 
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

[Yoder Stuart]

=20

> -----Original Message-----
> From: linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org]=20
> 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()=20
> utility function
>=20
> On Wed, Aug 06, 2008 at 11:46:47AM -0500, Timur Tabi wrote:
> > On Wed, Aug 6, 2008 at 1:02 AM, Grant Likely=20
> <grant.likely@secretlab.ca> wrote:
> > > From: Grant Likely <grant.likely@secretlab.ca>
> > >
> > > of_lookup_stdout() is useful for figuring out what device=20
> to use as output
> > > for early boot progress messages.  It returns the node=20
> pointed to by the
> > > linux,stdout-path property in the chosen node.
> >=20
> > I thought linux,stdout-path is deprecated are we're supposed to be
> > using the aliases node instead?
>=20
> 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

[Grant Likely]

On Thu, Aug 07, 2008 at 04:12:54PM +1000, David Gibson wrote:
> 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.

So, seeing as settling on a way to determine stdout still up in the air,
it probably makes sense to condense that code down to a single
authoritative function so that changes in this area are contained in one
place.  For now, I'll stick with decoding linux,stdout-path and on Sparc
decoding the ihandle with the expectation that there will be further
refinements to be made.

g.

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

[Timur Tabi]

Grant Likely wrote:

> So, seeing as settling on a way to determine stdout still up in the air,
> it probably makes sense to condense that code down to a single
> authoritative function so that changes in this area are contained in one
> place.  For now, I'll stick with decoding linux,stdout-path and on Sparc
> decoding the ihandle with the expectation that there will be further
> refinements to be made.

Ack.


-- 
Timur Tabi
Linux Kernel Developer @ Freescale

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

[Benjamin Herrenschmidt]

On Wed, 2008-08-06 at 11:46 -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?

You are mixing two completely different things afaik.

Ben.