From: Kishon Vijay Abraham I <kishon@ti.com>
To: Tony Lindgren <tony@atomide.com>, Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-mmc@vger.kernel.org,
afenkart@gmail.com, ulf.hansson@linaro.org,
linux@armlinux.org.uk, rogerq@ti.com, bcousson@baylibre.com,
galak@codeaurora.org, ijc+devicetree@hellion.org.uk,
mark.rutland@arm.com, pawel.moll@arm.com, robh+dt@kernel.org,
nsekhar@ti.com
Subject: Re: [RFC PATCH 2/3] mmc: host: omap_hsmmc: Enable ADMA2
Date: Thu, 19 May 2016 11:44:16 +0530 [thread overview]
Message-ID: <573D59B8.7050701@ti.com> (raw)
In-Reply-To: <20160518193028.GT5995@atomide.com>
Hi Tony,
On Thursday 19 May 2016 01:00 AM, Tony Lindgren wrote:
> * Peter Ujfalusi <peter.ujfalusi@ti.com> [160518 03:26]:
>> On 05/18/16 11:45, Kishon Vijay Abraham I wrote:
>>> omap hsmmc host controller has ADMA2 feature. Enable it here
>>> for better read and write throughput. Add a new dt binding
>>> "ti,use_adma" to enable ADMA2.
>>>
>>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>>> ---
>>> .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 1 +
>>> drivers/mmc/host/omap_hsmmc.c | 320 ++++++++++++++++----
>>> include/linux/platform_data/hsmmc-omap.h | 1 +
>>> 3 files changed, 256 insertions(+), 66 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>>> index 74166a0..eb5ceec2 100644
>>> --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>>> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>>> @@ -28,6 +28,7 @@ specifier is required.
>>> dma-names: List of DMA request names. These strings correspond
>>> 1:1 with the DMA specifiers listed in dmas. The string naming is
>>> to be "rx" and "tx" for RX and TX DMA requests, respectively.
>>> +ti,use_adma: enable adma2 feature
>>
>> Do we have use case when you want to fall back to generic DMA instead of aDMA2?
>
> Yes my guess is that PM runtime breaks with these currently..
pm_runtime_get is invoked during omap_hsmmc_request and pm_runtime_put is
invoked during omap_hsmmc_request_done. Both these calls are outside DMA API's.
So it shouldn't break anything w.r.t PM runtime no?
>
>> IMHO if the driver supports aDMA2, it is going to use it instead of the
>> generic s/eDMA.
>> What I mean is:
>> the driver implements the aDMA2 support.
>> if the IP has support for aDMA2, then it is going to use it, otherwise it will
>> use the generic DMA.
>
> Ideally the adma support would be a separate loadable module,
> similar how the cppi41dma is a child of the OTG controller.
>
> That way the systems wanting to use adma can just specify it
> in the binding, and adma PM runtime support can be added later
> on.
>
> Of course this won't work if the adma registers are sprinkled
> within the MMC controller registers..
right, adma registers are within the MMC controller register space.
Thanks
Kishon
next prev parent reply other threads:[~2016-05-19 6:15 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-18 8:45 [RFC PATCH 0/3] dra7/omap4/omap5: Enable ADMA2 Kishon Vijay Abraham I
2016-05-18 8:45 ` [RFC PATCH 1/3] mmc: host: omap_hsmmc: remove *use_dma* member Kishon Vijay Abraham I
2016-05-18 8:45 ` [RFC PATCH 2/3] mmc: host: omap_hsmmc: Enable ADMA2 Kishon Vijay Abraham I
2016-05-18 10:24 ` Peter Ujfalusi
2016-05-18 19:30 ` Tony Lindgren
2016-05-19 6:14 ` Kishon Vijay Abraham I [this message]
2016-05-19 8:07 ` Peter Ujfalusi
2016-05-19 14:57 ` Tony Lindgren
2016-05-19 18:36 ` Felipe Balbi
2016-05-23 6:22 ` Kishon Vijay Abraham I
2016-05-23 7:18 ` Felipe Balbi
2016-05-23 8:00 ` Kishon Vijay Abraham I
2016-05-19 6:06 ` Kishon Vijay Abraham I
2016-05-19 8:02 ` Peter Ujfalusi
2016-05-18 11:07 ` Peter Ujfalusi
2016-05-19 8:25 ` Peter Ujfalusi
2016-05-18 8:45 ` [RFC PATCH 3/3] ARM: dts: dra7/omap4/omap5: " Kishon Vijay Abraham I
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=573D59B8.7050701@ti.com \
--to=kishon@ti.com \
--cc=afenkart@gmail.com \
--cc=bcousson@baylibre.com \
--cc=galak@codeaurora.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mark.rutland@arm.com \
--cc=nsekhar@ti.com \
--cc=pawel.moll@arm.com \
--cc=peter.ujfalusi@ti.com \
--cc=robh+dt@kernel.org \
--cc=rogerq@ti.com \
--cc=tony@atomide.com \
--cc=ulf.hansson@linaro.org \
/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).