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
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.
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
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/
>> 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
>> @@ -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
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
> 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.
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>
> 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
> 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
>> +/*
>> + * 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.
>> 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
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>
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
>
.
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
>> 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
[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()
>>
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
>> +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.
>> + */
>> +
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
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
>>> 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
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
>> 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
> 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
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
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
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
29 matches
Mail list logo