sysdev_class use from DRM

sysdev_class use from DRM

[Jon Smirl]

DRM has a model where it runs without attaching to the PCI device. It
is doing this because the framebuffer devices are already attached to
the device.

Some developers want to add power manager support to the DRM drivers.
Since the normal pm hooks are occupied they are doing this by creating
a sysdev_class.

static struct sysdev_class drm_sysdev_class = {
	set_kset_name("drm"),
	.resume		= drm_resume,
	.suspend	= drm_suspend,
};

If I rmmod the modules before reboot I can reboot cleanly. But if the
modules are still loaded at reboot I get the following trap in sysdev.
I suspect this is because the kernel has already wiped out the
loadable drivers when sysdev shut down is happening.  Can anyone
explain what is happening?

I could unregister the sysdev device via _exitcall() but the kernel
doesn't call _exitcall() in current builds. Meanwhile it just occurred
to me to mark these routines and structures _exit, I'll try that while
wait for a reply to this.

Don't tell me to merge DRM/fbdev, that fight has been going on for two
years now.

-- 
Jon Smirl
jonsmirl@gmail.com


EIP:    0060:[<c01fc398>]    Not tainted VLI
EFLAGS: 00010246   (2.6.12)
EIP is at sysdev_shutdown+0xbd/0xd2
eax: 6b6b6b47   ebx: f9a904c0   ecx: 00000000   edx: 6b6b6b6b
esi: f9a904c0   edi: 6b6b6b47   ebp: f65e8e8c   esp: f65e8e7c
ds: 007b   es: 007b   ss: 0068
Process reboot (pid: 8899, threadinfoö5e8000 taskÁa7e520)
Stack: f9a904dc c03280fc c03281cc 4f51bff4 f65e8e9c c01ffa64 28121969 01234567
      f65e8fb4 c01272ce f7490d84 f7fa5180 00010800 f7fa5180 00000000 f65e8ed4
      c0140f08 f1ea4a5c f7f68d80 00030800 f7f68d80 00000000 f65e8f00 c0142321
Call Trace:
 [<c0103db8>] show_stack+0x7c/0x92
 [<c0103f39>] show_registers+0x152/0x1ca
 [<c0104136>] die+0xf4/0x16f
 [<c01140cb>] do_page_fault+0x42f/0x654
 [<c0103a2b>] error_code+0x4f/0x54
 [<c01ffa64>] device_shutdown+0x74/0x78
 [<c01272ce>] sys_reboot+0xf8/0x20f
 [<c0102e43>] sysenter_past_esp+0x54/0x75
Code: 8d 42 bc 89 c6 eb 86 f0 ff 05 64 82 32 c0 0f 8e 3f 02 00 00 83 c4 04 5b 5e
 5f 5d c3 8b 56 08 85 d2 75 17 8b 57 24 8d 42 dc 89 c7 <8b> 40 24 0f 18 00 90 3b
  55 f0 e9 77 ff ff ff 89 f8 ff d2 eb e3
INIT: no more processes left in this runlevel


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&opÌk
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: sysdev_class use from DRM

[Jon Smirl]

On 6/24/05, Jon Smirl <jonsmirl@gmail.com> wrote:
> If I rmmod the modules before reboot I can reboot cleanly. But if the
> modules are still loaded at reboot I get the following trap in sysdev.
> I suspect this is because the kernel has already wiped out the
> loadable drivers when sysdev shut down is happening.  Can anyone
> explain what is happening?

I found the problem. It is mandatory to have a shutdown function in
the sysdev class.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&opÌk
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: sysdev_class use from DRM

[Dmitry Torokhov]

On Friday 24 June 2005 09:12, Jon Smirl wrote:
> DRM has a model where it runs without attaching to the PCI device. It
> is doing this because the framebuffer devices are already attached to
> the device.
> 
> Some developers want to add power manager support to the DRM drivers.
> Since the normal pm hooks are occupied they are doing this by creating
> a sysdev_class.

