All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nate Watterson <nwatters@codeaurora.org>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	linux-acpi@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Will Deacon <will.deacon@arm.com>,
	Hanjun Guo <hanjun.guo@linaro.org>, Feng Kan <fkan@apm.com>,
	Jon Masters <jcm@redhat.com>,
	Robert Moore <robert.moore@intel.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Zhang Rui <rui.zhang@intel.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>
Subject: Re: [PATCH v3 0/5] ACPI: DMA ranges management
Date: Thu, 3 Aug 2017 11:45:04 -0400	[thread overview]
Message-ID: <3ccac0b0-dd5a-6a70-f253-99f038f69b8c@codeaurora.org> (raw)
In-Reply-To: <20170803123239.11359-1-lorenzo.pieralisi@arm.com>

Hi Lorenzo,

On 8/3/2017 8:32 AM, Lorenzo Pieralisi wrote:
> This patch series is v3 of a previous posting:
> 
> v2->v3:
> 	- Fixed DMA masks computation
>          - Fixed size computation overflow in acpi_dma_get_range()
> 
> v1->v2:
> 	- Reworked acpi_dma_get_range() flow and logs
> 	- Added IORT named component address limits
> 	- Renamed acpi_dev_get_resources() helper function
> 	- Rebased against v4.13-rc3
> 
> v2: http://lkml.kernel.org/r/20170731152323.32488-1-lorenzo.pieralisi@arm.com
> v1: http://lkml.kernel.org/r/20170720144517.32529-1-lorenzo.pieralisi@arm.com
> 
> -- Original cover letter --
> 
> As reported in:
> 
> http://lkml.kernel.org/r/CAL85gmA_SSCwM80TKdkZqEe+S1beWzDEvdki1kpkmUTDRmSP7g@mail.gmail.com
> 
> the bus connecting devices to an IOMMU bus can be smaller in size than
> the IOMMU input address bits which results in devices DMA HW bugs in
> particular related to IOVA allocation (ie chopping of higher address
> bits owing to system bus HW capabilities mismatch with the IOMMU).
> 
> Fortunately this problem can be solved through an already present but never
> used ACPI 6.2 firmware bindings (ie _DMA object) allowing to define the DMA
> window for a specific bus in ACPI and therefore all upstream devices
> connected to it.
> 
> This small patch series enables _DMA parsing in ACPI core code and
> use it in ACPI IORT code in order to detect DMA ranges for devices and
> update their data structures to make them work with their related DMA
> addressing restrictions.
> 
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Feng Kan <fkan@apm.com>
> Cc: Jon Masters <jcm@redhat.com>
> Cc: Robert Moore <robert.moore@intel.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Zhang Rui <rui.zhang@intel.com>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> 
> Lorenzo Pieralisi (5):
>    ACPICA: resource_mgr: Allow _DMA method in walk resources
>    ACPI: Make acpi_dev_get_resources() method agnostic
>    ACPI: Introduce DMA ranges parsing
>    ACPI: Make acpi_dma_configure() DMA regions aware
>    ACPI/IORT: Add IORT named component memory address limits
> 
>   drivers/acpi/acpica/rsxface.c |  7 ++--
>   drivers/acpi/arm64/iort.c     | 57 ++++++++++++++++++++++++++-
>   drivers/acpi/resource.c       | 82 +++++++++++++++++++++++++++++---------
>   drivers/acpi/scan.c           | 91 +++++++++++++++++++++++++++++++++++++++----
>   include/acpi/acnames.h        |  1 +
>   include/acpi/acpi_bus.h       |  2 +
>   include/linux/acpi.h          |  8 ++++
>   include/linux/acpi_iort.h     |  5 ++-
>   8 files changed, 219 insertions(+), 34 deletions(-)
> 

I tested with named components and with _DMA objects at a variety of
sizes and verified the configured masks matched the expected values.

Tested-by: Nate Watterson <nwatters@codeaurora.org>

One general question I had while testing the patch is whether it is
possible to define a complete 64-bit range using the _DMA method. For
instance, to get a 64-bit dma_mask I had to use a non-zero MIN value
so that LEN would not overflow.

