* [PATCH v3 1/2] iommu/dma: Implement dma_{map,unmap}_resource()
From: Robin Murphy @ 2016-11-11 18:27 UTC (permalink / raw)
To: linux-arm-kernel
With the new dma_{map,unmap}_resource() functions added to the DMA API
for the benefit of cases like slave DMA, add suitable implementations to
the arsenal of our generic layer. Since cache maintenance should not be
a concern, these can both be standalone callback implementations without
the need for arch code wrappers.
CC: Joerg Roedel <joro@8bytes.org>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
v3: Don't misuse phys_to_page()
drivers/iommu/dma-iommu.c | 24 +++++++++++++++++++++---
include/linux/dma-iommu.h | 4 ++++
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index c5ab8667e6f2..8b745260b3bc 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -432,13 +432,12 @@ int iommu_dma_mmap(struct page **pages, size_t size, struct vm_area_struct *vma)
return ret;
}
-dma_addr_t iommu_dma_map_page(struct device *dev, struct page *page,
- unsigned long offset, size_t size, int prot)
+dma_addr_t __iommu_dma_map(struct device *dev, phys_addr_t phys,
+ size_t size, int prot)
{
dma_addr_t dma_addr;
struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
struct iova_domain *iovad = cookie_iovad(domain);
- phys_addr_t phys = page_to_phys(page) + offset;
size_t iova_off = iova_offset(iovad, phys);
size_t len = iova_align(iovad, size + iova_off);
struct iova *iova = __alloc_iova(domain, len, dma_get_mask(dev));
@@ -454,6 +453,12 @@ dma_addr_t iommu_dma_map_page(struct device *dev, struct page *page,
return dma_addr + iova_off;
}
+dma_addr_t iommu_dma_map_page(struct device *dev, struct page *page,
+ unsigned long offset, size_t size, int prot)
+{
+ return __iommu_dma_map(dev, page_to_phys(page) + offset, size, prot);
+}
+
void iommu_dma_unmap_page(struct device *dev, dma_addr_t handle, size_t size,
enum dma_data_direction dir, unsigned long attrs)
{
@@ -624,6 +629,19 @@ void iommu_dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
__iommu_dma_unmap(iommu_get_domain_for_dev(dev), sg_dma_address(sg));
}
+dma_addr_t iommu_dma_map_resource(struct device *dev, phys_addr_t phys,
+ size_t size, enum dma_data_direction dir, unsigned long attrs)
+{
+ return __iommu_dma_map(dev, phys, size,
+ dma_direction_to_prot(dir, false) | IOMMU_MMIO);
+}
+
+void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
+ size_t size, enum dma_data_direction dir, unsigned long attrs)
+{
+ __iommu_dma_unmap(iommu_get_domain_for_dev(dev), handle);
+}
+
int iommu_dma_supported(struct device *dev, u64 mask)
{
/*
diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index 32c589062bd9..7f7e9a7e3839 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -61,6 +61,10 @@ void iommu_dma_unmap_page(struct device *dev, dma_addr_t handle, size_t size,
enum dma_data_direction dir, unsigned long attrs);
void iommu_dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
enum dma_data_direction dir, unsigned long attrs);
+dma_addr_t iommu_dma_map_resource(struct device *dev, phys_addr_t phys,
+ size_t size, enum dma_data_direction dir, unsigned long attrs);
+void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
+ size_t size, enum dma_data_direction dir, unsigned long attrs);
int iommu_dma_supported(struct device *dev, u64 mask);
int iommu_dma_mapping_error(struct device *dev, dma_addr_t dma_addr);
--
2.10.2.dirty
^ permalink raw reply related
* [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: liviu.dudau at arm.com @ 2016-11-11 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F8F9909@lhreml507-mbx>
On Fri, Nov 11, 2016 at 03:53:53PM +0000, Gabriele Paoloni wrote:
> Hi Liviu
Hi Gabriele,
>
> > -----Original Message-----
> > From: liviu.dudau at arm.com [mailto:liviu.dudau at arm.com]
> > Sent: 11 November 2016 14:46
> > To: Gabriele Paoloni
> > Cc: Arnd Bergmann; linux-arm-kernel at lists.infradead.org; Yuanzhichang;
> > mark.rutland at arm.com; devicetree at vger.kernel.org;
> > lorenzo.pieralisi at arm.com; minyard at acm.org; linux-pci at vger.kernel.org;
> > benh at kernel.crashing.org; John Garry; will.deacon at arm.com; linux-
> > kernel at vger.kernel.org; xuwei (O); Linuxarm; zourongrong at gmail.com;
> > robh+dt at kernel.org; kantyzc at 163.com; linux-serial at vger.kernel.org;
> > catalin.marinas at arm.com; olof at lixom.net; bhelgaas at googl e.com;
> > zhichang.yuan02 at gmail.com
> > Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
> > Hip06
> >
> > On Fri, Nov 11, 2016 at 01:39:35PM +0000, Gabriele Paoloni wrote:
> > > Hi Arnd
> > >
> > > > -----Original Message-----
> > > > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > > > Sent: 10 November 2016 16:07
> > > > To: Gabriele Paoloni
> > > > Cc: linux-arm-kernel at lists.infradead.org; Yuanzhichang;
> > > > mark.rutland at arm.com; devicetree at vger.kernel.org;
> > > > lorenzo.pieralisi at arm.com; minyard at acm.org; linux-
> > pci at vger.kernel.org;
> > > > benh at kernel.crashing.org; John Garry; will.deacon at arm.com; linux-
> > > > kernel at vger.kernel.org; xuwei (O); Linuxarm; zourongrong at gmail.com;
> > > > robh+dt at kernel.org; kantyzc at 163.com; linux-serial at vger.kernel.org;
> > > > catalin.marinas at arm.com; olof at lixom.net; liviu.dudau at arm.com;
> > > > bhelgaas at googl e.com; zhichang.yuan02 at gmail.com
> > > > Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
> > > > Hip06
> > > >
> > > > On Thursday, November 10, 2016 3:36:49 PM CET Gabriele Paoloni
> > wrote:
> > > > >
> > > > > Where should we get the range from? For LPC we know that it is
> > going
> > > > > Work on anything that is not used by PCI I/O space, and this is
> > > > > why we use [0, PCIBIOS_MIN_IO]
> > > >
> > > > It should be allocated the same way we allocate PCI config space
> > > > segments. This is currently done with the io_range list in
> > > > drivers/pci/pci.c, which isn't perfect but could be extended
> > > > if necessary. Based on what others commented here, I'd rather
> > > > make the differences between ISA/LPC and PCI I/O ranges smaller
> > > > than larger.
> >
> > Gabriele,
> >
> > >
> > > I am not sure this would make sense...
> > >
> > > IMHO all the mechanism around io_range_list is needed to provide the
> > > "mapping" between I/O tokens and physical CPU addresses.
> > >
> > > Currently the available tokens range from 0 to IO_SPACE_LIMIT.
> > >
> > > As you know the I/O memory accessors operate on whatever
> > > __of_address_to_resource sets into the resource (start, end).
> > >
> > > With this special device in place we cannot know if a resource is
> > > assigned with an I/O token or a physical address, unless we forbid
> > > the I/O tokens to be in a specific range.
> > >
> > > So this is why we are changing the offsets of all the functions
> > > handling io_range_list (to make sure that a range is forbidden to
> > > the tokens and is available to the physical addresses).
> > >
> > > We have chosen this forbidden range to be [0, PCIBIOS_MIN_IO)
> > > because this is the maximum physical I/O range that a non PCI device
> > > can operate on and because we believe this does not impose much
> > > restriction on the available I/O token range; that now is
> > > [PCIBIOS_MIN_IO, IO_SPACE_LIMIT].
> > > So we believe that the chosen forbidden range can accommodate
> > > any special ISA bus device with no much constraint on the rest
> > > of I/O tokens...
> >
> > Your idea is a good one, however you are abusing PCIBIOS_MIN_IO and you
> > actually need another variable for "reserving" an area in the I/O space
> > that can be used for physical addresses rather than I/O tokens.
> >
> > The one good example for using PCIBIOS_MIN_IO is when your
> > platform/architecture
> > does not support legacy ISA operations *at all*. In that case someone
> > sets the PCIBIOS_MIN_IO to a non-zero value to reserve that I/O range
> > so that it doesn't get used. With Zhichang's patch you now start
> > forcing
> > those platforms to have a valid address below PCIBIOS_MIN_IO.
>
> But if PCIBIOS_MIN_IO is 0 then it means that all I/O space is to be used
> by PCI controllers only...
Nope, that is not what it means. It means that PCI devices can see I/O addresses
on the bus that start from 0. There never was any usage for non-PCI controllers
when PCIBIOS_MIN_IO != 0. That is what Zhichang is trying to do now and what
I think is not the right thing (and not enough anyway).
> so if you have a special bus device using
> an I/O range in this case should be a PCI controller...
That has always been the case. It is this series that wants to introduce the
new meaning.
> i.e. I would
> expect it to fall back into the case of I/O tokens redirection rather than
> physical addresses redirection (as mentioned below from my previous reply).
> What do you think?
I think you have looked too much at the code *with* Zhichang's patches applied.
Take a step back and look at how PCIBIOS_MIN_IO is used now, before you apply
the patches. It is all about PCI addresses and there is no notion of non-PCI
busses using PCI framework. Only platforms and architectures that try to work
around some legacy standards (ISA) or HW restrictions.
Best regards,
Liviu
>
> Thanks
>
> Gab
>
>
> >
> > For the general case you also have to bear in mind that PCIBIOS_MIN_IO
> > could
> > be zero. In that case, what is your "forbidden" range? [0, 0) ? So it
> > makes
> > sense to add a new #define that should only be defined by those
> > architectures/
> > platforms that want to reserve on top of PCIBIOS_MIN_IO another region
> > where I/O tokens can't be generated for.
> >
> > Best regards,
> > Liviu
> >
> > >
> > > >
> > > > > > Your current version has
> > > > > >
> > > > > > if (arm64_extio_ops->pfout)
> > \
> > > > > > arm64_extio_ops->pfout(arm64_extio_ops-
> > >devpara,\
> > > > > > addr, value, sizeof(type));
> > \
> > > > > >
> > > > > > Instead, just subtract the start of the range from the logical
> > > > > > port number to transform it back into a bus-local port number:
> > > > >
> > > > > These accessors do not operate on IO tokens:
> > > > >
> > > > > If (arm64_extio_ops->start > addr || arm64_extio_ops->end < addr)
> > > > > addr is not going to be an I/O token; in fact patch 2/3 imposes
> > that
> > > > > the I/O tokens will start at PCIBIOS_MIN_IO. So from 0 to
> > > > PCIBIOS_MIN_IO
> > > > > we have free physical addresses that the accessors can operate
> > on.
> > > >
> > > > Ah, I missed that part. I'd rather not use PCIBIOS_MIN_IO to refer
> > to
> > > > the logical I/O tokens, the purpose of that macro is really meant
> > > > for allocating PCI I/O port numbers within the address space of
> > > > one bus.
> > >
> > > As I mentioned above, special devices operate on CPU addresses
> > directly,
> > > not I/O tokens. For them there is no way to distinguish....
> > >
> > > >
> > > > Note that it's equally likely that whichever next platform needs
> > > > non-mapped I/O access like this actually needs them for PCI I/O
> > space,
> > > > and that will use it on addresses registered to a PCI host bridge.
> > >
> > > Ok so here you are talking about a platform that has got an I/O range
> > > under the PCI host controller, right?
> > > And this I/O range cannot be directly memory mapped but needs special
> > > redirections for the I/O tokens, right?
> > >
> > > In this scenario registering the I/O ranges with the forbidden range
> > > implemented by the current patch would still allow to redirect I/O
> > > tokens as long as arm64_extio_ops->start >= PCIBIOS_MIN_IO
> > >
> > > So effectively the special PCI host controller
> > > 1) knows the physical range that needs special redirection
> > > 2) register such range
> > > 3) uses pci_pio_to_address() to retrieve the IO tokens for the
> > > special accessors
> > > 4) sets arm64_extio_ops->start/end to the IO tokens retrieved in 3)
> > >
> > > So to be honest I think this patch can fit well both with
> > > special PCI controllers that need I/O tokens redirection and with
> > > special non-PCI controllers that need non-PCI I/O physical
> > > address redirection...
> > >
> > > Thanks (and sorry for the long reply but I didn't know how
> > > to make the explanation shorter :) )
> > >
> > > Gab
> > >
> > > >
> > > > If we separate the two steps:
> > > >
> > > > a) assign a range of logical I/O port numbers to a bus
> > > > b) register a set of helpers for redirecting logical I/O
> > > > port to a helper function
> > > >
> > > > then I think the code will get cleaner and more flexible.
> > > > It should actually then be able to replace the powerpc
> > > > specific implementation.
> > > >
> > > > Arnd
> >
> > --
> > ====================
> > | I would like to |
> > | fix the world, |
> > | but they're not |
> > | giving me the |
> > \ source code! /
> > ---------------
> > ?\_(?)_/?
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
?\_(?)_/?
^ permalink raw reply
* [PATCH v2 5/5] iommu/mediatek: Fix M4Uv1 group refcounting
From: Robin Murphy @ 2016-11-11 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <37029eb869380edb0d5ce8cc6601ce7e69c80458.1478886974.git.robin.murphy@arm.com>
For each subsequent device assigned to the m4u_group after its initial
allocation, we need to take an additional reference. Otherwise, the
caller of iommu_group_get_for_dev() will inadvertently remove the
reference taken by iommu_group_add_device(), and the group will be
freed prematurely if any device is removed.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/mtk_iommu_v1.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index b8aeb0768483..c7063e9d67d8 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -502,6 +502,8 @@ static struct iommu_group *mtk_iommu_device_group(struct device *dev)
data->m4u_group = iommu_group_alloc();
if (IS_ERR(data->m4u_group))
dev_err(dev, "Failed to allocate M4U IOMMU group\n");
+ } else {
+ iommu_group_ref_get(data->m4u_group);
}
return data->m4u_group;
}
--
2.10.2.dirty
^ permalink raw reply related
* [PATCH v2 4/5] iommu/mediatek: Fix M4Uv2 group refcounting
From: Robin Murphy @ 2016-11-11 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <37029eb869380edb0d5ce8cc6601ce7e69c80458.1478886974.git.robin.murphy@arm.com>
For each subsequent device assigned to the m4u_group after its initial
allocation, we need to take an additional reference. Otherwise, the
caller of iommu_group_get_for_dev() will inadvertently remove the
reference taken by iommu_group_add_device(), and the group will be
freed prematurely if any device is removed.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/mtk_iommu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index b12c12d74c33..9799daeaacde 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -410,6 +410,8 @@ static struct iommu_group *mtk_iommu_device_group(struct device *dev)
data->m4u_group = iommu_group_alloc();
if (IS_ERR(data->m4u_group))
dev_err(dev, "Failed to allocate M4U IOMMU group\n");
+ } else {
+ iommu_group_ref_get(data->m4u_group);
}
return data->m4u_group;
}
--
2.10.2.dirty
^ permalink raw reply related
* [PATCH v2 3/5] iommu/amd: Fix group refcounting
From: Robin Murphy @ 2016-11-11 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <37029eb869380edb0d5ce8cc6601ce7e69c80458.1478886974.git.robin.murphy@arm.com>
If acpihid_device_group() finds an existing group for the relevant
devid, it should be taking an additional reference on that group.
Otherwise, the caller of iommu_group_get_for_dev() will inadvertently
remove the reference taken by iommu_group_add_device(), and the group
will be freed prematurely if any device is removed.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/amd_iommu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 754595ee11b6..019e02707cd5 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -373,6 +373,8 @@ static struct iommu_group *acpihid_device_group(struct device *dev)
if (!entry->group)
entry->group = generic_device_group(dev);
+ else
+ iommu_group_ref_get(entry->group);
return entry->group;
}
--
2.10.2.dirty
^ permalink raw reply related
* [PATCH v2 2/5] iommu/arm-smmu: Fix group refcounting
From: Robin Murphy @ 2016-11-11 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <37029eb869380edb0d5ce8cc6601ce7e69c80458.1478886974.git.robin.murphy@arm.com>
When arm_smmu_device_group() finds an existing group due to Stream ID
aliasing, it should be taking an additional reference on that group.
Otherwise, the caller of iommu_group_get_for_dev() will inadvertently
remove the reference taken by iommu_group_add_device(), and the group
will be freed prematurely if any device is removed.
Reported-by: Sricharan R <sricharan@codeaurora.org>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/arm-smmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 8f7281444551..b8cd5579a953 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1478,7 +1478,7 @@ static struct iommu_group *arm_smmu_device_group(struct device *dev)
}
if (group)
- return group;
+ return iommu_group_ref_get(group);
if (dev_is_pci(dev))
group = pci_device_group(dev);
--
2.10.2.dirty
^ permalink raw reply related
* [PATCH v2 1/5] iommu: Allow taking a reference on a group directly
From: Robin Murphy @ 2016-11-11 17:59 UTC (permalink / raw)
To: linux-arm-kernel
iommu_group_get_for_dev() expects that the IOMMU driver's device_group
callback return a group with a reference held for the given device.
Whilst allocating a new group is fine, and pci_device_group() correctly
handles reusing an existing group, there is no general means for IOMMU
drivers doing their own group lookup to take additional references on an
existing group pointer without having to also store device pointers or
resort to elaborate trickery.
Add an IOMMU-driver-specific function to fill the hole.
Acked-by: Sricharan R <sricharan@codeaurora.org>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
v2: Fix the function name; clarify what exactly its callers are fixing.
drivers/iommu/iommu.c | 13 +++++++++++++
include/linux/iommu.h | 1 +
2 files changed, 14 insertions(+)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 9a2f1960873b..9408c3145483 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -552,6 +552,19 @@ struct iommu_group *iommu_group_get(struct device *dev)
EXPORT_SYMBOL_GPL(iommu_group_get);
/**
+ * iommu_group_ref_get - Increment reference on a group
+ * @group: the group to use, must not be NULL
+ *
+ * This function is called by iommu drivers to take additional references on an
+ * existing group. Returns the given group for convenience.
+ */
+struct iommu_group *iommu_group_ref_get(struct iommu_group *group)
+{
+ kobject_get(group->devices_kobj);
+ return group;
+}
+
+/**
* iommu_group_put - Decrement group reference
* @group: the group to use
*
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 436dc21318af..431638110c6a 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -253,6 +253,7 @@ extern void iommu_group_remove_device(struct device *dev);
extern int iommu_group_for_each_dev(struct iommu_group *group, void *data,
int (*fn)(struct device *, void *));
extern struct iommu_group *iommu_group_get(struct device *dev);
+extern struct iommu_group *iommu_group_ref_get(struct iommu_group *group);
extern void iommu_group_put(struct iommu_group *group);
extern int iommu_group_register_notifier(struct iommu_group *group,
struct notifier_block *nb);
--
2.10.2.dirty
^ permalink raw reply related
* [RFC PATCH 0/6] media: davinci: VPIF: add DT support
From: Kevin Hilman @ 2016-11-11 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6058d790-5409-01c0-1d3f-b1bb45f8f85c@xs4all.nl>
Hans Verkuil <hverkuil@xs4all.nl> writes:
> Hi Kevin,
>
> On 10/26/2016 01:55 AM, Kevin Hilman wrote:
>> This series attempts to add DT support to the davinci VPIF capture
>> driver.
>>
>> I'm not sure I've completely grasped the proper use of the ports and
>> endpoints stuff, so this RFC is primarily to get input on whether I'm
>> on the right track.
>>
>> The last patch is the one where all my questions are, the rest are
>> just prep work to ge there.
>>
>> Tested on da850-lcdk and was able to do basic frame capture from the
>> composite input.
>>
>> Series applies on v4.9-rc1
>>
>> Kevin Hilman (6):
>> [media] davinci: add support for DT init
>> ARM: davinci: da8xx: VPIF: enable DT init
>> ARM: dts: davinci: da850: add VPIF
>> ARM: dts: davinci: da850-lcdk: enable VPIF capture
>> [media] davinci: vpif_capture: don't lock over s_stream
>> [media] davinci: vpif_capture: get subdevs from DT
>
> Looks good, but wouldn't it be better to do the dts changes last when all the
> supporting code is in?
I guess it doesn't really matter in this case, because the DT nodes will
be nops until the driver changes are in.
Either way, next week I'll repost a non-RFC version and separate out the
arch and DT patches, since those will go through Sekhar's davinci tree,
and then via arm-soc.
Thanks for the review,
Kevin
^ permalink raw reply
* [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic
From: Robin Murphy @ 2016-11-11 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111162736.GV2078@8bytes.org>
On 11/11/16 16:27, Joerg Roedel wrote:
> On Fri, Nov 11, 2016 at 04:17:37PM +0000, Robin Murphy wrote:
>> In the original of_iommu_configure design, the thought was that an ops
>> structure could be IOMMU-instance-specific (hence the later-removed
>> "priv" member), so I suppose right now it is mostly a hangover from
>> that. However, it's also what we initialise a device's fwspec with, so
>> becomes important again if we're ever going to get past the limitations
>> of buses-which-are-not-actually-buses[1].
>
> Yeah, I discussed this with a few others at LPC. My current idea is to
> tell the iommu-core which hardware-iommus exist in the system and a
> seperate iommu_ops ptr for each of them. Then every struct device can
> link to the iommu-instance it is translated by.
Er, that sounds very much like a description of what we already have in
4.9-rc. Every struct device now has an iommu_fwspec which encapsulates
both an iommu_ops pointer (which can perfectly well be per-instance if
the IOMMU driver wants) and a place for the IOMMU-private data to
replace the mess of archdata.iommu and driver-internal globals.
> We are not there yet, but this will give you the same per-device
> iommu-ops as implemented here.
With those two patches I linked to, which make the bulk of the IOMMU
core code per-device-ops-aware off the bat, I'd say we *are* already
pretty much there. It's only iommu_domain_alloc() which needs a
device-based alternative, and the non-of_xlate-based IOMMU drivers to
either call iommu_fwspec_init() for themselves, or perhaps for x86
plumbing in DMAR/IVRS equivalents of the IORT parsing to the
infrastructure provided by this series.
Robin.
^ permalink raw reply
* [PATCH] ARM64: dts: bcm2837-rpi-3-b: remove incorrect pwr LED
From: Eric Anholt @ 2016-11-11 17:38 UTC (permalink / raw)
To: linux-arm-kernel
From: Andrea Merello <andrea.merello@gmail.com>
We are incorrectly defining the pwr LED, attaching it to a gpio line
that is wired to the Wi-Fi SDIO module (which fails due to this).
The actual power LED is connected to the GPIO expander, which we don't
expose currently.
Thanks-to: Eric Anholt <eric@anholt.net> [for clarifying we can't control the LED]
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
---
arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts | 7 -------
1 file changed, 7 deletions(-)
diff --git a/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts b/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
index 7625e57a64b5..c309633a1e87 100644
--- a/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
+++ b/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
@@ -16,13 +16,6 @@
act {
gpios = <&gpio 47 0>;
};
-
- pwr {
- label = "PWR";
- gpios = <&gpio 35 0>;
- default-state = "keep";
- linux,default-trigger = "default-on";
- };
};
};
--
2.10.2
^ permalink raw reply related
* [PATCH RFT] irqchip: mxs: Enable SKIP_SET_WAKE and MASK_ON_SUSPEND
From: Stefan Wahren @ 2016-11-11 17:26 UTC (permalink / raw)
To: linux-arm-kernel
The ICOLL controller doesn't provide any facility to configure the
wakeup sources. That's the reason why this implementation lacks
the irq_set_wake implementation. But this prevent us from properly
entering power management states like "suspend to idle".
So enable the flags IRQCHIP_SKIP_SET_WAKE and IRQCHIP_MASK_ON_SUSPEND
to let the irqchip core allows and handles the power management.
This patch has been tested with a MX23 and a MX28 board. Any further
tests especially with ASM9260 would be appreciated.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
drivers/irqchip/irq-mxs.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/irqchip/irq-mxs.c b/drivers/irqchip/irq-mxs.c
index 1730470..05fa9f7 100644
--- a/drivers/irqchip/irq-mxs.c
+++ b/drivers/irqchip/irq-mxs.c
@@ -131,12 +131,16 @@ static void asm9260_unmask_irq(struct irq_data *d)
.irq_ack = icoll_ack_irq,
.irq_mask = icoll_mask_irq,
.irq_unmask = icoll_unmask_irq,
+ .flags = IRQCHIP_MASK_ON_SUSPEND |
+ IRQCHIP_SKIP_SET_WAKE,
};
static struct irq_chip asm9260_icoll_chip = {
.irq_ack = icoll_ack_irq,
.irq_mask = asm9260_mask_irq,
.irq_unmask = asm9260_unmask_irq,
+ .flags = IRQCHIP_MASK_ON_SUSPEND |
+ IRQCHIP_SKIP_SET_WAKE,
};
asmlinkage void __exception_irq_entry icoll_handle_irq(struct pt_regs *regs)
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines
From: Eric Anholt @ 2016-11-11 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7a5c1318-de70-bcfc-648d-fd5a43c2fac5@wwwdotorg.org>
Stephen Warren <swarren@wwwdotorg.org> writes:
> On 10/27/2016 10:52 AM, Eric Anholt wrote:
>> From: Linus Walleij <linus.walleij@linaro.org>
>>
>> The idea is to give useful names to GPIO lines that an implementer
>> will be using from userspace, e.g. for maker type projects. These are
>> user-visible using tools/gpio/lsgpio.c
>
>> arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 65 +++++++++++++++++++++++++++++++
>> arch/arm/boot/dts/bcm2835-rpi-a.dts | 67 ++++++++++++++++++++++++++++++++
>> arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 66 +++++++++++++++++++++++++++++++
>> arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts | 66 +++++++++++++++++++++++++++++++
>> arch/arm/boot/dts/bcm2835-rpi-b.dts | 67 ++++++++++++++++++++++++++++++++
>
> Aren't the A and B rev 2 pinouts the same.
Looking at the contents of the patches and the schematics referenced
>From them: no, they aren't.
> If so, why duplicate the
> content between the files instead of creating an inclue file? Same for
> A+, B+, Pi 2, and Pi 3. Shouldn't this patch update the Pi 2 and Pi 3
> DTs too?
Pi2 and 3 would be lovely. If someone wants to write them, I'd
encourage them to.
> I think the whole point of naming GPIOs is to give users the same
> experience across the different boards where the same semantics exist in
> HW. Both the A+ and B+ use GPIO0/1 (a/k/a ID_SD/ID_SC a/k/a SDA0/SCL0)
> for the same semantic purpose and are exposed in the same externally
> visible way (same pins on the expansion header); the board ID EEPROM.
> Therefore I assert the names of these GPIOs should be identical on all
> boards that use them for that purpose, to allow SW (or human knowledge)
> portability between the boards.
I weakly agree with this, but find the idea of "consistent semantics"
attached to the names rather silly given the number of ways people
reconfigure the boards (particularly given that people can pinmux
things).
That said, I agree with you on renaming ID_SD to disagree with the
schematic in favor of consistency, and I've done so.
>> + "GPIO17",
>
> This pin is known as GPIO_GEN0 on the expansion header. Given the
> expansion header is all end-users likely care about, and other pins
> (e.g. SPI_CE1_N) are named after the expansion header, shouldn't this
> patch use the GPIO expansion header naming for all pins that are routed
> to that header?
We've already been through this. Users *don't* know the GENx names and
they were confusing and got eliminated in the later schematics. This
was done for consistency, like you asked for above!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161111/1ba7017a/attachment.sig>
^ permalink raw reply
* PM regression with LED changes in next-20161109
From: Jacek Anaszewski @ 2016-11-11 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111120114.GA1076@amd>
On 11/11/2016 01:01 PM, Pavel Machek wrote:
> On Thu 2016-11-10 22:34:07, Jacek Anaszewski wrote:
>> Hi,
>>
>> On 11/10/2016 09:29 PM, Pavel Machek wrote:
>>> On Thu 2016-11-10 10:55:37, Tony Lindgren wrote:
>>>> * Pavel Machek <pavel@ucw.cz> [161110 09:29]:
>>>>> Hi!
>>>>>
>>>>>>>>> Looks like commit 883d32ce3385 ("leds: core: Add support for poll()ing
>>>>>>>>> the sysfs brightness attr for changes.") breaks runtime PM for me.
>>>>>>>>>
>>>>>>>>> On my omap dm3730 based test system, idle power consumption is over 70
>>>>>>>>> times higher now with this patch! It goes from about 6mW for the core
>>>>>>>>> system to over 440mW during idle meaning there's some busy timer now
>>>>>>>>> active.
>>>>>>>>>
>>>>>>>>> Reverting this patch fixes the issue. Any ideas?
>>>>>
>>>>> Are you using any LED that toggles with high frequency? Like perhaps
>>>>> LED that is lit when CPU is active?
>>>>
>>>> Yeah one of them seems to have cpu0 as the default trigger.
>>>
>>> Aha. Its quite obvious we don't want to notify sysfs each time that
>>> one is toggled, right?
>>>
>>> IMO brightness should display max brightness for the trigger, as Hans
>>> suggested, anything else is madness for trigger such as cpu activity.
>>
>> Are you suggesting that we should revert changes introduced
>> by below patch?
>>
>> commit 29d76dfa29fe22583aefddccda0bc56aa81035dc
>> Author: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
>> Date: Tue Mar 18 09:47:48 2008 +0000
>>
>> leds: Add support to leds with readable status
>>
>> Some led hardware allows drivers to query the led state, and this patch
>> adds a hook to let the led class take advantage of that information when
>> available.
>>
>> Without this functionality, when access to the led hardware is not
>> exclusive (i.e. firmware or hardware might change its state behind the
>> kernel's back), reality goes out of sync with the led class' idea of
>> what
>> the led is doing, which is annoying at best.
>
> Hmm. So userland can read the LED state, and it can get _some_ value
> back, but it can not know if it is current state or not.
>
> I don't think that's a good interface. I see it is from 2008... is
> someone using it? Maybe it is too late for revert.
I can imagine it being used in flash LED use case. E.g. one
could use oneshot trigger to trigger flash strobe, and then
he could periodically read brightness file to check, for whatever
reason, whether the flash is strobing.
> But I'd certainly not extend it with poll.
We could add a dedicated file e.g. hw_brightness_change for that
(maybe someone will have a better candidate for the file name).
This way it would be semantically consistent to report only
hardware originating brightness changes on it, which was the
initial reason for adding the brightness change notification
feature.
Moreover, LED class drivers could report on this file the
brightness level which was set by the firmware, which wouldn't
affect current LED class device brightness setting, unless
brightness file is read (and brightness_get op is supported).
> IMO reading/polling should only be available with some triggers. It
> does not make sense with "CPU load" trigger. It makes sense with
> "keyboard light changeable by hardware" trigger.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* [PATCH V8 0/6] thermal: bcm2835: add thermal driver
From: Eric Anholt @ 2016-11-11 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478081906-12009-1-git-send-email-kernel@martin.sperl.org>
kernel at martin.sperl.org writes:
> From: Martin Sperl <kernel@martin.sperl.org>
Since Eduardo seems to be AFK, I've pulled this series to my -next
branches.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161111/b4d84fe9/attachment.sig>
^ permalink raw reply
* [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: zhichang.yuan @ 2016-11-11 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111144539.GL10219@e106497-lin.cambridge.arm.com>
Hi, Liviu,
On 11/11/2016 10:45 PM, liviu.dudau at arm.com wrote:
> On Fri, Nov 11, 2016 at 01:39:35PM +0000, Gabriele Paoloni wrote:
>> Hi Arnd
>>
>>> -----Original Message-----
>>> From: Arnd Bergmann [mailto:arnd at arndb.de]
>>> Sent: 10 November 2016 16:07
>>> To: Gabriele Paoloni
>>> Cc: linux-arm-kernel at lists.infradead.org; Yuanzhichang;
>>> mark.rutland at arm.com; devicetree at vger.kernel.org;
>>> lorenzo.pieralisi at arm.com; minyard at acm.org; linux-pci at vger.kernel.org;
>>> benh at kernel.crashing.org; John Garry; will.deacon at arm.com; linux-
>>> kernel at vger.kernel.org; xuwei (O); Linuxarm; zourongrong at gmail.com;
>>> robh+dt at kernel.org; kantyzc at 163.com; linux-serial at vger.kernel.org;
>>> catalin.marinas at arm.com; olof at lixom.net; liviu.dudau at arm.com;
>>> bhelgaas at googl e.com; zhichang.yuan02 at gmail.com
>>> Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
>>> Hip06
>>>
>>> On Thursday, November 10, 2016 3:36:49 PM CET Gabriele Paoloni wrote:
>>>>
>>>> Where should we get the range from? For LPC we know that it is going
>>>> Work on anything that is not used by PCI I/O space, and this is
>>>> why we use [0, PCIBIOS_MIN_IO]
>>>
>>> It should be allocated the same way we allocate PCI config space
>>> segments. This is currently done with the io_range list in
>>> drivers/pci/pci.c, which isn't perfect but could be extended
>>> if necessary. Based on what others commented here, I'd rather
>>> make the differences between ISA/LPC and PCI I/O ranges smaller
>>> than larger.
>
> Gabriele,
>
>>
>> I am not sure this would make sense...
>>
>> IMHO all the mechanism around io_range_list is needed to provide the
>> "mapping" between I/O tokens and physical CPU addresses.
>>
>> Currently the available tokens range from 0 to IO_SPACE_LIMIT.
>>
>> As you know the I/O memory accessors operate on whatever
>> __of_address_to_resource sets into the resource (start, end).
>>
>> With this special device in place we cannot know if a resource is
>> assigned with an I/O token or a physical address, unless we forbid
>> the I/O tokens to be in a specific range.
>>
>> So this is why we are changing the offsets of all the functions
>> handling io_range_list (to make sure that a range is forbidden to
>> the tokens and is available to the physical addresses).
>>
>> We have chosen this forbidden range to be [0, PCIBIOS_MIN_IO)
>> because this is the maximum physical I/O range that a non PCI device
>> can operate on and because we believe this does not impose much
>> restriction on the available I/O token range; that now is
>> [PCIBIOS_MIN_IO, IO_SPACE_LIMIT].
>> So we believe that the chosen forbidden range can accommodate
>> any special ISA bus device with no much constraint on the rest
>> of I/O tokens...
>
> Your idea is a good one, however you are abusing PCIBIOS_MIN_IO and you
> actually need another variable for "reserving" an area in the I/O space
> that can be used for physical addresses rather than I/O tokens.
>
I think selecting PCIBIOS_MIN_IO as the separator of mapped and non-mapped I/O
range probably is not so reasonable.
PCIBIOS_MIN_IN is specific to PCI devices, it seems as the recommended minimal
start I/O address when assigning the pci device I/O region. It is probably not
defined in some platforms/architectures when no PCI is needed there. That is why
my patch caused some compile error on some archs;
But more important thing is that the PCIBIOS_MIN_IO has different value on
different platforms/architectures. On Arm64, it is 4K currently, but in other
archs, it is not true. And the maximum LPC I/O address should be 64K
theoretically, although for compatible ISA, 2K is enough.
So, It means using PCIBIOS_MIN_IO on arm64 can match our I/O reservation
require. But we can not make this indirectIO work well on other architectures.
I am thinking Arnd's suggestion. But I worry about I haven't completely
understood his idea. What about create a new bus host for LPC/ISA whose I/O
range can be 64KB? This LPC/ISA I/O range works similar to PCI host bridge's I/O
window, all the downstream devices under LPC/ISA should request I/O from that
root resource. But it seems Arnd want this root resource registered dynamically,
I am not sure how to do...
Anyway, if we have this root I/O resource, we don't need any new macro or
variable for the LPC/ISA I/O reservation.
Hope my thought is right.
Best,
Zhichang
> The one good example for using PCIBIOS_MIN_IO is when your platform/architecture
> does not support legacy ISA operations *at all*. In that case someone
> sets the PCIBIOS_MIN_IO to a non-zero value to reserve that I/O range
> so that it doesn't get used. With Zhichang's patch you now start forcing
> those platforms to have a valid address below PCIBIOS_MIN_IO.
>
> For the general case you also have to bear in mind that PCIBIOS_MIN_IO could
> be zero. In that case, what is your "forbidden" range? [0, 0) ? So it makes
> sense to add a new #define that should only be defined by those architectures/
> platforms that want to reserve on top of PCIBIOS_MIN_IO another region
> where I/O tokens can't be generated for.
>
> Best regards,
> Liviu
>
>>
>>>
>>>>> Your current version has
>>>>>
>>>>> if (arm64_extio_ops->pfout) \
>>>>> arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
>>>>> addr, value, sizeof(type)); \
>>>>>
>>>>> Instead, just subtract the start of the range from the logical
>>>>> port number to transform it back into a bus-local port number:
>>>>
>>>> These accessors do not operate on IO tokens:
>>>>
>>>> If (arm64_extio_ops->start > addr || arm64_extio_ops->end < addr)
>>>> addr is not going to be an I/O token; in fact patch 2/3 imposes that
>>>> the I/O tokens will start at PCIBIOS_MIN_IO. So from 0 to
>>> PCIBIOS_MIN_IO
>>>> we have free physical addresses that the accessors can operate on.
>>>
>>> Ah, I missed that part. I'd rather not use PCIBIOS_MIN_IO to refer to
>>> the logical I/O tokens, the purpose of that macro is really meant
>>> for allocating PCI I/O port numbers within the address space of
>>> one bus.
>>
>> As I mentioned above, special devices operate on CPU addresses directly,
>> not I/O tokens. For them there is no way to distinguish....
>>
>>>
>>> Note that it's equally likely that whichever next platform needs
>>> non-mapped I/O access like this actually needs them for PCI I/O space,
>>> and that will use it on addresses registered to a PCI host bridge.
>>
>> Ok so here you are talking about a platform that has got an I/O range
>> under the PCI host controller, right?
>> And this I/O range cannot be directly memory mapped but needs special
>> redirections for the I/O tokens, right?
>>
>> In this scenario registering the I/O ranges with the forbidden range
>> implemented by the current patch would still allow to redirect I/O
>> tokens as long as arm64_extio_ops->start >= PCIBIOS_MIN_IO
>>
>> So effectively the special PCI host controller
>> 1) knows the physical range that needs special redirection
>> 2) register such range
>> 3) uses pci_pio_to_address() to retrieve the IO tokens for the
>> special accessors
>> 4) sets arm64_extio_ops->start/end to the IO tokens retrieved in 3)
>>
>> So to be honest I think this patch can fit well both with
>> special PCI controllers that need I/O tokens redirection and with
>> special non-PCI controllers that need non-PCI I/O physical
>> address redirection...
>>
>> Thanks (and sorry for the long reply but I didn't know how
>> to make the explanation shorter :) )
>>
>> Gab
>>
>>>
>>> If we separate the two steps:
>>>
>>> a) assign a range of logical I/O port numbers to a bus
>>> b) register a set of helpers for redirecting logical I/O
>>> port to a helper function
>>>
>>> then I think the code will get cleaner and more flexible.
>>> It should actually then be able to replace the powerpc
>>> specific implementation.
>>>
>>> Arnd
>
^ permalink raw reply
* [PATCH 3/3] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Icenowy Zheng @ 2016-11-11 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111164654.15273-1-icenowy@aosc.xyz>
Orange Pi Zero is a board that came with the new Allwinner H2+ SoC.
Add a device tree file for it.
As there's still no mainline-compatible driver for the SDIO WLAN card on
board (a new card by Allwinner), the mmc1 controller is not enabled yet.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts | 148 +++++++++++++++++++++++
2 files changed, 149 insertions(+)
create mode 100644 arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd26..9843fb0 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -818,6 +818,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-a33-sinlinx-sina33.dtb \
sun8i-a83t-allwinner-h8homlet-v2.dtb \
sun8i-a83t-cubietruck-plus.dtb \
+ sun8i-h2plus-orangepi-zero.dtb \
sun8i-h3-bananapi-m2-plus.dtb \
sun8i-h3-nanopi-neo.dtb \
sun8i-h3-orangepi-2.dtb \
diff --git a/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
new file mode 100644
index 0000000..581f56e
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
@@ -0,0 +1,148 @@
+/*
+ * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.xyz>
+ *
+ * Based on sun8i-h3-orangepi-one.dts, which is:
+ * Copyright (C) 2016 Hans de Goede <hdegoede@redhat.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun8i-h2plus.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/pinctrl/sun4i-a10.h>
+
+/ {
+ model = "Xunlong Orange Pi Zero";
+ compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h2plus",
+ "allwinner,sun8i-h3";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&leds_opi0>, <&leds_r_opi0>;
+
+ pwr_led {
+ label = "orangepi:green:pwr";
+ gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+
+ status_led {
+ label = "orangepi:red:status";
+ gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>;
+ };
+ };
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
+ cd-inverted;
+ status = "okay";
+};
+
+&ohci1 {
+ status = "okay";
+};
+
+&pio {
+ leds_opi0: led_pins at 0 {
+ allwinner,pins = "PA17";
+ allwinner,function = "gpio_out";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+};
+
+&r_pio {
+ leds_r_opi0: led_pins at 0 {
+ allwinner,pins = "PL10";
+ allwinner,function = "gpio_out";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins_a>;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>;
+ status = "disabled";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2_pins>;
+ status = "disabled";
+};
+
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart3_pins>;
+ status = "disabled";
+};
+
+&usbphy {
+ /* USB VBUS is always on */
+ status = "okay";
+};
--
2.10.1
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: sunxi: add Allwinner H2+ dtsi
From: Icenowy Zheng @ 2016-11-11 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111164654.15273-1-icenowy@aosc.xyz>
Allwinner H2+ is a SoC so similar with H3 that H3 drivers and memory map
is known to work well on H2+, with both BSP kernel/firmware or the
mainline ones.
So add a dtsi file which only include the H3 dtsi only, so we can add
H2+-specified nodes in the dtsi file when we find any software
difference between H2+ and H3.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
arch/arm/boot/dts/sun8i-h2plus.dtsi | 43 +++++++++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
create mode 100644 arch/arm/boot/dts/sun8i-h2plus.dtsi
diff --git a/arch/arm/boot/dts/sun8i-h2plus.dtsi b/arch/arm/boot/dts/sun8i-h2plus.dtsi
new file mode 100644
index 0000000..76fc3d0
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-h2plus.dtsi
@@ -0,0 +1,43 @@
+/*
+ * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.xyz>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "sun8i-h3.dtsi"
--
2.10.1
^ permalink raw reply related
* [PATCH 1/3] ARM: sunxi: add support for H2+ SoC
From: Icenowy Zheng @ 2016-11-11 16:46 UTC (permalink / raw)
To: linux-arm-kernel
Allwinner H2+ is a quad-core Cortex-A7 SoC.
It is very like H3, that they share the same SoC ID (0x1680), and H3
memory maps as well as drivers works well on the SoC.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
Documentation/arm/sunxi/README | 4 ++++
Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
arch/arm/mach-sunxi/sunxi.c | 1 +
3 files changed, 6 insertions(+)
diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
index cd02433..1fe4d99c 100644
--- a/Documentation/arm/sunxi/README
+++ b/Documentation/arm/sunxi/README
@@ -63,6 +63,10 @@ SunXi family
+ User Manual
http://dl.linux-sunxi.org/A33/A33%20user%20manual%20release%201.1.pdf
+ - Allwinner H2+ (sun8i)
+ + No document available now, but is known to be working properly with
+ H3 drivers and memory map.
+
- Allwinner H3 (sun8i)
+ Datasheet
http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdf
diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt
index 3975d0a..0c0f277 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -13,5 +13,6 @@ using one of the following compatible strings:
allwinner,sun8i-a33
allwinner,sun8i-a83t
allwinner,sun8i-h3
+ allwinner,sun8i-h2plus
allwinner,sun9i-a80
nextthing,gr8
diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index 2e2bde2..3647ad7 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -63,6 +63,7 @@ static const char * const sun8i_board_dt_compat[] = {
"allwinner,sun8i-a23",
"allwinner,sun8i-a33",
"allwinner,sun8i-a83t",
+ "allwinner,sun8i-h2plus",
"allwinner,sun8i-h3",
NULL,
};
--
2.10.1
^ permalink raw reply related
* [PATCH v2 1/2] regulator: Add coupled regulator
From: Mark Brown @ 2016-11-11 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107154738.ewliwzx5plams4ni@lukather>
On Mon, Nov 07, 2016 at 04:47:38PM +0100, Maxime Ripard wrote:
> Since regulator_get returns a struct regulator pointer, it felt
> logical to try to add the list of parent regulators to it, especially
> as this structure is per-consumer, and different consumers might have
> different combinations of regulators.
> However, this structure embeds a pointer to a struct regulator_dev,
> which seems to model the regulator itself, but will also contain
> pointer to the struct regulator, probably to model its parent? I guess
It'd be a lot easier to follow this if you named the fields... The rdev
in the struct regulator is indeed the physical device. The struct
regulator called supply in struct regulator_dev is indeed the parent
regulator.
> my first question would be do we care about nesting? or having a
> regulator with multiple parents?
Well, it seems that your use case here is multiple parents so I guess we
do care about it. :)
> It also contains the constraints on each regulator, which might or
> might not be different for each of the coupled regulators, but I'm
> guessing the couple might have contraints of its own too I guess. Is
> it something that might happen? Should we care about it?
I can't see how one could physically have constraints that didn't apply
to both parents.
> And finally, my real question is, do we want to aggregate them in
> struct regulator, at the consumer level, which might make the more
> sense, or do we want to create an intermediate regulator internally?
> What is your take on this?
My initial thought without having tried to implement this is that doing
things in an intermediate regulator might do a better job of
encapsulating things it if it works out but I've got a feeling that it's
not going to work out well and that therefore doing it in the consumer
with multiple rdevs will be better. But really either approach is fine
if it doesn't look horrible.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161111/8ecde8e8/attachment.sig>
^ permalink raw reply
* [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback
From: Auger Eric @ 2016-11-11 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111162211.GU2078@8bytes.org>
Hi Joerg,
On 11/11/2016 17:22, Joerg Roedel wrote:
> Hi Eric,
>
> On Fri, Nov 11, 2016 at 04:47:01PM +0100, Auger Eric wrote:
>> Effectively in passthrough use case, the userspace defines the address
>> space layout and maps guest RAM PA=IOVA to PAs (using
>> VFIO_IOMMU_MAP_DMA). But this address space does not comprise the MSI
>> IOVAs. Userspace does not care about MSI IOMMU mapping. So the MSI IOVA
>> region must be allocated by either the VFIO driver or the IOMMU driver I
>> think. Who else could initialize the IOVA allocator domain?
>
> So I think we need a way to tell userspace about the reserved regions
> (per iommu-group) so that userspace knows where it can not map anything,
Current plan is to expose that info through an iommu-group sysfs
attribute, as you and Robin advised.
> and VFIO can enforce that. But the right struct here is not an
> iova-allocator rb-tree, a ordered linked list should be sufficient.
I plan a linked list to store the reserved regions (P2P regions, MSI
region, ...). get_dma_regions is called with a list local to a function
for that. Might be needed to move that list head in the iommu_group to
avoid calling the get_dm_regions again in the attribute show function?
But to allocate the IOVAs within the MSI reserved region, I understand
you don't want us to use the iova.c allocator, is that correct? We need
an allocator though, even a very basic one based on bitmap or whatever.
There potentially have several different physical MSI frame pages to map.
Best Regards
Eric
>
>
> Joerg
>
^ permalink raw reply
* [PATCH] ARM: davinci: enable PM for DT boot
From: Kevin Hilman @ 2016-11-11 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6c73eab0-dadd-f8a0-f822-84296d319443@ti.com>
Sekhar Nori <nsekhar@ti.com> writes:
> On Tuesday 08 November 2016 11:43 PM, Kevin Hilman wrote:
>> Hi Sekhar,
>>
>> Sekhar Nori <nsekhar@ti.com> writes:
>>
>>> On Wednesday 26 October 2016 03:17 AM, Kevin Hilman wrote:
>>>> Currently system PM is only enabled for legacy (non-DT) boot. Enable
>>>> for DT boot also.
>>>>
>>>> Tested on da850-lcdk using "rtcwake -m mem -s5 -d rtc0".
>>>>
>>>> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
>>>> ---
>>>> arch/arm/mach-davinci/da8xx-dt.c | 18 ++++++++++++++++++
>>>> 1 file changed, 18 insertions(+)
>>>>
>>>> diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
>>>> index c9f7e9274aa8..a8089fa40d86 100644
>>>> --- a/arch/arm/mach-davinci/da8xx-dt.c
>>>> +++ b/arch/arm/mach-davinci/da8xx-dt.c
>>>> @@ -43,8 +43,26 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
>>>>
>>>> #ifdef CONFIG_ARCH_DAVINCI_DA850
>>>>
>>>> +static struct davinci_pm_config da850_pm_pdata = {
>>>> + .sleepcount = 128,
>>>> +};
>>>> +
>>>> +static struct platform_device da850_pm_device = {
>>>> + .name = "pm-davinci",
>>>> + .dev = {
>>>> + .platform_data = &da850_pm_pdata,
>>>> + },
>>>> + .id = -1,
>>>> +};
>>>> +
>>>> static void __init da850_init_machine(void)
>>>> {
>>>> + int ret;
>>>> +
>>>> + ret = da850_register_pm(&da850_pm_device);
>>>
>>> I am not sure if it makes sense to keep the "pm device" around anymore.
>>> I think for both DT and non-DT boot, we can get rid of the fake PM
>>> device and combine da850_register_pm() and davinci_pm_probe() into a
>>> single davinci_init_suspend() function which can then be called both for
>>> DT and non-DT boot.
>>
>> Looking closer at this, where do you propose the pdata comes from for
>> the non-DT boot?
>>
>> It seems to me that we can't currently remove the pdata dependency
>> without breaking the non-DT platforms, so the approach proposed here is
>> the least invasive.
>
> There is a single value of sleep count that is used today (128). So I
> was thinking we can hardcode that in pm.c. We are not going to add more
> board files anyway so there is no risk here.
>
> For future, if a different sleepcount value is needed, it will need to
> be a new DT property.
Right, but getting rid of the pdata is more than just hard-coding the
sleep count. There are a bunch of other fields in the pdata, which are
filled out to some standard defaults in da850.c. Are you proposing to
hard-code those in pm.c also?
An intermediate step might be to start by removing the
platform_device/pdata from the board files, but keep it in da850.c for
now. Then, a follow-up cleanup could be done to either move all of that
into pm.c, or use DT.
Kevin
^ permalink raw reply
* [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic
From: Joerg Roedel @ 2016-11-11 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <552e674a-f434-f08f-8e16-a94544ce8e6e@arm.com>
On Fri, Nov 11, 2016 at 04:17:37PM +0000, Robin Murphy wrote:
> In the original of_iommu_configure design, the thought was that an ops
> structure could be IOMMU-instance-specific (hence the later-removed
> "priv" member), so I suppose right now it is mostly a hangover from
> that. However, it's also what we initialise a device's fwspec with, so
> becomes important again if we're ever going to get past the limitations
> of buses-which-are-not-actually-buses[1].
Yeah, I discussed this with a few others at LPC. My current idea is to
tell the iommu-core which hardware-iommus exist in the system and a
seperate iommu_ops ptr for each of them. Then every struct device can
link to the iommu-instance it is translated by.
We are not there yet, but this will give you the same per-device
iommu-ops as implemented here.
Joerg
^ permalink raw reply
* Summary of LPC guest MSI discussion in Santa Fe
From: Don Dutile @ 2016-11-11 16:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111085056.4cf8989d@t450s.home>
On 11/11/2016 10:50 AM, Alex Williamson wrote:
> On Fri, 11 Nov 2016 12:19:44 +0100
> Joerg Roedel <joro@8bytes.org> wrote:
>
>> On Thu, Nov 10, 2016 at 10:46:01AM -0700, Alex Williamson wrote:
>>> In the case of x86, we know that DMA mappings overlapping the MSI
>>> doorbells won't be translated correctly, it's not a valid mapping for
>>> that range, and therefore the iommu driver backing the IOMMU API
>>> should describe that reserved range and reject mappings to it.
>>
>> The drivers actually allow mappings to the MSI region via the IOMMU-API,
>> and I think it should stay this way also for other reserved ranges.
>> Address space management is done by the IOMMU-API user already (and has
>> to be done there nowadays), be it a DMA-API implementation which just
>> reserves these regions in its address space allocator or be it VFIO with
>> QEMU, which don't map RAM there anyway. So there is no point of checking
>> this again in the IOMMU drivers and we can keep that out of the
>> mapping/unmapping fast-path.
>
> It's really just a happenstance that we don't map RAM over the x86 MSI
> range though. That property really can't be guaranteed once we mix
> architectures, such as running an aarch64 VM on x86 host via TCG.
> AIUI, the MSI range is actually handled differently than other DMA
> ranges, so a iommu_map() overlapping a range that the iommu cannot map
> should fail just like an attempt to map beyond the address width of the
> iommu.
>
+1. As was stated at Plumbers, x86 MSI is in a fixed, hw location, so:
1) that memory space is never a valid page to the system to be used for IOVA,
therefore, nothing to micro-manage in the iommu mapping (fast) path.
2) migration btwn different systems isn't an issue b/c all x86 systems have this mapping.
3) ACS resolves DMA writes to mem going to a device(-mmio space).
For aarch64, without such a 'fixed' MSI location, whatever hole/used-space-struct
concept that is contrived for MSI (DMA) writes on aarch64 won't guarantee migration
failure across mixed aarch64 systems (migrate guest-G from sys-vendor-A to
sys-vendor-B; sys-vendor-A has MSI at addr-A; sys-vendor-B has MSI at addr-B).
Without agreement, migration only possilbe across the same systems (can even
be broken btwn two sytems from same vendor). ACS in the PCIe path handles
the iova->dev-mmio collision problem. q.e.d.
ergo, my proposal to put MSI space as the upper-most, space of any system....
FFFF.FFFF.FFFE0.0000 ... and hw drops the upper 1's/F's, and uses that for MSI.
Allows it to vary on each system based on max-memory. pseudo-fixed, but not
right smack in the middle of mem-space.
There is an inverse scenario for host phys addr's as well:
Wiring the upper-most bit of HPA to be 1==mmio, 0=mem simplifies a lot of
design issues in the cores & chipsets as well. Alpha-EV6, case in point
(18+ yr old design decision). another q.e.d.
I hate to admit it, but jcm has it right wrt 'fixed sys addr map', at least in this IO area.
>>> For PCI devices userspace can examine the topology of the iommu group
>>> and exclude MMIO ranges of peer devices based on the BARs, which are
>>> exposed in various places, pci-sysfs as well as /proc/iomem. For
>>> non-PCI or MSI controllers... ???
>>
>> Right, the hardware resources can be examined. But maybe this can be
>> extended to also cover RMRR ranges? Then we would be able to assign
>> devices with RMRR mappings to guests.
>
> RMRRs are special in a different way, the VT-d spec requires that the
> OS honor RMRRs, the user has no responsibility (and currently no
> visibility) to make that same arrangement. In order to potentially
> protect the physical host platform, the iommu drivers should prevent a
> user from remapping RMRRS. Maybe there needs to be a different
> interface used by untrusted users vs in-kernel drivers, but I think the
> kernel really needs to be defensive in the case of user mappings, which
> is where the IOMMU API is rooted. Thanks,
>
> Alex
>
^ permalink raw reply
* [PATCH RFC 00/12] tda998x updates
From: Jyri Sarha @ 2016-11-11 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111152700.GD1041@n2100.armlinux.org.uk>
On 11/11/16 17:27, Russell King - ARM Linux wrote:
> On Fri, Nov 11, 2016 at 05:10:09PM +0200, Jyri Sarha wrote:
>> On 11/08/16 14:24, Russell King - ARM Linux wrote:
>>> As no one responded to the previous round, I'm not spending soo much
>>> time writing up a description of these changes again. It's also been
>>> quite a long time, so I've forgotten all the details of the changes,
>>> so I'll do my best.
>>>
>>> Changes from the previous series include:
>>> - reorder the initial three patches
>>> - change the (now third patch)... I think to increase the size of the
>>> locked region.
>>> - fix edid parsing for infoframe generation - as was pointed out for
>>> dw-hdmi, parsing the EDID in get_modes() is incorrect, as that method
>>> will not be called when an override-edid is in effect. We need to
>>> parse the override-edid. Moreover, infoframe generation should not
>>> be keyed to whether the monitor is HDMI or not, CEA-861B allows non-
>>> HDMI to send infoframes.
>>> - only send audio if audio and infoframes are supported.
>>>
>>> Otherwise, these are very much like the previous posting of the series,
>>> except rebased upon the mali/hdlcd/tda998x change to remove the
>>> drm_connector_register() call.
>>>
>>> https://www.spinics.net/lists/dri-devel/msg121495.html
>>>
>>> It'd be nice to have other tda998x users ack and test these patches,
>>> I've tried to test on Juno, but the Juno situation seems to be a huge
>>> fail. (HBI0282B completely fails with latest firmware - (a) FPGA image
>>> incompatibilities io_b118 causes all FPGA AMBA devices to vanish, (b)
>>> seems no way to get SCPI support on it - adding the BL0 executable
>>> start address in the SCC registers seems to be incompatible with the
>>> devchip, causing the PLLs to fail. In discussion with Sudeep over
>>> these issues, but no idea where things are with it at the moment, other
>>> than Sudeep needs to investigate. All Linaro firmware releases are
>>> broken on HBI0282B.)
>>>
>>> drivers/gpu/drm/i2c/tda998x_drv.c | 826 ++++++++++++++++++++------------------
>>> 1 file changed, 429 insertions(+), 397 deletions(-)
>>>
>>
>> Reviewed-by: Jyri Sarha <jsarha@ti.com>
>>
>> For the whole series. I am also happy to test these patches if I can
>> fetch them from some git repo.
>
> git://git.armlinux.org.uk/~rmk/linux-arm.git drm-tda998x-devel
>
> The commit IDs are unstable, because I'll have to recommit them to add
> your r-by and any other tags you later give me. :)
>
I tested the branch with my Beaglebone-black and couple of TVs. I played
audio on different sample-rates while plugging and unplugging the cable
to the TVs and changing video modes. Everything worked as it should. I
let you decide whether or not this adhoc testing qualifies:
Tested-by: Jyri Sarha <jsarha@ti.com>
Best regards,
Jyri
^ permalink raw reply
* [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback
From: Joerg Roedel @ 2016-11-11 16:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79da09b8-ac1e-cebf-5393-7d67f002b3e3@redhat.com>
Hi Eric,
On Fri, Nov 11, 2016 at 04:47:01PM +0100, Auger Eric wrote:
> Effectively in passthrough use case, the userspace defines the address
> space layout and maps guest RAM PA=IOVA to PAs (using
> VFIO_IOMMU_MAP_DMA). But this address space does not comprise the MSI
> IOVAs. Userspace does not care about MSI IOMMU mapping. So the MSI IOVA
> region must be allocated by either the VFIO driver or the IOMMU driver I
> think. Who else could initialize the IOVA allocator domain?
So I think we need a way to tell userspace about the reserved regions
(per iommu-group) so that userspace knows where it can not map anything,
and VFIO can enforce that. But the right struct here is not an
iova-allocator rb-tree, a ordered linked list should be sufficient.
Joerg
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox