Re: [PATCH v3 0/5] ACPI: DMA ranges management

2017-12-01 Thread Lorenzo Pieralisi 
On Thu, Nov 30, 2017 at 04:43:00PM -0800, Feng Kan wrote:
> On Wed, Nov 29, 2017 at 11:28 PM, Feng Kan  wrote:
> > On Thu, Aug 3, 2017 at 5: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.pieral...@arm.com
> >> v1: 
> >> http://lkml.kernel.org/r/20170720144517.32529-1-lorenzo.pieral...@arm.com
> >>
> >> -- Original cover letter --
> >>
> >> As reported in:
> >>
> >> http://lkml.kernel.org/r/cal85gma_sscwm80tkdkzqee+s1bewzdevdki1kpkmutdrms...@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 
> >> Cc: Hanjun Guo 
> >> Cc: Feng Kan 
> >> Cc: Jon Masters 
> >> Cc: Robert Moore 
> >> Cc: Robin Murphy 
> >> Cc: Zhang Rui 
> >> Cc: "Rafael J. Wysocki" 
> >>
> >> 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(-)
> >>
> >> --
> >> 2.10.0
> >>
> > Lorenzo:
> >
> > A network driver can use pci_set_dma_mask or its like to override what
> > is done with this patch here.
> > Which would result in iova allocation greater than the original _DMA
> > aperture. Should we force
> > the dma_set_mask to not change if an existing mask is already set?
> 
> Let me clarify the question some more, in our system the IOMMU supports only
> 42 bits of address. With your _DMA aperture patch, the initial dma_mask and
> coherent_mask are correctly set by the code. However, the device driver can
> set the dma_mask and coherent mask at a later point which over writes the
> initial setting by your code. In which case, once the iova is exhausted with 
> the
> 32 bit address, it will start seeking more iova address via the
> dma_limit. In this
> case it would fail my system since the iommu.aperture_end is that of 48 bits
> as derived from ias field in  the SMMU.
> 
> Should the dma_limit be the smallest of driver->dma_mask, iommu.aperture_end 
> and
> your _DMA aperture size via ACPI table? Rather than just the
> driver->dma_mask and
> iommu.aperture_end. This will ensure the smallest/correct aperture is used.

IIUC Nate already reported this issue - I will sync with Robin to
check the status of this thread:

https://marc.info/?l=linux-acpi=150108156230455=2

Thanks,
Lorenzo

Re: [PATCH v3 0/5] ACPI: DMA ranges management

2017-12-01 Thread Lorenzo Pieralisi 
On Thu, Nov 30, 2017 at 04:43:00PM -0800, Feng Kan wrote:
> On Wed, Nov 29, 2017 at 11:28 PM, Feng Kan  wrote:
> > On Thu, Aug 3, 2017 at 5: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.pieral...@arm.com
> >> v1: 
> >> http://lkml.kernel.org/r/20170720144517.32529-1-lorenzo.pieral...@arm.com
> >>
> >> -- Original cover letter --
> >>
> >> As reported in:
> >>
> >> http://lkml.kernel.org/r/cal85gma_sscwm80tkdkzqee+s1bewzdevdki1kpkmutdrms...@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 
> >> Cc: Hanjun Guo 
> >> Cc: Feng Kan 
> >> Cc: Jon Masters 
> >> Cc: Robert Moore 
> >> Cc: Robin Murphy 
> >> Cc: Zhang Rui 
> >> Cc: "Rafael J. Wysocki" 
> >>
> >> 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(-)
> >>
> >> --
> >> 2.10.0
> >>
> > Lorenzo:
> >
> > A network driver can use pci_set_dma_mask or its like to override what
> > is done with this patch here.
> > Which would result in iova allocation greater than the original _DMA
> > aperture. Should we force
> > the dma_set_mask to not change if an existing mask is already set?
> 
> Let me clarify the question some more, in our system the IOMMU supports only
> 42 bits of address. With your _DMA aperture patch, the initial dma_mask and
> coherent_mask are correctly set by the code. However, the device driver can
> set the dma_mask and coherent mask at a later point which over writes the
> initial setting by your code. In which case, once the iova is exhausted with 
> the
> 32 bit address, it will start seeking more iova address via the
> dma_limit. In this
> case it would fail my system since the iommu.aperture_end is that of 48 bits
> as derived from ias field in  the SMMU.
> 
> Should the dma_limit be the smallest of driver->dma_mask, iommu.aperture_end 
> and
> your _DMA aperture size via ACPI table? Rather than just the
> driver->dma_mask and
> iommu.aperture_end. This will ensure the smallest/correct aperture is used.

