[PATCH] Revert "dm: core: device: switch off power domain after device removal"

[PATCH] Revert "dm: core: device: switch off power domain after device removal"

[Neil Armstrong]

This commit breaks Linux boot on Amlogic libretech-cc, libretech-ac, sei510,
sei610 board by automatically disabling the power domain after device removal.
This because the power domain associated to the video driver must be kept
enabled for linux to boot.

The only way is to use the introduced flag DM_FLAG_DEFAULT_PD_CTRL_OFF, which
removes automatic handling of power domain.
This flag is not a complete solution since it will force reverting to manually
enable the power domain from the driver probe.

Instead a flag to keep the power domain enabled after removal should be
introduced.

In the meantime revert this commit until a proper solution is found.

This reverts commit 52edfed65de967a86983a55c51ba0727090efc43.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Hi Simon, Tom,

This revert is the simplest fix to make the boards boot again on v2020.04,
the goal is to make this behavior happen again with a proper flag to keep the
power domain enabled on specific drivers.

I can push it on my next PR on my branch, is it ok ?

Neil

 drivers/core/device-remove.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/drivers/core/device-remove.c b/drivers/core/device-remove.c
index 444e34b492..5540053d3c 100644
--- a/drivers/core/device-remove.c
+++ b/drivers/core/device-remove.c
@@ -16,7 +16,6 @@
 #include <dm/uclass.h>
 #include <dm/uclass-internal.h>
 #include <dm/util.h>
-#include <power-domain.h>
 
 int device_chld_unbind(struct udevice *dev, struct driver *drv)
 {
@@ -194,10 +193,6 @@ int device_remove(struct udevice *dev, uint flags)
 		}
 	}
 
