Re: [PATCH v4] usb: dwc2: dwc2_vbus_supply_init: fix error check

[Tomeu Vizoso]

Hi,

could this patch be picked up, please? Or if for some reason it cannot
be, could the commit that introduced the regression be reverted?

It's causing some tests in KernelCI to fail:

https://storage.kernelci.org/next/master/next-20180423/arm/multi_v7_defconfig/lab-collabora/sleep-rk3288-veyron-jaq.html

Thanks,

Tomeu


On 11 April 2018 at 08:50, Minas Harutyunyan
<minas.harutyun...@synopsys.com> wrote:
> Hi Heiko,
>
> On 4/10/2018 7:37 PM, Heiko Stübner wrote:
>> Am Dienstag, 10. April 2018, 15:52:25 CEST schrieb Minas Harutyunyan:
>>> Hi Heiko,
>>>
>>> On 4/10/2018 4:28 PM, Heiko Stuebner wrote:
>>>> Am Montag, 26. März 2018, 11:00:01 CEST schrieb Tomeu Vizoso:
>>>>> devm_regulator_get_optional returns -ENODEV if the regulator isn't
>>>>> there, so if that's the case we have to make sure not to leave -ENODEV
>>>>> in the regulator pointer.
>>>>>
>>>>> Also, make sure we return 0 in that case, but correctly propagate any
>>>>> other errors. Also propagate the error from _dwc2_hcd_start.
>>>>>
>>>>> Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus
>>>>> supply") Cc: Amelie Delaunay <amelie.delau...@st.com>
>>>>> Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com>
>>>>
>>>> The patch that gets fixed here also breaks display-output on dwc2-based
>>>> Rockchip devices (likely even more), probably due to making the regulator
>>>> framework hickup.
>>>
>>> Could you please elaborate what mean "breaks display-output".
>>> On which Kernel version you apply this patch?
>>
>> I think I may have written that poorly. _Without_ this patch I get
>> display breakage on the most recent torvalds/master (merge-window)
>> where "usb: dwc2: add support for host mode external vbus supply" is
>> applied and this patch fixes the issue.
>>
>> "breaks display output" means both hdmi + edp output are missing
>> also including the backlight staying off.
>>
>> The patch we're fixing here, causes a null-pointer dereference in the
>> regulator framework, which seems to also cause issues when other
>> regulators are enabled, which I think is what I'm seeing here.
>>
>>
> Thank you for clarification. Earlier you added "reviewed" tag, this
> feedback can assumed as "tested" tag.
>
> Thanks,
> Minas
>
>> Heiko
>>
>>>
>>> Thanks,
>>> Minas
>>>
>>>> With this patch applied, apart from not seeing the NULL-ptr, I also get
>>>> display output on my rk3288-veycron Chromebook again, so
>>>>
>>>> Tested-by: Heiko Stuebner <he...@sntech.de>
>>>>
>>>>> v2: Only overwrite the error in the pointer after checking it (Heiko
>>>>>
>>>>>   Stübner <he...@sntech.de>)
>>>>>
>>>>> v3: Remove hunks that shouldn't be in this patch
>>>>> v4: Don't overwrite the error code before returning it (kbuild test
>>>>>
>>>>>   robot <l...@intel.com>)
>>>>>
>>>>> ---
>>>>>
>>>>>drivers/usb/dwc2/hcd.c | 13 -
>>>>>1 file changed, 8 insertions(+), 5 deletions(-)
>>>>>
>>>>> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
>>>>> index 190f95964000..c51b73b3e048 100644
>>>>> --- a/drivers/usb/dwc2/hcd.c
>>>>> +++ b/drivers/usb/dwc2/hcd.c
>>>>> @@ -358,9 +358,14 @@ static void dwc2_gusbcfg_init(struct dwc2_hsotg
>>>>> *hsotg)>>
>>>>>static int dwc2_vbus_supply_init(struct dwc2_hsotg *hsotg)
>>>>>{
>>>>>
>>>>> +  int ret;
>>>>> +
>>>>>
>>>>>hsotg->vbus_supply = devm_regulator_get_optional(hsotg->dev, 
>>>>> "vbus");
>>>>>
>>>>> -  if (IS_ERR(hsotg->vbus_supply))
>>>>> -  return 0;
>>>>> +  if (IS_ERR(hsotg->vbus_supply)) {
>>>>> +  ret = PTR_ERR(hsotg->vbus_supply);
>>>>> +  hsotg->vbus_supply = NULL;
>>>>> +  return ret == -ENODEV ? 0 : ret;
>>>>> +  }
>>>>>
>>>>>return regulator_enable(hsotg->vbus_supply);
>>>>>
>>>>>}
>>>>>
>>>>> @@ -4342,9 +4347,7 @@ static int _dwc2_hcd_start(struct usb_hcd *hcd)
>>>>>
>>>>>spin_unlock_irqrestore(>lock, flags);
>>>>>
>>>>> -  dwc2_vbus_supply_init(hsotg);
>>>>> -
>>>>> -  return 0;
>>>>> +  return dwc2_vbus_supply_init(hsotg);
>>>>>
>>>>>}
>>>>>
>>>>>/*
>>
>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] usb: dwc2: dwc2_vbus_supply_init: fix error check

[Tomeu Vizoso]

Hi Minas,

On 04/05/2018 09:54 AM, Minas Harutyunyan wrote:

Hi Tomeu,

On 3/26/2018 1:01 PM, Tomeu Vizoso wrote:

devm_regulator_get_optional returns -ENODEV if the regulator isn't
there, so if that's the case we have to make sure not to leave -ENODEV
in the regulator pointer.

Also, make sure we return 0 in that case, but correctly propagate any
other errors. Also propagate the error from _dwc2_hcd_start.

Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus 
supply")
Cc: Amelie Delaunay <amelie.delau...@st.com>
Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com>

---

v2: Only overwrite the error in the pointer after checking it (Heiko
  Stübner <he...@sntech.de>)
v3: Remove hunks that shouldn't be in this patch
v4: Don't overwrite the error code before returning it (kbuild test
  robot <l...@intel.com>)
---
   drivers/usb/dwc2/hcd.c | 13 -
   1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 190f95964000..c51b73b3e048 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -358,9 +358,14 @@ static void dwc2_gusbcfg_init(struct dwc2_hsotg *hsotg)
   
   static int dwc2_vbus_supply_init(struct dwc2_hsotg *hsotg)

   {
+   int ret;
+
hsotg->vbus_supply = devm_regulator_get_optional(hsotg->dev, "vbus");
-   if (IS_ERR(hsotg->vbus_supply))
-   return 0;
+   if (IS_ERR(hsotg->vbus_supply)) {
+   ret = PTR_ERR(hsotg->vbus_supply);
+   hsotg->vbus_supply = NULL;
+   return ret == -ENODEV ? 0 : ret;
+   }
   
   	return regulator_enable(hsotg->vbus_supply);

   }
@@ -4342,9 +4347,7 @@ static int _dwc2_hcd_start(struct usb_hcd *hcd)
   
   	spin_unlock_irqrestore(>lock, flags);
   
-	dwc2_vbus_supply_init(hsotg);

-
-   return 0;
+   return dwc2_vbus_supply_init(hsotg);
   }
   
   /*




Not able to apply patch. Please rebase to balbi/next


Are you sure? Just rebased and the resulting patch is identical to what 
was sent.


Thanks,

Tomeu
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] usb: dwc2: dwc2_vbus_supply_init: fix error check

[Tomeu Vizoso]

Could this patch be picked up, please?

Thanks,

Tomeu

On 26 March 2018 at 13:51, Heiko Stübner <he...@sntech.de> wrote:
> Am Montag, 26. März 2018, 11:00:01 CEST schrieb Tomeu Vizoso:
>> devm_regulator_get_optional returns -ENODEV if the regulator isn't
>> there, so if that's the case we have to make sure not to leave -ENODEV
>> in the regulator pointer.
>>
>> Also, make sure we return 0 in that case, but correctly propagate any
>> other errors. Also propagate the error from _dwc2_hcd_start.
>>
>> Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus
>> supply") Cc: Amelie Delaunay <amelie.delau...@st.com>
>> Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com>
>
> Reviewed-by: Heiko Stuebner <he...@sntech.de>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4] usb: dwc2: dwc2_vbus_supply_init: fix error check

[Tomeu Vizoso]

devm_regulator_get_optional returns -ENODEV if the regulator isn't
there, so if that's the case we have to make sure not to leave -ENODEV
in the regulator pointer.

Also, make sure we return 0 in that case, but correctly propagate any
other errors. Also propagate the error from _dwc2_hcd_start.

Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus 
supply")
Cc: Amelie Delaunay <amelie.delau...@st.com>
Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com>

---

v2: Only overwrite the error in the pointer after checking it (Heiko
Stübner <he...@sntech.de>)
v3: Remove hunks that shouldn't be in this patch
v4: Don't overwrite the error code before returning it (kbuild test
robot <l...@intel.com>)
---
 drivers/usb/dwc2/hcd.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 190f95964000..c51b73b3e048 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -358,9 +358,14 @@ static void dwc2_gusbcfg_init(struct dwc2_hsotg *hsotg)
 
 static int dwc2_vbus_supply_init(struct dwc2_hsotg *hsotg)
 {
+   int ret;
+
hsotg->vbus_supply = devm_regulator_get_optional(hsotg->dev, "vbus");
-   if (IS_ERR(hsotg->vbus_supply))
-   return 0;
+   if (IS_ERR(hsotg->vbus_supply)) {
+   ret = PTR_ERR(hsotg->vbus_supply);
+   hsotg->vbus_supply = NULL;
+   return ret == -ENODEV ? 0 : ret;
+   }
 
return regulator_enable(hsotg->vbus_supply);
 }
@@ -4342,9 +4347,7 @@ static int _dwc2_hcd_start(struct usb_hcd *hcd)
 
spin_unlock_irqrestore(>lock, flags);
 
-   dwc2_vbus_supply_init(hsotg);
-
-   return 0;
+   return dwc2_vbus_supply_init(hsotg);
 }
 
 /*
-- 
2.14.3

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: hub: Reduce warning to notice on power loss

[Tomeu Vizoso]

Currently we warn the user when the root hub lost power after resume,
but the user cannot do anything about it so it should probably be a
notice.

This will reduce the noise in the console during suspend and resume,
which is already quite significant in many systems.

Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com>
---
 drivers/usb/core/hub.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index ac7bab772a3a..5964008003b4 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3655,7 +3655,7 @@ static int hub_reset_resume(struct usb_interface *intf)
  */
 void usb_root_hub_lost_power(struct usb_device *rhdev)
 {
-   dev_warn(>dev, "root hub lost power or was reset\n");
+   dev_notice(>dev, "root hub lost power or was reset\n");
rhdev->reset_resume = 1;
 }
 EXPORT_SYMBOL_GPL(usb_root_hub_lost_power);
-- 
2.14.3

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] usb: dwc2: dwc2_vbus_supply_init: fix error check

[Tomeu Vizoso]

On 03/22/2018 02:26 PM, Heiko Stübner wrote:

Am Donnerstag, 22. März 2018, 14:14:51 CET schrieb Tomeu Vizoso:

devm_regulator_get_optional returns -ENODEV if the regulator isn't
there, so if that's the case we have to make sure not to leave -ENODEV
in the regulator pointer.

Also, make sure we return 0 in that case, but correctly propagate any
other errors. Also propagate the error from _dwc2_hcd_start.

Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus
supply") Cc: Amelie Delaunay <amelie.delau...@st.com>
Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com>

---

v2: Only overwrite the error in the pointer after checking it (Heiko
 Stübner <he...@sntech.de>)
v3: Remove hunks that shouldn't be in this patch
---
  drivers/usb/dwc2/hcd.c | 11 +++
  1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index dcfda5eb4cac..863aed20517f 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -359,8 +359,13 @@ static void dwc2_gusbcfg_init(struct dwc2_hsotg *hsotg)
static int dwc2_vbus_supply_init(struct dwc2_hsotg *hsotg)
  {
hsotg->vbus_supply = devm_regulator_get_optional(hsotg->dev, "vbus");
-   if (IS_ERR(hsotg->vbus_supply))
+   if (PTR_ERR(hsotg->vbus_supply) == -ENODEV) {
+   hsotg->vbus_supply = NULL;
return 0;
+   } else if (IS_ERR(hsotg->vbus_supply)) {
+   hsotg->vbus_supply = NULL;
+   return PTR_ERR(hsotg->vbus_supply);
+   }


my personal cluelessnes, but can you use PTR_ERR without checking for
IS_ERR first?


It's just a cast, so it should be fine.


I would've expected something along the line of

if (IS_ERR(hsotg->vbus_supply)) {
if (PTR_ERR(hsotg->vbus_supply) == -ENODEV) {
hsotg->vbus_supply = NULL;
return 0;
} else {
return PTR_ERR(hsotg->vbus_supply);
}
}


I kind of liked to avoid one indentation level. Also wanted to play safe 
and NULLify the pointer in both code paths.


Thanks,

Tomeu
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3] usb: dwc2: dwc2_vbus_supply_init: fix error check

[Tomeu Vizoso]

devm_regulator_get_optional returns -ENODEV if the regulator isn't
there, so if that's the case we have to make sure not to leave -ENODEV
in the regulator pointer.

Also, make sure we return 0 in that case, but correctly propagate any
other errors. Also propagate the error from _dwc2_hcd_start.

Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus 
supply")
Cc: Amelie Delaunay <amelie.delau...@st.com>
Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com>

---

v2: Only overwrite the error in the pointer after checking it (Heiko
Stübner <he...@sntech.de>)
v3: Remove hunks that shouldn't be in this patch
---
 drivers/usb/dwc2/hcd.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index dcfda5eb4cac..863aed20517f 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -359,8 +359,13 @@ static void dwc2_gusbcfg_init(struct dwc2_hsotg *hsotg)
 static int dwc2_vbus_supply_init(struct dwc2_hsotg *hsotg)
 {
hsotg->vbus_supply = devm_regulator_get_optional(hsotg->dev, "vbus");
-   if (IS_ERR(hsotg->vbus_supply))
+   if (PTR_ERR(hsotg->vbus_supply) == -ENODEV) {
+   hsotg->vbus_supply = NULL;
return 0;
+   } else if (IS_ERR(hsotg->vbus_supply)) {
+   hsotg->vbus_supply = NULL;
+   return PTR_ERR(hsotg->vbus_supply);
+   }
 
return regulator_enable(hsotg->vbus_supply);
 }
@@ -4342,9 +4347,7 @@ static int _dwc2_hcd_start(struct usb_hcd *hcd)
 
spin_unlock_irqrestore(>lock, flags);
 
