[commit] r768 - in trunk/openbios-devel: arch/sparc64 drivers

[repository service]

Author: blueswirl
Date: Sun May  2 22:08:43 2010
New Revision: 768
URL: http://tracker.coreboot.org/trac/openbios/changeset/768

Log:
Sparc64: add upa-portid properties

Signed-off-by: Blue Swirl

Modified:
   trunk/openbios-devel/arch/sparc64/openbios.c
   trunk/openbios-devel/drivers/pci.c

Modified: trunk/openbios-devel/arch/sparc64/openbios.c
==============================================================================
--- trunk/openbios-devel/arch/sparc64/openbios.c	Sun May  2 22:01:34 2010	(r767)
+++ trunk/openbios-devel/arch/sparc64/openbios.c	Sun May  2 22:08:43 2010	(r768)
@@ -147,6 +147,11 @@
     push_str("cpuid");
     fword("property");

+    PUSH(0);
+    fword("encode-int");
+    push_str("upa-portid");
+    fword("property");
+
     PUSH(clock_frequency);
     fword("encode-int");
     push_str("clock-frequency");

Modified: trunk/openbios-devel/drivers/pci.c
==============================================================================
--- trunk/openbios-devel/drivers/pci.c	Sun May  2 22:01:34 2010	(r767)
+++ trunk/openbios-devel/drivers/pci.c	Sun May  2 22:08:43 2010	(r768)
@@ -446,6 +446,8 @@
         props[2] = 0x000007ef;
         props[3] = 0x000007e5;
         set_property(dev, "interrupts", (char *)props, 4 * sizeof(props[0]));
+        props[0] = 0x0000001f;
+        set_property(dev, "upa-portid", (char *)props, 1 * sizeof(props[0]));
         return 0;
 }

[commit] r768 - in trunk/openbios-devel: arch/sparc64 drivers

[Igor Kovalenko]

On Mon, May 3, 2010 at 12:08 AM, repository service  wrote:
> Author: blueswirl
> Date: Sun May  2 22:08:43 2010
> New Revision: 768
> URL: http://tracker.coreboot.org/trac/openbios/changeset/768
>
> Log:
> Sparc64: add upa-portid properties
>
> Signed-off-by: Blue Swirl
>
> Modified:
>   trunk/openbios-devel/arch/sparc64/openbios.c
>   trunk/openbios-devel/drivers/pci.c
> Modified: trunk/openbios-devel/arch/sparc64/openbios.c
>
> --- trunk/openbios-devel/arch/sparc64/openbios.c        Sun May  2 22:01:34 2010        (r767)
> +++ trunk/openbios-devel/arch/sparc64/openbios.c        Sun May  2 22:08:43 2010        (r768)
> @@ -147,6 +147,11 @@
>     push_str("cpuid");
>     fword("property");
> PUSH(0);
> fword("encode-int");
> push_str("upa-portid");
> fword("property");
>
> PUSH(clock_frequency);
>     fword("encode-int");
>     push_str("clock-frequency");
> Modified: trunk/openbios-devel/drivers/pci.c
>
> --- trunk/openbios-devel/drivers/pci.c  Sun May  2 22:01:34 2010        (r767)
> +++ trunk/openbios-devel/drivers/pci.c  Sun May  2 22:08:43 2010        (r768)
> @@ -446,6 +446,8 @@
>         props[2] = 0x000007ef;
>         props[3] = 0x000007e5;
>         set_property(dev, "interrupts", (char *)props, 4 * sizeof(props[0]));
> props[0] = 0x0000001f;
> set_property(dev, "upa-portid", (char *)props, 1 * sizeof(props[0]));
>
> return 0;
>  }

This reminds me to ask a question if we have to encode all properties
as 32bit integers.

At the moment there are a few places which encode cells (64bit on
sparc64) to properties.
F.e. it breaks linux kernel code which expects framebuffer properties
to be 32bit whereas init_video will encode 64bit values.

[commit] r768 - in trunk/openbios-devel: arch/sparc64 drivers

[Tarl Neustaedter]

On 2010-5-2 4:20 PM, Igor Kovalenko wrote:
> [...]
> This reminds me to ask a question if we have to encode all properties
> as 32bit integers.

By tradition, yes - the assumption is that you write bindings for all 
implementations, not just for your particular implementation, so you 
can't assume the implementation has 64-bit cells. Also, if you look at 
the 1275 standard for "encode-int" (page 140 or so), it states 
specifically that it produces a string of /four/ bytes, with high-order 
byte being first in order (i.e., big-endian ordering).
> At the moment there are a few places which encode cells (64bit on
> sparc64) to properties.
> F.e. it breaks linux kernel code which expects framebuffer properties
> to be 32bit whereas init_video will encode 64bit values.

If they are encoding ints (with encode-int), they *must* be 32-bit 
items. If they are encoding byte-arrays, they can do anything.