imx8qxp mek: Booting mainline kernel with mainline U-Boot

[Lokesh Vutla]

On 16/01/20 11:46 PM, Tom Rini wrote:
> On Thu, Jan 16, 2020 at 08:03:51PM +0200, Igor Opaniuk wrote:
>> Hi Fabio,
>>
>> On Thu, Jan 16, 2020 at 6:38 PM Fabio Estevam <festevam at gmail.com> wrote:
>>>
>>> Hi Anatolij,
>>>
>>> On Tue, Jan 14, 2020 at 8:04 PM Anatolij Gustschin <agust at denx.de> wrote:
>>>
>>>> Currently I do not have an i.MX8QXP MEK board with RevB CPU and cannot
>>>> test, but I have an i.MX8QXP based custom SoM with console on ttyLP2.
>>>> Here I tested with NXP BSP kernel based on branch imx_4.14.98_2.0.0_ga
>>>> and it boots successfully (with NFS rootfs or rootfs on eMMC).
>>>
>>> I have just tested imx_4.14.98_2.0.0_ga and still get the same hang.
>>>
>>> [Adding Marcel]
>> Marcel is on vacation.
>>
>> FYI, mainline U-boot is broken on all our iMX8QXP and iMX8QM SoMs
>> at all since f0cc4eae9a ("core: device: use dev_power_domain_on") is merged, the
>> status hasn't changed. I haven't got deeply into this issue, just
>> quickly tried different
>> combinations of TF-A and SECO/SCFW, none of them has any impact.
>> Will get back to this issue soon.
>>>
>>> Just wondering if anyone else managed to boot mainline U-Boot with
>>> mainline kernel on i.MX8QXP.
>> I can test it for you with the revert patch for f0cc4eae9a applied tomorrow.
> 
> Adding in Lokesh as he nak'd the revert before because that would break
> other platforms and I chimed in saying that breaking one set of
> platforms to unbreak another set of platforms isn't a trade-off I like.
> 

Right, the mentioned patch f0cc4eae9a1 ("core: device: use dev_power_domain_on")
checks for power_domain return status when dm core tries to enable pd during
probe. If power domain enabling is failed then no point proceeding further to probe.

There are 2 ways to solve this:
1) Drop the return check like below. Which IMHO is a hack:

diff --git a/drivers/core/device.c b/drivers/core/device.c
index 9f39218423..c80ce16fbd 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -432,11 +432,8 @@ int device_probe(struct udevice *dev)

 	if (CONFIG_IS_ENABLED(POWER_DOMAIN) && dev->parent &&
 	    (device_get_uclass_id(dev) != UCLASS_POWER_DOMAIN) &&
-	    !(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF)) {
-		ret = dev_power_domain_on(dev);
-		if (ret)
-			goto fail;
-	}
+	    !(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF))
+		dev_power_domain_on(dev);

 	ret = uclass_pre_probe_device(dev);
 	if (ret)


2) Debug which device power-domain is failing and fix the driver or make sure
that dm core will not touch the pd by enabling the flag
DM_FLAG_DEFAULT_PD_CTRL_OFF in it.

Thanks and regards,
Lokesh