-   dwc2_vbus_supply_init(hsotg);
-
-   return 0;
+   return dwc2_vbus_supply_init(hsotg);
 }
 
 /*
-- 
2.14.3

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] usb: dwc2: dwc2_vbus_supply_init: fix error check

[Tomeu Vizoso]

devm_regulator_get_optional returns -ENODEV if the regulator isn't
there, so if that's the case we have to make sure not to leave -ENODEV
in the regulator pointer.

Also, make sure we return 0 in that case, but correctly propagate any
other errors. Also propagate the error from _dwc2_hcd_start.

Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus 
supply")
Cc: Amelie Delaunay <amelie.delau...@st.com>
Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com>

---

v2: Only overwrite the error in the pointer after checking it (Heiko
Stübner <he...@sntech.de>)
---
 arch/arm/configs/multi_v7_defconfig |  3 +++
 drivers/usb/dwc2/hcd.c  | 11 +++
 scripts/setlocalversion |  9 -
 3 files changed, 10 insertions(+), 13 deletions(-)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 846ce7bb24bc..33148fcabd17 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -1029,3 +1029,6 @@ CONFIG_VIRTIO=y
 CONFIG_VIRTIO_PCI=y
 CONFIG_VIRTIO_PCI_LEGACY=y
 CONFIG_VIRTIO_MMIO=y
+CONFIG_LOCALVERSION_AUTO=n
+CONFIG_LOCALVERSION=""
+
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index dcfda5eb4cac..863aed20517f 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -359,8 +359,13 @@ static void dwc2_gusbcfg_init(struct dwc2_hsotg *hsotg)
 static int dwc2_vbus_supply_init(struct dwc2_hsotg *hsotg)
 {
hsotg->vbus_supply = devm_regulator_get_optional(hsotg->dev, "vbus");
-   if (IS_ERR(hsotg->vbus_supply))
+   if (PTR_ERR(hsotg->vbus_supply) == -ENODEV) {
+   hsotg->vbus_supply = NULL;
return 0;
+   } else if (IS_ERR(hsotg->vbus_supply)) {
+   hsotg->vbus_supply = NULL;
+   return PTR_ERR(hsotg->vbus_supply);
+   }
 
return regulator_enable(hsotg->vbus_supply);
 }
@@ -4342,9 +4347,7 @@ static int _dwc2_hcd_start(struct usb_hcd *hcd)
 
spin_unlock_irqrestore(>lock, flags);
 
-   dwc2_vbus_supply_init(hsotg);
-
-   return 0;
+   return dwc2_vbus_supply_init(hsotg);
 }
 
 /*
diff --git a/scripts/setlocalversion b/scripts/setlocalversion
index 71f39410691b..cbc36d3b4d0f 100755
--- a/scripts/setlocalversion
+++ b/scripts/setlocalversion
@@ -161,15 +161,6 @@ res="${res}${CONFIG_LOCALVERSION}${LOCALVERSION}"
 if test "$CONFIG_LOCALVERSION_AUTO" = "y"; then
# full scm version string
res="$res$(scm_version)"
-else
-   # append a plus sign if the repository is not in a clean
-   # annotated or signed tagged state (as git describe only
-   # looks at signed or annotated tags - git tag -a/-s) and
-   # LOCALVERSION= is not specified
-   if test "${LOCALVERSION+set}" != "set"; then
-   scm=$(scm_version --short)
-   res="$res${scm:++}"
-   fi
 fi
 
 echo "$res"
-- 
2.14.3

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: dwc2: dwc2_vbus_supply_init: fix error check

[Tomeu Vizoso]

devm_regulator_get_optional returns -ENODEV if the regulator isn't
there, so if that's the case we have to make sure not to leave -ENODEV
in the regulator pointer.

Also, make sure we return 0 in that case, but correctly propagate any
other errors. Also propagate the error from _dwc2_hcd_start.

Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus 
supply")
Cc: Amelie Delaunay <amelie.delau...@st.com>
Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com>
---
 drivers/usb/dwc2/hcd.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index dcfda5eb4cac..4ae211f65e85 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -359,8 +359,13 @@ static void dwc2_gusbcfg_init(struct dwc2_hsotg *hsotg)
 static int dwc2_vbus_supply_init(struct dwc2_hsotg *hsotg)
 {
hsotg->vbus_supply = devm_regulator_get_optional(hsotg->dev, "vbus");
-   if (IS_ERR(hsotg->vbus_supply))
-   return 0;
+   if (IS_ERR(hsotg->vbus_supply)) {
+   hsotg->vbus_supply = NULL;
+   if (PTR_ERR(hsotg->vbus_supply) == -ENODEV)
+   return 0;
+   else
+   return PTR_ERR(hsotg->vbus_supply);
+   }
 
return regulator_enable(hsotg->vbus_supply);
 }
@@ -4342,9 +4347,7 @@ static int _dwc2_hcd_start(struct usb_hcd *hcd)
 
spin_unlock_irqrestore(>lock, flags);
 
-   dwc2_vbus_supply_init(hsotg);
-
-   return 0;
+   return dwc2_vbus_supply_init(hsotg);
 }
 
 /*
-- 
2.14.3

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v12 0/4] Allow USB devices to remain runtime-suspended when sleeping

[Tomeu Vizoso]

Hi,

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

For this, we interpret the absence of all PM callback implementations as
it being safe to do direct_complete, so their ancestors aren't prevented
from remaining runtime-suspended.

Additionally, the prepare() callback of USB devices will return 1 if
runtime PM is enabled and the current wakeup settings are correct.

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

Changes in v12:
- Include linux/pm_domain.h in vga_switcheroo.c for dev_pm_domain_set()

Changes in v11:
- Move calls to dev_pm_domain_set() out from >power.lock as that
  isn't needed for dev->pm_domain.

Changes in v10:
- Remove superfluous call to pm_runtime_enabled() as suggested by Alan

Changes in v9:
- Add docs noting the need for the device lock to be held before calling
  device_is_bound()
- Add docs noting the need for the device lock to be held before calling
  dev_pm_domain_set()
- Move to CONFIG_PM_SLEEP as suggested by Rafael and Ulf.
- Rename from device_check_pm_callbacks to device_pm_check_callbacks to
  follow with the naming convention of existing API.
- Re-add calling to device_pm_check_callbacks from device registration
  and when updating the PM domain of a device.

Changes in v8:
- Add device_is_bound()
- Add dev_pm_domain_set() and update code to use it
- Move no_pm_callbacks field into CONFIG_PM_SLEEP
- Call device_check_pm_callbacks only after a device is bound or unbound

Changes in v7:
- Reduce indentation by adding a label in device_prepare()

Changes in v6:
- Add stub for !CONFIG_PM.
- Move implementation of device_check_pm_callbacks to power/main.c as it
  doesn't belong to CONFIG_PM_SLEEP.
- Take dev->power.lock before modifying flag.

Changes in v5:
- Check for all dev_pm_ops instances associated to a device, updating a
  no_pm_callbacks flag at the times when that could change.

Tomeu Vizoso (4):
  device core: add device_is_bound()
  PM / Domains: add setter for dev.pm_domain
  PM / sleep: Go direct_complete if driver has no callbacks
  USB / PM: Allow USB devices to remain runtime-suspended when sleeping

 arch/arm/mach-omap2/omap_device.c |  7 ---
 drivers/acpi/acpi_lpss.c  |  5 -
 drivers/acpi/device_pm.c  |  5 +++--
 drivers/base/dd.c | 21 +++--
 drivers/base/power/clock_ops.c|  5 +++--
 drivers/base/power/common.c   | 24 
 drivers/base/power/domain.c   |  8 ++--
 drivers/base/power/main.c | 35 +++
 drivers/base/power/power.h|  3 +++
 drivers/gpu/vga/vga_switcheroo.c  | 11 ++-
 drivers/misc/mei/pci-me.c |  5 +++--
 drivers/misc/mei/pci-txe.c|  5 +++--
 drivers/usb/core/port.c   |  6 ++
 drivers/usb/core/usb.c|  8 +++-
 include/linux/device.h|  2 ++
 include/linux/pm.h|  1 +
 include/linux/pm_domain.h |  3 +++
 17 files changed, 132 insertions(+), 22 deletions(-)

-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v12 4/4] 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.viz...@collabora.com>
Reviewed-by: Ulf Hansson <ulf.hans...@linaro.org>
Acked-by: Alan Stern <st...@rowland.harvard.edu>
---

Changes in v10:
- Remove superfluous call to pm_runtime_enabled() as suggested by Alan

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

diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
index 460c855be0d0..14718a9ffcfb 100644
--- a/drivers/usb/core/port.c
+++ b/drivers/usb/core/port.c
@@ -249,12 +249,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 77e4c9bc0ab1..ebb29caa3fe4 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -311,7 +311,13 @@ 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);
+
+   /* 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.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v11 4/4] 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.viz...@collabora.com>
Reviewed-by: Ulf Hansson <ulf.hans...@linaro.org>
Acked-by: Alan Stern <st...@rowland.harvard.edu>
---

Changes in v10:
- Remove superfluous call to pm_runtime_enabled() as suggested by Alan

 drivers/usb/core/port.c | 6 ++
 drivers/usb/core/usb.c  | 8 +++-
 2 files changed, 13 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..3a55c91b13a1 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -316,7 +316,13 @@ 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);
+
+   /* 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.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v11 0/4] Allow USB devices to remain runtime-suspended when sleeping

[Tomeu Vizoso]

Hi,

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

For this, we interpret the absence of all PM callback implementations as
it being safe to do direct_complete, so their ancestors aren't prevented
from remaining runtime-suspended.

Additionally, the prepare() callback of USB devices will return 1 if
runtime PM is enabled and the current wakeup settings are correct.

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

Changes in v11:
- Move calls to dev_pm_domain_set() out from >power.lock as that
  isn't needed for dev->pm_domain.

Changes in v10:
- Remove superfluous call to pm_runtime_enabled() as suggested by Alan

Changes in v9:
- Add docs noting the need for the device lock to be held before calling
  device_is_bound()
- Add docs noting the need for the device lock to be held before calling
  dev_pm_domain_set()
- Move to CONFIG_PM_SLEEP as suggested by Rafael and Ulf.
- Rename from device_check_pm_callbacks to device_pm_check_callbacks to
  follow with the naming convention of existing API.
- Re-add calling to device_pm_check_callbacks from device registration
  and when updating the PM domain of a device.

Changes in v8:
- Add device_is_bound()
- Add dev_pm_domain_set() and update code to use it
- Move no_pm_callbacks field into CONFIG_PM_SLEEP
- Call device_check_pm_callbacks only after a device is bound or unbound

Changes in v7:
- Reduce indentation by adding a label in device_prepare()

Changes in v6:
- Add stub for !CONFIG_PM.
- Move implementation of device_check_pm_callbacks to power/main.c as it
  doesn't belong to CONFIG_PM_SLEEP.
- Take dev->power.lock before modifying flag.

Changes in v5:
- Check for all dev_pm_ops instances associated to a device, updating a
  no_pm_callbacks flag at the times when that could change.

Tomeu Vizoso (4):
  device core: add device_is_bound()
  PM / Domains: add setter for dev.pm_domain
  PM / sleep: Go direct_complete if driver has no callbacks
  USB / PM: Allow USB devices to remain runtime-suspended when sleeping

 arch/arm/mach-omap2/omap_device.c |  7 ---
 drivers/acpi/acpi_lpss.c  |  5 +++--
 drivers/acpi/device_pm.c  |  5 +++--
 drivers/base/dd.c | 21 +++--
 drivers/base/power/clock_ops.c|  5 +++--
 drivers/base/power/common.c   | 24 
 drivers/base/power/domain.c   |  8 ++--
 drivers/base/power/main.c | 35 +++
 drivers/base/power/power.h|  3 +++
 drivers/gpu/vga/vga_switcheroo.c  | 10 +-
 drivers/misc/mei/pci-me.c |  5 +++--
 drivers/misc/mei/pci-txe.c|  5 +++--
 drivers/usb/core/port.c   |  6 ++
 drivers/usb/core/usb.c|  8 +++-
 include/linux/device.h|  2 ++
 include/linux/pm.h|  1 +
 include/linux/pm_domain.h |  3 +++
 17 files changed, 130 insertions(+), 23 deletions(-)

-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 26 October 2015 at 11:51, Michael Turquette  wrote:
> Quoting Rafael J. Wysocki (2015-10-25 06:54:39)
>> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown  wrote:
>> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:
>> >
>> >> Well, I'm not quite sure why exactly everyone is so focused on probing 
>> >> here.
>> >
>> > Probe deferral is really noisy even if it's working fine on a given
>> > system so it's constantly being highlighted to people in a way that
>> > other issues aren't if you're not directly having problems.
>> >
>> > There's also the understanding people had that the order things get
>> > bound changes the ordering for some of the other cases (perhaps it's a
>> > good idea to do that, it seems likely to be sensible?).
>>
>> But it really doesn't do that.  Also making it do so doesn't help much
>> in the cases where things can happen asynchronously (system
>> suspend/resume, runtime PM).
>>
>> If, instead, there was a way to specify a functional dependency at the
>> device registration time, it might be used to change the order of
>> everything relevant, including probe.  That should help to reduce the
>> noise you're referring to.
>
> Taking it a step further, if functional dependencies were understood at
> link-time then we could optimize link order as well. There are probably
> lots of optimizations if we only made the effort to understand these
> dependencies earlier.
>
> Constructing the device/resource dependency graph before the device ever
> boots sounds interesting to me.

Alexander Holler has been looking at that for some time already.

Regards,

Tomeu

> Regards,
> Mike
>
>>
>> If the dependency could only be discovered at the probe time, the
>> order of things might be changed in response to letting the driver
>> core know about it rather than "just in case", which should be more
>> efficient.
>>
>> Thanks,
>> Rafael
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 10/22/2015 09:26 PM, Greg Kroah-Hartman wrote:
> On Thu, Oct 22, 2015 at 11:53:31AM -0700, Frank Rowand wrote:
>> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
>>> <oops, sent too early...>
>>>
>>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
>>>> But that's moot currently because Greg believes that the time spent
>>>> probing devices at boot time could be reduced enough so that the order
>>>> in which devices are probed becomes irrelevant. IME that would have to
>>>> be under 200ms so that the user doesn't notice and that's unicorn-far
>>>> from any bootlog I have ever seen.
>>>
>>> But as no one has actually produced a bootlog, how do you know that?
>>> Where exactly is your time being spent?  What driver is causing long
>>> delays?  Why is the long-delay-drivers not being done in their own
>>> thread?  And most importantly, why are you ignoring the work that people
>>> did back in 2008 to solve the issue on other hardware platforms?
>>>
>>>> Given that downstreams are already carrying as many hacks as they
>>>> could think of to speed total boot up, I think this is effectively
>>>> telling them to go away.
>>>
>>> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
>>> solve-the-random-issue-i'm-having type patch by putting random calls in
>>> semi-random subsystems all over the kernel.
>>>
>>> And when I ask for real data, you respond with the fact that you aren't
>>> trying to speed up boot time here at all, so what am I supposed to think
>>
>> I also had the understanding that this patch series was about improving
>> boot time.  But I was kindly corrected that the behavior change was
>> getting the panel displaying stuff at an earlier point in the boot sequence,
>> _not_ completing the entire boot faster. 
>>
>> The claim for the current series, in patch 0 in v7 is:
>>
>>With this series I get the kernel to output to the panel in 0.5s,
>>instead of 2.8s.
>>
>> Just to get side-tracked, one other approach at ordering to reduce
>> deferrals reported a modest boot time reduction for four boards and a
>> very slight boot time increase for one other board.) The report of boot
>> times with that approach was in:
>>
>>   http://article.gmane.org/gmane.linux.drivers.devicetree/133010
>>
>> from Alexander Holler.
>>
>> I have not searched further to see if there is more data of boot time
>> reductions from any of the other attempts to change driver binding
>> order to move dependencies before use of a resource.  But whether
>> there is a performance improvement or not, there continues to be
>> a stream of developers creatively impacting the binding order for
>> their specific driver(s) or board.  So it seems that maybe there
>> is an underlying problem, or we don't have adequate documentation
>> explaining how to avoid a need to order bindings, or the
>> documentation exists and is not being read.
>>
>> I have been defaulting to the position that has been asserted by
>> the device tree maintainters, that probe deferrals work just fine
>> for at least the majority of cases (and is the message I have been
>> sharing in my conference presentations about device tree).  But I
>> suspect that there is at least a small minority of cases that are not
>> well served by probe deferral.  (Not to be read as an endorsement of
>> this specific patch series, just a generic observation.)
> 
> I agree, there might be some small numbers that this is a problem for,
> and if so, great, show us the boot logs where things are taking up all
> of the time, and we can work on resolving those issues.
> 
> But without hard numbers / details, this all is just random hand-waving,
> and I don't like making core kernel changes on that basis.  And no one
> else should ever want us to do that either.

Hi,

have found the board in which Stéphane had the original issue on
(exynos5250-snow), and I'm attaching the bootlog of
next-20151013+exynos_defconfig with initcall_debug and DEBUG in dd.c.

As can be seen, 145b.dp-controller is tried reasonably early (at
0.25s), but is deferred and only retried at 0.9s, with the display
finally coming up at 1.35s.

But I'm not sure what's the point in discussing this further if you have
already said that it's fine if downstreams have to change the probing
order by moving files around in the makefiles and by fiddling with
initcall levels.

To give a better understanding of what's going on here, I wasn't
involved in the bringup of this board, but was tasked 

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 22 October 2015 at 02:54, Rafael J. Wysocki <r...@rjwysocki.net> wrote:
> On Tuesday, October 20, 2015 06:21:55 PM Tomeu Vizoso wrote:
>> On 20 October 2015 at 18:04, Alan Stern <st...@rowland.harvard.edu> wrote:
>> > On Tue, 20 Oct 2015, Mark Brown wrote:
>> >
>> >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
>> >>
>> >> > Furthermore, that applies only to devices that use synchronous suspend.
>> >> > Async suspend is becoming common, and there the only restrictions are
>> >> > parent-child relations plus whatever explicit requirements that drivers
>> >> > impose by calling device_pm_wait_for_dev().
>> >>
>> >> Hrm, this is the first I'd noticed that feature though I see the initial
>> >> commit dates from January.
>> >
>> > Async suspend and device_pm_wait_for_dev() were added in January 2010,
>> > not 2015!
>> >
>> >>  It looks like most of the users are PCs at
>> >> the minute but we should be using it more widely for embedded things,
>> >> there's definitely some cases I'm aware of where it will allow us to
>> >> remove some open coding.
>> >>
>> >> It does seem like we want to be feeding dependency information we
>> >> discover for probing way into the suspend dependencies...
>> >
>> > Rafael has been thinking about a way to do this systematically.
>> > Nothing concrete has emerged yet.
>>
>> This iteration of the series would make this quite easy, as
>> dependencies are calculated before probes are attempted:
>>
>> https://lkml.org/lkml/2015/6/17/311
>
> Well, if you know how to represent "links" between devices, the mechanism
> introduced here doesn't really add much value, because in that case the
> core knows what the dependencies are in the first place and can only
> defer the probes that have to be deferred.

By "here" you mean what you are proposing for ordering device
suspends, or on-demand probing?

If you meant that probing on-demand is unneeded if we already have
dependency information, I agree with you and that's why I only pushed
forward on-demand, as the approach linked above introduced some
duplication when inferring the dependencies. Maybe that could be
avoided without too much refactoring.

In any case, Thierry mentioned the other day in #tegra that one could
also collect dependency information as a follow up to the on-demand
series by calling device_depend() or such instead of
of_device_probe().

Regards,

Tomeu

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

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 21 October 2015 at 23:50, Frank Rowand <frowand.l...@gmail.com> wrote:
> On 10/21/2015 2:12 PM, Rob Herring wrote:
>> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand <frowand.l...@gmail.com> wrote:
>>> On 10/21/2015 9:27 AM, Mark Brown wrote:
>>>> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
>>>>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
>>>>
>>>>>> To be clear, I was saying that this series should NOT affect total
>>>>>> boot times much.
>>>>
>>>>> I'm confused.  If I understood correctly, improving boot time was
>>>>> the key justification for accepting this patch set.  For example,
>>>>> from "[PATCH v7 0/20] On-demand device probing":
>>>>>
>>>>>I have a problem with the panel on my Tegra Chromebook taking longer
>>>>>than expected to be ready during boot (Stéphane Marchesin reported what
>>>>>is basically the same issue in [0]), and have looked into ordered
>>>>>probing as a better way of solving this than moving nodes around in the
>>>>>DT or playing with initcall levels and linking order.
>>>>>
>>>>>...
>>>>>
>>>>>With this series I get the kernel to output to the panel in 0.5s,
>>>>>instead of 2.8s.
>>>>
>>>> Overall boot time and time to get some individual built in component up
>>>> and running aren't the same thing - what this'll do is get things up
>>>> more in the link order of the leaf consumers rather than deferring those
>>>> leaf consumers when their dependencies aren't ready yet.
>>>
>>> Thanks!  I read too much into what was being improved.
>>>
>>> So this patch series, which on other merits may be a good idea, is as
>>> a by product solving a specific ordering issue, moving successful panel
>>> initialization to an earlier point in the boot sequence, if I now
>>> understand more correctly.
>>>
>>> In that context, this seems like yet another ad hoc way of causing the
>>> probe order to change in a way to solves one specific issue?  Could
>>> it just as likely move the boot order of some other driver on some
>>> other board later, to the detriment of somebody else?
>>
>> Time to display on is important for many products. Having the console
>> up as early as possible is another case. CAN bus is another. This is a
>> real problem that is not just bad drivers.
>
> Yes, I agree.
>
> What I am seeing is that there continues to be a need for the ability
> to explicitly order at least some driver initialization (at some
> granularity), despite the push back against explicit ordering that
> has been present in the past.

The important point that I have struggled to explain is that right now
for downstreams to influence the order in which devices are probed,
they have to carry a substantial amount of patches that cannot be ever
upstreamed. This fiddling with initcall levels and link order means
changing files that are very frequently changing, increasing the
amount of work when rebasing and increasing the probability of
regressions after a rebase.

This just adds up to other shortcomings of mainline and ends up with
the net result of vendors getting stuck with 3.4 kernels on SoCs that
start production in 2015. Another consequence is that vendors don't
have a chance to upstream their stuff even if they cared. The
overarching goal of the project I'm in is to reduce those shortcomings
that downstreams have to workaround, to facilitate their involvement
upstream.

With this series, the order in which devices are probed becomes the
order in which they were registered, which is the order in which the
devices appear in the FW description of the hw or in the board files
(much more predictable, which makes for a more robust process). For DT
and board files, which cover a good part of the consumer devices
shipped today with Linux, the downstream could just change the order
of device nodes and get their display or whatever to probe before any
other devices.

And even if downstream's hw has a SoC .dtsi that exists in mainline,
they could add a step to their build process that automatically
reorders the nodes to avoid carrying changes to that DT fragment.

But that's moot currently because Greg believes that the time spent
probing devices at boot time could be reduced enough so that the order
in which devices are probed becomes irrelevant. IME that would have to
be under 200ms so that the user doesn't notice and that's unicorn-far
from any bootlog I have ever seen.

Given that downstreams are already carrying

[PATCH v10 4/4] 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.viz...@collabora.com>
Reviewed-by: Ulf Hansson <ulf.hans...@linaro.org>
---

Changes in v10:
- Remove superfluous call to pm_runtime_enabled() as suggested by Alan

 drivers/usb/core/port.c | 6 ++
 drivers/usb/core/usb.c  | 8 +++-
 2 files changed, 13 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..3a55c91b13a1 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -316,7 +316,13 @@ 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);
+
+   /* 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.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v10 0/4] Allow USB devices to remain runtime-suspended when sleeping

[Tomeu Vizoso]

Hi,

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

For this, we interpret the absence of all PM callback implementations as
it being safe to do direct_complete, so their ancestors aren't prevented
from remaining runtime-suspended.

Additionally, the prepare() callback of USB devices will return 1 if
runtime PM is enabled and the current wakeup settings are correct.

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

Changes in v10:
- Remove superfluous call to pm_runtime_enabled() as suggested by Alan

Changes in v9:
- Add docs noting the need for the device lock to be held before calling
  device_is_bound()
- Add docs noting the need for the device lock to be held before calling
  dev_pm_domain_set()
- Move to CONFIG_PM_SLEEP as suggested by Rafael and Ulf.
- Rename from device_check_pm_callbacks to device_pm_check_callbacks to
  follow with the naming convention of existing API.
- Re-add calling to device_pm_check_callbacks from device registration
  and when updating the PM domain of a device.

Changes in v8:
- Add device_is_bound()
- Add dev_pm_domain_set() and update code to use it
- Move no_pm_callbacks field into CONFIG_PM_SLEEP
- Call device_check_pm_callbacks only after a device is bound or unbound

Changes in v7:
- Reduce indentation by adding a label in device_prepare()

Changes in v6:
- Add stub for !CONFIG_PM.
- Move implementation of device_check_pm_callbacks to power/main.c as it
  doesn't belong to CONFIG_PM_SLEEP.
- Take dev->power.lock before modifying flag.

Changes in v5:
- Check for all dev_pm_ops instances associated to a device, updating a
  no_pm_callbacks flag at the times when that could change.

Tomeu Vizoso (4):
  device core: add device_is_bound()
  PM / Domains: add setter for dev.pm_domain
  PM / sleep: Go direct_complete if driver has no callbacks
  USB / PM: Allow USB devices to remain runtime-suspended when sleeping

 arch/arm/mach-omap2/omap_device.c |  7 ---
 drivers/acpi/acpi_lpss.c  |  5 +++--
 drivers/acpi/device_pm.c  |  5 +++--
 drivers/base/dd.c | 21 +++--
 drivers/base/power/clock_ops.c|  5 +++--
 drivers/base/power/common.c   | 24 
 drivers/base/power/domain.c   |  6 --
 drivers/base/power/main.c | 35 +++
 drivers/base/power/power.h|  3 +++
 drivers/gpu/vga/vga_switcheroo.c  | 10 +-
 drivers/misc/mei/pci-me.c |  5 +++--
 drivers/misc/mei/pci-txe.c|  5 +++--
 drivers/usb/core/port.c   |  6 ++
 drivers/usb/core/usb.c|  8 +++-
 include/linux/device.h|  2 ++
 include/linux/pm.h|  1 +
 include/linux/pm_domain.h |  3 +++
 17 files changed, 128 insertions(+), 23 deletions(-)

-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 20 October 2015 at 18:04, Alan Stern  wrote:
> On Tue, 20 Oct 2015, Mark Brown wrote:
>
>> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
>>
>> > Furthermore, that applies only to devices that use synchronous suspend.
>> > Async suspend is becoming common, and there the only restrictions are
>> > parent-child relations plus whatever explicit requirements that drivers
>> > impose by calling device_pm_wait_for_dev().
>>
>> Hrm, this is the first I'd noticed that feature though I see the initial
>> commit dates from January.
>
> Async suspend and device_pm_wait_for_dev() were added in January 2010,
> not 2015!
>
>>  It looks like most of the users are PCs at
>> the minute but we should be using it more widely for embedded things,
>> there's definitely some cases I'm aware of where it will allow us to
>> remove some open coding.
>>
>> It does seem like we want to be feeding dependency information we
>> discover for probing way into the suspend dependencies...
>
> Rafael has been thinking about a way to do this systematically.
> Nothing concrete has emerged yet.

This iteration of the series would make this quite easy, as
dependencies are calculated before probes are attempted:

https://lkml.org/lkml/2015/6/17/311

Regards,

Tomeu

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

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 18 October 2015 at 21:53, Mark Brown  wrote:
> On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
>> On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
>> > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
>
>> > > I can't see adding calls like this all over the tree just to solve a
>> > > bus-specific problem, you are adding of_* calls where they aren't
>> > > needed, or wanted, at all.
>
>> > This isn't bus specific, I'm not sure what makes you say that?
>
>> You are making it bus-specific by putting these calls all over the tree
>> in different bus subsystems semi-randomly for all I can determine.
>
> Do you mean firmware rather than bus here?  I think that's the confusion
> I have...

Hi all,

hope you don't mind I summarize the points taken instead of replying
to the individual emails. I tried to address all the concerns that
have been raised again in the cover letter, but I guess I did a bad
job at explaining myself, so here's another (more in-depth) go at it.

1) About the sprinkling of calls, everybody agreed it's a bad smell
from the start, but the intention is to modify the behaviour of the
already-DT-specific part of each subsystem without duplicating code.

A way to avoid the sprinkling would be to move the storage and lookup
of resources to the core (using classes and their list of devices to
replace the likes of __of_usb_find_phy). I also like Mark's idea of
calling of_device_probe from of_parse_phandle, which would be much
less invasive but I'm not sure if it would be right to call that
function in all the current cases in which of_parse_phandle is called.

2) About the goal of the series, what matters to my employer is that
once a device defers its probe it's only going to be reprobed in
late_initcall, after all the devices have been tentatively probed
once. In the practice this means that devices get probed in a
dependency order in which first go devices without dependencies then
go up the tree until the leave devices (which tend to be the ones with
effects visible to the user).

This series changes to another dependency order in which when a leaf
node gets probed, it recursively "pulls" its dependencies. This way we
stop massively delaying the probing of the display devices and vendors
can stop carrying sizeable hacks in their trees which just further
reduce the incentive to upstream.

The above is what funds this work, but in my personal opinion the
biggest advantage of this work is that it makes development on
embedded platforms more efficient because right now we don't have a
way of telling if a device deferred its probe because of an ordering
issue, or because there's a problem. If a device is available and has
a compatible driver, but it cannot be probed because a dependency
isn't going to be available, that's an error and is going to cause
real-world problems unless the device is redundant. Currently we say
nothing because with deferred probe the probe callbacks are also part
of the mechanism that determines the dependency order. I have wasted
countless hours hunting for the reason why a device didn't probe and I
have heard the same several times from others.

Having a specific switch for enabling deferred probe logging sounds
good, but there's going to be hundreds of spurious messages about
deferred probes that were just deferrals and only one of them is going
to be the actual error in which a device failed to find a dependency.

3) Regarding total boot time, I don't expect this series to make much
of a difference because though we would save a lot of matching and
querying for resources, that's little time compared with how long we
wait for hardware to react during probing. Async probing is more
likely to help with drivers that take a long time to probe.

4) About the breakage we have seen, that's not caused so far by
probing devices on-demand but by delaying probes until all built-in
drivers have been registered. The latter isn't strictly needed for
on-demand probing but without it most of the benefits are lost because
probes of dependencies are going to be deferred because the drivers
aren't there yet. We could avoid that by registering drivers also
on-demand but we would need to make the matching information available
beforehand, which is a massive change in itself. This should speed up
boot some, and also cause leaf devices to be up earlier.

One more thing about the breakage we have seen so far is that it's
generally caused by implicit dependencies and hunting those is
probably the second biggest timesink of the linux embedded developer
after failed probes. We depend on hacks such as link order, node order
in the DT, initcall gerrymandering and a blind hope in things that
started some time ago to have finished by now. And those implicit
dependencies are often left completely undocumented. This is really
fragile and breaks often when changing something unrelated such as
when adding another revision of a board 

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 19 October 2015 at 15:18, Russell King - ARM Linux
<li...@arm.linux.org.uk> wrote:
> On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote:
>> ... If a device is available and has
>> a compatible driver, but it cannot be probed because a dependency
>> isn't going to be available, that's an error and is going to cause
>> real-world problems unless the device is redundant. Currently we say
>> nothing because with deferred probe the probe callbacks are also part
>> of the mechanism that determines the dependency order.
>
> So what if device X depends on device Y, and we have a driver for
> device Y built-in to the kernel, but the driver for device X is a
> module?
>
> I don't see this being solvable in the way you describe above - it's
> going to identify X as being unable to be satisfied, and report it as
> an error - but it's not an error at all.

It's going to probe Y at late_initcall, then probe X when its driver
is registered. No deferred probes nor messages about it.

But if you meant to write the opposite case (X built-in and Y in a
module), then I have to ask you in what situation that would make
sense.

>> Having a specific switch for enabling deferred probe logging sounds
>> good, but there's going to be hundreds of spurious messages about
>> deferred probes that were just deferrals and only one of them is going
>> to be the actual error in which a device failed to find a dependency.
>
> Why would there be?  Sounds like something's very wrong there.

Sorry about that, I have checked that only now and I "only" get 39
deferred probe messages on exynos5250-snow.

> You should only get deferred probes for devices which are declared to
> be present, but their resources have not yet been satisfied.  It
> doesn't change anything if you have a kernel with lots of device drivers
> or just the device drivers you need - the device drivers you don't need
> do not contribute to the deferred probing in any way.

I don't think that the number of registered drivers affects the number
of probes that get deferred (but I'm not sure why you mention that).

> So, really, after boot and all appropriate modules have been loaded,
> you should end up with no deferred probes.  Are you saying that you
> still have "hundreds" at that point?  If you do, that sounds like
> there's something very wrong.

I was talking about messages if we log each -EPROBE_DEFER, not devices
that remain to be probed. The point being that right now we don't have
a way to know if we are deferring because the dependency will be
around later, or if we have a problem and the dependency isn't going
to be there at all.

If we had a way to enable printing the cause of each -EPROBE_DEFER,
right now that would print 39 messages of this board that are only due
to ordering. The actual issue would be printed in exactly the same way
somewhere in the middle.

>> 3) Regarding total boot time, I don't expect this series to make much
>> of a difference because though we would save a lot of matching and
>> querying for resources, that's little time compared with how long we
>> wait for hardware to react during probing. Async probing is more
>> likely to help with drivers that take a long time to probe.
>
> For me, on my fastest ARM board, though running serial console:
>
> [2.293468] VFS: Mounted root (ext4 filesystem) on device 179:1.
>
> There's a couple of delays in there, but they're not down to deferred
> probing.  The biggest one is serial console startup (due to the time
> it takes to write out the initial kernel messages):
>
> [0.289962] f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 23, base_baud 
> = 15625000) is a 16550A
> [0.944124] console [ttyS0] enabled
>
> and DSA switch initialisation:
>
> [1.530655] libphy: dsa slave smi: probed
> [2.034426] dsa dsa@0 lan6 (uninitialized): attached PHY at address 0 
> [Generic PHY]
>
> I'm not sure what causes that, but at a guess it's having to talk to the
> DSA switch over the MDIO bus via several layers of indirect accesses.
> Of course, serial console adds to the boot time significantly anyway,
> especially at the "standard" kernel logging level.

Yes, I don't think it makes any sense to measure boot times with the
serial console on, because it's not comparable to production and
because printing an additional line during boot affects significantly
the times.

To be clear, I was saying that this series should NOT affect total
boot times much.

>> One more thing about the breakage we have seen so far is that it's
>> generally caused by implicit dependencies and hunting those is
>> probably the second biggest timesink of the linux embedded developer
>> after failed probes.
>
> ... which is general

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 19 October 2015 at 16:30, Russell King - ARM Linux
<li...@arm.linux.org.uk> wrote:
> On Mon, Oct 19, 2015 at 04:10:56PM +0200, Tomeu Vizoso wrote:
>> On 19 October 2015 at 15:18, Russell King - ARM Linux
>> <li...@arm.linux.org.uk> wrote:
>> > On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote:
>> >> ... If a device is available and has
>> >> a compatible driver, but it cannot be probed because a dependency
>> >> isn't going to be available, that's an error and is going to cause
>> >> real-world problems unless the device is redundant. Currently we say
>> >> nothing because with deferred probe the probe callbacks are also part
>> >> of the mechanism that determines the dependency order.
>> >
>> > So what if device X depends on device Y, and we have a driver for
>> > device Y built-in to the kernel, but the driver for device X is a
>> > module?
>> >
>> > I don't see this being solvable in the way you describe above - it's
>> > going to identify X as being unable to be satisfied, and report it as
>> > an error - but it's not an error at all.
>>
>> It's going to probe Y at late_initcall, then probe X when its driver
>> is registered. No deferred probes nor messages about it.
>>
>> But if you meant to write the opposite case (X built-in and Y in a
>> module), then I have to ask you in what situation that would make
>> sense.
>
> I did mean the opposite way around.  It may not make sense if you're
> targetting a single platform, but it may make sense in a single zImage
> kernel.
>
> Consider something like a single zImage kernel that is built with
> everything built-in to be able to boot and mount rootfs without
> initramfs support on both platform A and platform B.  Both platforms
> share some hardware (eg, an I2C GPIO expander) which is built as a
> module.  It is a resource provider.  Platform B contains a driver
> which is required to boot on platform A, but not platform B (so the
> kernel has to have that driver built-in.)  On platform B, there is
> a dependency to the I2C GPIO expander device.

I see, in this situation the person trying to find out why some device
hadn't probed would enable debug logging of failed probes and would
see one spurious message if there was a deferred probe because of the
module.

>> >> Having a specific switch for enabling deferred probe logging sounds
>> >> good, but there's going to be hundreds of spurious messages about
>> >> deferred probes that were just deferrals and only one of them is going
>> >> to be the actual error in which a device failed to find a dependency.
>> >
>> > Why would there be?  Sounds like something's very wrong there.
>>
>> Sorry about that, I have checked that only now and I "only" get 39
>> deferred probe messages on exynos5250-snow.
>
> I typically see one or two, maybe five maximum on the platforms I have
> here, but normally zero.

Hmm, I have given a look at our lava farm and have seen 2 dozens as
common (with multi_v7).

>> > So, really, after boot and all appropriate modules have been loaded,
>> > you should end up with no deferred probes.  Are you saying that you
>> > still have "hundreds" at that point?  If you do, that sounds like
>> > there's something very wrong.
>>
>> I was talking about messages if we log each -EPROBE_DEFER, not devices
>> that remain to be probed. The point being that right now we don't have
>> a way to know if we are deferring because the dependency will be
>> around later, or if we have a problem and the dependency isn't going
>> to be there at all.
>
> What's the difference between a dependency which isn't around because
> the driver is not built into the kernel but is available as a module,
> and a dependency that isn't around because the module hasn't been
> loaded yet?
>
> How do you distinguish between those two scenarios?  In the former
> scenario, the device will eventually come up when udev loads the
> module.  In the latter case, it's a persistent failing case.

Agreed, but it's something that doesn't happen often and that's why
such messages would be at the debug level instead of being warns or
errors.

>> Agreed, with the note from above on why it would be better to only
>> print such a message only when the -EPROBE_DEFER is likely to be a
>> problem.
>
> ... and my argument is that there's _no way_ to know for certain which
> deferred probes will be a problem, and which won't.  The only way to
> definitely know that is if you disable kernel modules, and require
> all drivers to be built int

[GIT PULL] On-demand device probing

[Tomeu Vizoso]

Hi,

this second pull request replaces the last references to device_initcall_sync 
with late_initcall, as noticed by Frank Rowand.

Also fixes the url of the git repo and the wrapping, as suggested by Mark Brown.

Thanks,

Tomeu

The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:

  Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)

are available in the git repository at:

  git://git.collabora.com/git/user/tomeu/linux.git on-demand-probes-for-next

for you to fetch changes up to c074fef5d36e1c27dfdf7474e23c01a1b044ff98:

  of/platform: Defer probes of registered devices (2015-10-15 13:25:47 +0200)


Tomeu Vizoso (20):
  driver core: handle -EPROBE_DEFER from bus_type.match()
  ARM: amba: Move reading of periphid to amba_match()
  of/platform: Point to struct device from device node
  of: add function to allow probing a device from a OF node
  gpio: Probe GPIO drivers on demand
  pinctrl: Probe pinctrl devices on demand
  regulator: core: Probe regulators on demand
  drm: Probe panels on demand
  drm/tegra: Probe dpaux devices on demand
  i2c: core: Probe i2c adapters and devices on demand
  pwm: Probe PWM chip devices on demand
  backlight: Probe backlight devices on demand
  usb: phy: Probe phy devices on demand
  clk: Probe clk providers on demand
  pinctrl: Probe pinctrl devices on demand
  phy: core: Probe phy providers on demand
  dma: of: Probe DMA controllers on demand
  power-supply: Probe power supplies on demand
  driver core: Allow deferring probes until late init
  of/platform: Defer probes of registered devices

 drivers/amba/bus.c  | 88 +++--
 drivers/base/Kconfig| 18 
 drivers/base/dd.c   | 30 -
 drivers/clk/clk.c   |  3 ++
 drivers/dma/of-dma.c|  3 ++
 drivers/gpio/gpiolib-of.c   |  5 +++
 drivers/gpu/drm/drm_panel.c |  3 ++
 drivers/gpu/drm/tegra/dpaux.c   |  3 ++
 drivers/i2c/i2c-core.c  |  4 ++
 drivers/of/device.c | 61 +
 drivers/of/platform.c   | 30 -
 drivers/phy/phy-core.c  |  3 ++
 drivers/pinctrl/devicetree.c|  3 ++
 drivers/power/power_supply_core.c   |  3 ++
 drivers/pwm/core.c  |  3 ++
 drivers/regulator/core.c|  2 +
 drivers/usb/phy/phy.c   |  3 ++
 drivers/video/backlight/backlight.c |  3 ++
 include/linux/device.h  |  4 +-
 include/linux/of.h  |  1 +
 include/linux/of_device.h   |  3 ++
 21 files changed, 219 insertions(+), 57 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL] On-demand device probing

[Tomeu Vizoso]

Hi Rob,

here is the pull request you asked for, with no changes from the version
that I posted last to the list.

The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:

Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)

are available in the git repository at:

git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
on-demand-probes-for-next

for you to fetch changes up to 587402133fe433759d2d535e5d92ead87fd7f615:

of/platform: Defer probes of registered devices (2015-10-14 10:08:23 +0200)


Tomeu Vizoso (20):
driver core: handle -EPROBE_DEFER from bus_type.match()
ARM: amba: Move reading of periphid to amba_match()
of/platform: Point to struct device from device node
of: add function to allow probing a device from a OF node
gpio: Probe GPIO drivers on demand
pinctrl: Probe pinctrl devices on demand
regulator: core: Probe regulators on demand
drm: Probe panels on demand
drm/tegra: Probe dpaux devices on demand
i2c: core: Probe i2c adapters and devices on demand
pwm: Probe PWM chip devices on demand
backlight: Probe backlight devices on demand
usb: phy: Probe phy devices on demand
clk: Probe clk providers on demand
pinctrl: Probe pinctrl devices on demand
phy: core: Probe phy providers on demand
dma: of: Probe DMA controllers on demand
power-supply: Probe power supplies on demand
driver core: Allow deferring probes until late init
of/platform: Defer probes of registered devices

drivers/amba/bus.c | 88
++--
drivers/base/Kconfig | 18 ++
drivers/base/dd.c | 30 --
drivers/clk/clk.c | 3 +++
drivers/dma/of-dma.c | 3 +++
drivers/gpio/gpiolib-of.c | 5 +
drivers/gpu/drm/drm_panel.c | 3 +++
drivers/gpu/drm/tegra/dpaux.c | 3 +++
drivers/i2c/i2c-core.c | 4 
drivers/of/device.c | 61
+
drivers/of/platform.c | 30 ++
drivers/phy/phy-core.c | 3 +++
drivers/pinctrl/devicetree.c | 3 +++
drivers/power/power_supply_core.c | 3 +++
drivers/pwm/core.c | 3 +++
drivers/regulator/core.c | 2 ++
drivers/usb/phy/phy.c | 3 +++
drivers/video/backlight/backlight.c | 3 +++
include/linux/device.h | 4 +++-
include/linux/of.h | 1 +
include/linux/of_device.h | 3 +++
21 files changed, 219 insertions(+), 57 deletions(-)


Thanks,

Tomeu
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v9 4/4] 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.viz...@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

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v9 0/4] Allow USB devices to remain runtime-suspended when sleeping

[Tomeu Vizoso]

Hi,

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

For this, we interpret the absence of all PM callback implementations as
it being safe to do direct_complete, so their ancestors aren't prevented
from remaining runtime-suspended.

Additionally, the prepare() callback of USB devices will return 1 if
runtime PM is enabled and the current wakeup settings are correct.

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

Changes in v9:
- Add docs noting the need for the device lock to be held before calling
  device_is_bound()
- Add docs noting the need for the device lock to be held before calling
  dev_pm_domain_set()
- Move to CONFIG_PM_SLEEP as suggested by Rafael and Ulf.
- Rename from device_check_pm_callbacks to device_pm_check_callbacks to
  follow with the naming convention of existing API.
- Re-add calling to device_pm_check_callbacks from device registration
  and when updating the PM domain of a device.

Changes in v8:
- Add device_is_bound()
- Add dev_pm_domain_set() and update code to use it
- Move no_pm_callbacks field into CONFIG_PM_SLEEP
- Call device_check_pm_callbacks only after a device is bound or unbound

Changes in v7:
- Reduce indentation by adding a label in device_prepare()

Changes in v6:
- Add stub for !CONFIG_PM.
- Move implementation of device_check_pm_callbacks to power/main.c as it
  doesn't belong to CONFIG_PM_SLEEP.
- Take dev->power.lock before modifying flag.

Changes in v5:
- Check for all dev_pm_ops instances associated to a device, updating a
  no_pm_callbacks flag at the times when that could change.

Tomeu Vizoso (4):
  device core: add device_is_bound()
  PM / Domains: add setter for dev.pm_domain
  PM / sleep: Go direct_complete if driver has no callbacks
  USB / PM: Allow USB devices to remain runtime-suspended when sleeping

 arch/arm/mach-omap2/omap_device.c |  7 ---
 drivers/acpi/acpi_lpss.c  |  5 +++--
 drivers/acpi/device_pm.c  |  5 +++--
 drivers/base/dd.c | 21 +++--
 drivers/base/power/clock_ops.c|  5 +++--
 drivers/base/power/common.c   | 24 
 drivers/base/power/domain.c   |  6 --
 drivers/base/power/main.c | 35 +++
 drivers/base/power/power.h|  3 +++
 drivers/gpu/vga/vga_switcheroo.c  | 10 +-
 drivers/misc/mei/pci-me.c |  5 +++--
 drivers/misc/mei/pci-txe.c|  5 +++--
 drivers/usb/core/port.c   |  6 ++
 drivers/usb/core/usb.c| 11 ++-
 include/linux/device.h|  2 ++
 include/linux/pm.h|  1 +
 include/linux/pm_domain.h |  3 +++
 17 files changed, 131 insertions(+), 23 deletions(-)

-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v8 4/4] 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.viz...@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

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v8 0/4] Allow USB devices to remain runtime-suspended when sleeping

[Tomeu Vizoso]

Hi,

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

For this, we interpret the absence of all PM callback implementations as
it being safe to do direct_complete, so their ancestors aren't prevented
from remaining runtime-suspended.

Additionally, the prepare() callback of USB devices will return 1 if
runtime PM is enabled and the current wakeup settings are correct.

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

Changes in v8:
- Add device_is_bound()
- Add dev_pm_domain_set() and update code to use it
- Move no_pm_callbacks field into CONFIG_PM_SLEEP
- Call device_check_pm_callbacks only after a device is bound or unbound

Changes in v7:
- Reduce indentation by adding a label in device_prepare()

Changes in v6:
- Add stub for !CONFIG_PM.
- Move implementation of device_check_pm_callbacks to power/main.c as it
  doesn't belong to CONFIG_PM_SLEEP.
- Take dev->power.lock before modifying flag.

Changes in v5:
- Check for all dev_pm_ops instances associated to a device, updating a
  no_pm_callbacks flag at the times when that could change.

Tomeu Vizoso (4):
  device core: add device_is_bound()
  PM / Domains: add setter for dev.pm_domain
  PM / sleep: Go direct_complete if driver has no callbacks
  USB / PM: Allow USB devices to remain runtime-suspended when sleeping

 arch/arm/mach-omap2/omap_device.c |  7 ---
 drivers/acpi/acpi_lpss.c  |  5 +++--
 drivers/acpi/device_pm.c  |  5 +++--
 drivers/base/dd.c | 12 ++--
 drivers/base/power/clock_ops.c|  5 +++--
 drivers/base/power/common.c   |  8 
 drivers/base/power/domain.c   |  6 --
 drivers/base/power/main.c | 33 +
 drivers/base/power/power.h|  6 ++
 drivers/gpu/vga/vga_switcheroo.c  | 10 +-
 drivers/misc/mei/pci-me.c |  5 +++--
 drivers/misc/mei/pci-txe.c|  5 +++--
 drivers/usb/core/port.c   |  6 ++
 drivers/usb/core/usb.c| 11 ++-
 include/linux/device.h|  2 ++
 include/linux/pm.h|  1 +
 include/linux/pm_domain.h |  3 +++
 17 files changed, 107 insertions(+), 23 deletions(-)

-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7 0/2] Allow USB devices to remain runtime-suspended when sleeping

[Tomeu Vizoso]

Hi,

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

For this, we interpret the absence of all PM callback implementations as
it being safe to do direct_complete, so their ancestors aren't prevented
from remaining runtime-suspended.

Additionally, the prepare() callback of USB devices will return 1 if
runtime PM is enabled and the current wakeup settings are correct.

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

Changes in v7:
- Reduce indentation by adding a label in device_prepare()

Changes in v6:
- Add stub for !CONFIG_PM.
- Move implementation of device_check_pm_callbacks to power/main.c as it
  doesn't belong to CONFIG_PM_SLEEP.
- Take dev->power.lock before modifying flag.

Changes in v5:
- Check for all dev_pm_ops instances associated to a device, updating a
  no_pm_callbacks flag at the times when that could change.

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

 drivers/base/dd.c   |  3 +++
 drivers/base/power/common.c | 27 +++
 drivers/base/power/domain.c |  5 +
 drivers/base/power/main.c   |  8 
 drivers/base/power/power.h  |  6 ++
 drivers/usb/core/port.c |  6 ++
 drivers/usb/core/usb.c  | 11 ++-
 include/linux/pm.h  |  1 +
 8 files changed, 66 insertions(+), 1 deletion(-)

-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7 2/2] 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.viz...@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

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 0/2]

[Tomeu Vizoso]

Hi,

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

For this, we interpret the absence of all PM callback implementations as
it being safe to do direct_complete, so their ancestors aren't prevented
from remaining runtime-suspended.

Additionally, the prepare() callback of USB devices will return 1 if
runtime PM is enabled and the current wakeup settings are correct.

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

Changes in v5:
- Check for all dev_pm_ops instances associated to a device, updating a
  no_pm_callbacks flag at the times when that could change.

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

 drivers/base/dd.c   |  3 ++
 drivers/base/power/domain.c |  5 
 drivers/base/power/main.c   | 69 -
 drivers/base/power/power.h  |  2 ++
 drivers/usb/core/port.c |  6 
 drivers/usb/core/usb.c  | 11 +++-
 include/linux/pm.h  |  1 +
 7 files changed, 77 insertions(+), 20 deletions(-)

-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 2/2] 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.viz...@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

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 2/2] 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.viz...@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

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 0/2] Allow USB devices to remain runtime-suspended when sleeping

[Tomeu Vizoso]

Hi,

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

For this, we interpret the absence of all PM callback implementations as
it being safe to do direct_complete, so their ancestors aren't prevented
from remaining runtime-suspended.

Additionally, the prepare() callback of USB devices will return 1 if
runtime PM is enabled and the current wakeup settings are correct.

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

Changes in v6:
- Add stub for !CONFIG_PM.
- Move implementation of device_check_pm_callbacks to power/main.c as it
  doesn't belong to CONFIG_PM_SLEEP.
- Take dev->power.lock before modifying flag.

Changes in v5:
- Check for all dev_pm_ops instances associated to a device, updating a
  no_pm_callbacks flag at the times when that could change.

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

 drivers/base/dd.c   |  3 +++
 drivers/base/power/common.c | 27 +++
 drivers/base/power/domain.c |  5 +
 drivers/base/power/main.c   | 44 +---
 drivers/base/power/power.h  |  6 ++
 drivers/usb/core/port.c |  6 ++
 drivers/usb/core/usb.c  | 11 ++-
 include/linux/pm.h  |  1 +
 8 files changed, 83 insertions(+), 20 deletions(-)

-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 0/22] On-demand device probing

[Tomeu Vizoso]

On 9 September 2015 at 03:33, Rob Herring <r...@kernel.org> wrote:
> On 09/08/2015 02:30 AM, Tomeu Vizoso wrote:
>> On 7 September 2015 at 22:50, Rob Herring <robherri...@gmail.com> wrote:
>>> On Mon, Sep 7, 2015 at 7:23 AM, Tomeu Vizoso <tomeu.viz...@collabora.com> 
>>> wrote:
>>>> Hello,
>>>>
>>>> I have a problem with the panel on my Tegra Chromebook taking longer
>>>> than expected to be ready during boot (Stéphane Marchesin reported what
>>>> is basically the same issue in [0]), and have looked into ordered
>>>> probing as a better way of solving this than moving nodes around in the
>>>> DT or playing with initcall levels and linking order.
>>>>
>>>> While reading the thread [1] that Alexander Holler started with his
>>>> series to make probing order deterministic, it occurred to me that it
>>>> should be possible to achieve the same by probing devices as they are
>>>> referenced by other devices.
>>>>
>>>> This basically reuses the information that is already implicit in the
>>>> probe() implementations, saving us from refactoring existing drivers or
>>>> adding information to DTBs.
>>>>
>>>> During review of v1 of this series Linus Walleij suggested that it
>>>> should be the device driver core to make sure that dependencies are
>>>> ready before probing a device. I gave this idea a try [2] but Mark Brown
>>>> pointed out to the logic duplication between the resource acquisition
>>>> and dependency discovery code paths (though I think it's fairly minor).
>>>>
>>>> To address that code duplication I experimented with Arnd's devm_probe
>>>> [3] concept of having drivers declare their dependencies instead of
>>>> acquiring them during probe, and while it worked [4], I don't think we
>>>> end up winning anything when compared to just probing devices on-demand
>>>> from resource getters.
>>>>
>>>> One remaining objection is to the "sprinkling" of calls to
>>>> of_device_probe() in the resource getters of each subsystem, but I think
>>>> it's the right thing to do given that the storage of resources is
>>>> currently subsystem-specific.
>>>>
>>>> We could avoid the above by moving resource storage into the core, but I
>>>> don't think there's a compelling case for that.
>>>>
>>>> I have tested this on boards with Tegra, iMX.6, Exynos, Rockchip and
>>>> OMAP SoCs, and these patches were enough to eliminate all the deferred
>>>> probes (except one in PandaBoard because omap_dma_system doesn't have a
>>>> firmware node as of yet).
>>>>
>>>> Have submitted a branch [5] with only these patches on top of thursday's
>>>> linux-next to kernelci.org and I don't see any issues that could be
>>>> caused by them. For some reason it currently has more passes than the
>>>> version of -next it's based on!
>>>>
>>>> With this series I get the kernel to output to the panel in 0.5s,
>>>> instead of 2.8s.
>>>>
>>>> Regards,
>>>>
>>>> Tomeu
>>>>
>>>> [0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html
>>>>
>>>> [1] https://lkml.org/lkml/2014/5/12/452
>>>>
>>>> [2] https://lkml.org/lkml/2015/6/17/305
>>>>
>>>> [3] http://article.gmane.org/gmane.linux.ports.arm.kernel/277689
>>>>
>>>> [4] https://lkml.org/lkml/2015/7/21/441a
>>>>
>>>> [5] 
>>>> https://git.collabora.com/cgit/user/tomeu/linux.git/log/?h=on-demand-probes-v6
>>>>
>>>> [6] 
>>>> http://kernelci.org/boot/all/job/collabora/kernel/v4.2-11902-g25d80c927f8b/
>>>>
>>>> [7] http://kernelci.org/boot/all/job/next/kernel/next-20150903/
>>>>
>>>> Changes in v4:
>>>> - Added bus.pre_probe callback so the probes of Primecell devices can be
>>>>   deferred if their device IDs cannot be yet read because of the clock
>>>>   driver not having probed when they are registered. Maybe this goes
>>>>   overboard and the matching information should be in the DT if there is
>>>>   one.
>>>
>>> Seems overboard to me or at least a separate problem.
>>
>> It's a separate problem but this was preventing the series from
>> working on a few boards.
>
> 

Re: [PATCH v4 0/22] On-demand device probing

[Tomeu Vizoso]

On 7 September 2015 at 22:50, Rob Herring <robherri...@gmail.com> wrote:
> On Mon, Sep 7, 2015 at 7:23 AM, Tomeu Vizoso <tomeu.viz...@collabora.com> 
> wrote:
>> Hello,
>>
>> I have a problem with the panel on my Tegra Chromebook taking longer
>> than expected to be ready during boot (Stéphane Marchesin reported what
>> is basically the same issue in [0]), and have looked into ordered
>> probing as a better way of solving this than moving nodes around in the
>> DT or playing with initcall levels and linking order.
>>
>> While reading the thread [1] that Alexander Holler started with his
>> series to make probing order deterministic, it occurred to me that it
>> should be possible to achieve the same by probing devices as they are
>> referenced by other devices.
>>
>> This basically reuses the information that is already implicit in the
>> probe() implementations, saving us from refactoring existing drivers or
>> adding information to DTBs.
>>
>> During review of v1 of this series Linus Walleij suggested that it
>> should be the device driver core to make sure that dependencies are
>> ready before probing a device. I gave this idea a try [2] but Mark Brown
>> pointed out to the logic duplication between the resource acquisition
>> and dependency discovery code paths (though I think it's fairly minor).
>>
>> To address that code duplication I experimented with Arnd's devm_probe
>> [3] concept of having drivers declare their dependencies instead of
>> acquiring them during probe, and while it worked [4], I don't think we
>> end up winning anything when compared to just probing devices on-demand
>> from resource getters.
>>
>> One remaining objection is to the "sprinkling" of calls to
>> of_device_probe() in the resource getters of each subsystem, but I think
>> it's the right thing to do given that the storage of resources is
>> currently subsystem-specific.
>>
>> We could avoid the above by moving resource storage into the core, but I
>> don't think there's a compelling case for that.
>>
>> I have tested this on boards with Tegra, iMX.6, Exynos, Rockchip and
>> OMAP SoCs, and these patches were enough to eliminate all the deferred
>> probes (except one in PandaBoard because omap_dma_system doesn't have a
>> firmware node as of yet).
>>
>> Have submitted a branch [5] with only these patches on top of thursday's
>> linux-next to kernelci.org and I don't see any issues that could be
>> caused by them. For some reason it currently has more passes than the
>> version of -next it's based on!
>>
>> With this series I get the kernel to output to the panel in 0.5s,
>> instead of 2.8s.
>>
>> Regards,
>>
>> Tomeu
>>
>> [0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html
>>
>> [1] https://lkml.org/lkml/2014/5/12/452
>>
>> [2] https://lkml.org/lkml/2015/6/17/305
>>
>> [3] http://article.gmane.org/gmane.linux.ports.arm.kernel/277689
>>
>> [4] https://lkml.org/lkml/2015/7/21/441a
>>
>> [5] 
>> https://git.collabora.com/cgit/user/tomeu/linux.git/log/?h=on-demand-probes-v6
>>
>> [6] 
>> http://kernelci.org/boot/all/job/collabora/kernel/v4.2-11902-g25d80c927f8b/
>>
>> [7] http://kernelci.org/boot/all/job/next/kernel/next-20150903/
>>
>> Changes in v4:
>> - Added bus.pre_probe callback so the probes of Primecell devices can be
>>   deferred if their device IDs cannot be yet read because of the clock
>>   driver not having probed when they are registered. Maybe this goes
>>   overboard and the matching information should be in the DT if there is
>>   one.
>
> Seems overboard to me or at least a separate problem.

It's a separate problem but this was preventing the series from
working on a few boards.

> Most clocks have
> to be setup before the driver model simply because timers depend on
> clocks usually.

Yes, but in this case the apb clocks for the primecell devices are
implemented in a normal platform driver (vexpress_osc_driver), instead
of using CLK_OF_DECLARE.

Regards,

Tomeu

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

[PATCH v4 0/22] On-demand device probing

[Tomeu Vizoso]

Hello,

I have a problem with the panel on my Tegra Chromebook taking longer
than expected to be ready during boot (Stéphane Marchesin reported what
is basically the same issue in [0]), and have looked into ordered
probing as a better way of solving this than moving nodes around in the
DT or playing with initcall levels and linking order.

While reading the thread [1] that Alexander Holler started with his
series to make probing order deterministic, it occurred to me that it
should be possible to achieve the same by probing devices as they are
referenced by other devices.

This basically reuses the information that is already implicit in the
probe() implementations, saving us from refactoring existing drivers or
adding information to DTBs.

During review of v1 of this series Linus Walleij suggested that it
should be the device driver core to make sure that dependencies are
ready before probing a device. I gave this idea a try [2] but Mark Brown
pointed out to the logic duplication between the resource acquisition
and dependency discovery code paths (though I think it's fairly minor).

To address that code duplication I experimented with Arnd's devm_probe
[3] concept of having drivers declare their dependencies instead of
acquiring them during probe, and while it worked [4], I don't think we
end up winning anything when compared to just probing devices on-demand
from resource getters.

One remaining objection is to the "sprinkling" of calls to
of_device_probe() in the resource getters of each subsystem, but I think
it's the right thing to do given that the storage of resources is
currently subsystem-specific.

We could avoid the above by moving resource storage into the core, but I
don't think there's a compelling case for that.

I have tested this on boards with Tegra, iMX.6, Exynos, Rockchip and
OMAP SoCs, and these patches were enough to eliminate all the deferred
probes (except one in PandaBoard because omap_dma_system doesn't have a
firmware node as of yet).

Have submitted a branch [5] with only these patches on top of thursday's
linux-next to kernelci.org and I don't see any issues that could be
caused by them. For some reason it currently has more passes than the
version of -next it's based on!

With this series I get the kernel to output to the panel in 0.5s,
instead of 2.8s.

Regards,

Tomeu

[0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html

[1] https://lkml.org/lkml/2014/5/12/452

[2] https://lkml.org/lkml/2015/6/17/305

[3] http://article.gmane.org/gmane.linux.ports.arm.kernel/277689

[4] https://lkml.org/lkml/2015/7/21/441a

[5] 
https://git.collabora.com/cgit/user/tomeu/linux.git/log/?h=on-demand-probes-v6

[6] http://kernelci.org/boot/all/job/collabora/kernel/v4.2-11902-g25d80c927f8b/

[7] http://kernelci.org/boot/all/job/next/kernel/next-20150903/

Changes in v4:
- Added bus.pre_probe callback so the probes of Primecell devices can be
  deferred if their device IDs cannot be yet read because of the clock
  driver not having probed when they are registered. Maybe this goes
  overboard and the matching information should be in the DT if there is
  one.
- Rename of_platform_probe to of_device_probe
- Use device_node.device instead of device_node.platform_dev
- Take a reference to the regulator's device to prevent dangling
  pointers
- Add Kconfig DELAY_DEVICE_PROBES to allow disabling delayed probing in
  machines with initcalls that depend on devices probing at a given time.
- Start processing deferred probes in device_initcall_sync
- Also defer probes of AMBA devices registered from the DT as they can
  also request resources.

Changes in v3:
- Set and use device_node.platform_dev instead of reversing the logic to
  find the platform device that encloses a device node.
- Drop the fwnode API to probe firmware nodes and add OF-only API for
  now. I think this same scheme could be used for machines with ACPI,
  but I haven't been able to find one that had to defer its probes because
  of the device probe order.
- Avoid unlocking the regulator device's mutex if we don't have a device

Changes in v2:
- Acquire regulator device lock before returning from regulator_dev_lookup()

Tomeu Vizoso (22):
  driver core: Add pre_probe callback to bus_type
  ARM: amba: Move reading of periphid to pre_probe()
  of/platform: Point to struct device from device node
  of: add function to allow probing a device from a OF node
  gpio: Probe GPIO drivers on demand
  gpio: Probe pinctrl devices on demand
  regulator: core: Reduce critical area in _regulator_get
  regulator: core: Probe regulators on demand
  drm: Probe panels on demand
  drm/tegra: Probe dpaux devices on demand
  i2c: core: Probe i2c adapters and devices on demand
  pwm: Probe PWM chip devices on demand
  backlight: Probe backlight devices on demand
  usb: phy: Probe phy devices on demand
  clk: Probe clk providers on demand
  pinctrl: Probe pinctrl devices on demand
  phy: core: Probe phy providers on de

[PATCH v2 0/22] On-demand device probing

[Tomeu Vizoso]

Hello,

I have a problem with the panel on my Tegra Chromebook taking longer
than expected to be ready during boot (Stéphane Marchesin reported what
is basically the same issue in [0]), and have looked into ordered
probing as a better way of solving this than moving nodes around in the
DT or playing with initcall levels and linking order.

While reading the thread [1] that Alexander Holler started with his
series to make probing order deterministic, it occurred to me that it
should be possible to achieve the same by probing devices as they are
referenced by other devices.

This basically reuses the information that is already implicit in the
probe() implementations, saving us from refactoring existing drivers or
adding information to DTBs.

During review of v1 of this series Linus Walleij suggested that it
should be the device driver core to make sure that dependencies are
ready before probing a device. I gave this idea a try [2] but Mark Brown
pointed out to the logic duplication between the resource acquisition
and dependency discovery code paths (though I think it's fairly minor).

To address that code duplication I experimented with Arnd's devm_probe
[3] concept of having drivers declare their dependencies instead of
acquiring them during probe, and while it worked [4], I don't think we
end up winning anything when compared to just probing devices on-demand
from resource getters.

One remaining objection is to the sprinkling of calls to
fwnode_ensure_device() in the resource getters of each subsystem, but I
think it's the right thing to do given that the storage of resources is
currently subsystem-specific.

We could avoid the above by moving resource storage into the core, but I
don't think there's a compelling case for that.

I have tested this on boards with Tegra, iMX.6, Exynos and OMAP SoCs,
and these patches were enough to eliminate all the deferred probes
(except one in PandaBoard because omap_dma_system doesn't have a
firmware node as of yet).

With this series I get the kernel to output to the panel in 0.5s,
instead of 2.8s.

Regards,

Tomeu

[0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html

[1] https://lkml.org/lkml/2014/5/12/452

[2] https://lkml.org/lkml/2015/6/17/305

[3] http://article.gmane.org/gmane.linux.ports.arm.kernel/277689

[4] https://lkml.org/lkml/2015/7/21/441

Changes in v2:
- Move delay to platform.c
- Use set_primary_fwnode()
- Use of_node_full_name()
- Move the logic for finding a platform device from its firmware node to
  of/platform.c as it's not needed for ACPI nodes.
- Add acpi_dev_get_device()
- Add fwnode_ensure_device() so the mechanism for probing devices on
  demand is independent of the firmware format.
- Acquire regulator device lock before returning from regulator_dev_lookup()

Tomeu Vizoso (22):
  platform: delay device-driver matches until late_initcall
  of/platform: Set fwnode field for new devices
  device property: add fwnode_get_name()
  of/platform: add of_platform_device_find()
  ACPI: add acpi_dev_get_device()
  device property: add fwnode_ensure_device()
  gpio: Probe GPIO drivers on demand
  gpio: Probe pinctrl devices on demand
  regulator: core: Reduce critical area in _regulator_get
  regulator: core: Probe regulators on demand
  drm: Probe panels on demand
  drm/tegra: Probe dpaux devices on demand
  i2c: core: Probe i2c master devices on demand
  pwm: Probe PWM chip devices on demand
  backlight: Probe backlight devices on demand
  usb: phy: Probe phy devices on demand
  clk: Probe clk providers on demand
  pinctrl: Probe pinctrl devices on demand
  phy: core: Probe phy providers on demand
  dma: of: Probe DMA controllers on demand
  power-supply: Probe power supplies on demand
  ASoC: core: Probe components on demand

 drivers/base/platform.c | 28 +++
 drivers/base/property.c | 73 +++
 drivers/clk/clk.c   |  3 ++
 drivers/dma/of-dma.c|  2 +
 drivers/gpio/gpiolib-of.c   |  4 ++
 drivers/gpu/drm/drm_panel.c |  2 +
 drivers/gpu/drm/tegra/dpaux.c   |  2 +
 drivers/i2c/i2c-core.c  |  2 +
 drivers/of/platform.c   | 61 +++
 drivers/phy/phy-core.c  |  2 +
 drivers/pinctrl/devicetree.c|  1 +
 drivers/power/power_supply_core.c   |  2 +
 drivers/pwm/core.c  |  2 +
 drivers/regulator/core.c| 99 +
 drivers/usb/phy/phy.c   |  2 +
 drivers/video/backlight/backlight.c |  2 +
 include/linux/acpi.h| 10 
 include/linux/of_platform.h |  1 +
 include/linux/property.h|  4 ++
 sound/soc/soc-core.c|  6 ++-
 20 files changed, 264 insertions(+), 44 deletions(-)

-- 
2.4.3

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org

[PATCH v2 16/22] usb: phy: Probe phy devices on demand

[Tomeu Vizoso]

When looking up a phy through its firmware node, probe it if it hasn't
already.

The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.

Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
---

Changes in v2: None

 drivers/usb/phy/phy.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index 98f75d2842b7..2d51c12d0726 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -196,6 +196,8 @@ struct  usb_phy *devm_usb_get_phy_by_node(struct device 
*dev,
goto err0;
}
 
+   fwnode_ensure_device(node-fwnode);
+
spin_lock_irqsave(phy_lock, flags);
 
phy = __of_usb_find_phy(node);
-- 
2.4.3

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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 r...@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.viz...@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 majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[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.viz...@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

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[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

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/12] Discover and probe dependencies

[Tomeu Vizoso]

Hi,

this is version 2 of a series that probes devices in dependency order so
as to avoid deferred probes. While deferred probing is a powerful
solution that makes sure that you eventually get a working system at the
end of the boot, can make it very time consuming to find out why a
device didn't probe and can also introduce big delays in when a device
actually probes by sending it to the end of the deferred queue.

So far I have only tested on a Tegra124 Chromebook.

Thanks,

Tomeu

Changes in v2:
- Instead of delaying all probes until late_initcall, only delay matches
  of platform devices that have a firmware node attached.
- Allow bindings implementations register a function instead of using
  class callbacks, as not only subsystems implement firmware bindings.
- Move strends to string.h
- Document that consumers of backlight devices can use the 'backlight'
  property to hold a phandle to the backlight device.
- Allocate the list of dependencies and pass it to the function that
  fills it.

Tomeu Vizoso (12):
  device: property: delay device-driver matches
  device: property: find dependencies of a firmware node
  string: Introduce strends()
  gpio: register dependency parser for firmware nodes
  gpu: host1x: register dependency parser for firmware nodes
  backlight: Document consumers of backlight nodes
  backlight: register dependency parser for firmware nodes
  USB: EHCI: register dependency parser for firmware nodes
  regulator: register dependency parser for firmware nodes
  pwm: register dependency parser for firmware nodes
  ASoC: tegra: register dependency parser for firmware nodes
  driver-core: probe dependencies before probing

 .../bindings/video/backlight/backlight.txt |  22 
 drivers/base/dd.c  | 139 +
 drivers/base/property.c| 120 ++
 drivers/gpio/gpiolib.c |  54 
 drivers/gpu/host1x/dev.c   |  26 
 drivers/pwm/core.c |  28 +
 drivers/regulator/core.c   |  27 
 drivers/usb/host/ehci-tegra.c  |  16 +++
 drivers/video/backlight/backlight.c|  16 +++
 include/linux/fwnode.h |   5 +
 include/linux/property.h   |  12 ++
 include/linux/string.h |  13 ++
 sound/soc/tegra/tegra_max98090.c   |  42 ++-
 13 files changed, 519 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/video/backlight/backlight.txt

-- 
2.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 08/12] USB: EHCI: register dependency parser for firmware nodes

[Tomeu Vizoso]

So others can find out whether a firmware node depends on a phy as
specified in bindings/usb/nvidia,tegra20-ehci.txt.

Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
---

Changes in v2: None

 drivers/usb/host/ehci-tegra.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index 4031b37..3665eaa 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -589,6 +589,18 @@ static const struct ehci_driver_overrides tegra_overrides 
__initconst = {
.reset  = tegra_ehci_reset,
 };
 
+static void tegra_ehci_get_dependencies(struct fwnode_handle *fwnode,
+   struct list_head *deps)
+{
+   struct device_node *np;
+
+   np = of_parse_phandle(to_of_node(fwnode), nvidia,phy, 0);
+   if (!np)
+   return;
+
+   fwnode_add_dependency(np-fwnode, deps);
+}
+
 static int __init ehci_tegra_init(void)
 {
if (usb_disabled())
@@ -611,6 +623,8 @@ static int __init ehci_tegra_init(void)
tegra_ehci_hc_driver.unmap_urb_for_dma = tegra_ehci_unmap_urb_for_dma;
tegra_ehci_hc_driver.hub_control = tegra_ehci_hub_control;
 
+   fwnode_add_dependency_parser(tegra_ehci_get_dependencies);
+
return platform_driver_register(tegra_ehci_driver);
 }
 module_init(ehci_tegra_init);
@@ -618,6 +632,8 @@ module_init(ehci_tegra_init);
 static void __exit ehci_tegra_cleanup(void)
 {
platform_driver_unregister(tegra_ehci_driver);
+
+   fwnode_remove_dependency_parser(tegra_ehci_get_dependencies);
 }
 module_exit(ehci_tegra_cleanup);
 
-- 
2.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/21] On-demand device registration

[Tomeu Vizoso]

On 28 May 2015 at 06:33, Rob Herring robherri...@gmail.com wrote:
 On Mon, May 25, 2015 at 9:53 AM, Tomeu Vizoso
 tomeu.viz...@collabora.com wrote:
 Hello,

 I have a problem with the panel on my Tegra Chromebook taking longer than
 expected to be ready during boot (Stéphane Marchesin reported what is
 basically the same issue in [0]), and have looked into ordered probing as a
 better way of solving this than moving nodes around in the DT or playing with
 initcall levels.

 While reading the thread [1] that Alexander Holler started with his series to
 make probing order deterministic, it occurred to me that it should be 
 possible
 to achieve the same by registering devices as they are referenced by other
 devices.

 I like the concept and novel approach.

 This basically reuses the information that is already implicit in the probe()
 implementations, saving us from refactoring existing drivers or adding
 information to DTBs.

 Something I'm not completely happy with is that I have had to move the call 
 to
 of_platform_populate after all platform drivers have been registered.
 Otherwise I don't see how I could register drivers on demand as we don't have
 yet each driver's compatible strings.

 Yeah, this is the opposite of what we'd really like.

Can you elaborate on the reasons why we would like to have devices
registered before built-in drivers finish registering, even if we
don't probe them yet?

 Ideally, we would
 have a solution that works for modules too. However, we're no worse
 off. We pretty much build-in dependencies to avoid module ordering
 problems.

Nod, I haven't looked yet at requesting modules on-demand, but I guess
it should be doable. Modules that have dependencies described in the
firmware should get them probed automatically already though.

 Perhaps we need to make the probing on-demand rather than simply on
 device-driver match occurring.

I'm afraid that too much old code depends on that. For example, Rafael
pointed out to the PNP subsystem, which registers a driver that will
probe devices with the EISA ID PNP0c02 to reserve memory regions for
devices that will be probed later.

http://lxr.free-electrons.com/source/drivers/pnp/system.c

My understanding is that probing of PNP0c02 devices must happen before
the actual devices that depend on those regions are probed, so if we
decoupled the probing from the driver/device registration, we would be
breaking that assumption.

 For machs that don't move of_platform_populate() to a later point, these
 patches shouldn't cause any problems but it's not guaranteed that we'll avoid
 all the deferred probes as some drivers may not be registered yet.

 Ideally, of_platform_populate is not explicitly called by each
 platform. So I think we need to make this work for the default case.

The problem is that some platforms will need fixing because some
initcalls assume that some devices will have been registered already,
or even probed. I think removing those assumptions shouldn't be
problematic because I haven't had much trouble with this on the four
platforms I have tested with, but I cannot test every board that is
supported upstream.

I can ask though the KernelCI folks to boot my branch in all their
boards and make sure that those work when of_platform_populate is
called in late_initcall.

http://kernelci.org/boot/all/job/next/kernel/next-20150619/

 I have tested this on boards with Tegra, iMX.6 and Exynos SoCs, and these
 patches were enough to eliminate all the deferred probes.

 With this series I get the kernel to output to the panel in 0.5s, instead of 
 2.8s.

 That's certainly compelling.

Have to say that those numbers are with the serial console enabled
(without, it's 0.5s vs 1.5s), but on machines that take longer to boot
we should see bigger gains because we won't be sending devices to the
end of the queue when their probe is deferred.

Regards,

Tomeu

 Rob


 Regards,

 Tomeu

 [0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html

 [1] https://lkml.org/lkml/2014/5/12/452

 Tomeu Vizoso (21):
   regulator: core: Reduce critical area in _regulator_get
   ARM: tegra: Add gpio-ranges property
   ARM: tegra: Register drivers before devices
   ARM: EXYNOS: Register drivers before devices
   ARM i.MX6q: Register drivers before devices
   of/platform: Add of_platform_device_ensure()
   of/platform: Ensure device registration on lookup
   gpio: Probe GPIO drivers on demand
   gpio: Probe pinctrl devices on demand
   regulator: core: Probe regulators on demand
   drm: Probe panels on demand
   drm/tegra: Probe dpaux devices on demand
   i2c: core: Probe i2c master devices on demand
   pwm: Probe PWM chip devices on demand
   backlight: Probe backlight devices on demand
   usb: phy: Probe phy devices on demand
   clk: Probe clk providers on demand
   pinctrl: Probe pinctrl devices on demand
   phy: core: Probe phy providers on demand
   dma: of: Probe DMA controllers on demand
   power-supply: Probe power supplies

Re: [PATCH 00/21] On-demand device registration

[Tomeu Vizoso]

On 10 June 2015 at 09:30, Linus Walleij linus.wall...@linaro.org wrote:
 On Tue, Jun 2, 2015 at 12:14 PM, Tomeu Vizoso
 tomeu.viz...@collabora.com wrote:
 On 2 June 2015 at 10:48, Linus Walleij linus.wall...@linaro.org wrote:

 This is what systemd is doing in userspace for starting services:
 ask for your dependencies and wait for them if they are not
 there. So drivers ask for resources and wait for them. It also
 needs to be abstract, so for example we need to be able to
 hang on regulator_get() until the driver is up and providing that
 regulator, and as long as everything is in slowpath it should
 be OK. (And vice versa mutatis mutandis for clk, gpio, pin
 control, interrupts (!) and DMA channels for example.)

 I understood above that you propose probing devices in order, but now
 you mention that resource getters would block until the dependency is
 fulfilled which confuses me because if we are probing in order then
 all dependencies would be fulfilled before the device in question gets
 probed.

 Sorry, the problem space is a bit convoluted so the answers
 get a bit convoluted. Maybe I'm thinking aloud and altering the course
 of my thoughts as I type...

 I guess there can be explicit dependencies for resources like this
 patch does, but another way would be for all resource fetch functions
 to be instrumented, so that you do not block until you try to take
 a resource that is not yet there, e.g.:

 regulator_get(...) - not available, so:
 - identify target regulator provider - this will need instrumentation
 - probe it

 It then turns out the regulator driver is on the i2c bus, so we
 need to probe the i2c driver:
 - identify target i2c host for the regulator driver - this will need
   instrumentation
 - probe the i2c host driver

 i2c host comes out, probes the regulator driver, regulator driver
 probes and then the regulator_get() call returns.

Hmm, if I understand correctly what you say, this is exactly what this
particular series does:

regulator_get - of_platform_device_ensure - probe() on the platform
device that encloses the requested device node (i2c host) - i2c slave
gets probed and the regulator registered - regulator_get returns the
requested resource

The downside I'm currently looking at is that an explicit dependency
graph would be useful to have for other purposes. For example to print
a neat warning when a dependency cannot be fulfilled. Or to refuse to
unbind a device which other devices depend on, or to automatically
unbind the devices that depend on it, or to print a warning if a
device is hotplugged off and other devices depend on it.

 This requires instrumentation on anything providing a resource
 to another driver like those I mentioned and a lot of overhead
 infrastructure, but I think it's the right approach. However I don't
 know if I would ever be able to pull that off myself, I know talk
 is cheap and I should show the code instead.

Yeah, if you can give it a second look and say if it matches what you
wrote above, it would be very much appreciated.

 Deepest respect for your efforts!

Thanks!

Tomeu

 Yours,
 Linus Walleij
 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/21] On-demand device registration

[Tomeu Vizoso]

On 3 June 2015 at 21:57, grygorii.stras...@linaro.org
grygorii.stras...@linaro.org wrote:
 Hi Tomeu,

 On 05/28/2015 07:33 AM, Rob Herring wrote:
 On Mon, May 25, 2015 at 9:53 AM, Tomeu Vizoso tomeu.viz...@collabora.com 
 wrote:
 I have a problem with the panel on my Tegra Chromebook taking longer than
 expected to be ready during boot (Stéphane Marchesin reported what is
 basically the same issue in [0]), and have looked into ordered probing as a
 better way of solving this than moving nodes around in the DT or playing 
 with
 initcall levels.

 While reading the thread [1] that Alexander Holler started with his series 
 to
 make probing order deterministic, it occurred to me that it should be 
 possible
 to achieve the same by registering devices as they are referenced by other
 devices.

 I like the concept and novel approach.

 This basically reuses the information that is already implicit in the 
 probe()
 implementations, saving us from refactoring existing drivers or adding
 information to DTBs.

 Something I'm not completely happy with is that I have had to move the call 
 to
 of_platform_populate after all platform drivers have been registered.
 Otherwise I don't see how I could register drivers on demand as we don't 
 have
 yet each driver's compatible strings.

 Yeah, this is the opposite of what we'd really like. Ideally, we would
 have a solution that works for modules too. However, we're no worse
 off. We pretty much build-in dependencies to avoid module ordering
 problems.

 Perhaps we need to make the probing on-demand rather than simply on
 device-driver match occurring.

 For machs that don't move of_platform_populate() to a later point, these
 patches shouldn't cause any problems but it's not guaranteed that we'll 
 avoid
 all the deferred probes as some drivers may not be registered yet.

 Ideally, of_platform_populate is not explicitly called by each
 platform. So I think we need to make this work for the default case.

 I have tested this on boards with Tegra, iMX.6 and Exynos SoCs, and these
 patches were enough to eliminate all the deferred probes.

 With this series I get the kernel to output to the panel in 0.5s, instead 
 of 2.8s.

 That's certainly compelling.

 I've found your idea about moving device registration later during System boot
 very interesting so I've decided to try it on dra7-evem (TI) :).
 It's good to know time during Kernel boot when we can assume that all drivers 
 are
 ready for probing, so there are more ways to control probing order.

Thanks, though right now I'm following Rob's suggestion and only delay
probing, not registration. The patch is really simple (applies on
linux-next, with async probing):

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 8da8e07..7e6b1e1 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -407,6 +407,11 @@ int driver_probe_device(struct device_driver
*drv, struct device *dev)
if (!device_is_registered(dev))
return -ENODEV;

+   if (!driver_deferred_probe_enable) {
+   driver_deferred_probe_add(dev);
+   return 0;
+   }
+
pr_debug(bus: '%s': %s: matched device %s with driver %s\n,
 drv-bus-name, __func__, dev_name(dev), drv-name);

@@ -585,7 +590,7 @@ EXPORT_SYMBOL_GPL(device_attach);

 void device_initial_probe(struct device *dev)
 {
-   __device_attach(dev, true);
+   __device_attach(dev, driver_deferred_probe_enable);
 }

 static int __driver_attach(struct device *dev, void *data)

 Pls, Note here that TI OMAP2+ mach is not pure DT mach - it's combination of
 DT and not DT devices/drivers.

 Ok. So What was done...

 LKML Linux 4.1-rc3 (a simple case)
 1) use your patches 3/4 as reference (only these two patches :)
 2) move of_platform_populate later at device_initcall_sync time
 Boot time reduction ~0.4 sec

I'm a bit surprised at such a big improvement. May I ask how you are
measuring it?

 TI Android Kernel 3.14 (NOT a simple case)
 1) use your patches 3/4 as reference (only these two patches :)
 2) move of_platform_populate later at device_initcall_sync time
 3) make it to boot (not sure I've fixed all issues, but those which
break the System boot):
  - split non-DT and DT devices registration in platform code;
  - keep non-DT devices registration from .init_machine() [arch_initcall]
  - move DT-devices registration at device_initcall_sync time
  - fix drivers which use platform_driver_probe().
Note. Now there are at about ~190 occurrences of this macro in Kernel.
  - re-order few devices in DT (4 devices)
  - fix one driver which uses of_find_device_by_node() wrongly
Note. This API is used some times with assumption that
requested dev has been probed already.
 Boot time reduction ~0.3 sec. Probing of some devices are still deferred.

I got no deferred probes on a pandaboard with just these changes:

https://git.collabora.com/cgit/user/tomeu/linux.git/commit/?id=1586c6f50b3d3c65dc219a3cdc3327d798cabca6

Re: [PATCH 00/21] On-demand device registration

[Tomeu Vizoso]

On 2 June 2015 at 10:48, Linus Walleij linus.wall...@linaro.org wrote:
 On Mon, May 25, 2015 at 4:53 PM, Tomeu Vizoso
 tomeu.viz...@collabora.com wrote:

 have looked into ordered probing as a
 better way of solving this than moving nodes around in the DT or playing with
 initcall levels.

 While reading the thread [1] that Alexander Holler started with his series to
 make probing order deterministic, it occurred to me that it should be 
 possible
 to achieve the same by registering devices as they are referenced by other
 devices.

 This is pretty cool, but a too local solution to a global problem.

 Deferred probe and initcall reordering, silly as they may seem,
 does not require you to use device tree.

 The real solution, which I think I pointed out already when we
 added deferred probe, is to put dependency graphs in the drivers

By this you mean something like what Thierry suggested here?

http://article.gmane.org/gmane.linux.kernel/1774623

 and have the kernel device driver core percolate dependecies by
 walking the graph on probing driver, removing driver (usually the
 inverse use case), [runtime] suspend and [runtime] resumeing
 a driver. Possibly the dependencies will even be different
 depending on use case.

 This is what systemd is doing in userspace for starting services:
 ask for your dependencies and wait for them if they are not
 there. So drivers ask for resources and wait for them. It also
 needs to be abstract, so for example we need to be able to
 hang on regulator_get() until the driver is up and providing that
 regulator, and as long as everything is in slowpath it should
 be OK. (And vice versa mutatis mutandis for clk, gpio, pin
 control, interrupts (!) and DMA channels for example.)

I understood above that you propose probing devices in order, but now
you mention that resource getters would block until the dependency is
fulfilled which confuses me because if we are probing in order then
all dependencies would be fulfilled before the device in question gets
probed.

 So if this should be solved it should be solved in an abstract way
 in the device driver core available for all, then have calls calling
 out to DT, ACPI, possibly even PCI or USB (as these
 enumerate devices themselves) to obtain a certain
 dependency.

Yeah, I was planning looking into this now that I got it working with
async probing.

Thanks,

Tomeu

 Yours,
 Linus Walleij
 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 16/21] usb: phy: Probe phy devices on demand

[Tomeu Vizoso]

When looking up a phy through its DT node, ensure that the corresponding
device has been registered.

Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
---
 drivers/usb/phy/phy.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index d1cd6b5..7084f21 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -13,6 +13,7 @@
 #include linux/err.h
 #include linux/device.h
 #include linux/module.h
+#include linux/of_platform.h
 #include linux/slab.h
 #include linux/of.h
 
@@ -192,6 +193,8 @@ struct usb_phy *devm_usb_get_phy_by_phandle(struct device 
*dev,
goto err0;
}
 
+   of_platform_device_ensure(node);
+
spin_lock_irqsave(phy_lock, flags);
 
phy = __of_usb_find_phy(node);
-- 
2.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 00/21] On-demand device registration

[Tomeu Vizoso]

Hello,

I have a problem with the panel on my Tegra Chromebook taking longer than
expected to be ready during boot (Stéphane Marchesin reported what is
basically the same issue in [0]), and have looked into ordered probing as a
better way of solving this than moving nodes around in the DT or playing with
initcall levels.

While reading the thread [1] that Alexander Holler started with his series to
make probing order deterministic, it occurred to me that it should be possible
to achieve the same by registering devices as they are referenced by other
devices.

This basically reuses the information that is already implicit in the probe()
implementations, saving us from refactoring existing drivers or adding
information to DTBs.

Something I'm not completely happy with is that I have had to move the call to
of_platform_populate after all platform drivers have been registered.
Otherwise I don't see how I could register drivers on demand as we don't have
yet each driver's compatible strings.

For machs that don't move of_platform_populate() to a later point, these
patches shouldn't cause any problems but it's not guaranteed that we'll avoid
all the deferred probes as some drivers may not be registered yet.

I have tested this on boards with Tegra, iMX.6 and Exynos SoCs, and these
patches were enough to eliminate all the deferred probes.

With this series I get the kernel to output to the panel in 0.5s, instead of 
2.8s.

Regards,

Tomeu

[0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html

[1] https://lkml.org/lkml/2014/5/12/452

Tomeu Vizoso (21):
  regulator: core: Reduce critical area in _regulator_get
  ARM: tegra: Add gpio-ranges property
  ARM: tegra: Register drivers before devices
  ARM: EXYNOS: Register drivers before devices
  ARM i.MX6q: Register drivers before devices
  of/platform: Add of_platform_device_ensure()
  of/platform: Ensure device registration on lookup
  gpio: Probe GPIO drivers on demand
  gpio: Probe pinctrl devices on demand
  regulator: core: Probe regulators on demand
  drm: Probe panels on demand
  drm/tegra: Probe dpaux devices on demand
  i2c: core: Probe i2c master devices on demand
  pwm: Probe PWM chip devices on demand
  backlight: Probe backlight devices on demand
  usb: phy: Probe phy devices on demand
  clk: Probe clk providers on demand
  pinctrl: Probe pinctrl devices on demand
  phy: core: Probe phy providers on demand
  dma: of: Probe DMA controllers on demand
  power-supply: Probe power supplies on demand

 arch/arm/boot/dts/tegra124.dtsi |  1 +
 arch/arm/mach-exynos/exynos.c   |  4 +--
 arch/arm/mach-imx/mach-imx6q.c  | 12 -
 arch/arm/mach-tegra/tegra.c | 21 ++-
 drivers/clk/clk.c   |  3 +++
 drivers/dma/of-dma.c|  3 +++
 drivers/gpio/gpiolib-of.c   |  5 
 drivers/gpu/drm/drm_panel.c |  3 +++
 drivers/gpu/drm/tegra/dpaux.c   |  3 +++
 drivers/i2c/i2c-core.c  |  3 +++
 drivers/of/platform.c   | 53 +
 drivers/phy/phy-core.c  |  3 +++
 drivers/pinctrl/devicetree.c|  2 ++
 drivers/power/power_supply_core.c   |  3 +++
 drivers/pwm/core.c  |  3 +++
 drivers/regulator/core.c| 45 +++
 drivers/usb/phy/phy.c   |  3 +++
 drivers/video/backlight/backlight.c |  3 +++
 include/linux/of_platform.h |  2 ++
 19 files changed, 130 insertions(+), 45 deletions(-)

-- 
2.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Tomeu Vizoso]

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

Also enable runtime PM for endpoints, which is another requirement for
the above to work.

Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
---
 drivers/usb/core/endpoint.c | 17 +
 drivers/usb/core/message.c  | 16 
 drivers/usb/core/port.c |  6 ++
 drivers/usb/core/usb.c  |  8 +++-
 4 files changed, 46 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/core/endpoint.c b/drivers/usb/core/endpoint.c
index 39a2402..7c82bb7 100644
--- a/drivers/usb/core/endpoint.c
+++ b/drivers/usb/core/endpoint.c
@@ -160,6 +160,19 @@ static const struct attribute_group *ep_dev_groups[] = {
NULL
 };
 
+#ifdef CONFIG_PM
+
+static int usb_ep_device_prepare(struct device *dev)
+{
+   return 1;
+}
+
+static const struct dev_pm_ops usb_ep_device_pm_ops = {
+   .prepare =  usb_ep_device_prepare,
+};
+
+#endif /* CONFIG_PM */
+
 static void ep_device_release(struct device *dev)
 {
struct ep_device *ep_dev = to_ep_device(dev);
@@ -170,6 +183,9 @@ static void ep_device_release(struct device *dev)
 struct device_type usb_ep_device_type = {
.name = usb_endpoint,
.release = ep_device_release,
+#ifdef CONFIG_PM
+   .pm =   usb_ep_device_pm_ops,
+#endif
 };
 
 int usb_create_ep_devs(struct device *parent,
@@ -197,6 +213,7 @@ int usb_create_ep_devs(struct device *parent,
goto error_register;
 
device_enable_async_suspend(ep_dev-dev);
+   pm_runtime_enable(ep_dev-dev);
endpoint-ep_dev = ep_dev;
return retval;
 
diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index f368d20..9041aee 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -1589,10 +1589,26 @@ static int usb_if_uevent(struct device *dev, struct 
kobj_uevent_env *env)
return 0;
 }
 
+#ifdef CONFIG_PM
+
+static int usb_if_prepare(struct device *dev)
+{
+   return 1;
+}
+
+static const struct dev_pm_ops usb_if_pm_ops = {
+   .prepare =  usb_if_prepare,
+};
+
+#endif /* CONFIG_PM */
+
 struct device_type usb_if_device_type = {
.name = usb_interface,
.release =  usb_release_interface,
.uevent =   usb_if_uevent,
+#ifdef CONFIG_PM
+   .pm =   usb_if_pm_ops,
+#endif
 };
 
 static struct usb_interface_assoc_descriptor *find_iad(struct usb_device *dev,
diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
index 2106183..f49707d 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 8d5b2f4..3a55c91 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -316,7 +316,13 @@ 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);
+
+   /* 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.3.4

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Tomeu Vizoso]

On 31 March 2015 at 19:09, Alan Stern st...@rowland.harvard.edu wrote:
 On Tue, 31 Mar 2015, Tomeu Vizoso wrote:

 Have dev_pm_ops.prepare return 1 for USB devices, interfaces, endpoints
 and ports so that USB devices can remain runtime-suspended when the
 system goes to a sleep state.

 Also enable runtime PM for endpoints, which is another requirement for
 the above to work.

 Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com

 ...

 diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
 index b1fb9ae..1498faa 100644
 --- a/drivers/usb/core/usb.c
 +++ b/drivers/usb/core/usb.c
 @@ -300,7 +300,7 @@ 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? */
 + return 1;   /* Implement eventually? */
  }

 The rest of the patch is okay, but this part is wrong.  The documented
 requirement is that the prepare callback should return 1 if the device
 is already in the appropriate state.  This means it has to have the
 right wakeup setting.

 In other words, if the device is currently in runtime suspend with
 remote wakeup enabled, but device_may_wakeup() returns 0 (so that the
 device should be disabled for wakeup when the system goes into
 suspend), then the prepare callback has to return 0.

 Therefore what you need to do here is something like this:

 struct usb_device   *udev = to_usb_device(dev);

 /* Return 0 if the current wakeup setting is wrong, otherwise 1 */
 if (udev-do_remote_wakeup  !device_may_wakeup(dev))
 return 0;
 return 1;

Thanks, in v2 I have also covered the other case, as suggested by Oliver.

 Aside from this issue, I like the patch set.  Do you think you can do
 something similar for drivers/scsi/scsi_pm.c?  I'm not aware of any
 wakeup-capable SCSI devices -- not disk or CD/DVD drives, anyway.

I think I will be able to allocate some time on monday to look at this.

Thanks,

Tomeu

 Alan Stern

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

[PATCH v2 0/7] Allow UVC devices to remain runtime-suspended when sleeping

[Tomeu Vizoso]

v2: * Let creators of the input device to decide whether it should remain
runtime suspended when the system goes into a sleep state
* Don't enable PM runtime on all evdev handlers
* Cope with another wrong wakeup setting in usb_dev_prepare

Hi,

this series contain what I needed to do in order to have my USB webcam to not
be resumed when the system resumes, reducing considerably the total time that
resuming takes.

It makes use of the facility that Rafael Wysocki added in aae4518b3 (PM /
sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily),
which requires that a device and all its descendants opt-in by having their
dev_pm_ops.prepare callback return 1, to have runtime PM enabled, and to be
runtime suspended when the system goes to a sleep state.

Thanks,

Tomeu

Tomeu Vizoso (7):
  Input: Implement dev_pm_ops.prepare in input_class
  Input: Add input_dev.stay_runtime_suspended flag
  [media] uvcvideo: Set input_dev.stay_runtime_suspended flag
  [media] uvcvideo: Enable runtime PM of descendant devices
  [media] v4l2-core: Implement dev_pm_ops.prepare()
  [media] media-devnode: Implement dev_pm_ops.prepare callback
  USB / PM: Allow USB devices to remain runtime-suspended when sleeping

 drivers/input/input.c  | 20 
 drivers/media/media-devnode.c  | 10 ++
 drivers/media/usb/uvc/uvc_driver.c | 11 +++
 drivers/media/usb/uvc/uvc_status.c |  1 +
 drivers/media/v4l2-core/v4l2-dev.c | 10 ++
 drivers/usb/core/endpoint.c| 17 +
 drivers/usb/core/message.c | 16 
 drivers/usb/core/port.c|  6 ++
 drivers/usb/core/usb.c |  8 +++-
 include/linux/input.h  |  4 
 10 files changed, 102 insertions(+), 1 deletion(-)

-- 
2.3.4

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/6] Allow UVC devices to remain runtime-suspended when sleeping