Does DRM's PM needs interrupts to be off? If not you may try adding a 
platform device instead of a system device.

-- 
Dmitry


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: sysdev_class use from DRM

[Greg KH]

On Fri, Jun 24, 2005 at 10:12:19AM -0400, Jon Smirl wrote:
> DRM has a model where it runs without attaching to the PCI device. It
> is doing this because the framebuffer devices are already attached to
> the device.
> 
> Some developers want to add power manager support to the DRM drivers.
> Since the normal pm hooks are occupied they are doing this by creating
> a sysdev_class.
> 
> static struct sysdev_class drm_sysdev_class = {
> 	set_kset_name("drm"),
> 	.resume		= drm_resume,
> 	.suspend	= drm_suspend,
> };

Ick, don't do this, this is a hack.

If you really just want to catch the reboot, add a reboot notifier hook
to your driver.

> Don't tell me to merge DRM/fbdev, that fight has been going on for two
> years now.

Well, that's the only real way to fix this.  A simple single driver that
handles the pci registering and doles out the resources and callbacks to
the differnt DRM or fbdev driver is the way to go.  I thought you all
were working on this a year ago...

thanks,

greg k-h


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: sysdev_class use from DRM

[Jon Smirl]

On 6/30/05, Greg KH <greg@kroah.com> wrote:
> > Don't tell me to merge DRM/fbdev, that fight has been going on for two
> > years now.
> 
> Well, that's the only real way to fix this.  A simple single driver that
> handles the pci registering and doles out the resources and callbacks to
> the different DRM or fbdev driver is the way to go.  I thought you all
> were working on this a year ago...

Merging fbdev/DRM has a lot in common with removing devfs from the
kernel. There are numerous, vocal defenders of their rights to do
things the way they want to. There are also major defenders of the
right to hit a magic key (VT swap) and have a whole other set of
device drivers take over the hardware. Every time I think a merge is
going to happen somebody new shows up and it all falls apart.

The last round was that the fbdev drivers aren't well tested on the
x86 (they are on other architectures). My response was, let's get some
bug reports and fix the problems if there are any. Other people want
to create yet a third set of drivers which avoids use of the existing
fbdev ones.

My preference would be for Linus to refuse all patches from both fbdev
and DRM until a compromise is reached. I have wasted too much time
trying to get a merge to happen and I've switched to working around
the various problems.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&opÌk
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: sysdev_class use from DRM

[Greg KH]

On Thu, Jun 30, 2005 at 04:55:20PM -0400, Jon Smirl wrote:
> On 6/30/05, Greg KH <greg@kroah.com> wrote:
> > > Don't tell me to merge DRM/fbdev, that fight has been going on for two
> > > years now.
> > 
> > Well, that's the only real way to fix this.  A simple single driver that
> > handles the pci registering and doles out the resources and callbacks to
> > the different DRM or fbdev driver is the way to go.  I thought you all
> > were working on this a year ago...
> 
> Merging fbdev/DRM has a lot in common with removing devfs from the
> kernel. There are numerous, vocal defenders of their rights to do
> things the way they want to.

And like devfs, those people are wrong.

Seriously, they are, and need to get over it...

> There are also major defenders of the right to hit a magic key (VT
> swap) and have a whole other set of device drivers take over the
> hardware. Every time I think a merge is going to happen somebody new
> shows up and it all falls apart.

Why wouldn't having a "control the pci device" module not allow you to
do this?

> The last round was that the fbdev drivers aren't well tested on the
> x86 (they are on other architectures). My response was, let's get some
> bug reports and fix the problems if there are any. Other people want
> to create yet a third set of drivers which avoids use of the existing
> fbdev ones.

Bah, this sucks.

Last kernel summit I thought this was all hashed out.  I guess the
people not there didn't agree...

