Re: radeon-pre-2

Re: radeon-pre-2

[Jon Smirl]

On Fri, 10 Sep 2004 17:00:33 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > > > On Gwe, 2004-09-10 at 17:37, Jon Smirl wrote:
> > > >  The plan is to add fbdev capability to the DRM so that you won't need
> > > >  to run vesafb. DRM will give you the features found in VESA fb instead
> > > >  of you needing to load it separately.
> > > >
> > > Your personal plan.
> >
> > I'm writing code to fix the conflicts between vesafb, fbdev, DRM and
> > XAA and you're not. Either provide your own code for sorting out the
> > resource conflicts or keep your opinions to yourself.
> 
> You can write all the code you like its still "your personal plan". I
> have seen nothing but rejection of it by the kernel community.

My "personal plan" has been posted for comment to all relevant email
lists -- xorg, fbdev, dri, and lkml. All feedback that was received
was addressed and incorporated. Various aspects of the plan were
talked about at three OLS sessions. Everyone has been invited to
participate.  I even went through significant effort to encourage
fbdev developers to come to OLS and discuss the changes.

Plan as orginally posted to lkml:
http://lkml.org/lkml/2004/8/2/111

If the kernel community is going to reject this plan please let me
know now so that I won't waste a year of my life writing the code for
it. If Linux wants to stay with a 1980's desktop that's fine; at least
Microsoft and Apple are innovating.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: radeon-pre-2

[Alan Cox]

On Gwe, 2004-09-10 at 18:22, Jon Smirl wrote:
> My "personal plan" has been posted for comment to all relevant email
> lists -- xorg, fbdev, dri, and lkml. All feedback that was received
> was addressed and incorporated. Various aspects of the plan were

Addressed and eliminated would be closer. The BSD folks don't want GPL
frame buffer code in there kernel, nobody needs a single nasty splat
where DRI and fbdev got hammered into one block of code by someone with
a glue gun.

> Plan as orginally posted to lkml:
> http://lkml.org/lkml/2004/8/2/111

None of which is about nailing all the code together. You just don't
need to do that kind of stuff, and it'll make it much harder to
maintain.

Now, think about what happens if you register a pci handler for
everything which is "Video" class (or VIDEO/VGA). Your one mini module
now claims every video object in the kernel with a couple of exceptions
you can hand list.

vga_class.c now owns all the video devices. It can keep a global list
and a sorted by vga router list as well as letting frame buffer drivers
and other code add heads of a device lists.

Add register/unregister functions in the same format to allow DRI and FB
(and any future layers) to find cards and you don't need to glue stuff
together at all. You can load dri, you can load fb drivers, you can load
both. You also require minimal kernel changes to the drivers.

That is what I keep telling you, that is what I've been fiddling with
but keep getting distracted from by immediate locking and other kernel
catastrophes.

===
If the kernel community is going to reject this plan please let me
know now so that I won't waste a year of my life writing the code for
it. If Linux wants to stay with a 1980's desktop that's fine; at least
Microsoft and Apple are innovating.

I see you've been taking lessons from Hans Reiser.

Alan

Re: radeon-pre-2

[Jon Smirl]

On Fri, 10 Sep 2004 18:04:19 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Gwe, 2004-09-10 at 18:22, Jon Smirl wrote:
> > My "personal plan" has been posted for comment to all relevant email
> > lists -- xorg, fbdev, dri, and lkml. All feedback that was received
> > was addressed and incorporated. Various aspects of the plan were
> 
> Addressed and eliminated would be closer. The BSD folks don't want GPL
> frame buffer code in there kernel, nobody needs a single nasty splat
> where DRI and fbdev got hammered into one block of code by someone with
> a glue gun.

This has been discussed and we see the need to keep BSD's version of
DRM isolated from the Linux one.  There are several different schemes
that can be used to achieve this but there is agreement that GPL code
from Linux should not be mixed into the BSD code base.

For example DRM can link into the existing fbdev cfb* modules without
changing them. These modules are needed to implement OOPs display from
X. Another example is the radeon GPL I2C DDC driver. This will start
off as an isolated Linux feature. If a BSD coder wants to reimplement
this existing code GPL with a BSD license it can be added to the BSD
driver.

> 
> > Plan as orginally posted to lkml:
> > http://lkml.org/lkml/2004/8/2/111
> 
> None of which is about nailing all the code together. You just don't
> need to do that kind of stuff, and it'll make it much harder to
> maintain.
> 
> Now, think about what happens if you register a pci handler for
> everything which is "Video" class (or VIDEO/VGA). Your one mini module
> now claims every video object in the kernel with a couple of exceptions
> you can hand list.
> 
> vga_class.c now owns all the video devices. It can keep a global list
> and a sorted by vga router list as well as letting frame buffer drivers
> and other code add heads of a device lists.
> 
> Add register/unregister functions in the same format to allow DRI and FB
> (and any future layers) to find cards and you don't need to glue stuff
> together at all. You can load dri, you can load fb drivers, you can load
> both. You also require minimal kernel changes to the drivers.

You are focusing on the resource claiming problem. That is an easy
problem to solve, it's also not the one that is causing the hard
problems.

Hard problems:
1) Video cards have more than one head, fbdev can only set the mode on
one of them.
2) Video cards with more than one display buffer need memory
management, fbdev has none. OpenGL needs complex memory management.
3) Simultaneous users on two heads, fbdev cannot put the chip into 2D
mode while the other head is being used in 3D mode. Both heads have to
stay in 3D mode.
4) Conflicting use and programming of the 3D mode acceleration
registers between accelerated fbdev drivers and DRM
5) Support for multiple video cards - not addressed in fbdev.
6) Device driver multi-tasking. The concept that one device driver
should be suspended and another one allowed to take over the hardware
on a key stroke command. This completely violates normal OS rules of
one driver per device. If video can do it, I want to do it for the
disk and net subsystems too.
7) Building a bunch of cooperative interfaces between two groups of
developers that ignore each other.

I have to stick by a very basic rule of operating systems - one device
driver per device. The driver can have modules but these modules have
to make coordinated use of the hardware. Building a base layer for
fbdev and DRM that coordinates resource reservations does nothing to
address the above issues if everyone continues to do what they please
in the modules.

If you look at the recent changes to DRM you will notice that I am
building a base layer that will continue to work during the transition
period.  Code for accessing video ROMs is finished and should be in mm
soon. I'm in the middle of writing a VGA device driver that properly
does bridge chip routing. When it's finished we'll be able to reset
secondary cards. Once the reset program is finished the next step is
to alter DRM so that it can support take_over_console().

-- 
Jon Smirl
jonsmirl@gmail.com

Re: radeon-pre-2

[Dave Airlie]

>
> You are focusing on the resource claiming problem. That is an easy
> problem to solve, it's also not the one that is causing the hard
> problems.

I have to agree with Jon, nobody has addressed any of the issues he raises
except the one that is quite simple to solve, resource sharing is easy,

I think people are stuck in a graphics card having separate 2d/3d paths
and never the twain need meet, well that doesn't work, the 2d/3d split is
only in your mind, a graphics card is a single device, hence should only
one device driver, fbdev is not a complete driver, for all the reasons JOn
mentions (dualhead being a major one), the DRM is not a complete driver as
it ignores the basic VGA parts of the chip and relies on X or fb to set
them up..

> on a key stroke command. This completely violates normal OS rules of
> one driver per device. If video can do it, I want to do it for the
> disk and net subsystems too.

If the kernel developers can address this point I would be most
interested, in fact I don't want to hear any more about sharing lowlevel
VGA device drivers until someone addresses why it is acceptable to have
two separate driver driving the same hardware for video and not for
anything else.. (remembering graphics cards are not-multifunction cards -
like Christoph used as an example before - 2d/3d are not separate
functions...)...

Also I don't think what Jon has in mind is going to be truly possible and
IMHO an efficient flexible graphics card memory management system is
something worthy of multiple PhDs (maybe I'll go back to college), Ians
work is going to exist mainly in userspace using the DRM for paging things
and locking, I think the only way we can really do this is with a simple
fb memory manager in the kernel that the userspace one overrides and then
tells the fb drivers the new settings - and the fb drivers use those
settings until told otherwise..

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

Re: radeon-pre-2

[Alan Cox]

On Gwe, 2004-09-10 at 23:19, Dave Airlie wrote:
> If the kernel developers can address this point I would be most
> interested, in fact I don't want to hear any more about sharing lowlevel
> VGA device drivers until someone addresses why it is acceptable to have
> two separate driver driving the same hardware for video and not for
> anything else.. (remembering graphics cards are not-multifunction cards -
> like Christoph used as an example before - 2d/3d are not separate
> functions...)...

We've addressed this before. Zillions of drivers provide multiple
functions to multiple higher level subsystems. They don't all have to
be compiled together to make it work. 

2D and 3D _are_ to most intents and purposes different functions. They
are as different as IDE CD and IDE disk if not more so.

> something worthy of multiple PhDs (maybe I'll go back to college), Ians
> work is going to exist mainly in userspace using the DRM for paging things
> and locking, I think the only way we can really do this is with a simple
> fb memory manager in the kernel that the userspace one overrides and then
> tells the fb drivers the new settings - and the fb drivers use those
> settings until told otherwise..

The memory manager is a later problem. Yes you need minimal memory
management in kernel but you have to put the pieces together in a sane
way *first*. Having a vga class device is easy. It fixes up your
multiple pci device registration problem, it allows DRI/fbdev
co-existance, it fixes hotplugging. It's about using the kernel tools we
already have and implementing it the way the kernel wants to think. If
you fight the kernel you get a mess, if you move with it then it ends up
where you want it. Kind of like Aikido source management.

The basics I have provide (well they crash but they will provide) the
equivalent of pci_register_* for video and DRI modules. Notifiers for
use between the two and an ability to find one from the other.

Once you have that then you can begin plugging in crap like memory
managers for those cases you need it kernel side.

Alan

Re: radeon-pre-2

[Dave Airlie]

>
> 2D and 3D _are_ to most intents and purposes different functions. They
> are as different as IDE CD and IDE disk if not more so.

stop saying this, it isn't true and hasn't been for years, for the mach64
type cards I'd agree, for something even like the i810 this isn't
true, most cards have two paths (at least), an unaccelerated 2D path via
programmed registers, and an accelerated path via some DMA mechanism, this
isn't a 2d/3d split, you have to use the DMA mechanism for doing some 2d
acceleration and you have to use it for all 3d acceleration normally,

Lots of X DDX drivers use the accelerator for 2d stuff, some fbs use it
for accelerating scrolling, the DRM uses it, this is wrong wrong wrong
wrong...X/DRM at least lock each other out, but the fb just tramps in
wearing its size nines.. so in summary the 2D/3D split exists in peoples
minds (graphics cards designers excepted...)

> multiple pci device registration problem, it allows DRI/fbdev
> co-existance, it fixes hotplugging. It's about using the kernel tools we
> already have and implementing it the way the kernel wants to think. If
> you fight the kernel you get a mess, if you move with it then it ends up
> where you want it. Kind of like Aikido source management.

I'm with this, I want to see this stuff stay working on the way, I think
doing this might be a good step on the way, and it shouldn't break
anything too badly, I was going to start hacking something up myself but
the real world job just kicked me to get something done :-)

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

Re: radeon-pre-2

[Geert Uytterhoeven]

On Sat, 11 Sep 2004, Dave Airlie wrote:
> Lots of X DDX drivers use the accelerator for 2d stuff, some fbs use it
> for accelerating scrolling, the DRM uses it, this is wrong wrong wrong
> wrong...X/DRM at least lock each other out, but the fb just tramps in
> wearing its size nines.. so in summary the 2D/3D split exists in peoples
> minds (graphics cards designers excepted...)

Who tramps on who actually depends on your point of view... ;-)

First we had fbdev in the kernel (and some X played nice with it), then we also
got DRM...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: radeon-pre-2

[Keith Whitwell]

Dave Airlie wrote:
>>2D and 3D _are_ to most intents and purposes different functions. They
>>are as different as IDE CD and IDE disk if not more so.
> 
> 
> stop saying this, it isn't true and hasn't been for years, for the mach64
> type cards I'd agree, for something even like the i810 this isn't
> true, most cards have two paths (at least), an unaccelerated 2D path via
> programmed registers, and an accelerated path via some DMA mechanism, this
> isn't a 2d/3d split, you have to use the DMA mechanism for doing some 2d
> acceleration and you have to use it for all 3d acceleration normally,
> 
> Lots of X DDX drivers use the accelerator for 2d stuff, some fbs use it
> for accelerating scrolling, the DRM uses it, this is wrong wrong wrong
> wrong...X/DRM at least lock each other out, but the fb just tramps in
> wearing its size nines.. so in summary the 2D/3D split exists in peoples
> minds (graphics cards designers excepted...)

Yes, it is closest to the truth to believe there is one acceleration engine 
that does all drawing, and this should ideally have a single owner.

But that doesn't mean that mode-setting, etc, has to be moved into the DRM - 
for my money that stuff can stay where it is, provided there are some sensible 
interfaces put in place between the two components.

Keith

Re: radeon-pre-2

[Alan Cox]

On Sad, 2004-09-11 at 00:24, Dave Airlie wrote:
> stop saying this, it isn't true and hasn't been for years, for the mach64
> type cards I'd agree, for something even like the i810 this isn't

Its true. Its still true whether you demand people stop saying it or
not.

> true, most cards have two paths (at least), an unaccelerated 2D path via
> programmed registers, and an accelerated path via some DMA mechanism, this
> isn't a 2d/3d split, you have to use the DMA mechanism for doing some 2d
> acceleration and you have to use it for all 3d acceleration normally,

And a CD ROM is a round thing with removable optical media, while a hard
disk has a different command set and is magnetic. They are juat as
different. Its simple a matter of correct architecture.

> Lots of X DDX drivers use the accelerator for 2d stuff, some fbs use it
> for accelerating scrolling, the DRM uses it, this is wrong wrong wrong
> wrong...X/DRM at least lock each other out, but the fb just tramps in
> wearing its size nines.. so in summary the 2D/3D split exists in peoples
> minds (graphics cards designers excepted...)

Thats a different issue. IDE has to stop the CD and disk drivers from
stomping on each other over a shared bus. This is the problem of them
knowing each other exist and interacting. This is the point you need to
be able to find DRI from FB and vice versa. The point they need to know
about each other being loaded.

Multiple registrations on the same object is exactly what the class code
in the kernel is for. 

You end up with a VGA class driver that knows all the video devices. 
That has the usual match/install functions to allow the frame buffer to
attach, but can also have other sets for attaching different client
classes.

Re: radeon-pre-2

[Vladimir Dergachev]

Alan,
   I would like to disagree with you.

On Fri, 10 Sep 2004, Alan Cox wrote:

> On Gwe, 2004-09-10 at 23:19, Dave Airlie wrote:
>> If the kernel developers can address this point I would be most
>> interested, in fact I don't want to hear any more about sharing lowlevel
>> VGA device drivers until someone addresses why it is acceptable to have
>> two separate driver driving the same hardware for video and not for
>> anything else.. (remembering graphics cards are not-multifunction cards -
>> like Christoph used as an example before - 2d/3d are not separate
>> functions...)...
>
> We've addressed this before. Zillions of drivers provide multiple
> functions to multiple higher level subsystems. They don't all have to
> be compiled together to make it work.
>
> 2D and 3D _are_ to most intents and purposes different functions. They
> are as different as IDE CD and IDE disk if not more so.

Functions - yes, but they become such only at a higher level. 3d for 
example does not really exist in kernel in any form.

I would like to see unified fb (or the hardware-specific part of fb) and 
drm for one simple reason that I think you mentioned:

     One driver per device. I.e. one driver per *physical* device.

Lastly, one point that you appear to have missed: DRM does DMA transfers
(among everything else). FB sets video modes - i.e. messes with PLL.
The problem is that there are configurations where messing with PLL while 
a DMA trasfer is active will lock up PCI (or AGP) bus hard.

For example, a video decoder can be clocked off pixel clock for video pass 
through mode. If we trasfer video data to main RAM at the same time and
FB gets a command instructing it to change resolution there would be a 
hard lockup.

                           best

                             Vladimir Dergachev

Re: radeon-pre-2

[Keith Whitwell]

Vladimir Dergachev wrote:
> 
> Alan,
>   I would like to disagree with you.
> 
> On Fri, 10 Sep 2004, Alan Cox wrote:
> 
>> On Gwe, 2004-09-10 at 23:19, Dave Airlie wrote:
>>
>>> If the kernel developers can address this point I would be most
>>> interested, in fact I don't want to hear any more about sharing lowlevel
>>> VGA device drivers until someone addresses why it is acceptable to have
>>> two separate driver driving the same hardware for video and not for
>>> anything else.. (remembering graphics cards are not-multifunction 
>>> cards -
>>> like Christoph used as an example before - 2d/3d are not separate
>>> functions...)...
>>
>>
>> We've addressed this before. Zillions of drivers provide multiple
>> functions to multiple higher level subsystems. They don't all have to
>> be compiled together to make it work.
>>
>> 2D and 3D _are_ to most intents and purposes different functions. They
>> are as different as IDE CD and IDE disk if not more so.
> 
> 
> Functions - yes, but they become such only at a higher level. 3d for 
> example does not really exist in kernel in any form.
> 
> I would like to see unified fb (or the hardware-specific part of fb) and 
> drm for one simple reason that I think you mentioned:
> 
>     One driver per device. I.e. one driver per *physical* device.
> 
> Lastly, one point that you appear to have missed: DRM does DMA transfers
> (among everything else). FB sets video modes - i.e. messes with PLL.
> The problem is that there are configurations where messing with PLL 
> while a DMA trasfer is active will lock up PCI (or AGP) bus hard.
> 
> For example, a video decoder can be clocked off pixel clock for video 
> pass through mode. If we trasfer video data to main RAM at the same time 
> and
> FB gets a command instructing it to change resolution there would be a 
> hard lockup.

I can see this being the case, but why can't fb just using existing drm 
interfaces to achieve device quiescence before touching the PLL's?

Keith

Re: radeon-pre-2

[Mike Mestnik]

--- Keith Whitwell <keith@tungstengraphics.com> wrote:

> Vladimir Dergachev wrote:
> > 
> > Alan,
> >   I would like to disagree with you.
> > 
> > On Fri, 10 Sep 2004, Alan Cox wrote:
> > 
> >> On Gwe, 2004-09-10 at 23:19, Dave Airlie wrote:
> >>
> >>> If the kernel developers can address this point I would be most
> >>> interested, in fact I don't want to hear any more about sharing
> lowlevel
> >>> VGA device drivers until someone addresses why it is acceptable to
> have
> >>> two separate driver driving the same hardware for video and not for
> >>> anything else.. (remembering graphics cards are not-multifunction 
> >>> cards -
> >>> like Christoph used as an example before - 2d/3d are not separate
> >>> functions...)...
> >>
> >>
> >> We've addressed this before. Zillions of drivers provide multiple
> >> functions to multiple higher level subsystems. They don't all have to
> >> be compiled together to make it work.
> >>
> >> 2D and 3D _are_ to most intents and purposes different functions.
> They
> >> are as different as IDE CD and IDE disk if not more so.
> > 
> > 
> > Functions - yes, but they become such only at a higher level. 3d for 
> > example does not really exist in kernel in any form.
> > 
> > I would like to see unified fb (or the hardware-specific part of fb)
> and 
> > drm for one simple reason that I think you mentioned:
> > 
> >     One driver per device. I.e. one driver per *physical* device.
> > 
> > Lastly, one point that you appear to have missed: DRM does DMA
> transfers
> > (among everything else). FB sets video modes - i.e. messes with PLL.
> > The problem is that there are configurations where messing with PLL 
> > while a DMA trasfer is active will lock up PCI (or AGP) bus hard.
> > 
> > For example, a video decoder can be clocked off pixel clock for video 
> > pass through mode. If we trasfer video data to main RAM at the same
> time 
> > and
> > FB gets a command instructing it to change resolution there would be a
> 
> > hard lockup.
> 
> I can see this being the case, but why can't fb just using existing drm 
> interfaces to achieve device quiescence before touching the PLL's?
> 
I can see the problem here...

This happens with old(current) gatos and fglrx.  Where DRI sets up some
state in the card and then dosen't clear it after being unloaded.  This
leaves the card in an unknowen state that gatos or fglrx dosen't know any
thing about.

What will happen is that when the FB or DRM turns on a new feature the
other driver MAY need to be aware of the change.  This would imply that we
must now version as if there where an ABI.  The REAL problem is that the
ABI is all in hardware!  The bottom line is that nether of these drivers
SHOULD assume that the other won't change the way it uses the card, thus
forcing a bianary compatability issue.

> Keith
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM. 
> Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
> 



	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

Re: radeon-pre-2

[Vladimir Dergachev]

>>>> anything else.. (remembering graphics cards are not-multifunction cards -
>>>> like Christoph used as an example before - 2d/3d are not separate
>>>> functions...)...
>>> 
>>> 
>>> We've addressed this before. Zillions of drivers provide multiple
>>> functions to multiple higher level subsystems. They don't all have to
>>> be compiled together to make it work.
>>> 
>>> 2D and 3D _are_ to most intents and purposes different functions. They
>>> are as different as IDE CD and IDE disk if not more so.
>> 
>> 
>> Functions - yes, but they become such only at a higher level. 3d for 
>> example does not really exist in kernel in any form.
>> 
>> I would like to see unified fb (or the hardware-specific part of fb) and 
>> drm for one simple reason that I think you mentioned:
>> 
>>     One driver per device. I.e. one driver per *physical* device.
>> 
>> Lastly, one point that you appear to have missed: DRM does DMA transfers
>> (among everything else). FB sets video modes - i.e. messes with PLL.
>> The problem is that there are configurations where messing with PLL while a 
>> DMA trasfer is active will lock up PCI (or AGP) bus hard.
>> 
>> For example, a video decoder can be clocked off pixel clock for video pass 
>> through mode. If we trasfer video data to main RAM at the same time and
>> FB gets a command instructing it to change resolution there would be a hard 
>> lockup.
>
> I can see this being the case, but why can't fb just using existing drm 
> interfaces to achieve device quiescence before touching the PLL's?

Video decoder is not part of 3d engine. In fact if we are not transferring 
data via DMA into system RAM the video decoder will be running 
continuously and none of currently examined for quiescence flags would 
show it.

To do all this properly there should be a piece of code that knows all 
about currrent state of the card - which clocks are connected to what, 
which transfers are running and which parts of the engine are busy.

Btw, it would also be nice if that code received interrupts that can occur 
when user hotplugs monitors.

                              best

                                 Vladimir Dergachev

Re: radeon-pre-2

[Alan Cox]

On Sad, 2004-09-11 at 01:47, Vladimir Dergachev wrote:
>      One driver per device. I.e. one driver per *physical* device.

This is a religion the kernel doesn't follow. Its a pointless
religion

> Lastly, one point that you appear to have missed: DRM does DMA transfers
> (among everything else). FB sets video modes - i.e. messes with PLL.
> The problem is that there are configurations where messing with PLL while 
> a DMA trasfer is active will lock up PCI (or AGP) bus hard.

Yes its a co-ordination issue. If the IDE disk writes to the bus the
same moment as the IDE CD shit also happens.

> For example, a video decoder can be clocked off pixel clock for video pass 
> through mode. If we trasfer video data to main RAM at the same time and
> FB gets a command instructing it to change resolution there would be a 
> hard lockup.

Gosh, just like if the IDE disk driver changes the bus clocking during
an IDE CD transfer.

