On Fri, Apr 08, 2016 at 01:19:36PM +0200, Ulf Hansson wrote: > [...] > > >> > > >> > Shouldn't this be split into latency of the domain (and in the domain's > >> > node) and latency of the device? > >> > >> Yes! $Subject patch only takes device latencies into account. > >> > >> Perhaps what you mean is that we should document device PM QoS > >> latencies in another place than > >> Documentation/devicetree/bindings/power/power_domain.txt as well? > > > > Yes, the location is confusing that this is device latency which has > > nothing to do with power domains other than the fact we've lost all > > state (which a reset could cause too). > > Okay, will a new file, > Documentation/devicetree/bindings/power/device_qos.txt make sense for > you? > > > > >> Regarding bindings for the domain latencies, I will post that as a > >> separate patch soonish. > > > > It probably makes sense to look at latency bindings as a whole series. > > Well, unless you insist, I would rather look at this first. > > The domain latencies might be a bit more complex and those shouldn't > affect how we describe device latencies, or you think so? Probably not, but I was thinking at least property names would be common. Besides power domains, any external component can add latencies. For example, what's the latency for a display (subsystem) when you have display controller, phy, external bridge and panel? What I don't want to see in DT are people doing some simple latency that's added up all the components and then coming back later and saying they need to change it to be more fine grained and distributed to each component. Rob > > Kind regards > Uffe -- 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
