[PATCH v4 0/3]

[PATCH v4 0/3]

[Tomeu Vizoso]

Hi,

this is v4 of an attempt to make easier for devices to remain in runtime
PM when the system ges to sleep, mainly to reduce the time spent
resuming devices.

In this version there's a patch from Alan that relaxes the conditions
that allow a device to go directly to the complete phase, thus allowing
its ancestors to do the same.

Also, we interpret the absence of all PM callback implementations as
being safe to do direct_complete as well.

With these changes, a uvcvideo device (for example) stays in runtime
suspend when the system goes to sleep and is left in that state when the
system resumes, not delaying it unnecessarily.

Thanks,

Tomeu


Alan Stern (1):
  PM / sleep: Allow devices without runtime PM to do direct-complete

Tomeu Vizoso (2):
  PM / sleep: Go direct_complete if driver has no callbacks
  USB / PM: Allow USB devices to remain runtime-suspended when sleeping

 Documentation/power/devices.txt    |  7 +++++++
 Documentation/power/runtime_pm.txt |  4 ----
 drivers/base/power/main.c          | 19 ++++++++++++++++++-
 drivers/usb/core/port.c            |  6 ++++++
 drivers/usb/core/usb.c             | 11 ++++++++++-
 include/linux/pm_runtime.h         |  6 ------
 6 files changed, 41 insertions(+), 12 deletions(-)

-- 
2.4.3

[PATCH v4 1/3] PM / sleep: Allow devices without runtime PM to do direct-complete

[Tomeu Vizoso]

From: Alan Stern <stern@rowland.harvard.edu>

Don't unset the direct_complete flag on devices that have runtime PM
disabled, if they are runtime suspended.

This is needed because otherwise ancestor devices wouldn't be able to
do direct_complete without adding runtime PM support to all its
descendants.

Also removes pm_runtime_suspended_if_enabled() because it's now unused.

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
---

 Documentation/power/devices.txt    | 7 +++++++
 Documentation/power/runtime_pm.txt | 4 ----
 drivers/base/power/main.c          | 2 +-
 include/linux/pm_runtime.h         | 6 ------
 4 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
index d172bce0fd49..8ba6625fdd63 100644
--- a/Documentation/power/devices.txt
+++ b/Documentation/power/devices.txt
@@ -341,6 +341,13 @@ the phases are:
 	and is entirely responsible for bringing the device back to the
 	functional state as appropriate.
 
+	Note that this direct-complete procedure applies even if the device is
+	disabled for runtime PM; only the runtime-PM status matters.  It follows
+	that if a device has system-sleep callbacks but does not support runtime
+	PM, then its prepare callback must never return a positive value.  This
+	is because all devices are initially set to runtime-suspended with
+	runtime PM disabled.
+
     2.	The suspend methods should quiesce the device to stop it from performing
 	I/O.  They also may save the device registers and put it into the
 	appropriate low-power state, depending on the bus type the device is on,
diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt
index e76dc0ad4d2b..0784bc3a2ab5 100644
--- a/Documentation/power/runtime_pm.txt
+++ b/Documentation/power/runtime_pm.txt
@@ -445,10 +445,6 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
   bool pm_runtime_status_suspended(struct device *dev);
     - return true if the device's runtime PM status is 'suspended'
 
