---
drivers/base/core.c| 42 ++
include/linux/device.h | 3 +++
2 files changed, 45 insertions(+)
Basic version of the helper looks very good to me, thank you.
Reviewed-by: Grygorii Strashko
diff --git a/drivers/base/core.c b/drivers/base/core.c
Hi
On 29/06/2020 14:28, Andrzej Hajda wrote:
Hi Grygorii,
(...)
/*
* deferred_devs_show() - Show the devices in the deferred probe
pending list.
*/
@@ -221,7 +241,8 @@ static int deferred_devs_show(struct seq_file *s,
void *data)
mutex_lock(&deferred_probe_mutex);
l
On 26/06/2020 13:01, Andrzej Hajda wrote:
/sys/kernel/debug/devices_deferred property contains list of deferred devices.
This list does not contain reason why the driver deferred probe, the patch
improves it.
The natural place to set the reason is probe_err function introduced recently,
ie. if
On 17/06/2020 09:04, Tomi Valkeinen wrote:
On 16/06/2020 19:56, Grygorii Strashko wrote:
On 16/06/2020 18:30, Tony Lindgren wrote:
* Tomi Valkeinen [200616 13:02]:
On 11/06/2020 17:00, Grygorii Strashko wrote:
I think, suspend might be fixed if all devices, which are now child of ti
On 16/06/2020 18:30, Tony Lindgren wrote:
* Tomi Valkeinen [200616 13:02]:
On 11/06/2020 17:00, Grygorii Strashko wrote:
I think, suspend might be fixed if all devices, which are now child of ti-sysc,
will do
pm_runtime_force_xxx() calls at noirq suspend stage by adding
On 09/06/2020 18:26, Tomi Valkeinen wrote:
On 09/06/2020 18:19, Tony Lindgren wrote:
But there's an extra runtime PM reference (dev.power.usage_count) that seems
to come out of nowhere. So when omap_drm_suspend is finished, there's still
usage_count of 1, and dispc never suspends fully.
Hmm
Hi Russell,
On 10/21/2015 09:28 PM, Russell King - ARM Linux wrote:
> On Wed, Oct 21, 2015 at 09:13:48PM +0300, Grygorii Strashko wrote:
>> But I worry a bit (and that my main point) about these few additional
>> rounds of deferred device probing which I have right now and which al
On 10/21/2015 09:02 PM, Frank Rowand wrote:
> On 10/21/2015 9:55 AM, Grygorii Strashko wrote:
>> On 10/21/2015 06:36 PM, Frank Rowand wrote:
>>> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
>>>> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrot
Hi Russell,
On 10/21/2015 08:20 PM, Russell King - ARM Linux wrote:
> On Wed, Oct 21, 2015 at 07:55:29PM +0300, Grygorii Strashko wrote:
>> On 10/21/2015 06:36 PM, Frank Rowand wrote:
>>> The above is currently the last point for probe to succeed or defer
>>> (until
On 10/21/2015 06:36 PM, Frank Rowand wrote:
> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
>> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
>>> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
>
> < snip >
>
+
static bool driver_deferred_probe_enable =
On 03/02/2015 01:03 PM, Tomi Valkeinen wrote:
> On 26/02/15 15:57, Grygorii.Strashko at linaro.org wrote:
>
>> Could I ask you to update this patch as below, pls?
>
> Your changes look ok to me, but they are not related to my patch so I
> don't see any reason to merge them. I'll pick your patch t
On 11/03/2014 06:13 PM, Kevin Hilman wrote:
> Andrzej Hajda writes:
>
>> On 10/30/2014 08:36 AM, Krzysztof Kozlowski wrote:
>>> On Åro, 2014-10-29 at 10:46 -0700, Kevin Hilman wrote:
Krzysztof Kozlowski writes:
> When resuming the system the power domain has to be powered on early
Hi Krzysztof,
On 10/23/2014 04:48 PM, Krzysztof Kozlowski wrote:
> When resuming the system the power domain has to be powered on early so
> any runtime PM aware devices could resume.
>
> This fixes following scenario reproduced on Exynos DRM:
> 1. Power domain is off before suspending the system
13 matches
Mail list logo
