Re: [Q] How to tell we're using the KMS (during suspend/resume) outside the graphics driver
2010/3/10 Matthew Garrett mj...@srcf.ucam.org:
On Wed, Mar 10, 2010 at 10:15:26PM +0100, Rafael J. Wysocki wrote:
On Wednesday 10 March 2010, Matthew Garrett wrote:
As far as the ACPI video driver goes, acpi_get_physical_pci_device()
will give you something to work with.
Hmm. Did you mean acpi_get_physical_device()?
Ah, no, acpi_get_pci_dev.
So, AFAIU acpi_get_pci_dev will give me pointer to struct pci_dev of
video card, yes?
There is some path I could use then:
struct pci_dev {
.
struct pci_driver *driver; /* which driver has allocated this device */
.
}
struct pci_driver {
.
struct device_driverdriver;
.
}
Finally, struct device_driver is defined in device.h. Should I add flag
bool is_kms
to this struct then?
AFAIK we can not do anything with struct driver_private *p... Or is
there unified struct for video card drivers? We could then add flag
is_kms to some struct pointed by struct driver_private *p.
--
Rafał
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Q] How to tell we're using the KMS (during suspend/resume) outside the graphics driver
On Wed, Mar 10, 2010 at 10:15:26PM +0100, Rafael J. Wysocki wrote: On Wednesday 10 March 2010, Matthew Garrett wrote: As far as the ACPI video driver goes, acpi_get_physical_pci_device() will give you something to work with. Hmm. Did you mean acpi_get_physical_device()? Ah, no, acpi_get_pci_dev. Which acpi_device should I call that for? The video one. acpi_video_bus_check does something very similar to check whether the device actually exists. -- Matthew Garrett | mj...@srcf.ucam.org -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Q] How to tell we're using the KMS (during suspend/resume) outside the graphics driver
As far as the ACPI video driver goes, acpi_get_physical_pci_device() will give you something to work with. For the console-switching case, I think the most reasonable plan is probably to add a flag to the console drivers to indicate whether or not they support reprogramming the hardware themselves, and then walk all active console drivers. There'd need to be a way for fb drivers to tell fbcon that they can handle it. -- Matthew Garrett | mj...@srcf.ucam.org -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Q] How to tell we're using the KMS (during suspend/resume) outside the graphics driver
On Wed, Mar 10, 2010 at 7:50 AM, Paul Mundt let...@linux-sh.org wrote: On Tue, Mar 09, 2010 at 10:08:28PM +0100, Rafael J. Wysocki wrote: On Tuesday 09 March 2010, James Simmons wrote: Second, in the KMS case, we'd be able to skip the kernel VT switch, because the KMS driver uses its own framebuffer anyway. So, is there any reasonable way to check that from the outside of the graphics driver? It should be general enough to cover the cases when there are two graphics adapters with different drivers in the system and so forth. Inside the kernel? If you have a struct pci_dev you can get the associated struct drm_device with pci_get_drvdata and then check the KMS feature: drm_core_check_feature(dev, DRIVER_MODESET). Yeah, I know that. I'm note sure how to check that a device is graphic card though :| Well, that's the outside of the graphics driver part of my question. :-) if ((pdev-class 8) == PCI_CLASS_DISPLAY_VGA) I'm not sure if searching through all PCI devices really is an option. Why not? The VGA arbitration code tracks a list of VGA class devices, so could easily be queried. It looks like it might need a bit more work for PCI hotplug, but it should already have all of the infrastructure you need for getting at the pdev for the suspend/resume case. It would be better to add interface that can be used to query if a graphic device supports KMS. This should support multi-gpu setups at least. I don't think anything prevents running mixed system where secundary gpu is driven by UMS code in X. Are you sure that all vga class devices have private device data that matches private drm_device structure? -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Q] How to tell we're using the KMS (during suspend/resume) outside the graphics driver
On Wednesday 10 March 2010, Matthew Garrett wrote: As far as the ACPI video driver goes, acpi_get_physical_pci_device() will give you something to work with. Hmm. Did you mean acpi_get_physical_device()? Which acpi_device should I call that for? For the console-switching case, I think the most reasonable plan is probably to add a flag to the console drivers to indicate whether or not they support reprogramming the hardware themselves, and then walk all active console drivers. There'd need to be a way for fb drivers to tell fbcon that they can handle it. Yes, that sounds reasonable. Rafael -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Q] How to tell we're using the KMS (during suspend/resume) outside the graphics driver
On Tuesday 09 March 2010, Luca Tettamanti wrote: On Sat, Mar 6, 2010 at 10:36 PM, Rafael J. Wysocki r...@sisk.pl wrote: Hi, For at least two reasons it would be beneficial for some code outisde the graphics driver(s) to know if the KMS are used. First, in the non-KMS (ie. UMS) case we probably wouldn't want to call acpi_video_resume(), because that has a potential to mess up with the GPU (it actually is known to do that on at least one system). Second, in the KMS case, we'd be able to skip the kernel VT switch, because the KMS driver uses its own framebuffer anyway. So, is there any reasonable way to check that from the outside of the graphics driver? It should be general enough to cover the cases when there are two graphics adapters with different drivers in the system and so forth. Inside the kernel? If you have a struct pci_dev you can get the associated struct drm_device with pci_get_drvdata and then check the KMS feature: drm_core_check_feature(dev, DRIVER_MODESET). Yeah, I know that. I'm note sure how to check that a device is graphic card though :| Well, that's the outside of the graphics driver part of my question. :-) Rafael -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Q] How to tell we're using the KMS (during suspend/resume) outside the graphics driver
On Sat, Mar 6, 2010 at 10:36 PM, Rafael J. Wysocki r...@sisk.pl wrote: Hi, For at least two reasons it would be beneficial for some code outisde the graphics driver(s) to know if the KMS are used. First, in the non-KMS (ie. UMS) case we probably wouldn't want to call acpi_video_resume(), because that has a potential to mess up with the GPU (it actually is known to do that on at least one system). Second, in the KMS case, we'd be able to skip the kernel VT switch, because the KMS driver uses its own framebuffer anyway. So, is there any reasonable way to check that from the outside of the graphics driver? It should be general enough to cover the cases when there are two graphics adapters with different drivers in the system and so forth. Inside the kernel? If you have a struct pci_dev you can get the associated struct drm_device with pci_get_drvdata and then check the KMS feature: drm_core_check_feature(dev, DRIVER_MODESET). I'm note sure how to check that a device is graphic card though :| Luca -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Q] How to tell we're using the KMS (during suspend/resume) outside the graphics driver
2010/3/9 Rafael J. Wysocki r...@sisk.pl: On Tuesday 09 March 2010, Luca Tettamanti wrote: I'm note sure how to check that a device is graphic card though :| Well, that's the outside of the graphics driver part of my question. :-) Can we use the same way userspace (DDX) uses to check for KMS? Some IOCTL I guess? -- Rafał -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Q] How to tell we're using the KMS (during suspend/resume) outside the graphics driver
Second, in the KMS case, we'd be able to skip the kernel VT switch, because the KMS driver uses its own framebuffer anyway. So, is there any reasonable way to check that from the outside of the graphics driver? It should be general enough to cover the cases when there are two graphics adapters with different drivers in the system and so forth. Inside the kernel? If you have a struct pci_dev you can get the associated struct drm_device with pci_get_drvdata and then check the KMS feature: drm_core_check_feature(dev, DRIVER_MODESET). Yeah, I know that. I'm note sure how to check that a device is graphic card though :| Well, that's the outside of the graphics driver part of my question. :-) if ((pdev-class 8) == PCI_CLASS_DISPLAY_VGA) -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Q] How to tell we're using the KMS (during suspend/resume) outside the graphics driver
On Tuesday 09 March 2010, James Simmons wrote: Second, in the KMS case, we'd be able to skip the kernel VT switch, because the KMS driver uses its own framebuffer anyway. So, is there any reasonable way to check that from the outside of the graphics driver? It should be general enough to cover the cases when there are two graphics adapters with different drivers in the system and so forth. Inside the kernel? If you have a struct pci_dev you can get the associated struct drm_device with pci_get_drvdata and then check the KMS feature: drm_core_check_feature(dev, DRIVER_MODESET). Yeah, I know that. I'm note sure how to check that a device is graphic card though :| Well, that's the outside of the graphics driver part of my question. :-) if ((pdev-class 8) == PCI_CLASS_DISPLAY_VGA) I'm not sure if searching through all PCI devices really is an option. Thanks anyway. Rafael -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Q] How to tell we're using the KMS (during suspend/resume) outside the graphics driver
On Tue, Mar 09, 2010 at 10:08:28PM +0100, Rafael J. Wysocki wrote: On Tuesday 09 March 2010, James Simmons wrote: Second, in the KMS case, we'd be able to skip the kernel VT switch, because the KMS driver uses its own framebuffer anyway. So, is there any reasonable way to check that from the outside of the graphics driver? It should be general enough to cover the cases when there are two graphics adapters with different drivers in the system and so forth. Inside the kernel? If you have a struct pci_dev you can get the associated struct drm_device with pci_get_drvdata and then check the KMS feature: drm_core_check_feature(dev, DRIVER_MODESET). Yeah, I know that. I'm note sure how to check that a device is graphic card though :| Well, that's the outside of the graphics driver part of my question. :-) if ((pdev-class 8) == PCI_CLASS_DISPLAY_VGA) I'm not sure if searching through all PCI devices really is an option. Why not? The VGA arbitration code tracks a list of VGA class devices, so could easily be queried. It looks like it might need a bit more work for PCI hotplug, but it should already have all of the infrastructure you need for getting at the pdev for the suspend/resume case. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Q] How to tell we're using the KMS (during suspend/resume) outside the graphics driver
Hi, For at least two reasons it would be beneficial for some code outisde the graphics driver(s) to know if the KMS are used. First, in the non-KMS (ie. UMS) case we probably wouldn't want to call acpi_video_resume(), because that has a potential to mess up with the GPU (it actually is known to do that on at least one system). Second, in the KMS case, we'd be able to skip the kernel VT switch, because the KMS driver uses its own framebuffer anyway. So, is there any reasonable way to check that from the outside of the graphics driver? It should be general enough to cover the cases when there are two graphics adapters with different drivers in the system and so forth. Rafael -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
