On Tue, Sep 30, 2014 at 01:02:01PM +0200, Joerg Roedel wrote:
> Hi,
>
> here is a patch-set to fix an issue recently discovered when
> the Intel IOMMU is in use with devices that need RMRR
> mappings.
>
> The problem is that the RMRR mappings are destroyed when the
> device driver is unbound from
On Tue, Sep 30, 2014 at 01:02:01PM +0200, Joerg Roedel wrote:
> Hi,
>
> here is a patch-set to fix an issue recently discovered when
> the Intel IOMMU is in use with devices that need RMRR
> mappings.
>
> The problem is that the RMRR mappings are destroyed when the
> device driver is unbound from
On Wed, Oct 01 2014 at 01:27:27 AM, Arnd Bergmann wrote:
> On Tuesday 30 September 2014 18:28:13 Mitchel Humpherys wrote:
>> + if (readl_poll_timeout_atomic(cb_base + ARM_SMMU_CB_ATSR, tmp,
>> + !(tmp & ATSR_ACTIVE), 50, 100)) {
>>
>
> This looks really bad.
>
Hi Laurent,
> On Tuesday 30 September 2014 16:16:07 Suman Anna wrote:
>> The debugfs support for OMAP IOMMU is currently implemented
>> as a module, warranting certain OMAP-specific IOMMU API to
>> be exported. The OMAP IOMMU, when enabled, can only be built-in
>> into the kernel, so integrate the
Hi Suman,
Thank you for the patch.
On Tuesday 30 September 2014 16:16:07 Suman Anna wrote:
> The debugfs support for OMAP IOMMU is currently implemented
> as a module, warranting certain OMAP-specific IOMMU API to
> be exported. The OMAP IOMMU, when enabled, can only be built-in
> into the kernel
On Tue, 30 Sep 2014, Peter Hurley wrote:
> On 09/30/2014 07:45 PM, Thomas Gleixner wrote:
> > Whether the proposed patchset is the correct solution to support it is
> > a completely different question.
>
> This patchset has been in mainline since 3.16 and has already caused
> regressions, so the q
On Tue, Sep 30, 2014 at 05:00:35PM +0100, Will Deacon wrote:
> On Thu, Sep 25, 2014 at 07:40:23AM +0100, Thierry Reding wrote:
[...]
> > So I think what we're going to need is a way to prevent the default
> > attachment to DMA/IOMMU. Or alternatively not associate devices with
> > IOMMU domains by
On Tuesday 30 September 2014 18:28:13 Mitchel Humpherys wrote:
> + if (readl_poll_timeout_atomic(cb_base + ARM_SMMU_CB_ATSR, tmp,
> + !(tmp & ATSR_ACTIVE), 50, 100)) {
>
This looks really bad.
You are doing up to 50 100us delays, each of which can be much long
On Tuesday 30 September 2014 18:28:12 Mitchel Humpherys wrote:
> + */
> +#define readl_poll_timeout(addr, val, cond, sleep_us, timeout_us) \
> +({ \
> + ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
> + might_sleep_if(timeout_us); \
Does it make sense to call this with tim
