Silicon Motion 712 (Lynx EM+) and AMD Alchemy

[Ted Schroeder]

We are building a system that has an AMD Alchemy chip and a Silicon Motion 712
(Lynx EM+) graphics subsystem. I want to run Linux on this system and am trying
to figure out how to deal with the (new) graphics chip. We currently have a
similar system based on the Epson chip, which has a framebuffer driver built
into the 2.4.20 kernel that we are using. I then build a kdrive (TinyX) X server
and use the framebuffer mechanism for talking to the screen. This all works
fine, except the Epson doesn't have enough memory bandwidth to drive both and
LCD and a CRT display at the same time which is a requirement of this particular
device.

So, now I need to make the SM712 chip work in a similar, low memory, low storage
environment.

Anyway, a couple of questions:

1) Can I just use the VESA frame buffer driver with this setup? (That is, VESA
claims to be x86 only, but will it work in this setup?)

2) If not, does a frame buffer driver exist for the SM712 chip?

Any help greatly appreciated.

Ted Schroeder
FreeHand Systems, Inc.

[Lewin A.R.W. Edwards]

> fine, except the Epson doesn't have enough memory bandwidth to drive both and
> LCD and a CRT display at the same time which is a requirement of this

> 1) Can I just use the VESA frame buffer driver with this setup? (That is, VESA
> claims to be x86 only, but will it work in this setup?)

The question is kind of bass-ackwards. The VESA framebuffer driver is
not really "x86-specific" as such, but the whole idea is predicated on
the existence of a VESA BIOS in your target system. An extended int
10h call is made to set the video mode. If your system doesn't have a
VESA BIOS extension (which it won't if it's not a vanilla x86 system)
then the concept of using the VESA driver is meaningless.

> 2) If not, does a frame buffer driver exist for the SM712 chip?

There is no direct kernel support for the Lynx series. Are you
planning to use this chip as a long-term solution? TTBOMK SMI is out
of that business (retail graphics chips) - at least they claimed to be
when we last tried to talk to them a couple of years ago. I would say
that Trident is a better choice for future production.

By the way, have you considered one of the other Epson parts, e.g.
SED1386, which can support CRT or LCD? Or do you need dual-head
operation with different outputs on CRT and LCD?

[Ted Schroeder]

Thanks for the response:

Lewin A.R.W. Edwards wrote:
>>fine, except the Epson doesn't have enough memory bandwidth to drive both and
>>LCD and a CRT display at the same time which is a requirement of this
>>1) Can I just use the VESA frame buffer driver with this setup? (That is, VESA
>>claims to be x86 only, but will it work in this setup?)
>
>
> The question is kind of bass-ackwards. The VESA framebuffer driver is
> not really "x86-specific" as such, but the whole idea is predicated on
> the existence of a VESA BIOS in your target system. An extended int
> 10h call is made to set the video mode. If your system doesn't have a
> VESA BIOS extension (which it won't if it's not a vanilla x86 system)
> then the concept of using the VESA driver is meaningless.
>

Thanks for that tip. I know that X has some int10 simulation stuff in it. I'll
take a closer look at that.

>
>>2) If not, does a frame buffer driver exist for the SM712 chip?
>
>
> There is no direct kernel support for the Lynx series. Are you
> planning to use this chip as a long-term solution? TTBOMK SMI is out
> of that business (retail graphics chips) - at least they claimed to be
> when we last tried to talk to them a couple of years ago. I would say
> that Trident is a better choice for future production.

Hmm. That's news to me. We're finding no problem getting SM712 chips in plenty
of volume for the forseeable future. I will ask our hardware guy about this.

>
> By the way, have you considered one of the other Epson parts, e.g.
> SED1386, which can support CRT or LCD? Or do you need dual-head
> operation with different outputs on CRT and LCD?

We're using the SED1386 now and it, quite honestly, is not even close to
powerful enough to get the job done. It barely supports 800x600x16 and when you
put it in that mode the memory bandwidth is so limited that we had to reduce the
refresh rate to about 30 Hz to allow the CPU enough access to the VRAM so that
screen paints didn't take several seconds. This same memory bandwidth problem is
the reason why right now we can only output to either the CRT or the LCD. Not
enough bandwidth to make them both run at the same time. In addition, we're
going to 1024x768 size screens which aren't supported at all by the 1386.

Ted