Re: [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()

>> diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c >> b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c >> index 5ac373c..480b644 100644 >> --- a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c >> +++ b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c >> @@ -540,7 +540,7 @@ int fsl_mc_device_add(struct dprc_obj_desc

Re: [PATCH 2/2] arm64: avoid increasing DMA masks above what hardware supports

>> @@ -959,6 +990,15 @@ void arch_setup_dma_ops(struct device *dev, u64 >> dma_base, u64 size, >> if (!dev->archdata.dma_ops) >> dev->archdata.dma_ops = _dma_ops; >> >> + /* >> +* Whatever the parent bus can set. A device must not set >> +* a DMA

Re: [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()

12.01.2017 08:52, Nikita Yushchenko wrote: >>> diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c >>> b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c >>> index 5ac373c..480b644 100644 >>> --- a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c >>> +++ b/drivers/

Isn't gen3 peripheral bus 32-bit?

Hi R-Car GEN3 PCIe modules have 32-bit connect to internal AXI bus. Could please somebody with lowlevel hardware knowledge answer, if this is PCIe module limitation, or internal bus limitation. Depending on that, different modification of renesas/r8a779[56].dtsi files is needed: either - wrap

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

[CCing NVMe maintainers since we are discussion issues in that driver] >> With my patch applied and thus 32bit dma_mask set for NVMe device, I do >> see high addresses passed to dma_map_*() routines and handled by >> swiotlb. Thus your statement that behavior "succeed 64bit dma_set_mask() >>

Re: [PATCH] arm64: avoid increasing DMA masks above what hardware supports

> Yes, I think that ought to work, although the __iommu_setup_dma_ops() > call will still want a real size reflecting the default mask I see iommu_dma_ops do not define set_dma_mask. So what if setup was done for size reflecting one mask and then driver changes mask? Will things still operate

[PATCH 2/2] arm64: avoid increasing DMA masks above what hardware supports

capabilities. To avoid breakage, actual mask must not be set wider than device connection allows. Signed-off-by: Nikita Yushchenko <nikita.yo...@cogentembedded.com> CC: Arnd Bergmann <a...@arndb.de> CC: Robin Murphy <robin.mur...@arm.com> CC: Will Deacon <will.dea...@arm.com>

[PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()

boolean argument to arch_setup_dma_ops() to show if range originates from authorative source and thus should be enforced, or is just a guess and should be handled as such. Signed-off-by: Nikita Yushchenko <nikita.yo...@cogentembedded.com> --- arch/arm/include/asm/dma-mapping.h

[PATCH 0/2] arm64: fix handling of DMA masks wider than bus supports

> I reckon the easiest way forward would be to pass in some flag to > arch_setup_dma_ops to indicate whether it's an explicitly-configured > range or not - then simply initialising parent_dma_mask to ~0 for the > default case *should* keep things working as before. Tried to do that.

Re: [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()

Hmm, I think when the dma-ranges are missing, we should either enforce a 32-bit mask, or disallow DMA completely. It's probably too late for the latter, I wish we had done this earlier in order to force everyone on ARM64 to have a valid dma-ranges property for any DMA master.

NVMe vs DMA addressing limitations

>> I believe the bounce buffering code you refer to is not in SATA/SCSI/MMC >> but in block layer, in particular it should be controlled by >> blk_queue_bounce_limit(). [Yes there is CONFIG_MMC_BLOCK_BOUNCE but it >> is something completely different, namely it is for request merging for >> hw

Re: NVMe vs DMA addressing limitations

. Nikita > On Tue, Jan 10, 2017 at 09:47:21AM +0300, Nikita Yushchenko wrote: >> I'm now working with HW that: >> - is now way "low end" or "obsolete", it has 4G of RAM and 8 CPU cores, >> and is being manufactured and developed, >> - has 75% of it

Re: [PATCH] arm64: avoid increasing DMA masks above what hardware supports

>> +/* >> + * we don't yet support buses that have a non-zero mapping. >> + * Let's hope we won't need it >> + */ >> +WARN_ON(dma_base != 0); > > I believe we now accomodate the bus remap bits on BCM2837 as a DMA > offset, so unfortunately I think this is no longer true.

Re: [PATCH v2] arm64: do not set dma masks that device connection can't handle

> I actually have a third variation of this problem involving a PCI root > complex which *could* drive full-width (40-bit) addresses, but won't, > due to the way its PCI<->AXI interface is programmed. That would require > even more complicated dma-ranges handling to describe the windows of > valid

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

>> For OF platforms, this is called via of_dma_configure(), that checks >> dma-ranges of node that is *parent* for host bridge. Host bridge >> currently does not control this at all. > > We need to think about this a bit. Is it actually the PCI host > bridge that limits the ranges here, or the

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

For OF platforms, this is called via of_dma_configure(), that checks dma-ranges of node that is *parent* for host bridge. Host bridge currently does not control this at all. >>> >>> We need to think about this a bit. Is it actually the PCI host >>> bridge that limits the ranges

[PATCH 2/2] rcar-pcie: set host bridge's DMA mask

This gives platform DMA mapping code a chance to disallow setting device DMA mask to something that host bridge can't support. Signed-off-by: Nikita Yushchenko <nikita.yo...@cogentembedded.com> --- drivers/pci/host/pcie-rcar.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drive

[PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

in actually affected components - driver of particular PCI host bridge, and dma_map_ops of particular platform. Signed-off-by: Nikita Yushchenko <nikita.yo...@cogentembedded.com> --- arch/arm64/mm/dma-mapping.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm64/mm/dma-map

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

> commit 9a57d58d116800a535510053136c6dd7a9c26e25 > Author: Arnd Bergmann > Date: Tue Nov 17 14:06:55 2015 +0100 > > [EXPERIMENTAL] ARM64: check implement dma_set_mask > > Needs work for coherent mask > > Signed-off-by: Arnd Bergmann

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

the least destructive approach: currently dma_mask of that device >> object is not used anyhow, thus all existing setups will work as before, >> and modification is required only in actually affected components - >> driver of particular PCI host bridge, and dma_map_ops of particular &g

Re: [PATCH] arm64: do not set dma masks that device connection can't handle

>> +if (mask > dev->archdata.parent_dma_mask) >> +mask = dev->archdata.parent_dma_mask; >> + >> + > >One empty line is enough... Ok >> +/* >> + * Whatever the parent bus can set. A device must not set >> + * a DMA mask larger than this. >> + */ >> +

[PATCH v2] arm64: do not set dma masks that device connection can't handle

dev->dma_coherent_mask must still keep values that hardware handles physically. This patch enforces that. Based on original version by Arnd Bergmann <a...@arndb.de>, extended with coherent mask hadnling. Signed-off-by: Nikita Yushchenko <nikita.yo...@cogentembedded.com> CC: Arnd Bergm

[PATCH] arm64: do not set dma masks that device connection can't handle

dev->dma_coherent_mask must still keep values that hardware handles physically. This patch enforces that. Based on original version by Arnd Bergmann <a...@arndb.de>, extended with coherent mask hadnling. Signed-off-by: Nikita Yushchenko <nikita.yo...@cogentembedded.com> CC: Arnd Bergm

[PATCH] arm64: do not set dma masks that device connection can't handle

dev->dma_coherent_mask must still keep values that hardware handles physically. This patch enforces that. Based on original version by Arnd Bergmann <a...@arndb.de>, extended with coherent mask hadnling. Signed-off-by: Nikita Yushchenko <nikita.yo...@cogentembedded.com> CC: Arnd Bergm

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

>>> Just a guess, but if the inbound translation windows in the host >>> bridge are wider than 32-bit, the reason for setting up a single >>> 32-bit window is probably because that is what the parent bus supports. I've re-checked rcar-pcie hardware documentation. It indeed mentions that AXI bus

Re: [PATCH v2] arm64: do not set dma masks that device connection can't handle

Hi > The point here is that an IOMMU doesn't solve your issue, and the > IOMMU-backed DMA ops need the same treatment. In light of that, it really > feels to me like the DMA masks should be restricted in of_dma_configure > so that the parent mask is taken into account there, rather than hook >

Re: [PATCH v2] arm64: do not set dma masks that device connection can't handle

>> What issue "IOMMU doesn't solve"? >> >> Issue I'm trying to address is - inconsistency within swiotlb >> dma_map_ops, where (1) any wide mask is silently accepted, but (2) then >> mask is used to decide if bounce buffers are needed or not. This >> inconsistency causes NVMe+R-Car cobmo not

[PATCH] arm64: avoid increasing DMA masks above what hardware supports

capabilities. To avoid breakage, actual mask must not be set wider than device connection allows. Signed-off-by: Nikita Yushchenko <nikita.yo...@cogentembedded.com> CC: Arnd Bergmann <a...@arndb.de> CC: Robin Murphy <robin.mur...@arm.com> CC: Will Deacon <will.dea...@arm.com>

Re: issue on rcar-du and/or vsp suspend-resume paths

Hello Kieran. Mayne thanks for that information. It will save me a lot of time. Nikita Hello Nikita On 07/12/17 08:48, Nikita Yushchenko wrote: Hello. Writing this mail to commiters to rcar-du and vsp1 drivers in kernel branch v4.9/rcar-3.5.9 of git://git.kernel.org/pub/scm/linux/kernel