-  bool pm_runtime_suspended_if_enabled(struct device *dev);
-    - return true if the device's runtime PM status is 'suspended' and its
-      'power.disable_depth' field is equal to 1
-
   void pm_runtime_allow(struct device *dev);
     - set the power.runtime_auto flag for the device and decrease its usage
       counter (used by the /sys/devices/.../power/control interface to
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 30b7bbfdc558..1710c26ba097 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -1377,7 +1377,7 @@ static int __device_suspend(struct device *dev, pm_message_t state, bool async)
 	if (dev->power.direct_complete) {
 		if (pm_runtime_status_suspended(dev)) {
 			pm_runtime_disable(dev);
-			if (pm_runtime_suspended_if_enabled(dev))
+			if (pm_runtime_status_suspended(dev))
 				goto Complete;
 
 			pm_runtime_enable(dev);
diff --git a/include/linux/pm_runtime.h b/include/linux/pm_runtime.h
index 30e84d48bfea..3bdbb4189780 100644
--- a/include/linux/pm_runtime.h
+++ b/include/linux/pm_runtime.h
@@ -98,11 +98,6 @@ static inline bool pm_runtime_status_suspended(struct device *dev)
 	return dev->power.runtime_status == RPM_SUSPENDED;
 }
 
-static inline bool pm_runtime_suspended_if_enabled(struct device *dev)
-{
-	return pm_runtime_status_suspended(dev) && dev->power.disable_depth == 1;
-}
-
 static inline bool pm_runtime_enabled(struct device *dev)
 {
 	return !dev->power.disable_depth;
@@ -164,7 +159,6 @@ static inline void device_set_run_wake(struct device *dev, bool enable) {}
 static inline bool pm_runtime_suspended(struct device *dev) { return false; }
 static inline bool pm_runtime_active(struct device *dev) { return true; }
 static inline bool pm_runtime_status_suspended(struct device *dev) { return false; }
-static inline bool pm_runtime_suspended_if_enabled(struct device *dev) { return false; }
 static inline bool pm_runtime_enabled(struct device *dev) { return false; }
 
 static inline void pm_runtime_no_callbacks(struct device *dev) {}
-- 
2.4.3

Re: [PATCH v4 1/3] PM / sleep: Allow devices without runtime PM to do direct-complete

[Rafael J. Wysocki]

On Wednesday, July 15, 2015 02:40:06 PM Tomeu Vizoso wrote:
> From: Alan Stern <stern@rowland.harvard.edu>
> 
> Don't unset the direct_complete flag on devices that have runtime PM
> disabled, if they are runtime suspended.
> 
> This is needed because otherwise ancestor devices wouldn't be able to
> do direct_complete without adding runtime PM support to all its
> descendants.
> 
> Also removes pm_runtime_suspended_if_enabled() because it's now unused.
> 
> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> Signed-off-by: Alan Stern <stern@rowland.harvard.edu>

Applied, thanks!


> ---
> 
>  Documentation/power/devices.txt    | 7 +++++++
>  Documentation/power/runtime_pm.txt | 4 ----
>  drivers/base/power/main.c          | 2 +-
>  include/linux/pm_runtime.h         | 6 ------
>  4 files changed, 8 insertions(+), 11 deletions(-)
> 
> diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
> index d172bce0fd49..8ba6625fdd63 100644
> --- a/Documentation/power/devices.txt
> +++ b/Documentation/power/devices.txt
> @@ -341,6 +341,13 @@ the phases are:
>  	and is entirely responsible for bringing the device back to the
>  	functional state as appropriate.
>  
> +	Note that this direct-complete procedure applies even if the device is
> +	disabled for runtime PM; only the runtime-PM status matters.  It follows
> +	that if a device has system-sleep callbacks but does not support runtime
> +	PM, then its prepare callback must never return a positive value.  This
> +	is because all devices are initially set to runtime-suspended with
> +	runtime PM disabled.
> +
>      2.	The suspend methods should quiesce the device to stop it from performing
>  	I/O.  They also may save the device registers and put it into the
>  	appropriate low-power state, depending on the bus type the device is on,
> diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt
> index e76dc0ad4d2b..0784bc3a2ab5 100644
> --- a/Documentation/power/runtime_pm.txt
> +++ b/Documentation/power/runtime_pm.txt
> @@ -445,10 +445,6 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
>    bool pm_runtime_status_suspended(struct device *dev);
>      - return true if the device's runtime PM status is 'suspended'
>  
> -  bool pm_runtime_suspended_if_enabled(struct device *dev);
> -    - return true if the device's runtime PM status is 'suspended' and its
> -      'power.disable_depth' field is equal to 1
> -
>    void pm_runtime_allow(struct device *dev);
>      - set the power.runtime_auto flag for the device and decrease its usage
>        counter (used by the /sys/devices/.../power/control interface to
> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> index 30b7bbfdc558..1710c26ba097 100644
> --- a/drivers/base/power/main.c
> +++ b/drivers/base/power/main.c
> @@ -1377,7 +1377,7 @@ static int __device_suspend(struct device *dev, pm_message_t state, bool async)
>  	if (dev->power.direct_complete) {
>  		if (pm_runtime_status_suspended(dev)) {
>  			pm_runtime_disable(dev);
> -			if (pm_runtime_suspended_if_enabled(dev))
> +			if (pm_runtime_status_suspended(dev))
>  				goto Complete;
>  
>  			pm_runtime_enable(dev);
> diff --git a/include/linux/pm_runtime.h b/include/linux/pm_runtime.h
> index 30e84d48bfea..3bdbb4189780 100644
> --- a/include/linux/pm_runtime.h
> +++ b/include/linux/pm_runtime.h
> @@ -98,11 +98,6 @@ static inline bool pm_runtime_status_suspended(struct device *dev)
>  	return dev->power.runtime_status == RPM_SUSPENDED;
>  }
>  
> -static inline bool pm_runtime_suspended_if_enabled(struct device *dev)
> -{
> -	return pm_runtime_status_suspended(dev) && dev->power.disable_depth == 1;
> -}
> -
>  static inline bool pm_runtime_enabled(struct device *dev)
>  {
>  	return !dev->power.disable_depth;
> @@ -164,7 +159,6 @@ static inline void device_set_run_wake(struct device *dev, bool enable) {}
>  static inline bool pm_runtime_suspended(struct device *dev) { return false; }
>  static inline bool pm_runtime_active(struct device *dev) { return true; }
>  static inline bool pm_runtime_status_suspended(struct device *dev) { return false; }
> -static inline bool pm_runtime_suspended_if_enabled(struct device *dev) { return false; }
>  static inline bool pm_runtime_enabled(struct device *dev) { return false; }
>  
>  static inline void pm_runtime_no_callbacks(struct device *dev) {}
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

[PATCH v4 2/3] PM / sleep: Go direct_complete if driver has no callbacks

[Tomeu Vizoso]

If a suitable prepare callback cannot be found for a given device and
its driver has no PM callbacks at all, assume that it can go direct to
complete when the system goes to sleep.

The reason for this is that there's lots of devices in a system that do
no PM at all and there's no reason for them to prevent their ancestors
to do direct_complete if they can support it.

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
---

 drivers/base/power/main.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 1710c26ba097..edda3f233c7c 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -1540,6 +1540,21 @@ int dpm_suspend(pm_message_t state)
 	return error;
 }
 
+static bool driver_has_no_pm_callbacks(struct device_driver *drv)
+{
+	if (!drv->pm)
+		return true;
+
+	return !drv->pm->prepare &&
+	       !drv->pm->suspend &&
+	       !drv->pm->suspend_late &&
+	       !drv->pm->suspend_noirq &&
+	       !drv->pm->resume_noirq &&
+	       !drv->pm->resume_early &&
+	       !drv->pm->resume &&
+	       !drv->pm->complete;
+}
+
 /**
  * device_prepare - Prepare a device for system power transition.
  * @dev: Device to handle.
@@ -1590,6 +1605,8 @@ static int device_prepare(struct device *dev, pm_message_t state)
 
 	if (callback)
 		ret = callback(dev);
+	else if (!dev->driver || driver_has_no_pm_callbacks(dev->driver))
+		ret = 1;	/* Let device go direct_complete */
 
 	device_unlock(dev);
 
-- 
2.4.3

Re: [PATCH v4 2/3] PM / sleep: Go direct_complete if driver has no callbacks

[Alan Stern]

On Wed, 15 Jul 2015, Tomeu Vizoso wrote:

> If a suitable prepare callback cannot be found for a given device and
> its driver has no PM callbacks at all, assume that it can go direct to
> complete when the system goes to sleep.
> 
> The reason for this is that there's lots of devices in a system that do
> no PM at all and there's no reason for them to prevent their ancestors
> to do direct_complete if they can support it.
> 
> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> ---
> 
>  drivers/base/power/main.c | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> index 1710c26ba097..edda3f233c7c 100644
> --- a/drivers/base/power/main.c
> +++ b/drivers/base/power/main.c
> @@ -1540,6 +1540,21 @@ int dpm_suspend(pm_message_t state)
>  	return error;
>  }
>  
> +static bool driver_has_no_pm_callbacks(struct device_driver *drv)
> +{
> +	if (!drv->pm)
> +		return true;
> +
> +	return !drv->pm->prepare &&
> +	       !drv->pm->suspend &&
> +	       !drv->pm->suspend_late &&
> +	       !drv->pm->suspend_noirq &&
> +	       !drv->pm->resume_noirq &&
> +	       !drv->pm->resume_early &&
> +	       !drv->pm->resume &&
> +	       !drv->pm->complete;
> +}

This isn't exactly what I meant.  We also need to check the dev_pm_ops 
fields in dev->pm_domain, dev->type, dev->class, and dev->bus.  Only if 
_all_ of these callbacks are missing should we use direct_complete.

Alan Stern

Re: [PATCH v4 2/3] PM / sleep: Go direct_complete if driver has no callbacks

[Alan Stern]

On Wed, 15 Jul 2015, Tomeu Vizoso wrote:

> If a suitable prepare callback cannot be found for a given device and
> its driver has no PM callbacks at all, assume that it can go direct to
> complete when the system goes to sleep.
> 
> The reason for this is that there's lots of devices in a system that do
> no PM at all and there's no reason for them to prevent their ancestors
> to do direct_complete if they can support it.
> 
> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> ---
> 
>  drivers/base/power/main.c | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> index 1710c26ba097..edda3f233c7c 100644
> --- a/drivers/base/power/main.c
> +++ b/drivers/base/power/main.c
> @@ -1540,6 +1540,21 @@ int dpm_suspend(pm_message_t state)
>  	return error;
>  }
>  
> +static bool driver_has_no_pm_callbacks(struct device_driver *drv)
> +{
> +	if (!drv->pm)
> +		return true;
> +
> +	return !drv->pm->prepare &&
> +	       !drv->pm->suspend &&
> +	       !drv->pm->suspend_late &&
> +	       !drv->pm->suspend_noirq &&
> +	       !drv->pm->resume_noirq &&
> +	       !drv->pm->resume_early &&
> +	       !drv->pm->resume &&
> +	       !drv->pm->complete;
> +}

This isn't exactly what I meant.  We also need to check the dev_pm_ops 
fields in dev->pm_domain, dev->type, dev->class, and dev->bus.  Only if 
_all_ of these callbacks are missing should we use direct_complete.

Alan Stern

Re: [PATCH v4 2/3] PM / sleep: Go direct_complete if driver has no callbacks

[Rafael J. Wysocki]

On Wednesday, July 15, 2015 02:47:50 PM Alan Stern wrote:
> On Wed, 15 Jul 2015, Tomeu Vizoso wrote:
> 
> > If a suitable prepare callback cannot be found for a given device and
> > its driver has no PM callbacks at all, assume that it can go direct to
> > complete when the system goes to sleep.
> > 
> > The reason for this is that there's lots of devices in a system that do
> > no PM at all and there's no reason for them to prevent their ancestors
> > to do direct_complete if they can support it.
> > 
> > Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> > ---
> > 
> >  drivers/base/power/main.c | 17 +++++++++++++++++
> >  1 file changed, 17 insertions(+)
> > 
> > diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> > index 1710c26ba097..edda3f233c7c 100644
> > --- a/drivers/base/power/main.c
> > +++ b/drivers/base/power/main.c
> > @@ -1540,6 +1540,21 @@ int dpm_suspend(pm_message_t state)
> >  	return error;
> >  }
> >  
> > +static bool driver_has_no_pm_callbacks(struct device_driver *drv)
> > +{
> > +	if (!drv->pm)
> > +		return true;
> > +
> > +	return !drv->pm->prepare &&
> > +	       !drv->pm->suspend &&
> > +	       !drv->pm->suspend_late &&
> > +	       !drv->pm->suspend_noirq &&
> > +	       !drv->pm->resume_noirq &&
> > +	       !drv->pm->resume_early &&
> > +	       !drv->pm->resume &&
> > +	       !drv->pm->complete;
> > +}
> 
> This isn't exactly what I meant.  We also need to check the dev_pm_ops 
> fields in dev->pm_domain, dev->type, dev->class, and dev->bus.  Only if 
> _all_ of these callbacks are missing should we use direct_complete.

Also checking that on every suspend is kind of wasteful, because those things
do not change very often.

Thanks,
Rafael

Re: [PATCH v4 2/3] PM / sleep: Go direct_complete if driver has no callbacks

[Tomeu Vizoso]

On 16 July 2015 at 02:41, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Wednesday, July 15, 2015 02:47:50 PM Alan Stern wrote:
>> On Wed, 15 Jul 2015, Tomeu Vizoso wrote:
>>
>> > If a suitable prepare callback cannot be found for a given device and
>> > its driver has no PM callbacks at all, assume that it can go direct to
>> > complete when the system goes to sleep.
>> >
>> > The reason for this is that there's lots of devices in a system that do
>> > no PM at all and there's no reason for them to prevent their ancestors
>> > to do direct_complete if they can support it.
>> >
>> > Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
>> > ---
>> >
>> >  drivers/base/power/main.c | 17 +++++++++++++++++
>> >  1 file changed, 17 insertions(+)
>> >
>> > diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
>> > index 1710c26ba097..edda3f233c7c 100644
>> > --- a/drivers/base/power/main.c
>> > +++ b/drivers/base/power/main.c
>> > @@ -1540,6 +1540,21 @@ int dpm_suspend(pm_message_t state)
>> >     return error;
>> >  }
>> >
>> > +static bool driver_has_no_pm_callbacks(struct device_driver *drv)
>> > +{
>> > +   if (!drv->pm)
>> > +           return true;
>> > +
>> > +   return !drv->pm->prepare &&
>> > +          !drv->pm->suspend &&
>> > +          !drv->pm->suspend_late &&
>> > +          !drv->pm->suspend_noirq &&
>> > +          !drv->pm->resume_noirq &&
>> > +          !drv->pm->resume_early &&
>> > +          !drv->pm->resume &&
>> > +          !drv->pm->complete;
>> > +}
>>
>> This isn't exactly what I meant.  We also need to check the dev_pm_ops
>> fields in dev->pm_domain, dev->type, dev->class, and dev->bus.  Only if
>> _all_ of these callbacks are missing should we use direct_complete.
>
> Also checking that on every suspend is kind of wasteful, because those things
> do not change very often.

Do you have any suggestion on when would be a good time to do that
check? device_pm_sleep_init() and device_pm_add() are unfortunately
too early.

Alternatively we could check once on the first suspend and cache it,
but I'm not sure that complexity would be worth it.

Thanks,

Tomeu

> Thanks,
> Rafael
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 2/3] PM / sleep: Go direct_complete if driver has no callbacks