You need co-ordination not some horrible glue it all together and pray
hack. Thats always going to be true, and since you can do it without
glueing it all together you might get somewhere by keeping them apart,
otherwise I see no future. Most DRI users don't want FB, most FB users
don't care about DRI or want to control the DRI from the fb side.

Alan

Re: radeon-pre-2

[Dave Airlie]

>
> We've addressed this before. Zillions of drivers provide multiple
> functions to multiple higher level subsystems. They don't all have to
> be compiled together to make it work.
>
> 2D and 3D _are_ to most intents and purposes different functions. They
> are as different as IDE CD and IDE disk if not more so.

So the IDE-CD driver and IDE-disk drivers both program registers on the
IDE controller directly.. oh no the ide driver seems to do that.. this is
FUD, a graphics card is a device, singular one device, it requires one
device driver, the device driver should provide control over the device
and be the only one to program its registers.. it can provide services to
who ever wants services, be it a 2D console driver or a 3D client or a 4D
super-time-travelling application,

I can't write a user space IDE driver and still expect the kernel one to
be happy, I can't write a second IDE driver for a chipset for formatting
disks and expect the normal kernel driver to stay working with it, why do
people think graphics driver are meant to be different..

Alan, I agree with how you want to proceed with this, and keep things
stable, but anything short of a single card-specific driver looking after
the registers and DMA queueing and locking is going to have deficiencies
and the DRM has a better basis than the fb drivers,

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

Re: radeon-pre-2

[Michel Dänzer]

On Sat, 2004-09-11 at 01:50 +0100, Dave Airlie wrote:
> 
> Alan, I agree with how you want to proceed with this, and keep things
> stable, but anything short of a single card-specific driver looking after
> the registers and DMA queueing and locking is going to have deficiencies
> [...]

You're probably right, but it still doesn't follow that this driver must
include all the fbdev and DRM code as well. Both fbdev and the DRM could
use that driver, e.g., just like ide_cd and ide_disk use the IDE driver.


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer

Re: radeon-pre-2

[Dave Airlie]

>
> You're probably right, but it still doesn't follow that this driver must
> include all the fbdev and DRM code as well. Both fbdev and the DRM could
> use that driver, e.g., just like ide_cd and ide_disk use the IDE driver.
>

I think your wrong, look at drivers/video/aty/radeon* and tell me what in
there is capable of being abstracted from the hardware, every file access
lowlevel registers for something or other, be it mode setting or I2C, now
accessing lowlevels while the CP is running on a radeon is a one way
express to the land of the lockups... (think mode setting a second head,
while a 3d app is running on the first head...), the lowlevel driver can
provide a DRM and FB interface to fbcon and 3d stuff, but the lowlevel
driver needs all the code to do both...

The other thing I think some people are confusing is 2.4 fbdev and 2.6...
there is no console support in 2.6 fbdev drivers, it is all in the fbcon
stuff, so the fbdev drivers are only doing 2d mode setting and monitor
detection, some points I've considered are:

1. It doesn't matter where the code lives, fbdev/DRM need to start talking
about things
2. A generic interface between the two is probably going to be impossible,
graphics card interfaces aren't based on a standard like IDE (stop using
IDE for comparisons, it isn't the same IDE is a standard, and is designed
for things like cd drivers and hard drives, graphics card have no standard
interfaces, just because your pet card has a nice 2D/3D split it doesn't
mean that all do, if someone provides a better analogy feel free to use it
but can we all agree to drop the IDE comparisons now...)

I'm interested in seeing what Alan comes up with, even in a non-working
form .. I much prefer the evolution of these things than complete new
solutions... but I also think linking the fb and drm code together will
remove alot of the headaches and result in a more maintainable system
longterm, even if shortterm there are some ugly hacks..

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

Re: radeon-pre-2

[Michel Dänzer]

On Sat, 2004-09-11 at 06:19 +0100, Dave Airlie wrote:
> >
> > You're probably right, but it still doesn't follow that this driver must
> > include all the fbdev and DRM code as well. Both fbdev and the DRM could
> > use that driver, e.g., just like ide_cd and ide_disk use the IDE driver.
> 
> I think your wrong, look at drivers/video/aty/radeon* and tell me what in
> there is capable of being abstracted from the hardware, every file access
> lowlevel registers for something or other, be it mode setting or I2C, 

I'm not talking about abstracting much of anything, just moving
(arbitration of) actual hardware access to a common lowlevel driver. The
things you mentioned but snipped above, basically.

> now accessing lowlevels while the CP is running on a radeon is a one way
> express to the land of the lockups... 

No need to tell me that...

> (think mode setting a second head, while a 3d app is running on the first 
> head...), the lowlevel driver can provide a DRM and FB interface to fbcon 
> and 3d stuff, but the lowlevel driver needs all the code to do both...

I still haven't seen a complete logical chain leading to that
conclusion.

The lowlevel driver could provide all the necessary arbitration and
safety measures to prevent the two from stepping on each other's toes.


> The other thing I think some people are confusing is 2.4 fbdev and 2.6...

Again, not me.

> there is no console support in 2.6 fbdev drivers, it is all in the fbcon
> stuff, so the fbdev drivers are only doing 2d mode setting and monitor
> detection, [...]

Exactly. Why not leave it like that, and the DRM taking care of memory
management and rendering?


> 1. It doesn't matter where the code lives, fbdev/DRM need to start talking
> about things

Agreed.

> 2. A generic interface between the two is probably going to be impossible,

Probably true, I'm not talking about a generic interface (although some
parts might be generic, just like the DRM userspace interface).


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer

Re: radeon-pre-2

[Vladimir Dergachev]

>
> I still haven't seen a complete logical chain leading to that
> conclusion.
>
> The lowlevel driver could provide all the necessary arbitration and
> safety measures to prevent the two from stepping on each other's toes.
>

The thing is I know of no way to provide arbitration in such a way as to 
permit other code to access PLL registers directly.

One way or the other you will have to add "please set mode X" function to 
DRM and then the point of having a separate file for fb-con related 2d 
only is moot.

Additional argument for this is that DRM *NEEDS* to know about mode 
setting so that when it detects an engine lockup it is able to restore the 
card to a sane state without FB driver.

Right now there are two places where engine reset is handled: DRM driver
(where we reset the chip and leave it as is, with mode all screwed up) and
in Xserver (where we set the mode, but I have never seen this code path 
triggered).

Thus at the very least you would want to mandate the availability of mode 
setting part of FB when DRM is loaded - and they you can just as well link 
the relevant code together.

                          best

                              Vladimir Dergachev

Re: radeon-pre-2

[Alan Cox]

On Sad, 2004-09-11 at 08:11, Vladimir Dergachev wrote:
> The thing is I know of no way to provide arbitration in such a way as to 
> permit other code to access PLL registers directly.

This arises solely because the DRM and framebuffer drivers cannot find
each other and have no shared structures. The moment you have that it
becomes

	down(&dev->foo->pll_lock);

> Thus at the very least you would want to mandate the availability of mode 
> setting part of FB when DRM is loaded - and they you can just as well link 
> the relevant code together.

You are making a generic assumption for a single card specific problem
in a specific situation. That leads to bad decisions for embedded. It
does argue for mode setting and fb to be separate too.

(Remember for most embedded devices mode setting code is trivial)

Re: radeon-pre-2

[Vladimir Dergachev]

>
>> Thus at the very least you would want to mandate the availability of mode
>> setting part of FB when DRM is loaded - and they you can just as well link
>> the relevant code together.
>
> You are making a generic assumption for a single card specific problem
> in a specific situation. That leads to bad decisions for embedded. It
> does argue for mode setting and fb to be separate too.
>
> (Remember for most embedded devices mode setting code is trivial)
>

Alan,

     My point was that you would want to have DRM working on Radeon cards,
right ? And there are complexities of current Radeon hardware that one 
would have to deal with, no matter how simple it might be to do the same 
thing for embedded.

     Lastly, I am not saying you have to put all the code in the same file.
All I am saying we can mandate that all Radeon HW specific code is linked
in one module - and this would make things easier for developers.

     Alternatively, you can have a complicated scheme whereby you load FB 
and DRM drivers in any order. But DRM would want FB (or part of it) to be 
present anyway so it should be able to recover from engine lockup.

     I would agree that this can be coded as well - but why bother ? Or is 
it done and working already ?

                         best

                           Vladimir Dergachev

Re: radeon-pre-2

[Alan Cox]

On Sad, 2004-09-11 at 16:53, Vladimir Dergachev wrote:
>      Lastly, I am not saying you have to put all the code in the same file.
> All I am saying we can mandate that all Radeon HW specific code is linked
> in one module - and this would make things easier for developers.

And if I want dri but not frame buffer, or vice versa, as the majority
of current users do 

>      I would agree that this can be coded as well - but why bother ? Or is 
> it done and working already ?

Splitting the modules up is the easy bit. The API is the hard bit so you
might as well formalize it. It also gives the users the ability to not
load huge radeon modules.

Re: radeon-pre-2

[Vladimir Dergachev]

On Sat, 11 Sep 2004, Alan Cox wrote:

> On Sad, 2004-09-11 at 16:53, Vladimir Dergachev wrote:
>>      Lastly, I am not saying you have to put all the code in the same file.
>> All I am saying we can mandate that all Radeon HW specific code is linked
>> in one module - and this would make things easier for developers.
>
> And if I want dri but not frame buffer, or vice versa, as the majority
> of current users do

You are missing my point - I do not say we need to *activate* the 
framebuffer, just link the mode setting (and other hardware dependent 
code) into DRM driver.

This is kinda like vesafb driver is doing now - if I don't pass vga=XX 
parameter on the command line it does not touch the graphics card.

Thus, even if framebuffer support is not compiled into the kernel the DRM 
driver is able to reinitialize the card into a sane state.

>
>>      I would agree that this can be coded as well - but why bother ? Or is
>> it done and working already ?
>
> Splitting the modules up is the easy bit. The API is the hard bit so you
> might as well formalize it. It also gives the users the ability to not
> load huge radeon modules.
>

This is a good point - if we don't need DMA or 3d acceleration we can 
reduce memory footprint. This would seem that current DRM driver would 
need to be dependent on whatever driver contains the mode setting code.

What do you think ?

                       best

                         Vladimir Dergachev

Re: radeon-pre-2

[Alan Cox]

On Sad, 2004-09-11 at 18:10, Vladimir Dergachev wrote:
> This is a good point - if we don't need DMA or 3d acceleration we can 
> reduce memory footprint. This would seem that current DRM driver would 
> need to be dependent on whatever driver contains the mode setting code.
> 
> What do you think ?

Jon wants to get mode setting into a seperate piece of functionality -
preferably in user space for many cards. I'd dearly love to see hotplug
handing all but some "emergency" pre-computed mode settings.

Alan

Re: radeon-pre-2

[Vladimir Dergachev]

On Sat, 11 Sep 2004, Alan Cox wrote:

> On Sad, 2004-09-11 at 18:10, Vladimir Dergachev wrote:
>> This is a good point - if we don't need DMA or 3d acceleration we can
>> reduce memory footprint. This would seem that current DRM driver would
>> need to be dependent on whatever driver contains the mode setting code.
>>
>> What do you think ?
>
> Jon wants to get mode setting into a seperate piece of functionality -
> preferably in user space for many cards. I'd dearly love to see hotplug
> handing all but some "emergency" pre-computed mode settings.

I think there is a misunderstanding.

My view was that PLL setting (and setting of a fixed mode) would be done 
in DRM driver. This way it would be able to restore previous settings 
after a lockup or respond to FB request to change modes.

However the decision of which mode to set, as well as where the 
framebuffer is located is done in user-space. (So that subtleties of
layout of offscreen memory are not in the kernel).

Jon - did I understand you correctly ?

                             best

                               Vladimir Dergachev

Re: radeon-pre-2

[Jon Smirl]

On Sat, 11 Sep 2004 13:49:34 -0400 (EDT), Vladimir Dergachev
<volodya@mindspring.com> wrote:
> On Sat, 11 Sep 2004, Alan Cox wrote:
> 
> > On Sad, 2004-09-11 at 18:10, Vladimir Dergachev wrote:
> >> This is a good point - if we don't need DMA or 3d acceleration we can
> >> reduce memory footprint. This would seem that current DRM driver would
> >> need to be dependent on whatever driver contains the mode setting code.
> >>
> >> What do you think ?
> >
> > Jon wants to get mode setting into a seperate piece of functionality -
> > preferably in user space for many cards. I'd dearly love to see hotplug
> > handing all but some "emergency" pre-computed mode settings.
> 
> I think there is a misunderstanding.
> 
> My view was that PLL setting (and setting of a fixed mode) would be done
> in DRM driver. This way it would be able to restore previous settings
> after a lockup or respond to FB request to change modes.
> 
> However the decision of which mode to set, as well as where the
> framebuffer is located is done in user-space. (So that subtleties of
> layout of offscreen memory are not in the kernel).
> 
> Jon - did I understand you correctly ?

All register writes would occur in the driver. There is nothing
stopping the code that computes those register values from running in
user space.

A example mode setting IO would take:
  display buffer offset
  width, height, stride, etc - for fbcon to use
  register values to set the mode

Mode setting needs to be serialized. It may be better to do the
serialization before the hotplug event, in that case the mode setting
IOCTL would be implicitly serialized and not need a separate lock.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: radeon-pre-2

[Vladimir Dergachev]

On Sat, 11 Sep 2004, Jon Smirl wrote:
>>
>> My view was that PLL setting (and setting of a fixed mode) would be done
>> in DRM driver. This way it would be able to restore previous settings
>> after a lockup or respond to FB request to change modes.
>>
>> However the decision of which mode to set, as well as where the
>> framebuffer is located is done in user-space. (So that subtleties of
>> layout of offscreen memory are not in the kernel).
>>
>> Jon - did I understand you correctly ?
>
> All register writes would occur in the driver. There is nothing
> stopping the code that computes those register values from running in
> user space.
>
> A example mode setting IO would take:
>  display buffer offset
>  width, height, stride, etc - for fbcon to use
>  register values to set the mode
>
> Mode setting needs to be serialized. It may be better to do the
> serialization before the hotplug event, in that case the mode setting
> IOCTL would be implicitly serialized and not need a separate lock.

Just to clear up things - do you plan to retain the knowledge of last mode 
set in the DRM driver ?

                            best

                              Vladimir Dergachev



>
> -- 
> Jon Smirl
> jonsmirl@gmail.com
>

Re: radeon-pre-2

[Jon Smirl]

On Sat, 11 Sep 2004 14:05:54 -0400 (EDT), Vladimir Dergachev
<volodya@mindspring.com> wrote:
> > All register writes would occur in the driver. There is nothing
> > stopping the code that computes those register values from running in
> > user space.
> >
> > A example mode setting IO would take:
> >  display buffer offset
> >  width, height, stride, etc - for fbcon to use
> >  register values to set the mode
> >
> > Mode setting needs to be serialized. It may be better to do the
> > serialization before the hotplug event, in that case the mode setting
> > IOCTL would be implicitly serialized and not need a separate lock.
> 
> Just to clear up things - do you plan to retain the knowledge of last mode
> set in the DRM driver ?

Yes, you have to do that for fbcon and suspend/restore to work.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: radeon-pre-2

[Mike Mestnik]

--- Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> On Sad, 2004-09-11 at 16:53, Vladimir Dergachev wrote:
> >      Lastly, I am not saying you have to put all the code in the same
> file.
> > All I am saying we can mandate that all Radeon HW specific code is
> linked
> > in one module - and this would make things easier for developers.
> 
> And if I want dri but not frame buffer, or vice versa, as the majority
> of current users do 
> 
Hopefully any change to the kernel will allow building FB without DRM. 
This is a trivial seperation of code, that I might add has allready been
done, a good point that we should keep it this way.  Yes, there will be
some new memory mngmt code, posibly optonal as well, that is needed for
multi-headed setups.

> >      I would agree that this can be coded as well - but why bother ?
> Or is 
> > it done and working already ?
> 
> Splitting the modules up is the easy bit. The API is the hard bit so you
> might as well formalize it. It also gives the users the ability to not
> load huge radeon modules.
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM. 
> Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
> 



		
_______________________________
Do you Yahoo!?
Express yourself with Y! Messenger! Free. Download now. 
http://messenger.yahoo.com

Re: radeon-pre-2

[Antonino A. Daplas]

On Saturday 11 September 2004 13:19, Dave Airlie wrote:
> The other thing I think some people are confusing is 2.4 fbdev and 2.6...
> there is no console support in 2.6 fbdev drivers, it is all in the fbcon
> stuff, so the fbdev drivers are only doing 2d mode setting and monitor
> detection, some points I've considered are:

Correct.  fbdev is almost completely separate from fbcon. And you can
actually rip out fbdev and place it anywhere you want. As long as fbcon has
access to a pointer to framebuffer memory, and the characteristics of the
display such as depth, pitch, etc, then the framebuffer console will work.
Throw in a few functions, such as for buffer flipping, and fbcon will be happy. 

Hardware acceleration is entirely optional, and most drivers except for a few
(such as vga16fb or amiga) can use the cfb_* drawing functions.

There's also a recent change in the latest bk tree that changes the
intialization order of the framebuffer system. Previously, fbcon triggers
fbmem, then fbmem triggers each individual drivers.  This method requires
that a working fbdev is present, otherwise fbcon will fail (although you can
do a con2fbmap later, or modprobe a driver). With the change, the
order is reversed, driver->fbmem->fbcon.  This change is probably
significant because fbcon can wait until an active framebuffer activates.

In theory, one can have a process (kernel or userland) change the video
mode, then provide the in-kernel driver with the necessary information
about the layout of the framebuffer.  When this in-kernel driver gets the
necessary information, it can trigger fbcon. This in-kernel driver need not
know anything about the hardware (unless 2D acceleration is needed).

Tony

Re: radeon-pre-2

[Alan Cox]

On Sad, 2004-09-11 at 10:20, Antonino A. Daplas wrote:
> In theory, one can have a process (kernel or userland) change the video
> mode, then provide the in-kernel driver with the necessary information
> about the layout of the framebuffer.  When this in-kernel driver gets the
> necessary information, it can trigger fbcon. This in-kernel driver need not
> know anything about the hardware (unless 2D acceleration is needed).

Thats great because one of the things X wants to tell DRI to tell the
kernel eventually is "by the way the area visible is laid out like this
shoudl you want to panic on it".

(Jon wants to move the mode setting out of X eventually and that follows
the same line of requirement nicely).

Re: radeon-pre-2

[Jon Smirl]

On Sat, 11 Sep 2004 17:20:38 +0800, Antonino A. Daplas
<adaplas@hotpop.com> wrote:
> On Saturday 11 September 2004 13:19, Dave Airlie wrote:
> > The other thing I think some people are confusing is 2.4 fbdev and 2.6...
> > there is no console support in 2.6 fbdev drivers, it is all in the fbcon
> > stuff, so the fbdev drivers are only doing 2d mode setting and monitor
> > detection, some points I've considered are:
> 
> Correct.  fbdev is almost completely separate from fbcon. And you can
> actually rip out fbdev and place it anywhere you want. As long as fbcon has
> access to a pointer to framebuffer memory, and the characteristics of the
> display such as depth, pitch, etc, then the framebuffer console will work.
> Throw in a few functions, such as for buffer flipping, and fbcon will be happy.

The intention of the DRM work is to reuse fbcon without change if
possible or minimize the changes needed.

> Hardware acceleration is entirely optional, and most drivers except for a few
> (such as vga16fb or amiga) can use the cfb_* drawing functions.

No code has been written for this, but part of the plan is to split
the console function into two pieces: boot and user. The boot console
would be non-accelerated and use fbcon for drawing. It's goal is to be
as reliable as possible and to work in all environments including
interrupt time. Booting in single user mode would use boot console. So
would OOPs and initial boot.

Another major console use is for normal users doing things like
editing and command line stuff. This console would be implemented in
user space. User space console can call into DRM and achieve full
acceleration. This would also allow consoles in Asian and Indic
languages.

> There's also a recent change in the latest bk tree that changes the
> intialization order of the framebuffer system. Previously, fbcon triggers
> fbmem, then fbmem triggers each individual drivers.  This method requires
> that a working fbdev is present, otherwise fbcon will fail (although you can
> do a con2fbmap later, or modprobe a driver). With the change, the
> order is reversed, driver->fbmem->fbcon.  This change is probably
> significant because fbcon can wait until an active framebuffer activates.
> 
> In theory, one can have a process (kernel or userland) change the video
> mode, then provide the in-kernel driver with the necessary information
> about the layout of the framebuffer.  When this in-kernel driver gets the
> necessary information, it can trigger fbcon. This in-kernel driver need not
> know anything about the hardware (unless 2D acceleration is needed).

The plan for mode setting is to move as much as possible of it to user
space via a hotplug event. The driver would then be informed of the
information it needs like framebuffer location, dimensions, mode
register values, etc.

> 
> Tony
> 
> 



-- 
Jon Smirl
jonsmirl@gmail.com

Re: radeon-pre-2

[Alan Cox]

On Sad, 2004-09-11 at 06:19, Dave Airlie wrote:
> 1. It doesn't matter where the code lives, fbdev/DRM need to start talking
> about things

It matters immensely what the divison is because people talking doesn't
scale ..

> I'm interested in seeing what Alan comes up with, even in a non-working
> form .. I much prefer the evolution of these things than complete new
> solutions... but I also think linking the fb and drm code together will
> remove alot of the headaches and result in a more maintainable system
> longterm, even if shortterm there are some ugly hacks..

What I'm trying to end up with is this

	drv.type = TYPE_FB0;	/* Head 0 */
	/* Rest much like PCI */
	vga_register_driver(&drv)

	drv.type = TYPE_DRI;
	vga_register_driver(&drv)

all working like the PCI API, so you get add/remove notifications, you
also don't need to modify the video and DRI drivers much. Unlike the
pci_register it allows multiple claims for each device (one memory
manager, one dri driver, up to four "heads" for now - multihead needs
more pondering perhaps)

Each of these gets notified when the others are added/removed and can
veto such an add or remove. They can also provide whatever methods it
turns out are appropriate to each other for co-ordination.

For example I can see the radeon DRM driver providing

	->queue_commands()
	->quiesce()

to the 2D driver. And the 2D driver providing

	->define_fb_layout()  for DRI to provide to X

That way it is only these calls between drivers you and the fb authors
have to argue about the functionality and interfaces between. (eg who
saves registers, which registers)

Alan

Re: radeon-pre-2

[Jon Smirl]

On Sat, 11 Sep 2004 15:33:43 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> For example I can see the radeon DRM driver providing
> 
>         ->queue_commands()
>         ->quiesce()
> 
> to the 2D driver. And the 2D driver providing
> 
>         ->define_fb_layout()  for DRI to provide to X
> 
> That way it is only these calls between drivers you and the fb authors
> have to argue about the functionality and interfaces between. (eg who
> saves registers, which registers)
> 

Take a system with two simultaneous users on two heads of a dual head
card. The kernel will be process swapping between these two users as
needed.

User 1 is playing a 3D game. 
User 2 is editing with emacs on fbdev

User 1's game queues up 20ms of 3D drawing commands.
Process swap to user 2.  ->quiesce() is going to take 20ms. 
User 2's timeslice expires and we go back to user 1.
User 1 queues up another 20ms.

User 2's editor is never going to function.

The correct solution is to leave the chip in 3D mode and merge DMA
command streams. User 2 wouldn't have problems if it's console driver
queued 3D commands instead of stopping the 3D coprocessor, changing
the chip mode, executing a host based 2D command, and then restarting
the coprocessor.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: radeon-pre-2

[Alan Cox]

