From: JeffyChen <jeffy.chen@rock-chips.com> To: Robin Murphy <robin.murphy@arm.com>, Rob Herring <robh@kernel.org>, Tomasz Figa <tfiga@chromium.org> Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Ricky Liang <jcliang@chromium.org>, simon xue <xxm@rock-chips.com>, devicetree@vger.kernel.org, Heiko Stuebner <heiko@sntech.de>, "open list:ARM/Rockchip SoC..." <linux-rockchip@lists.infradead.org>, "list@263.net:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, Mark Rutland <mark.rutland@arm.com>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v5 08/13] iommu/rockchip: Control clocks needed to access the IOMMU Date: Wed, 28 Feb 2018 21:00:57 +0800 [thread overview] Message-ID: <5A96A809.2020509@rock-chips.com> (raw) In-Reply-To: <33d1d6bd-3455-5cad-6990-a9ca94063f3a@arm.com> Hi Robin, Thanks for your reply. On 02/28/2018 12:59 AM, Robin Murphy wrote: >>> the rockchip IOMMU is part of the master block in hardware, so it needs >>> to control the master's power domain and some of the master's clocks >>> when access it's registers. >>> >>> and the number of clocks needed here, might be different between each >>> IOMMUs(according to which master block it belongs), it's a little like >>> our power domain: >>> https://elixir.free-electrons.com/linux/latest/source/arch/arm64/boot/dts/rockchip/rk3399.dtsi#L935 >>> >>> >>> >>> i'm not sure how to describe this correctly, is it ok use something like >>> "the same as it's master block"? >> >> would it make sense to add a property to specify the master who owns >> the iommu, and we can get all clocks(only some of those clocks are >> actually needed) from it in the of_xlate()? and we can also reuse the >> clock-names of that master to build clk_bulk_data and log errors in >> clk_bulk_get. > > I'm inclined to agree with Rob here - if we're to add anything to the > binding, it should only be whatever clock inputs are defined for the > IOMMU IP block itself. If Linux doesn't properly handle the interconnect > clock hierarchy external to a particular integration, that's a separate > issue and it's not the binding's problem. > > I actually quite like the hack of "borrowing" the clocks from > dev->of_node in of_xlate() - you shouldn't need any DT changes for that, > because you already know that each IOMMU instance only has the one > master device anyway. Thanks:) but actually we are going to support sharing IOMMU between multiple masters(one of them is the main master i think) in the newer chips(not yet supported on upstream kernel)... So we might have to get all clocks from all masters, or find a way to specify the main master...and for the multiple masters case, do it in of_xlate() turns out to be a little racy...maybe we can add a property to specify main master, and get it's clocks in probe()? > > Robin.
WARNING: multiple messages have this Message-ID (diff)
From: jeffy.chen@rock-chips.com (JeffyChen) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v5 08/13] iommu/rockchip: Control clocks needed to access the IOMMU Date: Wed, 28 Feb 2018 21:00:57 +0800 [thread overview] Message-ID: <5A96A809.2020509@rock-chips.com> (raw) In-Reply-To: <33d1d6bd-3455-5cad-6990-a9ca94063f3a@arm.com> Hi Robin, Thanks for your reply. On 02/28/2018 12:59 AM, Robin Murphy wrote: >>> the rockchip IOMMU is part of the master block in hardware, so it needs >>> to control the master's power domain and some of the master's clocks >>> when access it's registers. >>> >>> and the number of clocks needed here, might be different between each >>> IOMMUs(according to which master block it belongs), it's a little like >>> our power domain: >>> https://elixir.free-electrons.com/linux/latest/source/arch/arm64/boot/dts/rockchip/rk3399.dtsi#L935 >>> >>> >>> >>> i'm not sure how to describe this correctly, is it ok use something like >>> "the same as it's master block"? >> >> would it make sense to add a property to specify the master who owns >> the iommu, and we can get all clocks(only some of those clocks are >> actually needed) from it in the of_xlate()? and we can also reuse the >> clock-names of that master to build clk_bulk_data and log errors in >> clk_bulk_get. > > I'm inclined to agree with Rob here - if we're to add anything to the > binding, it should only be whatever clock inputs are defined for the > IOMMU IP block itself. If Linux doesn't properly handle the interconnect > clock hierarchy external to a particular integration, that's a separate > issue and it's not the binding's problem. > > I actually quite like the hack of "borrowing" the clocks from > dev->of_node in of_xlate() - you shouldn't need any DT changes for that, > because you already know that each IOMMU instance only has the one > master device anyway. Thanks:) but actually we are going to support sharing IOMMU between multiple masters(one of them is the main master i think) in the newer chips(not yet supported on upstream kernel)... So we might have to get all clocks from all masters, or find a way to specify the main master...and for the multiple masters case, do it in of_xlate() turns out to be a little racy...maybe we can add a property to specify main master, and get it's clocks in probe()? > > Robin.
next prev parent reply other threads:[~2018-02-28 13:01 UTC|newest] Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-01-24 10:35 [PATCH v5 00/13] iommu/rockchip: Use OF_IOMMU Jeffy Chen 2018-01-24 10:35 ` Jeffy Chen 2018-01-24 10:35 ` Jeffy Chen 2018-01-24 10:35 ` [PATCH v5 01/13] iommu/rockchip: Prohibit unbind and remove Jeffy Chen 2018-01-24 10:35 ` Jeffy Chen 2018-01-24 10:35 ` Jeffy Chen 2018-01-24 10:35 ` [PATCH v5 02/13] iommu/rockchip: Fix error handling in probe Jeffy Chen 2018-01-24 10:35 ` Jeffy Chen 2018-01-24 10:35 ` [PATCH v5 03/13] iommu/rockchip: Request irqs in rk_iommu_probe() Jeffy Chen 2018-01-24 10:35 ` Jeffy Chen 2018-01-24 10:35 ` [PATCH v5 04/13] iommu/rockchip: Fix error handling in attach Jeffy Chen 2018-01-24 10:35 ` Jeffy Chen 2018-01-24 10:35 ` [PATCH v5 05/13] iommu/rockchip: Use iopoll helpers to wait for hardware Jeffy Chen 2018-01-24 10:35 ` Jeffy Chen 2018-01-24 10:35 ` [PATCH v5 06/13] iommu/rockchip: Fix TLB flush of secondary IOMMUs Jeffy Chen 2018-01-24 10:35 ` Jeffy Chen 2018-01-24 10:35 ` [PATCH v5 07/13] ARM: dts: rockchip: add clocks in vop iommu nodes Jeffy Chen 2018-01-24 10:35 ` Jeffy Chen 2018-01-24 10:35 ` Jeffy Chen 2018-01-24 10:35 ` [PATCH v5 08/13] iommu/rockchip: Control clocks needed to access the IOMMU Jeffy Chen 2018-01-24 10:35 ` Jeffy Chen 2018-01-24 10:35 ` Jeffy Chen 2018-01-24 13:49 ` Robin Murphy 2018-01-24 13:49 ` Robin Murphy 2018-01-26 9:45 ` JeffyChen 2018-01-26 9:45 ` JeffyChen 2018-01-26 9:45 ` JeffyChen 2018-02-14 10:03 ` Vivek Gautam 2018-02-14 10:03 ` Vivek Gautam 2018-02-14 10:03 ` Vivek Gautam 2018-02-14 11:27 ` Tomasz Figa 2018-02-14 11:27 ` Tomasz Figa 2018-02-14 11:27 ` Tomasz Figa via iommu 2018-01-30 17:05 ` Rob Herring 2018-01-30 17:05 ` Rob Herring 2018-01-30 17:05 ` Rob Herring 2018-01-31 7:52 ` Tomasz Figa 2018-01-31 7:52 ` Tomasz Figa 2018-01-31 7:52 ` Tomasz Figa 2018-01-31 13:50 ` Rob Herring 2018-01-31 13:50 ` Rob Herring 2018-01-31 13:50 ` Rob Herring 2018-02-01 11:19 ` JeffyChen [not found] ` <5A72F7D2.1050201-TNX95d0MmH7DzftRWevZcw@public.gmane.org> 2018-02-23 10:24 ` JeffyChen 2018-02-27 16:59 ` Robin Murphy 2018-02-27 16:59 ` Robin Murphy 2018-02-27 16:59 ` Robin Murphy 2018-02-28 13:00 ` JeffyChen [this message] 2018-02-28 13:00 ` JeffyChen 2018-02-28 15:06 ` Robin Murphy 2018-02-28 15:06 ` Robin Murphy 2018-02-28 15:06 ` Robin Murphy 2018-03-01 1:37 ` JeffyChen 2018-03-01 1:37 ` JeffyChen 2018-03-01 1:37 ` JeffyChen 2018-01-24 10:35 ` [PATCH v5 09/13] iommu/rockchip: Use IOMMU device for dma mapping operations Jeffy Chen 2018-01-24 10:35 ` Jeffy Chen 2018-01-24 10:35 ` [PATCH v5 10/13] iommu/rockchip: Use OF_IOMMU to attach devices automatically Jeffy Chen 2018-01-24 10:35 ` Jeffy Chen 2018-01-24 10:35 ` Jeffy Chen 2018-01-24 10:35 ` [PATCH v5 11/13] iommu/rockchip: Fix error handling in init Jeffy Chen 2018-01-24 10:35 ` Jeffy Chen 2018-01-24 10:35 ` [PATCH v5 12/13] iommu/rockchip: Add runtime PM support Jeffy Chen 2018-01-24 10:35 ` Jeffy Chen 2018-01-24 10:35 ` Jeffy Chen 2018-01-24 10:35 ` [PATCH v5 13/13] iommu/rockchip: Support sharing IOMMU between masters Jeffy Chen 2018-01-24 10:35 ` Jeffy Chen 2018-01-24 10:35 ` Jeffy Chen
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=5A96A809.2020509@rock-chips.com \ --to=jeffy.chen@rock-chips.com \ --cc=devicetree@vger.kernel.org \ --cc=heiko@sntech.de \ --cc=iommu@lists.linux-foundation.org \ --cc=jcliang@chromium.org \ --cc=joro@8bytes.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-rockchip@lists.infradead.org \ --cc=mark.rutland@arm.com \ --cc=robh@kernel.org \ --cc=robin.murphy@arm.com \ --cc=tfiga@chromium.org \ --cc=xxm@rock-chips.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: linkBe 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.