[Tomeu Vizoso]

Hi,

this series contain what I needed to do in order to have my USB webcam to not 
be resumed when the system resumes, reducing considerably the total time that 
resuming takes.

It makes use of the facility that Rafael Wysocki added in aae4518b3 (PM / 
sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily), 
which requires that a devices and all its descendants opt-in by having their 
dev_pm_ops.prepare callback return 1, to have runtime PM enabled, and to be 
runtime suspended when the system goes to a sleep state.

Thanks,

Tomeu

Tomeu Vizoso (6):
  [media] uvcvideo: Enable runtime PM of descendant devices
  [media] v4l2-core: Implement dev_pm_ops.prepare()
  Input: Implement dev_pm_ops.prepare()
  [media] media-devnode: Implement dev_pm_ops.prepare callback
  Input: evdev - Enable runtime PM of the evdev input handler
  USB / PM: Allow USB devices to remain runtime-suspended when sleeping

 drivers/input/evdev.c  |  3 +++
 drivers/input/input.c  | 13 +
 drivers/media/media-devnode.c  | 10 ++
 drivers/media/usb/uvc/uvc_driver.c |  4 
 drivers/media/usb/uvc/uvc_status.c |  3 +++
 drivers/media/v4l2-core/v4l2-dev.c | 10 ++
 drivers/usb/core/endpoint.c| 17 +
 drivers/usb/core/message.c | 16 
 drivers/usb/core/port.c|  6 ++
 drivers/usb/core/usb.c |  2 +-
 10 files changed, 83 insertions(+), 1 deletion(-)

