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
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,
Could this patch be picked up, please?
Thanks,
Tomeu
On 26 March 2018 at 13:51, Heiko Stübner 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
_hcd_start.
Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus
supply")
Cc: Amelie Delaunay
Signed-off-by: Tomeu Vizoso
---
v2: Only overwrite the error in the pointer after checking it (Heiko
Stübner )
v3: Remove hunks that shouldn't be in this patch
v4:
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
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, ma
_hcd_start.
Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus
supply")
Cc: Amelie Delaunay
Signed-off-by: Tomeu Vizoso
---
v2: Only overwrite the error in the pointer after checking it (Heiko
Stübner )
v3: Remove hunks that shouldn't be in this patch
--
_hcd_start.
Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus
supply")
Cc: Amelie Delaunay
Signed-off-by: Tomeu Vizoso
---
v2: Only overwrite the error in the pointer after checking it (Heiko
Stübner )
---
arch/arm/configs/multi_v7_defconfig | 3 +++
dr
_hcd_start.
Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus
supply")
Cc: Amelie Delaunay
Signed-off-by: Tomeu Vizoso
---
drivers/usb/dwc2/hcd.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/
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 sl
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
Reviewed-by: Ulf Hansson
Acked-by: Alan Stern
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
Reviewed-by: Ulf Hansson
Acked-by: Alan Stern
m_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):
devi
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 foc
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:
>>>
>>>
>>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
>>>> But
On 22 October 2015 at 02:54, Rafael J. Wysocki wrote:
> On Tuesday, October 20, 2015 06:21:55 PM Tomeu Vizoso wrote:
>> On 20 October 2015 at 18:04, Alan Stern wrote:
>> > On Tue, 20 Oct 2015, Mark Brown wrote:
>> >
>> >> On Tue, Oct 20, 201
On 21 October 2015 at 23:50, Frank Rowand wrote:
> On 10/21/2015 2:12 PM, Rob Herring wrote:
>> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand wrote:
>>> On 10/21/2015 9:27 AM, Mark Brown wrote:
>>>> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
>
n 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
US
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
Reviewed-by: Ulf Hansson
---
Changes in v10
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 restric
On 19 October 2015 at 16:30, Russell King - ARM Linux
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
>> wrote:
>> > On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote:
>> &
On 19 October 2015 at 15:18, Russell King - ARM Linux
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&
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 a
(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
://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
backs 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/a
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
---
drivers/usb/core/port.c | 6 ++
drivers
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 callbac
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
---
drivers/usb/core/port.c | 6 ++
drivers
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
---
drivers/usb/core/port.c | 6 ++
drivers
7;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 ca
lag.
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 sleep
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
---
drivers/usb/core/port.c | 6 ++
drivers
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
---
drivers/usb/core/port.c | 6 ++
drivers
nd 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 d
On 9 September 2015 at 03:33, Rob Herring wrote:
> On 09/08/2015 02:30 AM, Tomeu Vizoso wrote:
>> On 7 September 2015 at 22:50, Rob Herring wrote:
>>> On Mon, Sep 7, 2015 at 7:23 AM, Tomeu Vizoso
>>> wrote:
>>>> Hello,
>>>>
>>>>
On 7 September 2015 at 22:50, Rob Herring wrote:
> On Mon, Sep 7, 2015 at 7:23 AM, Tomeu Vizoso
> 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
When looking up a phy through its OF 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:
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:
- A
bed change due to
async probing or on-demand probing of dependencies.
Signed-off-by: Tomeu Vizoso
---
drivers/usb/chipidea/ci_hdrc_imx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 50
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:
o 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
On 16 July 2015 at 02:42, Rafael J. Wysocki 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
ystem 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 sle
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
---
drivers/usb/core/port.c | 6 ++
drivers/usb
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
---
Changes in v2: None
drivers/usb/host/ehci-tegra.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/usb/host/ehci
perty 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 de
On 28 May 2015 at 06:33, Rob Herring wrote:
> On Mon, May 25, 2015 at 9:53 AM, Tomeu Vizoso
> 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
On 10 June 2015 at 09:30, Linus Walleij wrote:
> On Tue, Jun 2, 2015 at 12:14 PM, Tomeu Vizoso
> wrote:
>> On 2 June 2015 at 10:48, Linus Walleij wrote:
>
>>> This is what systemd is doing in userspace for starting services:
>>> ask for your dependencies
On 3 June 2015 at 21:57, 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
>> wrote:
>>> I have a problem with the panel on my Tegra Chromebook taking longer than
>&g
On 2 June 2015 at 10:48, Linus Walleij wrote:
> On Mon, May 25, 2015 at 4:53 PM, Tomeu Vizoso
> 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.
>>
>> Whil
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: Regi
When looking up a phy through its DT node, ensure that the corresponding
device has been registered.
Signed-off-by: Tomeu Vizoso
---
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
On 31 March 2015 at 19:09, Alan Stern 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.
>
ecessarily"),
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
.
Signed-off-by: Tomeu Vizoso
---
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
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
ntime-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)
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
Thanks,
Tomeu
> Signed-off-by: Vince Hsu
> ---
> Hi,
>
> This fixes a regression found on 3.19-rc1. The USB ho
On 15 September 2014 19:06, Andrew Bresticker wrote:
> On Mon, Sep 15, 2014 at 12:00 AM, Tomeu Vizoso wrote:
>> On 12 September 2014 18:37, Andrew Bresticker wrote:
>>> On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso wrote:
>>>> On 8 September 2014 18:22, Andrew B
On 12 September 2014 18:37, Andrew Bresticker wrote:
> On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso wrote:
>> On 8 September 2014 18:22, Andrew Bresticker wrote:
>>> On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso wrote:
>>>> On 2 September 2014 23:34, Andrew Brestic
On 09/09/2014 07:09 PM, Andrew Bresticker wrote:
> On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso wrote:
>> On 8 September 2014 18:22, Andrew Bresticker wrote:
>>> On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso wrote:
>>>> On 2 September 2014 23:34, Andrew Bresticker
On 8 September 2014 18:22, Andrew Bresticker wrote:
> On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso wrote:
>> On 2 September 2014 23:34, Andrew Bresticker wrote:
>>>
>>> Tested on Venice2, Jetson TK1, and Big with a variety of USB2.0 and
>>> USB3.0 memo
On 2 September 2014 23:34, Andrew Bresticker 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.
On 21 August 2014 19:26, Andrew Bresticker wrote:
> On Thu, Aug 21, 2014 at 6:34 AM, Tomeu Vizoso wrote:
>> On 18 August 2014 19:08, Andrew Bresticker wrote:
>>>
>>> Tested on Venice2, Jetson TK1, and Big with a variety of USB2.0 and
>>> USB3.0 memo
On 18 August 2014 19:08, Andrew Bresticker 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 fo
66 matches
Mail list logo