IIUC Nate already reported this issue - I will sync with Robin to
check the status of this thread:

https://marc.info/?l=linux-acpi=150108156230455=2

Thanks,
Lorenzo

Re: [PATCH v3 0/5] ACPI: DMA ranges management

2017-11-30 Thread Feng Kan 
On Wed, Nov 29, 2017 at 11:28 PM, Feng Kan  wrote:
> On Thu, Aug 3, 2017 at 5: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.pieral...@arm.com
>> v1: http://lkml.kernel.org/r/20170720144517.32529-1-lorenzo.pieral...@arm.com
>>
>> -- Original cover letter --
>>
>> As reported in:
>>
>> http://lkml.kernel.org/r/cal85gma_sscwm80tkdkzqee+s1bewzdevdki1kpkmutdrms...@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 
>> Cc: Hanjun Guo 
>> Cc: Feng Kan 
>> Cc: Jon Masters 
>> Cc: Robert Moore 
>> Cc: Robin Murphy 
>> Cc: Zhang Rui 
>> Cc: "Rafael J. Wysocki" 
>>
>> 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(-)
>>
>> --
>> 2.10.0
>>
> Lorenzo:
>
> A network driver can use pci_set_dma_mask or its like to override what
> is done with this patch here.
> Which would result in iova allocation greater than the original _DMA
> aperture. Should we force
> the dma_set_mask to not change if an existing mask is already set?

Let me clarify the question some more, in our system the IOMMU supports only
42 bits of address. With your _DMA aperture patch, the initial dma_mask and
coherent_mask are correctly set by the code. However, the device driver can
set the dma_mask and coherent mask at a later point which over writes the
initial setting by your code. In which case, once the iova is exhausted with the
32 bit address, it will start seeking more iova address via the
dma_limit. In this
case it would fail my system since the iommu.aperture_end is that of 48 bits
as derived from ias field in  the SMMU.

Should the dma_limit be the smallest of driver->dma_mask, iommu.aperture_end and
your _DMA aperture size via ACPI table? Rather than just the
driver->dma_mask and
iommu.aperture_end. This will ensure the smallest/correct aperture is used.

Re: [PATCH v3 0/5] ACPI: DMA ranges management

2017-11-30 Thread Feng Kan 
On Wed, Nov 29, 2017 at 11:28 PM, Feng Kan  wrote:
> On Thu, Aug 3, 2017 at 5: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.pieral...@arm.com
>> v1: http://lkml.kernel.org/r/20170720144517.32529-1-lorenzo.pieral...@arm.com
>>
>> -- Original cover letter --
>>
>> As reported in:
>>
>> http://lkml.kernel.org/r/cal85gma_sscwm80tkdkzqee+s1bewzdevdki1kpkmutdrms...@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 
>> Cc: Hanjun Guo 
>> Cc: Feng Kan 
>> Cc: Jon Masters 
>> Cc: Robert Moore 
>> Cc: Robin Murphy 
>> Cc: Zhang Rui 
>> Cc: "Rafael J. Wysocki" 
>>
>> 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(-)
>>
>> --
>> 2.10.0
>>
> Lorenzo:
>
> A network driver can use pci_set_dma_mask or its like to override what
> is done with this patch here.
> Which would result in iova allocation greater than the original _DMA
> aperture. Should we force
> the dma_set_mask to not change if an existing mask is already set?

