On 15/04/25 18:13, Miquel Raynal wrote: > On 15/04/2025 at 15:29:09 +0530, Neha Malcom Francis <n-fran...@ti.com> wrote: > >> Hi Miquel >> >> On 15/04/25 15:20, Miquel Raynal wrote: >>>>> Francesco, are you also testing on K3 platforms? >>>>> >>>> >>>> Yes he would be, since the firmware print is K3 firmware. >>>> >>>>> Can one of you boot with the patch below applied? It should partially >>>>> revert the commit to the ancient behaviour, while adding more debug >>>>> traces (please enable the debug logs as well). This should clarify >>>>> which one of the 3 different path is likely failing. It should also help >>>>> identify who's the user that fails to enable/disable its own power >>>>> domain. I will need to know what board/SoC was used for the test, so I >>>>> can look the relevant driver up. >>>> >>>> Booted on j784s4_evm >>>> >>>> https://gist.github.com/nehamalcom/b09687a523bec89f9df3537fdd99b6f3 >> >> ^ > > Ah, sorry! This is very interesting. > > There are two things which I do not understand: > - if we look at the very first power domains, their id is 15 and 14 > respectively. I do not see these numbers in any device tree, am I > looking incorrectly? Could you help me identify what are the devices > requesting these IDs?
Yeah this might have been confusing. We have device IDs which are what is mentioned in the device tree mapped to the power domain (LPSC) IDs via arch/arm/mach-k3/r5/j784s4/dev-data.c which is consumed by a rudimentary power domain driver ti-power-domain.c I have enabled a debug log in ti-power-domain.c so you can see what is the device ID that is eventually mapped to it's corresponding power domain ID. So from: ti_power_domain_of_xlate(power_domain=41c65ecc, id=191) power_domain_on_lowlevel(power_domain=41c65ecc, id 15) You can see that LPSC 15 was mapped from dev ID 191 which is from memorycontroller@2990000. Hope this helps. > - all power domains appear to be already enabled the very first time we > enable them. I believe this is the root cause of the problem, as they > should have count_on to 0 when booting. I checked again, We're seeing only the logs after console is up. We are definitely enabling up some power domains for the first time prior to the very first print. > 'per_device_auto' is a field that is zeroed when allocated (using > calloc() in this case) so I am really puzzled about this. It looks > like "something else" is using this data field, which would be > wrong. > >>>> >>>> Currently debugging on my build where I hang in console_init itself, I >>>> think the path for failure is different here, will confirm. >>> >>> Thanks a lot for your feedback. Normally by applying the diff shared in >>> my previous e-mail, you should have the console back. If not, maybe >>> there is something else involved and the blamed commit is just the first >>> showing an underlying problem. >> >> I do have console back with that patch, see the gist link above. What I >> meant was the path of failure seems to be different, it's looking like >> with my version of firmware the serial driver probe >> (ns16550_serial_probe) tries to do a readb() and fails, this could >> possibly be because the device was not powered on to begin with. Whereas >> in another case (what Francesco is seeing), this issue is not run >> into. > > Clear. > > Could you make another round with this extra change? https://gist.github.com/nehamalcom/6772169d2b26d89ddcdeaf6049a8ff8f This includes the debug logs you've provided as well as the debug log I added as mentioned above. Maybe I need to go over the power framework in detail, but it seems like we (K3 devices) have a singular power-controller node that internally goes ahead and turns on the respective power domain via our ti,sci-pm-domain drivers. So the power-domain uclass sees only one power domain i.e. power-controller and keeps incrementing it's on_count (see the logs, I debugged even before the prints come we start from 0 and keep incrementing the same power-controller's on_count). But maybe what you expect when you wrote this patch is something similar to the fsl,imx8mq-gpc drivers where each power-domain is a device node with it's own on_count (see arm64/freescale/imx8mq.dtsi)? > > Thanks! > Miquèl > > --- a/drivers/power/domain/power-domain-uclass.c > +++ b/drivers/power/domain/power-domain-uclass.c > @@ -119,14 +119,18 @@ int power_domain_on_lowlevel(struct power_domain > *power_domain) > > debug("%s(power_domain=%p, id %d)\n", __func__, power_domain, > power_domain->id); > > - if (priv->on_count++ > 0) { > - debug("Power domain %s already on.\n", > power_domain->dev->name); > + if (priv->on_count > 0) { > + debug("Power domain %s already on (usage count: %d).\n", > power_domain->dev->name, priv->on_count); > + priv->on_count++; > //return -EALREADY; > + } else { > + priv->on_count++; > } > > ret = ops->on ? ops->on(power_domain) : 0; > if (ret) { > priv->on_count--; > + debug("Power domain %s on failed (usage count: %d).\n", > power_domain->dev->name, priv->on_count); > return ret; > } > -- Thanking You Neha Malcom Francis