-- 
2.3.4

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Tomeu Vizoso]

Have dev_pm_ops.prepare return 1 for USB devices, interfaces, endpoints
and ports so that USB devices can remain runtime-suspended when the
system goes to a sleep state.

Also enable runtime PM for endpoints, which is another requirement for
the above to work.

Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
---
 drivers/usb/core/endpoint.c | 17 +
 drivers/usb/core/message.c  | 16 
 drivers/usb/core/port.c |  6 ++
 drivers/usb/core/usb.c  |  2 +-
 4 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/core/endpoint.c b/drivers/usb/core/endpoint.c
index 39a2402..7c82bb7 100644
--- a/drivers/usb/core/endpoint.c
+++ b/drivers/usb/core/endpoint.c
@@ -160,6 +160,19 @@ static const struct attribute_group *ep_dev_groups[] = {
NULL
 };
 
+#ifdef CONFIG_PM
+
+static int usb_ep_device_prepare(struct device *dev)
+{
+   return 1;
+}
+
+static const struct dev_pm_ops usb_ep_device_pm_ops = {
+   .prepare =  usb_ep_device_prepare,
+};
+
+#endif /* CONFIG_PM */
+
 static void ep_device_release(struct device *dev)
 {
struct ep_device *ep_dev = to_ep_device(dev);
@@ -170,6 +183,9 @@ static void ep_device_release(struct device *dev)
 struct device_type usb_ep_device_type = {
.name = usb_endpoint,
.release = ep_device_release,
+#ifdef CONFIG_PM
+   .pm =   usb_ep_device_pm_ops,
+#endif
 };
 
 int usb_create_ep_devs(struct device *parent,
@@ -197,6 +213,7 @@ int usb_create_ep_devs(struct device *parent,
goto error_register;
 
device_enable_async_suspend(ep_dev-dev);
+   pm_runtime_enable(ep_dev-dev);
endpoint-ep_dev = ep_dev;
return retval;
 
diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index f368d20..9041aee 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -1589,10 +1589,26 @@ static int usb_if_uevent(struct device *dev, struct 
kobj_uevent_env *env)
return 0;
 }
 
+#ifdef CONFIG_PM
+
+static int usb_if_prepare(struct device *dev)
+{
+   return 1;
+}
+
+static const struct dev_pm_ops usb_if_pm_ops = {
+   .prepare =  usb_if_prepare,
+};
+
+#endif /* CONFIG_PM */
+
 struct device_type usb_if_device_type = {
.name = usb_interface,
.release =  usb_release_interface,
.uevent =   usb_if_uevent,
+#ifdef CONFIG_PM
+   .pm =   usb_if_pm_ops,
+#endif
 };
 
 static struct usb_interface_assoc_descriptor *find_iad(struct usb_device *dev,
diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
index 2106183..f49707d 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 b1fb9ae..1498faa 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -300,7 +300,7 @@ 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? */
+   return 1;   /* Implement eventually? */
 }
 
 static void usb_dev_complete(struct device *dev)
-- 
2.3.4

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: host: ehci-tegra: request deferred probe when failing to get phy

[Tomeu Vizoso]

On 24 December 2014 at 11:16, Vince Hsu vin...@nvidia.com wrote:
 The commit 1290a958d48e (usb: phy: propagate __of_usb_find_phy()'s error on
 failure) changed the condition to return -EPROBE_DEFER to host driver.
 Originally the Tegra host driver depended on the returned -EPROBE_DEFER to
 get the phy device later when booting. Now we have to do that explicitly.

With this patch, USB works again on this nyan-blaze board.

Tested-by: Tomeu Vizoso tomeu.viz...@collabora.com

Thanks,

Tomeu

 Signed-off-by: Vince Hsu vin...@nvidia.com
 ---
 Hi,

 This fixes a regression found on 3.19-rc1. The USB host can't be probed and
 the USB failed on Jetson TK1.

 Thanks,
 Vince


  drivers/usb/host/ehci-tegra.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
 index 19a9af1b4d74..ff9af29b4e9f 100644
 --- a/drivers/usb/host/ehci-tegra.c
 +++ b/drivers/usb/host/ehci-tegra.c
 @@ -451,7 +451,7 @@ static int tegra_ehci_probe(struct platform_device *pdev)

 u_phy = devm_usb_get_phy_by_phandle(pdev-dev, nvidia,phy, 0);
 if (IS_ERR(u_phy)) {
 -   err = PTR_ERR(u_phy);
 +   err = -EPROBE_DEFER;
 goto cleanup_clk_en;
 }
 hcd-usb_phy = u_phy;
 --
 1.9.1

 --
 To unsubscribe from this list: send the line unsubscribe linux-tegra in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/9] Tegra xHCI support

[Tomeu Vizoso]

On 15 September 2014 19:06, Andrew Bresticker abres...@chromium.org wrote:
 On Mon, Sep 15, 2014 at 12:00 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote:
 On 12 September 2014 18:37, Andrew Bresticker abres...@chromium.org wrote:
 On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote:
 On 8 September 2014 18:22, Andrew Bresticker abres...@chromium.org wrote:
 On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso to...@tomeuvizoso.net 
 wrote:
 On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org 
 wrote:

 Tested on Venice2, Jetson TK1, and Big with a variety of USB2.0 and
 USB3.0 memory sticks and ethernet dongles using controller firmware
 recently posted by Andrew Chew [2].

 I have had mixed results when testing this on a Jetson TK1 board. Of 8
 USB devices I tested with, about half where probed correctly, but the
 other half repeatedly fail in hub_port_init because in the GET_STATUS
 right after the reset, the C_PORT_CONNECTION bit is set.

 I don't see any correlation between the failure and the kind of usb
 device, but I don't have much experience with USB implementations
 either.

 Hmm... I haven't seen that before.  Which particular devices were you 
 using?

 Here they are:

 work:

 Genius keyboard: 05d5:6782
 Logitech mouse: 046d:c06a
 Denver MP3 player: 10d6:1100
 Atheros Bluetooth dongle: 0cf3:3005

 don't work:

 MCS7830 ethernet dongle: 9710:7830
 Genesys Logic hub: 05e3:0608

 I tried the hub and it works just fine for me... Have you tried this
 on any other boards like Big or Blaze?

 I have a Blaze here, but haven't been able to get the external ports
 to power up. I don't have schematics nor a strong interest to get that
 fixed myself, as I can test my code just fine with the Blaze's
 internal camera and the devices that do work on the Jetson.

 Ok, since Blaze has been announced, hopefully we can post a
 device-tree for it soon.

 I'm using the firmware file that was posted recently:

 xhci-tegra 7009.usb: Firmware timestamp: 2014-05-02 02:22:50 UTC,
 Falcon state 0x20

 Yup, I'm using the same firmware.

 If things work for you with the same sources, .config and firmware, I
 can only think of the hw being different (other hw revision?).

 That, or perhaps bootloader differences?  I'm using mainline U-Boot.

Also mainline here:

U-Boot 2014.10-rc1-00136-g7bee1c9 (Aug 28 2014 - 15:22:05)

Don't know how to check what revision of the hw I have, though.

Regards,

Tomeu

 Stephen, Thierry, have either of you had a chance to test this series?
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/9] Tegra xHCI support