Let me clarify the question some more, in our system the IOMMU supports only
42 bits of address. With your _DMA aperture patch, the initial dma_mask and
coherent_mask are correctly set by the code. However, the device driver can
set the dma_mask and coherent mask at a later point which over writes the
initial setting by your code. In which case, once the iova is exhausted with the
32 bit address, it will start seeking more iova address via the
dma_limit. In this
case it would fail my system since the iommu.aperture_end is that of 48 bits
as derived from ias field in  the SMMU.

Should the dma_limit be the smallest of driver->dma_mask, iommu.aperture_end and
your _DMA aperture size via ACPI table? Rather than just the
driver->dma_mask and
iommu.aperture_end. This will ensure the smallest/correct aperture is used.

Re: [PATCH v3 0/5] ACPI: DMA ranges management

2017-11-29 Thread Feng Kan 
On Thu, Aug 3, 2017 at 5: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.pieral...@arm.com
> v1: http://lkml.kernel.org/r/20170720144517.32529-1-lorenzo.pieral...@arm.com
>
> -- Original cover letter --
>
> As reported in:
>
> http://lkml.kernel.org/r/cal85gma_sscwm80tkdkzqee+s1bewzdevdki1kpkmutdrms...@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 
> Cc: Hanjun Guo 
> Cc: Feng Kan 
> Cc: Jon Masters 
> Cc: Robert Moore 
> Cc: Robin Murphy 
> Cc: Zhang Rui 
> Cc: "Rafael J. Wysocki" 
>
> 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(-)
>
> --
> 2.10.0
>
Lorenzo:

A network driver can use pci_set_dma_mask or its like to override what
is done with this patch here.
Which would result in iova allocation greater than the original _DMA
aperture. Should we force
the dma_set_mask to not change if an existing mask is already set?

Re: [PATCH v3 0/5] ACPI: DMA ranges management

2017-11-29 Thread Feng Kan 
On Thu, Aug 3, 2017 at 5: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.pieral...@arm.com
> v1: http://lkml.kernel.org/r/20170720144517.32529-1-lorenzo.pieral...@arm.com
>
> -- Original cover letter --
>
> As reported in:
>
> http://lkml.kernel.org/r/cal85gma_sscwm80tkdkzqee+s1bewzdevdki1kpkmutdrms...@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 
> Cc: Hanjun Guo 
> Cc: Feng Kan 
> Cc: Jon Masters 
> Cc: Robert Moore 
> Cc: Robin Murphy 
> Cc: Zhang Rui 
> Cc: "Rafael J. Wysocki" 
>
> 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(-)
>
> --
> 2.10.0
>
Lorenzo:

A network driver can use pci_set_dma_mask or its like to override what
is done with this patch here.
Which would result in iova allocation greater than the original _DMA
aperture. Should we force
the dma_set_mask to not change if an existing mask is already set?

Re: [PATCH v3 0/5] ACPI: DMA ranges management

2017-08-14 Thread Feng Kan 
On Thu, Aug 3, 2017 at 5: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.pieral...@arm.com
> v1: http://lkml.kernel.org/r/20170720144517.32529-1-lorenzo.pieral...@arm.com
>
> -- Original cover letter --
>
> As reported in:
>
> http://lkml.kernel.org/r/cal85gma_sscwm80tkdkzqee+s1bewzdevdki1kpkmutdrms...@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 
> Cc: Hanjun Guo 
> Cc: Feng Kan 
> Cc: Jon Masters 
> Cc: Robert Moore 
> Cc: Robin Murphy 
> Cc: Zhang Rui 
> Cc: "Rafael J. Wysocki" 
>
> 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(-)
>
> --
> 2.10.0
>
Works on XGene.
Tested-by: Feng Kan

Re: [PATCH v3 0/5] ACPI: DMA ranges management