-	if (!(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF) &&
-	    (dev != gd->cur_serial_dev))
-		dev_power_domain_off(dev);
-
 	if (flags_remove(flags, drv->flags)) {
 		device_free(dev);
 
-- 
2.22.0

[PATCH] Revert "dm: core: device: switch off power domain after device removal"

[Anatolij Gustschin]

On Mon, 17 Feb 2020 10:10:36 +0100
Neil Armstrong narmstrong at baylibre.com wrote:

> This commit breaks Linux boot on Amlogic libretech-cc, libretech-ac, sei510,
> sei610 board by automatically disabling the power domain after device removal.
> This because the power domain associated to the video driver must be kept
> enabled for linux to boot.
> 
> The only way is to use the introduced flag DM_FLAG_DEFAULT_PD_CTRL_OFF, which
> removes automatic handling of power domain.
> This flag is not a complete solution since it will force reverting to manually
> enable the power domain from the driver probe.
> 
> Instead a flag to keep the power domain enabled after removal should be
> introduced.
> 
> In the meantime revert this commit until a proper solution is found.
> 
> This reverts commit 52edfed65de967a86983a55c51ba0727090efc43.
> 
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> Hi Simon, Tom,
> 
> This revert is the simplest fix to make the boards boot again on v2020.04,
> the goal is to make this behavior happen again with a proper flag to keep the
> power domain enabled on specific drivers.
> 
> I can push it on my next PR on my branch, is it ok ?

Please test if these two patches fix the problem:
 http://patchwork.ozlabs.org/patch/1239143
 http://patchwork.ozlabs.org/patch/1239144

--
Anatolij

[PATCH] Revert "dm: core: device: switch off power domain after device removal"

[Neil Armstrong]

Hi Anatolij,

On 17/02/2020 12:53, Anatolij Gustschin wrote:
> On Mon, 17 Feb 2020 10:10:36 +0100
> Neil Armstrong narmstrong at baylibre.com wrote:
> 
>> This commit breaks Linux boot on Amlogic libretech-cc, libretech-ac, sei510,
>> sei610 board by automatically disabling the power domain after device removal.
>> This because the power domain associated to the video driver must be kept
>> enabled for linux to boot.
>>
>> The only way is to use the introduced flag DM_FLAG_DEFAULT_PD_CTRL_OFF, which
>> removes automatic handling of power domain.
>> This flag is not a complete solution since it will force reverting to manually
>> enable the power domain from the driver probe.
>>
>> Instead a flag to keep the power domain enabled after removal should be
>> introduced.
>>
>> In the meantime revert this commit until a proper solution is found.
>>
>> This reverts commit 52edfed65de967a86983a55c51ba0727090efc43.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> Hi Simon, Tom,
>>
>> This revert is the simplest fix to make the boards boot again on v2020.04,
>> the goal is to make this behavior happen again with a proper flag to keep the
>> power domain enabled on specific drivers.
>>
>> I can push it on my next PR on my branch, is it ok ?
> 

Thanks for pushing these, they should do the trick.

Let me test them and ack them.

Neil

> Please test if these two patches fix the problem:
>  http://patchwork.ozlabs.org/patch/1239143
>  http://patchwork.ozlabs.org/patch/1239144
> 
> --
> Anatolij
> 

[PATCH] Revert "dm: core: device: switch off power domain after device removal"

[Neil Armstrong]

Hi Analolij,

On 17/02/2020 12:53, Anatolij Gustschin wrote:
> On Mon, 17 Feb 2020 10:10:36 +0100
> Neil Armstrong narmstrong at baylibre.com wrote:
> 
>> This commit breaks Linux boot on Amlogic libretech-cc, libretech-ac, sei510,
>> sei610 board by automatically disabling the power domain after device removal.
>> This because the power domain associated to the video driver must be kept
>> enabled for linux to boot.
>>
>> The only way is to use the introduced flag DM_FLAG_DEFAULT_PD_CTRL_OFF, which
>> removes automatic handling of power domain.
>> This flag is not a complete solution since it will force reverting to manually
>> enable the power domain from the driver probe.
>>
>> Instead a flag to keep the power domain enabled after removal should be
>> introduced.
>>
>> In the meantime revert this commit until a proper solution is found.
>>
>> This reverts commit 52edfed65de967a86983a55c51ba0727090efc43.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> Hi Simon, Tom,
>>
>> This revert is the simplest fix to make the boards boot again on v2020.04,
>> the goal is to make this behavior happen again with a proper flag to keep the
>> power domain enabled on specific drivers.
>>
>> I can push it on my next PR on my branch, is it ok ?
> 
> Please test if these two patches fix the problem:
>  http://patchwork.ozlabs.org/patch/1239143
>  http://patchwork.ozlabs.org/patch/1239144

Should I apply these through my tree or you plan to push these yourself ?

Thanks,
Neil

> 
> --
> Anatolij
> 

[PATCH] Revert "dm: core: device: switch off power domain after device removal"

[Anatolij Gustschin]

Hi Neil,

On Mon, 2 Mar 2020 10:30:31 +0100
Neil Armstrong narmstrong at baylibre.com wrote:

> Hi Analolij,
> 
> On 17/02/2020 12:53, Anatolij Gustschin wrote:
> > On Mon, 17 Feb 2020 10:10:36 +0100
> > Neil Armstrong narmstrong at baylibre.com wrote:
> >   
> >> This commit breaks Linux boot on Amlogic libretech-cc, libretech-ac, sei510,
> >> sei610 board by automatically disabling the power domain after device removal.
> >> This because the power domain associated to the video driver must be kept
> >> enabled for linux to boot.
> >>
> >> The only way is to use the introduced flag DM_FLAG_DEFAULT_PD_CTRL_OFF, which
> >> removes automatic handling of power domain.
> >> This flag is not a complete solution since it will force reverting to manually
> >> enable the power domain from the driver probe.
> >>
> >> Instead a flag to keep the power domain enabled after removal should be
> >> introduced.
> >>
> >> In the meantime revert this commit until a proper solution is found.
> >>
> >> This reverts commit 52edfed65de967a86983a55c51ba0727090efc43.
> >>
> >> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> >> ---
> >> Hi Simon, Tom,
> >>
> >> This revert is the simplest fix to make the boards boot again on v2020.04,
> >> the goal is to make this behavior happen again with a proper flag to keep the
> >> power domain enabled on specific drivers.
> >>
> >> I can push it on my next PR on my branch, is it ok ?  
> > 
> > Please test if these two patches fix the problem:
> >  http://patchwork.ozlabs.org/patch/1239143
> >  http://patchwork.ozlabs.org/patch/1239144  
> 
> Should I apply these through my tree or you plan to push these yourself ?

These patches are assigned to Simon in patchwork, and are in his tree
under build-testing I think.

--
Anatolij