On Sad, 2004-09-11 at 17:46, Jon Smirl wrote:
> User 1's game queues up 20ms of 3D drawing commands.
> Process swap to user 2.  ->quiesce() is going to take 20ms. 
> User 2's timeslice expires and we go back to user 1.
> User 1 queues up another 20ms.
> 
> User 2's editor is never going to function.

If you implement it wrongly sure. If you implemented it right then
this occurs.

User 1 queues 20 ms of 3D commands
User 1 is pre-empted
User 2 wants the 2D engine
User 2 beings wait for 2D
User 2 sleeps
User 1 wakes
User 1 beings wait for 3D but discovers a claim is in progress
User 1 sleeps
User 2 wakes, runs commands

If you have DRI loaded then as you rightly say the obvious desired
outcome is that the fb engine either turns acceleration off or switches
to using the DRI layer. 

But this is a pretty obscure case, and one we can't even begin to
support yet anyway.

Re: radeon-pre-2

[Jon Smirl]

On Sat, 11 Sep 2004 17:21:22 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Sad, 2004-09-11 at 17:46, Jon Smirl wrote:
> > User 1's game queues up 20ms of 3D drawing commands.
> > Process swap to user 2.  ->quiesce() is going to take 20ms.
> > User 2's timeslice expires and we go back to user 1.
> > User 1 queues up another 20ms.
> >
> > User 2's editor is never going to function.
> 
> If you implement it wrongly sure. If you implemented it right then
> this occurs.
> 
> User 1 queues 20 ms of 3D commands
> User 1 is pre-empted
> User 2 wants the 2D engine
> User 2 beings wait for 2D
> User 2 sleeps
> User 1 wakes
> User 1 beings wait for 3D but discovers a claim is in progress
> User 1 sleeps
> User 2 wakes, runs commands

This model destroys the parallel processing between the main CPU and the GPU.

> 
> If you have DRI loaded then as you rightly say the obvious desired
> outcome is that the fb engine either turns acceleration off or switches
> to using the DRI layer.
> 
> But this is a pretty obscure case, and one we can't even begin to
> support yet anyway.
> 
> 

-- 
Jon Smirl
jonsmirl@gmail.com

Re: radeon-pre-2

[Keith Whitwell]

Jon Smirl wrote:
> On Sat, 11 Sep 2004 17:21:22 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> 
>>On Sad, 2004-09-11 at 17:46, Jon Smirl wrote:
>>
>>>User 1's game queues up 20ms of 3D drawing commands.
>>>Process swap to user 2.  ->quiesce() is going to take 20ms.
>>>User 2's timeslice expires and we go back to user 1.
>>>User 1 queues up another 20ms.
>>>
>>>User 2's editor is never going to function.
>>
>>If you implement it wrongly sure. If you implemented it right then
>>this occurs.
>>
>>User 1 queues 20 ms of 3D commands
>>User 1 is pre-empted
>>User 2 wants the 2D engine
>>User 2 beings wait for 2D
>>User 2 sleeps
>>User 1 wakes
>>User 1 beings wait for 3D but discovers a claim is in progress
>>User 1 sleeps
>>User 2 wakes, runs commands
> 
> 
> This model destroys the parallel processing between the main CPU and the GPU.

And this is the reason that cards tend to do 2d and 3d through the same 
command queue, and often the same hardware at the backend - there's no need on 
such hardware to quiesce between acclerated 2d and 3d commands.

Of course, if either user ends up wanting to touch the framebuffer directly, 
they will have to flush the queue & wait for quiescence.  There's nothing 
particularly 2D or 3D about this - they both have fallbacks, and they're both 
faster if fallbacks can be avoided.

