On 24/08/2022 00:31, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-08-05 04:56:30)diff --git a/drivers/gpu/drm/msm/msm_io_utils.c b/drivers/gpu/drm/msm/msm_io_utils.c index 7b504617833a..d02cd29ce829 100644 --- a/drivers/gpu/drm/msm/msm_io_utils.c +++ b/drivers/gpu/drm/msm/msm_io_utils.c @@ -124,3 +126,23 @@ void msm_hrtimer_work_init(struct msm_hrtimer_work *work, work->worker = worker; kthread_init_work(&work->work, fn); } + +struct icc_path *msm_icc_get(struct device *dev, const char *name) +{ + struct device *mdss_dev = dev->parent; + struct icc_path *path; + + path = of_icc_get(dev, name); + if (path) + return path; + + /* + * If there are no interconnects attached to the corresponding device + * node, of_icc_get() will return NULL. + * + * If the MDP5/DPU device node doesn't have interconnects, lookup the + * path in the parent (MDSS) device. + */ + return of_icc_get(mdss_dev, name);Perhaps this would be better served by having another icc_get() API that looks in the device and also the parent? Or maybe there should be interconnect-ranges (similar to clock-ranges) so that interconnects can be mapped to child nodes in DT.
I was not sure how common this situation is, so I did not add the helper/API. Typically the driver knows exactly, which node has the interconnects. In our case this is complicated because we are effectively merging two different driver generations and two different bindings. Thus I suppose this situation is quite unique.
-- With best wishes Dmitry
