From: Sekhar Nori <nsekhar@ti.com>
To: Adam Ford <aford173@gmail.com>, Linux-OMAP <linux-omap@vger.kernel.org>
Cc: Tero Kristo <t-kristo@ti.com>, Tony Lindgren <tony@atomide.com>,
"Liu, Bin" <b-liu@ti.com>
Subject: Re: AM3517 MUSB and CPPI
Date: Mon, 18 May 2020 11:05:17 +0530 [thread overview]
Message-ID: <fedbed5e-8365-85ab-9b81-2ec25ffa64b4@ti.com> (raw)
In-Reply-To: <CAHCN7x+PAsFBhKyUUdbW2_diZ9PX=-Keb=UtXbkUVv1Mp1eujQ@mail.gmail.com>
+ Bin who maintains MUSB controller support
On 5/18/20 8:17 AM, Adam Ford wrote:
> From what I can tell, the MUSB controller on the AM3517 hasn't worked
> in a very long time.
>
> I have been going through the TRM for the AM3517, and I am convinced
> the device tree for the OTG port is wrong, but I am struggling to fix
> it.
>
> From what I can see the USB OTG Port support the CPPI 4.1 DMA
> controller, but the CPPI 4.1 only appears to support the
> DA850/OMAP-L138 and the AM335x family.
>
> It appears as if the AM35xx is a bit closer in behavior to the AM335x
> than the L138, but I was hoping either Tony, Tero or someone from TI
> might have a suggestion.
>
> The compatible flag need to be something like "compatible =
> "ti,am35xx-musb" and not omap3, because OMAP3 doesn't support the CPPI
> 4.1 DMA controller and the AM3517 does.
>
> Secondly, we need to update a couple of the tables in the cppi driver
> to support the am3517, and lastly, the device tree node needs to
> support the CPPI driver.
>
> It looks like the DA850/L138 makes the CPPI driver a sub-node of the
> OTG port, while the am335x has it as a separate node from the USB
> controller.
>
> From what I can tell on the AM3517, the CPPI DMA node should be a
> sub-node of the OTG.
>
> What I am struggling with now is the register offsets for controller,
> scheduler and queue manager.
> On both DA850 the 335x, there is an explicit table entry showing the
> offset of DMAREVID, which tells the DMA revision ID. I cannot find a
> corresponding register for the AM3517, yet the AM3517
>
> FWICT, the scheduler is offset 0x2000 with respect to the OTG
> controller, and the Queue Manager register is at 0ffset 0x4000, both
> with respect to the OTG base address. Unfortunately, I am not finding
> the offset for the CDMA controller itself.
>
> Can someone tell me what it should be? I am guessing it would be near
> the 0x1000 offset, but it's a pure guess.
>
> adam
>
next prev parent reply other threads:[~2020-05-18 5:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-18 2:47 AM3517 MUSB and CPPI Adam Ford
2020-05-18 5:35 ` Sekhar Nori [this message]
2020-05-18 10:19 ` Adam Ford
2020-05-19 15:42 ` Tony Lindgren
2020-05-21 2:44 ` Bin Liu
2020-05-22 10:16 ` Adam Ford
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=fedbed5e-8365-85ab-9b81-2ec25ffa64b4@ti.com \
--to=nsekhar@ti.com \
--cc=aford173@gmail.com \
--cc=b-liu@ti.com \
--cc=linux-omap@vger.kernel.org \
--cc=t-kristo@ti.com \
--cc=tony@atomide.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).