Keith (who has lost track of who's arguing about what or why)

Re: radeon-pre-2

[Hamie]

Alan Cox wrote:

>On Sad, 2004-09-11 at 17:46, Jon Smirl wrote:
>  
>
>>User 1's game queues up 20ms of 3D drawing commands.
>>Process swap to user 2.  ->quiesce() is going to take 20ms. 
>>User 2's timeslice expires and we go back to user 1.
>>User 1 queues up another 20ms.
>>
>>User 2's editor is never going to function.
>>    
>>
>
>If you implement it wrongly sure. If you implemented it right then
>this occurs.
>
>User 1 queues 20 ms of 3D commands
>User 1 is pre-empted
>User 2 wants the 2D engine
>User 2 beings wait for 2D
>User 2 sleeps
>User 1 wakes
>User 1 beings wait for 3D but discovers a claim is in progress
>User 1 sleeps
>User 2 wakes, runs commands
>
>If you have DRI loaded then as you rightly say the obvious desired
>outcome is that the fb engine either turns acceleration off or switches
>to using the DRI layer. 
>
>But this is a pretty obscure case, and one we can't even begin to
>support yet anyway.
>
>  
>

What about if you want to use fb when in text mode (Because you get 
200x75 on a 1600x1200 screen) AND run DRI because the rest of the time 
you want to run fast 3D. Plus you want to be able to CTRL-ALT-F1/F2/F7 
back & forth between X & fb... (i.e. how I currently use it but with 
unaccelerated x.org radeon drivers, becaus ethe 3D ones WON'T play nicely).

Currently this fails to work... Presumably because the fb & DRI code 
(fglrx here BTW) don't talk to each other & so the display gets garbled 
if you're lucky... Lockup if you're not.

Although I didn't like (Understand?) Jon's suggestion at first, I have 
to admit, that his scheme would let this work... because the low level 
driver would know what mode was in place, and you'd call the low-level 
driver to change between 3D & fb mode... 

Although Linus' suggestion works for memory allocation... I don't 
believe it addresses two competing drivers wanting to play with the same 
screen... Even when it's serialised like that. And unfortunately 
although Alan's probably works for DRI & fb on separate heads, how does 
it guarantee that the chipset is all setup the same way for each process 
on different heads... (When they have to share some of the hardware). Or 
is that necessary?

Re: radeon-pre-2

[Alan Cox]

> What about if you want to use fb when in text mode (Because you get 
> 200x75 on a 1600x1200 screen) AND run DRI because the rest of the time 
> you want to run fast 3D. Plus you want to be able to CTRL-ALT-F1/F2/F7 
> back & forth between X & fb... (i.e. how I currently use it but with 
> unaccelerated x.org radeon drivers, becaus ethe 3D ones WON'T play nicely).

Thats actually the easy case. We don't care if it takes another 30th of
a second to flip console. The hard one Jon was trying to point out is
a dual head card. Head 0 has someone running bzflag, head 1 has someone
editing an open office document. You have one accelerator set for both
heads. At that point you do care about the switch over, but the drivers
can co-operate for it. So it would always work, but it would work better
with friendly drivers when there is a need to do so.

> Currently this fails to work... Presumably because the fb & DRI code 
> (fglrx here BTW) don't talk to each other & so the display gets garbled 
> if you're lucky... Lockup if you're not.

fglrx stomps blindly on everything including your AGP. Not much we can
do about it.

> although Alan's probably works for DRI & fb on separate heads, how does 
> it guarantee that the chipset is all setup the same way for each process 
> on different heads... (When they have to share some of the hardware). Or 
> is that necessary?

You assume someone else crapped on the hardware. That is how DRI works
for example. You have multiple rendering clients each of which when it
takes the lock finds out if it was the last user (thats one thing Linus
sketch lacked but is easy to add).

My code ends up looking like

	lock
	if(someone_else_used_it)
		restore_my_state()
	blah 
	unlock

Re: radeon-pre-2

[Geert Uytterhoeven]

On Sun, 12 Sep 2004, Alan Cox wrote:
> > What about if you want to use fb when in text mode (Because you get
> > 200x75 on a 1600x1200 screen) AND run DRI because the rest of the time
> > you want to run fast 3D. Plus you want to be able to CTRL-ALT-F1/F2/F7
> > back & forth between X & fb... (i.e. how I currently use it but with
> > unaccelerated x.org radeon drivers, becaus ethe 3D ones WON'T play nicely).
>
> Thats actually the easy case. We don't care if it takes another 30th of
> a second to flip console. The hard one Jon was trying to point out is

BTW, it's not always O(30th of seconds): if we have to reprogram the PLLs
(someone else may have changed the hardware state, let's play safe), it can
take much longer.

People already complained about long switching times between different VCs
using the same video mode, due to reprogramming the PLL from scratch, just to
be safe no one else did something to the hardware state we don't know about.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: radeon-pre-2

[Hamie]

Alan Cox wrote:

>>What about if you want to use fb when in text mode (Because you get 
>>200x75 on a 1600x1200 screen) AND run DRI because the rest of the time 
>>you want to run fast 3D. Plus you want to be able to CTRL-ALT-F1/F2/F7 
>>back & forth between X & fb... (i.e. how I currently use it but with 
>>unaccelerated x.org radeon drivers, becaus ethe 3D ones WON'T play nicely).
>>    
>>
>
>Thats actually the easy case. We don't care if it takes another 30th of
>a second to flip console. The hard one Jon was trying to point out is
>a dual head card. Head 0 has someone running bzflag, head 1 has someone
>editing an open office document. You have one accelerator set for both
>heads. At that point you do care about the switch over, but the drivers
>can co-operate for it. So it would always work, but it would work better
>with friendly drivers when there is a need to do so.
>
>  
>

I see you point of view. And agree with the sentiment about another 
1/30th of a scond to switch modes... Heck, I'd put up with 500ms... 
(1000ms looks like too much of a lag & makes me impatient when I want to 
switch. Especially if there's no feedback).

But this relies on drivers co-operating with each other. Which is a real 
pain, and we'd still be stuck with finger pointing whenever two drivers 
didn't manage to co-operate successfully... And you'd need co-operation 
& understanding to solve the problem... If one of the sides is 
proprietary closed source drivers then the co-operation may not be there.

At the end of the day, if it works & works well, it doesn't appear to 
matter too much whether it's a single driver, or multiple drivers 
accessing the same hardware. I have no axe to grind either way, and hope 
I'm keeping an open mind.

But from a supportability point of view I think Jon's single driver 
wins. Even if it's a closed source driver, as long as the entry points & 
callbacks are documented well & can be tested, it's easier to find where 
the problem lies (i.e. inside or outside the one driver). Having 
competing ones may well prove to be near impossible to get to work 
together (Risking the wrath and going back to an example like the ide cd 
& disk one, it would be like having a proprietary driver talking to your 
SCSI DVD drive, manipulating the chipset on your SCSI card & another one 
doing the same thing for you HD... It just doesn't happen that way 
now... We have a SCSI card driver that looks after the card & separate 
drivers that use the low-level one to just push SCSI commands to each. - 
Bad analogy?

>>Currently this fails to work... Presumably because the fb & DRI code 
>>(fglrx here BTW) don't talk to each other & so the display gets garbled 
>>if you're lucky... Lockup if you're not.
>>    
>>
>
>fglrx stomps blindly on everything including your AGP. Not much we can
>do about it.
>
>  
>

Yeah. Would fglrx  be more stable if you used the external AGP rather 
than fglrx's built in AGP driver?


>>although Alan's probably works for DRI & fb on separate heads, how does 
>>it guarantee that the chipset is all setup the same way for each process 
>>on different heads... (When they have to share some of the hardware). Or 
>>is that necessary?
>>    
>>
>
>You assume someone else crapped on the hardware. That is how DRI works
>for example. You have multiple rendering clients each of which when it
>takes the lock finds out if it was the last user (thats one thing Linus
>sketch lacked but is easy to add).
>
>My code ends up looking like
>
>	lock
>	if(someone_else_used_it)
>		restore_my_state()
>	blah 
>	unlock
>
>  
>
Ah... Now I understand what you've been talking about as well... The 
only caveat is whether you can always restore your own state from the 
state the other person put it into. Do any cards exist where you could 
perhaps still lock the card up because you didn't know the current state 
of the card?

Would it be better to do the state_changed flag as a callback to each 
registered driver?

Re: radeon-pre-2

[Alan Cox]

On Sul, 2004-09-12 at 12:36, Hamie wrote:
> But this relies on drivers co-operating with each other. 

Only minimally, and providing the co-operation is easy the rest comes
out fine. We don't often get ide-disk and ide-cd people arguing over
whose fault something is

> Yeah. Would fglrx  be more stable if you used the external AGP rather 
> than fglrx's built in AGP driver?

Who knows, ATI have the source, ask them 8)

> >My code ends up looking like
> >
> >	lock
> >	if(someone_else_used_it)
> >		restore_my_state()
> >	blah 
> >	unlock
>
> Ah... Now I understand what you've been talking about as well... The 
> only caveat is whether you can always restore your own state from the 
> state the other person put it into. Do any cards exist where you could 
> perhaps still lock the card up because you didn't know the current state 
> of the card?

There are lots of cards where you might need more than the basic
example. You need to know your own state clearly, you often can't
retrieve that from the card. You may also need to know the previous user
has left it in a sane state. That might lead you to say

	lock
		oldowner->release()
	blah
	unlock (&release_func)

so that the previous caller is told it is losing the lock and can
for example wait for its commands to complete.

Re: radeon-pre-2

[Alan Cox]

On Sad, 2004-09-11 at 17:46, Jon Smirl wrote:
> User 1's game queues up 20ms of 3D drawing commands.
> Process swap to user 2.  ->quiesce() is going to take 20ms. 
> User 2's timeslice expires and we go back to user 1.
> User 1 queues up another 20ms.
> 
> User 2's editor is never going to function.

If you implement it wrongly sure. If you implemented it right then
this occurs.

User 1 queues 20 ms of 3D commands
User 1 is pre-empted
User 2 wants the 2D engine
User 2 beings wait for 2D
User 2 sleeps
User 1 wakes
User 1 beings wait for 3D but discovers a claim is in progress
User 1 sleeps
User 2 wakes, runs commands

If you have DRI loaded then as you rightly say the obvious desired
outcome is that the fb engine either turns acceleration off or switches
to using the DRI layer. 

But this is a pretty obscure case, and one we can't even begin to
support yet anyway.

Re: radeon-pre-2

[Alan Cox]

On Sad, 2004-09-11 at 01:50, Dave Airlie wrote:
> So the IDE-CD driver and IDE-disk drivers both program registers on the
> IDE controller directly.. oh no the ide driver seems to do that.. this is
> FUD,

Its a shame the DRI people having nothing better to do than tell folks
to shut up or mutter FUD about things they don't grasp. You've almost
got the point by now at least.

The IDE CD and IDE disk drivers do both write to registers on the IDE
controller directly - often the same registers. The reason it doesn't
end up in a nasty heap is because the core IDE code does co-ordination. 
Two drivers, independant drivers, an access protocol an the ability for
some entity to co-ordinate them and lo - it all works.

>  a graphics card is a device, singular one device, it requires one
> device driver,

That appears to be the pet religion but repeating bullshit doesn't make
it true.

> I can't write a user space IDE driver and still expect the kernel one to
> be happy, I can't write a second IDE driver for a chipset for formatting
> disks and expect the normal kernel driver to stay working with it, why do
> people think graphics driver are meant to be different..

Because they are not different, and you can write such a formatting
driver providing it follows the IDE access protocols in the core code.
You won't have to modify existing IDE drivers either. It works because
the co-ordination layer is there.

> Alan, I agree with how you want to proceed with this, and keep things
> stable, but anything short of a single card-specific driver looking after
> the registers and DMA queueing and locking is going to have deficiencies
> and the DRM has a better basis than the fb drivers,

"I want to own it, mine mine". Pathetic really isn't it. The FB writers
I've no doubt think they should own it and their code is better too.
They also support a lot more hardware than you do of course, and on
platforms that DRI doesn't support.

What is actually so hard about driver code that instead looks like


my_fb_attach_notify(struct vga_dev *dev, int type)
{
	if(type == TYPE_DRI)
	{
		me->fb_ops = &dri_ops;
		my_fb_dri_init(dev);
		return 0;
	}
	if(type == TYPE_OVERLAY && dev->rev < 0xC4) /* Errata */
		return -EINVAL; /* Refuse overlays in fb mode */
}

or

	down(&dev->lock);
	vga_quiesce_all_drivers(dev);
	do nasty non parallel stuff
	up(&dev->lock);

This is essentially what the IDE layer does, although its closer to

	queue_this_function_and_args_to_list(dev, callback, args);
	if(!doing_stuff);
		begin_queue_run(dev);

Either model works

Re: radeon-pre-2

[Dave Airlie]

>
> > Alan, I agree with how you want to proceed with this, and keep things
> > stable, but anything short of a single card-specific driver looking after
> > the registers and DMA queueing and locking is going to have deficiencies
> > and the DRM has a better basis than the fb drivers,
>
> "I want to own it, mine mine". Pathetic really isn't it. The FB writers
> I've no doubt think they should own it and their code is better too.
> They also support a lot more hardware than you do of course, and on
> platforms that DRI doesn't support.

I actually don't give a rats arse who owns it, this isn't a them and us
despite these rather obvious attempts to make it so.. this is a who writes
the code and does the design and at the moment I'm seeing you and Jon with
differing view points, and I'm trying to get both sides to figure out what
needs to be done, I'll gladly review any changes for the drm but saying
it's a DRI vs kernel is a very small minded view that I don't really care
for..

The worst things that will happen for all concerened is this:
Jon does all this work on a merged solution outside the kernel, and it
works well, and the X team decide to do a decent X on mesa-solo on Jons
super-DRM, now the super-DRM gets pushed via the X tree and distributions
start relasing kernels with it merged into it and it never goes into the
main tree... it won't matter, RH/SuSE/whomever will want to pick up the
new features for the *enhanced user experience* and people will give out
about not being able to use Linus's kernels and it'll be a bit of a big
mess sort of like when the DRM came out first... now I think X is
probably the only project that can push this sort of change without
kernel developer consent, I personally would rather this didn't happen,

I think yourself and Linus's ideas for a locking scheme look good, I also
know they won't please Jon too much as he can see where the potential
ineffecienes with saving/restore card state on driver swap are, especailly
on running fbcon and X on a dual-head card with different users.

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

Re: radeon-pre-2

[Linus Torvalds]

On Sun, 12 Sep 2004, Dave Airlie wrote:
> 
> I think yourself and Linus's ideas for a locking scheme look good, I also
> know they won't please Jon too much as he can see where the potential
> ineffecienes with saving/restore card state on driver swap are, especailly
> on running fbcon and X on a dual-head card with different users.

Now, how much do you actually really need to restore/save?

Yes, intelligent restore/save means that there needs to be independent
memory management, but I thought that was the long-term plan _anyway_, no?  
And once you have reasonably intelligent memory management, you really
only need to save/restore the engine state, if even that (ie it should be
enough to just "idle" the engine).

Now, I'll agree that getting a good MM that solves peoples issues is a
huge problem. Much harder that some little locks. But on the other hand,
it really should be able to be largely card-agnostic, I sincerely hope.

And once you have some way to manage memory allocations between different
clients, saving/restoring card state really shouldn't be problematic. You 
make the rule be that everybody has to be able to re-create their caches 
(as with the locks, the cache manager would obviously have to have a 
callback), and you should never be in the position where you have to 
really save/restore any video memory contents at all.

(Yes, and if your working set ends up being bigger than your video ram, 
you won't perform well, but that's pretty fundamental regardless of number 
of clients or how they communicate).

The MM is still fairly complex, especially wrt areas that are "busy"  
(the client may be able to re-create them, but if the currently executing
_engine_ has pointers to it, the cache obviously can't be thrown away).  

Many of those things might be simplified by having fairly strict rules
("you can do video memory garbage collection only when the engine is
idle"), otherwise you'll need to have some complex infrastructure to keep
track of which areas are used by which commands...

			Linus

Re: radeon-pre-2

[Michel Dänzer]

On Sun, 2004-09-12 at 23:42 +0100, Dave Airlie wrote:
> 
> I think yourself and Linus's ideas for a locking scheme look good, I also
> know they won't please Jon too much as he can see where the potential
> ineffecienes with saving/restore card state on driver swap are, especailly
> on running fbcon and X on a dual-head card with different users.

Frankly, I don't understand the fuss about that. When you run a 3D
client on X today, 3D client and X server share the accelerator with
this scheme, and as imperfect as it is, it seems to do a pretty good job
in my experience.


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer

Re: radeon-pre-2

[Vladimir Dergachev]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=UTF-8; format=flowed, Size: 1825 bytes --]



On Sun, 12 Sep 2004, Michel [ISO-8859-1] Dänzer wrote:

> On Sun, 2004-09-12 at 23:42 +0100, Dave Airlie wrote:
>>
>> I think yourself and Linus's ideas for a locking scheme look good, I also
>> know they won't please Jon too much as he can see where the potential
>> ineffecienes with saving/restore card state on driver swap are, especailly
>> on running fbcon and X on a dual-head card with different users.
>
> Frankly, I don't understand the fuss about that. When you run a 3D
> client on X today, 3D client and X server share the accelerator with
> this scheme, and as imperfect as it is, it seems to do a pretty good job
> in my experience.

Not that good - try dragging something while a DVD video is playing.

But, I don't understand what the fuss is about either. What's wrong with 
putting PLL setting code inside DRM driver and letting it be the client of 
fbcon ? And the transition problems could be well solved by leaving the 
existing fbcon in for the time being, it is not like the kernel does not 
have duplicate drivers.

                      best

                        Vladimir Dergachev

>
>
> -- 
> Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
> Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>

Re: radeon-pre-2

[Michel Dänzer]

On Sun, 2004-09-12 at 20:45 -0400, Vladimir Dergachev wrote:
> 
> On Sun, 12 Sep 2004, Michel [ISO-8859-1] Dnzer wrote:
> 
> > On Sun, 2004-09-12 at 23:42 +0100, Dave Airlie wrote:
> >>
> >> I think yourself and Linus's ideas for a locking scheme look good, I also
> >> know they won't please Jon too much as he can see where the potential
> >> ineffecienes with saving/restore card state on driver swap are, especailly
> >> on running fbcon and X on a dual-head card with different users.
> >
> > Frankly, I don't understand the fuss about that. When you run a 3D
> > client on X today, 3D client and X server share the accelerator with
> > this scheme, and as imperfect as it is, it seems to do a pretty good job
> > in my experience.
> 
> Not that good - try dragging something while a DVD video is playing.

What are you getting at?


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer

Re: radeon-pre-2

[Vladimir Dergachev]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=UTF-8; format=flowed, Size: 2052 bytes --]



On Sun, 12 Sep 2004, Michel [ISO-8859-1] Dänzer wrote:

> On Sun, 2004-09-12 at 20:45 -0400, Vladimir Dergachev wrote:
>>
>> On Sun, 12 Sep 2004, Michel [ISO-8859-1] Dnzer wrote:
>>
>>> On Sun, 2004-09-12 at 23:42 +0100, Dave Airlie wrote:
>>>>
>>>> I think yourself and Linus's ideas for a locking scheme look good, I also
>>>> know they won't please Jon too much as he can see where the potential
>>>> ineffecienes with saving/restore card state on driver swap are, especailly
>>>> on running fbcon and X on a dual-head card with different users.
>>>
>>> Frankly, I don't understand the fuss about that. When you run a 3D
>>> client on X today, 3D client and X server share the accelerator with
>>> this scheme, and as imperfect as it is, it seems to do a pretty good job
>>> in my experience.
>>
>> Not that good - try dragging something while a DVD video is playing.
>
> What are you getting at?

The overlay window is currently using part of what is being proposed by
"multiple drivers" proponents. It has to make engine queiscent so it can 
write data directly to the video memory. It does *not* have to save the 
state.

So, as Jon rightly points out the "multiple drivers" scheme only makes 
sense in the current usage patter - you either use X or framebuffer, never 
both at the same time and you consider a few seconds per switch normal.
(Not that it actually has to take few seconds, I am just pointing out the 
the expectations are well below what we do now)

However, if we want the switch from X to framebuffer to be as fast as 
switching between different text consoles (assuming they have the same 
resolution) and if we want to be able to run different Xservers on 
different consoles or Xserver+framebuffer combinations Jon's proposal 
wins.

                        best

                           Vladimir Dergachev

>
>
> -- 
> Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
> Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer
>

Re: radeon-pre-2

[Alan Cox]

On Llu, 2004-09-13 at 15:52, Vladimir Dergachev wrote:
> However, if we want the switch from X to framebuffer to be as fast as 
> switching between different text consoles (assuming they have the same 
> resolution) and if we want to be able to run different Xservers on 
> different consoles or Xserver+framebuffer combinations Jon's proposal 
> wins.

It depends how the various components fit together. Clearly for Radeon
you want everyone using the DMA command path when DRI is loaded. That
doesn't require "one driver".

Re: radeon-pre-2

[Vladimir Dergachev]

On Mon, 13 Sep 2004, Alan Cox wrote:

> On Llu, 2004-09-13 at 15:52, Vladimir Dergachev wrote:
>> However, if we want the switch from X to framebuffer to be as fast as
>> switching between different text consoles (assuming they have the same
>> resolution) and if we want to be able to run different Xservers on
>> different consoles or Xserver+framebuffer combinations Jon's proposal
>> wins.
>
> It depends how the various components fit together. Clearly for Radeon
> you want everyone using the DMA command path when DRI is loaded. That
> doesn't require "one driver".
>

Alan, do I understand right that you are proposing to have two pieces of 
code in the framebuffer - one that can program the card in the absence of 
DRM driver and one that uses CP when it is present ?

                  best

                    Vladimir Dergachev

Re: radeon-pre-2

[Alan Cox]

On Llu, 2004-09-13 at 16:20, Vladimir Dergachev wrote:
> > It depends how the various components fit together. Clearly for Radeon
> > you want everyone using the DMA command path when DRI is loaded. That
> > doesn't require "one driver"
> 
> Alan, do I understand right that you are proposing to have two pieces of 
> code in the framebuffer - one that can program the card in the absence of 
> DRM driver and one that uses CP when it is present ?

We could do, or the DRM driver could provide DMA methods for the
framebuffer driver to use. I mean it might be that we should always be
using DMA methods in all the drivers for radeon all the time anyway  ?

The fb driver gets told when DRI comes and goes which means the two can
choose to co-operate if they wish.

Re: radeon-pre-2

[Linus Torvalds]

On Mon, 13 Sep 2004, Vladimir Dergachev wrote:
> 
> The overlay window is currently using part of what is being proposed by
> "multiple drivers" proponents. It has to make engine queiscent so it can 
> write data directly to the video memory. It does *not* have to save the 
> state.

It doesn't even really need to make the engine quiesce.

If two subsystems are aware of the locking rules (and the helper driver
obviously doesn't much care), they can just design their own handoff
trivially. For example, it might make sense to make the "wait for the
engine to stop" be the responsibility of the side that actually _needs_
it, namely the PIO user.

So if both users use the engine, not PIO, there's no need to ever stop the
engine. In my example of how to use the locking, it looked something like
this:

	if (get_lock(data->gfx.accelerator)) {
		/* Somebody else used the engine, need to re-load cached index */
		mydev->offset = readl(mydev->mmio + OFFSET_PORT);
	}
	OUT_RING(mydev, cmd);
	OUT_RING(mydev, arg);
	put_lock(data->gfx.accelerator);

See? You can have two clients doing accelerator things, and they _never_ 
wait for anything (well, obviously "OUT_RING()" needs to wait for the 
buffer to be empty enough ;).

They still need to know whether there was a previous user, because 
efficient command filling does require that you don't read the "where is 
the command buffer end" thing all the time, so that's why you have to 
cache that one in real RAM instead of reading it from the card every op. 
And because you cache it, you have to update your cache if somebody else 
uses the engine.

Now, a PIO writer would look different

	if (get_lock(data->gfx.accelerator)) {
		/* Somebody else used the engine, need to quiesce */
		wait_for_engine_idle(mydev);
	}
	outl(cmd, mydev->pio + OFFSET_CMD);
	...
	put_lock(data->gfx.accelerator);

and here if we switch back and forth between a client that uses 
synchronous commands (ie normally PIO) rather than the engine, then yes, 
we'd obviously halt the engine all the time. But hey, you can't avoid 
that: if you want good performance with most modern chips, you do all your 
work with the engine, not with synchronous commands.

> So, as Jon rightly points out the "multiple drivers" scheme only makes 
> sense in the current usage patter - you either use X or framebuffer, never 
> both at the same time and you consider a few seconds per switch normal.

I disagree. You can use a combination of X, framebuffer and "special 
clients", where the special client can be _exactly_ things like video 
overlays etc. 

Now, obviously we'd wish that X has support for video overlays directly, 
and thus you wouldn't even need to switch between clients at that level, 
but there are certainly cases where you may end up with an "external 
client". It might be some very card-specific thing that X or DRM just 
doesn't support yet, so you whip up a quick client for just that.

For example (and this may be a horribly _bad_ example, for all I know),  
let's say that somebody decides that they want to do a DirectX library, 
and all the DRM people just throw their hands up in horror and say "over 
my dead body".

In that case you have two choices: kill the DRM people and dance on their
graves, or just say "ok, I'll make this other client that does the DirectX
interfaces". And the thing is, it shouldn't fundamentally not work. As far
as I can tell, with some rudimentary locking support like the above (the
trivial part) and some memory management support (the _hard_ part), you
should be able to have the two clients work together quite well.

And yes, I realize that this is what DRM already does internally. I agree. 
I applaud it. I'm saying that if we moved that internal locking to be 
_external_, so that other clients can use it too, then fbcon and DRM and 
some random new subsystem could all live together in peace and harmony.

Now, let's all sit around the fire and sing Kumbaya.

		Linus

Re: radeon-pre-2

[Alex Deucher]

How would any of these plans handle power management and ACPI events?
I'd like to be able to suspect my laptop with the DRI enabled, or have
the DDX (or whatever) handle acpi lid and button events or put the
chip into various power modes.

Alex

On Mon, 13 Sep 2004 08:20:58 -0700 (PDT), Linus Torvalds
<torvalds@osdl.org> wrote:
> 
> 
> On Mon, 13 Sep 2004, Vladimir Dergachev wrote:
> >
> > The overlay window is currently using part of what is being proposed by
> > "multiple drivers" proponents. It has to make engine queiscent so it can
> > write data directly to the video memory. It does *not* have to save the
> > state.
> 
> It doesn't even really need to make the engine quiesce.
> 
> If two subsystems are aware of the locking rules (and the helper driver
> obviously doesn't much care), they can just design their own handoff
> trivially. For example, it might make sense to make the "wait for the
> engine to stop" be the responsibility of the side that actually _needs_
> it, namely the PIO user.
> 
> So if both users use the engine, not PIO, there's no need to ever stop the
> engine. In my example of how to use the locking, it looked something like
> this:
> 
>         if (get_lock(data->gfx.accelerator)) {
>                 /* Somebody else used the engine, need to re-load cached index */
>                 mydev->offset = readl(mydev->mmio + OFFSET_PORT);
>         }
>         OUT_RING(mydev, cmd);
>         OUT_RING(mydev, arg);
>         put_lock(data->gfx.accelerator);
> 
> See? You can have two clients doing accelerator things, and they _never_
> wait for anything (well, obviously "OUT_RING()" needs to wait for the
> buffer to be empty enough ;).
> 
> They still need to know whether there was a previous user, because
> efficient command filling does require that you don't read the "where is
> the command buffer end" thing all the time, so that's why you have to
> cache that one in real RAM instead of reading it from the card every op.
> And because you cache it, you have to update your cache if somebody else
> uses the engine.
> 
> Now, a PIO writer would look different
> 
>         if (get_lock(data->gfx.accelerator)) {
>                 /* Somebody else used the engine, need to quiesce */
>                 wait_for_engine_idle(mydev);
>         }
>         outl(cmd, mydev->pio + OFFSET_CMD);
>         ...
>         put_lock(data->gfx.accelerator);
> 
> and here if we switch back and forth between a client that uses
> synchronous commands (ie normally PIO) rather than the engine, then yes,
> we'd obviously halt the engine all the time. But hey, you can't avoid
> that: if you want good performance with most modern chips, you do all your
> work with the engine, not with synchronous commands.
> 
> > So, as Jon rightly points out the "multiple drivers" scheme only makes
> > sense in the current usage patter - you either use X or framebuffer, never
> > both at the same time and you consider a few seconds per switch normal.
> 
> I disagree. You can use a combination of X, framebuffer and "special
> clients", where the special client can be _exactly_ things like video
> overlays etc.
> 
> Now, obviously we'd wish that X has support for video overlays directly,
> and thus you wouldn't even need to switch between clients at that level,
> but there are certainly cases where you may end up with an "external
> client". It might be some very card-specific thing that X or DRM just
> doesn't support yet, so you whip up a quick client for just that.
> 
> For example (and this may be a horribly _bad_ example, for all I know),
> let's say that somebody decides that they want to do a DirectX library,
> and all the DRM people just throw their hands up in horror and say "over
> my dead body".
> 
> In that case you have two choices: kill the DRM people and dance on their
> graves, or just say "ok, I'll make this other client that does the DirectX
> interfaces". And the thing is, it shouldn't fundamentally not work. As far
> as I can tell, with some rudimentary locking support like the above (the
> trivial part) and some memory management support (the _hard_ part), you
> should be able to have the two clients work together quite well.
> 
> And yes, I realize that this is what DRM already does internally. I agree.
> I applaud it. I'm saying that if we moved that internal locking to be
> _external_, so that other clients can use it too, then fbcon and DRM and
> some random new subsystem could all live together in peace and harmony.
> 
> Now, let's all sit around the fire and sing Kumbaya.
> 
>                 Linus
> 
> 
> 
> 
>

Re: radeon-pre-2

[David Bronaugh]

Alex Deucher wrote:

>How would any of these plans handle power management and ACPI events?
>I'd like to be able to suspect my laptop with the DRI enabled, or have
>the DDX (or whatever) handle acpi lid and button events or put the
>chip into various power modes.
>
>Alex
>  
>
Since I've been doing a little bit of ACPI hacking (and gained a bit of 
understanding of it), I think I should probably speak on this one.

With the current ACPI infrastructure, you don't have the DDX or whatever 
catching ACPI events -- acpid catches ACPI events, and does appropriate 
things via scripts. So lid and button events can do things, but -- X 
doesn't handle them. Scripts called by acpid do.

As to putting chips into various power modes -- wouldn't this be better 
off in kernel, not in X? My impression is that this wouldn't be a large 
amount of code. It could also abstract away some details of chip power 
management -- it could (potentially) not matter if it's done via ACPI or 
via a custom bit of code for a chip. And it could expose a file in sysfs 
to adjust power settings for the graphics chip. Then the system that 
exists for handling ACPI events can happily keep being how it is.

Yu, Luming has been doing a lot of work in the area of a generic ACPI 
"video features" driver -- such a driver could do such things as change 
which heads are enabled, set backlight power, and generally muck with 
graphics state. I suspect some possible nasty interaction could happen, 
since ACPI could affect graphics state in some pretty hairy ways. It 
might be a good idea to get in contact with him before the user emails 
show up...

David Bronaugh

ps: I kinda trimmed the CC: list on this

Re: radeon-pre-2

[Alex Deucher]

On Mon, 13 Sep 2004 13:42:19 -0700, David Bronaugh
<dbronaugh@linuxboxen.org> wrote:
> Alex Deucher wrote:
> 
> >How would any of these plans handle power management and ACPI events?
> >I'd like to be able to suspect my laptop with the DRI enabled, or have
> >the DDX (or whatever) handle acpi lid and button events or put the
> >chip into various power modes.
> >
> >Alex
> >
> >
> Since I've been doing a little bit of ACPI hacking (and gained a bit of
> understanding of it), I think I should probably speak on this one.
> 
> With the current ACPI infrastructure, you don't have the DDX or whatever
> catching ACPI events -- acpid catches ACPI events, and does appropriate
> things via scripts. So lid and button events can do things, but -- X
> doesn't handle them. Scripts called by acpid do.
> 
> As to putting chips into various power modes -- wouldn't this be better
> off in kernel, not in X? My impression is that this wouldn't be a large
> amount of code. It could also abstract away some details of chip power
> management -- it could (potentially) not matter if it's done via ACPI or
> via a custom bit of code for a chip. And it could expose a file in sysfs
> to adjust power settings for the graphics chip. Then the system that
> exists for handling ACPI events can happily keep being how it is.
> 
> Yu, Luming has been doing a lot of work in the area of a generic ACPI
> "video features" driver -- such a driver could do such things as change
> which heads are enabled, set backlight power, and generally muck with
> graphics state. I suspect some possible nasty interaction could happen,
> since ACPI could affect graphics state in some pretty hairy ways. It
> might be a good idea to get in contact with him before the user emails
> show up...

It seems to be that this kind of necessitates some sort of kernel mode
driver to handle everything (albeit perhaps with lots of userspace
libs).  I can't see how a generic video acpi driver would play nice
with a userspace X, fbdev, and whever else my be using the hardware. 
It's not that I don't like the idea of letting everyone play I just
want to use my hardware to its fully functionality wihtout a million
kludges everywhere.  OTOH, maybe it'll all just work.  I'm not too
familiar with the ins and outs of ACPI and what's need on the chip
side vs. generic vs. machine specific.  Stuff like enabling outputs
and changine power states is chip specific though and it would need to
play nice.

Alex

> 
> David Bronaugh
> 
> ps: I kinda trimmed the CC: list on this
>

Re: radeon-pre-2

[Michel Dänzer]

On Mon, 2004-09-13 at 10:52 -0400, Vladimir Dergachev wrote:
> 
> So, as Jon rightly points out the "multiple drivers" scheme only makes 
> sense in the current usage patter - you either use X or framebuffer, never 
> both at the same time and you consider a few seconds per switch normal.

You are mixing up things. VT switch != context switch.


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer

Re: radeon-pre-2

[Alex Deucher]

On Sun, 12 Sep 2004 20:45:18 -0400 (EDT), Vladimir Dergachev
<volodya@mindspring.com> wrote:
> 
> 
> On Sun, 12 Sep 2004, Michel [ISO-8859-1] D�nzer wrote:
> 
> > On Sun, 2004-09-12 at 23:42 +0100, Dave Airlie wrote:
> >>
> >> I think yourself and Linus's ideas for a locking scheme look good, I also
> >> know they won't please Jon too much as he can see where the potential
> >> ineffecienes with saving/restore card state on driver swap are, especailly
> >> on running fbcon and X on a dual-head card with different users.
> >
> > Frankly, I don't understand the fuss about that. When you run a 3D
> > client on X today, 3D client and X server share the accelerator with
> > this scheme, and as imperfect as it is, it seems to do a pretty good job
> > in my experience.
> 
> Not that good - try dragging something while a DVD video is playing.

The overlay could be converted to use the CP engine as well. right now
it has to switch to MMIO for overlay.

Alex

> 
> But, I don't understand what the fuss is about either. What's wrong with
> putting PLL setting code inside DRM driver and letting it be the client of
> fbcon ? And the transition problems could be well solved by leaving the
> existing fbcon in for the time being, it is not like the kernel does not
> have duplicate drivers.
> 
>                       best
> 
>                         Vladimir Dergachev
> 
> 
> 
> >
> >
> > --
> > Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
> > Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> > Project Admins to receive an Apple iPod Mini FREE for your judgement on
> > who ports your project to Linux PPC the best. Sponsored by IBM.
> > Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
> > --
> > _______________________________________________
> > Dri-devel mailing list
> > Dri-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/dri-devel
> >
>

Re: radeon-pre-2

[Michel Dänzer]

On Mon, 2004-09-13 at 02:05 -0400, Alex Deucher wrote:
> On Sun, 12 Sep 2004 20:45:18 -0400 (EDT), Vladimir Dergachev
> <volodya@mindspring.com> wrote:
> > 
> > 
> > On Sun, 12 Sep 2004, Michel [ISO-8859-1] D�nzer wrote:
> > 
> > > On Sun, 2004-09-12 at 23:42 +0100, Dave Airlie wrote:
> > >>
> > >> I think yourself and Linus's ideas for a locking scheme look good, I also
> > >> know they won't please Jon too much as he can see where the potential
> > >> ineffecienes with saving/restore card state on driver swap are, especailly
> > >> on running fbcon and X on a dual-head card with different users.
> > >
> > > Frankly, I don't understand the fuss about that. When you run a 3D
> > > client on X today, 3D client and X server share the accelerator with
> > > this scheme, and as imperfect as it is, it seems to do a pretty good job
> > > in my experience.
> > 
> > Not that good - try dragging something while a DVD video is playing.
> 
> The overlay could be converted to use the CP engine as well. right now
> it has to switch to MMIO for overlay.

The question is whether that matters at all, i.e. whether the registers
used for the overlay are FIFO'd.

Either way, I don't see how this is related to the way DRM context
switches are handled.


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer

Re: radeon-pre-2

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 574 bytes --]

On Mon, 2004-09-13 at 00:42, Dave Airlie wrote:
> works well, and the X team decide to do a decent X on mesa-solo on Jons
> super-DRM, now the super-DRM gets pushed via the X tree and distributions
> start relasing kernels with it merged into it and it never goes into the
> main tree... it won't matter, RH/SuSE/whomever will want to pick up the
> new features for the *enhanced user experience* and people will give out

fwiw RH will ship the DRM that is in Linus' kernel not some weird
oddball external one, so at least that portion of your argument is moot
;)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: radeon-pre-2

[Alan Cox]

[-- Attachment #1: Type: text/plain, Size: 1060 bytes --]

On Sul, 2004-09-12 at 23:42, Dave Airlie wrote:
> The worst things that will happen for all concerened is this:
> Jon does all this work on a merged solution outside the kernel, and it
> works well, and the X team decide to do a decent X on mesa-solo on Jons
> super-DRM, now the super-DRM gets pushed via the X tree and distributions
> start relasing kernels with it merged into it 

Unlikely. Its rapidly unmaintainable because the core kernel changes
will obsolete it (see for example KGI).

> I think yourself and Linus's ideas for a locking scheme look good, I also
> know they won't please Jon too much as he can see where the potential
> ineffecienes with saving/restore card state on driver swap are, especailly
> on running fbcon and X on a dual-head card with different users.

Well this is what I came up with so far. It creates a vga class so you
can bind the drivers to functions of the card (and we can add/remove
functions later as appropriate), tells functions about each other and
now implements Linux lock proposal as I understood it.

Alan


[-- Attachment #2: vga_class.c --]
[-- Type: text/x-csrc, Size: 13514 bytes --]

/*
 * drivers/video/vga-driver.c
 *
 */

#include <linux/pci.h>
#include <linux/module.h>
#include <linux/init.h>
#include <linux/device.h>
#include <asm/semaphore.h>
#include "vga_class.h"

/*
 *  Registration of video drivers and handling of hot-pluggable devices.
 */

static LIST_HEAD(vga_devices);	/* No I don't know why its not DECLARE_LIST_HEAD either */

/**
 * vga_match_one_device - Tell if a PCI device structure has a matching
 *                        PCI device id structure
 * @id: single PCI device id structure to match
 * @dev: the PCI device structure to match against
 * 
 * Returns the matching vga_device_id structure or %NULL if there is no match.
 */

static inline const struct vga_device_id *
vga_match_one_device(const struct vga_device_id *id, const struct pci_dev *dev)
{
	if ((id->vendor == PCI_ANY_ID || id->vendor == dev->vendor) &&
	    (id->device == PCI_ANY_ID || id->device == dev->device) &&
	    (id->subvendor == PCI_ANY_ID || id->subvendor == dev->subsystem_vendor) &&
	    (id->subdevice == PCI_ANY_ID || id->subdevice == dev->subsystem_device) &&
	    !((id->class ^ dev->class) & id->class_mask))
		return id;
	return NULL;
}


/**
 * vga_match_device - Tell if a VGA device structure has a matching
 *                    PCI device id structure
 * @ids: array of PCI device id structures to search in
 * @dev: the PCI device structure to match against
 * 
 * Used by a driver to check whether a PCI device present in the
 * system is in its list of supported devices.Returns the matching
 * vga_device_id structure or %NULL if there is no match.
 */
static const struct vga_device_id *
vga_match_device(const struct vga_device_id *ids, const struct vga_dev *vdev)
{
	struct pci_dev *pdev = vdev->pci_dev;
	while (ids->vendor || ids->subvendor || ids->class_mask) {
		if (vga_match_one_device(ids, pdev) && ids->unit == vdev->unit)
			return ids;
		ids++;
	}
	return NULL;
}


static void vga_device_notify_install(struct vga_dev *vdev, int type)
{
	int i;
	for(i = TYPE_MEM; i < TYPE_LAST; i++) {
		struct vga_dev *v = vdev->shared->device[i];
		if(v != NULL && v->driver && i != type)
			v->driver->notify_attach(v, type);
	}
}

static void vga_device_notify_remove(struct vga_dev *vdev, int type)
{
	int i;
	for(i = TYPE_MEM; i < TYPE_LAST; i++) {
		struct vga_dev *v = vdev->shared->device[i];
		if(v != NULL && v->driver && i != type)
			v->driver->notify_detach(v, type);
	}
}

/**
 * vga_device_probe_static()
 * 
 * returns 0 and sets vdev->driver when drv claims vdev, else error.
 */
static int
vga_device_probe_static(struct vga_driver *vdrv, struct vga_dev *vdev)
{		   
	int error = -ENODEV;
	const struct vga_device_id *id;

	if (!vdrv->id_table)
		return error;
	id = vga_match_device(vdrv->id_table, vdev);
	if (id)
		error = vdrv->probe(vdev, id);
	if (error >= 0) {
		vdev->driver = vdrv;
		down(&vdev->shared->shared_sem);
		vdev->shared->users++;
		vga_device_notify_install(vdev, vdev->unit);
		up(&vdev->shared->shared_sem);
		error = 0;
	}
	return error;
}

/**
 * __vga_device_probe()
 * 
 * returns 0  on success, else error.
 * side-effect: vdev->driver is set to vdrv when drv claims vdev.
 */
static int
__vga_device_probe(struct vga_driver *vdrv, struct vga_dev *vdev)
{		   
	int error = 0;

	if (!vdev->driver && vdrv->probe) {
		error = vga_device_probe_static(vdrv, vdev);
	}
	return error;
}

static int vga_device_probe(struct device *dev)
{
	int error = 0;
	struct vga_driver *drv;
	struct vga_dev *vdev;

	drv = to_vga_driver(dev->driver);
	vdev = to_vga_dev(dev);
	vga_dev_get(vdev);
	error = __vga_device_probe(drv, vdev);
	if (error)
		vga_dev_put(vdev);

	return error;
}

static int vga_device_remove(struct device *dev)
{
	struct vga_dev *vdev = to_vga_dev(dev);
	struct vga_driver *vdrv = vdev->driver;

	down(&vdev->shared->shared_sem);	
	vdev->shared->users--;
	if (vdrv) {
		vga_device_notify_remove(vdev, vdev->unit);
		if (vdrv->remove)
			vdrv->remove(vdev, vdev->shared->count);
		vdev->driver = NULL;
	}
	vdev->shared->device[vdev->unit] = NULL;
	up(&vdev->shared->shared_sem);	
	
	vga_dev_put(vdev);
	return 0;
}

static int vga_device_suspend(struct device *dev, u32 state)
{
	return 0;
}


/* 
 * Default resume method for devices that have no driver provided resume,
 * or not even a driver at all.
 */

static int vga_device_resume(struct device *dev)
{
	return 0;
}

static struct kobj_type vga_driver_kobj_type = {
};

/**
 * vga_register_driver - register a new pci driver
 * @drv: the driver structure to register
 * 
 * Adds the driver structure to the list of registered drivers
 * Returns the number of vga devices which were claimed by the driver
 * during registration.  The driver remains registered even if the
 * return value is zero.
 */

int vga_register_driver(struct vga_driver *drv)
{
	/* initialize common driver fields */
	drv->driver.name = drv->name;
	drv->driver.bus = &vga_bus_type;
	drv->driver.probe = vga_device_probe;
	drv->driver.remove = vga_device_remove;
	drv->driver.kobj.ktype = &vga_driver_kobj_type;

	/* register with core */
	return driver_register(&drv->driver);
}

/**
 * vga_unregister_driver - unregister a pci driver
 * @drv: the driver structure to unregister
 * 
 * Deletes the driver structure from the list of registered VGA drivers,
 * gives it a chance to clean up by calling its remove() function for
 * each device it was responsible for, and marks those devices as
 * driverless.
 */

void vga_unregister_driver(struct vga_driver *vdrv)
{
	driver_unregister(&vdrv->driver);
}

/**
 * vga_dev_driver - get the vga_driver of a device
 * @dev: the device to query
 * @type: type of device
 *
 * Returns the appropriate vga_driver structure or %NULL if there is no 
 * registered driver for the device. The shared block is used so that
 * you can pass your own vdev to receive driver information about
 * other attached drivers to the same PCI device. Caller must be careful
 * about locking and use of shared_sem.
 */

struct vga_driver *vga_dev_driver(const struct vga_dev *vdev, int type)
{
	struct vga_dev *v = vdev->shared->device[type];
	if(v == NULL)
		return NULL;
	return v->driver;
}

/**
 * vga_bus_match - Tell if a VGA device structure has a matching PCI device id structure
 * @ids: array of PCI device id structures to search in
 * @dev: the VGA device structure to match against
 * 
 * Used by a driver to check whether a VGA device present in the
 * system is in its list of supported devices.Returns the matching
 * vga_device_id structure or %NULL if there is no match.
 */

static int vga_bus_match(struct device *dev, struct device_driver * drv) 
{
	const struct vga_dev *vdev = to_vga_dev(dev);
	struct vga_driver *vdrv = to_vga_driver(drv);
	const struct vga_device_id * ids = vdrv->id_table;
	if (!ids)
		return 0;
	return vga_match_device(ids, vdev) ? 1 : 0;
}

/**
 * vga_dev_get - increments the reference count of the pci device structure
 * @dev: the device being referenced
 *
 * Each live reference to a device should be refcounted.
 *
 * Drivers for VGA devices should normally record such references in
 * their probe() methods, when they bind to a device, and release
 * them by calling vga_dev_put(), in their disconnect() methods.
 *
 * A pointer to the device with the incremented reference counter is returned.
 */
struct vga_dev *vga_dev_get(struct vga_dev *vdev)
{
	struct device *tmp;

	if (!vdev)
		return NULL;

	tmp = get_device(&vdev->dev);
	if (tmp)        
		return to_vga_dev(tmp);
	else
		return NULL;
}

/**
 * vga_dev_put - release a use of the vga_dev structure
 * @dev: device that's been disconnected
 *
 * Must be called when a user of a device is finished with it.  When the last
 * user of the device calls this function, the memory of the device is freed.
 */
void vga_dev_put(struct vga_dev *dev)
{
	if (dev)
		put_device(&dev->dev);
}

/* For now */
int vga_hotplug (struct device *dev, char **envp, int num_envp,
		 char *buffer, int buffer_size)
{
	return -ENODEV;
}

struct bus_type vga_bus_type = {
	.name		= "vga",
	.match		= vga_bus_match,
	.hotplug	= vga_hotplug,
	.suspend	= vga_device_suspend,
	.resume		= vga_device_resume,
};



/*
 *	Helper for VESAfb and friends.
 */

static int mmio_resource_overlap(struct pci_dev *dev, int i, unsigned long mmio)
{
	unsigned long st = pci_resource_start(dev, i);
	unsigned long size = pci_resource_len(dev, i);
	unsigned long flags = pci_resource_flags(dev, i);
	
	if(st == 0 || size == 0)
	   	return 0;
	if(st + size < mmio)
		return 0;
	if(st > mmio)
		return 0;
	if(flags & IORESOURCE_IO)
		return 0;
	return 1;
}

static struct pci_dev *vga_find_by_mmio(unsigned long mmio)
{
	struct list_head *l;
	list_for_each(l, &vga_devices) {
		struct vga_dev *vdev = list_entry(l, struct vga_dev, next);
		int i;
		for (i = 0; i < 6; i++) {
			if (mmio_resource_overlap(vdev->pci_dev, i, mmio))
				return vdev->pci_dev;
		}
	}
	/* Check ISA window routing ? */
	return NULL;
}


/*
 *	Big locking as suggested by Linus. Drivers can of course be
 *	more friendly and work together on some things.
 */
 
void vga_take_lock(struct vga_dev *vdev, struct vga_driver *vdrv, void *context)
{
	struct vga_shared *v = vdev->shared;
	
	down(&v->shared_sem);
	down(&v->fb_sem);
	if(v->lock_owner != vdrv || v->lock_context != context)
	{
		if(v->lock_release)
			v->lock_release(vdev, v->lock_context);
		v->lock_release = NULL;
	}
	v->lock_owner = vdrv;
	v->lock_context = context;
}

EXPORT_SYMBOL_GPL(vga_take_lock);

/*
 *	Drop the big locking
 */
 
void vga_drop_lock(struct vga_dev *vdev, void (*lock_release)(struct vga_dev *, void *))
{
	struct vga_shared *v = vdev->shared;
	v->lock_release = lock_release;
	up(&v->fb_sem);
	up(&v->shared_sem);
}

EXPORT_SYMBOL_GPL(vga_drop_lock);

/*
 *	VGA device discovery from the PCI side
 */
 
 
/**
 * vga_release_dev - free a pci device structure when all users of it are finished.
 * @dev: device that's been disconnected
 *
 * Will be called only by the device core when all users of this vga device are
 * done.
 */

static void vga_release_dev(struct device *dev)
{
	struct vga_dev *vdev = to_vga_dev(dev);
	/* We want this very late because the remove methods might want to
	   use the locks */
	vga_take_lock(vdev, NULL, NULL);
	vga_drop_lock(vdev, NULL);
	down(&vdev->shared->shared_sem);
	vdev->shared->device[vdev->unit] = NULL;
	vdev->shared->count --;
	up(&vdev->shared->shared_sem);
	if(vdev->shared->count == 0)
		kfree(vdev->shared);
	kfree(vdev);
}

/**
 *	vga_remove_one		-	Remove vga adapter
 *	@pdev: PCI device
 *
 *	A VGA adapter has been removed. We must propogate this into the
 *	VGA bus world
 */
 
static void vga_remove_one(struct pci_dev *pdev)
{
	struct vga_dev *vdev = (struct vga_dev *)pdev->dev.driver_data;
	device_unregister(&vdev->dev);
	/* Remove from lists etc here */
	vga_dev_put(vdev);
}

/**
 *	vga_found_one		-	Add vga adapter
 *	@pdev: PCI device
 *	@ent: matching PCI entity
 *
 *	Allocate and install a new VGA class entity set after the PCI layer
 *	discovers it.  We create device objects for the frame buffer, 
 *	memory manager and dri objects at the moment. Additional frame
 *	buffer objects (multihead) can be allocated by the callers.
 */
 
static int vga_found_one(struct pci_dev *pdev, 
					const struct pci_device_id *ent)
{
	struct vga_shared *vshar = kmalloc(sizeof(*vshar), GFP_KERNEL);
	int i;
	if(vshar == NULL)
		return -ENOMEM;
	
	memset(vshar, 0, sizeof(*vshar));
	init_MUTEX(&vshar->shared_sem);
	init_MUTEX(&vshar->fb_sem);
	vshar->lock_owner = NULL;
	
	for(i = TYPE_MEM; i <= TYPE_FB0; i++)
	{
		struct vga_dev *vdev = kmalloc(sizeof(*vdev), GFP_KERNEL);
		if(vdev == NULL)
			return -ENOMEM;
		memset(vdev, 0, sizeof(*vdev));
	
		vdev->pci_dev = pdev;
		vdev->shared = vshar;
		vdev->unit = i;
		
		vshar->device[i] = vdev;
		vshar->count ++;
	
		vdev->dev.bus = &vga_bus_type;
		vdev->dev.parent = NULL;	/* ? */
		vdev->dev.driver_data = pdev;
		device_initialize(&vdev->dev);
		vdev->dev.release = vga_release_dev;
		vdev->dev.dma_mask = pdev->dev.dma_mask;
		vdev->dev.coherent_dma_mask = pdev->dev.coherent_dma_mask;
		vga_dev_get(vdev);

		INIT_LIST_HEAD(&vdev->next);
		list_add_tail(&vdev->next, &vga_devices);
	}
	return 1;
}

/*
 *	Match all video VGA class objects
 */
 
static struct pci_device_id vga_id_table[] = {
	{ PCI_DEVICE_CLASS(((PCI_CLASS_DISPLAY_VGA << 8) | 0x00), ~0), },
	{ 0, }
};

MODULE_DEVICE_TABLE(pci, vga_id_table);

static struct pci_driver vga_driver = {
	.name		= "vga",
	.probe		= vga_found_one,
	.remove		= vga_remove_one,
	.id_table	= vga_id_table,
	/* Could use suspend/resume hooks ? */
};
 
EXPORT_SYMBOL(vga_register_driver);
EXPORT_SYMBOL(vga_unregister_driver);
EXPORT_SYMBOL(vga_dev_driver);
EXPORT_SYMBOL(vga_bus_type);
EXPORT_SYMBOL(vga_dev_get);
EXPORT_SYMBOL(vga_dev_put);

int __init vga_driver_init(void)
{
	if( bus_register(&vga_bus_type) < 0)
		printk(KERN_ERR "Unable to register VGA bus type.\n");
	return pci_module_init(&vga_driver);
}


postcore_initcall(vga_driver_init);

[-- Attachment #3: vga_class.h --]
[-- Type: text/x-chdr, Size: 2286 bytes --]

#define TYPE_MEM		0	/* Memory manager */
#define TYPE_DRI		1	/* Direct render agent */
#define TYPE_FB0		2	/* Frame buffer head 0 */
#define TYPE_FB1		3	/* Frame buffer head 1 */
#define TYPE_FB2		4	/* Frame buffer head 2 */
#define TYPE_FB3		5	/* Frame buffer head 3 */
#define TYPE_LAST		5
#define NUM_TYPES		6

struct vga_shared {
	struct vga_dev *device[NUM_TYPES];
	struct semaphore shared_sem;
	int count;			/* Devices */
	int users;			/* Active users */
	struct semaphore fb_sem;
	void (*lock_release)(struct vga_dev *, void *);
	void *lock_context;
	struct vga_driver *lock_owner;
};

struct vga_dev {
	struct list_head next;		/* All VGA devices */
	struct list_head router_list;	/* By VGA router (not yet done) */
	struct vga_driver *driver;
	struct pci_dev *pci_dev;
	struct device dev;
	int unit;
	struct vga_shared *shared;
};

struct vga_device_id {
	__u32 vendor, device;		/* Vendor and device ID or PCI_ANY_ID*/
	__u32 subvendor, subdevice;	/* Subsystem ID's or PCI_ANY_ID */
	__u32 class, class_mask;	/* (class,subclass,prog-if) triplet */
	__u32 unit;			/* Logical unit for attach */
	kernel_ulong_t driver_data;	/* Data private to the driver */
};


#define	to_vga_dev(n) container_of(n, struct vga_dev, dev)

struct vga_driver {
	struct list_head node;
	int type;
	char *name;
	int (*probe) (struct vga_dev *vdev, const struct vga_device_id *id);
	void (*remove) (struct vga_dev *dev, int users);	/* Device removed (NULL if not a hot-plug capable driver) */
	int  (*suspend) (struct vga_dev *vdev, u32 state);	/* Device suspended */	int  (*resume) (struct vga_dev *vdev);	                /* Device woken up */
	void (*notify_attach) (struct vga_dev *, int);
	void (*notify_detach) (struct vga_dev *, int);
	struct device_driver driver;
	struct vga_device_id *id_table;
};

#define to_vga_driver(drv) container_of(drv, struct vga_driver, driver)

extern struct bus_type vga_bus_type;

extern int vga_register_driver(struct vga_driver *drv);
extern void vg_unregister_driver(struct vga_driver *drv);
extern struct vga_driver *vga_dev_driver(const struct vga_dev *, int);
extern struct bus_type vga_bus_type;
extern struct vga_dev *vga_dev_get(struct vga_dev *);
extern void vga_dev_put(struct vga_dev *);

Re: radeon-pre-2

[Jon Smirl]

[-- Attachment #1: Type: text/plain, Size: 2122 bytes --]

On Mon, 13 Sep 2004 12:26:33 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> Well this is what I came up with so far. It creates a vga class so you
> can bind the drivers to functions of the card (and we can add/remove
> functions later as appropriate), tells functions about each other and
> now implements Linux lock proposal as I understood it.

It needs something to sort out both drivers attaching to the IRQ.

It also needs something to sort out both drivers using pci_drvdata()
to get to their private data. For example in the hotplug routines you
only get passed a pdev and you want to use that to locate your private
data.

It also needs to track pci_enable_device() so that if one driver
unloads it won't turn the device off for the other driver.

VGA routing needs to be supported. I attached the code I was writing
for that. I was in the middle of writing it so it doesn't compile.
This code should be integrated into the VGA driver.

It needs to integrate into VGAcon. VGAcon should require the vga
device before loading. The resource reservation code in VGAcon needs
to be moved to the VGA driver. If you use a command to switch the
active VGA device, VGAcon needs to reset itself for the new device.

VGA driver needs to generate hotplug events for the VGA device that
indicate if they are primary or secondary. If they are secondary there
needs to be a user space reset program that uses the new ROM hooks to
reset the card.

It should support more than two drivers, I forgot to check, does it already?

fbdev takes a snapshot of the video registers when it loads. When you
unload it it writes those registers back. That doesn't work if you
load from an xterm and rmmod it from the command line. It snapshots
the card in graphics mode and then restores it in an environment
expecting text mode.

Something needs to be done for DMA processing. What if I get an
interrupt that the DMA queue has been completed but we've switched to
a driver that doesn't understand DMA? I guess the only safe thing to
do is make sure all DMA queue are finished before releasing control.

-- 
Jon Smirl
jonsmirl@gmail.com

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: v.diff --]
[-- Type: text/x-patch; name="v.diff", Size: 15928 bytes --]

===== arch/i386/pci/fixup.c 1.21 vs edited =====
--- 1.21/arch/i386/pci/fixup.c	Sun Aug 29 00:21:23 2004
+++ edited/arch/i386/pci/fixup.c	Fri Sep 10 01:03:06 2004
@@ -225,7 +225,7 @@
  * issue another HALT within 80 ns of the initial HALT, the failure condition
  * is avoided.
  */
-static void __init pci_fixup_nforce2(struct pci_dev *dev)
+static void __devinit pci_fixup_nforce2(struct pci_dev *dev)
 {
 	u32 val, fixed_val;
 	u8 rev;
@@ -290,6 +290,6 @@
 		}
 		bus = bus->parent;
 	}
-	pdev->resource[PCI_ROM_RESOURCE].flags |= IORESOURCE_ROM_SHADOW;
+	pdev->resource[PCI_ROM_RESOURCE].flags |= IORESOURCE_ROM_SHADOW | IORESOURCE_VGA_ENABLE;
 }
 DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, pci_fixup_video);
===== drivers/pci/Kconfig 1.6 vs edited =====
--- 1.6/drivers/pci/Kconfig	Mon Aug  2 04:00:43 2004
+++ edited/drivers/pci/Kconfig	Fri Sep 10 01:03:06 2004
@@ -47,3 +47,13 @@
 
 	  When in doubt, say Y.
 
+config VGA_CONTROL
+	bool "VGA Control Device"
+	depends on PCI
+	---help---
+	  Provides a VGA Control Device for ensuring that only a single VGA
+	  device can be enabled per PCI domain. If a VGA device is removed
+	  via hotplug, display is routed to another VGA device if available.
+
+	  If you have more than one VGA device, say Y.
+
===== drivers/pci/Makefile 1.41 vs edited =====
--- 1.41/drivers/pci/Makefile	Sun Aug 29 00:21:23 2004
+++ edited/drivers/pci/Makefile	Sat Sep 11 22:44:22 2004
@@ -28,6 +28,7 @@
 obj-$(CONFIG_MIPS) += setup-bus.o setup-irq.o
 obj-$(CONFIG_X86_VISWS) += setup-irq.o
 obj-$(CONFIG_PCI_MSI) += msi.o
+obj-$(CONFIG_VGA_CONTROL) += vga.o
 
 # Cardbus & CompactPCI use setup-bus
 obj-$(CONFIG_HOTPLUG) += setup-bus.o
===== drivers/pci/bus.c 1.9 vs edited =====
--- 1.9/drivers/pci/bus.c	Sat Apr 10 18:27:59 2004
+++ edited/drivers/pci/bus.c	Sat Sep 11 22:48:04 2004
@@ -100,7 +100,9 @@
 
 		pci_proc_attach_device(dev);
 		pci_create_sysfs_dev_files(dev);
-
+#if CONFIG_VGA_DEVICE
+		pci_vga_add_device(dev);
+#endif
 	}
 
 	list_for_each_entry(dev, &bus->devices, bus_list) {
===== drivers/pci/pci.h 1.13 vs edited =====
--- 1.13/drivers/pci/pci.h	Sun Aug 29 00:21:23 2004
+++ edited/drivers/pci/pci.h	Fri Sep 10 01:03:08 2004
@@ -11,6 +11,7 @@
 				  void (*alignf)(void *, struct resource *,
 					  	 unsigned long, unsigned long),
 				  void *alignf_data);
+int pci_vga_add_device(struct pci_dev *pdev);
 /* PCI /proc functions */
 #ifdef CONFIG_PROC_FS
 extern int pci_proc_attach_device(struct pci_dev *dev);
===== drivers/pci/setup-bus.c 1.25 vs edited =====
--- 1.25/drivers/pci/setup-bus.c	Sun Jul 11 08:41:20 2004
+++ edited/drivers/pci/setup-bus.c	Fri Sep 10 01:03:09 2004
@@ -51,16 +51,8 @@
 	struct resource_list head, *list, *tmp;
 	int idx;
 
-	bus->bridge_ctl &= ~PCI_BRIDGE_CTL_VGA;
-
 	head.next = NULL;
 	list_for_each_entry(dev, &bus->devices, bus_list) {
-		u16 class = dev->class >> 8;
-
-		if (class == PCI_CLASS_DISPLAY_VGA
-				|| class == PCI_CLASS_NOT_DEFINED_VGA)
-			bus->bridge_ctl |= PCI_BRIDGE_CTL_VGA;
-
 		pdev_sort_resources(dev, &head);
 	}
 
@@ -499,12 +491,6 @@
 
 	pbus_assign_resources_sorted(bus);
 
-	if (bus->bridge_ctl & PCI_BRIDGE_CTL_VGA) {
-		/* Propagate presence of the VGA to upstream bridges */
-		for (b = bus; b->parent; b = b->parent) {
-			b->bridge_ctl |= PCI_BRIDGE_CTL_VGA;
-		}
-	}
 	list_for_each_entry(dev, &bus->devices, bus_list) {
 		b = dev->subordinate;
 		if (!b)
===== drivers/pci/vga.c 1.1 vs edited =====
--- 1.1/drivers/pci/vga.c	Fri Sep 10 01:01:47 2004
+++ edited/drivers/pci/vga.c	Sat Sep 11 01:05:37 2004
@@ -1 +1,381 @@
+/*
+ * linux/drivers/char/vga.c
+ *
+ * (C) Copyright 2004 Jon Smirl <jonsmirl@gmail.com>
+ *
+ * VGA control device for ensuring only a single enabled VGA device
+ *
+ * Reuses the DRM major 226, starts minors at VGA_MINOR_BASE, 0x200
+ */
+
+#include <linux/init.h>
+#include <linux/fs.h>
+#include <linux/cdev.h>
+#include <linux/pci.h>
+#include <linux/major.h>
+#include <linux/vga.h>
+
+struct vga_dev {
+	struct class_device class_dev;
+	struct list_head node;
+	dev_t dev;
+	int enabled;
+};
+#define to_vga_dev(d) container_of(d, struct vga_dev, class_dev)
+
+static struct class *vga_class;
+static struct vga_dev *vga_device;
+static DECLARE_MUTEX(vga_mutex);
+static int vga_initialized;	/* = 0 */
+
+/*
+ * Open/close code for vga IO.
+ */
+static int vga_open(struct inode *inode, struct file *filp)
+{
+//	const int minor = iminor(inode);
+
+	down(&vga_mutex);
+	up(&vga_mutex);
+
+	return 0;
+}
+
+/*
+ */
+static int vga_release(struct inode *inode, struct file *filp)
+{
+	down(&vga_mutex);
+	up(&vga_mutex);
+
+	return 0;
+}
+
+/*
+ */
+static int
+vga_ioctl(struct inode *inode, struct file *filp,
+		  unsigned int command, unsigned long arg)
+{
+	return 0;
+}
+
+static struct file_operations vga_fops = {
+	.open	=	vga_open,
+	.release=	vga_release,
+	.ioctl	=	vga_ioctl,
+	.owner	=	THIS_MODULE,
+};
+
+static struct cdev vga_cdev = {
+	.kobj	=	{.name = "vga", },
+	.owner	=	THIS_MODULE,
+};
+
+static void bridge_yes(drm_device_t *dev)
+{
+	struct pci_dev *bridge;
+	struct pci_bus *bus;
+	
+	/* Make sure the bridges route to us */
+	bus = dev->pdev->bus;
+	while (bus) {
+		bridge = bus->self;
+		if (bridge) {
+			pci_read_config_word(bridge, PCI_BRIDGE_CONTROL, &pbus->bridge_ctl);
+			pbus->bridge_ctl |= PCI_BRIDGE_CTL_VGA;
+			pci_write_config_word(bridge, PCI_BRIDGE_CONTROL, pbus->bridge_ctl);
+		}
+		bus = bus->parent;
+	}
+}
+
+static void bridge_no(drm_device_t *dev)
+{
+	struct pci_dev *bridge;
+	struct pci_bus *bus;
+	
+	/* Make sure the bridges don't route to us */
+	bus = dev->pdev->bus;
+	while (bus) {
+		bridge = bus->self;
+		if (bridge) {
+			pci_read_config_word(bridge, PCI_BRIDGE_CONTROL, &pbus->bridge_ctl);
+			pbus->bridge_ctl &= ~PCI_BRIDGE_CTL_VGA;
+			pci_write_config_word(bridge, PCI_BRIDGE_CONTROL, pbus->bridge_ctl);
+		}
+		bus = bus->parent;
+	}
+}
+
+
+/* sysfs for VGA device */
+static ssize_t vga_device_show(struct device *dev, char *buf)
+{
+	struct pci_dev *pdev = to_pci_dev(dev);
+	return sprintf(bus, "%d\n", (pdev->resource[PCI_ROM_RESOURCE].flags & IORESOURCE_VGA_ENABLE) != 0);
+}
+static ssize_t vga_device_store(struct device *dev, const char *buf, size_t count)
+{
+	return count;
+}
+static struct device_attribute vga_device_attr = __ATTR(vga, S_IRUGO|S_IWUSR, vga_device_show, vga_device_store);
+
+/* sysfs for VGA routing bridge */
+static ssize_t vga_bridge_show(struct device *dev, char *buf)
+{
+	struct pci_dev *pdev = to_pci_dev(dev);
+	u16 l;
+
+	/* don't trust the shadow PCI_BRIDGE_CTL_VGA in pdev */
+	/* user space may change hardware without telling the kernel */
+	pci_read_config_word(pdev, PCI_BRIDGE_CONTROL, &l);
+	return sprintf(buf, "%d\n", (l & PCI_BRIDGE_CTL_VGA) != 0);
+}
+static struct device_attribute vga_bridge_attr = __ATTR(vga, S_IRUGO, vga_bridge_show, NULL);
+
+/* sysfs for VGA root legacy space */
+static ssize_t vga_root_show(struct class_device *class_dev, char *buf)
+{
+	struct vga_dev *vga = to_vga_dev(class_dev);
+	return sprintf(buf, "%d\n", vga->enabled);
+}
+static ssize_t vga_root_store(struct class_device *class_dev, const char *buf, size_t count)
+{
+	char *endp;
+	struct vga_dev *vga = to_vga_dev(class_dev);
+	
+	vga->enabled =  (simple_strtoul(buf, &endp, 0) != 0);
+	return count;
+}
+static struct class_device_attribute vga_root_attr = __ATTR(vga, S_IRUGO|S_IWUSR, vga_root_show, vga_root_store);
+
+/* sysfs for /class/vga/vga0/dev */
+static ssize_t show_dev(struct class_device *class_dev, char *buf)
+{
+	struct vga_dev *vga = to_vga_dev(class_dev);
+	return print_dev_t(buf, vga->dev);
+}
+CLASS_DEVICE_ATTR(dev, S_IRUGO, show_dev, NULL);
+
+int pci_vga_add_device(struct pci_dev *pdev)
+{
+	char name[20];
+	int class = pdev->class >> 8;
+
+	if (!vga_initialized)
+		return -EACCES;
+
+	if (class == PCI_CLASS_DISPLAY_VGA) {
+		device_create_file(&pdev->dev, &vga_device_attr);
+		snprintf(name, sizeof(name), "%04x:%02x:%02x.%d", pci_domain_nr(pdev->bus), 
+			pdev->bus->number, PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));
+		sysfs_create_link(&vga_device->class_dev.kobj, &pdev->dev.kobj, name);
+		return 0;
+	}
+
+	if ((class == PCI_CLASS_BRIDGE_PCI) || (class == PCI_CLASS_BRIDGE_CARDBUS)) {
+		device_create_file(&pdev->dev, &vga_bridge_attr);
+	}
+
+	return 0;
+}
+
+static int __init vga_init(void)
+{
+	int ret;
+	dev_t dev;
+	int minor = 0;
+	struct pci_dev *pdev = NULL;
+
+	vga_initialized = 1;
+	dev = MKDEV(DRM_MAJOR, VGA_MINOR_BASE);
+
+	if (register_chrdev_region(dev, VGA_MINOR_MAX, "vga"))
+		goto err_i1;
+
+	cdev_init(&vga_cdev, &vga_fops);
+	if (cdev_add(&vga_cdev, dev, VGA_MINOR_MAX)) {
+		kobject_put(&vga_cdev.kobj);
+		goto err_i2;
+	}
+
+	vga_class = kmalloc(sizeof(*vga_class), GFP_KERNEL);
+	if (!vga_class)
+		goto err_i3;
+	memset(vga_class, 0x00, sizeof(*vga_class));
+
+	vga_class->name = "vga";
+	if ((ret = class_register(vga_class)))
+		goto err_i4;
+
+	vga_device = kmalloc(sizeof(*vga_device), GFP_KERNEL);
+	if (!vga_device)
+		goto err_i5;
+	memset(vga_device, 0x00, sizeof(*vga_device));
+
+	vga_device->dev = MKDEV(DRM_MAJOR, VGA_MINOR_BASE + minor);
+	vga_device->class_dev.dev = NULL;
+	vga_device->class_dev.class = vga_class;
+	snprintf(vga_device->class_dev.class_id, BUS_ID_SIZE, "vga%d", minor);
+	
+	if ((ret = class_device_register(&vga_device->class_dev)))
+		goto err_i6;
+
+	class_device_create_file(&vga_device->class_dev, &class_device_attr_dev);
+	class_device_create_file(&vga_device->class_dev, &vga_root_attr);
+
+	while ((pdev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, pdev)) != NULL)
+		pci_vga_add_device(pdev);
+		
+	printk(KERN_INFO "VGA control device 1.0 initialized\n");
+
+	return 0;
+
+err_i6:
+	kfree(vga_device);
+err_i5:
+	class_unregister(vga_class);
+err_i4:
+	kfree(vga_class);
+err_i3:
+	cdev_del(&vga_cdev);
+err_i2:
+	unregister_chrdev_region(dev, VGA_MINOR_MAX);
+err_i1:
+	printk(KERN_ERR "error initializing VGA control device\n");
+	return 1;
+}
+
+static void __exit vga_exit(void)
+{
+	class_device_unregister(&vga_device->class_dev);
+	kfree(vga_device);
+	class_unregister(vga_class);
+	kfree(vga_class);
+	cdev_del(&vga_cdev);
+	unregister_chrdev_region(MKDEV(DRM_MAJOR, VGA_MINOR_BASE), VGA_MINOR_MAX);
+}
+
+__initcall(vga_init);
+__exitcall(vga_exit);
+
+
+
+/*
+ * 0 - Disable all VGA and cards
+ * 1 - Enable only active card and VGA (assumes other devices are disabled)
+ * 2 - Enable all pci devices
+ *
+ * This is a driver specific function accessed via DRM(stub)
+ * doing it this way allows for driver specific overrides if needed
+ */
+#define VE_DISABLE 0
+#define VE_ACTIVE 1
+#define VE_ENABLE 2
+int DRM(vgaenable)(int enable, int clear_active) {
+	int i;
+	drm_device_t *dev;
+	
+	switch (enable) {	
+	case VE_DISABLE:
+		/* disable all VGA and all devices */
+		/* loop over all the driver's cards */
+		for (i = 0; i < DRM(numdevs); i++) {
+			dev = &DRM(device)[i];
+			if (clear_active)
+				dev->vga_active = FALSE;
+		
+			bridge_yes(dev);
+			/* 0x3CC and 0x3C2 are correct, it's not a typo */
+			outb(~0x03 & inb(0x3CC),  0x3C2);
+			outb(~0x01 & inb(0x3C3),  0x3C3);
+			outb(~0x08 & inb(0x46e8), 0x46e8);
+			outb(~0x01 & inb(0x102),  0x102);
+			pci_disable_device(dev->pdev);
+			bridge_no(dev);
+		}
+		return 0;
+	case VE_ACTIVE:
+		/* enable device and VGA on active device */	
+		/* loop over all the driver's cards */
+		for (i = 0; i < DRM(numdevs); i++) {
+			dev = &DRM(device)[i];
+			if (!dev->vga_active)
+				continue;
+			/* this assumes all other potential VGA devices are disabled */
+			bridge_yes(dev);
+			pci_enable_device(dev->pdev);
+			/* 0x3CC and 0x3C2 are correct, it's not a typo */
+			outb(0x03 | inb(0x3CC),  0x3C2);
+			outb(0x01 | inb(0x3C3),  0x3C3);
+			outb(0x08 | inb(0x46e8), 0x46e8);
+			outb(0x01 | inb(0x102),  0x102);
+			return 0;
+		}
+		return 0;
+	case VE_ENABLE:
+		/* loop over all the driver's cards */
+		for (i = 0; i < DRM(numdevs); i++) {
+			dev = &DRM(device)[i];
+			pci_enable_device(dev->pdev);
+		}
+		return 0;
+	default:
+		return -1;
+	}
+}
+
+/*
+ * VGA_ENABLE_ACTIVE=0 - Make sure all DRM VGAs are disabled, if this one not active reenable active VGA
+ * VGA_ENABLE_THIS=1 - Make sure all DRM VGAs are disabled and enable this DRM VGA, mark as active VGA
+ * Used while resetting a board
+ * VGA_DISABLE_ALL=2 - Disable all DRM VGA and devices, remember active VGA
+ */
+int DRM(vga_enable)( DRM_IOCTL_ARGS ) {
+	DRM_DEVICE;
+	drm_file_t *filp_priv;
+	drm_vga_enable_t ve;
+	struct drm_stub_info *pStub;
+	
+	DRM_GET_PRIV_WITH_RETURN( filp_priv, filp );
+
+	DRM_COPY_FROM_USER_IOCTL( ve, ( drm_vga_enable_t* )data, sizeof( ve ) );
+
+	if ((ve.enable < VGA_ENABLE_ACTIVE) || (ve.enable > VGA_DISABLE_ALL))
+		return -1;
+
+	/* First disable all VGA and all devices */
+	/* loop over all drivers */
+	pStub = &DRM(stub_info);
+	do {
+		/* clear the active device if enable 1 */
+		pStub->vgaenable(VE_DISABLE, (ve.enable == VGA_ENABLE_THIS));
+		pStub = pStub->next;
+	} while (pStub != &DRM(stub_info));
+	
+	if (ve.enable == VGA_DISABLE_ALL)
+		return 0;
+
+	/* Mark us active if requested */	
+	if (ve.enable == VGA_ENABLE_THIS)
+		dev->vga_active = TRUE;
+		
+	/* Now enable VGA on the target device */
+	/* loop over all drivers; don't know where the device is */
+	pStub = &DRM(stub_info);
+	do {
+		pStub->vgaenable(VE_ACTIVE, 0);
+		pStub = pStub->next;
+	} while (pStub != &DRM(stub_info));
+	
+	/* Reenable all PCI devices but don't touch VGA state */
+	pStub = &DRM(stub_info);
+	do {
+		pStub->vgaenable(VE_ENABLE, 0);
+		pStub = pStub->next;
+	} while (pStub != &DRM(stub_info));
+	
+	return 0;
+}
 
===== include/linux/ioport.h 1.15 vs edited =====
--- 1.15/include/linux/ioport.h	Sun Aug 29 00:21:23 2004
+++ edited/include/linux/ioport.h	Fri Sep 10 01:03:10 2004
@@ -41,7 +41,6 @@
 #define IORESOURCE_CACHEABLE	0x00004000
 #define IORESOURCE_RANGELENGTH	0x00008000
 #define IORESOURCE_SHADOWABLE	0x00010000
-#define IORESOURCE_BUS_HAS_VGA	0x00080000
 
 #define IORESOURCE_DISABLED	0x10000000
 #define IORESOURCE_UNSET	0x20000000
@@ -86,6 +85,7 @@
 #define IORESOURCE_ROM_ENABLE		(1<<0)	/* ROM is enabled, same as PCI_ROM_ADDRESS_ENABLE */
 #define IORESOURCE_ROM_SHADOW		(1<<1)	/* ROM is copy at C000:0 */
 #define IORESOURCE_ROM_COPY		(1<<2)	/* ROM is alloc'd copy, resource field overlaid */
+#define IORESOURCE_VGA_ENABLE		(1<<3)	/* VGA device is active */
 
 /* PC/ISA/whatever - the normal PC address spaces: IO and memory */
 extern struct resource ioport_resource;
===== include/linux/major.h 1.12 vs edited =====
--- 1.12/include/linux/major.h	Fri Mar 19 00:59:29 2004
+++ edited/include/linux/major.h	Fri Sep 10 21:29:53 2004
@@ -160,6 +160,7 @@
 
 #define OSST_MAJOR		206	/* OnStream-SCx0 SCSI tape */
 
+#define DRM_MAJOR		226	/* Direct Rendering Manager */
 #define IBM_TTY3270_MAJOR	227
 #define IBM_FS3270_MAJOR	228
 
===== include/linux/vga.h 1.1 vs edited =====
--- 1.1/include/linux/vga.h	Fri Sep 10 01:01:47 2004
+++ edited/include/linux/vga.h	Fri Sep 10 21:41:00 2004
@@ -1 +1,14 @@
+/*
+ * include/linux/vga.h
+ *
+ * (C) Copyright 2004 Jon Smirl <jonsmirl@yahoo.com>
+ *
+ * VGA control device for ensuring only a single enabled VGA device
+ */
  
+/* VGA device shares it's major device number with the DRM devices */
+/* DRM_MAJOR defines the major number in major.h */
+
+#define VGA_MINOR_BASE	0x200	/* First VGA minor starts here */
+#define VGA_MINOR_MAX	16 
+

Re: radeon-pre-2

[Alan Cox]

On Llu, 2004-09-13 at 16:06, Jon Smirl wrote:
> It also needs something to sort out both drivers using pci_drvdata()
> to get to their private data. For example in the hotplug routines you
> only get passed a pdev and you want to use that to locate your private
> data.

The hotplug routines for vga objects in the code I posted get passed
vga_dev objects. You can put what you like in those. I guessed at 
"memory manager" "dri" and "framebuffer0" being the ones to create for
now but we can invent anything thats more appropriate.

> It also needs to track pci_enable_device() so that if one driver
> unloads it won't turn the device off for the other driver.

The ->remove function is passed the number of remaining clients for
exactly this reason. We could move the resource grabbing up the tree.
IRQ handling is rather harder. Quiescing and handing back the IRQ on
lock loss is ugggggggggly so I want to think about it - it works but its
not nice.

Should pci_enable and friends be done by the vga class driver- it can do
this and it would have to do it if it did the hotplug ?

> VGA routing needs to be supported. I attached the code I was writing
> for that. I was in the middle of writing it so it doesn't compile.
> This code should be integrated into the VGA driver.

Agreed. 

> It needs to integrate into VGAcon. VGAcon should require the vga
> device before loading. The resource reservation code in VGAcon needs
> to be moved to the VGA driver. If you use a command to switch the
> active VGA device, VGAcon needs to reset itself for the new device.

I saw vgacon as being a client of the vga class driver like the various
fb drivers would be.

> VGA driver needs to generate hotplug events for the VGA device that
> indicate if they are primary or secondary. If they are secondary there
> needs to be a user space reset program that uses the new ROM hooks to
> reset the card.

The VGA driver at the moment doesn't really know about legacy vga space.
That was something I wanted to touch last of all because it is foul. It
can do this and as you say its the perfect person to issue the hotplug
notifications. It also needs to do it for vesafb so if it is handed an
ISA hole it can work out the right PCI device.

> It should support more than two drivers, I forgot to check, does it already?

As many as you want. Just change the array size or the number
registered. One neat trick we can support is adding extra devices when
necessary - thus if the boot code in user space boots a card and decides
its multihead we'd want to add extra heads.

> fbdev takes a snapshot of the video registers when it loads. When you
> unload it it writes those registers back. That doesn't work if you
> load from an xterm and rmmod it from the command line. It snapshots
> the card in graphics mode and then restores it in an environment
> expecting text mode.

Big lock issue. You get told if someone else ate your environment. Being
more polite about that would help performance a ton. You know who had
the lock before and who has it now - so we can be intelligent about
->release cleanup I hope. (eg FB0 finds FB1 had it last it might do a
minimal restore)

> Something needs to be done for DMA processing. What if I get an
> interrupt that the DMA queue has been completed but we've switched to
> a driver that doesn't understand DMA? I guess the only safe thing to
> do is make sure all DMA queue are finished before releasing control.

The ->remove path takes the lock (so calls ->release) and then drops it
with no callback needed so providing the hand over code is robust this
will come for free.

Alan

Re: radeon-pre-2

[Jon Smirl]

Doesn't the base platform need to be designed to also treat individual
heads as resources?

fbdev only sets the mode on a single head. My cards have more that one
head. When I tried adding mode setting to DRM so that I could handle
my other heads there was a big uproar that fbdev owns mode setting and
that code shouldn't be duplicated. Making fbdev support more than one
head means that it's API has to be redesigned. DRM doesn't have a mode
API so one can be designed from scratch.

In a two head system with simultaneous users, one using fbdev console
and the other playing a 3D game, how is this locking thing going to
work on a process swap basis? Even though we don't have the code for
this today the architecture needs to be designed for it. The reason
you can't do this today is because the kernel level drivers won't
allow it, you can do this currently from the X server.

Heads need to stay in an "unassigned state" until someone logs in on
them. This allows a head to issue a request for "merged fb" mode and
take over the other head. This may require some creativity for drawing
the log in prompts.

Don't forget about SAK and drawing prompts that can't be spoofed.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: radeon-pre-2

[Alan Cox]

On Llu, 2004-09-13 at 17:28, Jon Smirl wrote:
> Doesn't the base platform need to be designed to also treat individual
> heads as resources?

Already covered - although at the moment the question is open about who
tells the vga generic code "It has 4 heads" ?

Had a look over your class code - its nice and it should integrate
really easily as well as remove most of the PCI layer patching it now
does.

Alan

Re: radeon-pre-2

[Jon Smirl]

It wasn't intended to stay in the PCI layer. Something needs to be
done about hotplugging bridges. There aren't callouts from the PCI
layer for that. A hotplugged bridge can be capable of VGA routing and
have VGA devices behind it. I just started off in the PCI layer while
I figured out what hooks were needed. If a VGA capable bridge is
hotplugged, the VGA driver needs to know about it since it has to
create sysfs attributes and directories for it.

Another solution would be to split it. VGA attributes for the bridges
would be handled by the PCI layer. The other stuff by the VGA driver.

The driver has to have a few capabilities:
1) Turn off all VGA devices in this "VGA space". This is needed
because resetting a card is going to turn on it's VGA mode and we
can't have more than one.
2) It can't rely on the kernel structures representing the VGA state
or bridge routing state. For example the reset program is going to
turn a VGA device on without telling the kernel. There are other
things like X that do VGA programming from user space. Instead of
using the structure you need to query the hardware.
3) Activate a new VGA device. The only safe way to do this is to turn
off all devices using function #1 first. User space may have turned a
device on with telling the kernel. Activating a new device need to
tell vgacon about new screen size/mode.

