Re: [PATCH 2/9] 8250/Kconfig: add config option CONFIG_SERIAL_8250_AMD

On Fri, Dec 04, 2015 at 11:24:19AM +0800, Wang Hongcheng wrote: > Add config option CONFIG_SERIAL_8250_AMD in use of AMD carrizo. > Because carrizo's UART DMA device is an amba device, it selects > ARM_AMBA option. Anything uses amba devices must select ARM_AMBA. > > Signed-off-by: Wang

Re: [PATCH 8/9] Documentation: Add ivrs_acpihid kernel parameter description

On Fri, Dec 04, 2015 at 11:24:25AM +0800, Wang Hongcheng wrote: > From: Wan Zongshun > > Add ivrs_acpihid kernel parameter description, > like ivrs_acpihid[00:14.5]=AMD0020:0. > > Signed-off-by: Wan Zongshun > --- > Documentation/kernel-parameters.txt

Re: [PATCH 6/9] dmaengine:pl330: set segment_boundary_mask = 0cffffffff

On 04/12/15 03:24, Wang Hongcheng wrote: Because amd iommu and software iommu need this mask.For example, if we use software iommu without this mask, we will get 'Out of SW-IOMMU space' error, when calling swiotlb_map_page function. The commit title doesn't match the code, but either way this

Re: [PATCH 3/9] ACPI: add struct acpi_amba_quirk for AMD pl330 specific device config

Hi Wang, [auto build test ERROR on pm/linux-next] [also build test ERROR on v4.4-rc3 next-20151203] url: https://github.com/0day-ci/linux/commits/Wang-Hongcheng/8250-AMD-Carrizo-UART-PL300-DMA-enablement/20151204-203235 base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux

Re: [PATCH 3/9] ACPI: add struct acpi_amba_quirk for AMD pl330 specific device config

On Fri, Dec 04, 2015 at 11:24:20AM +0800, Wang Hongcheng wrote: > AMD pl330 is a UART DMA device, it shares one ACPI item with UART. So > a platform device and an acpi device will be created according to > AMD0020 ACPI dev. And its mem base address must have an offset. As a > result,

RE: [PATCH 8/9] Documentation: Add ivrs_acpihid kernel parameter description

> > + ivrs_acpihid[HW,X86_64] > > + Provide an override to the ACPI-HID:UID<->DEVICE-ID > > + mapping provided in the IVRS ACPI table. For > > + example, to map UART-HID:UID AMD0020:0 to > > + PCI device 00:14.5 write

[PATCH 2/9] 8250/Kconfig: add config option CONFIG_SERIAL_8250_AMD

Add config option CONFIG_SERIAL_8250_AMD in use of AMD carrizo. Because carrizo's UART DMA device is an amba device, it selects ARM_AMBA option. Anything uses amba devices must select ARM_AMBA. Signed-off-by: Wang Hongcheng --- drivers/tty/serial/8250/Kconfig | 8

[PATCH 1/9] ACPI: Add support for AMBA bus type

From: Huang Rui Inspired by acpi platform bus type, to make driver "porting" more straightforward, this patch introduces ACPI support to the AMBA bus type. Instead of writing ACPI "glue" drivers for the exiting AMBA drivers. In the subsequent patches, we will use this

[PATCH 0/9] 8250: AMD Carrizo UART PL300 DMA enablement

Hi all, As AMD carrizo UART device is compatible with 8250 and has pl330 DMA IP, our uart driver is serial:8250 and DMA engines are registered by driver/dma/pl330. The following patches are made, in order to enable DMA. Firstly, we add an universal ACPI amba glue layer to create an amba device

Re: [PATCH 8/9] Documentation: Add ivrs_acpihid kernel parameter description

On Fri, Dec 04, 2015 at 01:19:35PM +, Wan, Vincent wrote: > > > + ivrs_acpihid[HW,X86_64] > > > + Provide an override to the ACPI-HID:UID<->DEVICE-ID > > > + mapping provided in the IVRS ACPI table. For > > > + example, to map UART-HID:UID

Re: [PATCH 1/9] ACPI: Add support for AMBA bus type

On Fri, Dec 04, 2015 at 09:59:28AM +, G Gregory wrote: > On 4 December 2015 at 09:42, Hanjun Guo wrote: > > On 2015/12/4 17:17, Huang Rui wrote: > >> On Fri, Dec 04, 2015 at 10:50:23AM +0200, Mika Westerberg wrote: > >>> On Fri, Dec 04, 2015 at 11:24:18AM +0800, Wang

[PATCH 9/9] iommu/amd: Add ACPI HID named devices IOMMU driver support

From: Wan Zongshun AMD UART is a ACPI HID named device, it also is none-pci device, currently, iommu driver only supports pci device, so UART DMA did not work at current AMD IOMMU driver. AMD reused 8250 serial driver and ARM PL330 DMA engine driver, since AMD uart and dma

Re: [PATCH 1/9] ACPI: Add support for AMBA bus type

