Convert Renesas VMSA-Compatible IOMMU bindings documentation
to json-schema.
Note that original documentation doesn't mention renesas,ipmmu-vmsa
for R-Mobile APE6. But, R-Mobile APE6 is similar to the R-Car
Gen2. So, renesas,ipmmu-r8a73a4 belongs the renesas,ipmmu-vmsa
section.
Signed-off-by:
Hi Rob,
Thank you for the review!
> From: Rob Herring, Sent: Tuesday, April 21, 2020 4:27 AM
>
> On Mon, Apr 13, 2020 at 07:25:33PM +0900, Yoshihiro Shimoda wrote:
> > Convert Renesas VMSA-Compatible IOMMU bindings documentation
> > to json-schema.
> >
> > Signed-off-by: Yoshihiro Shimoda
> >
On Mon, Apr 13, 2020 at 04:35:53PM +0300, Hadar Gat wrote:
> Both of_platform.h and of_device.h were included each other.
> In of_device.h, removed unneeded #include to of_platform.h
> and added include to of_platform.h in the files that needs it.
Guess we forgot about that temporary comment!
On Mon, Apr 13, 2020 at 07:25:33PM +0900, Yoshihiro Shimoda wrote:
> Convert Renesas VMSA-Compatible IOMMU bindings documentation
> to json-schema.
>
> Signed-off-by: Yoshihiro Shimoda
> ---
> .../bindings/iommu/renesas,ipmmu-vmsa.txt | 73 --
>
On 2020-04-20 22:27, Robin Murphy wrote:
On 2020-04-20 5:42 pm, Sai Prakash Ranjan wrote:
From: Jordan Crouse
Some client devices want to directly map the IOMMU themselves instead
of using the DMA domain. Allow those devices to opt in to direct
mapping by way of a list of compatible strings.
From: Sibi Sankar
Add iommus property to remoteproc modem node.
Following SMMU global faults are seen without it.
arm-smmu 1500.iommu: Unexpected global fault, this could be serious
arm-smmu 1500.iommu: GFSR 0x8002, GFSYNR0 0x,
GFSYNR1 0x0781,
Implement the new def_domain_type call-back for the ARM
SMMU driver. We need this to support requesting the domain
type by the client devices.
Signed-off-by: Sai Prakash Ranjan
Reviewed-by: Robin Murphy
---
drivers/iommu/arm-smmu.c | 12
drivers/iommu/arm-smmu.h | 1 +
2 files
From: Jordan Crouse
Some client devices want to directly map the IOMMU themselves instead
of using the DMA domain. Allow those devices to opt in to direct
mapping by way of a list of compatible strings.
Signed-off-by: Jordan Crouse
Co-developed-by: Sai Prakash Ranjan
Signed-off-by: Sai
From: Sibi Sankar
Add iommus property to allow Q6 modem to boot on platforms which do
not have trustZone.
Signed-off-by: Sibi Sankar
Signed-off-by: Sai Prakash Ranjan
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt | 3 +++
1 file changed, 3
This series allows DRM, Modem devices to set a default
identity mapping in qcom smmu implementation.
Patch 1 is cleanup to support other SoCs to call into
QCOM specific implementation.
Patch 2 sets the default identity domain for DRM devices.
Patch 3 implements def_domain_type callback for
From: Sibi Sankar
The Q6 modem sub-system has direct access to DDR through memnoc.
Also SMMU is not expected to provide access control/translation
for these SIDs (sandboxing of the modem is achieved through XPUs
engaged using SMC calls). So request direct mapping for modem on
platforms which
Currently the QCOM specific smmu reset implementation is very
specific to SDM845 SoC and has a wait-for-safe logic which
may not be required for other SoCs. So move the SDM845 specific
logic to its specific reset function. Also add SC7180 SMMU
compatible for calling into QCOM specific
On Mon, Apr 20, 2020 at 10:48:50AM -0700, Jacob Pan wrote:
> On Mon, 20 Apr 2020 10:57:27 -0300
> Jason Gunthorpe wrote:
>
> > On Mon, Apr 20, 2020 at 09:42:13AM +0200, Jean-Philippe Brucker wrote:
> > > On Thu, Apr 16, 2020 at 05:13:31AM -0700, Christoph Hellwig wrote:
> > > > On Thu, Apr 16,
Hi Robin,
On 2020-04-20 22:39, Robin Murphy wrote:
On 2020-04-20 5:42 pm, Sai Prakash Ranjan wrote:
From: Sibi Sankar
Request direct mapping for modem on platforms which don't have
TrustZone
(which programs the modem SIDs) to prevent the following global faults
seen
on Cheza/Trogdor:
Am 2020-04-20 um 1:44 p.m. schrieb Jacob Pan:
>> The bottom line is, when you allocate a PASID for a context, you want
>> to know how small it needs to be for all the devices that want to use
>> it. If you make it too big, some device will not be able to use it.
>> If you make it too small, you
On Mon, 20 Apr 2020 10:57:27 -0300
Jason Gunthorpe wrote:
> On Mon, Apr 20, 2020 at 09:42:13AM +0200, Jean-Philippe Brucker wrote:
> > On Thu, Apr 16, 2020 at 05:13:31AM -0700, Christoph Hellwig wrote:
> > > On Thu, Apr 16, 2020 at 10:54:02AM +0200, Jean-Philippe Brucker
> > > wrote:
> > > >
On Mon, 20 Apr 2020 11:00:28 -0400
Felix Kuehling wrote:
> Am 2020-04-20 um 8:40 a.m. schrieb Christian König:
> > Am 20.04.20 um 13:55 schrieb Christoph Hellwig:
> >> On Mon, Apr 20, 2020 at 01:44:56PM +0200, Christian König wrote:
> >>> Am 20.04.20 um 10:10 schrieb Christoph Hellwig:
>
On 2020-04-20 5:42 pm, Sai Prakash Ranjan wrote:
From: Sibi Sankar
Request direct mapping for modem on platforms which don't have TrustZone
(which programs the modem SIDs) to prevent the following global faults seen
on Cheza/Trogdor:
Not strictly true - it's patch #6/6 that prevents *those*
On 2020-04-20 5:42 pm, Sai Prakash Ranjan wrote:
Implement the new def_domain_type call-back for the ARM
SMMU driver. We need this to support requesting the domain
type by the client devices.
Modulo any further changes to the default domain rework,
Reviewed-by: Robin Murphy
Signed-off-by:
On 2020-04-20 5:42 pm, Sai Prakash Ranjan wrote:
From: Jordan Crouse
Some client devices want to directly map the IOMMU themselves instead
of using the DMA domain. Allow those devices to opt in to direct
mapping by way of a list of compatible strings.
Neat and tidy :)
Reviewed-by: Robin
This series allows DRM, Modem devices to set a default
identity mapping in qcom smmu implementation.
Patch 1 is cleanup to support other SoCs to call into
QCOM specific implementation.
Patch 2 sets the default identity domain for DRM devices.
Patch 3 implements def_domain_type callback for
From: Sibi Sankar
Add iommus property to allow Q6 modem to boot on platforms which do
not have trustZone.
Signed-off-by: Sibi Sankar
Signed-off-by: Sai Prakash Ranjan
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt | 3 +++
1 file changed, 3
From: Sibi Sankar
Add iommus property to remoteproc modem node.
Signed-off-by: Sibi Sankar
Signed-off-by: Sai Prakash Ranjan
---
arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
Currently the QCOM specific smmu reset implementation is very
specific to SDM845 SoC and has a wait-for-safe logic which
may not be required for other SoCs. So move the SDM845 specific
logic to its specific reset function. Also add SC7180 SMMU
compatible for calling into QCOM specific
Implement the new def_domain_type call-back for the ARM
SMMU driver. We need this to support requesting the domain
type by the client devices.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm-smmu.c | 12
1 file changed, 12 insertions(+)
diff --git
From: Sibi Sankar
Request direct mapping for modem on platforms which don't have TrustZone
(which programs the modem SIDs) to prevent the following global faults seen
on Cheza/Trogdor:
arm-smmu 1500.iommu: Unexpected global fault, this could be serious
arm-smmu 1500.iommu: GFSR
From: Jordan Crouse
Some client devices want to directly map the IOMMU themselves instead
of using the DMA domain. Allow those devices to opt in to direct
mapping by way of a list of compatible strings.
Signed-off-by: Jordan Crouse
Co-developed-by: Sai Prakash Ranjan
Signed-off-by: Sai
On 2020-04-20 21:27, Robin Murphy wrote:
On 2020-04-20 3:37 pm, Sai Prakash Ranjan wrote:
From: Jordan Crouse
Some client devices want to directly map the IOMMU themselves instead
of using the DMA domain. Allow those devices to opt in to direct
mapping by way of a list of compatible strings.
Hi Robin,
On 2020-04-20 20:56, Robin Murphy wrote:
On 2020-04-20 3:37 pm, Sai Prakash Ranjan wrote:
Implement the new def_domain_type call-back for the ARM
SMMU driver. We need this to support requesting the domain
type by the client devices.
Signed-off-by: Sai Prakash Ranjan
---
On 2020-04-20 3:39 pm, Maxime Ripard wrote:
Hi,
On Wed, Apr 08, 2020 at 04:06:49PM +0200, Joerg Roedel wrote:
On Wed, Apr 01, 2020 at 01:47:10PM +0200, Maxime Ripard wrote:
As far as I understand it, the page table can be accessed concurrently
since the framework doesn't seem to provide any
Am 20.04.20 um 13:55 schrieb Christoph Hellwig:
On Mon, Apr 20, 2020 at 01:44:56PM +0200, Christian König wrote:
Am 20.04.20 um 10:10 schrieb Christoph Hellwig:
On Mon, Apr 20, 2020 at 09:42:13AM +0200, Jean-Philippe Brucker wrote:
Right, I can see the appeal. I still like having a single mmu
On 2020-04-20 3:37 pm, Sai Prakash Ranjan wrote:
From: Jordan Crouse
Some client devices want to directly map the IOMMU themselves instead
of using the DMA domain. Allow those devices to opt in to direct
mapping by way of a list of compatible strings.
Signed-off-by: Jordan Crouse
Hi All,
I have an IOMMU master which has limitations as mentioned below:
1) The IOMMU master internally executes a firmware, and the firmware memory
is allocated by the same master driver.
The firmware buffer address should be of the lowest range than other address
allocated by the device, or in
Am 2020-04-20 um 8:40 a.m. schrieb Christian König:
> Am 20.04.20 um 13:55 schrieb Christoph Hellwig:
>> On Mon, Apr 20, 2020 at 01:44:56PM +0200, Christian König wrote:
>>> Am 20.04.20 um 10:10 schrieb Christoph Hellwig:
On Mon, Apr 20, 2020 at 09:42:13AM +0200, Jean-Philippe Brucker wrote:
On 2020-04-20 3:37 pm, Sai Prakash Ranjan wrote:
Implement the new def_domain_type call-back for the ARM
SMMU driver. We need this to support requesting the domain
type by the client devices.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm-smmu.c | 20
1 file
Both of_platform.h and of_device.h were included each other.
In of_device.h, removed unneeded #include to of_platform.h
and added include to of_platform.h in the files that needs it.
Signed-off-by: Hadar Gat
Reported-by: kbuild test robot
Acked-by: Jonathan Cameron #for-iio
Acked-by: Stephen
Hi,
On Wed, Apr 08, 2020 at 04:06:49PM +0200, Joerg Roedel wrote:
> On Wed, Apr 01, 2020 at 01:47:10PM +0200, Maxime Ripard wrote:
> > As far as I understand it, the page table can be accessed concurrently
> > since the framework doesn't seem to provide any serialization /
> > locking, shouldn't
From: Sibi Sankar
Request direct mapping for modem on platforms which don't have TrustZone
(which programs the modem SIDs) to prevent the following global faults seen
on Cheza/Trogdor:
arm-smmu 1500.iommu: Unexpected global fault, this could be serious
arm-smmu 1500.iommu: GFSR
From: Sibi Sankar
Add iommus property to allow Q6 modem to boot on platforms which do
not have trustZone.
Signed-off-by: Sibi Sankar
Signed-off-by: Sai Prakash Ranjan
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt | 3 +++
1 file changed, 3
From: Sibi Sankar
Add iommus property to remoteproc modem node.
Signed-off-by: Sibi Sankar
Signed-off-by: Sai Prakash Ranjan
---
arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
From: Jordan Crouse
Some client devices want to directly map the IOMMU themselves instead
of using the DMA domain. Allow those devices to opt in to direct
mapping by way of a list of compatible strings.
Signed-off-by: Jordan Crouse
Co-developed-by: Sai Prakash Ranjan
Signed-off-by: Sai
Implement the new def_domain_type call-back for the ARM
SMMU driver. We need this to support requesting the domain
type by the client devices.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm-smmu.c | 20
1 file changed, 20 insertions(+)
diff --git
Currently the QCOM specific smmu reset implementation is very
specific to SDM845 SoC and has a wait-for-safe logic which
may not be required for other SoCs. So move the SDM845 specific
logic to its specific reset function. Also add SC7180 SMMU
compatible for calling into QCOM specific
This series allows DRM, Modem devices to set a default
identity mapping in qcom smmu implementation.
Patch 1 is cleanup to support other SoCs to call into
QCOM specific implementation.
Patch 2 sets the default identity domain for DRM devices.
Patch 3 implements def_domain_type callback for
On Mon, Apr 20, 2020 at 09:42:13AM +0200, Jean-Philippe Brucker wrote:
> On Thu, Apr 16, 2020 at 05:13:31AM -0700, Christoph Hellwig wrote:
> > On Thu, Apr 16, 2020 at 10:54:02AM +0200, Jean-Philippe Brucker wrote:
> > > On Thu, Apr 16, 2020 at 12:28:52AM -0700, Christoph Hellwig wrote:
> > > > >
> On Apr 18, 2020, at 2:34 PM, Joerg Roedel wrote:
>
> On Sat, Apr 18, 2020 at 09:01:35AM -0400, Qian Cai wrote:
>> Hard to tell without testing further. I’ll leave that optimization in
>> the future, and focus on fixing those races first.
>
> Yeah right, we should fix the existing races
Am 20.04.20 um 10:10 schrieb Christoph Hellwig:
On Mon, Apr 20, 2020 at 09:42:13AM +0200, Jean-Philippe Brucker wrote:
Right, I can see the appeal. I still like having a single mmu notifier per
mm because it ensures we allocate a single PASID per mm (as required by
x86). I suppose one
On Mon, Apr 20, 2020 at 01:44:56PM +0200, Christian König wrote:
> Am 20.04.20 um 10:10 schrieb Christoph Hellwig:
> > On Mon, Apr 20, 2020 at 09:42:13AM +0200, Jean-Philippe Brucker wrote:
> > > Right, I can see the appeal. I still like having a single mmu notifier per
> > > mm because it ensures
Hi Christoph,
On Tue, Apr 14, 2020 at 3:21 PM Christoph Hellwig wrote:
> Just use __vmalloc_node instead which gets and extra argument. To be
> able to to use __vmalloc_node in all caller make it available outside
> of vmalloc and implement it in nommu.c.
>
> Signed-off-by: Christoph Hellwig
>
Hi Christoph,
On Tue, Apr 14, 2020 at 3:22 PM Christoph Hellwig wrote:
> Open code it in __bpf_map_area_alloc, which is the only caller. Also
> clean up __bpf_map_area_alloc to have a single vmalloc call with
> slightly different flags instead of the current two different calls.
>
> For this to
On Mon, Apr 20, 2020 at 09:42:13AM +0200, Jean-Philippe Brucker wrote:
> Right, I can see the appeal. I still like having a single mmu notifier per
> mm because it ensures we allocate a single PASID per mm (as required by
> x86). I suppose one alternative is to maintain a hashtable of mm->pasid,
>
On Thu, Apr 16, 2020 at 01:58:29PM -0700, Jacob Pan wrote:
> On Wed, 15 Apr 2020 09:47:36 +0200
> Jean-Philippe Brucker wrote:
>
> > On Fri, Apr 10, 2020 at 08:52:49AM -0700, Jacob Pan wrote:
> > > On Thu, 9 Apr 2020 16:50:58 +0200
> > > Jean-Philippe Brucker wrote:
> > >
> > > > > So unbind
On Thu, Apr 16, 2020 at 05:13:31AM -0700, Christoph Hellwig wrote:
> On Thu, Apr 16, 2020 at 10:54:02AM +0200, Jean-Philippe Brucker wrote:
> > On Thu, Apr 16, 2020 at 12:28:52AM -0700, Christoph Hellwig wrote:
> > > > + rcu_read_lock();
> > > > + hlist_for_each_entry_rcu(bond,
Hi Hadar,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on stm32/stm32-next]
[also build test ERROR on sunxi/sunxi/for-next linus/master v5.7-rc1
next-20200416]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we
Hi Hadar,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on stm32/stm32-next]
[also build test ERROR on sunxi/sunxi/for-next linus/master v5.7-rc1
next-20200416]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we
55 matches
Mail list logo
