Hi Robin,
>Hi Sricharan,
>
>On 02/12/16 14:55, Sricharan R wrote:
>> This series is a resend of the V5 that Mitch sent sometime back [2]
>> All the patches are the same and i have just rebased. Not sure why this
>> finally did not make it last time. The last patch in
ss_ of what they really are, though
>> arguably acpi_bind_one() touches ways more devices.
>>
>> I really think that removing the default dma masks settings from
>> acpi_dma_configure() is the safer thing to do for the time being (or
>> moving acpi_dma_configure() to acpi_create_platform_device(), where the
>> DMA masks are set-up by default by core ACPI. Mark, Suravee, what was
>> the rationale behind calling arch_setup_dma_ops() in acpi_bind_one() ?)
>
>Alternatively, you can add one more arch wrapper that will be a no-op
>on x86 and that will set up the default masks and call
>arch_setup_dma_ops() on ARM. Then, you can invoke that from
>acpi_dma_configure().
>
>Or make the definition of acpi_dma_configure() itself depend on the
>architecture.
>
So is it better that either removing the masks from acpi_dma_configure (or)
creating the wrapper as Rafael mentioned, than moving
acpi_dma_configure itself , because with something like iommu probe
deferral that is tried, acpi_dma_configure is getting invoked from a device's
really_probe, a different path again ?
Regards,
Sricharan
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Hi Robin,
>>> Hi Sricharan,
>>>
>>> On 02/12/16 14:55, Sricharan R wrote:
>>>> This series is a resend of the V5 that Mitch sent sometime back [2]
>>>> All the patches are the same and i have just rebased. Not sure why this
>>>> fi
s welcome..
>> in between debugging freedreno I'll try to put together some patches.
>
>From what I can tell we need SCTLR_CFCFG to make the stall happen otherwise
>the operation just gets terminated immediately and *then* we get notification
>but by then the system keeps going.
>
Yes thats right, SCTLR_CFCFG was removed as a part of this patch.
>I think SCTLR_HUPCF helps control that behavior (i.e. we don't go off faulting
>through eternity) but I don't know how it works.
>
>From my very unlearned understanding I think we do want to set CFCFG and then
>stall and let the interrupt handler decide to retry/terminate.
Yes, infact i was thinking of adding this as a new patch, but now that this was
a reverted one. As you said, it would be good to know the hw which was having
problem with this and probably having this has a quirk otherwise.
Also i see that FSR_SS is implemented by the qcom and the
downstream code uses it.
Regards,
Sricharan
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Hi Robin,
>Hi Robin,
>
>>>> Hi Sricharan,
>>>>
>>>> On 02/12/16 14:55, Sricharan R wrote:
>>>>> This series is a resend of the V5 that Mitch sent sometime back [2]
>>>>> All the patches are the same and i have just reba
Hi Robin,
>-Original Message-
>From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org]
>On Behalf Of Robin Murphy
>Sent: Tuesday, December 13, 2016 7:33 PM
>To: Sricharan R ; jcro...@codeaurora.org;
>pd...@codeaurora.org; jgeb...@codeaurora.org
Hi,
>
>On 13/12/16 14:38, Sricharan wrote:
>> Hi Robin,
>>
>>> -Original Message-
>>> From: linux-arm-kernel
>>> [mailto:linux-arm-kernel-boun...@lists.infradead.org] On Behalf Of Robin
>>> Murphy
>>> Sent: Tuesday, Decembe
pis in arm as to be modified to pass the PRIVILIGED attributes
as well. While my testing path was using the iommu_map directly i was not
seeing this, but then i did a patch like below. I will just figure out another
other codebase where the master uses the dma apis, test and add it in the
V8 that i would
hink that means we want both specific compatible strings to identify
>the SS bit behaviour, but also a way to opt-in for the stall model as a
>separate property to indicate that the SoC integration can support this
>without e.g. deadlocking.
>
To understand the reason on the need for t
ot missed anything else, realized that the
>> dma-mapping apis in arm as to be modified to pass the PRIVILIGED attributes
>> as well. While my testing path was using the iommu_map directly i was not
>> seeing this, but then i did a patch like below. I will just figure out
>> a
y owing to lack of
>test platforms, I would appreciate some help in testing this
>patch on those platforms before merging it even if it is just
>a simple interface conversion.
>
For msm,
Tested-by: Sricharan R
Regards,
Sricharan
___
iommu
m-...@vger.kernel.org; Sricharan R
>
>Subject: Re: [RFC 2/3] iommu/arm-smmu: Add qcom implementation
>
>On Tue, Jan 03, 2017 at 04:30:55PM -0500, Rob Clark wrote:
>> At least on the db820c I have, with the firmware I have, I'm not seeing
>> the SS bit set, even thoug
Hi Robin/Lorenzo,
>Hi Robin,Lorenzo,
>
>>On Wed, Nov 30, 2016 at 04:42:27PM +, Robin Murphy wrote:
>>> On 30/11/16 16:17, Lorenzo Pieralisi wrote:
>>> > Sricharan, Robin,
>>> >
>>> > I gave this series a go on ACPI and apart from an SMM
ock your series for this trivial niggle.
>
>Other than that, though, I like it :) IORT has a small, strictly
>bounded, set of supported devices, so I really don't see the need to go
>overboard putting it on parity with DT when something this neat and
>simple will suffice.
>
Ok sure, looks correct for me as well in whole of the context here.
Regards,
Sricharan
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Hi Joerg,
>-Original Message-
>From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org]
>On Behalf Of Joerg Roedel
>Sent: Friday, January 06, 2017 4:36 PM
>To: Sricharan R
>Cc: mitch...@codeaurora.org; pd...@codeaurora.org; vinod.k...
he check in xlate, which still can be called multiple times
even without deferring, incase of say multiple sids as well. But i
remember that sometime back Marek mentioned that the exynos
iommu currently always has "#iommu-cells = <0>" , but this patch might
be required if that change
Hi Lorenzo,
>-Original Message-
>From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org]
>On Behalf Of Lorenzo Pieralisi
>Sent: Thursday, January 19, 2017 8:11 PM
>To: Sricharan
>Cc: linux-arm-...@vger.kernel.org; j...@8bytes.org; will.dea..
Hi Lorenzo,
>On Thu, Jan 19, 2017 at 08:35:54PM +0530, Sricharan R wrote:
>> With all the DT based devices getting their dma ops configured
>> during probe time to have the right iommu setup, let us do the
>> same for acpi based devices as well.
>>
>> Configuring
Hi Lorenzo,
>-Original Message-
>From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
>Sent: Thursday, January 19, 2017 10:18 PM
>To: Sricharan R
>Cc: robin.mur...@arm.com; will.dea...@arm.com; j...@8bytes.org;
>iommu@lists.linux-foundation.or
Hi Robin,
>On 19/01/17 15:05, Sricharan R wrote:
>> Configuring DMA ops at probe time will allow deferring device probe when
>> the IOMMU isn't available yet. The dma_configure for the device is
>> now called from the generic device_attach callback just before the
>
gt;
>> > Similarly on the device/driver_unregister path __device_release_driver is
>> > called which inturn calls dma_deconfigure.
>> >
>> > Signed-off-by: Sricharan R
>> > ---
>> > * Removed the dma configuration for the pci devic
Hi Robin,
>-Original Message-
>From: linux-arm-msm-ow...@vger.kernel.org
>[mailto:linux-arm-msm-ow...@vger.kernel.org] On Behalf Of Robin Murphy
>Sent: Thursday, January 19, 2017 11:28 PM
>To: Lorenzo Pieralisi ; Sricharan R
>
>Cc: will.dea...@arm.com; j...@8bytes.o
Hi Will,
>-Original Message-
>From: linux-arm-msm-ow...@vger.kernel.org
>[mailto:linux-arm-msm-ow...@vger.kernel.org] On Behalf Of Will Deacon
>Sent: Thursday, January 19, 2017 9:48 PM
>To: Sricharan R
>Cc: robin.mur...@arm.com; j...@8bytes.org; lorenzo.pieral..
Hi Lorenzo,
>-Original Message-
>From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
>Sent: Monday, January 23, 2017 5:37 PM
>To: Sricharan R
>Cc: robin.mur...@arm.com; will.dea...@arm.com; j...@8bytes.org;
>iommu@lists.linux-foundation.org; linux-arm-
>ker..
Hi Lorenzo,
>>[+bjorn]
>>
>>On Sat, Jan 21, 2017 at 12:45:43AM +0530, Sricharan R wrote:
>>> Configuring DMA ops at probe time will allow deferring device probe when
>>> the IOMMU isn't available yet. The dma_configure for the device is
>>> now c
evice. But also the error value from
xlate/add_device is returned back and the probe of the device
would fail for any error. So if there can be cases like above, where
the xlate/add_device callbacks can return error for specific reasons,
should only EPROBE_DEFER be considered and rest of the e
Hi Marek,
>On 2017-01-23 17:18, Sricharan R wrote:
>> This series calls the dma ops configuration for the devices
>> at a generic place so that it works for all busses.
>> The dma_configure_ops for a device is now called during
>> the device_attach callback just bef
there is an way out of that that can be tried.
So should the default domain not be per device specific selectable ?
Regards,
Sricharan
>Will
>
>--->8
>
>Will Deacon (5):
> iommu/arm-smmu: Restrict domain attributes to UNMANAGED domains
> iommu/arm-smmu: Install bypass S2CRs f
Hi Lorenzo,
>[+hanjun, tomasz, sinan]
>
>It is quite a key patchset, I would be glad if they can test on their
>respective platforms with IORT.
>
>On Mon, Jan 23, 2017 at 09:48:10PM +0530, Sricharan R wrote:
>> This is an equivalent to the DT's handling of the
Hi Hanjun,
>On 2017/1/24 0:18, Sricharan R wrote:
>> This series calls the dma ops configuration for the devices
>> at a generic place so that it works for all busses.
>> The dma_configure_ops for a device is now called during
>> the device_attach callback just bef
>level,
>+ * and that unprivileged transactions should have as little access as
>possible.
>+ * This would usually imply the same permissions as kernel mappings on the
>CPU,
>+ * if the IOMMU page table format is equivalent.
> */
Agree, gives much more insight.
Regards,
Sricharan
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
elated.
Sorry that there is crash still. __of_match_node seems to checking
for NULL arguments , feels like some invalid pointer was passed in.
Is there any particular sequence to try for this ?
Regards,
Sricharan
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
an unprobed IOMMU (in this case
>disabled in DT), trips over trying to match the now-freed table. I'm
>working on the fix - technically the bug's in my patch (#2) anyway ;)
>
Ok, thanks for bringing this out. There is also an issue that
Sinan has mentioned while testi
Hi Bjorn,
>-Original Message-
>From: Bjorn Helgaas [mailto:helg...@kernel.org]
>Sent: Sunday, January 29, 2017 2:34 AM
>To: Sricharan R
>Cc: robin.mur...@arm.com; will.dea...@arm.com; j...@8bytes.org;
>lorenzo.pieral...@arm.com; iommu@lists.linux-foundation.o
>> Now that the appropriate ordering is enforced via profe-deferral of
>
>s/profe-deferral/probe-deferral/
>
ha, will change it.
Regards,
Sricharan
>> masters in core code, rip it all out and bask in the simplicity.
>>
>> Acked-by: Will Deacon
>> Sig
s here.
>
>s/notifier's/notifiers/
>
ok, will change.
>Personally I'd capitalize "IOMMU" in the English text above, too.
>
ok, will change this too.
Regards,
Sricharan
>> Acked-by: Will Deacon
>> Signed-off-by: Sricharan R
>> [rm: clea
Hi Bjorn,
>On Mon, Jan 23, 2017 at 09:48:02PM +0530, Sricharan R wrote:
>> This series calls the dma ops configuration for the devices
>> at a generic place so that it works for all busses.
>> The dma_configure_ops for a device is now called during
>> the device_atta
Hi,
>-Original Message-
>From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org]
>On Behalf Of Sinan Kaya
>Sent: Sunday, January 29, 2017 10:06 PM
>To: Sricharan R ; robin.mur...@arm.com;
>will.dea...@arm.com; j...@8bytes.org;
>lorenzo.pie
er,
>but they can wait until we've got the baseline functionality sorted.
>Updated full patch here:
>
>http://www.linux-arm.org/git?p=linux-rm.git;a=commitdiff;h=5616af885f7c5c24f7239d5c689583b2b583c407
Thanks, will use this. Yes, the magic iommu_of_table makes little
use with probe
in this series as well [1]
[1] https://www.spinics.net/lists/arm-kernel/msg556081.html
>(Is there really any purpose for having the dummy-ops??)
>
To enforce setting arch_setup_dma_ops for device so that the
devices can do cache coherent transactions, otherwise disabl
Hi Rob,
>-Original Message-
>From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org]
>On Behalf Of Rob Clark
>Sent: Thursday, February 02, 2017 8:33 PM
>To: Joerg Roedel
>Cc: Will Deacon ; iommu@lists.linux-foundation.org;
>Sricha
mapped.
>
>It started working once I applied the iort/dma-mapping patches I
>sent out earlier this week that use the iort memory_address_limit
>field to check if a dma_mask is sane.
>
>Sorry for the false alarm.
Ok, thanks for closing on it. I will just post V8 with all acks picked
Hi Lorenzo, Robin,
>-Original Message-
>From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org]
>On Behalf Of Sricharan R
>Sent: Friday, February 03, 2017 9:19 PM
>To: robin.mur...@arm.com; will.dea...@arm.com; j...@8bytes.org;
>lorenzo.pieral
Hi Will, Rob,
>-Original Message-
>From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org]
>On Behalf Of Will Deacon
>Sent: Thursday, February 02, 2017 9:41 PM
>To: Sricharan
>Cc: linux-arm-ker...@lists.infradead.org; 'Rob Clark'
Hi Robin,
>>
>>> -Original Message-
>>> From: linux-arm-kernel
>>> [mailto:linux-arm-kernel-boun...@lists.infradead.org] On Behalf Of
>>> Sricharan R
>>> Sent: Friday, February 03, 2017 9:19 PM
>>> To: robin.mur...@arm.co
Hi Mark,
>
>On Thu, Feb 02, 2017 at 10:40:18PM +0530, Sricharan R wrote:
>> +- clock-names:Should be a pair of "smmu_iface_clk" and "smmu_bus_clk"
>> + required for smmu's register group access and interface
>> +
Hi Mark,
>On Wed, Feb 08, 2017 at 04:23:17PM +0530, Sricharan wrote:
>> >On Thu, Feb 02, 2017 at 10:40:18PM +0530, Sricharan R wrote:
>> >> +- clock-names:Should be a pair of "smmu_iface_clk" and "smmu_bus_clk"
>> >> +
Hi Robin,
>>>>> On Thu, Feb 02, 2017 at 10:40:18PM +0530, Sricharan R wrote:
>>>>>> +- clock-names:Should be a pair of "smmu_iface_clk" and
>>>>>> "smmu_bus_clk"
>>>>>> + required for
Hi Robin,
>-Original Message-
>From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org]
>On Behalf Of Robin Murphy
>Sent: Wednesday, February 08, 2017 8:01 PM
>To: Mark Rutland ; Sricharan
>Cc: devicet...@vger.kernel.org; mathieu.poir...@linar
get(dev, "bus_clk");
>+ if (IS_ERR(qcom_iommu->bus_clk)) {
>+ dev_err(dev, "failed to get bus_clk\n");
>+ return PTR_ERR(qcom_iommu->bus_clk);
>+ }
>+
>+ if (of_property_r
ommu. (But it was Robin's
>suggestion to just model this as separate context-bank devices, since
>we cannot touch the global space).
>
>Did I misunderstand the downstream driver code? It looked like
>qcom_scm_restore_sec_cfg() was called once on first attach per
>context
iommu-map, and the caller should check if *target is still NULL?
>
>Ah yes, Tomasz had found breakages with the "mmu-masters" binding
>before, and I'd already pushed out a fixup for this one[1], but I forgot
that
>that discussion was all off-list (out of diplomatic c
might
>have existed on early versions of chips for new SoC bring-up.. but I think from
>upstream perspective we can ignore that).
Right, I would think this is the only one which has the MMU-500 behind the
*secure* access constraints to global registers. The next set of S
gt;irq);
+ return ret;
+ }
+
+ /* read the "reg" property directly to get the relative address
+* of the context bank, and calculate the asid from that:
+*/
+ if (of_property_read_u32_index(dev->of_node, "reg", 0, ®)) {
+
Hi Laurent,
On 2017-05-16 03:04, Laurent Pinchart wrote:
Hi Sricharan,
On Monday 15 May 2017 23:37:16 Laurent Pinchart wrote:
On Wednesday 03 May 2017 15:54:59 Sricharan R wrote:
> On 5/3/2017 3:24 PM, Robin Murphy wrote:
>> On 02/05/17 19:35, Geert Uytterhoeven wrote:
>>> O
Hi Will,
On 2017-05-15 19:52, Will Deacon wrote:
Hi Sricharan,
On Wed, May 03, 2017 at 03:54:59PM +0530, Sricharan R wrote:
On 5/3/2017 3:24 PM, Robin Murphy wrote:
> On 02/05/17 19:35, Geert Uytterhoeven wrote:
>> On Fri, Feb 3, 2017 at 4:48 PM, Sricharan R wrote:
>>> From
Hi Laurent,
On 2017-05-16 12:47, Laurent Pinchart wrote:
Hi Sricharan,
On Tuesday 16 May 2017 07:53:57 sricha...@codeaurora.org wrote:
On 2017-05-16 03:04, Laurent Pinchart wrote:
> On Monday 15 May 2017 23:37:16 Laurent Pinchart wrote:
>> On Wednesday 03 May 2017 15:54:59 Srichara
l
>> be set to old value, which is not right.
>>
>> Signed-off-by: Sricharan R
>> Reviewed-by: Robin Murphy
>> ---
>>
>> arch/arm/mm/dma-mapping.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/mm/dma-mapping
On 2017-05-17 10:45, Sricharan R wrote:
Hi Laurent/Robin,
On 5/16/2017 10:14 PM, Laurent Pinchart wrote:
Hi Robin,
On Tuesday 16 May 2017 16:47:36 Robin Murphy wrote:
On 16/05/17 16:14, Laurent Pinchart wrote:
arch_setup_dma_ops() is used in device probe code paths to create an
IOMMU
isabled together.
I will add little more description here for this here.
> Also, the second cell can't be a list of stream ids, as one cell stores
one value.
> A master device using multiple stream ids should use multiple entries in
the
> iommus property.
>
Hi Rob,
> On Wed, Apr 06, 2016 at 07:59:31PM +0530, Sricharan R wrote:
> > The driver currently works based on platform data. Remove this and add
> > support for DT. A single master can have multiple ports connected to
> > more than one iommu.
> >
&
Hi will,
> -Original Message-
> From: Will Deacon [mailto:will.dea...@arm.com]
> Sent: Tuesday, April 26, 2016 7:47 PM
> To: Sricharan R
> Cc: linux-arm-ker...@lists.infradead.org;
iommu@lists.linux-foundation.org;
> devicet...@vger.kernel.org; linux-arm-...@vger.kerne
g the DT bindings for the same.
> >
> > Signed-off-by: Sricharan R
> > ---
> > .../devicetree/bindings/iommu/msm,iommu-v0.txt | 62
> ++
> > 1 file changed, 62 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/iommu/ms
Hi Marek,
> -Original Message-
> From: linux-arm-kernel [mailto:linux-arm-kernel-
> boun...@lists.infradead.org] On Behalf Of Marek Szyprowski
> Sent: Thursday, May 12, 2016 6:23 PM
> To: Sricharan R ; will.dea...@arm.com;
> robin.mur...@arm.com; j...@8bytes.org;
hift))) + (((v) & (mask)) << (shift)),
>> addr);\
>> + writel_relaxed((t & ~((mask) << (shift))) + \
>> + (((v) & (mask)) << (shift)), addr);\
>> } while (0)
>
>No, please add a new macro for the relaxed accessors and then add comments
>in the places where those are used, to document why you can take shortcuts
>in those places.
Ok, will add a new accessor for this and comment them.
Regards,
Sricharan
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
ngs for the same.
>>
>> Signed-off-by: Sricharan R
>> ---
>> .../devicetree/bindings/iommu/msm,iommu-v0.txt | 64
>> ++
>> 1 file changed, 64 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/iommu/msm,iommu-v0.
only reason for changing this was to optimise out the additonal barriers
that were happening. I do not see any issue now as well, only that the writes
would
be faster.
Regards,
Sricharan
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
a patch here [1] with comments, i had to delete the
old accessors though as it became unused now.
http://www.spinics.net/lists/arm-kernel/msg505448.html
Regards,
Sricharan
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Hi Robin/Laurent,
>> -Original Message-
>> From: linux-arm-kernel [mailto:linux-arm-kernel-
>> boun...@lists.infradead.org] On Behalf Of Marek Szyprowski
>> Sent: Thursday, May 12, 2016 6:23 PM
>> To: Sricharan R ; will.dea...@arm.com;
>> robin.mu
e relaxed accessors first in a separate patch, and then
>change over one user at a time before you remove the non-relaxed ones.
>
ok
>It's hard to believe that all users are actually performance critical,
>so start with the ones that gain the most performance. As commented above,
>some of the conversions seem particularly fishy and it's likely that
>a slow reset() function should not be fixed by making reset() faster
>but by calling it less often.
Ok. Will change this. So i will split this in to separate series, one patch to
modify
relevant the flush_iotlb_range function in this series and rest of all changes
as a driver improvement in one more.
>Can you just remove those macros, and open-code the function calls?
>
>This is an unnecessary obfuscation that now also hides the fact that you
>are using relaxed accessors.
Ok, will make this in to inline functions to make it obvious.
Regards,
Sricharan
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Hi Marek,
>On 2016-04-25 17:58, Sricharan R wrote:
>> Now that the device's iommu ops are configured at probe time,
>> the device has to be added to the iommu late.
>>
>> Signed-off-by: Sricharan R
>> ---
>> drivers/of/device.c | 4
>>
ck on this to
>> measure
>> the latency difference. If thats true, then the iopgtable ops itself
>> provides a
>> function for iova_to_phys conversion, so that can be used.
>
>I hadn't realized that this is a lookup in the hardware, rather than
>reading a static register. It's probably a good idea to check this
>anyway.
Ok, will measure the difference and have the better one.
Regards,
Sricharan
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
e walker in your IOMMU, you don't need to worry
> about this.
>
To get my understanding correct here, is the barrier required here because
of speculative fetch ?
Regards,
Sricharan
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
omes before the MMIO write to the
>DMA master would ensure ordering of the DMA after both the IOPTE
>update and the MMIO flush (unless there was the speculative fetch you
>mentioned), but this is where I'm no longer confident enough in my
Hi Robin,
>On 25/04/16 16:58, Sricharan R wrote:
>> From: Laurent Pinchart
>>
>> Configuring DMA ops at probe time will allow deferring device probe when
>> the IOMMU isn't available yet.
>>
>> Signed-off-by: Laurent Pinchart
>> ---
>>
Hi Robin,
>On 25/04/16 16:58, Sricharan R wrote:
>> Now that the device's iommu ops are configured at probe time,
>> the device has to be added to the iommu late.
>>
>> Signed-off-by: Sricharan R
>> ---
>> drivers/of/device.c | 4
>>
0x) will trigger a fault.
>
So for the irq to be triggered, 'non-secure' irq line has to be
populated in DT. There is a 'secure'and 'non-secure' irq lines for these
iommus
and non-secure irq number is
apping), and the faults were getting triggered.
>>
>> Can you share me your dts data ?
>>
>
>I think this is what you want:
>
>https://github.com/freedreno/kernel-msm/blob/integration-linux-qcomlt/arch/arm/boot/dts/qcom-apq8064.dtsi#L200
>>
>>>I haven't tested a display fault, so I suppose it is possible that
>>>irq's are working for some iommu instances but not others?
>>
>> So in your DT, for gfx3d, the non-secure line is '70' and not '69' (This is
>> secure) .
>> Infact only '70' should be populated. The driver sets the irq line based on
>> resource 0.
>> This applies for all iommu nodes in your DT. (only the second irq line is
>> needed).
>
>ahh, that would explain.
>
>Is it better to remove the extra entry, or should I just swap them
>all? Ie. might there be some point in the future where the driver
>would want both?
I feel better to have one. Not sure why the secure irq was added in first
place in the downstream data and it would setup/handled by the TZ
Regards,
Sricharan
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
.
>>>>
>>>>Is it better to remove the extra entry, or should I just swap them
>>>>all? Ie. might there be some point in the future where the driver
>>>>would want both?
>>> I feel better to have one. Not sure why the secure irq was added in
>>> first
>>> place in the downstream data and it would setup/handled by the TZ
>>
>> Ok, getting further.. still seems like the gpu is not getting resumed,
>> but at least we are getting a fault interrupt..
>
>
>ok, seems like we need:
>
>---
>diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
>index b09692b..f6f596f 100644
>--- a/drivers/iommu/msm_iommu.c
>+++ b/drivers/iommu/msm_iommu.c
>@@ -628,6 +628,7 @@ irqreturn_t msm_iommu_fault_handler(int irq, void *dev_id)
> pr_err("Interesting registers:\n");
> print_ctx_regs(iommu->base, i);
> SET_FSR(iommu->base, i, 0x400F);
>+SET_RESUME(iommu->base, i, 1);
> }
ok, ya this is required for disabling the stall.
I can send a patch to change this.
> }
> __disable_clocks(iommu);
>---
>
>with that it seems like it kinda/mostly recovers, although there is
>still a bit of strangeness..
hmm ok, can test it and check something particular ?
Regards,
Sricharan
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
>> device_node *np)
>> coherent ? " " : " not ");
>>
>> iommu = of_iommu_configure(dev, np);
>> + if (IS_ERR(iommu))
>> + return PTR_ERR(iommu);
>
>nit: Would be good to add a blank line here for improved readability.
ok, will add.
Regards,
Sricharan
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
this patch need to be squashed with previous one to avoid
>breaking things in between by having the of_dma_configure_ops() called
>two times?
>
okay, i did it this way, for the sake of review. But ya will squash
it for the next post.
Regards,
Sricharan
pped and to have masks also done along
with ops,
but thought of getting some feedback if its really needed before probe
anywhere.
Regards,
Sricharan
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
msm_iommu_fault_handler(int irq, void *dev_id)
> pr_err("Interesting registers:\n");
> print_ctx_regs(iommu->base, i);
> SET_FSR(iommu->base, i, 0x400F);
>+ SET_RESUME(iommu-&
f its better to have only this as a
ratelimited print,
for global faults ?, otherwise
Reviewed-by: sricha...@codeaurora.org
Regards,
Sricharan
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Hi Laurent,
>Hi Sricharan,
>
>Thank you for the patch.
>
>On Tuesday 09 Aug 2016 04:19:07 Sricharan R wrote:
>> Configuring DMA ops at probe time will allow deferring device probe when
>> the IOMMU isn't available yet.
>>
>> Signed-off-by: Sricharan R
Hi Marek,
>Hi Sricharan,
>
>
>On 2016-08-12 17:40, Sricharan wrote:
>> Hi Tomaz,
>>
>>>> + if (ops->add_device)
>>>> + ops = ops->add_device(dev) ? ops : NULL;
>>> Patch description fails to
Hi Marek,
>Hi Sricharan and Laurent,
>
>
>On 2016-08-09 00:49, Sricharan R wrote:
>> From: Laurent Pinchart
>>
>> The arch_setup_dma_ops() function is in charge of setting dma_ops with a
>> call to set_dma_ops(). set_dma_ops() is also called from
>
Hi Marek,
>Hi Sricharan,
>
>On 2016-08-09 00:49, Sricharan R wrote:
> > From: Laurent Pinchart
> >
> > Failures to look up an IOMMU when parsing the DT iommus property need to
> > be handled separately from the .of_xlate() failures to support deferred
&
Hi Magnus,
>On Tue, Aug 9, 2016 at 7:49 AM, Sricharan R wrote:
>> From: Laurent Pinchart
>>
>> The of_configure_dma() function configures both the DMA masks and ops.
>> Moving DMA ops configuration to probe time would thus also delay
>> configuration of the D
Hi,
>-Original Message-
>From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org]
>On Behalf Of Sricharan R
>Sent: Tuesday, October 04, 2016 10:34 PM
>To: will.dea...@arm.com; robin.mur...@arm.com; j...@8bytes.org;
>iommu@lists.linux-foundation.or
Hi Marek,
>Hi Sricharan,
>
>
>On 2016-10-04 19:03, Sricharan R wrote:
>> Initial post from Laurent Pinchart[1]. This is
>> series calls the dma ops configuration for the devices
>> at a generic place so that it works for all busses.
>> The dma_configure_o
>-Original Message-
>From: Sricharan [mailto:sricha...@codeaurora.org]
>Sent: Wednesday, October 12, 2016 11:55 AM
>To: 'Marek Szyprowski' ; 'will.dea...@arm.com'
>; 'robin.mur...@arm.com'
>; 'j...@8bytes.org' ;
>'
Resending, missed out on the link last time.
>-Original Message-
>From: linux-arm-msm-ow...@vger.kernel.org
>[mailto:linux-arm-msm-ow...@vger.kernel.org] On Behalf Of Marek Szyprowski
>Sent: Monday, October 10, 2016 6:07 PM
>To: Sricharan R ; will.dea...@arm.com;
>ro
FIG_ARM_AMBA
>- ret = bus_set_iommu(&amba_bustype, &arm_smmu_ops);
>- if (ret)
>- return ret;
>+ bus_set_iommu(&amba_bustype, &arm_smmu_ops);
> #endif
>- return bus_set_iommu(&platform_bus_type, &arm_smmu_ops);
>+ bu
->rpm_lock);
> }
> return 0;
> }
>-#endif
>
> static const struct dev_pm_ops sysmmu_pm_ops = {
>- SET_LATE_SYSTEM_SLEEP_PM_OPS(exynos_sysmmu_suspend,
>exynos_sysmmu_resume)
>+ SET_RUNTIME_PM_OPS(exynos_sysmmu_suspend, exynos_sysmmu_resume, NULL)
>+ SET_LATE_SYSTEM_SLEEP_P
(dependency) to its
>+ * master device, so there are no direct calls to pm_runtime_get/put
>+ * in this driver.
>+ */
>+ device_link_add(dev, data->sysmmu, DL_FLAG_PM_RUNTIME);
>+
So in the case of master with multiple sids, this would be called multiple
times
for the same master ?
Regards,
Sricharan
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Hi Marek,
>Hi Sricharan
>
>
>On 2016-10-22 07:50, Sricharan wrote:
>>
>>> This patch adds runtime pm implementation, which is based on previous
>>> suspend/resume code. SYSMMU controller is now being enabled/disabled mainly
>> > from the runtime p
ontrollers (consumers), then links will be created
>for each SYSMMU
>controller. Please note that this code is based on vanilla v4.9-rc1,
>which calls
>of_xlate() callback only once for every iommu for given master device.
>Your IOMMU
>deferred probe patches change this, but I already posted a fix for
>Exynos IOMMU driver
>to handle such case.
By multiple sids, i meant iommus = <&phandle sid1 sid2 .. sidn> case,
so xlate would be called multiples for the same master without deferred
probing also. But the fix that you showed on the other thread would work
here as well or maybe if you dont have masters with multiple sids you
wont
have any issues as well.
Regards,
Sricharan
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
feature! Your can add my:
>>>
>>> Tested-by: Marek Szyprowski
>>>
>>Thanks for testing this. So the for the below fix, the remove_device
>> callback
>>gets called on the dma_ops cleanup path, so would it be easy to remove the
>>data
1 - 100 of 433 matches
Mail list logo
