search for: power_st

Another vga_switcheroo cleanup. Maintainers, is it okay to include the one-line change of each driver in here or do you want that split into separate patches? Thanks, Lukas Lukas Wunner (1): vga_switcheroo: Constify vga_switcheroo_handler drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 2 +- drivers/gpu/drm/nouveau/nouveau_acpi.c | 2 +-

I can confirm what Peter said, path contains \_SB_.PCI0.RP05 and power_state contains D3hot. Op do 27 okt. 2016 11:06 schreef Peter Wu <peter at lekensteyn.nl>: > On Thu, Oct 27, 2016 at 11:17:48AM +0300, Mika Westerberg wrote: > > On Thu, Oct 27, 2016 at 12:56:41AM +0200, Peter Wu wrote: > > > Hi PCI/ACPI PM experts, > > > > > &g...

...--git a/drivers/gpu/drm/nouveau/nouveau_drv.c b/drivers/gpu/drm/nouveau/nouveau_drv.c index 13bb672..f658a04 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drv.c +++ b/drivers/gpu/drm/nouveau/nouveau_drv.c @@ -234,9 +234,9 @@ nouveau_pci_suspend(struct pci_dev *pdev, pm_message_t pm_state) pci_set_power_state(pdev, PCI_D3hot); } - acquire_console_sem(); + console_lock(); nouveau_fbcon_set_suspend(dev, 1); - release_console_sem(); + console_unlock(); nouveau_fbcon_restore_accel(dev); return 0; @@ -359,9 +359,9 @@ nouveau_pci_resume(struct pci_dev *pdev) nv_crtc->lut.depth = 0; }...

...--git a/drivers/gpu/drm/nouveau/nouveau_drv.c b/drivers/gpu/drm/nouveau/nouveau_drv.c index 13bb672..f658a04 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drv.c +++ b/drivers/gpu/drm/nouveau/nouveau_drv.c @@ -234,9 +234,9 @@ nouveau_pci_suspend(struct pci_dev *pdev, pm_message_t pm_state) pci_set_power_state(pdev, PCI_D3hot); } - acquire_console_sem(); + console_lock(); nouveau_fbcon_set_suspend(dev, 1); - release_console_sem(); + console_unlock(); nouveau_fbcon_restore_accel(dev); return 0; @@ -359,9 +359,9 @@ nouveau_pci_resume(struct pci_dev *pdev) nv_crtc->lut.depth = 0; }...

...--git a/drivers/gpu/drm/nouveau/nouveau_drv.c b/drivers/gpu/drm/nouveau/nouveau_drv.c index 13bb672..f658a04 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drv.c +++ b/drivers/gpu/drm/nouveau/nouveau_drv.c @@ -234,9 +234,9 @@ nouveau_pci_suspend(struct pci_dev *pdev, pm_message_t pm_state) pci_set_power_state(pdev, PCI_D3hot); } - acquire_console_sem(); + console_lock(); nouveau_fbcon_set_suspend(dev, 1); - release_console_sem(); + console_unlock(); nouveau_fbcon_restore_accel(dev); return 0; @@ -359,9 +359,9 @@ nouveau_pci_resume(struct pci_dev *pdev) nv_crtc->lut.depth = 0; }...

On Thu, Oct 27, 2016 at 12:56:41AM +0200, Peter Wu wrote: > Hi PCI/ACPI PM experts, > > Since Linux 4.8, nouveau switched to rely on the PCIe port driver to > transition to D3cold. This however does not happen for an Acer Aspire > V7-582PG (Haswell, NVIDIA GTX 750M) from Rick. > > Any idea why? acpidump, lspci, dmesg and other details can be found in > the linked bug

...munication Channel Info */ + +struct acpi_mpst_channel { + ACPI_MPST_CHANNEL_INFO /* Platform Communication Channel */ +}; + +/* Memory Power Node Structure */ + +struct acpi_mpst_power_node { + u8 flags; + u8 reserved1; + u16 node_id; + u32 length; + u64 range_address; + u64 range_length; + u8 num_power_states; + u8 num_physical_components; + u16 reserved2; +}; + +/* Values for Flags field above */ + +#define ACPI_MPST_ENABLED 1 +#define ACPI_MPST_POWER_MANAGED 2 +#define ACPI_MPST_HOT_PLUG_CAPABLE 4 + +/* Memory Power State Structure (follows POWER_NODE above) */ + +struct...

On Thu, Oct 27, 2016 at 09:15:19AM +0000, Rick Kerkhof wrote: > I can confirm what Peter said, path contains \_SB_.PCI0.RP05 and > power_state contains D3hot. And there are no power_resources_Dx directories under /sys/bus/pci/devices/0000:00:1c.4/firmware_node?

...9;'70645ba3-bcbc-683b-099e-ed197301fcc2'') (''allowed_operations'' (''array'')) (''current_operations'' (''struct'' (''OpaqueRef:38ebb659-ac74-8e80-5ffe-a1da898f39ac'' ''start''))) (''power_state'' ''Halted'') (''name_label'' ''PVG1'') (''name_description'' ''Installed via xe CLI'') (''user_version'' ''1'') (''is_a_template'' (''boolean''...

...#39;fd478bba-f12f-8402-21b7-685566164390'') (''allowed_operations'' (''array'')) (''current_operations'' (''struct'' (''OpaqueRef:6a47fd73-bd61-5c62-d4b0-1701082d132f'' ''start_on''))) (''power_state'' ''Halted'') (''name_label'' ''Liberty'') (''name_description'' ''Installed via xe CLI'') (''user_version'' ''1'') (''is_a_template'' (''boolean'...

...munication Channel Info */ + +struct acpi_mpst_channel { + ACPI_MPST_CHANNEL_INFO /* Platform Communication Channel */ +}; + +/* Memory Power Node Structure */ + +struct acpi_mpst_power_node { + u8 flags; + u8 reserved1; + u16 node_id; + u32 length; + u64 range_address; + u64 range_length; + u8 num_power_states; + u8 num_physical_components; + u16 reserved2; +}; + +/* Values for Flags field above */ + +#define ACPI_MPST_ENABLED 1 +#define ACPI_MPST_POWER_MANAGED 2 +#define ACPI_MPST_HOT_PLUG_CAPABLE 4 + +/* Memory Power State Structure (follows POWER_NODE above) */ + +struct...

...et _STA > to 0 but should not affect here). > > I wonder what does /sys/bus/pci/devices/0000:00:1c.4/firmware_node/path contain? The value is as expected, \_SB.PCI0.RP05: /sys/bus/pci/devices/0000:00:1c.4/firmware_node/path:\_SB_.PCI0.RP05 /sys/bus/pci/devices/0000:00:1c.4/firmware_node/power_state:D3hot -- Kind regards, Peter Wu https://lekensteyn.nl

...ive directory listing: http://sprunge.us/FIRE Op do 27 okt. 2016 11:30 schreef Mika Westerberg < mika.westerberg at linux.intel.com>: > On Thu, Oct 27, 2016 at 09:15:19AM +0000, Rick Kerkhof wrote: > > I can confirm what Peter said, path contains \_SB_.PCI0.RP05 and > > power_state contains D3hot. > > And there are no power_resources_Dx directories under > /sys/bus/pci/devices/0000:00:1c.4/firmware_node? > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/nouveau/attachments/20161027/3617a...

Hi all, this small patch series implement guest SMP support for ARM, using the ARM PSCI interface for secondary cpu bringup. Stefano Stabellini (4): xen/arm: basic PSCI support, implement cpu_on xen/arm: support for guest SGI xen/arm: support vcpu_op hypercalls xen: move VCPUOP_register_vcpu_info to common code xen/arch/arm/domain.c | 66 ++++++++++++++++++++++++

Hi Folks: I am having trouble creating a Fedora 14 domU on a XCP 1.0 dom0 hypervisor and am hoping that someone can help me figure out what I am doing wrong. Here is what I did (per the user''s guide and reference manual): ## Step 1. Create the VM: # uuid=$(xe vm-install template=''Other install media'' new-name-label=''test'') ## Note: I also tried

The marilith boxes use a conserver (http://www.conserver.com/) setup for serial access. Our installation exports the logs via http allowing us to grab them with wget. Sending debug keys with is handled separately via xenuse. xenuse ultimately speaks to the conserver too but it abstracts away the IP and port to use so this is preferred. With these changes the correct Serial hostprop for a

...md/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index 50afcf65181a..ba4335fd4f65 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -720,7 +720,6 @@ static int amdgpu_pmops_runtime_suspend(struct device *dev) drm_dev->switch_power_state = DRM_SWITCH_POWER_CHANGING; drm_kms_helper_poll_disable(drm_dev); - vga_switcheroo_set_dynamic_switch(pdev, VGA_SWITCHEROO_OFF); ret = amdgpu_device_suspend(drm_dev, false, false); pci_save_state(pdev); @@ -757,7 +756,6 @@ static int amdgpu_pmops_runtime_resume(struct device *dev) r...

...rs/gpu/drm/amd/amdgpu/amdgpu_drv.c > index 50afcf65181a..ba4335fd4f65 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > @@ -720,7 +720,6 @@ static int amdgpu_pmops_runtime_suspend(struct device *dev) > > drm_dev->switch_power_state = DRM_SWITCH_POWER_CHANGING; > drm_kms_helper_poll_disable(drm_dev); > - vga_switcheroo_set_dynamic_switch(pdev, VGA_SWITCHEROO_OFF); > > ret = amdgpu_device_suspend(drm_dev, false, false); > pci_save_state(pdev); > @@ -757,7 +756,6 @@ static int amdgpu_pmops_runtime_re...

I''ve addressed all (I think/hope) of the review comments. The main change is to expose the guest virtual platform (e.g. memory layout and interrupt usage etc) to the toolstack via the public interface. This is then used during FDT generation. I have just codified the current defacto standard layout, it''s probably not the best layout but any change can be a separate patch/series.

Modernize vga_switcheroo by using a "device link" to enforce a runtime PM dependency from an HDA controller to the GPU it's integrated into. Remove thereby obsoleted code and fix a bunch of bugs. Device links were introduced in v4.10. Users might see a small power saving if the discrete GPU is in use and its HDA controller is not, because the HDA controller is now allowed to runtime