On 07/20/18 at 01:06pm, lijiang wrote:
> 在 2018年07月14日 01:08, Borislav Petkov 写道:
> > On Mon, Jul 09, 2018 at 09:55:35PM +0800, lijiang wrote:
> >> About this issue, i want to use an example to describe it.
> >> /* drivers/iommu/amd_iommu_init.c */
> >> static u8 __iomem * __init
在 2018年07月14日 01:08, Borislav Petkov 写道:
> On Mon, Jul 09, 2018 at 09:55:35PM +0800, lijiang wrote:
>> About this issue, i want to use an example to describe it.
>> /* drivers/iommu/amd_iommu_init.c */
>> static u8 __iomem * __init iommu_map_mmio_space(u64 address, u64 end)
>
> Those addresses
On Wed, 2018-07-11 at 14:51 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2018-07-04 at 13:57 +0100, Robin Murphy wrote:
> >
> > > Could it ? I wouldn't think dma_map_page is allows to cross page
> > > boundaries ... what about single() ? The main worry is people using
> > > these things on
On Thu, Jul 19, 2018 at 11:54 AM Vivek Gautam
wrote:
>
> Add device node for arm,mmu-500 available on sdm845.
> This MMU-500 with single TCU and multiple TBU architecture
> is shared among all the peripherals except gpu on sdm845.
>
> Signed-off-by: Vivek Gautam
> ---
>
Currently we check if the number of context banks is not equal to
num_context_interrupts. However, there are booloaders such as, one
on sdm845 that reserves few context banks and thus kernel views
less than the total available context banks.
So, although the hardware definition in device tree
Add device node for qcom,smmu-v2 available on sdm845.
This smmu is available only to GPU device.
Signed-off-by: Vivek Gautam
---
One power domain required for this GPU smmu - GPU_CX_GDSC,
commented out in the node is coming from gpu clock controller [1].
[1]
Add device node for arm,mmu-500 available on sdm845.
This MMU-500 with single TCU and multiple TBU architecture
is shared among all the peripherals except gpu on sdm845.
Signed-off-by: Vivek Gautam
---
arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 4 ++
arch/arm64/boot/dts/qcom/sdm845.dtsi| 73
This series enables apps-smmu (arm,mmu-500) and gpu-smmu (qcom,smmu-v2)
on sdm845. gpu-smmu needs one power domain from gpu clock controller
whose driver was sent by Amit [1].
This series also contains a patch to split the check for num_context_irqs
and num_context_banks in two. We now error out
Hi Mathias,
On Thu, Jul 19, 2018 at 06:42:19PM +0300, Mathias Nyman wrote:
> > > As first aid I could try to implement checks that make sure the flushed
> > > URBs
> > > trb pointers really are on the current endpoint ring, and also add some
> > > warning
> > > if we are we are dropping
As first aid I could try to implement checks that make sure the flushed URBs
trb pointers really are on the current endpoint ring, and also add some warning
if we are we are dropping endpoints with URBs still queued.
Yes, please. I think your first-aid will be a much better option than
the
On Thu, 19 Jul 2018, Mathias Nyman wrote:
> xhci driver will set up all the endpoints for the new altsetting already in
> usb_hcd_alloc_bandwidth().
>
> New endpoints will be ready and rings running after this. I don't know the
> exact
> history behind this, but I assume it is because xhci does
On Wed, Jul 18, 2018 at 02:55:59PM -0700, Geoff Levand wrote:
> Hi,
>
> On 07/17/2018 09:33 AM, Fredrik Noring wrote:
> >>> Here are three other regressions related to the coherent mask
> >>> WARN_ON_ONCE:
> >>
> >> They are a pretty strong indication that yes, you should really set
> >> the
Hi all,
can you review these patches to switch sh to use the generic
dma-noncoherent code? All the requirements are in mainline already
and we've switched various architectures over to it already.
___
iommu mailing list
iommu@lists.linux-foundation.org
Switch to the generic noncoherent direct mapping implementation.
Signed-off-by: Christoph Hellwig
---
arch/sh/Kconfig | 3 +-
arch/sh/include/asm/Kbuild| 1 +
arch/sh/include/asm/dma-mapping.h | 26 ---
arch/sh/kernel/Makefile | 2 +-
Remove the indirection through the dma_ops variable, and just return
nommu_dma_ops directly from get_arch_dma_ops.
Signed-off-by: Christoph Hellwig
---
arch/sh/include/asm/dma-mapping.h | 5 ++---
arch/sh/kernel/dma-nommu.c| 8 +---
arch/sh/mm/consistent.c | 3 ---
This is a slight change in behavior as we avoid the detour through the
virtual mapping for the coherent allocator, but if this CPU really is
coherent that should be the right thing to do.
Signed-off-by: Christoph Hellwig
---
arch/sh/Kconfig | 1 +
Half of the file just contains platform device memory setup code which
is required for all builds, and half contains helpers for dma coherent
allocation, which is only needed if CONFIG_DMA_NONCOHERENT is enabled.
Signed-off-by: Christoph Hellwig
---
arch/sh/kernel/Makefile | 2 +-
And use it in the maple bus code to avoid a dma API dependency.
Signed-off-by: Christoph Hellwig
---
arch/sh/include/asm/cacheflush.h | 7 +++
arch/sh/mm/consistent.c | 6 +-
drivers/sh/maple/maple.c | 7 ---
3 files changed, 12 insertions(+), 8 deletions(-)
diff
Signed-off-by: Christoph Hellwig
---
arch/openrisc/kernel/dma.c | 23 ---
1 file changed, 23 deletions(-)
diff --git a/arch/openrisc/kernel/dma.c b/arch/openrisc/kernel/dma.c
index 47601274abf7..7cadff93d179 100644
--- a/arch/openrisc/kernel/dma.c
+++
Switch to the generic noncoherent direct mapping implementation.
Signed-off-by: Christoph Hellwig
---
arch/openrisc/Kconfig | 2 +
arch/openrisc/include/asm/Kbuild| 1 +
arch/openrisc/include/asm/dma-mapping.h | 35 -
arch/openrisc/kernel/dma.c
openrisc does all the required cache maintainance at dma map time, and none
at unmap time. It thus has to implement sync_single_for_device to match
the map cace for buffer reuse, but there is no point in doing another
invalidation in the sync_single_cpu_case, which in terms of cache
maintainance
The cache maintaince in the sync_single_for_device operation should be
equivalent to the map_page operation to facilitate reusing buffers. Fix the
openrisc implementation by moving the cache maintaince performed in map_page
into the sync_single method, and calling that from map_page.
Hi Openrisc maintainers,
can you review these patches to switch openrisc to use the generic
dma-noncoherent code? All the requirements are in mainline already
and we've switched various architectures over to it already.
___
iommu mailing list
Switch to the generic noncoherent direct mapping implementation.
Signed-off-by: Christoph Hellwig
---
arch/hexagon/Kconfig | 2 +
arch/hexagon/include/asm/Kbuild| 1 +
arch/hexagon/include/asm/dma-mapping.h | 40 ---
arch/hexagon/kernel/dma.c |
This methods needs to provide the equivalent of sync_single_for_device
for each S/G list element, but was missing.
Signed-off-by: Christoph Hellwig
---
arch/hexagon/kernel/dma.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/hexagon/kernel/dma.c
hexagon does all the required cache maintainance at dma map time, and none
at unmap time. It thus has to implement sync_single_for_device to match
the map cace for buffer reuse, but there is no point in doing another
invalidation in the sync_single_cpu_case, which in terms of cache
maintainance
Hi Richard,
can you review these patches to switch hexagon to use the generic
dma-noncoherent code? All the requirements are in mainline already
and we've switched various architectures over to it already.
___
iommu mailing list
Switch to the generic noncoherent direct mapping implementation.
This removes the direction-based optimizations in
sync_{single,sg}_for_{cpu,device} which were marked untestested and
do not match the usually very well tested {un,}map_{single,sg}
implementations.
Signed-off-by: Christoph Hellwig
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 the conversions
here:
Hi Mathias,
On Thu, Jul 19, 2018 at 01:59:01PM +0300, Mathias Nyman wrote:
> On 17.07.2018 18:10, Sudip Mukherjee wrote:
> > Hi Alan, Greg,
> >
> > On Tue, Jul 17, 2018 at 03:49:18PM +0100, Sudip Mukherjee wrote:
> > > On Tue, Jul 17, 2018 at 03:40:22PM +0100, Sudip Mukherjee wrote:
> > > > Hi
On 17.07.2018 18:10, Sudip Mukherjee wrote:
Hi Alan, Greg,
On Tue, Jul 17, 2018 at 03:49:18PM +0100, Sudip Mukherjee wrote:
On Tue, Jul 17, 2018 at 03:40:22PM +0100, Sudip Mukherjee wrote:
Hi Alan,
On Tue, Jul 17, 2018 at 10:28:14AM -0400, Alan Stern wrote:
On Tue, 17 Jul 2018, Sudip
qcom,smmu-v2 is an arm,smmu-v2 implementation with specific
clock and power requirements. This smmu core is used with
multiple masters on msm8996, viz. mdss, video, etc.
Add bindings for the same.
Signed-off-by: Vivek Gautam
Reviewed-by: Rob Herring
Reviewed-by: Tomasz Figa
---
Change since
From: Sricharan R
Finally add the device link between the master device and
smmu, so that the smmu gets runtime enabled/disabled only when the
master needs it. This is done from add_device callback which gets
called once when the master is added to the smmu.
Signed-off-by: Sricharan R
From: Sricharan R
The smmu device probe/remove and add/remove master device callbacks
gets called when the smmu is not linked to its master, that is without
the context of the master device. So calling runtime apis in those places
separately.
Signed-off-by: Sricharan R
[vivek: Cleanup pm
This series provides the support for turning on the arm-smmu's
clocks/power domains using runtime pm. This is done using
device links between smmu and client devices. The device link
framework keeps the two devices in correct order for power-cycling
across runtime PM or across system-wide PM.
From: Sricharan R
The smmu needs to be functional only when the respective
master's using it are active. The device_link feature
helps to track such functional dependencies, so that the
iommu gets powered when the master device enables itself
using pm_runtime. So by adapting the smmu driver for
On Wed, 2018-07-11 at 17:32 +0200, Christoph Hellwig wrote:
> ping? Any comments?
>
> On Tue, Jun 19, 2018 at 09:01:37AM +0200, Christoph Hellwig wrote:
> >
> > Switch to the generic noncoherent direct mapping implementation.
> >
> > Signed-off-by: Christoph Hellwig
> > ---
> >
On 2017/10/18 22:04, Robin Murphy wrote:
> Even without the MSI trick, we can still do a lot better than hogging
> the entire queue while it drains. All we actually need to do for the
> necessary guarantee of completion is wait for our particular command to
> have been consumed, and as long as
38 matches
Mail list logo
