Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> writes: > On Tue, Aug 25, 2015 at 3:45 PM, Kevin Hilman <khilman@xxxxxxxxxx> wrote: >> Doug Anderson <dianders@xxxxxxxxxxxx> writes: >> >>> To put things in a >>> concrete way, for pd_vio we'd go through the entire device tree >>> ourselves and find all properties that look like "power-domains = >>> <&power RK3288_PD_VIO>;". We'd then find the parent of those >>> properties and look for a property named "clocks". We'd then iterate >>> over all those clocks and turn those on. Did I get that right? >> >> ... but you make it sound like more work than it is. The genpd already >> keeps a list of devices that refer to the power domain. In fact, the >> genpd 'attach' method can be platform-specific, so could be used to keep >> track of a list (or a subset) of clocks which are needed for reset. > > That is not really workable: the attach and detach happen in > probe/remove path; if you do not have driver for the device you will > miss the clocks for it. And in my proposal, I suggested that clocks without drivers are good candidates to list in the domain, with the caveat that the be called out (documented) as being device clocks that are missing a driver, so when a driver shows up they can be moved accordingly, and in a way that actually describes the hardware. > And the quirk of this SoC is that we need to > turn all clocks during domain transition, regardless of whether there > is a driver for all devices. I understand. And that "quirk" is not unique to rockchip socs. Kevin -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