sysfs looks like this:

/class/vga
     vga0
     vga1 --- one for each "VGA space"

/class/vga/vga0/dev - causes hotplug to create /dev/vga0. I used the
major from DRM and started the minors at 512.

/class/vga/vga0/vga - setting this attribute to zero turns off all VGA
devices in this space

/class/vga/vga0/* - links to all of the VGA devices in this "VGA space"

/class/vga/vga0/0000:01:00.0/vga - set this to one to enable a
specific VGA device. As a side effect it will always disable all other
VGA device in this space.

Each PCI bridge device has a vga attribute indicating it's state of
VGA routing. These are readonly. The actual bridge routing state is
set as a function of activating a new VGA device.

The IA64 people want a file/ioctl interface on the /dev/vga0 devices
so that they can issue control calls to the active device in each "VGA
space"

Re: radeon-pre-2

[Jesse Barnes]

On Monday, September 13, 2004 11:11 am, Jon Smirl wrote:
> The IA64 people want a file/ioctl interface on the /dev/vga0 devices
> so that they can issue control calls to the active device in each "VGA
> space"

I think ppc and sparc want this too, we'll use it for issuing legacy in/out.

Thanks,
Jesse

Re: radeon-pre-2

[Antonino A. Daplas]

On Tuesday 14 September 2004 00:28, Jon Smirl wrote:
> Doesn't the base platform need to be designed to also treat individual
> heads as resources?
>
> fbdev only sets the mode on a single head. My cards have more that one
> head. When I tried adding mode setting to DRM so that I could handle
> my other heads there was a big uproar that fbdev owns mode setting and
> that code shouldn't be duplicated. Making fbdev support more than one
> head means that it's API has to be redesigned.

What do you mean?

Your driver has 2 heads, both of which have independent outputs and
separate framebuffers, then register your driver twice:

display0->fb0->framebuffer0-|
                            common par
display1->fb1->framebuffer1-|

Or outputs are interdependent with a common framebuffer, then register the
driver once:

                           par0
display0->fb0->framebuffer-|
	                   par1

Or outputs are independent, but shares a common framebuffer, then register
driver twice, each info with the same pointer to framebuffer:

              par0
display0->fb0-|
              framebuffer
display1->fb1-|
	      par1

Tony

Re: radeon-pre-2

[Jon Smirl]

How's this going to work with hotplug? Hotplug works by associating a
device with a driver by the PCI ID table contained in the driver. Both
the fbdev and DRI drivers currently contain the same PCI IDs for the
cards that the chipsets they support.

So when a card gets hotplugged, which driver do I load? If it's the
VGA driver, then how do I tell the VGA driver that I want to use fbdev
or DRM? What if I want a different one on each head?

There is one VGA driver and multiple fbdev/DRM drivers, one for each chipset.

I guess you need to build something into the VGA driver that gets the
PCI ID tables out of the various fbdev/DRM drivers and combine them
into a single table visible to hotplug.  Then let the VGA driver take
the hotplug event. The VGA driver can then search it's table and
figure out which driver to initialize.

What if I have two identical PCI video cards. Don't we need an
initialization file to say load DRM on the one in slot 1 and fbdev on
the one in slot 2?

-- 
Jon Smirl
jonsmirl@gmail.com

Re: radeon-pre-2

[Alan Cox]

On Llu, 2004-09-13 at 18:50, Jon Smirl wrote:
> How's this going to work with hotplug? Hotplug works by associating a
> device with a driver by the PCI ID table contained in the driver. Both
> the fbdev and DRI drivers currently contain the same PCI IDs for the
> cards that the chipsets they support.

Insert card
	pc layer calls hotplug
	hotplug loads vga driver
	pci layer calls vga driver
	vga driver generates hotplug event
	hotplug loads stuff (user policy)
	vga driver calls hotplugged drivers

> I guess you need to build something into the VGA driver that gets the
> PCI ID tables out of the various fbdev/DRM drivers and combine them
> into a single table visible to hotplug.  Then let the VGA driver take
> the hotplug event. The VGA driver can then search it's table and
> figure out which driver to initialize.

Thats what it does. The vga_device_register functions take a vga_driver
object which is a PCI driver lookalike with an extra field of "type" so
you can load DRM's, FB's etc

> What if I have two identical PCI video cards. Don't we need an
> initialization file to say load DRM on the one in slot 1 and fbdev on
> the one in slot 2?

Possibly, thats for hotplug user space policy. 

Alan

Re: radeon-pre-2

[Keith Whitwell]

Alan Cox wrote:
> On Gwe, 2004-09-10 at 23:19, Dave Airlie wrote:
> 
>>If the kernel developers can address this point I would be most
>>interested, in fact I don't want to hear any more about sharing lowlevel
>>VGA device drivers until someone addresses why it is acceptable to have
>>two separate driver driving the same hardware for video and not for
>>anything else.. (remembering graphics cards are not-multifunction cards -
>>like Christoph used as an example before - 2d/3d are not separate
>>functions...)...
> 
> 
> We've addressed this before. Zillions of drivers provide multiple
> functions to multiple higher level subsystems. They don't all have to
> be compiled together to make it work. 
> 
> 2D and 3D _are_ to most intents and purposes different functions. They
> are as different as IDE CD and IDE disk if not more so.

This depends to a great deal what you mean by 2D.  The idea of a blitter or 
dedicated 2D acceleration engine is rapidly becoming history.  Several cards 
currently ship without one, and I expect to see that become the norm in future.

But if you define 2D to include things like mode setting, etc, and not any 
acceleration, then the split sortof works.

It might be better to call the components different names, like 
"configuration" and "acceleration".

Keith

Re: radeon-pre-2

[Jon Smirl]

On Fri, 10 Sep 2004 23:19:42 +0100 (IST), Dave Airlie <airlied@linux.ie> wrote:
> Also I don't think what Jon has in mind is going to be truly possible and
> IMHO an efficient flexible graphics card memory management system is
> something worthy of multiple PhDs (maybe I'll go back to college), Ians
> work is going to exist mainly in userspace using the DRM for paging things
> and locking, I think the only way we can really do this is with a simple
> fb memory manager in the kernel that the userspace one overrides and then
> tells the fb drivers the new settings - and the fb drivers use those
> settings until told otherwise..

I'm counting on Ian to provide the memory management code. I haven't
even looked at it very much. The point is simply that we have to have
something, you just can't support multiple heads without minimal
memory management and fbdev doesn't currently have any memory
management. Since the plan is for a mode setting command to take a
path unto user space via hotplug it may be possible for all memory
management code to exist in user space. The basic point is that the
memory management code must be unified.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: radeon-pre-2

[Alan Cox]

On Sad, 2004-09-11 at 00:10, Jon Smirl wrote:
> I'm counting on Ian to provide the memory management code. I haven't
> even looked at it very much. The point is simply that we have to have
> something, you just can't support multiple heads without minimal
> memory management and fbdev doesn't currently have any memory
> management. Since the plan is for a mode setting command to take a
> path unto user space via hotplug it may be possible for all memory
> management code to exist in user space. The basic point is that the
> memory management code must be unified.

DRI's memory allocator needs are very different to the others. That
probably means the kernel API should be very simple and push most of the
allocation to user space for rendering work. You want
"give me 4Mb" in kernel , but you don't want allocation for textures in
kernel (just profile the via driver).

fbdev does btw have memory management, quite a bit of it for some
multihead cards.

Re: radeon-pre-2

[Christoph Hellwig]

> If the kernel developers can address this point I would be most
> interested, in fact I don't want to hear any more about sharing lowlevel
> VGA device drivers until someone addresses why it is acceptable to have
> two separate driver driving the same hardware for video and not for
> anything else.. (remembering graphics cards are not-multifunction cards -
> like Christoph used as an example before - 2d/3d are not separate
> functions...)...

Well, Alan's proposal gets things back into a working shape with both
fbdev and get additional benefits like hotplug and autloading without
a major revamp of everything.  The major rework will have to happen sooner
or later anyway, but by fixing the obvious problems we face now first it
can be done in small pieces and with far less pressure.

Re: radeon-pre-2

[Mike Mestnik]

--- Christoph Hellwig <hch@infradead.org> wrote:

> > If the kernel developers can address this point I would be most
> > interested, in fact I don't want to hear any more about sharing
> lowlevel
> > VGA device drivers until someone addresses why it is acceptable to
> have
> > two separate driver driving the same hardware for video and not for
> > anything else.. (remembering graphics cards are not-multifunction
> cards -
> > like Christoph used as an example before - 2d/3d are not separate
> > functions...)...
> 
> Well, Alan's proposal gets things back into a working shape with both
> fbdev and get additional benefits like hotplug and autloading without
> a major revamp of everything.  The major rework will have to happen
> sooner
> or later anyway, but by fixing the obvious problems we face now first it
> can be done in small pieces and with far less pressure.
> 
Not to step on toes, but...  From what I can tell the idea is to add code
into FB that calles functions in the DRM and vice vers.  This would seam
to  add another ABI.  Unless the code gets linked into one module, this
idea has been flamed and killed already.

I would be willing to bet that if some one did this, into one module, it
would be exepted by all.  However I don't see why we can't add multi-head
support, posibly at the same time? -Since Joe seams so willing to do this,
why not let him.

> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM. 
> Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
> 



		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

Re: radeon-pre-2

[Christoph Hellwig]

On Sat, Sep 11, 2004 at 05:49:30AM -0700, Mike Mestnik wrote:
> Not to step on toes, but...  From what I can tell the idea is to add code
> into FB that calles functions in the DRM and vice vers.  This would seam
> to  add another ABI.  Unless the code gets linked into one module, this
> idea has been flamed and killed already.

in-kernel ABIs are absolutely not an issue for Linux.

Re: radeon-pre-2

[Jon Smirl]

On Sat, 11 Sep 2004 13:27:27 +0100, Christoph Hellwig <hch@infradead.org> wrote:
> > If the kernel developers can address this point I would be most
> > interested, in fact I don't want to hear any more about sharing lowlevel
> > VGA device drivers until someone addresses why it is acceptable to have
> > two separate driver driving the same hardware for video and not for
> > anything else.. (remembering graphics cards are not-multifunction cards -
> > like Christoph used as an example before - 2d/3d are not separate
> > functions...)...
> 
> Well, Alan's proposal gets things back into a working shape with both
> fbdev and get additional benefits like hotplug and autloading without
> a major revamp of everything.  The major rework will have to happen sooner
> or later anyway, but by fixing the obvious problems we face now first it
> can be done in small pieces and with far less pressure.
> 
The resource reservation conflicts are already solved in the current
DRM code. Most of the changes are in kernel and the rest are in the
pipeline.  DRM loads in two modes, primary where it behaves like a
normal Linux driver and stealth where it uses the resources without
telling the kernel. Stealth/primary mode is a transition tool until
things get fixed. Once everything is sorted out stealth mode can be
removed.

Think of this as having the shared resource platform code in the DRM
driver. This shared platform knows how to load DRM. The next step is
to teach it how to load fbcon. Final step is to integrate the chip
specific code from DRM and fbdev.

I believe this method is less disruptive that simultaneously tearing
up vesafb, fbdev and DRM. The end result will be the same.



-- 
Jon Smirl
jonsmirl@gmail.com

Re: radeon-pre-2

[Christoph Hellwig]

On Sat, Sep 11, 2004 at 12:11:13PM -0400, Jon Smirl wrote:
> The resource reservation conflicts are already solved in the current
> DRM code. Most of the changes are in kernel and the rest are in the
> pipeline.  DRM loads in two modes, primary where it behaves like a
> normal Linux driver and stealth where it uses the resources without
> telling the kernel. Stealth/primary mode is a transition tool until
> things get fixed. Once everything is sorted out stealth mode can be
> removed.

Not, it's not been solved.  You hacked around the most common symptoms.

Re: radeon-pre-2

[Linus Torvalds]

On Sat, 11 Sep 2004, Jon Smirl wrote:
>
> The resource reservation conflicts are already solved in the current
> DRM code. Most of the changes are in kernel and the rest are in the
> pipeline.  DRM loads in two modes, primary where it behaves like a
> normal Linux driver and stealth where it uses the resources without
> telling the kernel. Stealth/primary mode is a transition tool until
> things get fixed. Once everything is sorted out stealth mode can be
> removed.

I _think_ Alan's argument is that this isn't about the resource 
reservation conflicts. In many ways resource reservations don't much
matter, since for PCI devices the kernel can (and does) make sure that 
nobody else stomps on that particular IO range anyway.

So to some degree the real issue is not so much about who "owns" the 
device: clearly nobody _can_ "own" it, as there are multiple drivers that 
do want to access it. So the real issue is about how to serialize the 
existing multiple "owners".

At least this is where I _think_ Alan is coming from. You're been an 
argumentative bunch, it's hard to tell in between all the flamage ;)

> Think of this as having the shared resource platform code in the DRM
> driver. This shared platform knows how to load DRM. The next step is
> to teach it how to load fbcon. Final step is to integrate the chip
> specific code from DRM and fbdev.

Again, I think you're thinking about the problem from two fundamentally 
different standpoints. 

Jon, you want to get to that "Final step is to integrate the chip specific
code from DRM and fbdev". Alan doesn't even want to get there. I think 
Alan just wants some simple infrastructure to let everybody play together.

(Hey, at this point everybody will jump at me and tell me I'm taking
lessons from Hans, and that I'm totally misrepresenting what people want.  
"Bring it on", as those stupid US politicians would say).

So look at this another way: maybe we do _not_ want to integrate any code. 
It's ok to have fbdev/fbcon/X/DRM all sharing the same device. The only 
thing we need is something to serialize the damn things with.

My personal preference for this whole mess has always been the "silly 
driver" that isn't even hardware-specific, and really does _nothing_ on 
its own. This one would be the only thing that actually reserves the IO 
regions and "owns" the card from the respect of the resources. EVERYBODY 
else would be a "stealth" driver. Not just DRM.

And the drivers would never become non-stealth. They'd stay as stealth 
drivers, and just use the silly hardware-independent thing as a way to 
serialize themselves.

So what does the hw-independent thing need to do?

 - locking. This is the first-order problem, and maybe it never even needs 
   to go beyond this stage. If DRM can say "I want to own the 
   accelerator", and others will wait for it, then that's already a big 
   step forward.

   Implementation: have a data structure with <n> different pointers to
   locks, for each independent function you can think of that somebody
   would want exclusive access over. "accelerator" "modeswitch" 
   "framebuffer" "memory alloc" whatever.

   Now, the reason why these things are _pointers_ to locks rather than 
   locks themselves is that maybe some hardware ends up sharing resources 
   between these things (maybe "modeswitch" needs the accelerator to 
   work), and then they have to use the same lock. Fine - just make the
   pointer point to that lock. The hardware-independent part doesn't even 
   need to _know_ about this: it just sets up all <n> locks as being
   independent, and then the low-level drivers can move the lock pointers 
   around since _they_ know what the rules are.

   Or something like this.

 - memory allocation. Many of these issues really are generic, and once 
   you have the locking setup done, maybe you can have a generic memory
   allocation layer for splitting up AGP memory or whatever. See the 
   "dma_declare_coherent_memory()" interfaces that James Bottomley did for 
   some SCSI devices that have on-board memory that they want to let the 
   kernel allocate as DMA'able.

   In fact, maybe the existing _general_ dma_declare_coherent_memory() 
   interfaces can be enhanced enough that the drivers can just use that
   directly. See Documentation/DMA-API.txt for some docs (it's very 
   limited right now, because nobody _needs_ any more, but it already has 
   support for "if you can't find memory directly on the card, allocate
   some from system RAM instead" kind of operations).

Anyway, please stop the flamage. It all sounds like you're arguing across 
each other. Now you can flame me instead, but please try to direct the 
flamage to specific points so that I don't get the feeling that you're 
talking about something else..

		Linus

Re: radeon-pre-2

[Alan Cox]

On Sad, 2004-09-11 at 18:02, Linus Torvalds wrote:
> My personal preference for this whole mess has always been the "silly 
> driver" that isn't even hardware-specific, and really does _nothing_ on 
> its own. This one would be the only thing that actually reserves the IO 
> regions and "owns" the card from the respect of the resources. EVERYBODY 
> else would be a "stealth" driver. Not just DRM.

How do you plan to deal with hot plug. At the point the "silly driver"
(in my case this is the vga class driver) claims the PCI device and
propogates things onwards hotplug seems to work.

The second fun bit is that Jon is right that in some cases the fb driver
for a card may want to use the DRI layer if loaded - but only some and
only in a controlled manner. Sometimes the drivers want to co-operate
sometimes they just want to avoid beating each other senseless.

>    Now, the reason why these things are _pointers_ to locks rather than 
>    locks themselves is that maybe some hardware ends up sharing resources 
>    between these things (maybe "modeswitch" needs the accelerator to 

How do you deal with making sure the lock doesn't get freed and knowing
who needs it still ? I ended up with locks in the shared area itself
because I couldn't figure that one out ?

>  - memory allocation. Many of these issues really are generic, and once 
>    you have the locking setup done, maybe you can have a generic memory
>    allocation layer for splitting up AGP memory or whatever. See the 
>    "dma_declare_coherent_memory()" interfaces that James Bottomley did for 
>    some SCSI devices that have on-board memory that they want to let the 
>    kernel allocate as DMA'able.

I think allocation is genuinely a hard problem in the 3D card case. Some
devices have the most wonderful restrictions on layout that range
from "the frame buffer is here" to "I want 2Mb, 1Mb aligned within a 4Mb
range and you can free this stuff if you notify me but its not
textures". Multihead really makes this interesting and DRI itself
doesn't really address this problem either.

Linus let me run what I have now past you for comment (the code isnt
working yet since I've been having a fight with the class code)

The vga_class module registers itself as the owner of every VGA class
device on the PCI bus. The PCI layer duely gives it all the video
hotplug events.

On creation it creates a set of (currently 3) vga bus objects for each
card. So if we find say a Voodoo 3, we will create vga bus objects

		Voodoo 3 memory manager
		Voodoo 3 DRI
		Voodoo 3 Frame buffer 0

(for now. Quite possibly mode management is separate, maybe memory 
 manager eventually will or will not be)

and stick them onto global and per vga router lists.

vga_register_driver works like PCI register driver but also takes a 
"type" field and will attach to the appropriate one of the 3 objects,
detach on hotplug and all the rest as the base/* code provides.

When you attach or detach you get a notifier to the other members that
are loaded.

Finally there is a shared structure between the different vga bus
objects for each video card which allows you to find one function from
another (maybe the notifiers should pass these) and also a semaphore.

Re: radeon-pre-2

[Linus Torvalds]

On Sat, 11 Sep 2004, Alan Cox wrote:

> On Sad, 2004-09-11 at 18:02, Linus Torvalds wrote:
> > My personal preference for this whole mess has always been the "silly 
> > driver" that isn't even hardware-specific, and really does _nothing_ on 
> > its own. This one would be the only thing that actually reserves the IO 
> > regions and "owns" the card from the respect of the resources. EVERYBODY 
> > else would be a "stealth" driver. Not just DRM.
> 
> How do you plan to deal with hot plug. At the point the "silly driver"
> (in my case this is the vga class driver) claims the PCI device and
> propogates things onwards hotplug seems to work.

Since the users would have to use the locking methods, they'd all be
dependent on it, so it would either be compiled in, or "modprobe" would 
just automagically load it.

And yes, it would just attach directly to any VGA class device on PCI (and 
have some other way to detect any other kind of graphics devices).

If we make it small, simple and generic enough (serialization isn't really
a gfx-only thing), we could frigging attach it to _every_ device in the
system, at which point it doesn't even need to "attach" any more. It would 
just be there. That obviously requires that it really only do a _very_ 
generic set of minimal locks.

> The second fun bit is that Jon is right that in some cases the fb driver
> for a card may want to use the DRI layer if loaded - but only some and
> only in a controlled manner. Sometimes the drivers want to co-operate
> sometimes they just want to avoid beating each other senseless.

They can put whatever data they want in the shared data area (called
"gfx_data" in my previous pseudo-code-posting). They'd need to know about
each other if they want to cooperate, of course. The "silly driver" never 
uses the data area itself, really. It just contains a few predefined 
things, like the lock pointers, but the silly driver doesn't really even 
access them, it's up to the low-level drivers to pass in the proper lock 
to the silly driver.

> >    Now, the reason why these things are _pointers_ to locks rather than 
> >    locks themselves is that maybe some hardware ends up sharing resources 
> >    between these things (maybe "modeswitch" needs the accelerator to 
> 
> How do you deal with making sure the lock doesn't get freed and knowing
> who needs it still ? I ended up with locks in the shared area itself
> because I couldn't figure that one out ?

That's exactly what I would do. See the example I sent out.

> Linus let me run what I have now past you for comment (the code isnt
> working yet since I've been having a fight with the class code)

Please realize that I have not a _frigging_ clue what I'm talking about. 
I'm just listening in to the flame war, and throwing out suggestions in 
the middle to try to get the discussion going _forward_. I hate seeing 
hundreds of emails in my mailbox that don't seem to actually make any 
_progress_.

So my comments are likely worthless.

		Linus

Re: radeon-pre-2

[Jon Smirl]

Coprocessor 3D mode is deeply pipelined
2D mode is immediate

How can you build a system that process swaps between these two modes?
The 3D pipeline has to be emptied before you can enter 2D immediate
mode.

My solution is to leave the coprocessor always running and convert
everything to use the DMA based commands.

Re: radeon-pre-2

[Alan Cox]

On Sad, 2004-09-11 at 18:13, Jon Smirl wrote:
> Coprocessor 3D mode is deeply pipelined
> 2D mode is immediate

Card dependant.

> How can you build a system that process swaps between these two modes?
> The 3D pipeline has to be emptied before you can enter 2D immediate
> mode.
> My solution is to leave the coprocessor always running and convert
> everything to use the DMA based commands.

On such a card when DRI is available that is probably the right path,
especially if it has the "can't software touch the frame buffer while
the engine runs" design flaw.

If DRI isn't loaded, or isn't running you can carry on unaccelerated.

Re: radeon-pre-2

[Linus Torvalds]

On Sat, 11 Sep 2004, Jon Smirl wrote:
>
> Coprocessor 3D mode is deeply pipelined
> 2D mode is immediate

Now it is _you_ who confuse "3D mode" and "2D mode".

THERE IS NO SUCH THING.

There is only hardware.

> How can you build a system that process swaps between these two modes?

You don't switch between the two non-existent modes. You serialize on 
hardware accesses.

If the 2D graphics driver uses the accelerator, it takes the accelerator 
lock.

If the 2D graphics just uses the framebufferm it takes the framebuffer 
lock.

If there are hardware dependencies on the accelerator and the framebuffer, 
then the two lock pointers point to the same lock.

The locks themselves need to have a release mechanism, of course, the same 
way we already have "stateful" locks for X interactions where something 
needs to be done when a lock is given to another person. So the locks 
can't just be regular spinlocks or semaphores, they need to be slightly 
more complicated things where each user has an "ID" cookie.

This way:
 - the hardware-independent part really _is_ hardware-independent. It 
   literally hass _no_ clue what the different users do.
 - the hardware-independent part makes no policy at all. It just has a set 
   of lock pointers, and a generic locking mechanism which basically looks 
   something like

	/*
	 * Generic "release lock"
	 */
	typedef struct release_lock_struct {
		struct semaphore sem;
		void *cookie;
		void (*releasefn)(release_lock_t *, void *);
	} release_lock_t;

	/*
	 * get a lock. Return 1 if the resource had been owned by
	 * somebody else in the meantime. We may need to re-initialize
	 * hw state if so..
	 *
	 * Otherwise, just return 0, to let the caller know that it
	 * didn't have anybody else screw with its state in between.
	 *
	 * (The caller could just keep this information by tracking
	 * it's "releasefn()" calls, of course, since if another
	 * locker came in, we would have asked it to release the
	 * info. The return value is just a convenient interface).
	 */
	int get_lock(release_lock_t *lock, void *cookie,
		     void (*releasefn)(release_lock_t *, void *))
	{
		down(lock->sem);

		/* Same old owner? Coolio.. */
		if (lock->cookie == cookie)
			return 0;

		/* Tell the previous lock owner to clean up */
		lock->releasefn(lock, lock->cookie);

		/* We now have a new owner */
		lock->releasefn = releasefn;
		lock->cookie = cookie;
		return 1;
	}
		

	/*
	 * Release the lock
	 */
	void put_lock(release_lock_t *lock, void *cookie)
	{
		/*
		 * People screw up all the time. Only let the owner
		 * release the lock. Complain loudly when somebody gets
		 * mixed up.
		 */
		BUG_ON(lock->cookie != cookie);
		up(lock->sem);
	}