2017-08-14 Thread Feng Kan 
On Thu, Aug 3, 2017 at 5: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.pieral...@arm.com
> v1: http://lkml.kernel.org/r/20170720144517.32529-1-lorenzo.pieral...@arm.com
>
> -- Original cover letter --
>
> As reported in:
>
> http://lkml.kernel.org/r/cal85gma_sscwm80tkdkzqee+s1bewzdevdki1kpkmutdrms...@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 
> Cc: Hanjun Guo 
> Cc: Feng Kan 
> Cc: Jon Masters 
> Cc: Robert Moore 
> Cc: Robin Murphy 
> Cc: Zhang Rui 
> Cc: "Rafael J. Wysocki" 
>
> 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(-)
>
> --
> 2.10.0
>
Works on XGene.
Tested-by: Feng Kan

Re: [PATCH v3 0/5] ACPI: DMA ranges management

2017-08-11 Thread Lorenzo Pieralisi 
On Wed, Aug 09, 2017 at 04:14:43PM -0500, Jeremy Linton wrote:
> Hi,
> 
> Better late than never I guess..
> 
> On 08/03/2017 07: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.pieral...@arm.com
> >v1: http://lkml.kernel.org/r/20170720144517.32529-1-lorenzo.pieral...@arm.com
> >
> >-- Original cover letter --
> >
> >As reported in:
> >
> >http://lkml.kernel.org/r/cal85gma_sscwm80tkdkzqee+s1bewzdevdki1kpkmutdrms...@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 
> >Cc: Hanjun Guo 
> >Cc: Feng Kan 
> >Cc: Jon Masters 
> >Cc: Robert Moore 
> >Cc: Robin Murphy 
> >Cc: Zhang Rui 
> >Cc: "Rafael J. Wysocki" 
> >
> >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(-)
> 
> Ok, despite being merged already I think its worthwhile to say that
> I've been testing this with:
> 
> Method(_DMA, 0, Serialized)
> {
>   Return (ResourceTemplate()
>   {
>   QWORDMemory(
>   ResourceConsumer,

I asked to update the ACPI specifications because this should be
ResourceProducer, we need an errata to sort this out before it
becomes a problem.

>   PosDecode,  // _DEC
>   MinFixed,   // _MIF
>   MaxFixed,   // _MAF
>   Prefetchable,   // _MEM
>   ReadWrite,  // _RW
>   0,  // _GRA
>   0x1000, // _MIN
>   0x1fff, // _MAX
>   0x0,// _TRA
>   0x1000, // _LEN
>   ,
>   ,
>   ,
>   )
>   })
> } // Method(_DMA)
> 
> (and a couple minor variations)
> 
> and a fair number of debug statements sprinkled around to verify
> that the IOVAs are appropriately limited. So I don't see anything
> wrong with the code and it appears to work and the devices behind a
> bridge limited like this continue to work as long as sane values are
> placed in the min/max/len fields.
> 
> Thanks,
> 
> Tested-by: Jeremy Linton 

Thank you very much Jeremy for testing it, appreciated please let me
know if you spot anything wrong with it on the machines you are
running tests on.

Lorenzo

Re: [PATCH v3 0/5] ACPI: DMA ranges management

