All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Sricharan" <sricharan@codeaurora.org>
To: 'Arnd Bergmann' <arnd@arndb.de>
Cc: devicetree@vger.kernel.org, architt@codeaurora.org,
	linux-arm-msm@vger.kernel.org, joro@8bytes.org,
	iommu@lists.linux-foundation.org, robdclark@gmail.com,
	srinivas.kandagatla@linaro.org,
	laurent.pinchart@ideasonboard.com, treding@nvidia.com,
	robin.murphy@arm.com, linux-arm-kernel@lists.infradead.org,
	stepanm@codeaurora.org
Subject: RE: [PATCH V5 6/7] iommu/msm: Use writel_relaxed and add a barrier
Date: Wed, 25 May 2016 18:49:18 +0530	[thread overview]
Message-ID: <004c01d1b688$0f6379c0$2e2a6d40$@codeaurora.org> (raw)
In-Reply-To: <14302911.qQPb4UMJ8d@wuerfel>

Hi Arnd,

>> Ok, so i was doing this from the idea that, other iommu drivers
>>  where polling on a status bit in their sync call to ensure completion
>> of pending TLB invalidations. But in this case, there is no status bit.
>>  So added a barrier to have no ordering issues before the client
>> triggers the dma operation. But as you say above that it is implicit that
>> the device would have a barrier before starting the trigger, then the
>> barrier here becomes redundant.
>
>Ok. There are two more things to note here:
>
>* On other platforms, polling the register is likely required because
>  an MMIO write is "posted", meaning that a sync after writel() will
>  only ensure that it has left the CPU write queue, but it may still be
>  on the bus fabric and whatever side-effects are triggered by the
>  write are normally not guaranteed to be completed even after the
>  'sync'. You need to check the datasheet for your IOMMU to find out
>  whether the 'dsb' instruction actually has any effect on the IOMMU.
>  If not, then neither the barrier that you add here nor the barrier
>  in the following writel() is sufficient.
>
   Thanks for the detailed explanation.
i will check this. So with this, i think that if the iommu does not
 support polling for its status, then it should listen to 'dsb' otherwise
 there will no be no way of make it coherent ?

>* The one barrier that is normally required in an IOMMU is between
>  updating the in-memory page tables and the following MMIO store
>  that triggers the TLB flush for that entry. This barrier is
>  implied by writel() but not writel_relaxed(). If you don't have
>  a hardware page table 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

WARNING: multiple messages have this Message-ID (diff)
From: sricharan@codeaurora.org (Sricharan)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V5 6/7] iommu/msm: Use writel_relaxed and add a barrier
Date: Wed, 25 May 2016 18:49:18 +0530	[thread overview]
Message-ID: <004c01d1b688$0f6379c0$2e2a6d40$@codeaurora.org> (raw)
In-Reply-To: <14302911.qQPb4UMJ8d@wuerfel>

Hi Arnd,

>> Ok, so i was doing this from the idea that, other iommu drivers
>>  where polling on a status bit in their sync call to ensure completion
>> of pending TLB invalidations. But in this case, there is no status bit.
>>  So added a barrier to have no ordering issues before the client
>> triggers the dma operation. But as you say above that it is implicit that
>> the device would have a barrier before starting the trigger, then the
>> barrier here becomes redundant.
>
>Ok. There are two more things to note here:
>
>* On other platforms, polling the register is likely required because
>  an MMIO write is "posted", meaning that a sync after writel() will
>  only ensure that it has left the CPU write queue, but it may still be
>  on the bus fabric and whatever side-effects are triggered by the
>  write are normally not guaranteed to be completed even after the
>  'sync'. You need to check the datasheet for your IOMMU to find out
>  whether the 'dsb' instruction actually has any effect on the IOMMU.
>  If not, then neither the barrier that you add here nor the barrier
>  in the following writel() is sufficient.
>
   Thanks for the detailed explanation.
i will check this. So with this, i think that if the iommu does not
 support polling for its status, then it should listen to 'dsb' otherwise
 there will no be no way of make it coherent ?

