Message ID | cover.1586174566.git.leonard.crestez@nxp.com (mailing list archive) |
---|---|
Headers | show |
Series | interconnect: Add imx support via devfreq | expand |
Hi, On 4/6/20 15:03, Leonard Crestez wrote: > This series adds interconnect scaling support for imx8m series chips. It uses a > per-SOC interconnect provider layered on top of multiple instances of devfreq > for scalable nodes along the interconnect. > > Existing qcom interconnect providers mostly translate bandwidth requests into > firmware calls but equivalent firmware on imx8m is much thinner. Scaling > support for individual nodes is implemented as distinct devfreq drivers > instead. > > The imx interconnect provider doesn't communicate with devfreq directly > but rather computes "minimum frequencies" for nodes along the path and > creates dev_pm_qos requests. > > Since there is no single devicetree node that can represent the > "interconnect" the main NOC is picked as the "interconnect provider" and > will probe the interconnect platform device if #interconnect-cells is > present. This avoids introducing "virtual" devices but it means that DT > bindings of main NOC includes properties for both devfreq and > interconnect. Thank you for your work Leonard! There is no build dependency between the devfreq and interconnect patches, so i can apply patches 1,4-7. Chanwoo, should i take also the two devfreq patches with your Ack? Thanks, Georgi
Hi, On 4/29/20 4:30 PM, Georgi Djakov wrote: > Hi, > > On 4/6/20 15:03, Leonard Crestez wrote: >> This series adds interconnect scaling support for imx8m series chips. It uses a >> per-SOC interconnect provider layered on top of multiple instances of devfreq >> for scalable nodes along the interconnect. >> >> Existing qcom interconnect providers mostly translate bandwidth requests into >> firmware calls but equivalent firmware on imx8m is much thinner. Scaling >> support for individual nodes is implemented as distinct devfreq drivers >> instead. >> >> The imx interconnect provider doesn't communicate with devfreq directly >> but rather computes "minimum frequencies" for nodes along the path and >> creates dev_pm_qos requests. >> >> Since there is no single devicetree node that can represent the >> "interconnect" the main NOC is picked as the "interconnect provider" and >> will probe the interconnect platform device if #interconnect-cells is >> present. This avoids introducing "virtual" devices but it means that DT >> bindings of main NOC includes properties for both devfreq and >> interconnect. > > Thank you for your work Leonard! There is no build dependency between the > devfreq and interconnect patches, so i can apply patches 1,4-7. > > Chanwoo, should i take also the two devfreq patches with your Ack? As you commented, if there are no build dependency, I think it better to be merged to devfreq.git for the history. I'll apply patch2,3 to devfreq git for v5.8-rc1. Thanks.