2017-08-11 Thread Lorenzo Pieralisi 
On Wed, Aug 09, 2017 at 04:14:43PM -0500, Jeremy Linton wrote:
> Hi,
> 
> Better late than never I guess..
> 
> On 08/03/2017 07: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.pieral...@arm.com
> >v1: http://lkml.kernel.org/r/20170720144517.32529-1-lorenzo.pieral...@arm.com
> >
> >-- Original cover letter --
> >
> >As reported in:
> >
> >http://lkml.kernel.org/r/cal85gma_sscwm80tkdkzqee+s1bewzdevdki1kpkmutdrms...@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 
> >Cc: Hanjun Guo 
> >Cc: Feng Kan 
> >Cc: Jon Masters 
> >Cc: Robert Moore 
> >Cc: Robin Murphy 
> >Cc: Zhang Rui 
> >Cc: "Rafael J. Wysocki" 
> >
> >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(-)
> 
> Ok, despite being merged already I think its worthwhile to say that
> I've been testing this with:
> 
> Method(_DMA, 0, Serialized)
> {
>   Return (ResourceTemplate()
>   {
>   QWORDMemory(
>   ResourceConsumer,

I asked to update the ACPI specifications because this should be
ResourceProducer, we need an errata to sort this out before it
becomes a problem.

>   PosDecode,  // _DEC
>   MinFixed,   // _MIF
>   MaxFixed,   // _MAF
>   Prefetchable,   // _MEM
>   ReadWrite,  // _RW
>   0,  // _GRA
>   0x1000, // _MIN
>   0x1fff, // _MAX
>   0x0,// _TRA
>   0x1000, // _LEN
>   ,
>   ,
>   ,
>   )
>   })
> } // Method(_DMA)
> 
> (and a couple minor variations)
> 
> and a fair number of debug statements sprinkled around to verify
> that the IOVAs are appropriately limited. So I don't see anything
> wrong with the code and it appears to work and the devices behind a
> bridge limited like this continue to work as long as sane values are
> placed in the min/max/len fields.
> 
> Thanks,
> 
> Tested-by: Jeremy Linton 

Thank you very much Jeremy for testing it, appreciated please let me
know if you spot anything wrong with it on the machines you are
running tests on.

Lorenzo

Re: [PATCH v3 0/5] ACPI: DMA ranges management

2017-08-09 Thread Jeremy Linton 

Hi,

Better late than never I guess..

On 08/03/2017 07: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.pieral...@arm.com
v1: http://lkml.kernel.org/r/20170720144517.32529-1-lorenzo.pieral...@arm.com

-- Original cover letter --

As reported in:

http://lkml.kernel.org/r/cal85gma_sscwm80tkdkzqee+s1bewzdevdki1kpkmutdrms...@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 
Cc: Hanjun Guo 
Cc: Feng Kan 
Cc: Jon Masters 
Cc: Robert Moore 
Cc: Robin Murphy 
Cc: Zhang Rui 
Cc: "Rafael J. Wysocki" 

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(-)


Ok, despite being merged already I think its worthwhile to say that I've 
been testing this with:


Method(_DMA, 0, Serialized)
{
Return (ResourceTemplate()
{
QWORDMemory(
ResourceConsumer,
PosDecode,  // _DEC
MinFixed,   // _MIF
MaxFixed,   // _MAF
Prefetchable,   // _MEM
ReadWrite,  // _RW
0,  // _GRA
0x1000, // _MIN
0x1fff, // _MAX
0x0,// _TRA
0x1000, // _LEN
,
,
,
)
})
} // Method(_DMA)

(and a couple minor variations)

and a fair number of debug statements sprinkled around to verify that 
the IOVAs are appropriately limited. So I don't see anything wrong with 
the code and it appears to work and the devices behind a bridge limited 
like this continue to work as long as sane values are placed in the 
min/max/len fields.


Thanks,

Tested-by: Jeremy Linton

Re: [PATCH v3 0/5] ACPI: DMA ranges management

2017-08-09 Thread Jeremy Linton 

Hi,

Better late than never I guess..

On 08/03/2017 07: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.pieral...@arm.com
v1: http://lkml.kernel.org/r/20170720144517.32529-1-lorenzo.pieral...@arm.com

-- Original cover letter --

As reported in:

http://lkml.kernel.org/r/cal85gma_sscwm80tkdkzqee+s1bewzdevdki1kpkmutdrms...@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 
Cc: Hanjun Guo 
Cc: Feng Kan 
Cc: Jon Masters 
Cc: Robert Moore 
Cc: Robin Murphy 
Cc: Zhang Rui 
Cc: "Rafael J. Wysocki" 

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(-)


Ok, despite being merged already I think its worthwhile to say that I've 
been testing this with:


