Re: [PART2 RFC v2 00/10] iommu/AMD: Introduce IOMMU AVIC support

On 6/21/2016 9:46 AM, Joerg Roedel wrote: On Tue, Jun 21, 2016 at 09:27:27AM -0500, Suthikulpanit, Suravee wrote: On 6/21/2016 8:50 AM, Joerg Roedel wrote: The code has a few style issues (thing I'd implemented differently), but it looks functional. Anything in particular that you think I

Re: [PART2 RFC v2 00/10] iommu/AMD: Introduce IOMMU AVIC support

On 6/21/2016 9:46 AM, Joerg Roedel wrote: On Tue, Jun 21, 2016 at 09:27:27AM -0500, Suthikulpanit, Suravee wrote: On 6/21/2016 8:50 AM, Joerg Roedel wrote: The code has a few style issues (thing I'd implemented differently), but it looks functional. Anything in particular that you think I

Re: [PART2 RFC v2 00/10] iommu/AMD: Introduce IOMMU AVIC support

On 6/21/2016 8:50 AM, Joerg Roedel wrote: The code has a few style issues (thing I'd implemented differently), but it looks functional. Anything in particular that you think I should improve or/and change? Thanks, Suravee

Re: [PART2 RFC v2 00/10] iommu/AMD: Introduce IOMMU AVIC support

On 6/21/2016 8:50 AM, Joerg Roedel wrote: The code has a few style issues (thing I'd implemented differently), but it looks functional. Anything in particular that you think I should improve or/and change? Thanks, Suravee

Re: [PATCH] KVM: SVM: compile out AVIC if !CONFIG_X86_LOCAL_APIC

On 6/14/2016 5:01 PM, Paolo Bonzini wrote: On 14/06/2016 23:44, Suravee Suthikulanit wrote: > On 6/14/2016 4:22 PM, Paolo Bonzini wrote: >> - Original Message - >>> From: "Suravee Suthikulanit" <suravee.suthikulpa...@amd.com> >>> To: "

Re: [PATCH] KVM: SVM: compile out AVIC if !CONFIG_X86_LOCAL_APIC

On 6/14/2016 5:01 PM, Paolo Bonzini wrote: On 14/06/2016 23:44, Suravee Suthikulanit wrote: > On 6/14/2016 4:22 PM, Paolo Bonzini wrote: >> - Original Message - >>> From: "Suravee Suthikulanit" >>> To: "Paolo Bonzini" , >>> l

Re: [PATCH] KVM: SVM: compile out AVIC if !CONFIG_X86_LOCAL_APIC

On 6/14/2016 4:22 PM, Paolo Bonzini wrote: - Original Message - From: "Suravee Suthikulanit" <suravee.suthikulpa...@amd.com> To: "Paolo Bonzini" <pbonz...@redhat.com>, linux-kernel@vger.kernel.org, k...@vger.kernel.org Cc: rkrc...@redhat.com Sent: T

Re: [PATCH] KVM: SVM: compile out AVIC if !CONFIG_X86_LOCAL_APIC

On 6/14/2016 4:22 PM, Paolo Bonzini wrote: - Original Message - From: "Suravee Suthikulanit" To: "Paolo Bonzini" , linux-kernel@vger.kernel.org, k...@vger.kernel.org Cc: rkrc...@redhat.com Sent: Tuesday, June 14, 2016 8:20:30 PM Subject: Re: [PATCH] KVM: S

Re: [PATCH] KVM: SVM: compile out AVIC if !CONFIG_X86_LOCAL_APIC

Hi Paolo, On 6/14/2016 11:40 AM, Paolo Bonzini wrote: AVIC needs __default_cpu_present_to_apicid. Stub out all functions that use it, and disable the module parameter, if Linux is compiled without local APIC support. I think you are right that we should disable AVIC #ifndef

Re: [PATCH] KVM: SVM: compile out AVIC if !CONFIG_X86_LOCAL_APIC

Hi Paolo, On 6/14/2016 11:40 AM, Paolo Bonzini wrote: AVIC needs __default_cpu_present_to_apicid. Stub out all functions that use it, and disable the module parameter, if Linux is compiled without local APIC support. I think you are right that we should disable AVIC #ifndef

Re: [PATCH V8 0/9] Support for ARM64 ACPI based PCI host controller

On 5/30/2016 10:14 AM, Tomasz Nowicki wrote: From the functionality point of view this series may be split into the following logic parts: 1. Export ECAM API and add parent device to pci_config_window 2. Add IO resources handling to PCI core code 3. Support for generic domain assignment based on

Re: [PATCH V8 0/9] Support for ARM64 ACPI based PCI host controller

On 5/30/2016 10:14 AM, Tomasz Nowicki wrote: From the functionality point of view this series may be split into the following logic parts: 1. Export ECAM API and add parent device to pci_config_window 2. Add IO resources handling to PCI core code 3. Support for generic domain assignment based on

Re: [PART2 RFC v1 1/9] iommu/amd: Detect and enable guest vAPIC support

On 5/9/2016 6:49 AM, Joerg Roedel wrote: On Fri, Apr 08, 2016 at 07:49:22AM -0500, Suthikulpanit, Suravee wrote: From: Suravee Suthikulpanit This patch introduces a new IOMMU driver parameter, amd_iommu_guest_ir, which can be used to specify different interrupt

Re: [PART2 RFC v1 1/9] iommu/amd: Detect and enable guest vAPIC support

On 5/9/2016 6:49 AM, Joerg Roedel wrote: On Fri, Apr 08, 2016 at 07:49:22AM -0500, Suthikulpanit, Suravee wrote: From: Suravee Suthikulpanit This patch introduces a new IOMMU driver parameter, amd_iommu_guest_ir, which can be used to specify different interrupt remapping mode for passthrough

Re: [PART1 RFC v4 08/11] svm: Add VMEXIT handlers for AVIC

Hi Radim / Paolo, Sorry for delay in response. On 4/12/2016 11:22 AM, Radim Krčmář wrote: 2016-04-07 03:20-0500, Suravee Suthikulpanit: From: Suravee Suthikulpanit This patch introduces VMEXIT handlers, avic_incomplete_ipi_interception() and

Re: [PART1 RFC v4 08/11] svm: Add VMEXIT handlers for AVIC

Hi Radim / Paolo, Sorry for delay in response. On 4/12/2016 11:22 AM, Radim Krčmář wrote: 2016-04-07 03:20-0500, Suravee Suthikulpanit: From: Suravee Suthikulpanit This patch introduces VMEXIT handlers, avic_incomplete_ipi_interception() and avic_unaccelerated_access_interception() along

Re: [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS

On 1/28/2016 8:43 PM, Olof Johansson wrote: On Thu, Jan 28, 2016 at 2:20 PM, Suravee Suthikulanit wrote: Hi Olof, On 1/28/2016 3:39 PM, Olof Johansson wrote: Hi Suravee, On Wed, Jan 27, 2016 at 1:11 PM, Suravee Suthikulpanit wrote: From: Suravee Suthikulpanit This patch series

Re: [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS

On 1/28/2016 8:43 PM, Olof Johansson wrote: On Thu, Jan 28, 2016 at 2:20 PM, Suravee Suthikulanit <suravee.suthikulpa...@amd.com> wrote: Hi Olof, On 1/28/2016 3:39 PM, Olof Johansson wrote: Hi Suravee, On Wed, Jan 27, 2016 at 1:11 PM, Suravee Suthikulpanit <suravee.suthikulpa..

Re: [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS

Hi Olof, On 1/28/2016 3:39 PM, Olof Johansson wrote: Hi Suravee, On Wed, Jan 27, 2016 at 1:11 PM, Suravee Suthikulpanit wrote: From: Suravee Suthikulpanit This patch series contains several updates for the AMD Seattle SOC DTS files. It also adds new board files for newer Overdrive and

Re: [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS

Hi Olof, On 1/28/2016 3:39 PM, Olof Johansson wrote: Hi Suravee, On Wed, Jan 27, 2016 at 1:11 PM, Suravee Suthikulpanit wrote: From: Suravee Suthikulpanit This patch series contains several updates for the AMD Seattle SOC DTS

Re: [PATCH v7 3/4] gicv2m: Refactor to prepare for ACPI support

On 12/17/2015 10:57 AM, Bjorn Helgaas wrote: On Wed, Dec 16, 2015 at 06:23:49PM -0600, Suravee Suthikulanit wrote: Hi Bjorn, Thanks for your review. Please see my comments below. On 12/16/2015 4:12 PM, Bjorn Helgaas wrote: On Thu, Dec 10, 2015 at 08:55:29AM -0800, Suravee Suthikulpanit wrote

Re: [PATCH v2] i2c: designware: Do not require clock when SSCN and FFCN are provided

Hi Mika, On 12/18/2015 4:13 AM, Mika Westerberg wrote: [] So instead of this, what if we do not assign dev->get_clk_rate_khz at all and then do something like below in the core driver? I like the changes below since it is clear to see within the core file how things are handled when

Re: [PATCH v2] i2c: designware: Do not require clock when SSCN and FFCN are provided

Hi Mika, On 12/18/2015 4:13 AM, Mika Westerberg wrote: [] So instead of this, what if we do not assign dev->get_clk_rate_khz at all and then do something like below in the core driver? I like the changes below since it is clear to see within the core file how things are handled when

Re: [PATCH v7 3/4] gicv2m: Refactor to prepare for ACPI support

On 12/17/2015 10:57 AM, Bjorn Helgaas wrote: On Wed, Dec 16, 2015 at 06:23:49PM -0600, Suravee Suthikulanit wrote: Hi Bjorn, Thanks for your review. Please see my comments below. On 12/16/2015 4:12 PM, Bjorn Helgaas wrote: On Thu, Dec 10, 2015 at 08:55:29AM -0800, Suravee Suthikulpanit wrote

Re: [PATCH] iommu/amd: Assign default IOMMU when there is only one IOMMU

On 12/14/2015 9:08 AM, Joerg Roedel wrote: On Fri, Dec 11, 2015 at 04:54:38PM -0600, Suravee Suthikulpanit wrote: Current driver makes assumption that device with devid zero is always included in the range of devices to be managed by IOMMU. However, certain FW does not include devid zero in

Re: [PATCH v2] i2c: designware: Do not require clock when SSCN and FFCN are provided

On 12/16/2015 8:56 PM, Loc Ho wrote: Hi, The current driver uses input clock source frequency to calculate values for [SS|FS]_[HC|LC] registers. However, when booting ACPI, we do not currently have a good way to provide the frequency information. Instead, we can leverage the SSCN and FFCN ACPI

Re: [PATCH] i2c: designware: Add support for AMD Seattle I2C

Mika, On 12/16/2015 8:54 AM, Mika Westerberg wrote: On Wed, Dec 16, 2015 at 08:29:38AM -0600, Suravee Suthikulpanit wrote: > > >On 12/16/2015 03:16 AM, Mika Westerberg wrote: > >On Tue, Dec 15, 2015 at 08:14:34PM -0600, Suravee Suthikulpanit wrote: > >>Hi Mika, > >> > >>On 12/15/15 15:55,

Re: [PATCH v7 1/4] acpi: pci: Setup MSI domain for ACPI based pci devices

On 12/16/2015 4:15 PM, Bjorn Helgaas wrote: On Thu, Dec 10, 2015 at 08:55:27AM -0800, Suravee Suthikulpanit wrote: >This patch introduces pci_msi_register_fwnode_provider() for irqchip >to register a callback, to provide a way to determine appropriate MSI >domain for a pci device. > >It also

Re: [PATCH v7 3/4] gicv2m: Refactor to prepare for ACPI support

Hi Bjorn, Thanks for your review. Please see my comments below. On 12/16/2015 4:12 PM, Bjorn Helgaas wrote: On Thu, Dec 10, 2015 at 08:55:29AM -0800, Suravee Suthikulpanit wrote: This patch replaces the struct device_node with struct fwnode_handle since this structure is common between DT and

Re: [PATCH v7 3/4] gicv2m: Refactor to prepare for ACPI support

Hi Bjorn, Thanks for your review. Please see my comments below. On 12/16/2015 4:12 PM, Bjorn Helgaas wrote: On Thu, Dec 10, 2015 at 08:55:29AM -0800, Suravee Suthikulpanit wrote: This patch replaces the struct device_node with struct fwnode_handle since this structure is common between DT and

Re: [PATCH] i2c: designware: Add support for AMD Seattle I2C

Mika, On 12/16/2015 8:54 AM, Mika Westerberg wrote: On Wed, Dec 16, 2015 at 08:29:38AM -0600, Suravee Suthikulpanit wrote: > > >On 12/16/2015 03:16 AM, Mika Westerberg wrote: > >On Tue, Dec 15, 2015 at 08:14:34PM -0600, Suravee Suthikulpanit wrote: > >>Hi Mika, > >> > >>On 12/15/15 15:55,

Re: [PATCH v7 1/4] acpi: pci: Setup MSI domain for ACPI based pci devices

On 12/16/2015 4:15 PM, Bjorn Helgaas wrote: On Thu, Dec 10, 2015 at 08:55:27AM -0800, Suravee Suthikulpanit wrote: >This patch introduces pci_msi_register_fwnode_provider() for irqchip >to register a callback, to provide a way to determine appropriate MSI >domain for a pci device. > >It also

Re: [PATCH v2] i2c: designware: Do not require clock when SSCN and FFCN are provided

On 12/16/2015 8:56 PM, Loc Ho wrote: Hi, The current driver uses input clock source frequency to calculate values for [SS|FS]_[HC|LC] registers. However, when booting ACPI, we do not currently have a good way to provide the frequency information. Instead, we can leverage the SSCN and FFCN ACPI

Re: [PATCH] iommu/amd: Assign default IOMMU when there is only one IOMMU

On 12/14/2015 9:08 AM, Joerg Roedel wrote: On Fri, Dec 11, 2015 at 04:54:38PM -0600, Suravee Suthikulpanit wrote: Current driver makes assumption that device with devid zero is always included in the range of devices to be managed by IOMMU. However, certain FW does not include devid zero in

Re: [PATCH v6 4/4] gicv2m: acpi: Introducing GICv2m ACPI support

On 12/10/2015 3:14 AM, Marc Zyngier wrote: +int __init gicv2m_init(struct fwnode_handle *parent_handle, >+ struct irq_domain *parent) >+{ >+ int ret = gicv2m_of_init(parent_handle, parent); >+ >+ if (ret) >+ ret = gicv2m_acpi_init(parent); >+ return ret; This

Re: [PATCH v6 4/4] gicv2m: acpi: Introducing GICv2m ACPI support

On 12/10/2015 3:14 AM, Marc Zyngier wrote: +int __init gicv2m_init(struct fwnode_handle *parent_handle, >+ struct irq_domain *parent) >+{ >+ int ret = gicv2m_of_init(parent_handle, parent); >+ >+ if (ret) >+ ret = gicv2m_acpi_init(parent); >+ return ret; This

Re: [PATCH v6 0/4] gicv2m: acpi: Add ACPI support for GICv2m MSI

On 12/9/2015 8:20 PM, Duc Dang wrote: This has been tested on AMD Seattle (Overdrive) RevB system. > >NOTE: I have not tested ACPI GICv2m multiframe support since >I don't have access to such system. Any helps are appreciated. Hi Suravee, I tested your v2m-multiframe-v6 branch with APM X-Gene

Re: [PATCH v5 5/5] gicv2m: acpi: Introducing GICv2m ACPI support

On 12/9/2015 12:16 PM, Marc Zyngier wrote: diff --git a/drivers/irqchip/irq-gic-v2m.c b/drivers/irqchip/irq-gic-v2m.c >>>[...] >>>@@ -359,6 +368,8 @@ static int __init gicv2m_init_one(struct fwnode_handle *fwnode, >>> >>>if (to_of_node(fwnode)) >>>name =

Re: [PATCH v5 5/5] gicv2m: acpi: Introducing GICv2m ACPI support

Hi Marc, On 12/9/2015 4:38 AM, Marc Zyngier wrote: On Tue, 8 Dec 2015 17:48:06 -0800 Suravee Suthikulpanit wrote: This patch introduces gicv2m_acpi_init(), which uses information in MADT GIC MSI frames structure to initialize GICv2m driver. Signed-off-by: Suravee Suthikulpanit

Re: [PATCH v5 1/5] acpi: pci: Setup MSI domain for ACPI based pci devices

On 12/9/2015 4:13 AM, Marc Zyngier wrote: On Tue, 8 Dec 2015 17:48:02 -0800 Suravee Suthikulpanit wrote: This patch introduces pci_msi_register_fwnode_provider() for irqchip to register a callback, to provide a way to determine appropriate MSI domain for a pci device. It also introduces

Re: [PATCH v5 1/5] acpi: pci: Setup MSI domain for ACPI based pci devices

On 12/9/2015 4:13 AM, Marc Zyngier wrote: On Tue, 8 Dec 2015 17:48:02 -0800 Suravee Suthikulpanit wrote: This patch introduces pci_msi_register_fwnode_provider() for irqchip to register a callback, to provide a way to determine appropriate MSI domain for a pci

Re: [PATCH v5 5/5] gicv2m: acpi: Introducing GICv2m ACPI support

Hi Marc, On 12/9/2015 4:38 AM, Marc Zyngier wrote: On Tue, 8 Dec 2015 17:48:06 -0800 Suravee Suthikulpanit wrote: This patch introduces gicv2m_acpi_init(), which uses information in MADT GIC MSI frames structure to initialize GICv2m driver. Signed-off-by:

Re: [PATCH v5 5/5] gicv2m: acpi: Introducing GICv2m ACPI support

On 12/9/2015 12:16 PM, Marc Zyngier wrote: diff --git a/drivers/irqchip/irq-gic-v2m.c b/drivers/irqchip/irq-gic-v2m.c >>>[...] >>>@@ -359,6 +368,8 @@ static int __init gicv2m_init_one(struct fwnode_handle *fwnode, >>> >>>if (to_of_node(fwnode)) >>>name =

Re: [PATCH v6 0/4] gicv2m: acpi: Add ACPI support for GICv2m MSI

On 12/9/2015 8:20 PM, Duc Dang wrote: This has been tested on AMD Seattle (Overdrive) RevB system. > >NOTE: I have not tested ACPI GICv2m multiframe support since >I don't have access to such system. Any helps are appreciated. Hi Suravee, I tested your v2m-multiframe-v6 branch with APM X-Gene

Re: [PATCH] PCI: Fix logic OF logic in pci_dma_configure()

Arg... sorry for the typo in the subject. It should say: [PATCH] PCI: Fix OF logic in pci_dma_configure() Suravee On 11/18/2015 6:49 PM, Suravee Suthikulpanit wrote: This patch fixes a bug introduced by previous commit, which incorrectly checkes the of_node of the end-point device. Instead,

Re: [PATCH V5 8/9] PCI: OF: Move of_pci_dma_configure() to pci_dma_configure()

Hi All, On 11/18/2015 6:41 AM, Arnd Bergmann wrote: On Wednesday 18 November 2015 12:00:32 Robin Murphy wrote: On 17/11/15 15:00, Robin Murphy wrote: On 28/10/15 22:50, Suravee Suthikulpanit wrote: Signed-off-by: Suravee Suthikulpanit Acked-by: Rob Herring Acked-by: Bjorn Helgaas

Re: [PATCH V5 8/9] PCI: OF: Move of_pci_dma_configure() to pci_dma_configure()

On 11/18/2015 6:41 AM, Arnd Bergmann wrote: On Wednesday 18 November 2015 12:00:32 Robin Murphy wrote: On 17/11/15 15:00, Robin Murphy wrote: On 28/10/15 22:50, Suravee Suthikulpanit wrote: Signed-off-by: Suravee Suthikulpanit Acked-by: Rob Herring Acked-by: Bjorn Helgaas Reviewed-by:

Re: [PATCH V5 8/9] PCI: OF: Move of_pci_dma_configure() to pci_dma_configure()

Hi All, On 11/18/2015 6:41 AM, Arnd Bergmann wrote: On Wednesday 18 November 2015 12:00:32 Robin Murphy wrote: On 17/11/15 15:00, Robin Murphy wrote: On 28/10/15 22:50, Suravee Suthikulpanit wrote: Signed-off-by: Suravee Suthikulpanit Acked-by: Rob Herring

Re: [PATCH V5 8/9] PCI: OF: Move of_pci_dma_configure() to pci_dma_configure()

On 11/18/2015 6:41 AM, Arnd Bergmann wrote: On Wednesday 18 November 2015 12:00:32 Robin Murphy wrote: On 17/11/15 15:00, Robin Murphy wrote: On 28/10/15 22:50, Suravee Suthikulpanit wrote: Signed-off-by: Suravee Suthikulpanit Acked-by: Rob Herring

Re: [PATCH] PCI: Fix logic OF logic in pci_dma_configure()

Arg... sorry for the typo in the subject. It should say: [PATCH] PCI: Fix OF logic in pci_dma_configure() Suravee On 11/18/2015 6:49 PM, Suravee Suthikulpanit wrote: This patch fixes a bug introduced by previous commit, which incorrectly checkes the of_node of the end-point device. Instead,

Re: [PATCH V5 0/9] PCI: ACPI: Setting up DMA coherency for PCI device from _CCA attribute

On 11/1/2015 7:01 PM, Rafael J. Wysocki wrote: Queued up for v4.4, but I'll include it into my second pull request in the second half of the merge window. Thanks, Rafael Thank you, Suravee -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

Re: [PATCH V5 1/9] ACPI: Honor ACPI _CCA attribute setting

Hi Dennis / Hanjun, On 11/2/2015 5:58 AM, Hanjun Guo wrote: Hi Dennis, On 11/02/2015 12:02 PM, Dennis Chen wrote: On Thu, Oct 29, 2015 at 6:50 AM, Suravee Suthikulpanit wrote: From: Jeremy Linton ACPI configurations can now mark devices as noncoherent, support that choice. NOTE: This is

Re: [PATCH V5 1/9] ACPI: Honor ACPI _CCA attribute setting

Hi Dennis / Hanjun, On 11/2/2015 5:58 AM, Hanjun Guo wrote: Hi Dennis, On 11/02/2015 12:02 PM, Dennis Chen wrote: On Thu, Oct 29, 2015 at 6:50 AM, Suravee Suthikulpanit wrote: From: Jeremy Linton ACPI configurations can now mark

Re: [PATCH V5 0/9] PCI: ACPI: Setting up DMA coherency for PCI device from _CCA attribute

On 11/1/2015 7:01 PM, Rafael J. Wysocki wrote: Queued up for v4.4, but I'll include it into my second pull request in the second half of the merge window. Thanks, Rafael Thank you, Suravee -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

Re: [PATCH V2 6/6] gicv2m: acpi: Introducing GICv2m ACPI support

Hi Tomasz, On 10/15/2015 9:03 AM, Suravee Suthikulanit wrote: +if (!data) +return NULL; + +return data->fwnode; +} + +static int __init +acpi_parse_madt_msi(struct acpi_subtable_header *header, +const unsigned long end) +{ +int ret; +struct resource

Re: [PATCH V2 6/6] gicv2m: acpi: Introducing GICv2m ACPI support

Hi Tomasz, Thanks for the feedback. On 10/15/2015 1:15 AM, Tomasz Nowicki wrote: [..] @@ -138,6 +140,11 @@ static int gicv2m_irq_gic_domain_alloc(struct irq_domain *domain, fwspec.param[0] = 0; fwspec.param[1] = hwirq - 32; fwspec.param[2] = IRQ_TYPE_EDGE_RISING;

Re: [PATCH V2 6/6] gicv2m: acpi: Introducing GICv2m ACPI support

Hi Tomasz, On 10/15/2015 9:03 AM, Suravee Suthikulanit wrote: +if (!data) +return NULL; + +return data->fwnode; +} + +static int __init +acpi_parse_madt_msi(struct acpi_subtable_header *header, +const unsigned long end) +{ +int ret; +struct resource

Re: [PATCH V2 6/6] gicv2m: acpi: Introducing GICv2m ACPI support

Hi Tomasz, Thanks for the feedback. On 10/15/2015 1:15 AM, Tomasz Nowicki wrote: [..] @@ -138,6 +140,11 @@ static int gicv2m_irq_gic_domain_alloc(struct irq_domain *domain, fwspec.param[0] = 0; fwspec.param[1] = hwirq - 32; fwspec.param[2] = IRQ_TYPE_EDGE_RISING;

Re: [PATCH v2 2/2] irqchip/gic-v2m: Add support for multiple MSI frames

On 10/14/2015 10:28 AM, Marc Zyngier wrote: On 14/10/15 15:13, Suravee Suthikulanit wrote: Hi Marc, On 10/14/2015 6:27 AM, Marc Zyngier wrote: The GICv2m driver is so far limited to a single MSI frame, but nothing prevents an implementation from having several of them. This patch expands

Re: [PATCH v2 2/2] irqchip/gic-v2m: Add support for multiple MSI frames

Hi Marc, On 10/14/2015 6:27 AM, Marc Zyngier wrote: The GICv2m driver is so far limited to a single MSI frame, but nothing prevents an implementation from having several of them. This patch expands the driver to enumerate all frames, keeping the first one as the canonical identifier for the

Re: [PATCH v2 2/2] irqchip/gic-v2m: Add support for multiple MSI frames

On 10/14/2015 10:28 AM, Marc Zyngier wrote: On 14/10/15 15:13, Suravee Suthikulanit wrote: Hi Marc, On 10/14/2015 6:27 AM, Marc Zyngier wrote: The GICv2m driver is so far limited to a single MSI frame, but nothing prevents an implementation from having several of them. This patch expands

Re: [PATCH v2 2/2] irqchip/gic-v2m: Add support for multiple MSI frames

Hi Marc, On 10/14/2015 6:27 AM, Marc Zyngier wrote: The GICv2m driver is so far limited to a single MSI frame, but nothing prevents an implementation from having several of them. This patch expands the driver to enumerate all frames, keeping the first one as the canonical identifier for the

Re: [PATCH V3 2/4] ACPI/scan: Clean up acpi_check_dma

Bjorn / Rafael, On 10/13/2015 10:52 AM, Suravee Suthikulpanit wrote: On 09/14/2015 09:34 AM, Bjorn Helgaas wrote: [..] I think acpi_check_dma_coherency() is better, but only slightly. It still doesn't give a hint about the *sense* of the return value. I think it'd be easier to read if there

Re: [PATCH V3 2/4] ACPI/scan: Clean up acpi_check_dma

Bjorn / Rafael, On 10/13/2015 10:52 AM, Suravee Suthikulpanit wrote: On 09/14/2015 09:34 AM, Bjorn Helgaas wrote: [..] I think acpi_check_dma_coherency() is better, but only slightly. It still doesn't give a hint about the *sense* of the return value. I think it'd be easier to read if there

Re: [RFC/RFT PATCH v2] PCI: move pci_read_bridge_bases to the generic PCI layer

For ARM64 PROBE_ONLY and non-PROBE_ONLY modes: Reviewed and Tested-by: Suravee Suthikulpanit Please see minor comments below. On 6/9/2015 4:01 AM, Lorenzo Pieralisi wrote: When a PCI bus is scanned, upon PCI bridge detection the kernel has to read the bridge registers to set-up its

Re: [RFC/RFT PATCH v2] PCI: move pci_read_bridge_bases to the generic PCI layer

For ARM64 PROBE_ONLY and non-PROBE_ONLY modes: Reviewed and Tested-by: Suravee Suthikulpanit suravee.suthikulpa...@amd.com Please see minor comments below. On 6/9/2015 4:01 AM, Lorenzo Pieralisi wrote: When a PCI bus is scanned, upon PCI bridge detection the kernel has to read the bridge

Re: [V5 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object

On 5/28/2015 9:38 PM, Mark Salter wrote: On Wed, 2015-05-20 at 17:09 -0500, Suravee Suthikulpanit wrote: >Fromhttp://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf, >section 6.2.17 _CCA states that ARM platforms require ACPI _CCA >object to be specified for DMA-cabpable devices.

Re: [V5 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object

On 5/28/2015 9:38 PM, Mark Salter wrote: On Wed, 2015-05-20 at 17:09 -0500, Suravee Suthikulpanit wrote: Fromhttp://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf, section 6.2.17 _CCA states that ARM platforms require ACPI _CCA object to be specified for DMA-cabpable devices.

Re: [RFC/RFT PATCH] PCI: move pci_read_bridge_bases to the generic PCI layer

On 5/27/2015 12:54 PM, Lorenzo Pieralisi wrote: diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c > >index 062fee6..335d9f2 100644 > >--- a/drivers/pci/probe.c > >+++ b/drivers/pci/probe.c > >@@ -453,7 +453,11 @@ void pci_read_bridge_bases(struct pci_bus *child) > > struct resource

Re: [RFC/RFT PATCH] PCI: move pci_read_bridge_bases to the generic PCI layer

Hi Lorenzo, Sorry for late reply. On 5/21/2015 8:14 AM, Lorenzo Pieralisi wrote: When a PCI bus is scanned, upon PCI bridge detection the kernel has to read the bridge registers to set-up its resources so that the PCI resource hierarchy can be validated properly. Most if not all architectures

Re: [RFC/RFT PATCH] PCI: move pci_read_bridge_bases to the generic PCI layer

Hi Lorenzo, Sorry for late reply. On 5/21/2015 8:14 AM, Lorenzo Pieralisi wrote: When a PCI bus is scanned, upon PCI bridge detection the kernel has to read the bridge registers to set-up its resources so that the PCI resource hierarchy can be validated properly. Most if not all architectures

Re: [RFC/RFT PATCH] PCI: move pci_read_bridge_bases to the generic PCI layer

On 5/27/2015 12:54 PM, Lorenzo Pieralisi wrote: diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 062fee6..335d9f2 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -453,7 +453,11 @@ void pci_read_bridge_bases(struct pci_bus *child) struct resource *res;

Re: [V5 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency

On 5/22/2015 8:25 PM, Rafael J. Wysocki wrote: On Friday, May 22, 2015 07:15:17 PM Suravee Suthikulanit wrote: On 5/22/2015 6:05 PM, Rafael J. Wysocki wrote: On Friday, May 22, 2015 05:24:15 PM Suravee Suthikulanit wrote: Not sure if this went out earlier. So I am resending. On 5/22/15 16:56

Re: [V5 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency

On 5/22/2015 6:05 PM, Rafael J. Wysocki wrote: On Friday, May 22, 2015 05:24:15 PM Suravee Suthikulanit wrote: Not sure if this went out earlier. So I am resending. On 5/22/15 16:56, Rafael J. Wysocki wrote: diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c index 39c485b..b9657af 100644

Re: [V5 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency

Not sure if this went out earlier. So I am resending. On 5/22/15 16:56, Rafael J. Wysocki wrote: diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c >index 39c485b..b9657af 100644 >--- a/drivers/acpi/glue.c >+++ b/drivers/acpi/glue.c >@@ -13,6 +13,7 @@ > #include > #include > #include

Re: [V5 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency

Not sure if this went out earlier. So I am resending. On 5/22/15 16:56, Rafael J. Wysocki wrote: diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c index 39c485b..b9657af 100644 --- a/drivers/acpi/glue.c +++ b/drivers/acpi/glue.c @@ -13,6 +13,7 @@ #include linux/slab.h #include

Re: [V5 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency

On 5/22/2015 8:25 PM, Rafael J. Wysocki wrote: On Friday, May 22, 2015 07:15:17 PM Suravee Suthikulanit wrote: On 5/22/2015 6:05 PM, Rafael J. Wysocki wrote: On Friday, May 22, 2015 05:24:15 PM Suravee Suthikulanit wrote: Not sure if this went out earlier. So I am resending. On 5/22/15 16:56

Re: [V5 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency

On 5/22/2015 6:05 PM, Rafael J. Wysocki wrote: On Friday, May 22, 2015 05:24:15 PM Suravee Suthikulanit wrote: Not sure if this went out earlier. So I am resending. On 5/22/15 16:56, Rafael J. Wysocki wrote: diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c index 39c485b..b9657af 100644

Re: [V4 PATCH 4/6] device property: Introduces device_dma_is_coherent()

On 5/20/2015 5:28 AM, Will Deacon wrote: On Fri, May 15, 2015 at 10:23:12PM +0100, Suravee Suthikulpanit wrote: Currently, device drivers, which support both OF and ACPI, need to call two separate APIs, of_dma_is_coherent() and acpi_dma_is_coherent()) to determine device coherency attribute.

Re: [V4 PATCH 3/6] pci: Generic function for setting up PCI device DMA coherency

On 5/20/2015 4:34 AM, Catalin Marinas wrote: On Wed, May 20, 2015 at 11:27:54AM +0200, Arnd Bergmann wrote: On Wednesday 20 May 2015 10:24:15 Catalin Marinas wrote: On Sat, May 16, 2015 at 01:59:00AM +0200, Rafael J. Wysocki wrote: On Friday, May 15, 2015 04:23:11 PM Suravee Suthikulpanit

Re: [V4 PATCH 1/6] ACPI / scan: Parse _CCA and setup device coherency

On 5/20/2015 5:01 AM, Catalin Marinas wrote: On Fri, May 15, 2015 at 04:23:09PM -0500, Suravee Suthikulpanit wrote: +static inline bool acpi_dma_is_supported(struct acpi_device *adev) +{ + /** +* Currently, we mainly support _CCA=1 (i.e. is_coherent=1) +* This should be

Re: [V4 PATCH 2/6] arm64 : Introduce support for ACPI _CCA object

On 5/20/2015 5:03 AM, Catalin Marinas wrote: On Fri, May 15, 2015 at 04:23:10PM -0500, Suravee Suthikulpanit wrote: From http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf, section 6.2.17 _CCA states that ARM platforms require ACPI _CCA object to be specified for DMA-cabpable

Re: [V4 PATCH 1/6] ACPI / scan: Parse _CCA and setup device coherency

On 5/20/2015 5:01 AM, Catalin Marinas wrote: On Fri, May 15, 2015 at 04:23:09PM -0500, Suravee Suthikulpanit wrote: +static inline bool acpi_dma_is_supported(struct acpi_device *adev) +{ + /** +* Currently, we mainly support _CCA=1 (i.e. is_coherent=1) +* This should be

Re: [V4 PATCH 3/6] pci: Generic function for setting up PCI device DMA coherency

On 5/20/2015 4:34 AM, Catalin Marinas wrote: On Wed, May 20, 2015 at 11:27:54AM +0200, Arnd Bergmann wrote: On Wednesday 20 May 2015 10:24:15 Catalin Marinas wrote: On Sat, May 16, 2015 at 01:59:00AM +0200, Rafael J. Wysocki wrote: On Friday, May 15, 2015 04:23:11 PM Suravee Suthikulpanit

Re: [V4 PATCH 2/6] arm64 : Introduce support for ACPI _CCA object

On 5/20/2015 5:03 AM, Catalin Marinas wrote: On Fri, May 15, 2015 at 04:23:10PM -0500, Suravee Suthikulpanit wrote: From http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf, section 6.2.17 _CCA states that ARM platforms require ACPI _CCA object to be specified for DMA-cabpable

Re: [V4 PATCH 4/6] device property: Introduces device_dma_is_coherent()

On 5/20/2015 5:28 AM, Will Deacon wrote: On Fri, May 15, 2015 at 10:23:12PM +0100, Suravee Suthikulpanit wrote: Currently, device drivers, which support both OF and ACPI, need to call two separate APIs, of_dma_is_coherent() and acpi_dma_is_coherent()) to determine device coherency attribute.

Re: [V4 PATCH 1/6] ACPI / scan: Parse _CCA and setup device coherency

Hi Rafael, On 5/15/2015 6:53 PM, Rafael J. Wysocki wrote: On Friday, May 15, 2015 04:23:09 PM Suravee Suthikulpanit wrote: [...] diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c index 4bf7559..f6bc438 100644 --- a/drivers/acpi/acpi_platform.c +++

Re: [V4 PATCH 1/6] ACPI / scan: Parse _CCA and setup device coherency

Hi Rafael, On 5/15/2015 6:53 PM, Rafael J. Wysocki wrote: On Friday, May 15, 2015 04:23:09 PM Suravee Suthikulpanit wrote: [...] diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c index 4bf7559..f6bc438 100644 --- a/drivers/acpi/acpi_platform.c +++

Re: [V3 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency

On 5/11/2015 8:20 PM, Rafael J. Wysocki wrote: On Monday, May 11, 2015 05:16:27 PM Catalin Marinas wrote: On Fri, May 08, 2015 at 10:53:59PM +0200, Rafael J. Wysocki wrote: On Thursday, May 07, 2015 07:37:12 PM Suravee Suthikulpanit wrote: diff --git a/drivers/acpi/Kconfig

Re: [V3 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency

On 5/11/2015 8:20 PM, Rafael J. Wysocki wrote: On Monday, May 11, 2015 05:16:27 PM Catalin Marinas wrote: On Fri, May 08, 2015 at 10:53:59PM +0200, Rafael J. Wysocki wrote: On Thursday, May 07, 2015 07:37:12 PM Suravee Suthikulpanit wrote: diff --git a/drivers/acpi/Kconfig

Re: [V2 PATCH 3/5] device property: Introduces device_dma_is_coherent()

Rafael, Any comments on this patch? Thanks, Suravee On 5/5/2015 10:12 AM, Suravee Suthikulpanit wrote: Currently, device drivers, which support both OF and ACPI, need to call two separate APIs, of_dma_is_coherent() and acpi_dma_is_coherent()) to determine device coherency attribute. This

Re: [V2 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency

On 5/6/2015 5:21 PM, Rafael J. Wysocki wrote: > >>+ bool > >>+ > >>+config ACPI_SUPPORT_CCA_ZERO > > > >I guess this means "we support devices that can DMA, but are not coherent". > >right? > >Yes, basically when _CCA=0. So what about ARCH_SUPPORT_CACHE_INCOHERENT_DMA Since this

Re: [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object

On 5/6/2015 5:08 AM, Robin Murphy wrote: [...] +static void __dummy_sync_single_for_cpu(struct device *dev, +dma_addr_t dev_addr, size_t size, +enum dma_data_direction dir) +{ +} + +static void __dummy_sync_single_for_device(struct device *dev, +

Re: [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object

On 5/6/2015 5:08 AM, Robin Murphy wrote: [...] +static void __dummy_sync_single_for_cpu(struct device *dev, +dma_addr_t dev_addr, size_t size, +enum dma_data_direction dir) +{ +} + +static void __dummy_sync_single_for_device(struct device *dev, +

Re: [V2 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency

On 5/6/2015 5:21 PM, Rafael J. Wysocki wrote: + bool + +config ACPI_SUPPORT_CCA_ZERO I guess this means we support devices that can DMA, but are not coherent. right? Yes, basically when _CCA=0. So what about ARCH_SUPPORT_CACHE_INCOHERENT_DMA Since this is specific to ACPI

Re: [V2 PATCH 3/5] device property: Introduces device_dma_is_coherent()

Rafael, Any comments on this patch? Thanks, Suravee On 5/5/2015 10:12 AM, Suravee Suthikulpanit wrote: Currently, device drivers, which support both OF and ACPI, need to call two separate APIs, of_dma_is_coherent() and acpi_dma_is_coherent()) to determine device coherency attribute. This

Re: [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object

On 5/5/2015 10:44 AM, Arnd Bergmann wrote: On Tuesday 05 May 2015 10:12:06 Suravee Suthikulpanit wrote: +struct dma_map_ops dummy_dma_ops = { + .alloc = __dummy_alloc, + .free = __dummy_free, + .mmap = __dummy_mmap, +

Re: [Linaro-acpi] [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object

On 5/5/2015 11:12 AM, Arnd Bergmann wrote: On Tuesday 05 May 2015 11:09:38 Suravee Suthikulanit wrote: However, codes in several places are making use of dma_map_ops without checking if the ops are NULL (i.e. include/asm-generic/dma-mapping-common.h and in arch-specific implementation

Re: [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object

On 5/5/2015 10:44 AM, Arnd Bergmann wrote: On Tuesday 05 May 2015 10:12:06 Suravee Suthikulpanit wrote: +struct dma_map_ops dummy_dma_ops = { + .alloc = __dummy_alloc, + .free = __dummy_free, + .mmap = __dummy_mmap, +

Re: [Linaro-acpi] [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object

On 5/5/2015 11:12 AM, Arnd Bergmann wrote: On Tuesday 05 May 2015 11:09:38 Suravee Suthikulanit wrote: However, codes in several places are making use of dma_map_ops without checking if the ops are NULL (i.e. include/asm-generic/dma-mapping-common.h and in arch-specific implementation

  1   2   3   >