On Mon, Jul 23, 2018 at 04:20:42PM +0800, Ley Foon Tan wrote:
> On Thu, 2018-07-19 at 14:22 +0200, Christoph Hellwig wrote:
> > On Thu, Jul 19, 2018 at 01:48:55PM +0800, Ley Foon Tan wrote:
> > >
> > > Do you have git repo for this series of patches?
> > This patch should apply without the need fo
On Thu, 2018-07-19 at 14:22 +0200, Christoph Hellwig wrote:
> On Thu, Jul 19, 2018 at 01:48:55PM +0800, Ley Foon Tan wrote:
> >
> > Do you have git repo for this series of patches?
> This patch should apply without the need for any other patch
> to Linus' latest tree, but I have a tree with all th
Hi Jacopo,
On Mon, Jul 23, 2018 at 10:42 AM jacopo mondi wrote:
> I have a single comment on something I noticed which might be an
> implementation bug. On the overall patch architecture, it's very hard
> for me to provide a valuable opinion as it's all relatively new for me
> here :)
>
> On Thu,
Hi Christoph,
I have a single comment on something I noticed which might be an
implementation bug. On the overall patch architecture, it's very hard
for me to provide a valuable opinion as it's all relatively new for me
here :)
On Thu, Jul 19, 2018 at 06:05:15AM -0700, Christoph Hellwig wrote:
>
Dear Jörg,
On 07/20/18 14:31, Jörg Rödel wrote:
> On Tue, Jul 17, 2018 at 06:02:07PM +0200, Paul Menzel wrote:
>> $ dmesg
>> […]
>> [0.145696] calling pci_iommu_init+0x0/0x3f @ 1
>> [0.145719] AMD-Vi: Unable to write to IOMMU perf counter.
>
> This is likely a firmware issue. Either th
On Mon, Jul 23, 2018 at 7:59 AM, Marek Szyprowski
wrote:
> Hi Rafael,
>
> On 2018-07-11 22:36, Rafael J. Wysocki wrote:
>> On Wed, Jul 11, 2018 at 3:40 PM, Marek Szyprowski
>> wrote:
[cut]
>>> Frankly, if there are no other reasons I suggest to wire system
>>> suspend/resume to pm_runtime_force
From: Miao Zhong
When PRI queue occurs overflow, driver should update the OVACKFLG to
the PRIQ consumer register, otherwise subsequent PRI requests will not
be processed.
Cc: Will Deacon
Cc: Robin Murphy
Signed-off-by: Miao Zhong
---
drivers/iommu/arm-smmu-v3.c | 1 +
1 file changed, 1 inse
On 23/07/18 13:56, Shaokun Zhang wrote:
> From: Miao Zhong
>
> When PRI queue occurs overflow, driver should update the OVACKFLG to
> the PRIQ consumer register, otherwise subsequent PRI requests will not
> be processed.
Since the upstream driver doesn't enable PRI in endpoints, I'm not sure
thi
Hi Jean,
On 23/07/18 22:24, Miao Zhong wrote:
> From: Miao Zhong
>
> When PRI queue occurs overflow, driver should update the OVACKFLG to
> the PRIQ consumer register, otherwise subsequent PRI requests will not
> be processed.
>Since the upstream driver doesn't enable PRI in endpoints, I'm n
Hi,
On 23/07/18 15:43, Zhongmiao wrote:
> Yeah,I haven't tested smmu eventq overflow , so i'm not sure if there
> is any problem with smmu eventq. However, the code shows that there is also
> a problem after the smmu eventq overflows. ^_^…….
There really shouldn't be any problem with th
The reasons why dma_free_attrs() should not be called from IRQ context
are not necessarily obvious and somewhat buried in the development
history, so let's start by documenting the warning itself to help anyone
who does happen to hit it and wonder what the deal is.
However, this check turns out to
Whilst the common firmware code invoked by dma_configure() initialises
devices' DMA masks according to limitations described by the respective
properties ("dma-ranges" for OF and _DMA/IORT for ACPI), the nature of
the dma_set_mask() API leads to that information getting lost when
well-behaved drive
IORT revision D allows PCI root complex nodes to specify a memory
address size limit equivalently to named components, to help describe
straightforward integrations which don't really warrant a full-blown
_DMA method. Now that our headers are up-to-date, plumb it in.
If both _DMA and an address si
Whilst the notion of an upstream DMA restriction is most commonly seen
in PCI host bridges saddled with a 32-bit native interface, a more
general version of the same issue can exist on complex SoCs where a bus
or point-to-point interconnect link from a device's DMA master interface
to another compo
When an explicit DMA limit is described by firmware, we need to remember
it regardless of how drivers might subsequently update their devices'
masks. The new bus_dma_mask field does that.
CC: Lorenzo Pieralisi
CC: Hanjun Guo
CC: Sudeep Holla
Signed-off-by: Robin Murphy
---
drivers/acpi/arm64/
When an explicit DMA limit is described by firmware, we need to remember
it regardless of how drivers might subsequently update their devices'
masks. The new bus_dma_mask field does that.
CC: Rob Herring
CC: Frank Rowand
Signed-off-by: Robin Murphy
---
drivers/of/device.c | 1 +
1 file changed
Take the new bus limit into account (when present) for IOVA allocations,
to accommodate those SoCs which integrate off-the-shelf IP blocks with
narrower interconnects such that the link between a device output and an
IOMMU input can truncate DMA addresses to even fewer bits than the
native size of
Now that we can track upstream DMA constraints properly with
bus_dma_mask instead of trying (and failing) to maintain it in
coherent_dma_mask, it doesn't make much sense for the firmware code to
be touching the latter at all. It's merely papering over bugs wherein a
driver has failed to call dma_se
Now that we can track upstream DMA constraints properly with
bus_dma_mask instead of trying (and failing) to maintain it in
coherent_dma_mask, it doesn't make much sense for the firmware code to
be touching the latter at all. It's merely papering over bugs wherein a
driver has failed to call dma_se
Hi ,
>"Note: In terms of delivering events, a queue in an unacknowledged overflow
>state does not behave any differently to normal queue state. If software were
>to consume events and free space but leave overflow unacknowledged, new events
>could be recorded."
Yeah, I agree with you . But I
Hi Yi,
Thank you for reviewing my patch.
On 07/23/2018 12:44 PM, Liu, Yi L wrote:
> Hi Baolu,
>
> Per my understanding, the subject is not accurate. I think this patch is
> to get parent device structure for a mediate device instead of iommu
> device. This may be misleading for reviewers.
Please
Hi,
On 07/23/2018 12:44 PM, Liu, Yi L wrote:
>> From: Lu Baolu [mailto:baolu...@linux.intel.com]
>> Sent: Sunday, July 22, 2018 2:09 PM
>>
>> The PASID-granular 2nd level address translation makes it possible to
>> isolate and
>> protect a mediated device exposed by a real device which support PC
On Mon, 2018-07-23 at 10:27 +0200, Christoph Hellwig wrote:
> On Mon, Jul 23, 2018 at 04:20:42PM +0800, Ley Foon Tan wrote:
> >
> > On Thu, 2018-07-19 at 14:22 +0200, Christoph Hellwig wrote:
> > >
> > > On Thu, Jul 19, 2018 at 01:48:55PM +0800, Ley Foon Tan wrote:
> > > >
> > > >
> > > > Do yo
Hi,
On 07/23/2018 12:44 PM, Liu, Yi L wrote:
>> From: Lu Baolu [mailto:baolu...@linux.intel.com]
>> Sent: Sunday, July 22, 2018 2:09 PM
>>
>> With the Intel IOMMU supporting PASID granularity isolation and protection, a
>> mediated device could be isolated and protected by an IOMMU unit. We need t
Hi,
On 07/23/2018 12:44 PM, Liu, Yi L wrote:
>> From: Lu Baolu [mailto:baolu...@linux.intel.com]
>> Sent: Sunday, July 22, 2018 2:09 PM
>>
>> This configures the second level page table when external components request
>> to
>> allocate a domain for a mediated device.
> I think it should be the t
Hi,
On 24/07/18 12:45, Zhongmiao wrote:
> Yeah,I haven't tested smmu eventq overflow , so i'm not sure if there
> is any problem with smmu eventq. However, the code shows that there is also
> a problem after the smmu eventq overflows. ^_^…….
>There really shouldn't be any problem with
26 matches
Mail list logo
