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.
next prev parent reply other threads:[~2018-02-28 13:00 UTC|newest]
Thread overview: 15+ 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
[not found] ` <20180124103516.2571-1-jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
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 ` [PATCH v5 08/13] iommu/rockchip: Control clocks needed to access the IOMMU Jeffy Chen
2018-01-24 13:49 ` Robin Murphy
[not found] ` <f06d2d9f-3869-ed02-43f4-f4ea4a104a57-5wv7dgnIgG8@public.gmane.org>
2018-01-26 9:45 ` JeffyChen
2018-02-14 10:03 ` Vivek Gautam
[not found] ` <edc5002d-c83f-cf11-ecfb-0c4400b10d07-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2018-02-14 11:27 ` Tomasz Figa via iommu
[not found] ` <20180124103516.2571-9-jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2018-01-30 17:05 ` Rob Herring
2018-01-31 7:52 ` Tomasz Figa
[not found] ` <CAAFQd5A383Ey3Ntg_hcsvzHj2DsSuW6RMQ+kP=LPAZ1YmqjHOg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
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
[not found] ` <33d1d6bd-3455-5cad-6990-a9ca94063f3a@arm.com>
2018-02-28 13:00 ` JeffyChen [this message]
[not found] ` <5A96A809.2020509-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2018-02-28 15:06 ` Robin Murphy
[not found] ` <34a60ab2-a3af-3302-6612-740cba5460db-5wv7dgnIgG8@public.gmane.org>
2018-03-01 1:37 ` JeffyChen
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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).