Re: [PATCH RFC 03/13] drm/msm: look for lpac from dts
From: Anna Maniscalco
Date: Fri Oct 23 2026 - 11:32:05 EST
On 10/22/26 11:46 PM, Akhil P Oommen wrote:
In other words that would mean not upstreaming the DTS change? Although we plan
On 10/22/2026 6:24 PM, Anna Maniscalco wrote:
On 7/9/26 9:39 PM, Dmitry Baryshkov wrote:+ Bjorn/Konrad
On Thu, Jul 09, 2026 at 05:54:23PM +0300, Dmitry Baryshkov wrote:One thing sashiko is pointing out is that new dt should work with hold kernel so, in general moving sid1 from there would break it since old kernels don't know how to handle them separately.
On Thu, Jul 09, 2026 at 07:12:39PM +0530, Akhil P Oommen wrote:After a brief discussion: it can be either, depending on what suites
On 7/7/2026 10:09 PM, Dmitry Baryshkov wrote:Let me check internally.
On Tue, Jul 07, 2026 at 05:02:43PM +0200, Anna Maniscalco wrote:iiuc, the conclusion in this recent thread is to use child nodes for a
On 7/6/26 5:04 PM, Dmitry Baryshkov wrote:I think, you were poined to the Glymur Iris patches. Another option is
On Sun, Jul 05, 2026 at 09:13:37PM +0200, Anna Maniscalco wrote:What I was trying to say is that we need to map sid0 and sid1 to different
In order to associate the SID used by LPAC to it's own domain andCan we use iommu-map instead of adding a new device using the same
context bank we need a separate node on the DTS.
addresses? You provide zero explanations, but it seems like you are
trying to separate a part of the GPU into a separate device, but it's
unnecessary.
context banks.
From what I recall, so long as we use the same dt node, the iommu drivert
provides no way of doing this.
What kgsl does is having a node for the iommu and then subnodes for gfx lpac
and secure.
The address on the lpac device doesn't really matter. I have very limted
knowledge of DTSs but I think we could just leave it out altogether?
the QDA driver being submitted too. Both ot them use iommu-map to
describe the same usecase - a set of SIDs which are used by the device
but which should not be a part of the defaut set. With it in place you
don't need to have separate qcom,lpac devices, no additional properties,
etc.
I'd recommend following the same approach.
similar case:
https://lore.kernel.org/all/20260618151745.GD231643@xxxxxxxx/
better (and if you can persuade DMA / IOMMU maintainers to let one extra
bus or not).
Not sure how strict is the requirement for compatibility with older kernel version. An
option in your case could be just do an override in the board dts file of the
Steam Frame.'
on keeping LPAC off by default upstream it feels like that would be quite a big
barrier to enabling it for people that want it.
Also yeah not sure where sashiko got that requirement, maybe it's not a real problem?
-Akhil.
Not sure how to address this.
Best regards,
Best regards,
--
Anna Maniscalco <anna.maniscalco2000@xxxxxxxxx>