Hey, how about at KS/OLS we (anyone who cares about this) sit down and
hash it all out and produce code that does this?  With a working patch,
it should be simple to get it into the tree and then everyone can move
on.

I don't want to see any silly workarounds like what you are being forced
to do to happen.

thanks,

greg k-h


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: sysdev_class use from DRM

[Jon Smirl]

On 7/1/05, Greg KH <greg@kroah.com> wrote:
> Last kernel summit I thought this was all hashed out.  I guess the
> people not there didn't agree...

There are more layers to the problem. 

For example there is a bunch of redundant code between radeonDRM and
radeonfb. To make the embedded people happy things are set up so that
radeonfb can be run standalone and a merged radeonDRM can optionally
be loaded. Since radeonfb is always there you put all of the redundant
code into radeonfb, right?

But radeonDRM has shared source with BSD. The BSD people started
howling when I tried to remove the redundant code since they don't
have an radeonfb equivalent to put it into.

Then there is the pure architecture group. This group wants to define
a small layer that works as a multiplexer and let you plug fbdev and
DRM into it. This is a great idea if you have someone lined up to
modify 67 fbdev drivers on ten different platforms/archs.

Next is defense of backwards compatibility. Right now the rules of VT
swap are that after swap another driver can reset the card and wipe
it's memory, then when you VT swap back to the first driver it has to
gracefully recover all of it's state. This was fine where there were
14 VGA registers but now we have 500 registers and 256MB of video
memory. Trying to tamper with the rules of VT swap sets off major
screams from groups like DirectFB.

At a higher level the problem is tied into the Xserver. The server
community is split right now between the EXA group and Xgl. EXA
extends the current XAA model of doing almost every in user space and
having platform independent drivers. Xgl take the philosophy that the
OpenGL stack is the device driver and it can be as platform dependent
as it wants. Then the Xgl server which sits on top is platform
independent. This is really hurting because it is splitting our very
small number of driver developers.

There is still no agreement on the very basic concept of a single
driver being in charge of the hardware and other are subordinate to
it. I've also left out another dozen side arguments, like should mode
setting be in-kernel or out?

Another unsettled area is consoles and the kernel. If I put two
graphics cards in a system should I get two consoles with VT's? Right
now the kernel supports a single console, there is a 100K line patch
to make it support more than one. I think it is crazy to further the
current VT mess and I want to push console support into user space.
(there would still be an in-kernel emergency console with no VTs).

> Hey, how about at KS/OLS we (anyone who cares about this) sit down and
> hash it all out and produce code that does this?  With a working patch,
> it should be simple to get it into the tree and then everyone can move
> on.

I am still uncommitted to coming. We have a new set of eight month old
twins and I can't get permission to leave. The compromise may be to
bring the wife, twins and nanny.

This is not an easy area to get consensus on. You can get agreements
from small groups but when it expands the agreements fall apart. It
may require that someone like Linus bless a roadmap for video
development and then reject anything that is not on the roadmap. With
road we are on right now we are going to end up with ten different
half finished systems.

> I don't want to see any silly workarounds like what you are being forced
> to do to happen.
> 
> thanks,
> 
> greg k-h
> 


-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&opÌk
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: sysdev_class use from DRM

[Greg KH]

On Fri, Jul 01, 2005 at 07:18:08PM -0400, Jon Smirl wrote:
> On 7/1/05, Greg KH <greg@kroah.com> wrote:
> > Last kernel summit I thought this was all hashed out.  I guess the
> > people not there didn't agree...
> 
> There are more layers to the problem. 

{sigh}  there always is...

<good reasons snipped>

What about starting small, with just the pci driver functions, and going
on from there.  That way you all can still fight it out over the
different details, and I'll be happy that you play nice with the driver
core.  Something as simple as:

register_my_driver(struct pci_driver *drv)
{
	/* add drv to list of drivers that want to use this hardware */
}


