linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Petr Vandrovec Ing. VTEI" <VANDROVE@vc.cvut.cz>
To: Owen Waller <O.Waller@ee.qub.ac.uk>
Cc: linuxppc-dev@lists.linuxppc.org
Subject: Re: matroxfb, anybody? (More details...)
Date: Mon, 1 Feb 1999 17:38:06 MET-1	[thread overview]
Message-ID: <1F2ACA229B9@vcnet.vc.cvut.cz> (raw)

[-- Attachment #1: Mail message body --]
[-- Type: text/plain, Size: 1697 bytes --]

On  1 Feb 99 at 15:30, Owen Waller wrote:
> o.k. well the x86 board definelty doesn't... So we now have a more general
> problem:
> If I have two idential video boards in my Mac one "mac" specific which
> shows up in the OF tree, and one that is x86 sourced and doesn't show up
> under OF how can we initialise both boards correctly.
If you have at least one matrox in your OF tree, driver will initialize
all matroxes from offb. If you have no matrox in OF tree, driver will
initialize them from matrox_init.
> im my case matroxfb will become my primary head, but I'd still like access
> to the internal (control) video in case soemthing in a new kernel dies
> before matroxfb is initialised.
Without offb you can set order by
video=control: video=matrox:
to get control first (or vice versa to get matrox first). With offb I do not
know.

So, attached patch adds back that matrox_init is called unless you
specify `video=matrox:off' on command line. In this case, matrox can
be still initialized through offb. If you specify `video=matrox:disabled',
driver will be unavailable for offb too.
Also, driver still does not use device_node passed to driver by offb
because of no-one told me what I can expect in that variable... Driver
uses nvram_read_byte(NV_VMODE & NV_CMODE) to set initial resolution if
offb is enabled.
                                    Best regards,
                                        Petr Vandrovec
                                        vandrove@vc.cvut.cz

P.S.: I hope that your list survive this 890 bytes long attachment.
P.P.S.: As usual, cc-me if you have comments/question/...
P.P.P.S.: If patch will not apply cleanly, apply Geert's scr_readw()
patches first.

[-- Attachment #2: Text from file 'OW' --]
[-- Type: text/plain, Size: 890 bytes --]

--- linux-2.2.1.dist/drivers/video/matroxfb.c	Fri Jan 15 22:56:49 1999
+++ linux/drivers/video/matroxfb.c	Mon Feb  1 16:55:56 1999
@@ -4,7 +4,7 @@
  *
  * (c) 1998,1999 Petr Vandrovec <vandrove@vc.cvut.cz>
  *
- * Version: 1.9 1999/01/04
+ * Version: 1.13 1999/02/01
  *
  * MTRR stuff: 1998 Tom Rini <tmrini@ntplx.net>
  *
@@ -5743,20 +5748,26 @@
 }
 
 #ifndef MODULE
+static int __init initialized = 0;
+
 __initfunc(void matroxfb_init(void))
 {
 	DBG("matroxfb_init")
-#if defined(CONFIG_FB_OF)
-/* Nothing to do, must be called from offb */
-#else	
-	matrox_init();
-#endif
+	
+	if (!initialized) {
+		initialized = 1;
+		matrox_init();
+	}
 }
 
 #if defined(CONFIG_FB_OF)
 __initfunc(int matrox_of_init(struct device_node *dp)) {
 	DBG("matrox_of_init");
-	matrox_init();
+	
+	if (!initialized) {
+		initialized = 1;
+		matrox_init();
+	}
 	if (!fb_list) return -ENXIO;
 	return 0;
 }

             reply	other threads:[~1999-02-01 17:38 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-02-01 17:38 Petr Vandrovec Ing. VTEI [this message]
1999-02-01 17:15 ` matroxfb, anybody? (More details...) Geert Uytterhoeven
1999-02-01 20:32   ` Owen Waller
1999-02-01 20:38   ` 2.2.1 & serial ports Owen Waller
1999-02-02  0:30     ` Matt McLean
  -- strict thread matches above, loose matches on Subject: below --
1999-02-02 12:53 matroxfb, anybody? (More details...) Petr Vandrovec Ing. VTEI
1999-02-04  5:49 ` dhiltgen@toocool.calpoly.edu
1999-02-04 22:52   ` Takashi Oe
1999-02-01 18:32 Petr Vandrovec Ing. VTEI
1999-02-01 15:55 Benjamin Herrenschmidt
1999-02-01 16:25 ` Geert Uytterhoeven
1999-02-02 15:10   ` Owen Waller
1999-02-02 20:03     ` Geert Uytterhoeven
1999-02-01 12:51 Petr Vandrovec Ing. VTEI
1999-02-01 12:08 ` Geert Uytterhoeven
1999-02-01 16:30   ` Owen Waller
1999-02-01 16:18     ` Geert Uytterhoeven
1999-02-01 19:14     ` Benjamin Herrenschmidt
1999-02-01 20:30       ` Owen Waller
1999-02-02 15:04       ` Owen Waller
1999-02-01 10:34 Petr Vandrovec Ing. VTEI
1999-02-01 10:04 ` Geert Uytterhoeven
1999-02-01 12:35 ` Owen Waller
1999-02-02 10:37   ` dhiltgen@toocool.calpoly.edu
1999-01-30 10:00 matroxfb, anybody? dhiltgen@toocool.calpoly.edu
1999-01-30 15:32 ` Owen Waller
1999-01-30 23:34   ` matroxfb, anybody? (More details...) dhiltgen@toocool.calpoly.edu
1999-01-31  9:38     ` Gerd Knorr
1999-01-31 14:24       ` Geert Uytterhoeven
1999-02-06 15:22         ` Gerd Knorr
1999-01-31 14:36     ` Geert Uytterhoeven

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=1F2ACA229B9@vcnet.vc.cvut.cz \
    --to=vandrove@vc.cvut.cz \
    --cc=O.Waller@ee.qub.ac.uk \
    --cc=linuxppc-dev@lists.linuxppc.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).