[Tomeu Vizoso]

On 12 September 2014 18:37, Andrew Bresticker abres...@chromium.org wrote:
 On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote:
 On 8 September 2014 18:22, Andrew Bresticker abres...@chromium.org wrote:
 On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote:
 On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote:

 Tested on Venice2, Jetson TK1, and Big with a variety of USB2.0 and
 USB3.0 memory sticks and ethernet dongles using controller firmware
 recently posted by Andrew Chew [2].

 I have had mixed results when testing this on a Jetson TK1 board. Of 8
 USB devices I tested with, about half where probed correctly, but the
 other half repeatedly fail in hub_port_init because in the GET_STATUS
 right after the reset, the C_PORT_CONNECTION bit is set.

 I don't see any correlation between the failure and the kind of usb
 device, but I don't have much experience with USB implementations
 either.

 Hmm... I haven't seen that before.  Which particular devices were you using?

 Here they are:

 work:

 Genius keyboard: 05d5:6782
 Logitech mouse: 046d:c06a
 Denver MP3 player: 10d6:1100
 Atheros Bluetooth dongle: 0cf3:3005

 don't work:

 MCS7830 ethernet dongle: 9710:7830
 Genesys Logic hub: 05e3:0608

 I tried the hub and it works just fine for me... Have you tried this
 on any other boards like Big or Blaze?

