From: Jon Hunter <jonathanh@nvidia.com>
To: Vinod Koul <vinod.koul@intel.com>,
Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Laxman Dewangan <ldewangan@nvidia.com>,
Stephen Warren <swarren@wwwdotorg.org>,
Thierry Reding <thierry.reding@gmail.com>,
"Alexandre Courbot" <gnurou@gmail.com>,
Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>, <dmaengine@vger.kernel.org>,
<linux-tegra@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V3 0/2] Add support for Tegra210 ADMA
Date: Tue, 24 May 2016 12:19:54 +0100 [thread overview]
Message-ID: <574438DA.2080307@nvidia.com> (raw)
In-Reply-To: <20160524035329.GO2735@localhost>
Hi Paul,
On 24/05/16 04:53, Vinod Koul wrote:
> On Fri, May 20, 2016 at 02:51:14PM -0400, Paul Gortmaker wrote:
>> On Fri, Oct 16, 2015 at 3:35 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
>>> Add support for the Tegra210 Audio DMA (ADMA) controller. This was
>>> originally distributed as an RFC [0] based upon the existing tegra
>>> APB-DMA driver. Since then the driver has been significantly
>>> re-worked to remove a lot of the unused/unnecessary functionality
>>> that was carried over from the APB-DMA. This version is no longer
>>> derived from the APB-DMA driver and has been updated to use the
>>> virt-dma helpers.
>>
>> Does this driver make sense to support modular use? I ask because
>> it inherits the inconsistency of being a bool Kconfig but using some
>> modular infrastructure from the APB driver.
>>
>> Sometime ago when I sent patches to dma/* to "demodularize" other
>> bools, the general consensus of reviewers/maintainers was that
>> (to paraphrase) "if it can be modular, it should be modular" -- in
>> order to keep the multi platform bzImage size as small as can be.
>>
>> I did a quick test with it tristate, but that fails as follows:
>>
>> ERROR: "pm_clk_add_clk" [drivers/dma/tegra210-adma.ko] undefined!
>> ERROR: "pm_clk_create" [drivers/dma/tegra210-adma.ko] undefined!
>> ERROR: "pm_clk_destroy" [drivers/dma/tegra210-adma.ko] undefined!
>> ERROR: "pm_clk_suspend" [drivers/dma/tegra210-adma.ko] undefined!
>> ERROR: "pm_clk_resume" [drivers/dma/tegra210-adma.ko] undefined!
Thanks for reporting.
>> ...since drivers/base/power/clock_ops.c does not currently have any of
>> those fcns as EXPORT_SYMBOL. Not a show-stopper, but I don't
>> want to blindly export those fcns if it doesn't make sense.
>
> Sure, patch is welcome!
I don't have strong feeling either way. I think that long-term it would
be nice to add EXPORTS because I could see a lot of drivers starting to
use these. However, seeing that the ADMA is currently the only one it is
fine to demodularise the ADMA driver for now. Let me know if you want me
to send a patch or not.
Cheers
Jon
--
nvpublic
prev parent reply other threads:[~2016-05-24 11:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-16 7:35 [PATCH V3 0/2] Add support for Tegra210 ADMA Jon Hunter
2015-10-16 7:35 ` [PATCH V3 1/2] Documentation: DT: Add binding documentation for NVIDIA ADMA Jon Hunter
2015-10-16 16:09 ` Stephen Warren
2015-10-19 11:22 ` Jon Hunter
2015-10-19 16:33 ` Stephen Warren
2015-10-20 8:54 ` Jon Hunter
2015-10-16 7:35 ` [PATCH V3 2/2] dmaengine: tegra-adma: Add support for Tegra210 ADMA Jon Hunter
2015-10-27 2:10 ` Vinod Koul
2015-10-27 9:24 ` Jon Hunter
2015-10-28 13:17 ` Jon Hunter
2015-10-29 21:03 ` Andy Shevchenko
2015-11-02 16:22 ` Jon Hunter
2015-11-03 11:06 ` Jon Hunter
2016-05-20 18:51 ` [PATCH V3 0/2] " Paul Gortmaker
2016-05-24 3:53 ` Vinod Koul
2016-05-24 11:19 ` Jon Hunter [this message]
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=574438DA.2080307@nvidia.com \
--to=jonathanh@nvidia.com \
--cc=dmaengine@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=gnurou@gmail.com \
--cc=ijc+devicetree@hellion.org.uk \
--cc=ldewangan@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=paul.gortmaker@windriver.com \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
--cc=swarren@wwwdotorg.org \
--cc=thierry.reding@gmail.com \
--cc=vinod.koul@intel.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).