Notice? There's _zero_ hardware knowledge here. This can work for 
video-cards, but it can work for anything else too.

And yes, maybe you need more complicated locks than the above, but hey,
they probably don't need to be _much_ more complicated.

So how would you use the above? Just combine it with the "graphics 
subsystem" specific list of locks, which you attach to each device some 
way (so that each driver that _shares_ the hardware device can find it):

	struct gfx_lock_ptr {
		release_lock_t *accelerator;
		release_lock_t *framebuffer;
		release_lock_t *memorymanager;
		..
	};

	struct gfx_data {
		struct gfx_lock_ptr ptr;
		release_lock_t locks[MAXLOCKS];
	};

and then the code just does

 - hw-independent gfx code initializes the locks to defaults:

	gfx_data->ptr.accelerator = gfx_data->locks + 0;
	gfx_data->ptr.framebuffer = gfx_data->locks + 1;
	gfx_data->ptr.memorymanager = gfx_data->locks + 2;
	...
	dev->gfx_data = gfx_data;

 - the _low_level_ drivers at their initialization will know what hardware 
   structures are shared, so they do (when _they_ init, and notice how 
   this doesn't actually matter in which order they loaded - they can both
   do this thing without knowing about each other):

	/* This chip can't access the frame buffer when the accelerator is busy */
	gfx_data->ptr.accelerator = gfx_data->ptr.framebuffer;

 - then the low-level drivers just do

	/* execute command */
	if (get_lock(gfx_data->ptr.accelerator, mydev, myrelease)) {
		/*
		 * Somebody else used the accelerator earlier, need to
		 * re-load my cached pointers:
		 */
		mydev->offset = readl(command_buffer + CMD_OFFSET);
	}
	WRITE_RING(mydev, cmd);
	WRITE_RING(mydev, arg);
	put_lock(gfx_data->ptr.accelerator, mydev);

 - and then the "myrelease" function just does whatever writer-side 
   synchronization needed (wait for commands to flush, for example).