I have a Blaze here, but haven't been able to get the external ports
to power up. I don't have schematics nor a strong interest to get that
fixed myself, as I can test my code just fine with the Blaze's
internal camera and the devices that do work on the Jetson.

I'm using the firmware file that was posted recently:

xhci-tegra 7009.usb: Firmware timestamp: 2014-05-02 02:22:50 UTC,
Falcon state 0x20

If things work for you with the same sources, .config and firmware, I
can only think of the hw being different (other hw revision?).

Regards,

Tomeu
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/9] Tegra xHCI support

[Tomeu Vizoso]

On 09/09/2014 07:09 PM, Andrew Bresticker wrote:
 On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote:
 On 8 September 2014 18:22, Andrew Bresticker abres...@chromium.org wrote:
 On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote:
 On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote:

 Tested on Venice2, Jetson TK1, and Big with a variety of USB2.0 and
 USB3.0 memory sticks and ethernet dongles using controller firmware
 recently posted by Andrew Chew [2].

 I have had mixed results when testing this on a Jetson TK1 board. Of 8
 USB devices I tested with, about half where probed correctly, but the
 other half repeatedly fail in hub_port_init because in the GET_STATUS
 right after the reset, the C_PORT_CONNECTION bit is set.

 I don't see any correlation between the failure and the kind of usb
 device, but I don't have much experience with USB implementations
 either.

 Hmm... I haven't seen that before.  Which particular devices were you using?

 Here they are:

 work:

 Genius keyboard: 05d5:6782
 Logitech mouse: 046d:c06a
 Denver MP3 player: 10d6:1100
 Atheros Bluetooth dongle: 0cf3:3005

 don't work:

 MCS7830 ethernet dongle: 9710:7830
 Genesys Logic hub: 05e3:0608
 Alcor flash drive: 058f:6387
 JMicron SATA bridge: 152d:2329
 
 I have the same SATA bridge and it is enumerating fine for me, but
 I've ordered the hub as well and will check that out.
 
 Did you have any other patches applied when testing these?

