lkml.org 
[lkml]   [1998]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: S3 High Speed text font support in vgacon.c [patch 2.1.112]


On Fri, 31 Jul 1998, Geert Uytterhoeven wrote:

> > On mine (PreP) it would not be initialized at all either, although later
> > versions of the firmware finally allocate PCI resources. But the worst
>
> I even have to allocate PCI resources for my S3.

Not sure, see later comments.

> I've been thinking about adding code for that to the kernel, but it's not
> trivial: how do you find out which devices have been assigned PCI resources
> already? Is this the correct way?
>
> oldaddr = pci_read(PCI_BASE_ADDRESS_i);
> pci_write(PCI_BASE_ADDRESS_i, -1);
> newaddr = pci_read(PCI_BASE_ADDRESS_i);
> if (oldaddr == newaddr) {
> /* not assigned */
> newaddr = pci_alloc(newaddr);
> pci_write(PCI_BASE_ADDRESS_i, newaddr);
> } else {
> /* assigned */
> pci_write(PCI_BASE_ADDRESS_i, oldaddr);
> }

Not necessarily correct, nothing in theory prevents the address from a
device to be the highest possible one. It depends whether the address is
valid from the motherboard/architecture pooint of view. Often it is not
the case since high addresses are reserved for boot ROMs... but it is
only an heuristic which will work in most cases but cannot be guaranteed.

IIRC setting an address to 0 disables the corresponding decoder (I'm sure
for I/O space, not absolutely for memory space).

> OK, this is a bit simplistic. I need two passes to prealloc the already
> assigned stuff. I cannot reassign new adresses to already assigned stuff since
> those adresses may be in the Open Firmware device tree properties, and thus
> can't be changed.

Well, you may have to find the free addresses. I was trying to write a PCI
resource allocator and it's not that simple when you have bridges. I
might have some working code next week. But why do you want to keep
the resources assigned by OF (I mean address space, not interrupts
obviously) ? OF is not used after boot, after all.
Anyway current OF releases are still quite buggy and forget to allocate
resources to all devices. This is plain wrong since it prevents you from
using the components. I simply would not rely on OF resource allocation.
Even if you use RTAS, IIRC you have a function to tell the system that you
have remapped the resources so that it can track your changes.

> And I have to enable PCI_COMMAND_IO and PCI_COMMAND_MEMORY, if necessary,
> right?

Very likely.

> `lspci -v' gives for me (stripped irrelevant information):
> | 00:03.0 VGA compatible controller: S3 Inc. Vision 968
> | Flags: stepping, medium devsel, IRQ 28
>

It's not exactly like this: on my board lspci -vvx gives:

00:10.0 VGA compatible controller: S3 Inc. 86C764_1 [Trio 32/64 vers 1]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 15
00: 33 53 11 88 00 00 00 02 00 00 00 03 00 00 00 00
10: 00 00 00 3b 00 00 00 00 00 00 00 00 00 00 00 00
^^^^^^^^^^^
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 ff ff 00 00 00 00 00 00 00 00 0f 01 00 00

as you can see from the hex dump ;), the memory area has been allocated by
the firmware at address 0x3b000000. lspci does not report it since memory
accesses have not been enabled (Mem-).

> i.e. nothing assigned for the Vision968.
>
> | 00:05.0 VGA compatible controller: ATI Technologies Inc 215GT [Mach64 GT] (rev 9a)
> | Flags: stepping, medium devsel, IRQ 30
> | Memory at c2000000 (32-bit, non-prefetchable)
> | Memory at fffff000 (32-bit, non-prefetchable)
>
> The first memory block of the RAGE II+ is assigned, the second isn't.

Ok, it seems clear it is not assigned knowing the PPC architecture. But
it could be perfectly valid on other architectures. So I believe that
the S3 resources have not been assigned either.

> > part was that the S3 specific initialization code in the PPC port of Linux
> > would not work either.
>
> Same for me.

So I'm not alone ;)

> > To solve the problem I have written a small (~24kB code+data) real mode
> > 80486SX emulator which executes the x86 BIOS initialization routine on the
> > PPC. It works well for me, but unfortunately AFAIK the few people who
> > have tried it on their machines have not been successful :-(
> >
> > The code was written as an user mode utility but still needs some
> > modifications to run under 2.1. Of course I'm using a serial console
> > since the screen is unreadable until the utility runs.
>
> If you port it to 2.1.112, I'm willing to try on my Vision968 ;-)

Hopefully on Monday.

Greetings,
Gabriel.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.078 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site