On Tue, Nov 27, 2018 at 12:03 PM Georgi Djakov <georgi.djakov@xxxxxxxxxx> wrote: > > This patch introduces a new API to get requirements and configure the > interconnect buses across the entire chipset to fit with the current > demand. > > The API is using a consumer/provider-based model, where the providers are > the interconnect buses and the consumers could be various drivers. > The consumers request interconnect resources (path) between endpoints and > set the desired constraints on this data flow path. The providers receive > requests from consumers and aggregate these requests for all master-slave > pairs on that path. Then the providers configure each participating in the > topology node according to the requested data flow path, physical links and > constraints. The topology could be complicated and multi-tiered and is SoC > specific. > > Signed-off-by: Georgi Djakov <georgi.djakov@xxxxxxxxxx> > Reviewed-by: Evan Green <evgreen@xxxxxxxxxxxx> [...] > +struct icc_path *icc_get(struct device *dev, const int src_id, > + const int dst_id); > +void icc_put(struct icc_path *path); > +int icc_set(struct icc_path *path, u32 avg_bw, u32 peak_bw); icc_set() is very generic, but this function isn't easily extended to other parameters than bandwidth. Perhaps icc_set_bandwidth() instead. Then when you add some other setting, you just add a new function. Of course, if you wind up with a bunch of different parameters, then you'll probably need an atomic type interface where you test all the settings together and then commit them separately in one call. But from a DT perspective, I certainly hope there are not lots of new settings folks want to add. :) Rob