[Rafael J. Wysocki]

On Thursday, July 16, 2015 10:47:51 AM Tomeu Vizoso wrote:
> On 16 July 2015 at 02:41, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Wednesday, July 15, 2015 02:47:50 PM Alan Stern wrote:
> >> On Wed, 15 Jul 2015, Tomeu Vizoso wrote:
> >>
> >> > If a suitable prepare callback cannot be found for a given device and
> >> > its driver has no PM callbacks at all, assume that it can go direct to
> >> > complete when the system goes to sleep.
> >> >
> >> > The reason for this is that there's lots of devices in a system that do
> >> > no PM at all and there's no reason for them to prevent their ancestors
> >> > to do direct_complete if they can support it.
> >> >
> >> > Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> >> > ---
> >> >
> >> >  drivers/base/power/main.c | 17 +++++++++++++++++
> >> >  1 file changed, 17 insertions(+)
> >> >
> >> > diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> >> > index 1710c26ba097..edda3f233c7c 100644
> >> > --- a/drivers/base/power/main.c
> >> > +++ b/drivers/base/power/main.c
> >> > @@ -1540,6 +1540,21 @@ int dpm_suspend(pm_message_t state)
> >> >     return error;
> >> >  }
> >> >
> >> > +static bool driver_has_no_pm_callbacks(struct device_driver *drv)
> >> > +{
> >> > +   if (!drv->pm)
> >> > +           return true;
> >> > +
> >> > +   return !drv->pm->prepare &&
> >> > +          !drv->pm->suspend &&
> >> > +          !drv->pm->suspend_late &&
> >> > +          !drv->pm->suspend_noirq &&
> >> > +          !drv->pm->resume_noirq &&
> >> > +          !drv->pm->resume_early &&
> >> > +          !drv->pm->resume &&
> >> > +          !drv->pm->complete;
> >> > +}
> >>
> >> This isn't exactly what I meant.  We also need to check the dev_pm_ops
> >> fields in dev->pm_domain, dev->type, dev->class, and dev->bus.  Only if
> >> _all_ of these callbacks are missing should we use direct_complete.
> >
> > Also checking that on every suspend is kind of wasteful, because those things
> > do not change very often.
> 
> Do you have any suggestion on when would be a good time to do that
> check? device_pm_sleep_init() and device_pm_add() are unfortunately
> too early.

The time to check that is (a) when the device is registered (for the bus
type/class/device type), (b) when it is added to (or removed from) a PM
domain and (c) when a driver is bound to (unbound from) it.

> Alternatively we could check once on the first suspend and cache it,

That information may be stale by the time we suspend next time.

> but I'm not sure that complexity would be worth it.

I don't think that adding extra overhead to *every* suspend can be
justified easily, however.


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

[PATCH v4 3/3] USB / PM: Allow USB devices to remain runtime-suspended when sleeping

[Tomeu Vizoso]

Have dev_pm_ops.prepare return 1 for USB devices and ports so that USB
devices can remain runtime-suspended when the system goes to a sleep
state, if their wakeup state is correct and they have runtime PM enabled.

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
---

 drivers/usb/core/port.c |  6 ++++++
 drivers/usb/core/usb.c  | 11 ++++++++++-
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
index 210618319f10..f49707d73b5a 100644
--- a/drivers/usb/core/port.c
+++ b/drivers/usb/core/port.c
@@ -168,12 +168,18 @@ static int usb_port_runtime_suspend(struct device *dev)
 
 	return retval;
 }
+
+static int usb_port_prepare(struct device *dev)
+{
+	return 1;
+}
 #endif
 
 static const struct dev_pm_ops usb_port_pm_ops = {
 #ifdef CONFIG_PM
 	.runtime_suspend =	usb_port_runtime_suspend,
 	.runtime_resume =	usb_port_runtime_resume,
+	.prepare =		usb_port_prepare,
 #endif
 };
 
diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
index 8d5b2f4113cd..cf4dde11db1c 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -316,7 +316,16 @@ static int usb_dev_uevent(struct device *dev, struct kobj_uevent_env *env)
 
 static int usb_dev_prepare(struct device *dev)
 {
-	return 0;		/* Implement eventually? */
+	struct usb_device *udev = to_usb_device(dev);
+
+	if (!pm_runtime_enabled(dev))
+		return 0;
+
+	/* Return 0 if the current wakeup setting is wrong, otherwise 1 */
+	if (udev->do_remote_wakeup != device_may_wakeup(dev))
+		return 0;
+
+	return 1;
 }
 
 static void usb_dev_complete(struct device *dev)
-- 
2.4.3

Re: [PATCH v4 3/3] USB / PM: Allow USB devices to remain runtime-suspended when sleeping

[Rafael J. Wysocki]

On Wednesday, July 15, 2015 02:40:08 PM Tomeu Vizoso wrote:
> Have dev_pm_ops.prepare return 1 for USB devices and ports so that USB
> devices can remain runtime-suspended when the system goes to a sleep
> state, if their wakeup state is correct and they have runtime PM enabled.
> 
> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> ---
> 
>  drivers/usb/core/port.c |  6 ++++++
>  drivers/usb/core/usb.c  | 11 ++++++++++-
>  2 files changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
> index 210618319f10..f49707d73b5a 100644
> --- a/drivers/usb/core/port.c
> +++ b/drivers/usb/core/port.c
> @@ -168,12 +168,18 @@ static int usb_port_runtime_suspend(struct device *dev)
>  
>  	return retval;
>  }
> +
> +static int usb_port_prepare(struct device *dev)
> +{
> +	return 1;
> +}
>  #endif
>  
>  static const struct dev_pm_ops usb_port_pm_ops = {
>  #ifdef CONFIG_PM
>  	.runtime_suspend =	usb_port_runtime_suspend,
>  	.runtime_resume =	usb_port_runtime_resume,
> +	.prepare =		usb_port_prepare,
>  #endif
>  };
>  
> diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
> index 8d5b2f4113cd..cf4dde11db1c 100644
> --- a/drivers/usb/core/usb.c
> +++ b/drivers/usb/core/usb.c
> @@ -316,7 +316,16 @@ static int usb_dev_uevent(struct device *dev, struct kobj_uevent_env *env)
>  
>  static int usb_dev_prepare(struct device *dev)
>  {
> -	return 0;		/* Implement eventually? */
> +	struct usb_device *udev = to_usb_device(dev);
> +
> +	if (!pm_runtime_enabled(dev))

Why just enabled and not suspended?

> +		return 0;
> +
> +	/* Return 0 if the current wakeup setting is wrong, otherwise 1 */
> +	if (udev->do_remote_wakeup != device_may_wakeup(dev))
> +		return 0;
> +
> +	return 1;
>  }
>  
>  static void usb_dev_complete(struct device *dev)
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [PATCH v4 3/3] USB / PM: Allow USB devices to remain runtime-suspended when sleeping

