From: peter.ujfalusi@ti.com (Peter Ujfalusi)
To: linux-arm-kernel@lists.infradead.org
Subject: EDMA oftree entry for AM335x
Date: Tue, 5 May 2015 16:53:24 +0300 [thread overview]
Message-ID: <5548CB54.1040302@ti.com> (raw)
In-Reply-To: <20150504141103.GD24469@atomide.com>
On 05/04/2015 05:11 PM, Tony Lindgren wrote:
> Hi,
>
> Adding Peter to Cc as well.
>
> * Robert Schwebel <r.schwebel@pengutronix.de> [150503 23:44]:
>> Hi,
>>
>> since 5e863c561, I get this warning for an AM335x board:
>>
>> omap_hwmod: tptc0 using broken dt data from edma
>> omap_hwmod: tptc1 using broken dt data from edma
>> omap_hwmod: tptc2 using broken dt data from edma
>>
>> It seems like the code in arch/arm/mach-omap2/omap_hwmod.c expects the oftree
>> entry to look differently than what we currently have in
>> arch/arm/boot/dts/am33xx.dtsi:
>>
>> edma: edma at 49000000 {
>> compatible = "ti,edma3";
>> ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2"; <==========
>> reg = <0x49000000 0x10000>,
>> <0x44e10f90 0x40>;
>> interrupts = <12 13 14>;
>> #dma-cells = <1>;
>> };
>>
>> The patch description says the device should be split into more devices instead
>> of specifying several ti,hwmods entries, but unfortunately the Documentation
>> still suggests the above format in Documentation/devicetree/bindings/dma/ti-edma.txt.
>>
>> How would a correct entry look like?
>
> Each tptc instance has it's own sysconfig register. This means each
> one of them can be clocked and idled independently. They should be
> treated as separate device instances. I believe the interrupts all
> belong to the tpcc, which should be also treated as a separate
> device instance.
>
> In order to get rid of the ti,hwmods property, we want to have a
> 1-1-1 mapping of the compatible property, ti,hwmod property, and
> the device entry.
>
> Looking at the TRM "Table 2-1. L3 Memory Map", these all are on
> the L3, so they should be like this for now (assuming the
> interrupts all belong to tpcc):
>
> ocp {
> ...
>
> edma: tpcc at 49000000 {
> compatible = "ti,edma3";
> ti,hwmods = "tpcc";
> reg = <0x49000000 0x10000>;
> interrupts = <12 13 14>;
> #dma-cells = <1>;
> };
>
> tptc0: tptc at 49800000 {
> compatible = "ti,tptc3";
> ti,hwmods = "tptc0";
> reg = <0x49800000 0x10000>;
> };
>
> tptc1: tptc at 49900000 {
> compatible = "ti,tptc3";
> ti,hwmods = "tptc1";
> reg = <0x49900000 0x10000>;
> };
>
> tptc2: tptc at 49a00000 {
> compatible = "ti,tptc3";
> ti,hwmods = "tptc2";
> reg = <0x49a00000 0x10000>;
> };
> ...
> };
It is not that simple ;)
eDMA consists of Channel Controller(s) and Transfer Controllers. In AM335x we
have 1 CC and 3 TC. TC is mostly a box for us, we do not need to configure
anything within so the eDMA driver stack just does that: do not touch anything
TC related in TC address space, we only deal with the CC.
But in order to be able to move data around we need both CC and the TCs
enabled and this is why we have the multiple hwmod. with pm_runtime we manage
both CC and TCs at the same time.
But from the SW point of view the TC does not really exists. As I said we only
touch CC registers, paRAM entries.
And yes, both TC and CCs can generate interrupts.
So it is not straight forward to separate the TC from the CC driver (edma3).
>
> Then eventually we can deprecate the ti,hwmods property and just
> leave it out.
>
> Changing thing this way means each tptc instance should register
> itself separately with tpcc when probed. Other than that, I think
> that's pretty much the only changes needed here to fix up things.
>
> Regards,
>
> Tony
>
--
P?ter
next prev parent reply other threads:[~2015-05-05 13:53 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-04 6:43 EDMA oftree entry for AM335x Robert Schwebel
2015-05-04 14:11 ` Tony Lindgren
2015-05-04 21:11 ` Robert Schwebel
2015-05-04 21:24 ` Tony Lindgren
2015-05-04 21:33 ` Robert Schwebel
2015-05-04 21:42 ` Tony Lindgren
2015-05-05 13:53 ` Peter Ujfalusi [this message]
2015-05-05 14:58 ` Tony Lindgren
2015-05-06 11:22 ` Peter Ujfalusi
2015-05-06 14:39 ` Tony Lindgren
2015-06-08 10:59 ` Robert Schwebel
2015-06-10 5:10 ` Tony Lindgren
2015-06-10 11:13 ` Peter Ujfalusi
2015-06-11 14:13 ` Tony Lindgren
2015-06-11 14:53 ` Peter Ujfalusi
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=5548CB54.1040302@ti.com \
--to=peter.ujfalusi@ti.com \
--cc=linux-arm-kernel@lists.infradead.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).