search for: dev_pm_op

Use SIMPLE_DEV_PM_OPS macro in order to make the code simpler. Signed-off-by: Jingoo Han <jg1.han at samsung.com> --- drivers/virtio/virtio_pci.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c index 3d1463c6b120..c5fbdb4023d...

Use SIMPLE_DEV_PM_OPS macro in order to make the code simpler. Signed-off-by: Jingoo Han <jg1.han at samsung.com> --- drivers/virtio/virtio_pci.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c index 3d1463c6b120..c5fbdb4023d...

Myron, On Tue, Jul 16, 2013 at 8:21 PM, Myron Stowe <myron.stowe at gmail.com> wrote: > > Shuah - You brought up the idea about "Converting drivers from Legacy > PM ops to dev_pm_ops"; would you like to present what you have > done/encountered so far? > Awesome. Yes, I would like to present what I have done so far and I do have a couple of things that could benefit from a face to face discussion which would help me make progress on the rest of the work that needs t...

Myron, On Tue, Jul 16, 2013 at 8:21 PM, Myron Stowe <myron.stowe at gmail.com> wrote: > > Shuah - You brought up the idea about "Converting drivers from Legacy > PM ops to dev_pm_ops"; would you like to present what you have > done/encountered so far? > Awesome. Yes, I would like to present what I have done so far and I do have a couple of things that could benefit from a face to face discussion which would help me make progress on the rest of the work that needs t...

On Tuesday, September 09, 2014 9:14 AM, Rusty Russell wrote: > Jingoo Han <jg1.han at samsung.com> writes: > > Use SIMPLE_DEV_PM_OPS macro in order to make the code simpler. > > > > Signed-off-by: Jingoo Han <jg1.han at samsung.com> > > This patch is obviously wrong. It won't compile without > CONFIG_PM_SLEEP. No, there is no compile issue. When, CONFIG_PM_SLEEP=n, there is no build error. ...

On Tuesday, September 09, 2014 9:14 AM, Rusty Russell wrote: > Jingoo Han <jg1.han at samsung.com> writes: > > Use SIMPLE_DEV_PM_OPS macro in order to make the code simpler. > > > > Signed-off-by: Jingoo Han <jg1.han at samsung.com> > > This patch is obviously wrong. It won't compile without > CONFIG_PM_SLEEP. No, there is no compile issue. When, CONFIG_PM_SLEEP=n, there is no build error. ...

...ay, July 17, 2013 08:31:55 AM Shuah Khan wrote: >> Myron, >> >> On Tue, Jul 16, 2013 at 8:21 PM, Myron Stowe <myron.stowe at gmail.com> wrote: >> >>> >>> Shuah - You brought up the idea about "Converting drivers from Legacy >>> PM ops to dev_pm_ops"; would you like to present what you have >>> done/encountered so far? >>> >> >> Awesome. Yes, I would like to present what I have done so far and I do >> have a couple of things that could benefit from a face to face >> discussion which would help me...

...ay, July 17, 2013 08:31:55 AM Shuah Khan wrote: >> Myron, >> >> On Tue, Jul 16, 2013 at 8:21 PM, Myron Stowe <myron.stowe at gmail.com> wrote: >> >>> >>> Shuah - You brought up the idea about "Converting drivers from Legacy >>> PM ops to dev_pm_ops"; would you like to present what you have >>> done/encountered so far? >>> >> >> Awesome. Yes, I would like to present what I have done so far and I do >> have a couple of things that could benefit from a face to face >> discussion which would help me...

Hello, Turns out S3 is not different from S4 for virtio devices: the device is assumed to be reset, so the host and guest state are to be assumed to be out of sync upon resume. We handle the S4 case with exactly the same scenario, so just point the suspend/resume routines to the freeze/restore ones. Once that is done, we also use the PM API's macro to initialise the sleep functions. A

Hello, Turns out S3 is not different from S4 for virtio devices: the device is assumed to be reset, so the host and guest state are to be assumed to be out of sync upon resume. We handle the S4 case with exactly the same scenario, so just point the suspend/resume routines to the freeze/restore ones. Once that is done, we also use the PM API's macro to initialise the sleep functions. A

