On Thu, 2017-07-06 at 17:55 +0100, Robin Murphy wrote:
> Under certain circumstances, the io-pgtable code may end up issuing two
> TLB sync operations without any intervening invalidations. This goes
> badly for the M4U hardware, since it means the second sync ends up
> polling for a non-existent o
Hi Will,
On 7/6/17 8:08 AM, Will Deacon wrote:
> Hi Ray,
>
> Thanks for testing this, and sorry it didn't help.
>
> On Wed, Jul 05, 2017 at 04:24:22PM -0700, Ray Jui wrote:
>> On 7/5/17 1:41 AM, Will Deacon wrote:
>>> On Tue, Jul 04, 2017 at 06:45:17PM -0700, Ray Jui wrote:
Has anything fun
Under certain circumstances, the io-pgtable code may end up issuing two
TLB sync operations without any intervening invalidations. This goes
badly for the M4U hardware, since it means the second sync ends up
polling for a non-existent operation to finish, and as a result times
out and warns. The io
The tlb_sync_pending flag was necessary for correctness in the Mediatek
M4U driver, but since it offered a small theoretical optimisation for
all io-pgtable users it was implemented as a high-level thing. However,
now that some users may not be using a synchronising lock, there are
several ways thi
qcom,msm8996-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
---
Documentation/devicetree/bindings/iommu/arm,smmu.txt | 18 +
From: Sricharan R
The MMU400x/500 is the implementation of the SMMUv2
arch specification. It is split in to two blocks
TBU, TCU. TBU caches the page table, instantiated
for each master locally, clocked by the TBUn_clk.
TCU manages the address translation with PTW and has
the programming interface
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
---
driv
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
[stanimir: added runtime
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
fwspec->iommu_priv is available only after arm_smmu_master_cfg
instance has been allocated. We shouldn't free it before that.
Also it's logical to free the master cfg itself without
checking for fwspec.
Signed-off-by: Vivek Gautam
---
drivers/iommu/arm-smmu.c | 6 +++---
1 file changed, 3 insert
This series provides the support for turning on the arm-smmu's
clocks/power domains using runtime pm. This is done using the
recently introduced device links patches, which lets the symmu's
runtime to follow the master's runtime pm, so the smmu remains
powered only when the masters use it.
Took so
Hi Ray,
Thanks for testing this, and sorry it didn't help.
On Wed, Jul 05, 2017 at 04:24:22PM -0700, Ray Jui wrote:
> On 7/5/17 1:41 AM, Will Deacon wrote:
> > On Tue, Jul 04, 2017 at 06:45:17PM -0700, Ray Jui wrote:
> >> Has anything functionally changed between PATCH v2 and v1? I'm seeing a
> >
On Thu, Jul 6, 2017 at 11:35 PM, Arnd Bergmann wrote:
> On Thu, Jul 6, 2017 at 4:24 PM, Tomasz Figa wrote:
>> On Thu, Jul 6, 2017 at 11:17 PM, Tomasz Figa wrote:
>>> On Thu, Jul 6, 2017 at 11:10 PM, Christoph Hellwig wrote:
On Thu, Jul 06, 2017 at 12:09:45PM +0100, Robin Murphy wrote:
On Thu, Jul 6, 2017 at 11:27 PM, Arnd Bergmann wrote:
> On Thu, Jul 6, 2017 at 4:06 PM, Tomasz Figa wrote:
>> On Thu, Jul 6, 2017 at 11:02 PM, Arnd Bergmann wrote:
>>> On Thu, Jul 6, 2017 at 3:49 PM, Tomasz Figa wrote:
On Thu, Jul 6, 2017 at 10:31 PM, Tomasz Figa wrote:
>>>
> On the o
On Thu, Jul 6, 2017 at 4:24 PM, Tomasz Figa wrote:
> On Thu, Jul 6, 2017 at 11:17 PM, Tomasz Figa wrote:
>> On Thu, Jul 6, 2017 at 11:10 PM, Christoph Hellwig wrote:
>>> On Thu, Jul 06, 2017 at 12:09:45PM +0100, Robin Murphy wrote:
I suppose another option is to just make the IOMMU and DMA
On Thu, Jul 6, 2017 at 4:06 PM, Tomasz Figa wrote:
> On Thu, Jul 6, 2017 at 11:02 PM, Arnd Bergmann wrote:
>> On Thu, Jul 6, 2017 at 3:49 PM, Tomasz Figa wrote:
>>> On Thu, Jul 6, 2017 at 10:31 PM, Tomasz Figa wrote:
>>
On the other hand, if it's strictly about base/dma-mapping, we might
>
On Thu, Jul 6, 2017 at 11:17 PM, Tomasz Figa wrote:
> On Thu, Jul 6, 2017 at 11:10 PM, Christoph Hellwig wrote:
>> On Thu, Jul 06, 2017 at 12:09:45PM +0100, Robin Murphy wrote:
>>> I suppose another option is to just make the IOMMU and DMA ops a
>>> self-contained non-modular driver mirroring the
On Thu, Jul 6, 2017 at 11:10 PM, Christoph Hellwig wrote:
> On Thu, Jul 06, 2017 at 12:09:45PM +0100, Robin Murphy wrote:
>> I suppose another option is to just make the IOMMU and DMA ops a
>> self-contained non-modular driver mirroring the VT-d/AMD-Vi IOMMUs -
>> AFAICS it shouldn't have to be al
On Thu, Jul 6, 2017 at 11:02 PM, Arnd Bergmann wrote:
> On Thu, Jul 6, 2017 at 3:49 PM, Tomasz Figa wrote:
>> On Thu, Jul 6, 2017 at 10:31 PM, Tomasz Figa wrote:
>
>>> On the other hand, if it's strictly about base/dma-mapping, we might
>>> not need it indeed. The driver could call iommu-dma hel
On Thu, Jul 06, 2017 at 12:09:45PM +0100, Robin Murphy wrote:
> I suppose another option is to just make the IOMMU and DMA ops a
> self-contained non-modular driver mirroring the VT-d/AMD-Vi IOMMUs -
> AFAICS it shouldn't have to be all that tightly coupled to the IPU bus
> code, the latter more or
On Thu, Jul 6, 2017 at 3:49 PM, Tomasz Figa wrote:
> On Thu, Jul 6, 2017 at 10:31 PM, Tomasz Figa wrote:
>> On the other hand, if it's strictly about base/dma-mapping, we might
>> not need it indeed. The driver could call iommu-dma helpers directly,
>> without the need to provide its own DMA ops
On Thu, Jul 6, 2017 at 3:31 PM, Tomasz Figa wrote:
> On Thu, Jul 6, 2017 at 9:23 PM, Arnd Bergmann wrote:
>> On Thu, Jul 6, 2017 at 10:36 AM, Tomasz Figa wrote:
>>> On Thu, Jul 6, 2017 at 5:34 PM, Tomasz Figa wrote:
>>>
>>> Sorry, I intended to mean:
>>>
>>> IMHO re-implementing the code that's
On Thu, Jul 6, 2017 at 10:31 PM, Tomasz Figa wrote:
> On Thu, Jul 6, 2017 at 9:23 PM, Arnd Bergmann wrote:
>> On Thu, Jul 6, 2017 at 10:36 AM, Tomasz Figa wrote:
>>> On Thu, Jul 6, 2017 at 5:34 PM, Tomasz Figa wrote:
On Thu, Jul 6, 2017 at 5:26 PM, Arnd Bergmann wrote:
> On Thu, Jul 6
On Thu, Jul 6, 2017 at 9:23 PM, Arnd Bergmann wrote:
> On Thu, Jul 6, 2017 at 10:36 AM, Tomasz Figa wrote:
>> On Thu, Jul 6, 2017 at 5:34 PM, Tomasz Figa wrote:
>>> On Thu, Jul 6, 2017 at 5:26 PM, Arnd Bergmann wrote:
On Thu, Jul 6, 2017 at 3:44 AM, Tomasz Figa wrote:
>
>>>
>>> I'd say th
On Thu, Jul 6, 2017 at 10:36 AM, Tomasz Figa wrote:
> On Thu, Jul 6, 2017 at 5:34 PM, Tomasz Figa wrote:
>> On Thu, Jul 6, 2017 at 5:26 PM, Arnd Bergmann wrote:
>>> On Thu, Jul 6, 2017 at 3:44 AM, Tomasz Figa wrote:
>>
>> I'd say that this is something that has been consistently tried to be
>>
On 04.07.17 11:07:59, Lorenzo Pieralisi wrote:
> On Wed, Jun 28, 2017 at 07:47:50PM +0200, Robert Richter wrote:
> > On 15.06.17 14:46:03, Lorenzo Pieralisi wrote:
> > > On Thu, Jun 08, 2017 at 10:14:19AM +0530, Ganapatrao Kulkarni wrote:
> > > > Add code to parse proximity domain in SMMUv3 IORT ta
On 06/07/17 03:25, Tomasz Figa wrote:
> On Thu, Jul 6, 2017 at 1:22 AM, Robin Murphy wrote:
>> On 05/07/17 08:12, Tomasz Figa wrote:
>>> There is nothing wrong in having a loadable module implementing DMA API,
>>> for example to be used for sub-devices registered by the module. However,
>>> most o
On Thu, Jul 6, 2017 at 5:34 PM, Tomasz Figa wrote:
> On Thu, Jul 6, 2017 at 5:26 PM, Arnd Bergmann wrote:
>> On Thu, Jul 6, 2017 at 3:44 AM, Tomasz Figa wrote:
>>> On Thu, Jul 6, 2017 at 2:20 AM, Christoph Hellwig wrote:
On Thu, Jul 06, 2017 at 12:22:35AM +0900, Tomasz Figa wrote:
>>
On Thu, Jul 6, 2017 at 5:26 PM, Arnd Bergmann wrote:
> On Thu, Jul 6, 2017 at 3:44 AM, Tomasz Figa wrote:
>> On Thu, Jul 6, 2017 at 2:20 AM, Christoph Hellwig wrote:
>>> On Thu, Jul 06, 2017 at 12:22:35AM +0900, Tomasz Figa wrote:
>
>>> In general I think moving dma
>>> ops and iommu implementat
On Thu, Jul 6, 2017 at 3:44 AM, Tomasz Figa wrote:
> On Thu, Jul 6, 2017 at 2:20 AM, Christoph Hellwig wrote:
>> On Thu, Jul 06, 2017 at 12:22:35AM +0900, Tomasz Figa wrote:
>> In general I think moving dma
>> ops and iommu implementations into modules is a bad idea
>
> Could you elaborate on th
30 matches
Mail list logo