Here is the branch, including the .config I used:

http://cgit.collabora.com/git/user/tomeu/linux.git/log/?h=3.17rc4-xhci

 Were you
 using either SATA or PCIe at the same time?

Nope, haven't even tried those yet.

 Just trying to figure out
 if there's anything else different between our setups.

Yeah, I'm afraid I don't have any good suggestion to make. But maybe you
will find some error on my part in how I have applied the patches or in
the config.

Regards,

Tomeu

 --
 To unsubscribe from this list: send the line unsubscribe linux-tegra in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/9] Tegra xHCI support

[Tomeu Vizoso]

On 8 September 2014 18:22, Andrew Bresticker abres...@chromium.org wrote:
 On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote:
 On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote:

 Tested on Venice2, Jetson TK1, and Big with a variety of USB2.0 and
 USB3.0 memory sticks and ethernet dongles using controller firmware
 recently posted by Andrew Chew [2].

 I have had mixed results when testing this on a Jetson TK1 board. Of 8
 USB devices I tested with, about half where probed correctly, but the
 other half repeatedly fail in hub_port_init because in the GET_STATUS
 right after the reset, the C_PORT_CONNECTION bit is set.

 I don't see any correlation between the failure and the kind of usb
 device, but I don't have much experience with USB implementations
 either.

 Hmm... I haven't seen that before.  Which particular devices were you using?

