Thread (69 messages) 69 messages, 11 authors, 2022-08-15

Re: [PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()

From: Tony Lindgren <tony@atomide.com>
Date: 2022-07-01 05:34:03
Also in: linux-gpio, linux-iommu, linux-pm, lkml

* Saravana Kannan [off-list ref] [220630 23:25]:
On Thu, Jun 30, 2022 at 4:26 PM Rob Herring [off-list ref] wrote:
quoted
On Thu, Jun 30, 2022 at 5:11 PM Saravana Kannan [off-list ref] wrote:
quoted
On Mon, Jun 27, 2022 at 2:10 AM Tony Lindgren [off-list ref] wrote:
quoted
* Saravana Kannan [off-list ref] [220623 08:17]:
quoted
On Thu, Jun 23, 2022 at 12:01 AM Tony Lindgren [off-list ref] wrote:
quoted
* Saravana Kannan [off-list ref] [220622 19:05]:
quoted
On Tue, Jun 21, 2022 at 9:59 PM Tony Lindgren [off-list ref] wrote:
quoted
This issue is no directly related fw_devlink. It is a side effect of
removing driver_deferred_probe_check_state(). We no longer return
-EPROBE_DEFER at the end of driver_deferred_probe_check_state().
Yes, I understand the issue. But driver_deferred_probe_check_state()
was deleted because fw_devlink=on should have short circuited the
probe attempt with an  -EPROBE_DEFER before reaching the bus/driver
probe function and hitting this -ENOENT failure. That's why I was
asking the other questions.
OK. So where is the -EPROBE_DEFER supposed to happen without
driver_deferred_probe_check_state() then?
device_links_check_suppliers() call inside really_probe() would short
circuit and return an -EPROBE_DEFER if the device links are created as
expected.
OK
quoted
quoted
Hmm so I'm not seeing any supplier for the top level ocp device in
the booting case without your patches. I see the suppliers for the
ocp child device instances only.
Hmmm... this is strange (that the device link isn't there), but this
is what I suspected.
Yup, maybe it's because of the supplier being a device in the child
interconnect for the ocp.
Ugh... yeah, this is why the normal (not SYNC_STATE_ONLY) device link
isn't being created.

So the aggregated view is something like (I had to set tabs = 4 space
to fit it within 80 cols):

    ocp: ocp {         <========================= Consumer
        compatible = "simple-pm-bus";
        power-domains = <&prm_per>; <=========== Supplier ref

                l4_wkup: interconnect@44c00000 {
            compatible = "ti,am33xx-l4-wkup", "simple-pm-bus";

            segment@200000 {  /* 0x44e00000 */
                compatible = "simple-pm-bus";

                target-module@0 { /* 0x44e00000, ap 8 58.0 */
                    compatible = "ti,sysc-omap4", "ti,sysc";

                    prcm: prcm@0 {
                        compatible = "ti,am3-prcm", "simple-bus";

                        prm_per: prm@c00 { <========= Actual Supplier
                            compatible = "ti,am3-prm-inst", "ti,omap-prm-inst";
                        };
                    };
                };
            };
        };
    };

The power-domain supplier is the great-great-great-grand-child of the
consumer. It's not clear to me how this is valid. What does it even
mean?

Rob, is this considered a valid DT?
Valid DT for broken h/w.
I'm not sure even in that case it's valid. When the parent device is
in reset (when the SoC is coming out of reset), there's no way the
descendant is functional. And if the descendant is not functional, how
is the parent device powered up? This just feels like an incorrect
representation of the real h/w.
It should be correct representation based on scanning the interconnects
and looking at the documentation. Some interconnect parts are wired
always-on and some interconnect instances may be dual-mapped.

We have a quirk to probe prm/prcm first with pdata_quirks_init_clocks().
Maybe that also now fails in addition to the top level interconnect
probing no longer producing -EPROBE_DEFER.
quoted
So the domain must be default on and then simple-pm-bus is going to
hold a reference to the domain preventing it from ever getting powered
off and things seem to work. Except what happens during suspend?
But how can simple-pm-bus even get a reference? The PM domain can't
get added until we are well into the probe of the simple-pm-bus and
AFAICT the genpd attach is done before the driver probe is even
called.
The prm/prcm gets of_platform_populate() called on it early.

Regards,

Tony
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help