On 8 Feb 01 at 13:14, Alex Deucher wrote:
> Jeff Hartmann wrote:
> > Petr Vandrovec wrote:
> > It does not use dynamic DMA mapping, because it doesn't do PCI DMA at
> > all. It uses AGP DMA. Actually, it shouldn't be too hard to get it to
> > work on the Alpha (just a few 32/64 bit issues probably.) Someone just
> > needs to get agpgart working on the Alpha, thats the big step.
>
> That shouldn't be too hard since many (all?) AGP alpha boards (UP1000's
> anyway) are based on the AMD 751 Northbridge? And there is already
> support for that in the kernel for x86.
My AlphaPC 164LX does not have AGP at all - and I want to get G200/G400 PCI
working on it with dri, using 21174 features.
Petr Vandrovec
[email protected]
There is preliminary support for pcigart in the dri tree. I believe
some people have had some success with it.
Alex
Petr Vandrovec wrote:
>
> On 8 Feb 01 at 13:14, Alex Deucher wrote:
> > Jeff Hartmann wrote:
> > > Petr Vandrovec wrote:
>
> > > It does not use dynamic DMA mapping, because it doesn't do PCI DMA at
> > > all. It uses AGP DMA. Actually, it shouldn't be too hard to get it to
> > > work on the Alpha (just a few 32/64 bit issues probably.) Someone just
> > > needs to get agpgart working on the Alpha, thats the big step.
> >
> > That shouldn't be too hard since many (all?) AGP alpha boards (UP1000's
> > anyway) are based on the AMD 751 Northbridge? And there is already
> > support for that in the kernel for x86.
>
> My AlphaPC 164LX does not have AGP at all - and I want to get G200/G400 PCI
> working on it with dri, using 21174 features.
> Petr Vandrovec
> [email protected]
>
Alex Deucher wrote:
> There is preliminary support for pcigart in the dri tree. I believe
> some people have had some success with it.
>
> Alex
>
> Petr Vandrovec wrote:
>
>> On 8 Feb 01 at 13:14, Alex Deucher wrote:
>>
>>> Jeff Hartmann wrote:
>>>
>>>> Petr Vandrovec wrote:
>>>
>>>> It does not use dynamic DMA mapping, because it doesn't do PCI DMA at
>>>> all. It uses AGP DMA. Actually, it shouldn't be too hard to get it to
>>>> work on the Alpha (just a few 32/64 bit issues probably.) Someone just
>>>> needs to get agpgart working on the Alpha, thats the big step.
>>>
>>> That shouldn't be too hard since many (all?) AGP alpha boards (UP1000's
>>> anyway) are based on the AMD 751 Northbridge? And there is already
>>> support for that in the kernel for x86.
>>
>> My AlphaPC 164LX does not have AGP at all - and I want to get G200/G400 PCI
>> working on it with dri, using 21174 features.
>> Petr Vandrovec
>> [email protected]
>>
pcigart is only for the r128/radeon (and the radeon support is not done
yet.) The has been success using pcigart on the PPC, I would suspect
the Alpha will probably be pretty easy to get going.
-Jeff
On Thu, 8 Feb 2001, Petr Vandrovec wrote:
> On 8 Feb 01 at 13:14, Alex Deucher wrote:
> > Jeff Hartmann wrote:
> > > Petr Vandrovec wrote:
>
> > > It does not use dynamic DMA mapping, because it doesn't do PCI DMA at
> > > all. It uses AGP DMA. Actually, it shouldn't be too hard to get it to
> > > work on the Alpha (just a few 32/64 bit issues probably.) Someone just
> > > needs to get agpgart working on the Alpha, thats the big step.
> >
> > That shouldn't be too hard since many (all?) AGP alpha boards (UP1000's
> > anyway) are based on the AMD 751 Northbridge? And there is already
> > support for that in the kernel for x86.
>
> My AlphaPC 164LX does not have AGP at all - and I want to get G200/G400 PCI
> working on it with dri, using 21174 features.
After looking into this a little more I have found it is uglier than that.
The answers I have are not very good.
I assume you are wanting to use this with X. There is a rather odd driver
issue involved.
There are two X drivers available for the G400. One from Matrox and one in
the version of X that you are using.
The Matrox driver will not work under the 2.4.x kernel for DRM due to a
version conflict. (It wants version 1.0 and 2.4.x uses version 2.0.) It
will also not compile with 4.0.2 and above at the present time.
The XFree86 version has some odd problems in Xinerama, but at least it
works. (Ugly artifact borders on the second screen.)
BUT...
Both drivers want Matrox's HALlib. (Which is x86 binary only.) Matrox will
not release the info on that interface to the chipset. (Using the
standard corporate excuse whenever they don't want to do something
"Intelectual Property concerns".)
Good luck on getting them to make an Alpha version of the library or get
them to release the underlying library interface specs.
[email protected] | Note to AOL users: for a quick shortcut to reply
Alan Olsen | to my mail, just hit the ctrl, alt and del keys.
"In the future, everything will have its 15 minutes of blame."
On Thu, 8 Feb 2001, Alex Deucher wrote:
> There is preliminary support for pcigart in the dri tree. I believe
> some people have had some success with it.
but there doesn't need to be. DEC 2x17x Alpha chipsets have an IOMMU
for hardware scatter-gather support. (ie generic agpgart for the PCI
bus).
why put in mga specific code? generic support for the IOMMU
capabilities of every recent (since the 20172 chipset at least iirc)
DEC chipset would benefit everything from cheap sound cards, to
high-end IO (scatter-gather even if hardware does not support it and
direct access to/from host memory > 4GB without needing bounce
buffers).
only machines without this IOMMU are the AMD chipset machines, but
they have AGP.
>
> Alex
--paulj
replying to myself..
On Fri, 9 Feb 2001, Paul Jakma wrote:
> why put in mga specific code?
last time i asked why 2x74x hardware iommu wasn't supported i was told
something along the lines of cause generic kernel driver interfaces
wouldn't support it. so support for the alpha hardware would require
changing certain global interfaces (and all the drivers using them).
so for the short-term i guess you will have to implement a dri-local
hack. However for the 2x17x boards you could make use of the IOMMU
and at least prove the usefullness of it. (and a speed benefit.)
--paulj
[email protected] said:
> Both drivers want Matrox's HALlib. (Which is x86 binary only.) Matrox
> will not release the info on that interface to the chipset. (Using
> the standard corporate excuse whenever they don't want to do something
> "Intelectual Property concerns".)
> Good luck on getting them to make an Alpha version of the library or
> get them to release the underlying library interface specs.
I submitted a patch to XFree86 on Tuesday which drives the primary head of
G450. It's a cleaned up version of Matrox's own code, and it works on Alpha
for me. Dual head will come later - we have the example code in matroxfb to
work from. All the binary-only HALlib does is mode setup - all the
acceleration is done in the open source code anyway, even when the HALlib
is present.
ftp://ftp.uk.linux.org/pub/people/dwmw2/X/mga-G450-patch
--
dwmw2
> > the standard corporate excuse whenever they don't want to do something
> > "Intelectual Property concerns".)
If open source people knew how it worked they might do horrible evil things
like TV-out with the macrovision turned off. Thats basically the root of all
this - yet again its the US movie industry
[email protected] said:
> If open source people knew how it worked they might do horrible evil
> things like TV-out with the macrovision turned off. Thats basically
> the root of all this - yet again its the US movie industry
Er... have you tried recording from the G400 TV out with matroxfb?
Try it. You might like it.
--
dwmw2
On Fri, 9 Feb 2001, David Woodhouse wrote:
> [email protected] said:
> > If open source people knew how it worked they might do horrible evil
> > things like TV-out with the macrovision turned off. Thats basically
> > the root of all this - yet again its the US movie industry
>
> Er... have you tried recording from the G400 TV out with matroxfb?
>
> Try it. You might like it.
Just because something is pointless does not mean that they are not going
to attempt to ram it down out throats.
But I could rant on that all day...
[email protected] | Note to AOL users: for a quick shortcut to reply
Alan Olsen | to my mail, just hit the ctrl, alt and del keys.
"In the future, everything will have its 15 minutes of blame."