Here they are:

work:

Genius keyboard: 05d5:6782
Logitech mouse: 046d:c06a
Denver MP3 player: 10d6:1100
Atheros Bluetooth dongle: 0cf3:3005

don't work:

MCS7830 ethernet dongle: 9710:7830
Genesys Logic hub: 05e3:0608
Alcor flash drive: 058f:6387
JMicron SATA bridge: 152d:2329

HTH,

Tomeu
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/9] Tegra xHCI support

[Tomeu Vizoso]

On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote:

 Tested on Venice2, Jetson TK1, and Big with a variety of USB2.0 and
 USB3.0 memory sticks and ethernet dongles using controller firmware
 recently posted by Andrew Chew [2].

I have had mixed results when testing this on a Jetson TK1 board. Of 8
USB devices I tested with, about half where probed correctly, but the
other half repeatedly fail in hub_port_init because in the GET_STATUS
right after the reset, the C_PORT_CONNECTION bit is set.

I don't see any correlation between the failure and the kind of usb
device, but I don't have much experience with USB implementations
either.

Regards,

Tomeu

 Notes:
  - HSIC support is mostly untested and I think there are still some issues
to work out there.  I do have a Tegra124 board with a HSIC hub so I'll
try to sort those out later.
  - The XUSB padctl driver doesn't play nice with the existing Tegra USB2.0
PHY driver, so all ports should be assigned to the XHCI controller.

 Based on work by:
   a lot of people, but from what I can tell from the L4T tree [3], the
   original authors of the Tegra xHCI driver are:
 Ajay Gupta aj...@nvidia.com
 Bharath Yadav bya...@nvidia.com

 Chagnes from v2:
  - Dropped mailbox channel specifier.  The mailbox driver allocates virtual
channels backed by the single physical channel.
  - Added support for HS_CURR_LEVEL adjustment pinconfig property, which
will be required for the Blaze board.
  - Addressed Stephen's review comments.

 Changes from v1:
  - Converted mailbox driver to use the common mailbox framework.
  - Fixed up host driver so that it can now be built and used as a module.
  - Addressed Stephen's review comments.
  - Misc. cleanups.

 Changes from RFC:
  - Dropped Tegra114 support.
  - Split out mailbox into separate driver.
  - Stopped using child xhci-plat device in xHCI host-controller driver.
  - Added PHY support to Thierry's XUSB padctl driver instead of in a separate
USB PHY driver.
  - Added Jetson TK1 support.
  - Misc. cleanups.

 [0] https://lkml.org/lkml/2014/8/1/200
 [1] https://lkml.org/lkml/2014/8/18/504
 [2] https://patchwork.ozlabs.org/patch/384013/
 [3] git://nv-tegra.nvidia.com/linux-3.10.git

 Andrew Bresticker (9):
   of: Add NVIDIA Tegra XUSB mailbox binding
   mailbox: Add NVIDIA Tegra XUSB mailbox driver
   of: Update Tegra XUSB pad controller binding for USB
   pinctrl: tegra-xusb: Add USB PHY support
   of: Add NVIDIA Tegra xHCI controller binding
   usb: xhci: Add NVIDIA Tegra xHCI host-controller driver
   ARM: tegra: Add Tegra124 XUSB mailbox and xHCI controller
   ARM: tegra: jetson-tk1: Add xHCI support
   ARM: tegra: venice2: Add xHCI support

  .../bindings/mailbox/nvidia,tegra124-xusb-mbox.txt |   32 +
  .../pinctrl/nvidia,tegra124-xusb-padctl.txt|   56 +-
  .../bindings/usb/nvidia,tegra124-xhci.txt  |  104 ++
  arch/arm/boot/dts/tegra124-jetson-tk1.dts  |   48 +-
  arch/arm/boot/dts/tegra124-venice2.dts |   79 +-
  arch/arm/boot/dts/tegra124.dtsi|   41 +
  drivers/mailbox/Kconfig|3 +
  drivers/mailbox/Makefile   |2 +
  drivers/mailbox/tegra-xusb-mailbox.c   |  290 +
  drivers/pinctrl/Kconfig|1 +
  drivers/pinctrl/pinctrl-tegra-xusb.c   | 1233 
 +++-
  drivers/usb/host/Kconfig   |9 +
  drivers/usb/host/Makefile  |1 +
  drivers/usb/host/xhci-tegra.c  |  905 ++
  include/dt-bindings/pinctrl/pinctrl-tegra-xusb.h   |   20 +
  include/soc/tegra/xusb.h   |   53 +
  16 files changed, 2796 insertions(+), 81 deletions(-)
  create mode 100644 
 Documentation/devicetree/bindings/mailbox/nvidia,tegra124-xusb-mbox.txt
  create mode 100644 
 Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt
  create mode 100644 drivers/mailbox/tegra-xusb-mailbox.c
  create mode 100644 drivers/usb/host/xhci-tegra.c
  create mode 100644 include/soc/tegra/xusb.h

 --
 2.1.0.rc2.206.gedb03e5

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

Re: [PATCH v2 0/9] Tegra xHCI support

[Tomeu Vizoso]

On 18 August 2014 19:08, Andrew Bresticker abres...@chromium.org wrote:

 Tested on Venice2, Jetson TK1, and Big with a variety of USB2.0 and
 USB3.0 memory sticks and ethernet dongles using controller firmware from
 the ChromiumOS tree [2].

Hi Andrew,

do you have any information regarding the port assignments for the
Blaze board? Would like to test this there.

Thanks,

Tomeu
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html