Re: [RFC PATCH] drm/msm: lookup the ICC paths in both mdp5/dpu and mdss devices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux