Skip to contentSkip to conversation

dri and udev

DISCUSSION Jon Smirl 4 participants 12 messages Dec 27, 2003 – Dec 30, 2003

lore
Share & tools
lore

Jon Smirl

author
#0 lore raw

I've been working on the dri drivers to make them appear in sysfs and udev. I have it all working now using the simple_add_class_device() routine. The dri device is normally found in /dev/dri/card0, /dev/dri/card1, etc. How do I make the device appear in a subdir under udev?

==Jon Smirl
[email protected]

__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#1 lore raw
Quoted 4 lines · Jon Smirl

I've been working on the dri drivers to make them appear in sysfs and udev. I have it all working now using the simple_add_class_device() routine. The dri device is normally found in /dev/dri/card0, /dev/dri/card1, etc. How do I make the device appear in a subdir under udev?

You may try NAME="dev/dri/card0", it will create the subdirs for you. Examples are in the file udev.rules.devfs.

Kay

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

author
#2 lore raw
In reply to Jon Smirl

Adding:
REPLACE, KERNEL="card*", NAME="dri/card%n"
to udev rules makes it work.

DRI sure made an unfortunate legacy choice of calling the driver cardX.

How is this going to work when there are multiple devices with the same name? For example
/dev/hda and /dev/i2o/hda?

Quoted 5 lines · --- Kay Sievers
Quoted 1 line · Jon Smirl

I've been working on the dri drivers to make them appear in sysfs and udev.

I

Quoted 2 lines

have it all working now using the simple_add_class_device() routine. The dri device is normally found in /dev/dri/card0, /dev/dri/card1, etc. How do I

Quoted 7 lines

make

Quoted 1 line

the device appear in a subdir under udev?

You may try NAME="dev/dri/card0", it will create the subdirs for you. Examples are in the file udev.rules.devfs.

Kay

==Jon Smirl
[email protected]

__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#3 lore raw
In reply to Jon Smirl
Quoted 9 lines · Jon Smirl

Adding:
REPLACE, KERNEL="card*", NAME="dri/card%n"
to udev rules makes it work.

DRI sure made an unfortunate legacy choice of calling the driver cardX.

How is this going to work when there are multiple devices with the same name? For example
/dev/hda and /dev/i2o/hda?

Those are two different devices, with different major/minor numbers. i2o can't create a hda block device if there is already a block device called hda in the system. So it will be called something else. As i2o isn't working yet in 2.6, I'm not to worried about it :)

thanks,

greg k-h

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#4 lore raw
In reply to Jon Smirl
Quoted 9 lines · Jon Smirl

Adding:
REPLACE, KERNEL="card*", NAME="dri/card%n"
to udev rules makes it work.

DRI sure made an unfortunate legacy choice of calling the driver cardX.

How is this going to work when there are multiple devices with the same name? For example
/dev/hda and /dev/i2o/hda?

Those are two different devices, with different major/minor numbers. i2o can't create a hda block device if there is already a block device called hda in the system. So it will be called something else. As i2o isn't working yet in 2.6, I'm not to worried about it :)

thanks,

greg k-h

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#5 lore raw
In reply to Jon Smirl
Quoted 9 lines · Jon Smirl

Adding:
REPLACE, KERNEL="card*", NAME="dri/card%n"
to udev rules makes it work.

DRI sure made an unfortunate legacy choice of calling the driver cardX.

How is this going to work when there are multiple devices with the same name? For example
/dev/hda and /dev/i2o/hda?

Those are two different devices, with different major/minor numbers. i2o can't create a hda block device if there is already a block device called hda in the system. So it will be called something else. As i2o isn't working yet in 2.6, I'm not to worried about it :)

thanks,

greg k-h

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#6 lore raw
In reply to Jon Smirl
Quoted 2 lines · Jon Smirl

I've been working on the dri drivers to make them appear in sysfs and udev. I have it all working now using the simple_add_class_device() routine.

Great, care to send me the kernel patch for this?

thanks,

greg k-h

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

author
#7 lore raw
In reply to Jon Smirl

The new DRM module has other changes in it so it has to be sync'd with a DRI/Xfree86 release. I also have to get the changes coordinated with the BSD DRI people. DRM development happens out of the DRI tree not the kernel tree. So after there is a DRI/Xfree86 Linus moves the changes over to the copy in the kernel.