struct pci_driver foo = {
	.owner = THIS_MODULE,
	.name = "foo_video_multiplexor",
	.id_table = all_foo_ids_combined,
	.probe = foo_probe,
	.suspend = foo_suspend,
	...
};

static int foo_probe(struct pci_dev *dev, id)
{
	for (all drivers registered with me)
		drv->probe(dev, id);
}

and so on...

That would be a good start...

> > Hey, how about at KS/OLS we (anyone who cares about this) sit down and
> > hash it all out and produce code that does this?  With a working patch,
> > it should be simple to get it into the tree and then everyone can move
> > on.
> 
> I am still uncommitted to coming. We have a new set of eight month old
> twins

Say no more.  I totally understand, don't worry about it, not a big
deal.

> and I can't get permission to leave.

If I was your wife, I wouldn't give you permission either :)

> This is not an easy area to get consensus on. You can get agreements
> from small groups but when it expands the agreements fall apart. It
> may require that someone like Linus bless a roadmap for video
> development and then reject anything that is not on the roadmap.

I thought we almost had that last year.  Did I miss something?

> With road we are on right now we are going to end up with ten
> different half finished systems.

Which I really don't want to see.

Want me to write up the above in real code for you all to use?  Anything
else I can do to help fix this?  Anyone you want me to confront at OLS
and "persuade"?

thanks,

greg k-h


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: sysdev_class use from DRM

[Jon Smirl]

On 7/2/05, Greg KH <greg@kroah.com> wrote:
> On Fri, Jul 01, 2005 at 07:18:08PM -0400, Jon Smirl wrote:
> > On 7/1/05, Greg KH <greg@kroah.com> wrote:
> > > Last kernel summit I thought this was all hashed out.  I guess the
> > > people not there didn't agree...
> >
> > There are more layers to the problem.
> 
> {sigh}  there always is...
> 
> <good reasons snipped>
> 
> What about starting small, with just the pci driver functions, and going
> on from there.  That way you all can still fight it out over the
> different details, and I'll be happy that you play nice with the driver
> core.  Something as simple as:
> 
> register_my_driver(struct pci_driver *drv)
> {
>         /* add drv to list of drivers that want to use this hardware */
> }
> 
> 
> struct pci_driver foo = {
>         .owner = THIS_MODULE,
>         .name = "foo_video_multiplexor",
>         .id_table = all_foo_ids_combined,
>         .probe = foo_probe,
>         .suspend = foo_suspend,
>         ...
> };
> 
> static int foo_probe(struct pci_dev *dev, id)
> {
>         for (all drivers registered with me)
>                 drv->probe(dev, id);
> }

That is the pure architecture scheme of a small base driver. It
doesn't do anything for the fact that some of the drivers are
programming the chips in incompatible ways. Also each driver will
initialize the chip and format things the way they want to since they
will all assume no other driver is going to be loaded. Another example
is interrupts, with the thin base all of the drivers will each ACK the
interrupts and we have several drivers trying to service the same
interrupts.

GPUs have two basic modes - 2D programmed IO, and DMA based drawing.
fbdev will put it into 2D mode, DRM into DMA mode.

My approach is to make fbdev the base layer. fbdev will initialize the
chip and attach/ACK the interrupts. I then have to disable/remove
fbdev acceleration since it uses the chip in a conflicting way with
DRM. DRM then hooks into fbdev in a coordinated way.

Nothing can protect from the current X server coming in and
programming everything from user space. On VT swap the friendly X
server walks the PCI bus and disables the IO/MEM space of all VGA
adapters that it does not own. Guess what happens if my driver has an
interrupt while X has disabled it's ability to write to the interrupt
ACK register. Remember, the rules on VT swap are that you can do
anything you want to the hardware including resetting or disabling it.

There definitely should be a huge kernel rule that no future driver
that does not attach to a device will be accepted. That would have
blocked the current DRM from getting in and forced a merger long ago.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&opÌk
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel