All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yong Wu <yong.wu@mediatek.com>
To: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Joerg Roedel <joro@8bytes.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Rob Herring <robh+dt@kernel.org>,
	youlin.pei@mediatek.com, devicetree@vger.kernel.org,
	Nicolas Boichat <drinkcat@chromium.org>,
	arnd@arndb.de, srv_heupstream@mediatek.com,
	Will Deacon <will.deacon@arm.com>,
	linux-kernel@vger.kernel.org, Tomasz Figa <tfiga@google.com>,
	iommu@lists.linux-foundation.org,
	linux-mediatek@lists.infradead.org,
	Arvind Yadav <arvind.yadav.cs@gmail.com>,
	yingjoe.chen@mediatek.com, linux-arm-kernel@lists.infradead.org,
	YT.shen@mediatek.com
Subject: Re: [PATCH v3 13/15] memory: mtk-smi: Get rid of need_larbid
Date: Mon, 3 Dec 2018 16:40:51 +0800	[thread overview]
Message-ID: <1543826451.23023.35.camel@mhfsdcap03> (raw)
In-Reply-To: <21767ceb-1db5-045f-06ac-29c57f1a74a5@gmail.com>

On Mon, 2018-12-03 at 00:04 +0100, Matthias Brugger wrote:
> 
> On 17/11/2018 03:35, Yong Wu wrote:
> > The "mediatek,larb-id" has already been parsed in MTK IOMMU driver.
> > It's no need to parse it again in SMI driver. Only clean some codes.
> > This patch is fit for all the current mt2701, mt2712, mt7623, mt8173
> > and mt8183.
> 
> I'm trying to understand why we need the mediatek,larb-id at all. From what I
> understand as long as the mediatek larbs described in the iommu are ordered
> (larb0, larb1, larb2, etc) we actually get the same value as defined by
> mediatek,larb-id. At least this holds for all present implementations.
> 
> On the other hand I don't see where the mtk_iommu_v1 driver actually parses the
> larb-id, can you please help to understand:
> 
> 1) why we need the larb-id at all

Actually only mt2712 which have 2 M4U HW need "mediatek,larb-id".

This is larbs in the m4u0/1 dtsi node of mt2712:
m4u0 { mediatek,larbs = <&larb0 &larb1 &larb2 &larb3 &larb6>;}
m4u1 { mediatek,larbs = <&larb4 &larb5 &larb7>;}

the id don't increase one by one, M4U have to get the larbid with the
help of "mediatek,larb-id".

(The m4u/smi dtsi patch of mt2712 will be send with some other modules,
maybe in this week.)


> 2) how this will work if we do not parse the larb-id for v1 iommu at all

As you said above and I also have wrote that the larbid "must sort
according to the local arbiter index" in the "mediatek,larbs"
description of dt-binding. All the M4U except mt2712 could ignore
"mediatek,larb-id". the v1 iommu also should be ok.

I'm not sure whether we should change [1], if only reserving mt2712
there, we also should change the dtsi file of mt2701 and mt7623.or keep
it as is.

[1]
https://elixir.bootlin.com/linux/v4.20-rc1/source/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt#L20

> 
> Thanks a lot,
> Matthias
> 
> > 

[snip]

WARNING: multiple messages have this Message-ID (diff)
From: Yong Wu <yong.wu@mediatek.com>
To: Matthias Brugger <matthias.bgg@gmail.com>
Cc: youlin.pei@mediatek.com, devicetree@vger.kernel.org,
	Nicolas Boichat <drinkcat@chromium.org>,
	srv_heupstream@mediatek.com, arnd@arndb.de,
	Joerg Roedel <joro@8bytes.org>, Will Deacon <will.deacon@arm.com>,
	linux-kernel@vger.kernel.org, Tomasz Figa <tfiga@google.com>,
	iommu@lists.linux-foundation.org,
	Rob Herring <robh+dt@kernel.org>,
	linux-mediatek@lists.infradead.org, yingjoe.chen@mediatek.com,
	YT.shen@mediatek.com, Arvind Yadav <arvind.yadav.cs@gmail.com>,
	Robin Murphy <robin.murphy@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 13/15] memory: mtk-smi: Get rid of need_larbid
Date: Mon, 3 Dec 2018 16:40:51 +0800	[thread overview]
Message-ID: <1543826451.23023.35.camel@mhfsdcap03> (raw)
In-Reply-To: <21767ceb-1db5-045f-06ac-29c57f1a74a5@gmail.com>

On Mon, 2018-12-03 at 00:04 +0100, Matthias Brugger wrote:
> 
> On 17/11/2018 03:35, Yong Wu wrote:
> > The "mediatek,larb-id" has already been parsed in MTK IOMMU driver.
> > It's no need to parse it again in SMI driver. Only clean some codes.
> > This patch is fit for all the current mt2701, mt2712, mt7623, mt8173
> > and mt8183.
> 
> I'm trying to understand why we need the mediatek,larb-id at all. From what I
> understand as long as the mediatek larbs described in the iommu are ordered
> (larb0, larb1, larb2, etc) we actually get the same value as defined by
> mediatek,larb-id. At least this holds for all present implementations.
> 
> On the other hand I don't see where the mtk_iommu_v1 driver actually parses the
> larb-id, can you please help to understand:
> 
> 1) why we need the larb-id at all

Actually only mt2712 which have 2 M4U HW need "mediatek,larb-id".

This is larbs in the m4u0/1 dtsi node of mt2712:
m4u0 { mediatek,larbs = <&larb0 &larb1 &larb2 &larb3 &larb6>;}
m4u1 { mediatek,larbs = <&larb4 &larb5 &larb7>;}

the id don't increase one by one, M4U have to get the larbid with the
help of "mediatek,larb-id".

(The m4u/smi dtsi patch of mt2712 will be send with some other modules,
maybe in this week.)


> 2) how this will work if we do not parse the larb-id for v1 iommu at all

As you said above and I also have wrote that the larbid "must sort
according to the local arbiter index" in the "mediatek,larbs"
description of dt-binding. All the M4U except mt2712 could ignore
"mediatek,larb-id". the v1 iommu also should be ok.

I'm not sure whether we should change [1], if only reserving mt2712
there, we also should change the dtsi file of mt2701 and mt7623.or keep
it as is.

[1]
https://elixir.bootlin.com/linux/v4.20-rc1/source/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt#L20

> 
> Thanks a lot,
> Matthias
> 
> > 

[snip]



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Yong Wu <yong.wu@mediatek.com>
To: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Joerg Roedel <joro@8bytes.org>,
	Robin Murphy <robin.murphy@arm.com>,
	"Rob Herring" <robh+dt@kernel.org>, <youlin.pei@mediatek.com>,
	<devicetree@vger.kernel.org>,
	Nicolas Boichat <drinkcat@chromium.org>, <arnd@arndb.de>,
	<srv_heupstream@mediatek.com>, Will Deacon <will.deacon@arm.com>,
	<linux-kernel@vger.kernel.org>, Tomasz Figa <tfiga@google.com>,
	<iommu@lists.linux-foundation.org>,
	<linux-mediatek@lists.infradead.org>,
	Arvind Yadav <arvind.yadav.cs@gmail.com>,
	<yingjoe.chen@mediatek.com>,
	<linux-arm-kernel@lists.infradead.org>, <YT.shen@mediatek.com>
Subject: Re: [PATCH v3 13/15] memory: mtk-smi: Get rid of need_larbid
Date: Mon, 3 Dec 2018 16:40:51 +0800	[thread overview]
Message-ID: <1543826451.23023.35.camel@mhfsdcap03> (raw)
In-Reply-To: <21767ceb-1db5-045f-06ac-29c57f1a74a5@gmail.com>

On Mon, 2018-12-03 at 00:04 +0100, Matthias Brugger wrote:
> 
> On 17/11/2018 03:35, Yong Wu wrote:
> > The "mediatek,larb-id" has already been parsed in MTK IOMMU driver.
> > It's no need to parse it again in SMI driver. Only clean some codes.
> > This patch is fit for all the current mt2701, mt2712, mt7623, mt8173
> > and mt8183.
> 
> I'm trying to understand why we need the mediatek,larb-id at all. From what I
> understand as long as the mediatek larbs described in the iommu are ordered
> (larb0, larb1, larb2, etc) we actually get the same value as defined by
> mediatek,larb-id. At least this holds for all present implementations.
> 
> On the other hand I don't see where the mtk_iommu_v1 driver actually parses the
> larb-id, can you please help to understand:
> 
> 1) why we need the larb-id at all

Actually only mt2712 which have 2 M4U HW need "mediatek,larb-id".

This is larbs in the m4u0/1 dtsi node of mt2712:
m4u0 { mediatek,larbs = <&larb0 &larb1 &larb2 &larb3 &larb6>;}
m4u1 { mediatek,larbs = <&larb4 &larb5 &larb7>;}

the id don't increase one by one, M4U have to get the larbid with the
help of "mediatek,larb-id".

(The m4u/smi dtsi patch of mt2712 will be send with some other modules,
maybe in this week.)


> 2) how this will work if we do not parse the larb-id for v1 iommu at all

As you said above and I also have wrote that the larbid "must sort
according to the local arbiter index" in the "mediatek,larbs"
description of dt-binding. All the M4U except mt2712 could ignore
"mediatek,larb-id". the v1 iommu also should be ok.

I'm not sure whether we should change [1], if only reserving mt2712
there, we also should change the dtsi file of mt2701 and mt7623.or keep
it as is.

[1]
https://elixir.bootlin.com/linux/v4.20-rc1/source/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt#L20

> 
> Thanks a lot,
> Matthias
> 
> > 

