From: Dmitry Osipenko <digetx@gmail.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Nicolin Chen <nicoleotsuka@gmail.com>,
joro@8bytes.org, krzk@kernel.org, vdumpa@nvidia.com,
jonathanh@nvidia.com, linux-tegra@vger.kernel.org,
iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/3] memory: tegra: Add devm_tegra_get_memory_controller()
Date: Wed, 30 Sep 2020 20:32:37 +0300 [thread overview]
Message-ID: <eacbcce4-4574-6b24-9f06-02349ec3092f@gmail.com> (raw)
In-Reply-To: <20200930163842.GA3852280@ulmo>
...
>> I don't think that the MC driver will stay built-in forever, although
>> its modularization is complicated right now. Hence something shall keep
>> the reference to the MC device resources while they are in use and this
>> patch takes care of doing that.
>
> It looks to me like all the other places where we get a reference to the
> MC also keep a reference to the device. That's obviously not going to be
> enough once the code is turned into a module. At that point we need to
> make sure to also grab a reference to the module. But that's orthogonal
> to this discussion.
>
>> Secondly, the Nicolin's patch doesn't pretend on anything, but rather
>
> Yes, the patch does pretend to "look up" the memory controller device,
> but in reality it will always return a singleton object, which can just
> as easily be achieved by using a global variable.
>
>> brings the already existing duplicated code to a single common place.
>
> Where exactly is that duplicated code? The only places I see where we
> get a reference to the memory controller are from the EMC drivers and
> they properly look up the MC via the nvidia,memory-controller device
> tree property.
Yours observation is correct, all the drivers *do the lookup*. My point
is that the nvidia,memory-controller usage isn't strictly necessary.
The tegra20-devfreq driver doesn't use the phandle lookup because
Tegra20 DTs don't have it, instead it uses the compatible lookup. Hence
this patch doesn't really change the already existing behaviour for the
drivers. The phandle usage is optional.
This patch adds a common API that is usable by *all* the already
existing drivers, starting from the Tegra20 drivers.
> But that's not what this new helper does. This code will use the OF
> lookup table to find any match and then returns that, completely
> ignoring any links established by the device tree.
As I already said in the other reply, it should be fine to add lookup by
the phandle and then fall back to the compatible matching. On the other
hand, this is not strictly necessary because we always have only a
single MC device at a time.
Please note that I don't have any objections to improving this patch. In
the end either way will work, so we just need to choose the best option.
I was merely explaining the rationale behind this patch and not trying
to defend it.
Yours suggestion about using static mc variable is also good to me since
currently MC driver is built-in and at least that won't be a
globally-visible kernel variable, which doesn't feel great to have.
I think we can follow approach of the static mc variable for the starter
and improve it once there will be a real need. This should be the
simplest option right now.
But again, we may slightly future-proof the API by adding the
resource-managed variant. Either way will be good, IMO :) Currently I
don't have a strong preference.
WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Osipenko <digetx@gmail.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
krzk@kernel.org, jonathanh@nvidia.com,
linux-tegra@vger.kernel.org
Subject: Re: [PATCH v3 1/3] memory: tegra: Add devm_tegra_get_memory_controller()
Date: Wed, 30 Sep 2020 20:32:37 +0300 [thread overview]
Message-ID: <eacbcce4-4574-6b24-9f06-02349ec3092f@gmail.com> (raw)
In-Reply-To: <20200930163842.GA3852280@ulmo>
...
>> I don't think that the MC driver will stay built-in forever, although
>> its modularization is complicated right now. Hence something shall keep
>> the reference to the MC device resources while they are in use and this
>> patch takes care of doing that.
>
> It looks to me like all the other places where we get a reference to the
> MC also keep a reference to the device. That's obviously not going to be
> enough once the code is turned into a module. At that point we need to
> make sure to also grab a reference to the module. But that's orthogonal
> to this discussion.
>
>> Secondly, the Nicolin's patch doesn't pretend on anything, but rather
>
> Yes, the patch does pretend to "look up" the memory controller device,
> but in reality it will always return a singleton object, which can just
> as easily be achieved by using a global variable.
>
>> brings the already existing duplicated code to a single common place.
>
> Where exactly is that duplicated code? The only places I see where we
> get a reference to the memory controller are from the EMC drivers and
> they properly look up the MC via the nvidia,memory-controller device
> tree property.
Yours observation is correct, all the drivers *do the lookup*. My point
is that the nvidia,memory-controller usage isn't strictly necessary.
The tegra20-devfreq driver doesn't use the phandle lookup because
Tegra20 DTs don't have it, instead it uses the compatible lookup. Hence
this patch doesn't really change the already existing behaviour for the
drivers. The phandle usage is optional.
This patch adds a common API that is usable by *all* the already
existing drivers, starting from the Tegra20 drivers.
> But that's not what this new helper does. This code will use the OF
> lookup table to find any match and then returns that, completely
> ignoring any links established by the device tree.
As I already said in the other reply, it should be fine to add lookup by
the phandle and then fall back to the compatible matching. On the other
hand, this is not strictly necessary because we always have only a
single MC device at a time.
Please note that I don't have any objections to improving this patch. In
the end either way will work, so we just need to choose the best option.
I was merely explaining the rationale behind this patch and not trying
to defend it.
Yours suggestion about using static mc variable is also good to me since
currently MC driver is built-in and at least that won't be a
globally-visible kernel variable, which doesn't feel great to have.
I think we can follow approach of the static mc variable for the starter
and improve it once there will be a real need. This should be the
simplest option right now.
But again, we may slightly future-proof the API by adding the
resource-managed variant. Either way will be good, IMO :) Currently I
don't have a strong preference.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-09-30 17:32 UTC|newest]
Thread overview: 132+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-30 8:42 [PATCH v3 0/3] iommu/tegra-smmu: Add PCI support Nicolin Chen
2020-09-30 8:42 ` Nicolin Chen
2020-09-30 8:42 ` [PATCH v3 1/3] memory: tegra: Add devm_tegra_get_memory_controller() Nicolin Chen
2020-09-30 8:42 ` Nicolin Chen
2020-09-30 9:07 ` Krzysztof Kozlowski
2020-09-30 9:07 ` Krzysztof Kozlowski
2020-09-30 9:41 ` Nicolin Chen
2020-09-30 9:41 ` Nicolin Chen
2020-09-30 10:27 ` Krzysztof Kozlowski
2020-09-30 10:27 ` Krzysztof Kozlowski
2020-09-30 14:41 ` Dmitry Osipenko
2020-09-30 14:41 ` Dmitry Osipenko
2020-09-30 14:45 ` Krzysztof Kozlowski
2020-09-30 14:45 ` Krzysztof Kozlowski
2020-09-30 15:22 ` Dmitry Osipenko
2020-09-30 15:22 ` Dmitry Osipenko
2020-09-30 15:23 ` Thierry Reding
2020-09-30 15:23 ` Thierry Reding
2020-09-30 15:27 ` Dmitry Osipenko
2020-09-30 15:27 ` Dmitry Osipenko
2020-09-30 15:53 ` Dmitry Osipenko
2020-09-30 15:53 ` Dmitry Osipenko
2020-09-30 16:03 ` Thierry Reding
2020-09-30 16:03 ` Thierry Reding
2020-09-30 16:06 ` Dmitry Osipenko
2020-09-30 16:06 ` Dmitry Osipenko
2020-09-30 16:15 ` Thierry Reding
2020-09-30 16:15 ` Thierry Reding
2020-09-30 16:26 ` Dmitry Osipenko
2020-09-30 16:26 ` Dmitry Osipenko
2020-09-30 16:38 ` Thierry Reding
2020-09-30 16:38 ` Thierry Reding
2020-09-30 17:32 ` Dmitry Osipenko [this message]
2020-09-30 17:32 ` Dmitry Osipenko
2020-09-30 8:42 ` [PATCH v3 2/3] iommu/tegra-smmu: Rework .probe_device and .attach_dev Nicolin Chen
2020-09-30 8:42 ` Nicolin Chen
2020-09-30 9:21 ` Krzysztof Kozlowski
2020-09-30 9:21 ` Krzysztof Kozlowski
2020-09-30 9:40 ` Nicolin Chen
2020-09-30 9:40 ` Nicolin Chen
2020-09-30 10:19 ` Krzysztof Kozlowski
2020-09-30 10:19 ` Krzysztof Kozlowski
2020-09-30 14:41 ` Dmitry Osipenko
2020-09-30 14:41 ` Dmitry Osipenko
2020-09-30 15:09 ` Dmitry Osipenko
2020-09-30 15:09 ` Dmitry Osipenko
2020-09-30 20:51 ` Nicolin Chen
2020-09-30 20:51 ` Nicolin Chen
2020-09-30 15:31 ` Thierry Reding
2020-09-30 15:31 ` Thierry Reding
2020-09-30 15:36 ` Dmitry Osipenko
2020-09-30 15:36 ` Dmitry Osipenko
2020-09-30 16:06 ` Thierry Reding
2020-09-30 16:06 ` Thierry Reding
2020-09-30 16:25 ` Dmitry Osipenko
2020-09-30 16:25 ` Dmitry Osipenko
2020-09-30 16:47 ` Thierry Reding
2020-09-30 16:47 ` Thierry Reding
2020-10-01 2:11 ` Dmitry Osipenko
2020-10-01 2:11 ` Dmitry Osipenko
2020-10-01 7:58 ` Thierry Reding
2020-10-01 7:58 ` Thierry Reding
2020-10-01 19:04 ` Dmitry Osipenko
2020-10-01 19:04 ` Dmitry Osipenko
2020-10-05 9:16 ` Thierry Reding
2020-10-05 9:16 ` Thierry Reding
2020-10-05 9:38 ` Dmitry Osipenko
2020-10-05 9:38 ` Dmitry Osipenko
2020-10-05 10:27 ` Thierry Reding
2020-10-05 10:27 ` Thierry Reding
2020-09-30 16:10 ` Thierry Reding
2020-09-30 16:10 ` Thierry Reding
2020-09-30 16:29 ` Dmitry Osipenko
2020-09-30 16:29 ` Dmitry Osipenko
2020-10-01 7:59 ` Thierry Reding
2020-10-01 7:59 ` Thierry Reding
2020-09-30 20:36 ` Nicolin Chen
2020-09-30 20:36 ` Nicolin Chen
2020-09-30 21:24 ` Dmitry Osipenko
2020-09-30 21:24 ` Dmitry Osipenko
2020-09-30 21:32 ` Nicolin Chen
2020-09-30 21:32 ` Nicolin Chen
2020-09-30 21:56 ` Dmitry Osipenko
2020-09-30 21:56 ` Dmitry Osipenko
2020-10-01 1:26 ` Nicolin Chen
2020-10-01 1:26 ` Nicolin Chen
2020-10-01 2:06 ` Dmitry Osipenko
2020-10-01 2:06 ` Dmitry Osipenko
2020-10-01 2:48 ` Nicolin Chen
2020-10-01 2:48 ` Nicolin Chen
2020-10-01 4:04 ` Dmitry Osipenko
2020-10-01 4:04 ` Dmitry Osipenko
2020-10-01 10:23 ` Thierry Reding
2020-10-01 10:23 ` Thierry Reding
2020-10-01 11:04 ` Nicolin Chen
2020-10-01 11:04 ` Nicolin Chen
2020-10-01 20:33 ` Dmitry Osipenko
2020-10-01 20:33 ` Dmitry Osipenko
2020-10-02 1:07 ` Nicolin Chen
2020-10-02 1:07 ` Nicolin Chen
2020-10-02 1:55 ` Dmitry Osipenko
2020-10-02 1:55 ` Dmitry Osipenko
2020-10-02 2:54 ` Nicolin Chen
2020-10-02 2:54 ` Nicolin Chen
2020-10-05 7:24 ` Thierry Reding
2020-10-05 7:24 ` Thierry Reding
2020-10-05 7:13 ` Thierry Reding
2020-10-05 7:13 ` Thierry Reding
2020-10-05 8:14 ` Dmitry Osipenko
2020-10-05 8:14 ` Dmitry Osipenko
2020-10-05 9:31 ` Thierry Reding
2020-10-05 9:31 ` Thierry Reding
2020-10-01 9:54 ` Thierry Reding
2020-10-01 9:54 ` Thierry Reding
2020-10-01 9:51 ` Thierry Reding
2020-10-01 9:51 ` Thierry Reding
2020-10-01 10:33 ` Nicolin Chen
2020-10-01 10:33 ` Nicolin Chen
2020-10-01 10:42 ` Thierry Reding
2020-10-01 10:42 ` Thierry Reding
2020-10-01 9:47 ` Thierry Reding
2020-10-01 9:47 ` Thierry Reding
2020-10-01 10:46 ` Thierry Reding
2020-10-01 10:46 ` Thierry Reding
2020-10-02 1:29 ` Nicolin Chen
2020-10-02 1:29 ` Nicolin Chen
2020-09-30 8:42 ` [PATCH v3 3/3] iommu/tegra-smmu: Add PCI support Nicolin Chen
2020-09-30 8:42 ` Nicolin Chen
2020-09-30 14:53 ` Dmitry Osipenko
2020-09-30 14:53 ` Dmitry Osipenko
2020-09-30 20:03 ` Nicolin Chen
2020-09-30 20:03 ` Nicolin 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=eacbcce4-4574-6b24-9f06-02349ec3092f@gmail.com \
--to=digetx@gmail.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jonathanh@nvidia.com \
--cc=joro@8bytes.org \
--cc=krzk@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=nicoleotsuka@gmail.com \
--cc=thierry.reding@gmail.com \
--cc=vdumpa@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.