...; > DRM_DEBUG_DRIVER("... vram_pushbuf : %d\n", nouveau_vram_pushbuf); > DRM_DEBUG_DRIVER("... pstate : %d\n", nouveau_pstate); > + DRM_DEBUG_DRIVER("... staging : %d\n", nouveau_staging); > } > > static const struct dev_pm_ops nouveau_pm_ops = { > @@ -1088,6 +1094,18 @@ err_free: > static int __init > nouveau_drm_init(void) > { > + /* Do not register staging ioctsl if option not specified */ > + if (!nouveau_staging) { > + unsigned i; > + > + /* This...

.... vram_pushbuf : %d\n", nouveau_vram_pushbuf); >>> DRM_DEBUG_DRIVER("... pstate : %d\n", nouveau_pstate); >>> + DRM_DEBUG_DRIVER("... staging : %d\n", nouveau_staging); >>> } >>> >>> static const struct dev_pm_ops nouveau_pm_ops = { >>> @@ -1088,6 +1094,18 @@ err_free: >>> static int __init >>> nouveau_drm_init(void) >>> { >>> + /* Do not register staging ioctsl if option not specified */ >>> + if (!nouveau_staging) { >>> +...

Fixes a couple of minor compliance issues in new virtio 1.0 code. Plus, adds a couple of minor cleanups - not bugfixes, but seem safe enough for 3.19. Michael S. Tsirkin (6): virtio: set VIRTIO_CONFIG_S_FEATURES_OK on restore virtio_config: fix virtio_cread_bytes virtio_pci_common.h: drop VIRTIO_PCI_NO_LEGACY virtio_pci: move probe to common file virtio_pci: add VIRTIO_PCI_NO_LEGACY

Fixes a couple of minor compliance issues in new virtio 1.0 code. Plus, adds a couple of minor cleanups - not bugfixes, but seem safe enough for 3.19. Michael S. Tsirkin (6): virtio: set VIRTIO_CONFIG_S_FEATURES_OK on restore virtio_config: fix virtio_cread_bytes virtio_pci_common.h: drop VIRTIO_PCI_NO_LEGACY virtio_pci: move probe to common file virtio_pci: add VIRTIO_PCI_NO_LEGACY

...drm/i915/i915_drv.h > index bacb4c762f5b..666db65fe69e 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -1736,6 +1736,7 @@ intel_ggtt_update_needs_vtd_wa(struct drm_i915_private *dev_priv) > > /* i915_drv.c */ > extern const struct dev_pm_ops i915_pm_ops; > +extern const struct drm_gem_object_funcs i915_gem_object_funcs; > > int i915_driver_probe(struct pci_dev *pdev, const struct pci_device_id *ent); > void i915_driver_remove(struct drm_i915_private *i915); > diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_devi...

...eckpoint on Xen. The Linux Xen guest can be saved the state to restore later, and also created snapshot like checkpoint via the hypervisor. But, when the snapshot is created for the PV guest, it will hangup. We added ''PMSG_CANCEL'' message and ''cancel'' handler in dev_pm_ops struct in the pm-linux part. In creating checkpoint mode, the resume handler of xenbus should not be called. In this case, it is recognized that the suspend was canceled in drivers/xen/manage.c and call dpm_resume_end() with PMSG_CANCEL. If the ''cancel'' handler is defined, it is...

...s_probe_frontend.c +++ b/drivers/xen/xenbus/xenbus_probe_frontend.c @@ -81,10 +81,6 @@ static void backend_changed(struct xenbus_watch *watch, xenbus_otherend_changed(watch, vec, len, 1); } -static struct device_attribute xenbus_frontend_dev_attrs[] = { - __ATTR_NULL -}; - static const struct dev_pm_ops xenbus_pm_ops = { .suspend = xenbus_dev_suspend, .resume = xenbus_dev_resume, @@ -106,7 +102,7 @@ static struct xen_bus_type xenbus_frontend = { .probe = xenbus_dev_probe, .remove = xenbus_dev_remove, .shutdown = xenbus_dev_shutdown, - .dev_attrs = xenbus_frontend_dev_attrs, + .d...

...s_probe_frontend.c +++ b/drivers/xen/xenbus/xenbus_probe_frontend.c @@ -81,10 +81,6 @@ static void backend_changed(struct xenbus_watch *watch, xenbus_otherend_changed(watch, vec, len, 1); } -static struct device_attribute xenbus_frontend_dev_attrs[] = { - __ATTR_NULL -}; - static const struct dev_pm_ops xenbus_pm_ops = { .suspend = xenbus_dev_suspend, .resume = xenbus_dev_resume, @@ -106,7 +102,7 @@ static struct xen_bus_type xenbus_frontend = { .probe = xenbus_dev_probe, .remove = xenbus_dev_remove, .shutdown = xenbus_dev_shutdown, - .dev_attrs = xenbus_frontend_dev_attrs, + .d...

...s_probe_frontend.c +++ b/drivers/xen/xenbus/xenbus_probe_frontend.c @@ -81,10 +81,6 @@ static void backend_changed(struct xenbus_watch *watch, xenbus_otherend_changed(watch, vec, len, 1); } -static struct device_attribute xenbus_frontend_dev_attrs[] = { - __ATTR_NULL -}; - static const struct dev_pm_ops xenbus_pm_ops = { .suspend = xenbus_dev_suspend, .resume = xenbus_dev_resume, @@ -106,7 +102,7 @@ static struct xen_bus_type xenbus_frontend = { .probe = xenbus_dev_probe, .remove = xenbus_dev_remove, .shutdown = xenbus_dev_shutdown, - .dev_attrs = xenbus_frontend_dev_attrs, + .d...

Hello, There is a trouble on ARM with DMA allocations made by device drivers, the trouble is that DMA allocations are getting implicitly backed with IOMMU mapping by the driver core if IOMMU presents in a system and IOMMU could handle device. This is an undesired behaviour for drivers that manage IOMMU by themselves, like NVIDIA Tegra GPU driver. On arm32 the implicit backing happens if