Method(_DMA, 0, Serialized)
{
Return (ResourceTemplate()
{
QWORDMemory(
ResourceConsumer,
PosDecode,  // _DEC
MinFixed,   // _MIF
MaxFixed,   // _MAF
Prefetchable,   // _MEM
ReadWrite,  // _RW
0,  // _GRA
0x1000, // _MIN
0x1fff, // _MAX
0x0,// _TRA
0x1000, // _LEN
,
,
,
)
})
} // Method(_DMA)

(and a couple minor variations)

and a fair number of debug statements sprinkled around to verify that 
the IOVAs are appropriately limited. So I don't see anything wrong with 
the code and it appears to work and the devices behind a bridge limited 
like this continue to work as long as sane values are placed in the 
min/max/len fields.


Thanks,

Tested-by: Jeremy Linton

Re: [PATCH v3 0/5] ACPI: DMA ranges management

2017-08-03 Thread Robin Murphy 
On 03/08/17 16:45, Nate Watterson wrote:
> 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.pieral...@arm.com
>> v1:
>> http://lkml.kernel.org/r/20170720144517.32529-1-lorenzo.pieral...@arm.com
>>
>> -- Original cover letter --
>>
>> As reported in:
>>
>> http://lkml.kernel.org/r/cal85gma_sscwm80tkdkzqee+s1bewzdevdki1kpkmutdrms...@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 
>> Cc: Hanjun Guo 
>> Cc: Feng Kan 
>> Cc: Jon Masters 
>> Cc: Robert Moore 
>> Cc: Robin Murphy 
>> Cc: Zhang Rui 
>> Cc: "Rafael J. Wysocki" 
>>
>> 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 
> 
> 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.

As far as I understand ACPI, all addresses are at most 64-bit. Thus the
only valid DMA range of size 2^64 would be one with a minimum of 0 and
no offset, and that can already be described by the simple absence of a
_DMA object.

Robin.

> 
> QWORDMemory(
> ResourceConsumer,
> PosDecode,   // _DEC
> MinFixed,// _MIF
> MaxFixed,// _MAF
> Prefetchable,// _MEM
> ReadWrite,   // _RW
> 0,   // _GRA
> 0x1000,   // _MIN
> 0x,   // _MAX
> 0x0,  // _TRA
> 0xf000,   // _LEN
> ,
> ,
> ,
> )
> 
> -Nate
>

Re: [PATCH v3 0/5] ACPI: DMA ranges management

2017-08-03 Thread Robin Murphy 
On 03/08/17 16:45, Nate Watterson wrote:
> 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.pieral...@arm.com
>> v1:
>> http://lkml.kernel.org/r/20170720144517.32529-1-lorenzo.pieral...@arm.com
>>
>> -- Original cover letter --
>>
>> As reported in:
>>
>> http://lkml.kernel.org/r/cal85gma_sscwm80tkdkzqee+s1bewzdevdki1kpkmutdrms...@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 
>> Cc: Hanjun Guo 
>> Cc: Feng Kan 
>> Cc: Jon Masters 
>> Cc: Robert Moore 
>> Cc: Robin Murphy 
>> Cc: Zhang Rui 
>> Cc: "Rafael J. Wysocki" 
>>
>> 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 
> 
> 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.

As far as I understand ACPI, all addresses are at most 64-bit. Thus the
only valid DMA range of size 2^64 would be one with a minimum of 0 and
no offset, and that can already be described by the simple absence of a
_DMA object.

Robin.

> 
> QWORDMemory(
> ResourceConsumer,
> PosDecode,   // _DEC
> MinFixed,// _MIF
> MaxFixed,// _MAF
> Prefetchable,// _MEM
> ReadWrite,   // _RW
> 0,   // _GRA
> 0x1000,   // _MIN
> 0x,   // _MAX
> 0x0,  // _TRA
> 0xf000,   // _LEN
> ,
> ,
> ,
> )
> 
> -Nate
>

Re: [PATCH v3 0/5] ACPI: DMA ranges management

2017-08-03 Thread Nate Watterson 

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.pieral...@arm.com
v1: http://lkml.kernel.org/r/20170720144517.32529-1-lorenzo.pieral...@arm.com

-- Original cover letter --