>* The one barrier that is normally required in an IOMMU is between
>  updating the in-memory page tables and the following MMIO store
>  that triggers the TLB flush for that entry. This barrier is
>  implied by writel() but not writel_relaxed(). If you don't have
>  a hardware page table 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

  reply	other threads:[~2016-05-25 13:19 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-20 10:54 [PATCH V5 0/7] iommu/msm: Add DT adaptation and generic bindings support Sricharan R
2016-05-20 10:54 ` Sricharan R
2016-05-20 10:54 ` [PATCH V5 1/7] iommu/msm: Add DT adaptation Sricharan R
2016-05-20 10:54   ` Sricharan R
2016-05-20 10:54 ` [PATCH V5 2/7] documentation: iommu: Add bindings for msm,iommu-v0 ip Sricharan R
2016-05-20 10:54   ` [PATCH V5 2/7] documentation: iommu: Add bindings for msm, iommu-v0 ip Sricharan R
     [not found]   ` <1463741694-1735-3-git-send-email-sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-05-23 21:23     ` [PATCH V5 2/7] documentation: iommu: Add bindings for msm,iommu-v0 ip Rob Herring
2016-05-23 21:23       ` Rob Herring
     [not found] ` <1463741694-1735-1-git-send-email-sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-05-20 10:54   ` [PATCH V5 3/7] iommu/msm: Move the contents from msm_iommu_dev.c to msm_iommu.c Sricharan R
2016-05-20 10:54     ` Sricharan R
2016-05-23  8:10   ` [PATCH V5 0/7] iommu/msm: Add DT adaptation and generic bindings support Srinivas Kandagatla
2016-05-23  8:10     ` Srinivas Kandagatla
2016-05-20 10:54 ` [PATCH V5 4/7] iommu/msm: Add support for generic master bindings Sricharan R
2016-05-20 10:54   ` Sricharan R
2016-05-20 10:54 ` [PATCH V5 5/7] iommu/msm: use generic ARMV7S short descriptor pagetable ops Sricharan R
2016-05-20 10:54   ` Sricharan R
2016-05-20 10:54 ` [PATCH V5 6/7] iommu/msm: Use writel_relaxed and add a barrier Sricharan R
2016-05-20 10:54   ` Sricharan R
     [not found]   ` <1463741694-1735-7-git-send-email-sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-05-20 11:44     ` Arnd Bergmann
2016-05-20 11:44       ` Arnd Bergmann
2016-05-20 12:20       ` Arnd Bergmann
2016-05-20 12:20         ` Arnd Bergmann
2016-05-23  6:05       ` Sricharan
2016-05-23  6:05         ` Sricharan
2016-05-24 14:00         ` Arnd Bergmann
2016-05-24 14:00           ` Arnd Bergmann
2016-05-25 10:45           ` Sricharan
2016-05-25 10:45             ` Sricharan
2016-05-25 12:18             ` Arnd Bergmann
2016-05-25 12:18               ` Arnd Bergmann
2016-05-25 13:19               ` Sricharan [this message]
2016-05-25 13:19                 ` Sricharan
2016-05-25 14:15                 ` Arnd Bergmann
2016-05-25 14:15                   ` Arnd Bergmann
2016-05-25 16:49                   ` Sricharan
2016-05-25 16:49                     ` Sricharan
2016-05-20 10:54 ` [PATCH V5 7/7] iommu/msm: Remove driver BROKEN Sricharan R
2016-05-20 10:54   ` Sricharan R
2016-05-23  2:53 ` [PATCH V5 0/7] iommu/msm: Add DT adaptation and generic bindings support Archit Taneja
2016-05-23  2:53   ` Archit Taneja

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='004c01d1b688$0f6379c0$2e2a6d40$@codeaurora.org' \
    --to=sricharan@codeaurora.org \
    --cc=architt@codeaurora.org \
    --cc=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=robdclark@gmail.com \
    --cc=robin.murphy@arm.com \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=stepanm@codeaurora.org \
    --cc=treding@nvidia.com \
    /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.