Do I know what the hell I'm talking abut? No. You should see the above as 
a very quick "this _kind_ of approach should work", and work out the 
details. But I really think something like the above would be quite 
doable. No?

And yes, it requires changes to _both_ DRM and to fbcon, but the changes
are hopefully fairly independent, and it doesn't really require that they
share any fundamental code - it only requires a fbcon driver and a DRM
driver for the same hardware to agree on an use some _very_ simple
serialization.

			Linus

Re: radeon-pre-2

[Michel Dänzer]

On Sat, 2004-09-11 at 13:13 -0400, Jon Smirl wrote:
> Coprocessor 3D mode is deeply pipelined
> 2D mode is immediate

Have you looked at the radeon X driver acceleration code in the last
couple of years?


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer

Re: radeon-pre-2

[Eric Anholt]

On Sat, 2004-09-11 at 10:13, Jon Smirl wrote:
> Coprocessor 3D mode is deeply pipelined
> 2D mode is immediate
> 
> How can you build a system that process swaps between these two modes?
> The 3D pipeline has to be emptied before you can enter 2D immediate
> mode.
> 
> My solution is to leave the coprocessor always running and convert
> everything to use the DMA based commands.

Now, I'll admit that I've only really worked on three sets of hardware
(SiS 300-series, Radeon, Rage 128), but they don't have any "3d mode"
and "2d mode" concept.  On SiS both 3d and 2d go through a FIFO, so for
switching between clients you just have to check how much free space
there is in the fifo.  For Radeon and Rage 128 you can send rendering
commands either through the CP/CCE (DMA) or an MMIO FIFO.  You can do 2d
and 3d commands both ways.  In fact, you can send DMA commands through
an MMIO aperture as well.  But there is nothing "immediate" about 2d. 
It goes through the FIFO or the CP just like 3d rendering.  If I'm not
mistaken about other hardware I've poked at (3dfx, mach64), they don't
have any "2d mode" and "3d mode" either.

To summarize, there is no "2d mode" and "3d mode."  Please stop
referring to it.  If you were actually trying to talk about
synchronization for MMIO vs DMA command submission (which is and would
be a very rare case anyway), well, I don't see why that can't be done
using Linus' example, which seemed like what Alan Cox has been driving
toward for a long time.

If you want to avoid idling to switch from DMA to MMIO in that rare
case, then have whatever client in question write all commands into a
DMA buffer, then dispatch it through either the DRM or decoding into
MMIO writes.  Xati is an example of doing just that, and it's not that
hard.   Or, you could go the route that the XFree86 X Server has and
just have two sets of your acceleration functions, generated through
macros, which write to MMIO or write DMA buffers depending on which has
been set up.

