On 07/27/2018 05:35 PM, Andy Shevchenko wrote:
> On Sat, Jul 28, 2018 at 12:27 AM, Tony Battersby
> wrote:
>> On 07/27/2018 03:38 PM, Tony Battersby wrote:
>>> But the bigger problem is that my first patch adds another list_head to
>>> the dma_page for the avail_page_link to make allocations fast
On Sat, Jul 28, 2018 at 12:27 AM, Tony Battersby wrote:
> On 07/27/2018 03:38 PM, Tony Battersby wrote:
>> But the bigger problem is that my first patch adds another list_head to
>> the dma_page for the avail_page_link to make allocations faster. I
>> suppose we could make the lists singly-linked
On 07/27/2018 03:38 PM, Tony Battersby wrote:
> But the bigger problem is that my first patch adds another list_head to
> the dma_page for the avail_page_link to make allocations faster. I
> suppose we could make the lists singly-linked instead of doubly-linked
> to save space.
>
I managed to red
Hi Christoph.
Some observations below - nitpick and bikeshedding only.
The parameter of phys_addr_t is sometimes renamed
to use the same name as in the original prototype (good),
and sometimes uses the old name (bad).
This makes it inconsistent as the local name changes in the
different functions
On 2018-07-27 7:45 PM, Grygorii Strashko wrote:
[...]
But I have a question to all:
- The patch [1] sets default DMA mask to DMA_BIT_MASK(32)
+ dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ if (!dev->dev.dma_mask)
+ dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
th
On 07/27/2018 03:11 PM, Robin Murphy wrote:
> On 2018-07-27 6:45 PM, Grygorii Strashko wrote:
>> On 07/23/2018 05:16 PM, Robin Murphy wrote:
>>> 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
>>> genera
On 2018-07-27 6:45 PM, Grygorii Strashko wrote:
On 07/23/2018 05:16 PM, Robin Murphy wrote:
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
On Friday, 27 July 2018 21:31:34 MSK Joerg Roedel wrote:
> On Fri, Jul 27, 2018 at 11:13:31AM -0600, Rob Herring wrote:
> > I don't follow why we need a property rather than being implied by the
> > device's (the GPU) compatible string.
>
> There might be devices where either setup works, with or
On 2018-07-27 6:34 PM, Grygorii Strashko wrote:
On 07/27/2018 06:36 AM, Robin Murphy wrote:
On 27/07/18 01:22, Grygorii Strashko wrote:
[...]
the result of this change is pretty strange as for me :(
Resulted code:
/*
* If @dev is expected to be DMA-capable then the bus code that
crea
On 07/27/2018 11:23 AM, Matthew Wilcox wrote:
> On Fri, Jul 27, 2018 at 09:23:30AM -0400, Tony Battersby wrote:
>> On 07/26/2018 08:07 PM, Matthew Wilcox wrote:
>>> If you're up for more major surgery, then I think we can put all the
>>> information currently stored in dma_page into struct page. S
On 2018-07-27 7:13 PM, Russell King - ARM Linux wrote:
On Fri, Jul 27, 2018 at 12:36:00PM +0100, Robin Murphy wrote:
That is intentional. Consider a 32-bit device on a bus with an upstream DMA
range of 40 bits (which could easily happen with e.g. PCI). If the firmware
code gives that device 40-b
On 07/27/2018 01:13 PM, Russell King - ARM Linux wrote:
> On Fri, Jul 27, 2018 at 12:36:00PM +0100, Robin Murphy wrote:
>> That is intentional. Consider a 32-bit device on a bus with an upstream DMA
>> range of 40 bits (which could easily happen with e.g. PCI). If the firmware
>> code gives that
On Fri, Jul 27, 2018 at 11:13:31AM -0600, Rob Herring wrote:
> I don't follow why we need a property rather than being implied by the
> device's (the GPU) compatible string.
There might be devices where either setup works, with or without IOMMU
translation, and the firmware can set the property de
On 07/24/2018 03:21 PM, Christoph Hellwig wrote:
> On Tue, Jul 24, 2018 at 02:01:42PM +0200, Christoph Hellwig wrote:
>> 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 ar
On Fri, Jul 27, 2018 at 12:36:00PM +0100, Robin Murphy wrote:
> That is intentional. Consider a 32-bit device on a bus with an upstream DMA
> range of 40 bits (which could easily happen with e.g. PCI). If the firmware
> code gives that device 40-bit DMA masks and the driver doesn't change them,
> t
On 07/23/2018 05:16 PM, Robin Murphy wrote:
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
On 07/27/2018 06:36 AM, Robin Murphy wrote:
On 27/07/18 01:22, Grygorii Strashko wrote:
[...]
the result of this change is pretty strange as for me :(
Resulted code:
/*
* If @dev is expected to be DMA-capable then the bus code that
created
* it should have initialised its dma_m
mips_swiotlb_ops differs from the generic swiotlb_dma_ops only in that
it contains a mb() barrier after each operations that maps or syncs
dma memory to the device.
The dma operations are defined to not be memory barriers, but instead
the write* operations to kick the DMA off are supposed to conta
On 07/27/2018 05:55 AM, Robin Murphy wrote:
> Hi Grygorii,
>
> Thanks for the report.
>
> On 27/07/18 00:45, Grygorii Strashko wrote:
> [...]
>> With this series applied I can't boot TI ARM32 am574x-idk any more.
>>
>> And log output is full of "DMA mask not set" -
>
> That's somewhat expected
On Friday, 27 July 2018 20:03:26 MSK Jordan Crouse wrote:
> On Fri, Jul 27, 2018 at 05:02:37PM +0100, Robin Murphy wrote:
> > On 27/07/18 15:10, Dmitry Osipenko wrote:
> > >On Friday, 27 July 2018 12:03:28 MSK Will Deacon wrote:
> > >>On Fri, Jul 27, 2018 at 10:25:13AM +0200, Joerg Roedel wrote:
>
On Fri, Jul 27, 2018 at 8:20 AM Joerg Roedel wrote:
>
> On Fri, Jul 27, 2018 at 05:10:22PM +0300, Dmitry Osipenko wrote:
> > I'm not sure what you guys are meaning by the "firmware", could you
> > elaborate
> > please? Do you mean the Open Firmware and hence the devicetree or what?
>
> Yes, I thi
On Fri, Jul 27, 2018 at 05:02:37PM +0100, Robin Murphy wrote:
> On 27/07/18 15:10, Dmitry Osipenko wrote:
> >On Friday, 27 July 2018 12:03:28 MSK Will Deacon wrote:
> >>On Fri, Jul 27, 2018 at 10:25:13AM +0200, Joerg Roedel wrote:
> >>>On Fri, Jul 27, 2018 at 02:16:18AM +0300, Dmitry Osipenko wrote
On Fri, Jul 27, 2018 at 10:50:34AM -0600, Rob Herring wrote:
> On Fri, Jul 27, 2018 at 8:18 AM Robin Murphy wrote:
> >
> > On 27/07/18 15:20, Christoph Hellwig wrote:
> > > On Fri, Jul 27, 2018 at 03:14:15PM +0100, Robin Murphy wrote:
> > >> This shouldn't strictly depend on the changes currently
On Fri, Jul 27, 2018 at 8:18 AM Robin Murphy wrote:
>
> On 27/07/18 15:20, Christoph Hellwig wrote:
> > On Fri, Jul 27, 2018 at 03:14:15PM +0100, Robin Murphy wrote:
> >> This shouldn't strictly depend on the changes currently queued in the
> >> dma-mapping tree, so should be OK to go through the
Dave, can you take a review this and apply if ok? I've been
sending this twice already but never got an answer. Out of my
batch of conversion sparc is one of only two that haven't been
merged yet.
___
iommu mailing list
iommu@lists.linux-foundation.or
Switch to the generic noncoherent direct mapping implementation.
This removes the previous sync_single_for_device implementation, which
looks bogus given that no syncing is happening in the similar but more
important map_single case.
Signed-off-by: Christoph Hellwig
---
arch/sparc/Kconfig
On 27/07/18 13:56, Ganapatrao Kulkarni wrote:
[...]
did you get any chance to look in to this issue?
i am waiting for your suggestion/patch for this issue!
I got as far as [1], but I wasn't sure how much I liked it, since it still
seems a little invasive for such a specific case (plus I can't
On 27/07/18 15:10, Dmitry Osipenko wrote:
On Friday, 27 July 2018 12:03:28 MSK Will Deacon wrote:
On Fri, Jul 27, 2018 at 10:25:13AM +0200, Joerg Roedel wrote:
On Fri, Jul 27, 2018 at 02:16:18AM +0300, Dmitry Osipenko wrote:
The proposed solution adds a new option to the base device driver
str
On Fri, Jul 27, 2018 at 09:23:30AM -0400, Tony Battersby wrote:
> On 07/26/2018 08:07 PM, Matthew Wilcox wrote:
> > If you're up for more major surgery, then I think we can put all the
> > information currently stored in dma_page into struct page. Something
> > like this:
> >
> > +++ b/include/lin
On Fri, Jul 27, 2018 at 05:10:22PM +0300, Dmitry Osipenko wrote:
> I'm not sure what you guys are meaning by the "firmware", could you elaborate
> please? Do you mean the Open Firmware and hence the devicetree or what?
Yes, I think the best way to request this is using a device-tree
property. Let
On 27/07/18 15:20, Christoph Hellwig wrote:
On Fri, Jul 27, 2018 at 03:14:15PM +0100, Robin Murphy wrote:
This shouldn't strictly depend on the changes currently queued in the
dma-mapping tree, so should be OK to go through the DT tree in parallel.
Ideally we'd fix all DMA-capable drivers to set
On Fri, Jul 27, 2018 at 03:14:15PM +0100, Robin Murphy wrote:
> This shouldn't strictly depend on the changes currently queued in the
> dma-mapping tree, so should be OK to go through the DT tree in parallel.
> Ideally we'd fix all DMA-capable drivers to set their masks correctly,
> but in the shor
When of_dma_configure() was first born in 591c1ee465ce ("of: configure
the platform device dma parameters"), everything DMA-related was
factored out of of_platform_device_create_pdata() as seemed appropriate
at the time. However, now that of_dma_configure() has grown into the
generic handler for pr
On Friday, 27 July 2018 12:03:28 MSK Will Deacon wrote:
> On Fri, Jul 27, 2018 at 10:25:13AM +0200, Joerg Roedel wrote:
> > On Fri, Jul 27, 2018 at 02:16:18AM +0300, Dmitry Osipenko wrote:
> > > The proposed solution adds a new option to the base device driver
> > > structure that allows device dri
> That would be true if the test were "if
> (list_empty(&pool->avail_page_list))". But it is testing the list
> pointers in the item rather than the list pointers in the pool. It may
> be a bit confusing if you have never seen that usage before, which is
> why I added a comment. Basically, if y
On 07/26/2018 08:07 PM, Matthew Wilcox wrote:
> On Thu, Jul 26, 2018 at 04:06:05PM -0400, Tony Battersby wrote:
>> On 07/26/2018 03:42 PM, Matthew Wilcox wrote:
>>> On Thu, Jul 26, 2018 at 02:54:56PM -0400, Tony Battersby wrote:
dma_pool_free() scales poorly when the pool contains many pages b
On Fri, Jul 27, 2018 at 12:51:42PM +0100, Will Deacon wrote:
> The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
>
> Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.
Hi Robin,
On Wed, Jul 25, 2018 at 7:50 PM, Robin Murphy wrote:
> On 12/07/18 08:45, Ganapatrao Kulkarni wrote:
>>
>> Hi Robin,
>>
>>
>> On Mon, Jun 4, 2018 at 9:36 AM, Ganapatrao Kulkarni
>> wrote:
>>>
>>> ping??
>>>
>>> On Mon, May 21, 2018 at 6:45 AM, Ganapatrao Kulkarni
>>> wrote:
Hi Joerg,
Please pull these ARM SMMU updates for 4.19. Most of these are non-critical
fixes, but the main change is switching our default behaviour so that we
now abort transactions originating from unknown devices (i.e. those which
are not attached to an iommu domain) rather than silently let the
On 27/07/18 01:22, Grygorii Strashko wrote:
[...]
the result of this change is pretty strange as for me :(
Resulted code:
/*
* If @dev is expected to be DMA-capable then the bus code that created
* it should have initialised its dma_mask pointer by this point. For
Hi Grygorii,
Thanks for the report.
On 27/07/18 00:45, Grygorii Strashko wrote:
[...]
With this series applied I can't boot TI ARM32 am574x-idk any more.
And log output is full of "DMA mask not set" -
That's somewhat expected - as the relevant commit message mentions,
there will be bugs flu
On Fri, Jul 27, 2018 at 11:18:56AM +0200, Paul Menzel wrote:
> On the AMD site [1] I see the three family 0x17 documents below.
>
> 1. Open-Source Register Reference for AMD Family 17h Processors (PUB)
> 2. Processor Programming Reference (PPR) for AMD Family 17h Models 00h-0Fh
> Processors (PU
On 2018/7/27 17:48, Will Deacon wrote:
> On Fri, Jul 27, 2018 at 05:41:46PM +0800, Zhangshaokun wrote:
>> I saw it in your trees, is it necessary to Cc stable version?
>
> I don't think so, given that we don't actually support PRI upstream.
>
Got it, thanks your reply.
Shaokun
> Will
>
>> O
On Wed, Jul 25, 2018 at 5:27 PM, Will Deacon wrote:
> On Tue, Jul 24, 2018 at 03:09:41PM +0530, Vivek Gautam wrote:
>> On 7/24/2018 2:06 PM, Will Deacon wrote:
>> >On Thu, Jul 19, 2018 at 11:23:56PM +0530, Vivek Gautam wrote:
>> >>diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>>
On Fri, Jul 27, 2018 at 05:41:46PM +0800, Zhangshaokun wrote:
> I saw it in your trees, is it necessary to Cc stable version?
I don't think so, given that we don't actually support PRI upstream.
Will
> On 2018/7/23 20:56, Shaokun Zhang wrote:
> > From: Miao Zhong
> >
> > When PRI queue occurs
Hi Will,
I saw it in your trees, is it necessary to Cc stable version?
Cheers,
Shaokun
On 2018/7/23 20: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
>
On Fri, Jul 27, 2018 at 10:49:59AM +0800, Leizhen (ThunderTown) wrote:
> On 2018/7/26 22:16, Robin Murphy wrote:
> > On 2018-07-26 4:44 AM, Leizhen (ThunderTown) wrote:
> >> Passthrough is not enough to support VFIO, and virtualization need
> >> the later.
> >
> > Huh? The whole point of passthrou
Dear Jörg,
On 07/27/18 10:27, Jörg Rödel wrote:
> On Mon, Jul 23, 2018 at 12:09:37PM +0200, Paul Menzel wrote:
>>> or the BIOS did not enable the performance counter feature in the IOMMU
>>> hardware.
>>
>> Is it possible to check that from the OS side?
>
> It would be if we had the NB document
Hi Dmitry,
(CC'ing Geert and Magnus)
Thank you for the patch.
On Friday, 27 July 2018 00:19:16 EEST Dmitry Osipenko wrote:
> This fixes kernel crashing on NVIDIA Tegra if kernel is compiled in
> a multiplatform configuration and IPMMU-VMSA driver is enabled.
>
> Cc: # v3.20+
> Signed-off-by: D
On Fri, Jul 27, 2018 at 10:25:13AM +0200, Joerg Roedel wrote:
> On Fri, Jul 27, 2018 at 02:16:18AM +0300, Dmitry Osipenko wrote:
> > The proposed solution adds a new option to the base device driver
> > structure that allows device drivers to explicitly convey to the drivers
> > core that the impli
Hi Paul,
On Mon, Jul 23, 2018 at 12:09:37PM +0200, Paul Menzel wrote:
> > or the BIOS did not enable the performance counter feature in the IOMMU
> > hardware.
>
> Is it possible to check that from the OS side?
It would be if we had the NB documentation, but I guess those details
are not publicl
On Fri, Jul 27, 2018 at 02:16:18AM +0300, Dmitry Osipenko wrote:
> The proposed solution adds a new option to the base device driver
> structure that allows device drivers to explicitly convey to the drivers
> core that the implicit IOMMU backing for devices must not happen.
Why is IOMMU mapping a
On Wed, Jul 25, 2018 at 03:10:29PM +0200, Geert Uytterhoeven wrote:
> The Renesas IPMMU-VMSA driver supports not just R-Car H2 and M2 SoCs,
> but also other R-Car Gen2 and R-Car Gen3 SoCs.
>
> Drop a superfluous "Renesas" while at it.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/iommu/
On Fri, Jul 27, 2018 at 12:19:16AM +0300, Dmitry Osipenko wrote:
> This fixes kernel crashing on NVIDIA Tegra if kernel is compiled in
> a multiplatform configuration and IPMMU-VMSA driver is enabled.
>
> Cc: # v3.20+
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/iommu/ipmmu-vmsa.c | 7 +
On Fri, Jul 20, 2018 at 06:16:59PM +0200, Geert Uytterhoeven wrote:
> When attaching a device to an IOMMU group with
> CONFIG_DEBUG_ATOMIC_SLEEP=y:
>
> BUG: sleeping function called from invalid context at mm/slab.h:421
> in_atomic(): 1, irqs_disabled(): 128, pid: 61, name: kworker/1:1
>
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 v1
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
Signed-of
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 runtim
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.
With
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
r
60 matches
Mail list logo
