In your log, it seems something incorrect while copying pages.
Your last DMAR fault is:
DMAR:[fault reason 01] Present bit in root entry is clear
But this time, it is:
DMAR:[fault reason 05] PTE Write access is not set
So I think this line I added to this version , it works.
function intel_iomm
On 2015/01/07 17:52, Li, ZhenHua wrote:
> Well, that's quite good news.
> Looking forward Takao's testing on his system.
Unfortunately DMAR fault still occurs with this patch...
I attach console log.
Thanks,
Takao Indoh
>
> Regards
> Zhenhua
> On 01/07/2015 04:28 PM, Baoquan He wrote:
>> On 01/
On Wed, Jan 7, 2015 at 12:49 PM, Murali Karicheri wrote:
> Move of_dma_configure() to device.c so that same function can be re-used
> for PCI devices to obtain DMA configuration from DT. Also add a second
> argument so that for PCI, DT node of root bus host bridge can be used to
> obtain the DMA c
On Wed, Jan 7, 2015 at 12:49 PM, Murali Karicheri wrote:
> Function of_iommu_configure() is called from of_dma_configure() to
> setup iommu ops using DT property. This API is currently used for
> platform devices for which DMA configuration (including iommu ops)
> may come from device's parent. To
On Wed, Jan 7, 2015 at 5:05 PM, Murali Karicheri wrote:
> On 01/07/2015 01:49 PM, Murali Karicheri wrote:
>>
>> PCI devices on Keystone doesn't have correct dma_pfn_offset set. This
>> patch
>> add capability to set the dma configuration such as dma-mask,
>> dma_pfn_offset,
>> and dma ops etc usin
On 01/07/2015 01:49 PM, Murali Karicheri wrote:
PCI devices on Keystone doesn't have correct dma_pfn_offset set. This patch
add capability to set the dma configuration such as dma-mask, dma_pfn_offset,
and dma ops etc using the information from DT. The prior RFCs and discussions
are available at
On 01/07/2015 04:18 PM, Arnd Bergmann wrote:
On Wednesday 07 January 2015 13:49:50 Murali Karicheri wrote:
PCI devices on Keystone doesn't have correct dma_pfn_offset set. This patch
add capability to set the dma configuration such as dma-mask, dma_pfn_offset,
and dma ops etc using the informati
On Wednesday 07 January 2015 13:49:50 Murali Karicheri wrote:
> PCI devices on Keystone doesn't have correct dma_pfn_offset set. This patch
> add capability to set the dma configuration such as dma-mask, dma_pfn_offset,
> and dma ops etc using the information from DT. The prior RFCs and discussions
Move of_dma_configure() to device.c so that same function can be re-used
for PCI devices to obtain DMA configuration from DT. Also add a second
argument so that for PCI, DT node of root bus host bridge can be used to
obtain the DMA configuration for the slave PCI device. Additionally fix
the dma-ra
Hi Javier,
On 01/07/2015 06:33 PM, Javier Martinez Canillas wrote:
> Hello Joonyoung,
>
> On 01/07/2015 03:03 AM, Joonyoung Shim wrote:
>> On 01/06/2015 06:49 PM, Javier Martinez Canillas wrote:
>>>
>>> Also I tried forcing the kernel to not disable unused power domains by
>>> passing the pd_igno
On 01/06/2015 06:49 PM, Javier Martinez Canillas wrote:
> Hello Marek,
>
> On Fri, Dec 5, 2014 at 11:22 AM, Marek Szyprowski
> wrote:
>> On 2014-12-02 10:59, Sjoerd Simons wrote:
This is another attempt to finally make Exynos SYSMMU driver fully
integrated with DMA-mapping subsyste
Add of_pci_dma_configure() to allow updating the dma configuration
of the pci device using the configuration from DT of the parent of
the root bridge device.
Signed-off-by: Murali Karicheri
---
drivers/of/of_pci.c| 39 +++
include/linux/of_pci.h | 12 +
PCI devices on Keystone doesn't have correct dma_pfn_offset set. This patch
add capability to set the dma configuration such as dma-mask, dma_pfn_offset,
and dma ops etc using the information from DT. The prior RFCs and discussions
are available at [1] and [2] below.
[2] : https://www.mail-archive
Function of_iommu_configure() is called from of_dma_configure() to
setup iommu ops using DT property. This API is currently used for
platform devices for which DMA configuration (including iommu ops)
may come from device's parent. To extend this functionality for PCI
devices, this API need to take
If there is a DT node available for the root bridge's parent device,
use the dma configuration from that device node. For example, keystone
PCI devices would require dma_pfn_offset to be set correctly in the
device structure of the pci device in order to have the correct dma mask.
The DT node will
Hello Joonyoung,
On 01/07/2015 03:03 AM, Joonyoung Shim wrote:
> On 01/06/2015 06:49 PM, Javier Martinez Canillas wrote:
>>
>> Also I tried forcing the kernel to not disable unused power domains by
>> passing the pd_ignore_unused parameter to the kernel command line. I
>> see on the kernel log a
Hello Marek,
On Fri, Dec 5, 2014 at 11:22 AM, Marek Szyprowski
wrote:
> On 2014-12-02 10:59, Sjoerd Simons wrote:
>>>
>>> This is another attempt to finally make Exynos SYSMMU driver fully
>>> integrated with DMA-mapping subsystem. The main change from previous
>>> version is a rebase onto latest
On Wednesday 07 January 2015 18:57:05 Will Deacon wrote:
>
> Sorry for the delay on this, I had to do a bit of digging.
>
> On Mon, Dec 22, 2014 at 01:36:01PM +, Arnd Bergmann wrote:
> > Do you think it's possible that we might have to deal with a single PCI host
> > that is connected two dif
Hi Arnd,
Sorry for the delay on this, I had to do a bit of digging.
On Mon, Dec 22, 2014 at 01:36:01PM +, Arnd Bergmann wrote:
> Do you think it's possible that we might have to deal with a single PCI host
> that is connected two different SMMU instances for the purposes of extending
> the St
On Wed, Jan 07, 2015 at 06:35:41PM +, Mitchel Humpherys wrote:
> On Wed, Jan 07 2015 at 10:04:20 AM, Will Deacon wrote:
> > On Wed, Jan 07, 2015 at 05:52:46PM +, Mitchel Humpherys wrote:
> >> On Wed, Jan 07 2015 at 02:13:00 AM, Will Deacon
> >> wrote:
> >> > If would be better to check f
On Wed, Jan 07 2015 at 10:04:20 AM, Will Deacon wrote:
> On Wed, Jan 07, 2015 at 05:52:46PM +, Mitchel Humpherys wrote:
>> On Wed, Jan 07 2015 at 02:13:00 AM, Will Deacon wrote:
>> > On Tue, Jan 06, 2015 at 11:30:49PM +, Mitchel Humpherys wrote:
>> >> On Tue, Jan 06 2015 at 02:35:28 PM, R
On Wed, Jan 07, 2015 at 05:52:46PM +, Mitchel Humpherys wrote:
> On Wed, Jan 07 2015 at 02:13:00 AM, Will Deacon wrote:
> > On Tue, Jan 06, 2015 at 11:30:49PM +, Mitchel Humpherys wrote:
> >> On Tue, Jan 06 2015 at 02:35:28 PM, Rob Herring
> >> wrote:
> >> > On Tue, Jan 6, 2015 at 2:16 P
On Wed, Jan 07 2015 at 02:13:00 AM, Will Deacon wrote:
> On Tue, Jan 06, 2015 at 11:30:49PM +, Mitchel Humpherys wrote:
>> On Tue, Jan 06 2015 at 02:35:28 PM, Rob Herring
>> wrote:
>> > On Tue, Jan 6, 2015 at 2:16 PM, Mitchel Humpherys
>> > wrote:
>> >> On Tue, Jan 06 2015 at 06:15:07 AM, W
Hi Linus,
The following changes since commit b7392d2247cfe6771f95d256374f1a8e6a6f48d6:
Linux 3.19-rc2 (2014-12-28 16:49:37 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iommu-fixes-v3.19-rc3
for you to fetch changes up to
Hi Cho KyongHo, Joerg et al,
I found the latest Exynos IOMMU driver doesn't work, the line 481:
BUG_ON(!has_sysmmu(dev));
in function __exynos_sysmmu_enable() in file exynos-iommu.c triggers
kernel panic.
Then I found the dev->archdata.iommu isn't initialized at all, it
should be the root cause.
On Tue, Jan 06, 2015 at 11:30:49PM +, Mitchel Humpherys wrote:
> On Tue, Jan 06 2015 at 02:35:28 PM, Rob Herring wrote:
> > On Tue, Jan 6, 2015 at 2:16 PM, Mitchel Humpherys
> > wrote:
> >> On Tue, Jan 06 2015 at 06:15:07 AM, Will Deacon
> >> wrote:
> /* Invalidate the TLB, just i
Well, that's quite good news.
Looking forward Takao's testing on his system.
Regards
Zhenhua
On 01/07/2015 04:28 PM, Baoquan He wrote:
On 01/07/15 at 01:25pm, Li, ZhenHua wrote:
It is same as the last one I send to you yesterday.
The continuous memory that needed for data in this patchset:
RE:
On 01/07/15 at 01:25pm, Li, ZhenHua wrote:
> It is same as the last one I send to you yesterday.
>
> The continuous memory that needed for data in this patchset:
> RE: PAGE_SIZE, 4096 Bytes;
> IRTE: 65536 * 16 ; 1M Bytes;
>
> It should use same memory as the old versions of this patchset. The
> c
28 matches
Mail list logo