But I see nothing in this issue that requires all the drivers live in
one module together, which would only make life a little more convenient
for some developers, at the expense of all the users who don't want all
of those drivers necessarily.

-- 
Eric Anholt                                eta@lclark.edu          
http://people.freebsd.org/~anholt/         anholt@FreeBSD.org

Re: radeon-pre-2

[Jon Smirl]

On Sat, 11 Sep 2004 13:29:33 -0700, Eric Anholt <eta@lclark.edu> wrote:
> To summarize, there is no "2d mode" and "3d mode."  Please stop
> referring to it.  If you were actually trying to talk about
> synchronization for MMIO vs DMA command submission (which is and would

You are right on all of this, I'm just using 2D and 3D as shorthand
for GPU coprocessor/DMA vs CPU/registers. Don't take this as literally
meaning 2D vs 3D.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: radeon-pre-2

[Jon Smirl]

On Sat, 11 Sep 2004 10:02:57 -0700 (PDT), Linus Torvalds
<torvalds@osdl.org> wrote:
> Jon, you want to get to that "Final step is to integrate the chip specific
> code from DRM and fbdev". Alan doesn't even want to get there. I think
> Alan just wants some simple infrastructure to let everybody play together.

This is the core problem. I want to get to a point where there is a
single, integrated piece of code controlling the complex functions of
the 3D hardware.

I want to get away from the model of "I just got control of the chip,
who knows what the state of it is, I better reset everything". I also
want to get away from "now I want to use this register, i need to
inspect every over driver and piece of user space code to make sure
they don't stomp it". Or "I didn't even know your code existed, sorry
about stomping that critical register and causing 100 bug reports". Or
"why don't we just split the VRAM in half so we don't have to share
memory management".  Or suspend code that restores 2D mode and ignores
3D.

The problem with everyone playing together in separate code bases
assumes that everyone knows what everyone else is doing and that's
never the case. A single card specific code base collects everything
to a single place where it can be monitored.

A good example of this is switching the GPU between 2D and 3D mode on
every process swap.

In general the current X design only has a single 3D client. With a
composited display and pbuffer background drawing we are going to have
one 3D client for every top level window. This is going to require
complicated code to smoothly multitask the 3D drawing streams. The
last thing we need is something in the middle of this switching the
chip in and out of 2D mode.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: radeon-pre-2

[Linus Torvalds]

On Sat, 11 Sep 2004, Jon Smirl wrote:

> On Sat, 11 Sep 2004 10:02:57 -0700 (PDT), Linus Torvalds
> <torvalds@osdl.org> wrote:
> > Jon, you want to get to that "Final step is to integrate the chip specific
> > code from DRM and fbdev". Alan doesn't even want to get there. I think
> > Alan just wants some simple infrastructure to let everybody play together.
> 
> This is the core problem. I want to get to a point where there is a
> single, integrated piece of code controlling the complex functions of
> the 3D hardware.

I think you can get there without having to merge the two.

How about just accepting the fact that there might be other people 
accessing your hardware, and then trying to make it _rare_?

> I want to get away from the model of "I just got control of the chip,
> who knows what the state of it is, I better reset everything". I also
> want to get away from "now I want to use this register, i need to
> inspect every over driver and piece of user space code to make sure
> they don't stomp it". Or "I didn't even know your code existed, sorry
> about stomping that critical register and causing 100 bug reports". Or
> "why don't we just split the VRAM in half so we don't have to share
> memory management".  Or suspend code that restores 2D mode and ignores
> 3D.

Well, what _I_ want to get away from is a "I'm the only game in town" 
mentality. 

I want people to be able to play with other things, without having one 
driver that has to know about it all. I also want to avoid flag-days, ie 
I'd like to be able to have a gradual transition.

And I don't think your model really has the option for a gradual 
transition, and other people doing their thing. 

So I'd much rather see the "hey, somebody else might have stolen my 
hardware, and now I need to re-initialize" as the _basic_ model. That just 
allows others to do their own thing, and play well together. More 
importantly, it allows the existing status quo, which means that if we 
take that as the basic approach, we _never_ have to make a complete flag 
day when we switch over to "_this_ driver does everything". See?

HOWEVER, I do realize that that is horribly inefficient as a common thing
to happen, which is why I have the cunning plan (always steal good ideas 
from others and call them "your" cunning plans) to have the locking that 
allows for caching over locks. That means that _if_ you get to the point 
where your driver does everything, you'll never really have to worry about 
performance, because you'll never see the bad cases.

Or maybe you'll only see the bad cases when the kernel oopses, and decides 
that it _has_ to write to the screen and screw your model. See what I'm 
saying? Having a model that allows for that is a _good_ thing.

And you can do it. Basically, if you build on top of the "silly driver"  
locks, your DRM layer would have _one_ cookie (per hw device, of course)
that it ever uses, and it would point to your basic device descriptor. 
You'd then do the X cookies within that decide descriptor, ie they'd never 
change the "silly driver" cookie, and thus you'd never see a "conflict". 
You'd take care of the existing DRM locking methods yourself, you wouldn't 
try to shoe-horn them into the silly driver locks.

So what I'm saying is that you _can_ get to your ideal world, without 
taking the option away from others to decide that they prefer having two 
(or three, or fifteen) drivers all accessing the same hardware. For 
example, the single-driver approach might be good for some hadrware. It 
might not be so good for others (think vendor drivers etc).

> A good example of this is switching the GPU between 2D and 3D mode on
> every process swap.
> 
> In general the current X design only has a single 3D client. With a
> composited display and pbuffer background drawing we are going to have
> one 3D client for every top level window.

But if you make your DRM thing be the "master" of these different 3D
client contexts, then you _can_ handle that without ever having to lose
your "hardware lock". See what I'm saying? You do two-level locking:

 - the "hardware level" is the silly driver one. It's the one that allows 
   multiple kinds of subsystems to play together, be it DRM of fbcon. When 
   you get a "release event" for this one, you basically have to serialize
   _everything_, because this level of release means that you literally
   don't know what happened (with the exception of mode switching, I 
   really think that one has to be a totally separate class of events).

 - you have your _own_ "DRM level" context lock, which is the one the 3D 
   clients from X actually interface to. That one also has to reset _some_ 
   client state, of course, when you switch between clients, but now it's
   only state that _you_ know about.

You can have your cake and eat it too. I don't think these things are 
incompatible.

		Linus

Re: radeon-pre-2

[Jon Smirl]

Alan, if you will commit Redhat to implementing all of the features
referenced in this message:
http://lkml.org/lkml/2004/8/2/111
then I'll back off and go work on the X server.

Use whatever mechanism you want, but implement all of the features. 

There are two main goals:

#1) Get mesa-solo running with superbuffers, this means memory
allocation and mode setting have to be fixed. This will be the base
platform for X on GL.

#2) Support independent users logged into each head. One using the
console with fbdev and the other X and a 3D game.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: radeon-pre-2

[Christoph Hellwig]

On Sat, Sep 11, 2004 at 05:02:36PM -0400, Jon Smirl wrote:
> Alan, if you will commit Redhat to implementing all of the features
> referenced in this message:

You definitly start sounding like Hans ;-)

Re: radeon-pre-2

[Jon Smirl]

On Sat, 11 Sep 2004 22:06:14 +0100, Christoph Hellwig <hch@infradead.org> wrote:
> On Sat, Sep 11, 2004 at 05:02:36PM -0400, Jon Smirl wrote:
> > Alan, if you will commit Redhat to implementing all of the features
> > referenced in this message:
> 
> You definitly start sounding like Hans ;-)

Getting the Linux display subsystem to a point where it can compete
with Longhorn/Mac is a very complicated problem. It is going to take
several years of work and the cooperation of a lot of people. It's a
pyramid problem with lot's of layers.

Of course Linux can choose not to build a display system based on 3D
hardware. But I've seen the
current Longhorn/Mac implementations and they are way, way better than
X. If Linux ignores 3D mode it is going to be very visible on the
desktop.

I've tried to follow the Linux model for proposing the changes. The
plan has been circulated to all relevant lists: fbdev, dri, xorg, lkml
for over six months. Three sessions at OLS talked about various parts
of the plan. Nothing has been kept secret, there must be 5,000
messages in the archive on this subject.

But since I've written most of the code so far I get to pick the
details of the implementation. If Alan would instead like to pick the
details I've offered to withdraw if he'll write the code needed to
implement the major points of the plan. Of course if Redhat wants to
send me a check for a couple of hundred thousand dollars I'll write
whatever they want, but they haven't done that.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: radeon-pre-2

[Alan Cox]

On Sad, 2004-09-11 at 22:37, Jon Smirl wrote:
> But since I've written most of the code so far I get to pick the
> details of the implementation. 

Umm thats what happened to ruby and thats what happened to KGI.

> If Alan would instead like to pick the
> details I've offered to withdraw if he'll write the code needed to
> implement the major points of the plan.

I'll try and debug the vga generic (Linus "stupid" driver as he calls
it). That'll provide the framework to plug the other bits in. That needs
doing anyway to get hotplugging and all the other sane stuff right (oh
and probably sysfs but someone else can do that).

I was using much simpler lock ideas than Linus but I'll have a poke at
that too, something more like a dri lock that knows who had it last.

Alan

Re: radeon-pre-2

[Eric Anholt]

On Sat, 2004-09-11 at 14:37, Jon Smirl wrote: 
> On Sat, 11 Sep 2004 22:06:14 +0100, Christoph Hellwig <hch@infradead.org> wrote:
> > On Sat, Sep 11, 2004 at 05:02:36PM -0400, Jon Smirl wrote:
> > > Alan, if you will commit Redhat to implementing all of the features
> > > referenced in this message:
> > 
> > You definitly start sounding like Hans ;-)
> 
> Getting the Linux display subsystem to a point where it can compete
> with Longhorn/Mac is a very complicated problem. It is going to take
> several years of work and the cooperation of a lot of people. It's a
> pyramid problem with lot's of layers.
> 
> Of course Linux can choose not to build a display system based on 3D
> hardware. But I've seen the
> current Longhorn/Mac implementations and they are way, way better than
> X. If Linux ignores 3D mode it is going to be very visible on the
> desktop.
> 
> I've tried to follow the Linux model for proposing the changes. The
> plan has been circulated to all relevant lists: fbdev, dri, xorg, lkml
> for over six months. Three sessions at OLS talked about various parts
> of the plan. Nothing has been kept secret, there must be 5,000
> messages in the archive on this subject.
> 
> But since I've written most of the code so far I get to pick the
> details of the implementation. If Alan would instead like to pick the
> details I've offered to withdraw if he'll write the code needed to
> implement the major points of the plan. Of course if Redhat wants to
> send me a check for a couple of hundred thousand dollars I'll write
> whatever they want, but they haven't done that.

I don't see what longhorn and quartz have to do with the question at
hand (this plan to cram FB and DRM together).

If we want to do the pretty graphics things that these improvements to
graphics on other OSes have done, we don't need to touch FB at all.  We
already have X Servers with the composite extension.  We've got a vector
graphics library.  Now we need to make those go fast.  We can do the
go-faster part within the X Server and the vector graphics library
without touching the DRM, FB, or anyone else.  I'm spending far too much
of my free time currently working on this.

Now, another good project is to get our 3d drivers to the point that we
could write our X Server on top of that.  Basically, we need pbuffer
support for that.  That'll touch the DRM and client drivers (and our
current X Servers, though that part wouldn't be used in the X-on-GL
model).  Again, not FB.

A completely separate issue is how to arrange for synchronization
between the multiple users of the graphics hardware on linux.  I think a
pretty decent model has been proposed by the Linux kernel people, and it
seems rather simple.  FreeBSD is happy with it because it doesn't affect
us in any way.  (When we get around to dealing with the issue (if ever),
i.e. when we've got accelerated graphics layers for console, I'm quite
sure we'll follow the same model of a relatively generic lock in the
kernel which all graphics clients will use to arbitrate hardware
access).

Please, stop trotting out Longhorn and Quartz to justify whatever you're
trying to push into the kernel.

-- 
Eric Anholt                                eta@lclark.edu          
http://people.freebsd.org/~anholt/         anholt@FreeBSD.org

Re: radeon-pre-2

[Jon Smirl]

On Sat, 11 Sep 2004 11:13:17 -0700 (PDT), Linus Torvalds
<torvalds@osdl.org> wrote:
> So I'd much rather see the "hey, somebody else might have stolen my
> hardware, and now I need to re-initialize" as the _basic_ model. That just
> allows others to do their own thing, and play well together. More
> importantly, it allows the existing status quo, which means that if we
> take that as the basic approach, we _never_ have to make a complete flag
> day when we switch over to "_this_ driver does everything". See?

We already have a mechanism for this: suspend/resume. The downside to
this approach is that after I get a resume I have to rebuild the
hardware state. It takes a while to rebuild half a gig of graphics
state but this model will provide the required isolation.

> HOWEVER, I do realize that that is horribly inefficient as a common thing
> to happen, which is why I have the cunning plan (always steal good ideas
> from others and call them "your" cunning plans) to have the locking that
> allows for caching over locks. That means that _if_ you get to the point
> where your driver does everything, you'll never really have to worry about
> performance, because you'll never see the bad cases.

suspend/resume will address this too. On VT switch DRM would receive a
suspend command and fbdev a resume, then vice versa on the way back.
We will have to build a scheme for assigning a driver to each VT. A
general mechanism would extend this beyond the video drivers.

This is implementing device driver multitasking something I didn't
want to do. I never said it wouldn't work, I just didn't want to do
it. I thought the complexity/performance trade offs weren't worth it.

> 
> Or maybe you'll only see the bad cases when the kernel oopses, and decides
> that it _has_ to write to the screen and screw your model. See what I'm
> saying? Having a model that allows for that is a _good_ thing.
> 
> And you can do it. Basically, if you build on top of the "silly driver"
> locks, your DRM layer would have _one_ cookie (per hw device, of course)
> that it ever uses, and it would point to your basic device descriptor.
> You'd then do the X cookies within that decide descriptor, ie they'd never
> change the "silly driver" cookie, and thus you'd never see a "conflict".
> You'd take care of the existing DRM locking methods yourself, you wouldn't
> try to shoe-horn them into the silly driver locks.
> 
> So what I'm saying is that you _can_ get to your ideal world, without
> taking the option away from others to decide that they prefer having two
> (or three, or fifteen) drivers all accessing the same hardware. For
> example, the single-driver approach might be good for some hadrware. It
> might not be so good for others (think vendor drivers etc).

Why do we have fifteen video drivers for the radeon and only one for
each SCSI card? Could it be that the SCSI drivers are well designed
and do everything needed, thus removing the incentive for most people
to write new ones? If we had a good, standardized library for
accessing accelerated drawing functions people might stop rewriting
the video drivers. I'd rather spend my effort trying to build a good
library rather than building sandboxes to keep fifteen partial
libraries from interfering.

> > A good example of this is switching the GPU between 2D and 3D mode on
> > every process swap.
> >
> > In general the current X design only has a single 3D client. With a
> > composited display and pbuffer background drawing we are going to have
> > one 3D client for every top level window.
> 
> But if you make your DRM thing be the "master" of these different 3D
> client contexts, then you _can_ handle that without ever having to lose
> your "hardware lock". See what I'm saying? You do two-level locking:
> 
>  - the "hardware level" is the silly driver one. It's the one that allows
>    multiple kinds of subsystems to play together, be it DRM of fbcon. When
>    you get a "release event" for this one, you basically have to serialize
>    _everything_, because this level of release means that you literally
>    don't know what happened (with the exception of mode switching, I
>    really think that one has to be a totally separate class of events).

You almost said resume - "release event" was real close.

>  - you have your _own_ "DRM level" context lock, which is the one the 3D
>    clients from X actually interface to. That one also has to reset _some_
>    client state, of course, when you switch between clients, but now it's
>    only state that _you_ know about.
> 
> You can have your cake and eat it too. I don't think these things are
> incompatible.

Build the sandboxes and then let everyone play.

> 
>                 Linus
> 



-- 
Jon Smirl
jonsmirl@gmail.com

Re: radeon-pre-2

[Linus Torvalds]

On Sat, 11 Sep 2004, Jon Smirl wrote:

> On Sat, 11 Sep 2004 11:13:17 -0700 (PDT), Linus Torvalds
> <torvalds@osdl.org> wrote:
> > So I'd much rather see the "hey, somebody else might have stolen my
> > hardware, and now I need to re-initialize" as the _basic_ model. That just
> > allows others to do their own thing, and play well together. More
> > importantly, it allows the existing status quo, which means that if we
> > take that as the basic approach, we _never_ have to make a complete flag
> > day when we switch over to "_this_ driver does everything". See?
> 
> We already have a mechanism for this: suspend/resume.

Jon, you're not making sense any more.

This discussion is just ridiculous, and I don't think it's worth cc'ing me 
if people can't try to work together, since I'm sadly not going to have 
time to actually implement any of this myself.

If you are claiming that we should suspend/resume the whole chip just 
because two different programs want to access it, you're just crazy. 

We clearly _do_ have different subsystems already working together 
accessign the same chip, and they are _not_ doing stupid things like you 
are suggesting. They _work_. Today. No suspend/resume involved.

That interaction has some troubles, and we're trying to _fix_ them. We're 
not trying to make idiotic statments.

Yours was a singularly idiotic statment.

		Linus

Re: radeon-pre-2

[Dave Airlie]

> >
> > We already have a mechanism for this: suspend/resume.
>
> Jon, you're not making sense any more.

> This discussion is just ridiculous, and I don't think it's worth cc'ing me
> if people can't try to work together, since I'm sadly not going to have
> time to actually implement any of this myself.
>
> If you are claiming that we should suspend/resume the whole chip just
> because two different programs want to access it, you're just crazy.
>
> We clearly _do_ have different subsystems already working together
> accessign the same chip, and they are _not_ doing stupid things like you
> are suggesting. They _work_. Today. No suspend/resume involved.

I think you are missing Jon's point here, we do complete suspend/resume
nowdays, just look at the radeon DDX Enter/Leave VT code, now I don't
particularly want that code in the kernel, it assumes nothing about the
chip after you switch back to X and restores the whole lot.. so we are
doing this today, they work because of that code, the DRM doesn't do
anything unless X is running in most scenarios today, so the DRM and fb
never do anything that simulatenous that you might notice as when you
switch away from X the drm is locked against working, and the fb can take
over, in the future this isn't going to be true, the mesa-solo work being
one case where fb and drm are going to be accessed from the one
process....

So his statement didn't seem that idiotic to me... he might have explained
himself better, and may have assumed everyone understands the internals of
the X DDXes,

Dave.


-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

Re: radeon-pre-2

[Vladimir Dergachev]

On Sat, 11 Sep 2004, Jon Smirl wrote:

> On Sat, 11 Sep 2004 10:02:57 -0700 (PDT), Linus Torvalds
> <torvalds@osdl.org> wrote:
>> Jon, you want to get to that "Final step is to integrate the chip specific
>> code from DRM and fbdev". Alan doesn't even want to get there. I think
>> Alan just wants some simple infrastructure to let everybody play together.
>
> This is the core problem. I want to get to a point where there is a
> single, integrated piece of code controlling the complex functions of
> the 3D hardware.

Jon,

   Alan did have a valid point about the current size of DRM driver.

   Would it not be possible to separate parts that assist 3d acceleration -
like DRM ioctls to submit textures etc and the code to validate the 
command stream submitted from userspace ? This should cut down the size
considerably.

                               best

                                  Vladimir Dergachev

>
> I want to get away from the model of "I just got control of the chip,
> who knows what the state of it is, I better reset everything". I also
> want to get away from "now I want to use this register, i need to
> inspect every over driver and piece of user space code to make sure
> they don't stomp it". Or "I didn't even know your code existed, sorry
> about stomping that critical register and causing 100 bug reports". Or
> "why don't we just split the VRAM in half so we don't have to share
> memory management".  Or suspend code that restores 2D mode and ignores
> 3D.
>
> The problem with everyone playing together in separate code bases
> assumes that everyone knows what everyone else is doing and that's
> never the case. A single card specific code base collects everything
> to a single place where it can be monitored.
>
> A good example of this is switching the GPU between 2D and 3D mode on
> every process swap.
>
> In general the current X design only has a single 3D client. With a
> composited display and pbuffer background drawing we are going to have
> one 3D client for every top level window. This is going to require
> complicated code to smoothly multitask the 3D drawing streams. The
> last thing we need is something in the middle of this switching the
> chip in and out of 2D mode.
>
> -- 
> Jon Smirl
> jonsmirl@gmail.com
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>

Re: radeon-pre-2

[Alan Cox]

PS: Don't get me wrong - we have to address the main points on that list
(the ones on the list not in your head). The last thing I want to see is
another person march off into the distance with a framebuffer agenda and
a lack of understanding about the importance of getting
from where we are now to where we want to be without breaking anything
major and without leaving everyone else behind or going a different
way.

Thats happened at least twice before in the console world because people
didn't get it. Kgi is one case, ruby is another.

Alan

Re: radeon-pre-2

[Jon Smirl]

The current DRM code doesn't suffer from resource conflicts anymore.
DRM now supports two modes: primary and stealth. In primary mode DRM
behaves like a Linux device driver should, it attaches to it's PCI
IDs, claims it's resources, registers with sysfs, generates hotplug
events, etc.

On the other hand, if vesafb or fbdev are loaded they will be attached
to all of the resources. DRM is blocked now, it can't load and attach
to things like a normal driver. In this case the DRM code reverts to
stealth mode.  Since vesa/fbdev is already attached to the DRM PCI IDs
DRM can't directly attach. Instead the module init code searches the
pci bus for DRM hardware. If DRM finds it's hardware DRM will install
itself and function without informing the kernel that it is there.

Before every one blows up and says how stupid this is, stealth mode
came first, it's what DRM originally did. It's the primary mode code
that is new. Over time the plan is to give DRM the ability to do
take_over_console() and handle printk's. DRM will also gain mode
setting capabilities. Once these capabilities are added the need for a
standalone fbdev will be eliminated. You will still have all of the
fbdev features, they will just be coming out of the integrated code
base, not separate drivers. This is not an attempt to build a new
fbdev, the existing fbdev code is simply being reused and modified to
work in conjunction with DRM.

Stealth and primary mode are transition tools. Once DRM subsumes fbdev
capabilities stealth mode will not be needed anymore and can be
removed.

This is a different strategy than building a base driver that claims
the resources and then loads vesafb, fbdev and DRM on top of the base.
The stealth mode scheme is a smoother transition to coordinating the
video drivers since it doesn't require a simultaneous change to all of
the video drivers. Stealth/primary mode in DRM is already implemented
and tested. Parts of it are already in the kernel and the rest is in
the pipeline.

On Fri, 10 Sep 2004 23:04:56 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Gwe, 2004-09-10 at 14:31, Felix Kühling wrote:
> > The first region (frame buffer and apperture) is claimed (partially) by
> > vesafb, the second one (MMIO registers) is not claimed at all. I don't
> > see an obvious way to fix this.
> 
> Its already fixed in the stuff I'm working on. Given the list of all
> video devices its simply a matter of taking the mmio address and seeing
> who owns it. That gives you the PCI device so you now know what the VESA
> console is Linux pci_device terms. At that point VESA is attachable to
> the PCI device and so it can veto DRI attaches.
> 
> I've not addressed what occurs if you get an answer in the ISA window
> because for VESA2 allocations I don't think it can occur. If it does
> then Jon's code dealing with finding the live VGA route will handle it
> for most boxes. (Anyone using VESA video on an IBM summit can fix it
> themselves).
> 
> Alan
> 



-- 
Jon Smirl
jonsmirl@gmail.com