QWORDMemory(
	ResourceConsumer,
	PosDecode,       // _DEC
	MinFixed,        // _MIF
	MaxFixed,        // _MAF
	Prefetchable,    // _MEM
	ReadWrite,       // _RW
	0,               // _GRA
	0x1000,               // _MIN
	0xffffffffffffffff,   // _MAX
	0x0,                  // _TRA
	0xfffffffffffff000,   // _LEN
	,
	,
	,
)

-Nate

-- 
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

WARNING: multiple messages have this Message-ID (diff)
From: nwatters@codeaurora.org (Nate Watterson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 0/5] ACPI: DMA ranges management
Date: Thu, 3 Aug 2017 11:45:04 -0400	[thread overview]
Message-ID: <3ccac0b0-dd5a-6a70-f253-99f038f69b8c@codeaurora.org> (raw)
In-Reply-To: <20170803123239.11359-1-lorenzo.pieralisi@arm.com>

Hi Lorenzo,

On 8/3/2017 8:32 AM, Lorenzo Pieralisi wrote:
> This patch series is v3 of a previous posting:
> 
> v2->v3:
> 	- Fixed DMA masks computation
>          - Fixed size computation overflow in acpi_dma_get_range()
> 
> v1->v2:
> 	- Reworked acpi_dma_get_range() flow and logs
> 	- Added IORT named component address limits
> 	- Renamed acpi_dev_get_resources() helper function
> 	- Rebased against v4.13-rc3
> 
> v2: http://lkml.kernel.org/r/20170731152323.32488-1-lorenzo.pieralisi at arm.com
> v1: http://lkml.kernel.org/r/20170720144517.32529-1-lorenzo.pieralisi at arm.com
> 
> -- Original cover letter --
> 
> As reported in:
> 
> http://lkml.kernel.org/r/CAL85gmA_SSCwM80TKdkZqEe+S1beWzDEvdki1kpkmUTDRmSP7g at mail.gmail.com
> 
> the bus connecting devices to an IOMMU bus can be smaller in size than
> the IOMMU input address bits which results in devices DMA HW bugs in
> particular related to IOVA allocation (ie chopping of higher address
> bits owing to system bus HW capabilities mismatch with the IOMMU).
> 
> Fortunately this problem can be solved through an already present but never
> used ACPI 6.2 firmware bindings (ie _DMA object) allowing to define the DMA
> window for a specific bus in ACPI and therefore all upstream devices
> connected to it.
> 
> This small patch series enables _DMA parsing in ACPI core code and
> use it in ACPI IORT code in order to detect DMA ranges for devices and
> update their data structures to make them work with their related DMA
> addressing restrictions.
> 
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Feng Kan <fkan@apm.com>
> Cc: Jon Masters <jcm@redhat.com>
> Cc: Robert Moore <robert.moore@intel.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Zhang Rui <rui.zhang@intel.com>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> 
> Lorenzo Pieralisi (5):
>    ACPICA: resource_mgr: Allow _DMA method in walk resources
>    ACPI: Make acpi_dev_get_resources() method agnostic
>    ACPI: Introduce DMA ranges parsing
>    ACPI: Make acpi_dma_configure() DMA regions aware
>    ACPI/IORT: Add IORT named component memory address limits
> 
>   drivers/acpi/acpica/rsxface.c |  7 ++--
>   drivers/acpi/arm64/iort.c     | 57 ++++++++++++++++++++++++++-
>   drivers/acpi/resource.c       | 82 +++++++++++++++++++++++++++++---------
>   drivers/acpi/scan.c           | 91 +++++++++++++++++++++++++++++++++++++++----
>   include/acpi/acnames.h        |  1 +
>   include/acpi/acpi_bus.h       |  2 +
>   include/linux/acpi.h          |  8 ++++
>   include/linux/acpi_iort.h     |  5 ++-
>   8 files changed, 219 insertions(+), 34 deletions(-)
> 

I tested with named components and with _DMA objects at a variety of
sizes and verified the configured masks matched the expected values.

Tested-by: Nate Watterson <nwatters@codeaurora.org>

One general question I had while testing the patch is whether it is
possible to define a complete 64-bit range using the _DMA method. For
instance, to get a 64-bit dma_mask I had to use a non-zero MIN value
so that LEN would not overflow.