As reported in:

http://lkml.kernel.org/r/cal85gma_sscwm80tkdkzqee+s1bewzdevdki1kpkmutdrms...@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 
Cc: Hanjun Guo 
Cc: Feng Kan 
Cc: Jon Masters 
Cc: Robert Moore 
Cc: Robin Murphy 
Cc: Zhang Rui 
Cc: "Rafael J. Wysocki" 

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 

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
0x,   // _MAX
0x0,  // _TRA
0xf000,   // _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.

Re: [PATCH v3 0/5] ACPI: DMA ranges management

2017-08-03 Thread Nate Watterson 

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.pieral...@arm.com
v1: http://lkml.kernel.org/r/20170720144517.32529-1-lorenzo.pieral...@arm.com

-- Original cover letter --

As reported in:

http://lkml.kernel.org/r/cal85gma_sscwm80tkdkzqee+s1bewzdevdki1kpkmutdrms...@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 
Cc: Hanjun Guo 
Cc: Feng Kan 
Cc: Jon Masters 
Cc: Robert Moore 
Cc: Robin Murphy 
Cc: Zhang Rui 
Cc: "Rafael J. Wysocki" 

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 

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
0x,   // _MAX
0x0,  // _TRA
0xf000,   // _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.

Re: [PATCH v3 0/5] ACPI: DMA ranges management

2017-08-03 Thread Will Deacon 
On Thu, Aug 03, 2017 at 01:32:34PM +0100, 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.pieral...@arm.com
> v1: http://lkml.kernel.org/r/20170720144517.32529-1-lorenzo.pieral...@arm.com

For the arm64 bits:

Acked-by: Will Deacon 

Will

Re: [PATCH v3 0/5] ACPI: DMA ranges management

2017-08-03 Thread Will Deacon 
On Thu, Aug 03, 2017 at 01:32:34PM +0100, 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.pieral...@arm.com
> v1: http://lkml.kernel.org/r/20170720144517.32529-1-lorenzo.pieral...@arm.com

For the arm64 bits:

Acked-by: Will Deacon 

Will

Re: [PATCH v3 0/5] ACPI: DMA ranges management

2017-08-03 Thread Hanjun Guo 
On 2017/8/3 20:32, 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.pieral...@arm.com
> v1: http://lkml.kernel.org/r/20170720144517.32529-1-lorenzo.pieral...@arm.com
>
> -- Original cover letter --
>
> As reported in:
>
> http://lkml.kernel.org/r/cal85gma_sscwm80tkdkzqee+s1bewzdevdki1kpkmutdrms...@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 
> Cc: Hanjun Guo 
> Cc: Feng Kan 
> Cc: Jon Masters 
> Cc: Robert Moore 
> Cc: Robin Murphy 
> Cc: Zhang Rui 
> Cc: "Rafael J. Wysocki" 

with the whole patch set:

Reviewed-by: Hanjun Guo 

I tested this patch set with no _DMA in DSDT but with named
component in IORT table, seeing no regressions on D05.

Thanks
Hanjun

Re: [PATCH v3 0/5] ACPI: DMA ranges management

2017-08-03 Thread Hanjun Guo 
On 2017/8/3 20:32, 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.pieral...@arm.com
> v1: http://lkml.kernel.org/r/20170720144517.32529-1-lorenzo.pieral...@arm.com
>
> -- Original cover letter --
>
> As reported in:
>
> http://lkml.kernel.org/r/cal85gma_sscwm80tkdkzqee+s1bewzdevdki1kpkmutdrms...@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 
> Cc: Hanjun Guo 
> Cc: Feng Kan 
> Cc: Jon Masters 
> Cc: Robert Moore 
> Cc: Robin Murphy 
> Cc: Zhang Rui 
> Cc: "Rafael J. Wysocki" 

with the whole patch set:

Reviewed-by: Hanjun Guo 

I tested this patch set with no _DMA in DSDT but with named
component in IORT table, seeing no regressions on D05.

Thanks
Hanjun