Hi Ralf,
On 07/31/2018 11:47 AM, Ralf Göbel wrote:
> I think that the offset for the table entry is already included in the pt_dma variable. So adding the offset again leads to an incorrect address, except for the first entry with offset = 0.
>
> Changing the line only in iopte_alloc_page() seems to solve the problem for me. But I changed all three locations because I think they are incorrect:
>
> iopte_alloc_page() and iopte_alloc_large() get the pt_dma value by calling iopte_alloc(), which uses iopte_offset() to calculate the address:
>
> static u32 *iopte_alloc(struct omap_iommu *obj, u32 *iopgd, dma_addr_t *pt_dma, u32 da)
> {
> ...
> pte_ready:
> iopte = iopte_offset(iopgd, da);
> *pt_dma = virt_to_phys(iopte);
Yeah, agreed. This is a bug, thanks for catching this. Need to fix the
value being reflected in *pt_dma, not forcing the offset to 0. The
internal dma ops adds the offset to the base while performing the operation.
Care to submit a patch, or do you want me to take care of this?
regards
Suman
>
> return iopte;
> }
>
> iopgtable_clear_entry_core() also uses iopte_offset() to get the address.
>
> Thanks,
> Ralf
>
>> -----Original Message-----
>> From: Suman Anna [mailto:s-anna@xxxxxx]
>> Sent: Tuesday, July 31, 2018 6:07 PM
>>
>> Hi Ralf,
>>
>> Removing Josue from the thread so that mails don't bounce.
>>
>> On 07/31/2018 05:01 AM, Ralf Göbel wrote:
>>> Hi,
>>>
>>> I think the offsets used for flushing the page table entries in
>>> iopte_alloc_page(), iopte_alloc_large() and iopgtable_clear_entry_core()
>> are
>>> incorrect. The offsets are already included in pt_dma and therefore they
>>> should be zero.
>>>
>>> The problem occurred while adding support for System MMU2 (PCIe) on a
>>> AM5728.
>>> An exception occurs during a memory write from a device into memory:
>>>
>>> [ 63.607203] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:147
>>> l3_interrupt_handler+0x25c/0x36c
>>> [ 63.616373] 44000000.ocp:L3 Custom Error: MASTER PCIE1 TARGET MMU2
>>> (Idle): Data Access in User mode during Functional access
>>> [ 63.627633] Modules linked in: agexpcidrv(O)
>>> [ 63.631934] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O
>>> 4.9.59-rt23-visioncam-xm+ #38
>>> [ 63.640839] Hardware name: Generic DRA74X (Flattened Device Tree)
>>> [ 63.646953] Backtrace:
>>> ...
>>> [ 63.916445] iommu_report_fault(): status = 0x00000002
>>> [ 63.916456] omap-iommu 4881e000.mmu: 4881e000.mmu: errs:0x00000002
>>> da:0x80002f80 pgd:0xeeba6000 *pgd:0xad989c01 pte:0xed989c08
>> *pte:0xb73d7002
>>>
>>> According to TI documentation, this error (status = 0x00000002) is
>> caused by
>>> an invalid descriptor in the translation tables (TRANSLATIONFAULT).
>>>
>>> The following change in the functions mentioned above fixed the problem:
>>>
>>> flush_iopte_range(obj->dev, pt_dma, 0/*offset*/, ...);
>>
>> There calls are flushing only the entries modified, so that's where the
>> offset is coming from, and the num_entries is used to compute the length.
>>
>> Which line did you have to modify to get this working - did you modify a
>> specific line or all of them?
>>
>> regards
>> Suman
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