QWORDMemory(
	ResourceConsumer,
	PosDecode,       // _DEC
	MinFixed,        // _MIF
	MaxFixed,        // _MAF
	Prefetchable,    // _MEM
	ReadWrite,       // _RW
	0,               // _GRA
	0x1000,               // _MIN
	0xffffffffffffffff,   // _MAX
	0x0,                  // _TRA
	0xfffffffffffff000,   // _LEN
	,
	,
	,
)

-Nate

-- 
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

  parent reply	other threads:[~2017-08-03 15:45 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-03 12:32 [PATCH v3 0/5] ACPI: DMA ranges management Lorenzo Pieralisi
2017-08-03 12:32 ` Lorenzo Pieralisi
2017-08-03 12:32 ` [PATCH v3 1/5] ACPICA: resource_mgr: Allow _DMA method in walk resources Lorenzo Pieralisi
2017-08-03 12:32   ` Lorenzo Pieralisi
2017-08-03 12:32 ` [PATCH v3 2/5] ACPI: Make acpi_dev_get_resources() method agnostic Lorenzo Pieralisi
2017-08-03 12:32   ` Lorenzo Pieralisi
2017-08-03 12:32 ` [PATCH v3 3/5] ACPI: Introduce DMA ranges parsing Lorenzo Pieralisi
2017-08-03 12:32   ` Lorenzo Pieralisi
2017-08-06  5:12   ` kbuild test robot
2017-08-06  5:12     ` kbuild test robot
2017-08-06  5:12     ` kbuild test robot
2017-08-06  9:42     ` Lorenzo Pieralisi
2017-08-06  9:42       ` Lorenzo Pieralisi
2017-08-06 11:21       ` Rafael J. Wysocki
2017-08-06 11:21         ` Rafael J. Wysocki
2017-08-06 11:21         ` Rafael J. Wysocki
2017-08-03 12:32 ` [PATCH v3 4/5] ACPI: Make acpi_dma_configure() DMA regions aware Lorenzo Pieralisi
2017-08-03 12:32   ` Lorenzo Pieralisi
2017-08-03 12:32 ` [PATCH v3 5/5] ACPI/IORT: Add IORT named component memory address limits Lorenzo Pieralisi
2017-08-03 12:32   ` Lorenzo Pieralisi
2017-08-03 13:25 ` [PATCH v3 0/5] ACPI: DMA ranges management Hanjun Guo
2017-08-03 13:25   ` Hanjun Guo
2017-08-03 13:25   ` Hanjun Guo
2017-08-03 15:16 ` Will Deacon
2017-08-03 15:16   ` Will Deacon
2017-08-03 15:45 ` Nate Watterson [this message]
2017-08-03 15:45   ` Nate Watterson
2017-08-03 17:21   ` Robin Murphy
2017-08-03 17:21     ` Robin Murphy
2017-08-09 21:14 ` Jeremy Linton
2017-08-09 21:14   ` Jeremy Linton
2017-08-11  8:52   ` Lorenzo Pieralisi
2017-08-11  8:52     ` Lorenzo Pieralisi
2017-08-14 18:41 ` Feng Kan
2017-08-14 18:41   ` Feng Kan
2017-08-14 18:41   ` Feng Kan
2017-11-30  7:28 ` Feng Kan
2017-11-30  7:28   ` Feng Kan
2017-11-30  7:28   ` Feng Kan
2017-12-01  0:43   ` Feng Kan
2017-12-01  0:43     ` Feng Kan
2017-12-01  0:43     ` Feng Kan
2017-12-01 10:39     ` Lorenzo Pieralisi
2017-12-01 10:39       ` Lorenzo Pieralisi
2017-12-01 10:39       ` Lorenzo Pieralisi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3ccac0b0-dd5a-6a70-f253-99f038f69b8c@codeaurora.org \
    --to=nwatters@codeaurora.org \
    --cc=fkan@apm.com \
    --cc=hanjun.guo@linaro.org \
    --cc=jcm@redhat.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=rjw@rjwysocki.net \
    --cc=robert.moore@intel.com \
    --cc=robin.murphy@arm.com \
    --cc=rui.zhang@intel.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.