[Tomeu Vizoso]

On 16 July 2015 at 02:42, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Wednesday, July 15, 2015 02:40:08 PM Tomeu Vizoso wrote:
>> Have dev_pm_ops.prepare return 1 for USB devices and ports so that USB
>> devices can remain runtime-suspended when the system goes to a sleep
>> state, if their wakeup state is correct and they have runtime PM enabled.
>>
>> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
>> ---
>>
>>  drivers/usb/core/port.c |  6 ++++++
>>  drivers/usb/core/usb.c  | 11 ++++++++++-
>>  2 files changed, 16 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
>> index 210618319f10..f49707d73b5a 100644
>> --- a/drivers/usb/core/port.c
>> +++ b/drivers/usb/core/port.c
>> @@ -168,12 +168,18 @@ static int usb_port_runtime_suspend(struct device *dev)
>>
>>       return retval;
>>  }
>> +
>> +static int usb_port_prepare(struct device *dev)
>> +{
>> +     return 1;
>> +}
>>  #endif
>>
>>  static const struct dev_pm_ops usb_port_pm_ops = {
>>  #ifdef CONFIG_PM
>>       .runtime_suspend =      usb_port_runtime_suspend,
>>       .runtime_resume =       usb_port_runtime_resume,
>> +     .prepare =              usb_port_prepare,
>>  #endif
>>  };
>>
>> diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
>> index 8d5b2f4113cd..cf4dde11db1c 100644
>> --- a/drivers/usb/core/usb.c
>> +++ b/drivers/usb/core/usb.c
>> @@ -316,7 +316,16 @@ static int usb_dev_uevent(struct device *dev, struct kobj_uevent_env *env)
>>
>>  static int usb_dev_prepare(struct device *dev)
>>  {
>> -     return 0;               /* Implement eventually? */
>> +     struct usb_device *udev = to_usb_device(dev);
>> +
>> +     if (!pm_runtime_enabled(dev))
>
> Why just enabled and not suspended?

Hmm, the core checks if it's runtime suspended before going
direct_complete, but it's true that the API docs say that it should
return a positive value only if it's runtime suspended.

Is there a reason why the prepare() implementations have to check that
instead of leaving it to the core?

Thanks,

Tomeu

>> +             return 0;
>> +
>> +     /* Return 0 if the current wakeup setting is wrong, otherwise 1 */
>> +     if (udev->do_remote_wakeup != device_may_wakeup(dev))
>> +             return 0;
>> +
>> +     return 1;
>>  }
>>
>>  static void usb_dev_complete(struct device *dev)
>>
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 3/3] USB / PM: Allow USB devices to remain runtime-suspended when sleeping

[Rafael J. Wysocki]

