From: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> To: Will Deacon <will@kernel.org> Cc: Rob Clark <robdclark@gmail.com>, "Isaac J. Manjarres" <isaacm@codeaurora.org>, freedreno <freedreno@lists.freedesktop.org>, Jordan Crouse <jcrouse@codeaurora.org>, David Airlie <airlied@linux.ie>, linux-arm-msm <linux-arm-msm@vger.kernel.org>, Akhil P Oommen <akhilpo@codeaurora.org>, dri-devel <dri-devel@lists.freedesktop.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, "list@263.net:IOMMU DRIVERS , Joerg Roedel <joro@8bytes.org>," <iommu@lists.linux-foundation.org>, Kristian H Kristensen <hoegsberg@google.com>, Daniel Vetter <daniel@ffwll.ch>, Sean Paul <sean@poorly.run>, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" <linux-arm-kernel@lists.infradead.org>, Robin Murphy <robin.murphy@arm.com> Subject: Re: [Freedreno] [PATCH 0/3] iommu/drm/msm: Allow non-coherent masters to use system cache Date: Tue, 10 Aug 2021 15:24:41 +0530 [thread overview] Message-ID: <5b6953c5afdf566c248a2da59f91d9de@codeaurora.org> (raw) In-Reply-To: <20210810091619.GA2494@willie-the-truck> On 2021-08-10 14:46, Will Deacon wrote: > On Mon, Aug 09, 2021 at 11:17:40PM +0530, Sai Prakash Ranjan wrote: >> On 2021-08-09 23:10, Will Deacon wrote: >> > On Mon, Aug 09, 2021 at 10:18:21AM -0700, Rob Clark wrote: >> > > On Mon, Aug 9, 2021 at 10:05 AM Will Deacon <will@kernel.org> wrote: >> > > > On Mon, Aug 09, 2021 at 09:57:08AM -0700, Rob Clark wrote: >> > > > > But I suppose we could call it instead IOMMU_QCOM_LLC or something >> > > > > like that to make it more clear that it is not necessarily something >> > > > > that would work with a different outer level cache implementation? >> > > > >> > > > ... or we could just deal with the problem so that other people can reuse >> > > > the code. I haven't really understood the reluctance to solve this properly. >> > > > >> > > > Am I missing some reason this isn't solvable? >> > > >> > > Oh, was there another way to solve it (other than foregoing setting >> > > INC_OCACHE in the pgtables)? Maybe I misunderstood, is there a >> > > corresponding setting on the MMU pgtables side of things? >> > >> > Right -- we just need to program the CPU's MMU with the matching memory >> > attributes! It's a bit more fiddly if you're just using ioremap_wc() >> > though, as it's usually the DMA API which handles the attributes under >> > the >> > hood. >> > >> > Anyway, sorry, I should've said that explicitly earlier on. We've done >> > this >> > sort of thing in the Android tree so I assumed Sai knew what needed to >> > be >> > done and then I didn't think to explain to you :( >> > >> >> Right I was aware of that but even in the android tree there is no >> user :) > > I'm assuming there are vendor modules using it there, otherwise we > wouldn't > have been asked to put it in. Since you work at Qualcomm, maybe you > could > talk to your colleagues (Isaac and Patrick) directly? > Right I will check with them regarding the vendor modules in android. >> I think we can't have a new memory type without any user right in >> upstream >> like android tree? > > Correct. But I don't think we should be adding IOMMU_* anything > upstream > if we don't have a user. > Agreed, once we have the fix for GPU crash I can continue further on using this properly. Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
WARNING: multiple messages have this Message-ID (diff)
From: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> To: Will Deacon <will@kernel.org> Cc: "Isaac J. Manjarres" <isaacm@codeaurora.org>, David Airlie <airlied@linux.ie>, linux-arm-msm <linux-arm-msm@vger.kernel.org>, Jordan Crouse <jcrouse@codeaurora.org>, dri-devel <dri-devel@lists.freedesktop.org>, Akhil P Oommen <akhilpo@codeaurora.org>, Sean Paul <sean@poorly.run>, "list@263.net:IOMMU DRIVERS , Joerg Roedel <joro@8bytes.org>, " <iommu@lists.linux-foundation.org>, Kristian H Kristensen <hoegsberg@google.com>, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" <linux-arm-kernel@lists.infradead.org>, Daniel Vetter <daniel@ffwll.ch>, freedreno <freedreno@lists.freedesktop.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Robin Murphy <robin.murphy@arm.com> Subject: Re: [Freedreno] [PATCH 0/3] iommu/drm/msm: Allow non-coherent masters to use system cache Date: Tue, 10 Aug 2021 15:24:41 +0530 [thread overview] Message-ID: <5b6953c5afdf566c248a2da59f91d9de@codeaurora.org> (raw) In-Reply-To: <20210810091619.GA2494@willie-the-truck> On 2021-08-10 14:46, Will Deacon wrote: > On Mon, Aug 09, 2021 at 11:17:40PM +0530, Sai Prakash Ranjan wrote: >> On 2021-08-09 23:10, Will Deacon wrote: >> > On Mon, Aug 09, 2021 at 10:18:21AM -0700, Rob Clark wrote: >> > > On Mon, Aug 9, 2021 at 10:05 AM Will Deacon <will@kernel.org> wrote: >> > > > On Mon, Aug 09, 2021 at 09:57:08AM -0700, Rob Clark wrote: >> > > > > But I suppose we could call it instead IOMMU_QCOM_LLC or something >> > > > > like that to make it more clear that it is not necessarily something >> > > > > that would work with a different outer level cache implementation? >> > > > >> > > > ... or we could just deal with the problem so that other people can reuse >> > > > the code. I haven't really understood the reluctance to solve this properly. >> > > > >> > > > Am I missing some reason this isn't solvable? >> > > >> > > Oh, was there another way to solve it (other than foregoing setting >> > > INC_OCACHE in the pgtables)? Maybe I misunderstood, is there a >> > > corresponding setting on the MMU pgtables side of things? >> > >> > Right -- we just need to program the CPU's MMU with the matching memory >> > attributes! It's a bit more fiddly if you're just using ioremap_wc() >> > though, as it's usually the DMA API which handles the attributes under >> > the >> > hood. >> > >> > Anyway, sorry, I should've said that explicitly earlier on. We've done >> > this >> > sort of thing in the Android tree so I assumed Sai knew what needed to >> > be >> > done and then I didn't think to explain to you :( >> > >> >> Right I was aware of that but even in the android tree there is no >> user :) > > I'm assuming there are vendor modules using it there, otherwise we > wouldn't > have been asked to put it in. Since you work at Qualcomm, maybe you > could > talk to your colleagues (Isaac and Patrick) directly? > Right I will check with them regarding the vendor modules in android. >> I think we can't have a new memory type without any user right in >> upstream >> like android tree? > > Correct. But I don't think we should be adding IOMMU_* anything > upstream > if we don't have a user. > Agreed, once we have the fix for GPU crash I can continue further on using this properly. Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2021-08-10 9:55 UTC|newest] Thread overview: 136+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-11 14:15 [PATCH 0/3] iommu/drm/msm: Allow non-coherent masters to use system cache Sai Prakash Ranjan 2021-01-11 14:15 ` Sai Prakash Ranjan 2021-01-11 14:15 ` Sai Prakash Ranjan 2021-01-11 14:15 ` [PATCH 1/3] iommu/io-pgtable: Rename last-level cache quirk to IO_PGTABLE_QUIRK_PTW_LLC Sai Prakash Ranjan 2021-01-11 14:15 ` Sai Prakash Ranjan 2021-01-11 14:15 ` Sai Prakash Ranjan 2021-01-11 14:15 ` [PATCH 2/3] iommu/io-pgtable-arm: Add IOMMU_LLC page protection flag Sai Prakash Ranjan 2021-01-11 14:15 ` Sai Prakash Ranjan 2021-01-11 14:15 ` Sai Prakash Ranjan 2021-01-29 9:05 ` Will Deacon 2021-01-29 9:05 ` Will Deacon 2021-01-29 9:05 ` Will Deacon 2021-01-29 9:42 ` Sai Prakash Ranjan 2021-01-29 9:42 ` Sai Prakash Ranjan 2021-02-01 11:15 ` Will Deacon 2021-02-01 11:15 ` Will Deacon 2021-02-01 11:15 ` Will Deacon 2021-02-01 11:15 ` Will Deacon 2021-02-01 16:20 ` Rob Clark 2021-02-01 16:20 ` Rob Clark 2021-02-01 16:20 ` Rob Clark 2021-02-01 16:20 ` Rob Clark 2021-02-01 18:20 ` Jordan Crouse 2021-02-01 18:20 ` Jordan Crouse 2021-02-01 18:20 ` Jordan Crouse 2021-02-02 6:26 ` Sai Prakash Ranjan 2021-02-02 6:26 ` Sai Prakash Ranjan 2021-02-02 6:26 ` Sai Prakash Ranjan 2021-02-03 21:46 ` Will Deacon 2021-02-03 21:46 ` Will Deacon 2021-02-03 21:46 ` Will Deacon 2021-02-03 21:46 ` Will Deacon 2021-02-03 22:14 ` Rob Clark 2021-02-03 22:14 ` Rob Clark 2021-02-03 22:14 ` Rob Clark 2021-02-03 22:14 ` Rob Clark 2021-03-16 17:04 ` Rob Clark 2021-03-16 17:04 ` Rob Clark 2021-03-16 17:04 ` Rob Clark 2021-03-16 17:04 ` Rob Clark 2021-03-16 17:16 ` Rob Clark 2021-03-16 17:16 ` Rob Clark 2021-03-16 17:16 ` Rob Clark 2021-03-16 17:16 ` Rob Clark 2021-03-17 9:33 ` Sai Prakash Ranjan 2021-03-25 18:36 ` Rob Clark 2021-02-05 12:08 ` Sai Prakash Ranjan 2021-02-05 12:08 ` Sai Prakash Ranjan 2021-02-05 12:08 ` Sai Prakash Ranjan 2021-03-09 6:40 ` Sai Prakash Ranjan 2021-03-09 6:40 ` Sai Prakash Ranjan 2021-03-09 6:40 ` Sai Prakash Ranjan 2021-03-25 17:33 ` Will Deacon 2021-03-25 17:33 ` Will Deacon 2021-03-25 17:33 ` Will Deacon 2021-03-25 17:33 ` Will Deacon 2021-06-30 10:07 ` Sai Prakash Ranjan 2021-06-30 10:07 ` Sai Prakash Ranjan 2021-06-30 10:07 ` Sai Prakash Ranjan 2021-02-02 6:28 ` Sai Prakash Ranjan 2021-02-02 6:28 ` Sai Prakash Ranjan 2021-02-02 6:28 ` Sai Prakash Ranjan 2021-01-11 14:15 ` [PATCH 3/3] drm/msm: Use IOMMU_LLC page protection flag to map gpu buffers Sai Prakash Ranjan 2021-01-11 14:15 ` Sai Prakash Ranjan 2021-01-11 14:15 ` Sai Prakash Ranjan 2021-01-20 5:18 ` [PATCH 0/3] iommu/drm/msm: Allow non-coherent masters to use system cache Sai Prakash Ranjan 2021-01-20 5:18 ` Sai Prakash Ranjan 2021-01-20 5:18 ` Sai Prakash Ranjan 2021-01-29 8:53 ` Sai Prakash Ranjan 2021-01-29 8:53 ` Sai Prakash Ranjan 2021-07-28 14:00 ` Georgi Djakov 2021-07-28 14:00 ` Georgi Djakov 2021-07-28 14:00 ` Georgi Djakov 2021-07-28 14:00 ` Georgi Djakov 2021-07-29 4:38 ` Sai Prakash Ranjan 2021-07-29 4:38 ` Sai Prakash Ranjan 2021-07-29 4:38 ` Sai Prakash Ranjan 2021-08-02 10:55 ` Will Deacon 2021-08-02 10:55 ` Will Deacon 2021-08-02 10:55 ` Will Deacon 2021-08-02 15:08 ` [Freedreno] " Rob Clark 2021-08-02 15:08 ` Rob Clark 2021-08-02 15:08 ` Rob Clark 2021-08-02 15:08 ` Rob Clark 2021-08-02 15:14 ` Will Deacon 2021-08-02 15:14 ` Will Deacon 2021-08-02 15:14 ` Will Deacon 2021-08-02 15:14 ` Will Deacon 2021-08-03 1:36 ` Rob Clark 2021-08-03 1:36 ` Rob Clark 2021-08-03 1:36 ` Rob Clark 2021-08-03 1:36 ` Rob Clark 2021-08-09 14:56 ` Will Deacon 2021-08-09 14:56 ` Will Deacon 2021-08-09 14:56 ` Will Deacon 2021-08-09 14:56 ` Will Deacon 2021-08-09 16:57 ` Rob Clark 2021-08-09 16:57 ` Rob Clark 2021-08-09 16:57 ` Rob Clark 2021-08-09 16:57 ` Rob Clark 2021-08-09 17:05 ` Will Deacon 2021-08-09 17:05 ` Will Deacon 2021-08-09 17:05 ` Will Deacon 2021-08-09 17:05 ` Will Deacon 2021-08-09 17:18 ` Rob Clark 2021-08-09 17:18 ` Rob Clark 2021-08-09 17:18 ` Rob Clark 2021-08-09 17:18 ` Rob Clark 2021-08-09 17:40 ` Will Deacon 2021-08-09 17:40 ` Will Deacon 2021-08-09 17:40 ` Will Deacon 2021-08-09 17:40 ` Will Deacon 2021-08-09 17:47 ` Sai Prakash Ranjan 2021-08-09 17:47 ` Sai Prakash Ranjan 2021-08-09 17:47 ` Sai Prakash Ranjan 2021-08-09 18:07 ` Rob Clark 2021-08-09 18:07 ` Rob Clark 2021-08-09 18:07 ` Rob Clark 2021-08-09 18:07 ` Rob Clark 2021-08-09 18:10 ` Sai Prakash Ranjan 2021-08-09 18:10 ` Sai Prakash Ranjan 2021-08-09 18:10 ` Sai Prakash Ranjan 2021-08-09 18:30 ` Rob Clark 2021-08-09 18:30 ` Rob Clark 2021-08-09 18:30 ` Rob Clark 2021-08-09 18:30 ` Rob Clark 2021-08-09 18:32 ` Sai Prakash Ranjan 2021-08-09 18:32 ` Sai Prakash Ranjan 2021-08-09 18:32 ` Sai Prakash Ranjan 2021-08-10 9:16 ` Will Deacon 2021-08-10 9:16 ` Will Deacon 2021-08-10 9:16 ` Will Deacon 2021-08-10 9:16 ` Will Deacon 2021-08-10 9:54 ` Sai Prakash Ranjan [this message] 2021-08-10 9:54 ` Sai Prakash Ranjan 2021-08-10 9:54 ` Sai Prakash Ranjan
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=5b6953c5afdf566c248a2da59f91d9de@codeaurora.org \ --to=saiprakash.ranjan@codeaurora.org \ --cc=airlied@linux.ie \ --cc=akhilpo@codeaurora.org \ --cc=daniel@ffwll.ch \ --cc=dri-devel@lists.freedesktop.org \ --cc=freedreno@lists.freedesktop.org \ --cc=hoegsberg@google.com \ --cc=iommu@lists.linux-foundation.org \ --cc=isaacm@codeaurora.org \ --cc=jcrouse@codeaurora.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=robdclark@gmail.com \ --cc=robin.murphy@arm.com \ --cc=sean@poorly.run \ --cc=will@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.