On 4 December 2015 at 10:20, Huang Rui wrote: > On Fri, Dec 04, 2015 at 09:59:28AM +, G Gregory wrote: >> On 4 December 2015 at 09:42, Hanjun Guo wrote: >> > On 2015/12/4 17:17, Huang Rui wrote: >> >> On Fri, Dec 04, 2015 at 10:50:23AM +0200, Mika

[PATCH 8/9] Documentation: Add ivrs_acpihid kernel parameter description

From: Wan Zongshun Add ivrs_acpihid kernel parameter description, like ivrs_acpihid[00:14.5]=AMD0020:0. Signed-off-by: Wan Zongshun --- Documentation/kernel-parameters.txt | 7 +++ 1 file changed, 7 insertions(+) diff --git

Re: [PATCH 1/9] ACPI: Add support for AMBA bus type

On Fri, Dec 04, 2015 at 11:24:18AM +0800, Wang Hongcheng wrote: > From: Huang Rui > > Inspired by acpi platform bus type, to make driver "porting" more > straightforward, this patch introduces ACPI support to the AMBA bus > type. Instead of writing ACPI "glue" drivers for the

[PATCH 3/9] ACPI: add struct acpi_amba_quirk for AMD pl330 specific device config

AMD pl330 is a UART DMA device, it shares one ACPI item with UART. So a platform device and an acpi device will be created according to AMD0020 ACPI dev. And its mem base address must have an offset. As a result, MULTI_ATTACHED_QUIRK and MULTI_ATTACHED_QUIRK are used. Signed-off-by: Wang

[PATCH 5/9] dmaengine: pl330: provide ACPI dmaengine interface

register acpi_dma controller, so ACPI devices can request pl330 DMA channel. A filter is added in private data for Carrizo specific hardware design Signed-off-by: Wang Hongcheng --- drivers/acpi/acpi_apd.c| 12 drivers/dma/pl330.c| 38

Re: [PATCH 1/9] ACPI: Add support for AMBA bus type

On 4 December 2015 at 09:42, Hanjun Guo wrote: > On 2015/12/4 17:17, Huang Rui wrote: >> On Fri, Dec 04, 2015 at 10:50:23AM +0200, Mika Westerberg wrote: >>> On Fri, Dec 04, 2015 at 11:24:18AM +0800, Wang Hongcheng wrote: From: Huang Rui

[PATCH 4/9] dmaengine: pl330: add new items for pl330 private data

has_no_cap_mask means this device has no preset cap mask. mcbuf_sz means bytes to allocate for MC buffer. flags is for irq sharing, default is non-shared, in AMD Carrizo, pl330 shares IRQ with its corresponding UART device. Signed-off-by: Wang Hongcheng ---

[PATCH 6/9] dmaengine:pl330: set segment_boundary_mask = 0cffffffff

Because amd iommu and software iommu need this mask.For example, if we use software iommu without this mask, we will get 'Out of SW-IOMMU space' error, when calling swiotlb_map_page function. Signed-off-by: Wan Zongshun Signed-off-by: Wang Hongcheng ---

[PATCH 5/5] iommu/io-pgtable: Add ARMv7 short descriptor support

Add a nearly-complete ARMv7 short descriptor implementation, omitting only a few legacy and CPU-centric aspects which shouldn't be necessary for IOMMU API use anyway. Signed-off-by: Yong Wu Signed-off-by: Robin Murphy --- drivers/iommu/Kconfig

[PATCH 0/5] io-pgtable fixes + ARM short-descriptor format

This has been tested on an MMU-500 Fast Model, with the ARM SMMU driver hacked up to force short-descriptor at stage 1 - doing it properly needs more work to decouple the context format from the kernel bit-ness. Since I didn't want to delay getting this lot posted, that can come later. Thanks,

[PATCH 4/5] iommu/io-pgtable: Make io_pgtable_ops_to_pgtable() macro common

There is no need to keep a useful accessor for a public structure hidden away in a private implementation. Move it out alongside the structure definition so that other implementations may reuse it. Signed-off-by: Robin Murphy --- drivers/iommu/io-pgtable-arm.c | 3 ---

[PATCH 2/5] iommu/io-pgtable: Indicate granule for TLB maintenance

IOMMU hardware with range-based TLB maintenance commands can work happily with the iova and size arguments passed via the tlb_add_flush callback, but for IOMMUs which require separate commands per entry in the range, it is not straightforward to infer the necessary granularity when it comes to

[PATCH 1/5] iommu/io-pgtable-arm: Avoid dereferencing bogus PTEs

In the case of corrupted page tables, or when an invalid size is given, __arm_lpae_unmap() may recurse beyond the maximum number of levels. Unfortunately the detection of this error condition only happens *after* calculating a nonsense offset from something which might not be a valid table pointer

[PATCH 3/5] iommu/arm-smmu: Invalidate TLBs properly

When invalidating an IOVA range potentially spanning multiple pages, such as when removing an entire intermediate-level table, we currently only issue an invalidation for the first IOVA of that range. Since the architecture specifies that address-based TLB maintenance operations target a single