[snip]



  reply	other threads:[~2018-12-03  8:40 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-17  2:35 [PATCH v3 00/15] MT8183 IOMMU SUPPORT Yong Wu
2018-11-17  2:35 ` Yong Wu
2018-11-17  2:35 ` Yong Wu
2018-11-17  2:35 ` [PATCH v3 01/15] dt-bindings: mediatek: Add binding for mt8183 IOMMU and SMI Yong Wu
2018-11-17  2:35   ` Yong Wu
2018-11-17  2:35   ` Yong Wu
2018-11-17  2:35 ` [PATCH v3 03/15] memory: mtk-smi: Use a general config_port interface Yong Wu
2018-11-17  2:35   ` Yong Wu
2018-11-17  2:35   ` Yong Wu
     [not found] ` <1542422142-30688-1-git-send-email-yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2018-11-17  2:35   ` [PATCH v3 02/15] iommu/mediatek: Use a struct as the platform data Yong Wu
2018-11-17  2:35     ` Yong Wu
2018-11-17  2:35     ` Yong Wu
2018-11-17  2:35   ` [PATCH v3 04/15] iommu/io-pgtable-arm-v7s: Add paddr_to_iopte and iopte_to_paddr helpers Yong Wu
2018-11-17  2:35     ` Yong Wu
2018-11-17  2:35     ` Yong Wu
2018-11-17  2:35   ` [PATCH v3 05/15] iommu/io-pgtable-arm-v7s: Extend MediaTek 4GB Mode Yong Wu
2018-11-17  2:35     ` Yong Wu
2018-11-17  2:35     ` Yong Wu
2018-11-17  2:35   ` [PATCH v3 06/15] iommu/mediatek: Add mt8183 IOMMU support Yong Wu
2018-11-17  2:35     ` Yong Wu
2018-11-17  2:35     ` Yong Wu
     [not found]     ` <1542422142-30688-7-git-send-email-yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2018-12-02 23:56       ` Matthias Brugger
2018-12-02 23:56         ` Matthias Brugger
2018-12-02 23:56         ` Matthias Brugger
2018-12-03  8:40         ` Yong Wu
2018-12-03  8:40           ` Yong Wu
2018-12-03  8:40           ` Yong Wu
2018-11-17  2:35   ` [PATCH v3 08/15] memory: mtk-smi: Invoke pm runtime_callback to enable clocks Yong Wu
2018-11-17  2:35     ` Yong Wu
2018-11-17  2:35     ` Yong Wu
2018-11-17  2:35   ` [PATCH v3 09/15] memory: mtk-smi: Use a struct for the platform data for smi-common Yong Wu
2018-11-17  2:35     ` Yong Wu
2018-11-17  2:35     ` Yong Wu
2018-11-17  2:35   ` [PATCH v3 10/15] memory: mtk-smi: Add bus_sel for mt8183 Yong Wu
2018-11-17  2:35     ` Yong Wu
2018-11-17  2:35     ` Yong Wu
     [not found]     ` <1542422142-30688-11-git-send-email-yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2018-11-23  2:59       ` Yong Wu
2018-11-23  2:59         ` Yong Wu
2018-11-23  2:59         ` Yong Wu
2018-11-17  2:35   ` [PATCH v3 12/15] iommu/mediatek: Add shutdown callback Yong Wu
2018-11-17  2:35     ` Yong Wu
2018-11-17  2:35     ` Yong Wu
2018-11-17  2:35   ` [PATCH v3 13/15] memory: mtk-smi: Get rid of need_larbid Yong Wu
2018-11-17  2:35     ` Yong Wu
2018-11-17  2:35     ` Yong Wu
2018-12-02 23:04     ` Matthias Brugger
2018-12-02 23:04       ` Matthias Brugger
2018-12-03  8:40       ` Yong Wu [this message]
2018-12-03  8:40         ` Yong Wu
2018-12-03  8:40         ` Yong Wu
2018-11-17  2:35   ` [PATCH v3 14/15] iommu/mediatek: Constify iommu_ops Yong Wu
2018-11-17  2:35     ` Yong Wu
2018-11-17  2:35     ` Yong Wu
2018-11-17  2:35   ` [PATCH v3 15/15] iommu/mediatek: Switch to SPDX license identifier Yong Wu
2018-11-17  2:35     ` Yong Wu
2018-11-17  2:35     ` Yong Wu
2018-11-17  2:35 ` [PATCH v3 07/15] iommu/mediatek: Add mmu1 support Yong Wu
2018-11-17  2:35   ` Yong Wu
2018-11-17  2:35   ` Yong Wu
2018-11-17  2:35 ` [PATCH v3 11/15] iommu/mediatek: Add VLD_PA_RANGE register backup when suspend Yong Wu
2018-11-17  2:35   ` Yong Wu
2018-11-17  2:35   ` Yong Wu
2018-11-22 12:59 ` [PATCH v3 00/15] MT8183 IOMMU SUPPORT Joerg Roedel
2018-11-22 12:59   ` Joerg Roedel
     [not found]   ` <20181122125931.GC1586-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2018-11-22 13:35     ` Will Deacon
2018-11-22 13:35       ` Will Deacon
2018-11-22 13:35       ` Will Deacon
2018-11-22 13:42       ` Joerg Roedel
2018-11-22 13:42         ` Joerg Roedel
2018-11-23  2:55       ` Yong Wu
2018-11-23  2:55         ` Yong Wu
2018-11-23  2:55         ` Yong Wu

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=1543826451.23023.35.camel@mhfsdcap03 \
    --to=yong.wu@mediatek.com \
    --cc=YT.shen@mediatek.com \
    --cc=arnd@arndb.de \
    --cc=arvind.yadav.cs@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=drinkcat@chromium.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=srv_heupstream@mediatek.com \
    --cc=tfiga@google.com \
    --cc=will.deacon@arm.com \
    --cc=yingjoe.chen@mediatek.com \
    --cc=youlin.pei@mediatek.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.