Rafael, Mark, Suravee,
On Mon, Nov 21, 2016 at 10:01:39AM +, Lorenzo Pieralisi wrote:
> On DT based systems, the of_dma_configure() API implements DMA
> configuration for a given device. On ACPI systems an API equivalent to
> of_dma_configure() is missing which implies that it is
On Sat, Dec 03, 2016 at 03:11:09AM +0100, Rafael J. Wysocki wrote:
> On Fri, Dec 2, 2016 at 4:38 PM, Lorenzo Pieralisi
> wrote:
> > Rafael, Mark, Suravee,
> >
> > On Mon, Nov 21, 2016 at 10:01:39AM +, Lorenzo Pieralisi wrote:
> >> On DT based systems, the of_d
On Mon, Dec 05, 2016 at 03:22:02PM +0530, Sricharan wrote:
> Hi Lorenzo,
>
> >
> >On Sat, Dec 3, 2016 at 11:39 AM, Lorenzo Pieralisi
> > wrote:
> >> On Sat, Dec 03, 2016 at 03:11:09AM +0100, Rafael J. Wysocki wrote:
> >>> On Fri, Dec 2, 20
to a NOP on x86/ia64 systems, restoring the
default expected behaviour on x86/ia64 systems and keeping DMA default
masks set-up on IORT based (ie ARM) arch configurations.
Signed-off-by: Lorenzo Pieralisi
Cc: Will Deacon
Cc: Hanjun Guo
Cc: Bjorn Helgaas
Cc: Robin Murphy
Cc: Tomasz Nowicki
Cc
Hi Joerg,
On Mon, Dec 05, 2016 at 11:18:56PM +0100, Rafael J. Wysocki wrote:
> On Mon, Dec 5, 2016 at 1:26 PM, Lorenzo Pieralisi
> wrote:
> > The introduction of acpi_dma_configure() allows to configure DMA
> > and related IOMMU for any device that is DMA capable. To achiev
to a NOP on x86/ia64 systems, restoring the
default expected behaviour on x86/ia64 systems and keeping DMA default
masks set-up on IORT based (ie ARM) arch configurations.
Signed-off-by: Lorenzo Pieralisi
Acked-by: Will Deacon
Acked-by: Rafael J. Wysocki
Reviewed-by: Hanjun Guo
Tested-by
On Tue, Dec 06, 2016 at 02:24:48PM +0100, Joerg Roedel wrote:
> Hi Lorenzo,
>
> On Tue, Dec 06, 2016 at 09:37:10AM +, Lorenzo Pieralisi wrote:
> > I can apply Rafael and Hanjun's tags and resend a v2 to you if you
> > prefer, it would be great if you could apply t
mplete the interface rework.
Signed-off-by: Lorenzo Pieralisi
Cc: Matthias Brugger
Cc: Will Deacon
Cc: Robin Murphy
Cc: Joerg Roedel
Cc: Marek Szyprowski
---
Exynos, msm and mtk code compile tested only owing to lack of
test platforms, I would appreciate some help in testing this
patch on those
On Thu, Jan 05, 2017 at 02:04:37PM +0530, Sricharan wrote:
> Hi Robin/Lorenzo,
>
> >Hi Robin,Lorenzo,
> >
> >>On Wed, Nov 30, 2016 at 04:42:27PM +, Robin Murphy wrote:
> >>> On 30/11/16 16:17, Lorenzo Pieralisi wrote:
> >>> > Sricharan,
On Thu, Jan 05, 2017 at 01:52:29PM +, Robin Murphy wrote:
[...]
> > Question: I had a look into this and instead of fiddling about with the
> > linker script entries in ACPI (ie IORT_ACPI_DECLARE - which I hope this
> > patchset would help remove entirely), I think that the only check we
> >
On Thu, Jan 05, 2017 at 08:21:53PM +0530, Sricharan wrote:
> Hi,
>
> [...]
>
> >>>
> >>> With the thinking of taking this series through, would it be fine if i
> >>> cleanup the pci configure hanging outside and push it in to
> >>> of/acpi_iommu configure respectively ? This time with all neeeded
Hi Sricharan,
On Fri, Jan 06, 2017 at 04:24:00PM +, Lorenzo Pieralisi wrote:
> On Thu, Jan 05, 2017 at 08:21:53PM +0530, Sricharan wrote:
> > Hi,
> >
> > [...]
> >
> > >>>
> > >>> With the thinking of taking this series through
On Thu, Jan 19, 2017 at 08:35:54PM +0530, Sricharan R wrote:
> With all the DT based devices getting their dma ops configured
> during probe time to have the right iommu setup, let us do the
> same for acpi based devices as well.
>
> Configuring DMA ops at probe time will allow deferring device pr
On Thu, Jan 19, 2017 at 08:35:49PM +0530, Sricharan R wrote:
> Configuring DMA ops at probe time will allow deferring device probe when
> the IOMMU isn't available yet. The dma_configure for the device is
> now called from the generic device_attach callback just before the
> bus/driver probe is cal
On Thu, Jan 19, 2017 at 08:35:52PM +0530, Sricharan R wrote:
> From: Robin Murphy
>
> Now that the appropriate ordering is enforced via profe-deferral of
> masters in core code, rip it all out and bask in the simplicity.
>
> Signed-off-by: Robin Murphy
> [Sricharan: Rebased on top of ACPI IORT
On Thu, Jan 19, 2017 at 05:49:58PM +, Robin Murphy wrote:
> On 19/01/17 15:05, Sricharan R wrote:
> > Configuring DMA ops at probe time will allow deferring device probe when
> > the IOMMU isn't available yet. The dma_configure for the device is
> > now called from the generic device_attach cal
[+bjorn]
On Sat, Jan 21, 2017 at 12:45:43AM +0530, Sricharan R wrote:
> Configuring DMA ops at probe time will allow deferring device probe when
> the IOMMU isn't available yet. The dma_configure for the device is
> now called from the generic device_attach callback just before the
> bus/driver pr
!dev->iommu_group) {
> + int err = ops->add_device(dev);
> +
> + if (err)
> + ops = ERR_PTR(err);
> + }
I think there is nothing ACPI specific in this add_device() replay
path, so there is room for further DT/ACPI consolidation
e:
> >>> > On 2017-01-30 08:59, Sinan Kaya wrote:
> >>> >> On 1/30/2017 7:22 AM, Robin Murphy wrote:
> >>> >>> On 29/01/17 17:53, Sinan Kaya wrote:
> >>> >>>> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
> >>>
On Mon, Jan 30, 2017 at 03:03:06PM -0500, Sinan Kaya wrote:
> On 1/30/2017 11:51 AM, Lorenzo Pieralisi wrote:
> > On Mon, Jan 30, 2017 at 10:46:39AM -0500, Sinan Kaya wrote:
> >> On 1/30/2017 9:54 AM, Nate Watterson wrote:
> >>> On 2017-01-30 09:38, Will Deacon wrot
On Fri, Mar 24, 2017 at 09:27:51AM +, Shameerali Kolothum Thodi wrote:
[...]
> @@ -107,7 +107,7 @@ int of_dma_configure(struct device *dev, struct
> device_node *np)
> ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
> if (ret < 0) {
> dma_addr = offset = 0;
>
On Mon, Mar 27, 2017 at 05:18:15PM +0100, Robin Murphy wrote:
[...]
> >> [ 145.212351] iommu: Adding device :81:10.0 to group 5
> >> [ 145.212367] ixgbevf :81:10.0: 0x0 0x1, 0x0 0x,
> >> 0x 0x
> >> [ 145.213261] ixgbevf :81:10.0: enabling device
nt Pinchart [1]
> >
> > [1] http://lists.linuxfoundation.org/pipermail/iommu/2015-May/013016.html
> > [2]
> > http://www.linux-arm.org/git?p=linux-rm.git;a=shortlog;h=refs/heads/iommu/defer
> > [3] https://lkml.org/lkml/2016/11/21/141
> > [4]
> > https://www.mai
On Tue, Apr 11, 2017 at 10:27:55PM +0530, Sunil Kovvuri wrote:
> On Tue, Apr 11, 2017 at 9:29 PM, Robin Murphy wrote:
> > On 11/04/17 15:42, linucher...@gmail.com wrote:
> >> From: Linu Cherian
> >>
> >> Add SMMuV3 model definitions.
> >>
> >> Signed-off-by: Linu Cherian
> >> ---
> >> include/a
:
drivers/acpi/arm64/iort.c: In function 'iort_iommu_xlate':
drivers/acpi/arm64/iort.c:647:22: error: 'struct iommu_fwspec' has no
member named 'ops'
by wrapping the code in static inline functions that provide a NOP
implementation when CONFIG_IOMMU_API is not selected.
Si
Hi Sricharan,
On Thu, May 18, 2017 at 08:24:16PM +0530, Sricharan R wrote:
> While deferring the probe of IOMMU masters, xlate and
> add_device callbacks called from iort_iommu_configure
> can pass back error values like -ENODEV, which means
> the IOMMU cannot be connected with that master for rea
On Mon, May 22, 2017 at 04:35:43PM +0530, Sricharan R wrote:
> Hi Lorenzo,
>
> On 5/22/2017 4:07 PM, Lorenzo Pieralisi wrote:
> > Hi Sricharan,
> >
> > On Thu, May 18, 2017 at 08:24:16PM +0530, Sricharan R wrote:
> >> While deferring the probe of IOMM
ter device probe depending
> >on whether the IOMMU is optional or mandatory would be a good
> >enhancement.
> >
> >Tested-by: Hanjun Guo
> >Reviewed-by: Robin Murphy
> >[Lorenzo: Added fixes for dma_coherent_mask overflow, acpi_dma_configure
> &g
On Tue, May 23, 2017 at 02:31:17PM +0530, Sricharan R wrote:
> Hi Lorenzo,
>
> On 5/23/2017 2:22 PM, Lorenzo Pieralisi wrote:
> > On Tue, May 23, 2017 at 02:26:10AM -0400, Nate Watterson wrote:
> >> Hi Sricharan,
> >>
> >> On 4/10/2017 7:21 AM, Srichar
On Mon, May 29, 2017 at 10:36:42AM +0530, Sricharan R wrote:
> Hi Rafael,
>
> On 5/28/2017 12:48 AM, Rafael J. Wysocki wrote:
> > On Saturday, May 27, 2017 07:17:42 PM Sricharan R wrote:
> >> While deferring the probe of IOMMU masters, xlate and
> >> add_device callbacks called from iort_iommu_con
On Thu, Jun 01, 2017 at 07:35:37PM +0530, Ganapatrao Kulkarni wrote:
> ARM IORT specification has provision to define Proximity domain
> in SMMUv3 IORT table. Adding required code to parse Proximity domain of
> SMMUv3 IORT table. Parsed Proximity domain is used to set numa_node
> of SMMUv3 platform
On Wed, May 31, 2017 at 03:32:13PM +0100, shameer wrote:
> The HiSilicon erratum 161010801 describes the limitation of HiSilicon
> platforms Hip06/Hip07 to support the SMMU mappings for MSI transactions.
>
> On these platforms GICv3 ITS translator is presented with the deviceID
> by extending the
On Wed, May 31, 2017 at 03:32:12PM +0100, shameer wrote:
> This provides a helper function to find and retrieve the ITS
> base address from the ID mappings array reference of a device
> IORT node(if any).
>
> This is used in the subsequent patch to retrieve the ITS base
> address associated with
On Tue, Jun 06, 2017 at 04:17:45PM +0530, Ganapatrao Kulkarni wrote:
> Add code to parse proximity domain in SMMUv3 IORT table to
> set numa node mapping for smmuv3 devices.
>
> Signed-off-by: Ganapatrao Kulkarni
> ---
> drivers/acpi/arm64/iort.c | 20
> 1 file changed, 20 i
On Tue, Jun 06, 2017 at 03:01:36PM +, Shameerali Kolothum Thodi wrote:
> Hi Lorenzo,
>
> > -Original Message-
> > From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
> > Sent: Tuesday, June 06, 2017 2:56 PM
> > To: Shameerali Kolothum Thod
On Tue, Jun 06, 2017 at 03:01:36PM +, Shameerali Kolothum Thodi wrote:
[...]
> > > + irq_dom = pci_msi_get_device_domain(to_pci_dev(dev));
> > > + if (irq_dom) {
> > > + int ret;
> > > + u32 rid;
> > > +
> > > + rid = pci_msi_domain_get_msi_rid(irq_dom,
> > to_
On Tue, May 30, 2017 at 05:33:39PM +0530, Geetha sowjanya wrote:
> From: Linu Cherian
>
> Cavium ThunderX2 implementation doesn't support second page in SMMU
> register space. Hence, resource size is set as 64k for this model.
>
> Signed-off-by: Linu Cherian
> Signed-off-by: Geetha Sowjanya
>
On Thu, Jun 08, 2017 at 09:09:28AM +, Shameerali Kolothum Thodi wrote:
>
>
> > -Original Message-
> > From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
> > Sent: Thursday, June 08, 2017 9:49 AM
> > To: Shameerali Kolothum Thodi
> >
On Tue, May 30, 2017 at 05:33:38PM +0530, Geetha sowjanya wrote:
> Cavium ThunderX2 SMMUv3 implementation has two Silicon Erratas.
> 1. Errata ID #74
>SMMU register alias Page 1 is not implemented
> 2. Errata ID #126
>SMMU doesnt support unique IRQ lines and also MSI for gerror,
>eventq
Hi Rafael, Lv,
On Thu, Jun 08, 2017 at 07:13:24PM +0200, Rafael J. Wysocki wrote:
> On Thu, Jun 8, 2017 at 6:32 PM, Lorenzo Pieralisi
> wrote:
> > On Tue, May 30, 2017 at 05:33:38PM +0530, Geetha sowjanya wrote:
> >> Cavium ThunderX2 SMMUv3 implementation has two Silicon Er
On Tue, Jun 13, 2017 at 12:48:29PM +0100, shameer wrote:
> The HiSilicon erratum 161010801 describes the limitation of HiSilicon
> platforms Hip06/Hip07 to support the SMMU mappings for MSI transactions.
>
> On these platforms GICv3 ITS translator is presented with the deviceID
> by extending the
Hi,
On Thu, Jun 08, 2017 at 10:14:19AM +0530, Ganapatrao Kulkarni wrote:
> Add code to parse proximity domain in SMMUv3 IORT table to
> set numa node mapping for smmuv3 devices.
>
> Signed-off-by: Ganapatrao Kulkarni
> ---
> drivers/acpi/arm64/iort.c | 28 ++--
> 1 file
On Fri, Jun 16, 2017 at 09:43:52AM +, Shameerali Kolothum Thodi wrote:
> Hi Lorenzo,
>
> > -Original Message-
> > From: linuxarm-boun...@huawei.com [mailto:linuxarm-
> > boun...@huawei.com] On Behalf Of Shameerali Kolothum Thodi
> > Sent: Tuesday, June 13
Hi Shameer,
On Mon, Jun 19, 2017 at 04:45:00PM +0100, shameer wrote:
> The HiSilicon erratum 161010801 describes the limitation of HiSilicon
> platforms Hip06/Hip07 to support the SMMU mappings for MSI transactions.
>
> On these platforms GICv3 ITS translator is presented with the deviceID
> by e
On Tue, Jun 20, 2017 at 10:51:23AM +0200, Robert Richter wrote:
> On 20.06.17 10:19:43, Robert Richter wrote:
> > On 30.05.17 17:33:39, Geetha sowjanya wrote:
> > > From: Linu Cherian
>
> > > + /*
> > > + * Override the size, for Cavium ThunderX2 implementation
> > > + * which doesn't support t
On Tue, Jun 20, 2017 at 04:16:18PM +0100, Robin Murphy wrote:
> On 20/06/17 15:07, Shameerali Kolothum Thodi wrote:
> >
> >
> >> -Original Message-
> >> From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
> >> Sent: Tuesday, June 20,
On Tue, Jun 20, 2017 at 03:39:30PM +, Shameerali Kolothum Thodi wrote:
>
>
> > -Original Message-
> > From: Robin Murphy [mailto:robin.mur...@arm.com]
> > Sent: Tuesday, June 20, 2017 4:16 PM
> > To: Shameerali Kolothum Thodi; Lorenzo Pieralisi
> >
ed-off-by: Geetha Sowjanya
> ---
> drivers/acpi/arm64/iort.c | 15 ++-
> 1 files changed, 14 insertions(+), 1 deletions(-)
Acked-by: Lorenzo Pieralisi
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index c5fecf9..c166f3e 100644
> --- a/dr
On Thu, Jun 22, 2017 at 09:35:35PM +0200, Robert Richter wrote:
> On 22.06.17 19:58:22, Will Deacon wrote:
> > On Thu, Jun 22, 2017 at 07:22:57PM +0100, Will Deacon wrote:
> > > On Thu, Jun 22, 2017 at 05:35:35PM +0530, Geetha sowjanya wrote:
> > > > Cavium ThunderX2 SMMUv3 implementation has two S
On Fri, Jun 23, 2017 at 06:55:41AM +0200, Robert Richter wrote:
> On 22.06.17 22:04:37, Lorenzo Pieralisi wrote:
> > On Thu, Jun 22, 2017 at 09:35:35PM +0200, Robert Richter wrote:
> > > On 22.06.17 19:58:22, Will Deacon wrote:
> > > > On Thu, Jun 22, 2017 at 07:22
On Fri, Jun 23, 2017 at 06:59:33AM +0200, Robert Richter wrote:
> On 23.06.17 06:55:41, Robert Richter wrote:
> > On 22.06.17 22:04:37, Lorenzo Pieralisi wrote:
> > > On Thu, Jun 22, 2017 at 09:35:35PM +0200, Robert Richter wrote:
> > > > On 22.06.17 19:58:22, Will
On Fri, Jun 23, 2017 at 11:28:05AM +0530, Geetha sowjanya wrote:
[...]
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -828,6 +828,18 @@ static int __init arm_smmu_v3_count_resources(struct
> acpi_iort_node *node)
> return num_res;
> }
>
> +static bool arm_smmu_
On Fri, Jun 23, 2017 at 03:58:00PM +0100, shameer wrote:
> The helper function retrieves ITS address regions through IORT
> device <-> ITS mappings and reserves it so that these regions
> will not be translated by IOMMU and will be excluded from IOVA
> allocations. IOMMU drivers can use this to imp
Hi Robert,
On Wed, Jun 28, 2017 at 07:47:50PM +0200, Robert Richter wrote:
> On 15.06.17 14:46:03, Lorenzo Pieralisi wrote:
> > On Thu, Jun 08, 2017 at 10:14:19AM +0530, Ganapatrao Kulkarni wrote:
> > > Add code to parse proximity domain in SMMUv3 IORT table to
> > >
On Mon, Jul 03, 2017 at 08:18:45AM +, Shameerali Kolothum Thodi wrote:
>
>
> > -Original Message-
> > From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
> > Sent: Friday, June 23, 2017 5:54 PM
> > To: Shameerali Kolothum Thodi
> >
ncy on header file patch [1], which is
> > already merged to linux-pm.
> >
> > [1]
> > https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&id=c944230064eb65e4fa018d86779b4fd200b1d7e7
> >
> > v4:
> > - Fix compilation
On Tue, Jul 25, 2017 at 12:17:31PM +0100, Shameer Kolothum wrote:
> The helper function retrieves ITS address regions through IORT
> device <-> ITS mappings and reserves it so that these regions
> will not be translated by IOMMU and will be excluded from IOVA
> allocations. IOMMU drivers can use th
On Tue, Jul 25, 2017 at 06:32:40PM +0100, Robin Murphy wrote:
> On 25/07/17 18:11, Lorenzo Pieralisi wrote:
> > On Tue, Jul 25, 2017 at 12:17:31PM +0100, Shameer Kolothum wrote:
> >> The helper function retrieves ITS address regions through IORT
> >> device <-> ITS
On Thu, Jul 27, 2017 at 09:13:42AM +, Shameerali Kolothum Thodi wrote:
[...]
> > > >> +int iort_iommu_its_get_resv_regions(struct device *dev, struct
> > list_head *head)
> > > >> +{
> > > >> + int i;
> > > >> + struct acpi_iort_its_group *its;
> > > >> + struct acpi_iort_node
On Mon, Nov 12, 2018 at 07:02:03PM +0100, Lukas Wunner wrote:
> On Mon, Nov 12, 2018 at 07:06:25PM +0300, Mika Westerberg wrote:
> > --- a/drivers/pci/probe.c
> > +++ b/drivers/pci/probe.c
> > @@ -1378,6 +1378,27 @@ static void set_pcie_thunderbolt(struct pci_dev *dev)
> > }
> > }
> >
> > +s
On Tue, Nov 13, 2018 at 01:27:00PM +0200, Mika Westerberg wrote:
[...]
> > To be frank the concept (and Microsoft _DSD bindings) seems a bit vague
> > and not thoroughly defined and I would question its detection at
> > PCI/ACPI core level, I would hope this can be clarified at ACPI
> > specifica
On Thu, Nov 15, 2018 at 12:22:39PM +0200, Mika Westerberg wrote:
> On Tue, Nov 13, 2018 at 11:45:36AM +0000, Lorenzo Pieralisi wrote:
> > On Tue, Nov 13, 2018 at 01:27:00PM +0200, Mika Westerberg wrote:
> >
> > [...]
> >
> > > > To be frank the concept (a
On Thu, Nov 15, 2018 at 02:16:27PM +0200, Mika Westerberg wrote:
> On Thu, Nov 15, 2018 at 01:07:36PM +0100, Lukas Wunner wrote:
> > On Thu, Nov 15, 2018 at 01:37:37PM +0200, Mika Westerberg wrote:
> > > On Thu, Nov 15, 2018 at 11:13:56AM +, Lorenzo Pieralisi wrote:
>
On Thu, Nov 15, 2018 at 07:33:54PM +, mario.limoncie...@dell.com wrote:
>
>
> > -Original Message-
> > From: Mika Westerberg
> > Sent: Thursday, November 15, 2018 1:01 PM
> > To: Lorenzo Pieralisi
> > Cc: Lukas Wunner; iommu@lists.linux
On Tue, Nov 20, 2018 at 10:43:35PM +0100, Rafael J. Wysocki wrote:
> On Friday, November 16, 2018 11:57:38 AM CET Lorenzo Pieralisi wrote:
> > On Thu, Nov 15, 2018 at 07:33:54PM +, mario.limoncie...@dell.com wrote:
> > >
> > >
> > > > -Original Mes
On Tue, Feb 05, 2019 at 10:27:00AM +0530, Srinath Mannam wrote:
> In the current implementation, config read output data 0x0001 is
> assumed as CRS completion. But sometimes 0x0001 can be a valid data.
>
> IPROC PCIe host controller has a register to show config read request
> status flags
On Tue, Feb 05, 2019 at 10:27:01AM +0530, Srinath Mannam wrote:
> Add configuration to support IPROC PCIe host controller outbound memory
> window mapping with SOC address range inside 4GB boundary, which is 32 bit
> AXI address.
I do not understand what this means, explain it to me and rewrite th
On Thu, Feb 27, 2020 at 12:05:39PM +0200, laurentiu.tu...@nxp.com wrote:
> From: Laurentiu Tudor
>
> The devices on this bus are not discovered by way of device tree
> but by queries to the firmware. It makes little sense to trick the
> generic of layer into thinking that these devices are of rel
On Wed, Mar 25, 2020 at 06:48:55PM +0200, Laurentiu Tudor wrote:
> Hi Lorenzo,
>
> On 3/25/2020 2:51 PM, Lorenzo Pieralisi wrote:
> > On Thu, Feb 27, 2020 at 12:05:39PM +0200, laurentiu.tu...@nxp.com wrote:
> >> From: Laurentiu Tudor
> >>
> >> The device
On Wed, Apr 15, 2020 at 05:42:03AM +, Makarand Pawagi wrote:
>
>
> > -Original Message-
> > From: Lorenzo Pieralisi
> > Sent: Tuesday, April 14, 2020 8:02 PM
> > To: Laurentiu Tudor
> > Cc: linux-ker...@vger.kernel.org; iommu@lists.linux-fou
On Wed, Apr 15, 2020 at 06:44:37PM +0300, Laurentiu Tudor wrote:
>
>
> On 4/14/2020 5:32 PM, Lorenzo Pieralisi wrote:
> > On Wed, Mar 25, 2020 at 06:48:55PM +0200, Laurentiu Tudor wrote:
> >> Hi Lorenzo,
> >>
> >> On 3/25/2020 2:51 PM, Lorenzo Pieralisi
On Thu, Apr 23, 2020 at 09:56:54AM +, Makarand Pawagi wrote:
[...]
> > > At a first glance, looks like this could very well fix the ACPI
> > > scenario, but I have some unclarities on the approach:
> > > * are we going to rely in DT and ACPI generic layers even if these
> > > devices are no
allow the bus layer to provide the
device input id parameter - that is retrieved/assigned in bus
specific code and firmware.
Augment of_dma_configure() to add an optional input_id parameter,
leaving current functionality unchanged.
Signed-off-by: Lorenzo Pieralisi
Cc: Rob Herring
Cc: Robin
From: Diana Craciun
The DPRC driver is not taking into account the msi-map property
and assumes that the icid is the same as the stream ID. Although
this assumption is correct, generalize the code to include a
translation between icid and streamID.
Furthermore do not just copy the MSI domain fro
From: Laurentiu Tudor
The existing bindings cannot be used to specify the relationship
between fsl-mc devices and GIC ITSes.
Add a generic binding for mapping fsl-mc devices to GIC ITSes, using
msi-map property.
Signed-off-by: Laurentiu Tudor
Cc: Rob Herring
---
.../devicetree/bindings/misc/
From: Diana Craciun
of_msi_map_get_device_domain() is PCI specific but it need not be and
can be easily changed to be bus agnostic in order to be used by other
busses by adding an IRQ domain bus token as an input parameter.
Signed-off-by: Diana Craciun
Signed-off-by: Lorenzo Pieralisi
Cc
iort_get_device_domain() is PCI specific but it need not be,
since it can be used to retrieve IRQ domain nexus of any kind
by adding an irq_domain_bus_token input to it.
Make it PCI agnostic by also renaming the requestor ID input
to a more generic ID name.
Signed-off-by: Lorenzo Pieralisi
Cc
against the named component entry to check whether
there is a match and therefore an IORT node describing the in/out ID
translation for the device has been found.
Signed-off-by: Lorenzo Pieralisi
Cc: Will Deacon
Cc: Hanjun Guo
Cc: Sudeep Holla
Cc: Catalin Marinas
Cc: Robin Murphy
Cc: "R
for fsl-mc bus
Lorenzo Pieralisi (8):
ACPI/IORT: Make iort_match_node_callback walk the ACPI namespace for
NC
ACPI/IORT: Make iort_get_device_domain IRQ domain agnostic
ACPI/IORT: Make iort_msi_map_rid() PCI agnostic
ACPI/IORT: Remove useless PCI bus walk
ACPI/IORT: Add
of_msi_map_rid() in place to keep
existing PCI code mapping requester ID syntactically unchanged.
No functional change intended.
Signed-off-by: Lorenzo Pieralisi
Cc: Rob Herring
Cc: Marc Zyngier
---
drivers/of/irq.c | 28 ++--
include/linux/of_irq.h | 14
There is nothing PCI specific in iort_msi_map_rid(). Make it
a generic function, iort_msi_map_id() and provide a stub
for iort_msi_map_rid() on top of it to keep current users
unchanged.
Signed-off-by: Lorenzo Pieralisi
Cc: Will Deacon
Cc: Hanjun Guo
Cc: Sudeep Holla
Cc: Catalin Marinas
Cc
.
By adding an ID parameter to acpi_dma_configure(), the IORT
code can map the child device ID to an IOMMU stream id through
the IORT named component representing the bus in/out ID mappings.
Signed-off-by: Lorenzo Pieralisi
Cc: Will Deacon
Cc: Hanjun Guo
Cc: Sudeep Holla
Cc: Catalin Marinas
Cc
From: Diana Craciun
Add ACPI support in the fsl-mc driver. Driver parses MC DSDT table to
extract memory and other resources.
Interrupt (GIC ITS) information is extracted from the MADT table
by drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c.
IORT table is parsed to configure DMA.
Signed-off-by: M
device->bus PCI bus pointer will do.
Remove this useless code.
Signed-off-by: Lorenzo Pieralisi
Cc: Will Deacon
Cc: Hanjun Guo
Cc: Sudeep Holla
Cc: Catalin Marinas
Cc: Robin Murphy
Cc: "Rafael J. Wysocki"
---
drivers/acpi/arm64/iort.c | 3 ---
1 file changed, 3 deletions(-)
unction so that we can leave the existing
(and legitimate) callers unchanged.
No functionality change intended.
Signed-off-by: Lorenzo Pieralisi
Cc: Rob Herring
Cc: Joerg Roedel
Cc: Robin Murphy
Cc: Marc Zyngier
---
drivers/iommu/of_iommu.c | 2 +-
drivers/of/base.c
On Fri, May 22, 2020 at 05:32:02AM +, Makarand Pawagi wrote:
[...]
> > Subject: Re: [PATCH 12/12] bus: fsl-mc: Add ACPI support for fsl-mc
> >
> > Hi Lorenzo,
> >
> > On 5/21/2020 4:00 PM, Lorenzo Pieralisi wrote:
> > > From: Diana Craciun
> >
On Thu, May 21, 2020 at 04:47:19PM -0600, Rob Herring wrote:
> On Thu, May 21, 2020 at 7:00 AM Lorenzo Pieralisi
> wrote:
> >
> > There is nothing PCI specific (other than the RID - requester ID)
> > in the of_map_rid() implementation, so the same function can be
> &g
On Thu, May 21, 2020 at 05:02:20PM -0600, Rob Herring wrote:
> On Thu, May 21, 2020 at 7:00 AM Lorenzo Pieralisi
> wrote:
> >
> > Devices sitting on proprietary busses have a device ID space that
> > is owned by the respective bus and related firmware bindings. In order
&
On Thu, May 21, 2020 at 05:17:27PM -0600, Rob Herring wrote:
> On Thu, May 21, 2020 at 7:00 AM Lorenzo Pieralisi
> wrote:
> >
> > There is nothing PCI bus specific in the of_msi_map_rid()
> > implementation other than the requester ID tag for the input
> > ID space.
On Mon, Feb 17, 2020 at 12:08:48PM +, John Garry wrote:
> > >
> > > Right, and even worse is that it relies on the port driver even
> > > existing at all.
> > >
> > > All this iommu group assignment should be taken outside device
> > > driver probe paths.
> > >
> > > However we could still c
On Wed, Oct 15, 2014 at 04:06:52AM +0100, Yijing Wang wrote:
> Saving msi chip in pci_sys_data can make pci bus and
> devices don't need to know msi chip detail, it also
> make pci enumeration code be decoupled from msi chip.
> In fact, all pci devices under the same pci hostbridge
> share same msi
On Fri, Nov 01, 2019 at 12:41:48PM +0100, Jean-Philippe Brucker wrote:
[...]
> > > I'm also wondering about ACPI support.
> >
> > I'd love to add ACPI support too, but I have zero knowledge of ACPI.
> > I'd be happy to help anyone who wants to add ACPI support that allows
> > ACPI to add device
On Fri, Nov 01, 2019 at 02:26:05PM -0700, Saravana Kannan wrote:
> On Fri, Nov 1, 2019 at 5:28 AM Lorenzo Pieralisi
> wrote:
> >
> > On Fri, Nov 01, 2019 at 12:41:48PM +0100, Jean-Philippe Brucker wrote:
> >
> > [...]
> >
> > > > > I'm als
> drivers/iommu/arm-smmu-v3.c | 1 +
> drivers/iommu/arm-smmu.c| 1 +
> 3 files changed, 4 insertions(+), 2 deletions(-)
I think it is best if Will picks this up and add it to the
series that modularize the SMMU drivers:
Acked-by: Lorenzo Pieralisi
> diff --git a/drivers/acp
On Fri, Jan 10, 2020 at 10:21:08AM -0700, Jon Derrick wrote:
> v2 Set:
> https://lore.kernel.org/linux-iommu/1578580256-3483-1-git-send-email-jonathan.derr...@intel.com/T/#t
> v1 Set:
> https://lore.kernel.org/linux-iommu/20200107134125.gd30...@8bytes.org/T/#t
>
> VMD currently works with VT-d e
On Mon, Jan 13, 2020 at 12:01:13PM -0600, Bjorn Helgaas wrote:
> On Mon, Jan 13, 2020 at 05:13:38PM +, Derrick, Jonathan wrote:
> > On Mon, 2020-01-13 at 12:08 +, Lorenzo Pieralisi wrote:
> > > On Fri, Jan 10, 2020 at 10:21:08AM -0700, Jon Derrick wrote:
> > &g
ick
> ---
> drivers/pci/controller/Kconfig | 1 -
> drivers/pci/controller/vmd.c | 150
> -----
> 2 files changed, 151 deletions(-)
Acked-by: Lorenzo Pieralisi
> diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kc
On Sun, Jan 19, 2020 at 11:25:23PM +0100, Christoph Hellwig wrote:
> This series looks good to me (modulo the one minor nitpick which isn't
> all that important):
>
> Reviewed-by: Christoph Hellwig
Hi Bjorn,
are you picking this up ? I can merge it too but since it is mostly
x86 changes I recko
On Wed, Jan 22, 2020 at 03:12:59PM -0600, Bjorn Helgaas wrote:
> On Tue, Jan 21, 2020 at 06:37:47AM -0700, Jon Derrick wrote:
> > The current DMA alias implementation requires the aliased device be on
> > the same PCI bus as the requester ID. This introduces an arch-specific
> > mechanism to point
o/?l=linux-arm-kernel&m=145675372917701&w=2
T.Nowicki "Introduce ACPI world to ITS irqchip"
https://marc.info/?l=linux-acpi&m=145976009630179&w=2
Tested on Juno-r2 board with both DT and ACPI probing paths.
Lorenzo Pieralisi (11):
drivers: acpi: iort: fix struct pci_dev com
1 - 100 of 372 matches
Mail list logo