Another issue is the current conflict between fbdev and dri. Both device drivers are trying to take overship of the graphics hardware. Right now fbdev owns the hardware and DRI operates as a stealth module. For sysfs/udev to work DRI has to have a PCI ID table and own the hardware. Doing this prevents fbdev and DRI from simultaneously being loaded.

This conflict has not been resolved. We did a previous version of DRM which registered with the kernel as owning the hardware and got a lot of vocal complaints from fbdev developers. DRM was backed off into steath mode again.

Stealth mode looks like this. It never calls pci_register_driver so the kernel never knows that DRM has attached to the device.

static int __init drm_init( void )

{
	struct pci_dev *pdev = NULL;

	DRM(parse_options)( drm_opts );
	DRM(mem_init)();

	while ((pdev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, pdev)) != NULL) {
		DRM(probe)(pdev);
	}
	return 0;
}

My personal opinion on this is that it is insane for two device drivers to be trying to share the same same piece of hardware - it's multitasking for device drivers. I also don't think udev/sysfs are set up to deal with two device drivers claiming the same piece of hardware.

==Jon Smirl
[email protected]

__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

author
#8 lore raw
In reply to Jon Smirl

The new DRM module has other changes in it so it has to be sync'd with a DRI/Xfree86 release. I also have to get the changes coordinated with the BSD DRI people. DRM development happens out of the DRI tree not the kernel tree. So after there is a DRI/Xfree86 Linus moves the changes over to the copy in the kernel.

Another issue is the current conflict between fbdev and dri. Both device drivers are trying to take overship of the graphics hardware. Right now fbdev owns the hardware and DRI operates as a stealth module. For sysfs/udev to work DRI has to have a PCI ID table and own the hardware. Doing this prevents fbdev and DRI from simultaneously being loaded.

This conflict has not been resolved. We did a previous version of DRM which registered with the kernel as owning the hardware and got a lot of vocal complaints from fbdev developers. DRM was backed off into steath mode again.

Stealth mode looks like this. It never calls pci_register_driver so the kernel never knows that DRM has attached to the device.

static int __init drm_init( void )

{
	struct pci_dev *pdev = NULL;

	DRM(parse_options)( drm_opts );
	DRM(mem_init)();

	while ((pdev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, pdev)) != NULL) {
		DRM(probe)(pdev);
	}
	return 0;
}

My personal opinion on this is that it is insane for two device drivers to be trying to share the same same piece of hardware - it's multitasking for device drivers. I also don't think udev/sysfs are set up to deal with two device drivers claiming the same piece of hardware.

==Jon Smirl
[email protected]

__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#9 lore raw
In reply to Jon Smirl
Quoted 4 lines · Jon Smirl

My personal opinion on this is that it is insane for two device drivers to be trying to share the same same piece of hardware - it's multitasking for device drivers. I also don't think udev/sysfs are set up to deal with two device drivers claiming the same piece of hardware.

I fully agree. This also has the downside that hotplug cannot automatically load the DRM modules.
(And probably many more people need DRM than they need fbdev...)

Signature · 13 lines
ciao, |
Marco | [3810 esbuHOWw6GXX6]


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
#10 lore raw
In reply to Jon Smirl
Quoted 4 lines · Jon Smirl

My personal opinion on this is that it is insane for two device drivers to be trying to share the same same piece of hardware - it's multitasking for device drivers. I also don't think udev/sysfs are set up to deal with two device drivers claiming the same piece of hardware.

I fully agree. This also has the downside that hotplug cannot automatically load the DRM modules.
(And probably many more people need DRM than they need fbdev...)

Signature · 13 lines
ciao, |
Marco | [3810 esbuHOWw6GXX6]


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
#11 lore raw
In reply to Jon Smirl
Quoted 2 lines · Jon Smirl
	while ((pdev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, pdev)) != NULL) {

If you _have_ to do this, please use pci_get_device() instead. It's much safer to use.

Quoted 4 lines

My personal opinion on this is that it is insane for two device drivers to be trying to share the same same piece of hardware - it's multitasking for device drivers. I also don't think udev/sysfs are set up to deal with two device drivers claiming the same piece of hardware.

The driver model is not set up to do that. And it is correct, you should claim the device, like the fbdev people do. If users want one or the other, that's fine. Bad things might happen if two drivers talk to the same hardware at the same time.

thanks,

greg k-h

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel