All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mitchel Humpherys <mitchelh-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
To: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
Cc: "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
	<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH 2/2] iommu/arm-smmu: add support for iova_to_phys through ATS1PR
Date: Wed, 24 Sep 2014 13:34:26 -0700	[thread overview]
Message-ID: <vnkw38bgkbal.fsf@mitchelh-linux.qualcomm.com> (raw)
In-Reply-To: <20140924163712.GG16244-5wv7dgnIgG8@public.gmane.org> (Will Deacon's message of "Wed, 24 Sep 2014 17:37:12 +0100")

On Wed, Sep 24 2014 at 09:37:12 AM, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote:
> On Wed, Sep 24, 2014 at 02:12:00AM +0100, Mitchel Humpherys wrote:
>> On Mon, Sep 22 2014 at 08:26:14 AM, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote:
>> > On Thu, Sep 11, 2014 at 07:30:44PM +0100, Mitchel Humpherys wrote:
>> >> +		return arm_smmu_iova_to_phys_soft(domain, iova);
>> >> +	}
>> >> +
>> >> +	phys = readl_relaxed(cb_base + ARM_SMMU_CB_PAR_LO);
>> >> +	phys |= ((u64) readl_relaxed(cb_base + ARM_SMMU_CB_PAR_HI)) << 32;
>> >> +
>> >> +	if (phys & CB_PAR_F) {
>> >> +		dev_err(dev, "translation fault on %s!\n", dev_name(dev));
>> >> +		dev_err(dev, "PAR = 0x%llx\n", phys);
>> >> +	}
>> >> +	phys = (phys & 0xFFFFFFF000ULL) | (iova & 0x00000FFF);
>> >
>> > How does this work for 64k pages?
>> 
>> So at the moment we're always assuming that we're using v7/v8 long
>> descriptor format, right?  All I see in the spec (14.5.15 SMMU_CBn_PAR)
>> is that bits[47:12]=>PA[47:12]...  Or am I missing something completely?
>
> I think you've got 64k pages confused with the short-descriptor format.
>
> When we use 64k pages with long descriptors, you're masked off bits 15-12 of
> the iova above, so you'll have a hole in the physical address afaict.

Even with long descriptors the spec says bits 15-12 should come from
CB_PAR...  It makes no mention of reinterpreting those bits depending on
the programmed page granule.  The only thing I can conclude from the
spec is that hardware should be smart enough to do the right thing with
bits 15-12 when the page granule is 64k.  Although even if hardware is
smart enough I guess CB_PAR[15:12] should be the same as iova[15:12] for
the 64k case?


-Mitch

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

WARNING: multiple messages have this Message-ID (diff)
From: mitchelh@codeaurora.org (Mitchel Humpherys)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] iommu/arm-smmu: add support for iova_to_phys through ATS1PR
Date: Wed, 24 Sep 2014 13:34:26 -0700	[thread overview]
Message-ID: <vnkw38bgkbal.fsf@mitchelh-linux.qualcomm.com> (raw)
In-Reply-To: <20140924163712.GG16244@arm.com> (Will Deacon's message of "Wed, 24 Sep 2014 17:37:12 +0100")

On Wed, Sep 24 2014 at 09:37:12 AM, Will Deacon <will.deacon@arm.com> wrote:
> On Wed, Sep 24, 2014 at 02:12:00AM +0100, Mitchel Humpherys wrote:
>> On Mon, Sep 22 2014 at 08:26:14 AM, Will Deacon <will.deacon@arm.com> wrote:
>> > On Thu, Sep 11, 2014 at 07:30:44PM +0100, Mitchel Humpherys wrote:
>> >> +		return arm_smmu_iova_to_phys_soft(domain, iova);
>> >> +	}
>> >> +
>> >> +	phys = readl_relaxed(cb_base + ARM_SMMU_CB_PAR_LO);
>> >> +	phys |= ((u64) readl_relaxed(cb_base + ARM_SMMU_CB_PAR_HI)) << 32;
>> >> +
>> >> +	if (phys & CB_PAR_F) {
>> >> +		dev_err(dev, "translation fault on %s!\n", dev_name(dev));
>> >> +		dev_err(dev, "PAR = 0x%llx\n", phys);
>> >> +	}
>> >> +	phys = (phys & 0xFFFFFFF000ULL) | (iova & 0x00000FFF);
>> >
>> > How does this work for 64k pages?
>> 
>> So at the moment we're always assuming that we're using v7/v8 long
>> descriptor format, right?  All I see in the spec (14.5.15 SMMU_CBn_PAR)
>> is that bits[47:12]=>PA[47:12]...  Or am I missing something completely?
>
> I think you've got 64k pages confused with the short-descriptor format.
>
> When we use 64k pages with long descriptors, you're masked off bits 15-12 of
> the iova above, so you'll have a hole in the physical address afaict.

Even with long descriptors the spec says bits 15-12 should come from
CB_PAR...  It makes no mention of reinterpreting those bits depending on
the programmed page granule.  The only thing I can conclude from the
spec is that hardware should be smart enough to do the right thing with
bits 15-12 when the page granule is 64k.  Although even if hardware is
smart enough I guess CB_PAR[15:12] should be the same as iova[15:12] for
the 64k case?


-Mitch

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

  parent reply	other threads:[~2014-09-24 20:34 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-11 18:30 [PATCH 0/2] iommu/arm-smmu: hard iova_to_phys Mitchel Humpherys
2014-09-11 18:30 ` Mitchel Humpherys
     [not found] ` <1410460244-18943-1-git-send-email-mitchelh-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2014-09-11 18:30   ` [PATCH 1/2] iopoll: Introduce memory-mapped IO polling macros Mitchel Humpherys
2014-09-11 18:30     ` Mitchel Humpherys
     [not found]     ` <1410460244-18943-2-git-send-email-mitchelh-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2014-09-22 15:23       ` Will Deacon
2014-09-22 15:23         ` Will Deacon
2014-09-11 18:30   ` [PATCH 2/2] iommu/arm-smmu: add support for iova_to_phys through ATS1PR Mitchel Humpherys
2014-09-11 18:30     ` Mitchel Humpherys
     [not found]     ` <1410460244-18943-3-git-send-email-mitchelh-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2014-09-22 15:26       ` Will Deacon
2014-09-22 15:26         ` Will Deacon
     [not found]         ` <20140922152614.GP25809-5wv7dgnIgG8@public.gmane.org>
2014-09-24  1:12           ` Mitchel Humpherys
2014-09-24  1:12             ` Mitchel Humpherys
     [not found]             ` <vnkwiokdx1nj.fsf-Yf+dfxj6toJBVvN7MMdr1KRtKmQZhJ7pQQ4Iyu8u01E@public.gmane.org>
2014-09-24 16:37               ` Will Deacon
2014-09-24 16:37                 ` Will Deacon
     [not found]                 ` <20140924163712.GG16244-5wv7dgnIgG8@public.gmane.org>
2014-09-24 20:34                   ` Mitchel Humpherys [this message]
2014-09-24 20:34                     ` Mitchel Humpherys
     [not found]                     ` <vnkw38bgkbal.fsf-Yf+dfxj6toJBVvN7MMdr1KRtKmQZhJ7pQQ4Iyu8u01E@public.gmane.org>
2014-09-26 10:24                       ` Will Deacon
2014-09-26 10:24                         ` Will Deacon
     [not found]                         ` <20140926102430.GF22293-5wv7dgnIgG8@public.gmane.org>
2014-09-26 17:20                           ` Mitchel Humpherys
2014-09-26 17:20                             ` Mitchel Humpherys
2014-09-11 18:53   ` [PATCH 0/2] iommu/arm-smmu: hard iova_to_phys Mitchel Humpherys
2014-09-11 18:53     ` Mitchel Humpherys

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=vnkw38bgkbal.fsf@mitchelh-linux.qualcomm.com \
    --to=mitchelh-sgv2jx0feol9jmxxk+q4oq@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=will.deacon-5wv7dgnIgG8@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.