On Fri, 9 Jun 2023 at 17:52, Konrad Dybcio <konrad.dybcio@xxxxxxxxxx> wrote: > > > > On 9.06.2023 16:45, Robin Murphy wrote: > > On 2023-06-09 13:56, Parikshit Pareek wrote: > >> On Fri, Jun 09, 2023 at 10:52:26AM +0200, Konrad Dybcio wrote: > >>> > >>> > >>> On 9.06.2023 07:41, Parikshit Pareek wrote: > >>>> Some qcom SoCs have SMMUs, which need the interconnect bandwidth to be > >>>> This series introduce the due support for associated interconnect, and > >>>> setting of the due interconnect-bandwidth. Setting due interconnect > >>>> bandwidth is needed to avoid the issues like [1], caused by not having > >>>> due clock votes(indirectly dependent upon interconnect bandwidth). > >>> > >>> [1] ??? > >> > >> My bad. Intended to mention following: > >> https://lore.kernel.org/linux-arm-msm/20230418165224.vmok75fwcjqdxspe@echanude/ > > > > This sounds super-dodgy - do you really have to rely on configuration of the interconnect path from the SMMU's pagetable walker to RAM to keep a completely different interconnect path clocked for the CPU to access SMMU registers? You can't just request the programming interface clock directly like on other SoCs? > On Qualcomm platforms, particularly so with the more recent ones, some > clocks are managed by various remote cores. Half of what the interconnect > infra does on these SoCs is telling one such core to change the internally > managed clock's rate based on the requested bw. But enabling PCIe interconnect to keep SMMU working sounds strange to me too. Does the fault come from some outstanding PCIe transaction? -- With best wishes Dmitry
