Am Dienstag, 7. August 2018, 10:54:05 CEST schrieb Marc Zyngier:
> pm_runtime_get_if_in_use can fail: either PM has been disabled
> altogether (-EINVAL), or the device hasn't been enabled yet (0).
> Sadly, the Rockchip IOMMU driver tends to conflate the two things
> by considering a non-zero return
Am Dienstag, 7. August 2018, 16:25:53 CEST schrieb Marc Zyngier:
> On 07/08/18 14:15, Heiko Stuebner wrote:
> > Am Dienstag, 7. August 2018, 14:31:49 CEST schrieb Marc Zyngier:
> >> On 07/08/18 13:09, Heiko Stuebner wrote:
> >>> Hi Marc,
> >>>
> >>> Am Dienstag, 7. August 2018, 10:54:05 CEST schrie
On Tue, Aug 07, 2018 at 07:19:27PM -0500, Richard Kuo wrote:
> I am here, and I have the patch queued up but it's waiting for approval
> before I get to push it out through my tree.
>
> That said, I am perfectly fine with this going through a different tree
> if expedience is needed.
I just want
在 2018年08月06日 星期一 08:27 下午, Pavel Machek 写道:
Hi!
WarpDrive is a common user space accelerator framework. Its main component
in Kernel is called spimdev, Share Parent IOMMU Mediated Device. It exposes
spimdev is really unfortunate name. It looks like it has something to do with
SPI, but
it
在 2018年08月07日 星期二 01:05 上午, Alex Williamson 写道:
On Mon, 6 Aug 2018 09:34:28 -0700
"Raj, Ashok" wrote:
On Mon, Aug 06, 2018 at 09:49:40AM -0600, Alex Williamson wrote:
On Mon, 6 Aug 2018 09:40:04 +0800
Kenneth Lee wrote:
1. It supports thousands of processes. Take zip accelerator as an exa
在 2018年08月06日 星期一 11:32 下午, Jerome Glisse 写道:
On Mon, Aug 06, 2018 at 11:12:52AM +0800, Kenneth Lee wrote:
On Fri, Aug 03, 2018 at 10:39:44AM -0400, Jerome Glisse wrote:
On Fri, Aug 03, 2018 at 11:47:21AM +0800, Kenneth Lee wrote:
On Thu, Aug 02, 2018 at 10:22:43AM -0400, Jerome Glisse wrote
On Tue, Aug 07, 2018 at 09:01:36AM +0200, Christoph Hellwig wrote:
> On Tue, Jul 31, 2018 at 05:22:29PM +0200, Christoph Hellwig wrote:
> > On Wed, Jul 25, 2018 at 06:39:27AM +0200, Christoph Hellwig wrote:
> > > On Tue, Jul 24, 2018 at 10:29:48PM -0500, Richard Kuo wrote:
> > > > Patch series look
On Wed, Jul 25, 2018 at 01:24:36PM -0500, thor.tha...@linux.intel.com wrote:
> From: Thor Thayer
>
> Add SMMU support to the Stratix10 Device Tree which
> includes adding the SMMU node and adding IOMMU stream
> ids to the SMMU peripherals. Update bindings.
>
> Signed-off-by: Thor Thayer
> ---
>
Replace chain_dma_pool with direct calls to dma_alloc_coherent() and
dma_free_coherent(). Since the chain lookup can involve hundreds of
thousands of allocations, it is worthwile to avoid the overhead of the
dma_pool API.
Signed-off-by: Tony Battersby
---
No changes since v1.
The original code
Prevent a possible endless loop with DMAPOOL_DEBUG enabled if a buggy
driver corrupts DMA pool memory.
Signed-off-by: Tony Battersby
---
Changes since v2:
This is closer to the improved version from "dmapool: reduce footprint
in struct page" in v2 thanks to a previous patch adding blks_per_alloc
The "total number of blocks in pool" debug statistic currently does not
take the boundary value into account, so it diverges from the "total
number of blocks in use" statistic when a boundary is in effect. Add a
calculation for the number of blocks per allocation that takes the
boundary into accou
To represent the size of a single allocation, dmapool currently uses
'unsigned int' in some places and 'size_t' in other places. Standardize
on 'unsigned int' to reduce overhead, but use 'size_t' when counting all
the blocks in the entire pool.
Signed-off-by: Tony Battersby
---
This was split o
Remove a small amount of code duplication between dma_pool_destroy() and
pool_free_page() in preparation for adding more code without having to
duplicate it. No functional changes.
Signed-off-by: Tony Battersby
---
No changes since v2.
--- linux/mm/dmapool.c.orig 2018-08-02 09:59:15.00
dma_pool_free() scales poorly when the pool contains many pages because
pool_find_page() does a linear scan of all allocated pages. Improve its
scalability by replacing the linear scan with virt_to_page() and storing
dmapool private data directly in 'struct page', thereby eliminating
'struct dma_p
Rename fields in 'struct dma_page' in preparation for moving them into
'struct page'. No functional changes.
in_use -> dma_in_use
offset -> dma_free_off
Signed-off-by: Tony Battersby
---
Changes since v2:
Use dma_free_off instead of dma_free_o.
--- linux/mm/dmapool.c.orig 2018-08-03 17:46
dma_pool_alloc() scales poorly when allocating a large number of pages
because it does a linear scan of all previously-allocated pages before
allocating a new one. Improve its scalability by maintaining a separate
list of pages that have free blocks ready to (re)allocate. In big O
notation, this
dmapool originally tried to support pools without a device because
dma_alloc_coherent() supports allocations without a device. But nobody
ended up using dma pools without a device, so the current checks in
dmapool.c for pool->dev == NULL are both insufficient and causing bloat.
Remove them.
Signe
Fix the boundary comparison when constructing the list of free blocks
for the case that 'size' is a power of two. Since 'boundary' is also a
power of two, that would make 'boundary' a multiple of 'size', in which
case a single block would never cross the boundary. This bug would
cause some of the
Major changes since v2:
*) Addressed review comments.
*) Changed the description of patch #2.
*) Dropped "dmapool: reduce footprint in struct page", but split off
parts of it for merging (patches #7 and #8) and used it to improve
patch #9.
---
drivers/scsi/mpt3sas is running into a scala
On 07/08/18 14:15, Heiko Stuebner wrote:
> Am Dienstag, 7. August 2018, 14:31:49 CEST schrieb Marc Zyngier:
>> On 07/08/18 13:09, Heiko Stuebner wrote:
>>> Hi Marc,
>>>
>>> Am Dienstag, 7. August 2018, 10:54:05 CEST schrieb Marc Zyngier:
pm_runtime_get_if_in_use can fail: either PM has been di
Yonu, Fenghua,
any chance you could look over these patches for 4.19? That would
make my life for the next merge window a lot easier.
On Wed, Aug 01, 2018 at 06:02:43PM +0200, Christoph Hellwig wrote:
> Hi all,
>
> this is a resend of the last two series plus additional cleanups. The
> driver
Am Dienstag, 7. August 2018, 14:31:49 CEST schrieb Marc Zyngier:
> On 07/08/18 13:09, Heiko Stuebner wrote:
> > Hi Marc,
> >
> > Am Dienstag, 7. August 2018, 10:54:05 CEST schrieb Marc Zyngier:
> >> pm_runtime_get_if_in_use can fail: either PM has been disabled
> >> altogether (-EINVAL), or the de
On 07/08/18 13:09, Heiko Stuebner wrote:
> Hi Marc,
>
> Am Dienstag, 7. August 2018, 10:54:05 CEST schrieb Marc Zyngier:
>> pm_runtime_get_if_in_use can fail: either PM has been disabled
>> altogether (-EINVAL), or the device hasn't been enabled yet (0).
>> Sadly, the Rockchip IOMMU driver tends t
Hi Marc,
Am Dienstag, 7. August 2018, 10:54:05 CEST schrieb Marc Zyngier:
> pm_runtime_get_if_in_use can fail: either PM has been disabled
> altogether (-EINVAL), or the device hasn't been enabled yet (0).
> Sadly, the Rockchip IOMMU driver tends to conflate the two things
> by considering a non-z
Am Dienstag, 7. August 2018, 10:54:06 CEST schrieb Marc Zyngier:
> Enabling the interrupt early, before power has been applied to the
> device, can result in an interrupt being delivered too early if:
>
> - the IOMMU shares an interrupt with a VOP
> - the VOP has a pending interrupt (after a kexec
As an optimisation for PCI devices, there is always first attempt
been made to allocate iova from SAC address range. This will lead
to unnecessary attempts/function calls, when there are no free ranges
available.
This patch optimises by adding flag to track previous failed attempts
and avoids furt
Enabling the interrupt early, before power has been applied to the
device, can result in an interrupt being delivered too early if:
- the IOMMU shares an interrupt with a VOP
- the VOP has a pending interrupt (after a kexec, for example)
In these conditions, we end-up taking the interrupt without
This small series addresses a couple of runtime PM issues I've spotted
while running 4.18 on a Chromebook Plus (kevin, rk3399) platform, and
specifically doing kexec.
Note that even with these two patches, kexec is still fairly broken on
rk3399, as the VOP is never turned off (see [1] for a fix).
pm_runtime_get_if_in_use can fail: either PM has been disabled
altogether (-EINVAL), or the device hasn't been enabled yet (0).
Sadly, the Rockchip IOMMU driver tends to conflate the two things
by considering a non-zero return value as successful.
This has the consequence of hiding other bugs, so
29 matches
Mail list logo