On Thursday, July 16, 2015 02:09:41 PM Tomeu Vizoso wrote:
> On 16 July 2015 at 02:42, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Wednesday, July 15, 2015 02:40:08 PM Tomeu Vizoso wrote:
> >> Have dev_pm_ops.prepare return 1 for USB devices and ports so that USB
> >> devices can remain runtime-suspended when the system goes to a sleep
> >> state, if their wakeup state is correct and they have runtime PM enabled.
> >>
> >> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> >> ---
> >>
> >>  drivers/usb/core/port.c |  6 ++++++
> >>  drivers/usb/core/usb.c  | 11 ++++++++++-
> >>  2 files changed, 16 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
> >> index 210618319f10..f49707d73b5a 100644
> >> --- a/drivers/usb/core/port.c
> >> +++ b/drivers/usb/core/port.c
> >> @@ -168,12 +168,18 @@ static int usb_port_runtime_suspend(struct device *dev)
> >>
> >>       return retval;
> >>  }
> >> +
> >> +static int usb_port_prepare(struct device *dev)
> >> +{
> >> +     return 1;
> >> +}
> >>  #endif
> >>
> >>  static const struct dev_pm_ops usb_port_pm_ops = {
> >>  #ifdef CONFIG_PM
> >>       .runtime_suspend =      usb_port_runtime_suspend,
> >>       .runtime_resume =       usb_port_runtime_resume,
> >> +     .prepare =              usb_port_prepare,
> >>  #endif
> >>  };
> >>
> >> diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
> >> index 8d5b2f4113cd..cf4dde11db1c 100644
> >> --- a/drivers/usb/core/usb.c
> >> +++ b/drivers/usb/core/usb.c
> >> @@ -316,7 +316,16 @@ static int usb_dev_uevent(struct device *dev, struct kobj_uevent_env *env)
> >>
> >>  static int usb_dev_prepare(struct device *dev)
> >>  {
> >> -     return 0;               /* Implement eventually? */
> >> +     struct usb_device *udev = to_usb_device(dev);
> >> +
> >> +     if (!pm_runtime_enabled(dev))
> >
> > Why just enabled and not suspended?
> 
> Hmm, the core checks if it's runtime suspended before going
> direct_complete, but it's true that the API docs say that it should
> return a positive value only if it's runtime suspended.
> 
> Is there a reason why the prepare() implementations have to check that
> instead of leaving it to the core?

The concern is that they generally need to check the state of the device
which is meaningless from the suspend suitability (so to speak) perspective
if the device is not (runtime) suspended when the check is made.

But this particular case seems to be exceptional as ->prepare doesn't realy
check the device's (hardware) state, but only its software configuration
(if I'm not mistaken).  So checking the RPM status is not needed here.


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [PATCH v4 3/3] USB / PM: Allow USB devices to remain runtime-suspended when sleeping

[Rafael J. Wysocki]

On Thursday, July 16, 2015 02:09:41 PM Tomeu Vizoso wrote:
> On 16 July 2015 at 02:42, Rafael J. Wysocki <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org> wrote:
> > On Wednesday, July 15, 2015 02:40:08 PM Tomeu Vizoso wrote:
> >> Have dev_pm_ops.prepare return 1 for USB devices and ports so that USB
> >> devices can remain runtime-suspended when the system goes to a sleep
> >> state, if their wakeup state is correct and they have runtime PM enabled.
> >>
> >> Signed-off-by: Tomeu Vizoso <tomeu.vizoso-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> >> ---
> >>
> >>  drivers/usb/core/port.c |  6 ++++++
> >>  drivers/usb/core/usb.c  | 11 ++++++++++-
> >>  2 files changed, 16 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
> >> index 210618319f10..f49707d73b5a 100644
> >> --- a/drivers/usb/core/port.c
> >> +++ b/drivers/usb/core/port.c
> >> @@ -168,12 +168,18 @@ static int usb_port_runtime_suspend(struct device *dev)
> >>
> >>       return retval;
> >>  }
> >> +
> >> +static int usb_port_prepare(struct device *dev)
> >> +{
> >> +     return 1;
> >> +}
> >>  #endif
> >>
> >>  static const struct dev_pm_ops usb_port_pm_ops = {
> >>  #ifdef CONFIG_PM
> >>       .runtime_suspend =      usb_port_runtime_suspend,
> >>       .runtime_resume =       usb_port_runtime_resume,
> >> +     .prepare =              usb_port_prepare,
> >>  #endif
> >>  };
> >>
> >> diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
> >> index 8d5b2f4113cd..cf4dde11db1c 100644
> >> --- a/drivers/usb/core/usb.c
> >> +++ b/drivers/usb/core/usb.c
> >> @@ -316,7 +316,16 @@ static int usb_dev_uevent(struct device *dev, struct kobj_uevent_env *env)
> >>
> >>  static int usb_dev_prepare(struct device *dev)
> >>  {
> >> -     return 0;               /* Implement eventually? */
> >> +     struct usb_device *udev = to_usb_device(dev);
> >> +
> >> +     if (!pm_runtime_enabled(dev))
> >
> > Why just enabled and not suspended?
> 
> Hmm, the core checks if it's runtime suspended before going
> direct_complete, but it's true that the API docs say that it should
> return a positive value only if it's runtime suspended.
> 
> Is there a reason why the prepare() implementations have to check that
> instead of leaving it to the core?

The concern is that they generally need to check the state of the device
which is meaningless from the suspend suitability (so to speak) perspective
if the device is not (runtime) suspended when the check is made.

But this particular case seems to be exceptional as ->prepare doesn't realy
check the device's (hardware) state, but only its software configuration
(if I'm not mistaken).  So checking the RPM status is not needed here.


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/3] ref-filter: add worktreepath atom

[Jeff King]

On Wed, Dec 19, 2018 at 11:09:59PM -0800, Nickolai Belakovski wrote:

> > Also, why are we replacing it with a single space? Wouldn't the empty
> > string be more customary (and work with the other "if empty, then do
> > this" formatting options)?
> 
> I was just following what was done for HEAD, but overall I agree that
> empty is preferable to single space, will change.

Ah, right, that makes more sense. I do still think for %(HEAD) it's a
little different because it is "+" or a single space, so always one
character.  Here we have some value or not, and in the "not" case for
such things we usually give an empty string (e.g., for %(push),
%(upstream), etc).

> To sum up the hashmap comments:
> -I hadn't thought to re-use the head_ref of worktree as the key.
> That's clever. I like the readability of having separate entries for
> key and value, but I can see the benefit of not having to do an extra
> allocation. I can make up for the readability hit with a comment.

Thanks, that makes sense.

> -Actually, for any valid use case there will only be one instance of
> the map since the entries of used_atom are cached, but regardless it
> makes sense to keep per-atom info in used_atom and global context
> somewhere else, so I'll make that change to make it a static variable
> outside of used_atom.

Ah, right, I forgot there was some magic around used_atom. I do still
agree that the separate static global makes things a little simpler.

> -Will change the lookup logic to remove the extra allocation. Since
> I'm letting the hashmap use its internal comparison function on the
> hash, I don't need to provide a comparison function.

I don't think that works. The default function is always_equal(), which
will treat two entries equal if they have the same hash value. I.e., any
collisions would be considered a match.

> Thanks for all the feedback, will try to turn these around quickly.

Great, thanks! I'll be on vacation for the next two weeks, so I may be
very slow to look at the next iteration. :)

-Peff

[PATCH v4 0/3]

[nbelakovski]

From: Nickolai Belakovski <nbelakovski@gmail.com>

> I don't think that works. The default function is always_equal(), which
> will treat two entries equal if they have the same hash value. I.e., any
> collisions would be considered a match.

You're absolutely right. I've added a compare function, but I left out the
functionality for it to work with an entry passed in as a key. Doing so would
mean the user would have to allocate a worktree struct, which just seems silly
when the ref is all that's needed (and also defeats the purpose of avoiding
extra allocations).

And while most of the hashmap API seems OK, yea, this is definitely awful. It
feels like it should just be able to take a key and return either an entry or
NULL, and do away with entry_or_key and equals_function_data.

Travis-CI results: https://travis-ci.org/nbelakovski/git/builds/471787317

Nickolai Belakovski (3):
  ref-filter: add worktreepath atom
  branch: Mark and color a branch differently if it is checked out in a
    linked worktree
  branch: Add an extra verbose output displaying worktree path for refs
    checked out in a linked worktree

 Documentation/git-for-each-ref.txt |  5 +++
 builtin/branch.c                   | 16 ++++++---
 ref-filter.c                       | 72 +++++++++++++++++++++++++++++++++++++-
 t/t3200-branch.sh                  |  8 ++---
 t/t3203-branch-output.sh           | 21 +++++++++++
 t/t6302-for-each-ref-filter.sh     | 15 ++++++++
 6 files changed, 128 insertions(+), 9 deletions(-)

-- 
2.14.2

Re: [PATCH v4 0/3]

[Jeff King]

On Mon, Dec 24, 2018 at 12:47:53AM -0800, nbelakovski@gmail.com wrote:

> From: Nickolai Belakovski <nbelakovski@gmail.com>
> 
> > I don't think that works. The default function is always_equal(), which
> > will treat two entries equal if they have the same hash value. I.e., any
> > collisions would be considered a match.
> 
> You're absolutely right. I've added a compare function, but I left out the
> functionality for it to work with an entry passed in as a key. Doing so would
> mean the user would have to allocate a worktree struct, which just seems silly
> when the ref is all that's needed (and also defeats the purpose of avoiding
> extra allocations).

Unfortunately, that doesn't quite work. :)

Your compare function has to handle _both_ cases: two keys, or one key
and a keydata.

The former may be called when the hashmap has to compare two entries
internally (e.g., when it has to re-bucket all of the entries after a
resize). Your tests likely wouldn't run into this case in practice,
since you'd only have a handful of worktrees. But if you added, say,
thousands of worktrees and we had to grow the hash midway through the
process, it would segfault.  So you do need to handle the case when your
keydata is NULL.

In theory it would also be used for comparisons if we used a more clever
data structure to hold entries within a bucket. But since we just use a
linked list and linear search for now, we don't.

> And while most of the hashmap API seems OK, yea, this is definitely awful. It
> feels like it should just be able to take a key and return either an entry or
> NULL, and do away with entry_or_key and equals_function_data.

In your case, yeah, equals_function_data is not used at all (but there
are a few call-sites which need it to avoid relying on global data).

But the entry_or_key (coupled with keydata) is the magic that lets the
same function be used for both lookups as well as internal entry
comparisons.

I think having two separate comparison functions would make this a lot
more clear, though likely at the cost of having more boilerplate.

-Peff

[PATCH v4 0/3]

[Jeykumar Sankaran]

Reviving the patch posted by Sean initially.

This patch set adds MDSS and DSI nodes to SDM845 dtsi to enable display. The
patches are tested on SDM845 MTP platform using the kernel based on [1].

Part of the dependent drivers are already posted on list. Rest of the
dependencies are met using using downstream version of the driver(s) which are
yet to make it to the list. 

References to the driver patches used for testing:

display controller: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/qcom/sdm845.dtsi?id=40019e8452fe76867bdb2e7
WLED: https://patchwork.kernel.org/project/linux-arm-msm/list/?series=11023&archive=both&state=*
Panel: https://patchwork.freedesktop.org/series/50657/
iommu: https://patchwork.kernel.org/patch/10534999/

[1] https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/log/?h=integration-linux-qcomlt

Thanks and Regards,
Jeykumar S.

Changes in v4:
	- changes to add pinctrl nodes to SoC dts and display nodes to MTP
	  are included in the series
	- clock name clean up in dsi nodes
	- move around added nodes to maintain naming orders

Jeykumar Sankaran (3):
  arm64: dts: qcom: sdm845: Add dpu to sdm845 dts file
  arm64: dts: sdm845: Add dsi pinctrl nodes
  arm64: dts: sdm845: Add display nodes to MTP dts

 arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 124 +++++++++++++++++++
 arch/arm64/boot/dts/qcom/sdm845.dtsi    | 205 ++++++++++++++++++++++++++++++++
 2 files changed, 329 insertions(+)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

[PATCH v4 0/3]

[Murali Karicheri]

This patch series enable accumulator queue support for K2 SoCs. Accumulator
queues are a type of qmss queue that is monitored by the PDSP firmware and
accumulated. Host is interrupted by PDSP firmware when packets become
available in a ring buffer shared between the host and PDSP.

There was an issue raised when merging the original patch set at
 (1) https://lkml.org/lkml/2015/9/4/681
	[PATCH v1 1/2] soc: ti: display firmware file name as part of boot log
 (2) https://lkml.org/lkml/2015/9/4/680
	[PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels

This series fixes the issues raised against v3. Maintainer, could you please
apply this series to v4.4 next please at your earliest opportunity.

Change Log
==========
v4
	- collected Acked-by from Arnd Bergmann against 1/3
v3
	- Added Arnd's Acked-by against 2/4
	- 1/4 modified not to touch the DT documentation per Rob's comment.
	- Removed DTS update from the series per Santosh. Will send the same
	  as a separate patch
v2
	- Remove the firmware filename from DT and add it to the driver.
	  Use a name ks2_qmss_pdsp_acc48.bin. The idea is this can be a
	  soft link pointing to the real firmware file in file system.

	- Move the description of the driver design from DT document to one
	  under Documentation/arm/keystone/knav-qmss.txt. Update the this
	  document with location of acc firmware available under
	  linux-firmware.git.

	- Additionally added accumulator queue support optional so that lack
	  of firmware in the file system will not cause other queue types not
	  available due to driver probe failure.

Murali Karicheri (3):
  Documentation: dt: soc: Add description for knav qmss driver
  soc: ti: add firmware file name as part of the driver
  soc: ti: qmss: make acc queue support optional in the driver

 Documentation/arm/keystone/knav-qmss.txt           | 56 ++++++++++++++++++
 .../bindings/soc/ti/keystone-navigator-qmss.txt    |  1 -
 drivers/soc/ti/knav_qmss.h                         |  3 +-
 drivers/soc/ti/knav_qmss_acc.c                     | 10 +++-
 drivers/soc/ti/knav_qmss_queue.c                   | 67 ++++++++++++++--------
 5 files changed, 109 insertions(+), 28 deletions(-)
 create mode 100644 Documentation/arm/keystone/knav-qmss.txt

-- 
1.9.1

[PATCH v4 0/3]

[Murali Karicheri]

This patch series enable accumulator queue support for K2 SoCs. Accumulator
queues are a type of qmss queue that is monitored by the PDSP firmware and
accumulated. Host is interrupted by PDSP firmware when packets become
available in a ring buffer shared between the host and PDSP.

There was an issue raised when merging the original patch set at
 (1) https://lkml.org/lkml/2015/9/4/681
	[PATCH v1 1/2] soc: ti: display firmware file name as part of boot log
 (2) https://lkml.org/lkml/2015/9/4/680
	[PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels

This series fixes the issues raised against v3. Maintainer, could you please
apply this series to v4.4 next please at your earliest opportunity.

Change Log
==========
v4
	- collected Acked-by from Arnd Bergmann against 1/3
v3
	- Added Arnd's Acked-by against 2/4
	- 1/4 modified not to touch the DT documentation per Rob's comment.
	- Removed DTS update from the series per Santosh. Will send the same
	  as a separate patch
v2
	- Remove the firmware filename from DT and add it to the driver.
	  Use a name ks2_qmss_pdsp_acc48.bin. The idea is this can be a
	  soft link pointing to the real firmware file in file system.

	- Move the description of the driver design from DT document to one
	  under Documentation/arm/keystone/knav-qmss.txt. Update the this
	  document with location of acc firmware available under
	  linux-firmware.git.

	- Additionally added accumulator queue support optional so that lack
	  of firmware in the file system will not cause other queue types not
	  available due to driver probe failure.

Murali Karicheri (3):
  Documentation: dt: soc: Add description for knav qmss driver
  soc: ti: add firmware file name as part of the driver
  soc: ti: qmss: make acc queue support optional in the driver

 Documentation/arm/keystone/knav-qmss.txt           | 56 ++++++++++++++++++
 .../bindings/soc/ti/keystone-navigator-qmss.txt    |  1 -
 drivers/soc/ti/knav_qmss.h                         |  3 +-
 drivers/soc/ti/knav_qmss_acc.c                     | 10 +++-
 drivers/soc/ti/knav_qmss_queue.c                   | 67 ++++++++++++++--------
 5 files changed, 109 insertions(+), 28 deletions(-)
 create mode 100644 Documentation/arm/keystone/knav-qmss.txt

-- 
1.9.1

[PATCH v4 0/3]

[Murali Karicheri]

This patch series enable accumulator queue support for K2 SoCs. Accumulator
queues are a type of qmss queue that is monitored by the PDSP firmware and
accumulated. Host is interrupted by PDSP firmware when packets become
available in a ring buffer shared between the host and PDSP.

There was an issue raised when merging the original patch set at
 (1) https://lkml.org/lkml/2015/9/4/681
	[PATCH v1 1/2] soc: ti: display firmware file name as part of boot log
 (2) https://lkml.org/lkml/2015/9/4/680
	[PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels

This series fixes the issues raised against v3. Maintainer, could you please
apply this series to v4.4 next please at your earliest opportunity.

Change Log
==========
v4
	- collected Acked-by from Arnd Bergmann against 1/3
v3
	- Added Arnd's Acked-by against 2/4
	- 1/4 modified not to touch the DT documentation per Rob's comment.
	- Removed DTS update from the series per Santosh. Will send the same
	  as a separate patch
v2
	- Remove the firmware filename from DT and add it to the driver.
	  Use a name ks2_qmss_pdsp_acc48.bin. The idea is this can be a
	  soft link pointing to the real firmware file in file system.

	- Move the description of the driver design from DT document to one
	  under Documentation/arm/keystone/knav-qmss.txt. Update the this
	  document with location of acc firmware available under
	  linux-firmware.git.

	- Additionally added accumulator queue support optional so that lack
	  of firmware in the file system will not cause other queue types not
	  available due to driver probe failure.

Murali Karicheri (3):
  Documentation: dt: soc: Add description for knav qmss driver
  soc: ti: add firmware file name as part of the driver
  soc: ti: qmss: make acc queue support optional in the driver

 Documentation/arm/keystone/knav-qmss.txt           | 56 ++++++++++++++++++
 .../bindings/soc/ti/keystone-navigator-qmss.txt    |  1 -
 drivers/soc/ti/knav_qmss.h                         |  3 +-
 drivers/soc/ti/knav_qmss_acc.c                     | 10 +++-
 drivers/soc/ti/knav_qmss_queue.c                   | 67 ++++++++++++++--------
 5 files changed, 109 insertions(+), 28 deletions(-)
 create mode 100644 Documentation/arm/keystone/knav-qmss.txt

-- 
1.9.1

Re: [PATCH v4 0/3]

[santosh shilimkar]

10/14/2015 7:17 AM, Murali Karicheri wrote:
> This patch series enable accumulator queue support for K2 SoCs. Accumulator
> queues are a type of qmss queue that is monitored by the PDSP firmware and
> accumulated. Host is interrupted by PDSP firmware when packets become
> available in a ring buffer shared between the host and PDSP.
>
> There was an issue raised when merging the original patch set at
>   (1) https://lkml.org/lkml/2015/9/4/681
> 	[PATCH v1 1/2] soc: ti: display firmware file name as part of boot log
>   (2) https://lkml.org/lkml/2015/9/4/680
> 	[PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels
>
> This series fixes the issues raised against v3. Maintainer, could you please
> apply this series to v4.4 next please at your earliest opportunity.
>
I have picked up the series. Thanks for quick turnaround.

Regards,
Santosh

[PATCH v4 0/3]

[santosh shilimkar]

10/14/2015 7:17 AM, Murali Karicheri wrote:
> This patch series enable accumulator queue support for K2 SoCs. Accumulator
> queues are a type of qmss queue that is monitored by the PDSP firmware and
> accumulated. Host is interrupted by PDSP firmware when packets become
> available in a ring buffer shared between the host and PDSP.
>
> There was an issue raised when merging the original patch set at
>   (1) https://lkml.org/lkml/2015/9/4/681
> 	[PATCH v1 1/2] soc: ti: display firmware file name as part of boot log
>   (2) https://lkml.org/lkml/2015/9/4/680
> 	[PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels
>
> This series fixes the issues raised against v3. Maintainer, could you please
> apply this series to v4.4 next please at your earliest opportunity.
>
I have picked up the series. Thanks for quick turnaround.

Regards,
Santosh

Re: [PATCH v4 0/3]

[Murali Karicheri]

On 10/14/2015 11:41 AM, santosh shilimkar wrote:
> 10/14/2015 7:17 AM, Murali Karicheri wrote:
>> This patch series enable accumulator queue support for K2 SoCs.
>> Accumulator
>> queues are a type of qmss queue that is monitored by the PDSP firmware
>> and
>> accumulated. Host is interrupted by PDSP firmware when packets become
>> available in a ring buffer shared between the host and PDSP.
>>
>> There was an issue raised when merging the original patch set at
>>   (1) https://lkml.org/lkml/2015/9/4/681
>>     [PATCH v1 1/2] soc: ti: display firmware file name as part of boot
>> log
>>   (2) https://lkml.org/lkml/2015/9/4/680
>>     [PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels
>>
>> This series fixes the issues raised against v3. Maintainer, could you
>> please
>> apply this series to v4.4 next please at your earliest opportunity.
>>
> I have picked up the series. Thanks for quick turnaround.

Thanks Santosh. Could you send this pull request for v4.4 next. We want 
this merged to our internal release and if this is on next branch it 
will help.

Thanks

Murali
>
> Regards,
> Santosh
>
>


-- 
Murali Karicheri
Linux Kernel, Keystone

[PATCH v4 0/3]

[Murali Karicheri]

On 10/14/2015 11:41 AM, santosh shilimkar wrote:
> 10/14/2015 7:17 AM, Murali Karicheri wrote:
>> This patch series enable accumulator queue support for K2 SoCs.
>> Accumulator
>> queues are a type of qmss queue that is monitored by the PDSP firmware
>> and
>> accumulated. Host is interrupted by PDSP firmware when packets become
>> available in a ring buffer shared between the host and PDSP.
>>
>> There was an issue raised when merging the original patch set at
>>   (1) https://lkml.org/lkml/2015/9/4/681
>>     [PATCH v1 1/2] soc: ti: display firmware file name as part of boot
>> log
>>   (2) https://lkml.org/lkml/2015/9/4/680
>>     [PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels
>>
>> This series fixes the issues raised against v3. Maintainer, could you
>> please
>> apply this series to v4.4 next please at your earliest opportunity.
>>
> I have picked up the series. Thanks for quick turnaround.

Thanks Santosh. Could you send this pull request for v4.4 next. We want 
this merged to our internal release and if this is on next branch it 
will help.

Thanks

Murali
>
> Regards,
> Santosh
>
>


-- 
Murali Karicheri
Linux Kernel, Keystone

Re: [PATCH v4 0/3]

[Murali Karicheri]

On 10/14/2015 11:41 AM, santosh shilimkar wrote:
> 10/14/2015 7:17 AM, Murali Karicheri wrote:
>> This patch series enable accumulator queue support for K2 SoCs.
>> Accumulator
>> queues are a type of qmss queue that is monitored by the PDSP firmware
>> and
>> accumulated. Host is interrupted by PDSP firmware when packets become
>> available in a ring buffer shared between the host and PDSP.
>>
>> There was an issue raised when merging the original patch set at
>>   (1) https://lkml.org/lkml/2015/9/4/681
>>     [PATCH v1 1/2] soc: ti: display firmware file name as part of boot
>> log
>>   (2) https://lkml.org/lkml/2015/9/4/680
>>     [PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels
>>
>> This series fixes the issues raised against v3. Maintainer, could you
>> please
>> apply this series to v4.4 next please at your earliest opportunity.
>>
> I have picked up the series. Thanks for quick turnaround.

Thanks Santosh. Could you send this pull request for v4.4 next. We want 
this merged to our internal release and if this is on next branch it 
will help.

Thanks

Murali
>
> Regards,
> Santosh
>
>


-- 
Murali Karicheri
Linux Kernel, Keystone

Re: [PATCH v4 0/3]

[santosh shilimkar]

On 10/15/2015 9:02 AM, Murali Karicheri wrote:
> On 10/14/2015 11:41 AM, santosh shilimkar wrote:
>> 10/14/2015 7:17 AM, Murali Karicheri wrote:
>>> This patch series enable accumulator queue support for K2 SoCs.
>>> Accumulator
>>> queues are a type of qmss queue that is monitored by the PDSP firmware
>>> and
>>> accumulated. Host is interrupted by PDSP firmware when packets become
>>> available in a ring buffer shared between the host and PDSP.
>>>
>>> There was an issue raised when merging the original patch set at
>>>   (1) https://lkml.org/lkml/2015/9/4/681
>>>     [PATCH v1 1/2] soc: ti: display firmware file name as part of boot
>>> log
>>>   (2) https://lkml.org/lkml/2015/9/4/680
>>>     [PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels
>>>
>>> This series fixes the issues raised against v3. Maintainer, could you
>>> please
>>> apply this series to v4.4 next please at your earliest opportunity.
>>>
>> I have picked up the series. Thanks for quick turnaround.
>
> Thanks Santosh. Could you send this pull request for v4.4 next. We want
> this merged to our internal release and if this is on next branch it
> will help.
>
It should be already in linux-next and pull request was sent before I
replied yesterday. Its late for the merge window with usual norms
so lets see if it makes it.

Regards,
Santosh

[PATCH v4 0/3]

[santosh shilimkar]

On 10/15/2015 9:02 AM, Murali Karicheri wrote:
> On 10/14/2015 11:41 AM, santosh shilimkar wrote:
>> 10/14/2015 7:17 AM, Murali Karicheri wrote:
>>> This patch series enable accumulator queue support for K2 SoCs.
>>> Accumulator
>>> queues are a type of qmss queue that is monitored by the PDSP firmware
>>> and
>>> accumulated. Host is interrupted by PDSP firmware when packets become
>>> available in a ring buffer shared between the host and PDSP.
>>>
>>> There was an issue raised when merging the original patch set at
>>>   (1) https://lkml.org/lkml/2015/9/4/681
>>>     [PATCH v1 1/2] soc: ti: display firmware file name as part of boot
>>> log
>>>   (2) https://lkml.org/lkml/2015/9/4/680
>>>     [PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels
>>>
>>> This series fixes the issues raised against v3. Maintainer, could you
>>> please
>>> apply this series to v4.4 next please at your earliest opportunity.
>>>
>> I have picked up the series. Thanks for quick turnaround.
>
> Thanks Santosh. Could you send this pull request for v4.4 next. We want
> this merged to our internal release and if this is on next branch it
> will help.
>
It should be already in linux-next and pull request was sent before I
replied yesterday. Its late for the merge window with usual norms
so lets see if it makes it.

Regards,
Santosh

Re: [PATCH v4 0/3]

[santosh shilimkar]

On 10/15/2015 9:02 AM, Murali Karicheri wrote:
> On 10/14/2015 11:41 AM, santosh shilimkar wrote:
>> 10/14/2015 7:17 AM, Murali Karicheri wrote:
>>> This patch series enable accumulator queue support for K2 SoCs.
>>> Accumulator
>>> queues are a type of qmss queue that is monitored by the PDSP firmware
>>> and
>>> accumulated. Host is interrupted by PDSP firmware when packets become
>>> available in a ring buffer shared between the host and PDSP.
>>>
>>> There was an issue raised when merging the original patch set at
>>>   (1) https://lkml.org/lkml/2015/9/4/681
>>>     [PATCH v1 1/2] soc: ti: display firmware file name as part of boot
>>> log
>>>   (2) https://lkml.org/lkml/2015/9/4/680
>>>     [PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels
>>>
>>> This series fixes the issues raised against v3. Maintainer, could you
>>> please
>>> apply this series to v4.4 next please at your earliest opportunity.
>>>
>> I have picked up the series. Thanks for quick turnaround.
>
> Thanks Santosh. Could you send this pull request for v4.4 next. We want
> this merged to our internal release and if this is on next branch it
> will help.
>
It should be already in linux-next and pull request was sent before I
replied yesterday. Its late for the merge window with usual norms
so lets see if it makes it.

Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 0/3]

[Murali Karicheri]

On 10/15/2015 12:21 PM, santosh shilimkar wrote:
> On 10/15/2015 9:02 AM, Murali Karicheri wrote:
>> On 10/14/2015 11:41 AM, santosh shilimkar wrote:
>>> 10/14/2015 7:17 AM, Murali Karicheri wrote:
>>>> This patch series enable accumulator queue support for K2 SoCs.
>>>> Accumulator
>>>> queues are a type of qmss queue that is monitored by the PDSP firmware
>>>> and
>>>> accumulated. Host is interrupted by PDSP firmware when packets become
>>>> available in a ring buffer shared between the host and PDSP.
>>>>
>>>> There was an issue raised when merging the original patch set at
>>>>   (1) https://lkml.org/lkml/2015/9/4/681
>>>>     [PATCH v1 1/2] soc: ti: display firmware file name as part of boot
>>>> log
>>>>   (2) https://lkml.org/lkml/2015/9/4/680
>>>>     [PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels
>>>>
>>>> This series fixes the issues raised against v3. Maintainer, could you
>>>> please
>>>> apply this series to v4.4 next please at your earliest opportunity.
>>>>
>>> I have picked up the series. Thanks for quick turnaround.
>>
>> Thanks Santosh. Could you send this pull request for v4.4 next. We want
>> this merged to our internal release and if this is on next branch it
>> will help.
>>
> It should be already in linux-next and pull request was sent before I
> replied yesterday. Its late for the merge window with usual norms
> so lets see if it makes it.
Santosh,

I see both driver and DTS. Thanks once again for your support

Regards,

Murali
>
> Regards,
> Santosh
>
>


-- 
Murali Karicheri
Linux Kernel, Keystone

[PATCH v4 0/3]

[Murali Karicheri]

On 10/15/2015 12:21 PM, santosh shilimkar wrote:
> On 10/15/2015 9:02 AM, Murali Karicheri wrote:
>> On 10/14/2015 11:41 AM, santosh shilimkar wrote:
>>> 10/14/2015 7:17 AM, Murali Karicheri wrote:
>>>> This patch series enable accumulator queue support for K2 SoCs.
>>>> Accumulator
>>>> queues are a type of qmss queue that is monitored by the PDSP firmware
>>>> and
>>>> accumulated. Host is interrupted by PDSP firmware when packets become
>>>> available in a ring buffer shared between the host and PDSP.
>>>>
>>>> There was an issue raised when merging the original patch set at
>>>>   (1) https://lkml.org/lkml/2015/9/4/681
>>>>     [PATCH v1 1/2] soc: ti: display firmware file name as part of boot
>>>> log
>>>>   (2) https://lkml.org/lkml/2015/9/4/680
>>>>     [PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels
>>>>
>>>> This series fixes the issues raised against v3. Maintainer, could you
>>>> please
>>>> apply this series to v4.4 next please at your earliest opportunity.
>>>>
>>> I have picked up the series. Thanks for quick turnaround.
>>
>> Thanks Santosh. Could you send this pull request for v4.4 next. We want
>> this merged to our internal release and if this is on next branch it
>> will help.
>>
> It should be already in linux-next and pull request was sent before I
> replied yesterday. Its late for the merge window with usual norms
> so lets see if it makes it.
Santosh,

I see both driver and DTS. Thanks once again for your support

Regards,

Murali
>
> Regards,
> Santosh
>
>


-- 
Murali Karicheri
Linux Kernel, Keystone

Re: [PATCH v4 0/3]

[Murali Karicheri]

On 10/15/2015 12:21 PM, santosh shilimkar wrote:
> On 10/15/2015 9:02 AM, Murali Karicheri wrote:
>> On 10/14/2015 11:41 AM, santosh shilimkar wrote:
>>> 10/14/2015 7:17 AM, Murali Karicheri wrote:
>>>> This patch series enable accumulator queue support for K2 SoCs.
>>>> Accumulator
>>>> queues are a type of qmss queue that is monitored by the PDSP firmware
>>>> and
>>>> accumulated. Host is interrupted by PDSP firmware when packets become
>>>> available in a ring buffer shared between the host and PDSP.
>>>>
>>>> There was an issue raised when merging the original patch set at
>>>>   (1) https://lkml.org/lkml/2015/9/4/681
>>>>     [PATCH v1 1/2] soc: ti: display firmware file name as part of boot
>>>> log
>>>>   (2) https://lkml.org/lkml/2015/9/4/680
>>>>     [PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels
>>>>
>>>> This series fixes the issues raised against v3. Maintainer, could you
>>>> please
>>>> apply this series to v4.4 next please at your earliest opportunity.
>>>>
>>> I have picked up the series. Thanks for quick turnaround.
>>
>> Thanks Santosh. Could you send this pull request for v4.4 next. We want
>> this merged to our internal release and if this is on next branch it
>> will help.
>>
> It should be already in linux-next and pull request was sent before I
> replied yesterday. Its late for the merge window with usual norms
> so lets see if it makes it.
Santosh,

I see both driver and DTS. Thanks once again for your support

Regards,

Murali
>
> Regards,
> Santosh
>
>


-- 
Murali Karicheri
Linux Kernel, Keystone

Re: [PATCH/v3] bundle.c: added --stdin option to git-bundle

[Junio C Hamano]

"Adam Brewster" <adambrewster@gmail.com> writes:

> Subject: Re: [PATCH/v3] bundle.c: added --stdin option to git-bundle

When the change is not about implementation detail (in which case you do
want to name the source file and perhaps even a function name), but about
a new feature that is visible to the end-users of a command, we'd want the
message talk in terms of what the new feature does, not how the new
feature is invoked nor where it is implemented.  In other words, something
like these are preferred:

	git-bundle: add --stdin
        Teach git-bundle to read tips and basis from standard input

and don't say "You did" in past tense --- say things in imperative mood
instead, as if you are commanding the person who applies the patch to make
it happen.  Older log entries in our history (e.g. "git log -n 20 v0.99")
may give you a better feel.

And give a few lines of obvious justfication in the body of the commit log
message, e.g.

	This patch allows the caller to feed the revision parameters to
	git-bundle from its standard input.  This way, a script do not
	have to worry about limitation of the length of command line.

to explain why this is good.  In order to explain that you may have to
talk about other things (like what it does and how it does it), but keep
in mind that the primary thing you should talk about is _why_.

> ... because it already implies that this option is available.

If that is the case, please mention in the commit log message something
like "Even though the documentation said "bundle --stdin" is accepted it
didn't.  This patch teaches the option to the command".

But I do not think there is no such implication.  "bundle create" may take
list of positive and negative refs as arguments or --branches, but it does
not take (and it shouldn't -- I do not think it should take --bisect
option, for example) artibrary options that rev-list command accepts.

>  bundle.c |   22 ++++++++++++++++++++--
>  1 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/bundle.c b/bundle.c
> index 0ba5df1..b44a4af 100644
> --- a/bundle.c
> +++ b/bundle.c
> @@ -227,8 +227,26 @@ int create_bundle(struct bundle_header *header,
> const char *path,

Wrapped.

>         /* write references */
>         argc = setup_revisions(argc, argv, &revs, NULL);
> -       if (argc > 1)
> -               return error("unrecognized argument: %s'", argv[1]);
> +
> +       for (i = 1; i < argc; i++) {
> +               if ( !strcmp(argv[i], "--stdin") ) {

Style.

> +                       char line[1000];
> +                               while (fgets(line, sizeof(line),
> stdin) != NULL) {

Too deep indentation.  Wrapped.

> +                               int len = strlen(line);
> +                               if (len && line[len - 1] == '\n')
> +                                       line[--len] = '\0';
> +                               if (!len)
> +                                       break;
> +                               if (line[0] == '-')
> +                                       die("options not supported in
> --stdin mode");
> +                               if (handle_revision_arg(line, &revs, 0, 1))
> +                                       die("bad revision '%s'", line);
> +                       }
> +                       continue;
> +               }
> +
> +               return error("unrecognized argument: %s'", argv[i]);
> +       }

Having said that, I think copying and pasting read_revisions_from_stdin()
in bundle.c is a wrong approach to take.  Probably the function can easily
be split out of builtin-rev-list.c and moved to revision.c or somewhere
(which will be the first patch), and then a separate patch can add a few
lines to call it from bundle.c.

[PATCH v4 0/3]

[Adam Brewster]

Sorry for the idiotic wrapping problems in my last email.

Previously, I was trying to keep from changing any of the important stuff,
like git-rev-list, but I should know better than cut-and-pasting code.

As requested, I've broken the change into a multiple of patches.  First moving
read_revisions_from_stdin to revision.c, next modifying git-bundle to handle
--stdin, and finally a patch adding my old git-basis to contrib.

I think I've corrected all of the style issues you pointed out, and I've also 
tried to craft more informative commit messages.