On Wed, May 20, 2020 at 9:44 PM Bin Liu <b-liu@xxxxxx> wrote: > > Hi Adam, > > First of all for my curiosity, what motivates you to bring up the AM3517 > MUSB support up to date? > > Though I maintain the musb drivers, I don't know much about the devices > other than AM335x. But I spent a little time looked at the drivers and > the TRM, here is what I thought. > > Your query below seems showing that you are trying to bring up the CPPI41 > support for AM3517 MUSB, but have you got the glue driver working in PIO > mode yet? It seems to be quite amount of effort to get PIO mode working. > The glue driver am35x.c is there but it doesn't support device tree. The > dts am3517.dtsi defines the musb node with 'ti,omap3-musb' compatible, > which seems not right, at least internal phy vs external phy, comparing > with omap3 musb. am3517.dtsi also misses some required musb properties. > So I am not sure which glue driver should be used for AM3517 MUSB. > > I also looked the CPPI section in the TRM, yes, the scheduler register > base offset should be 0x2000, and the queue manager register base offset > should be 0x4000. But I think the CDMA controller register base should > be 0x1800, not 0x1000 as shown in Table 20-9. However the register > layout in these 3 segments are quite different from those on AM335x, so > it seems the CPPI41 dmaengine driver need some work as well to support > AM3517 CPPI. > Bin, Sorry to resurrect such an old thread, but I have the AM35xx MUSB driver working in PIO mode. I have made some attempts to get the CPPI DMA working, but if I enable the DMA it starts to crash. If I sent an RFC for the CPPI41 drivers, would you be willing to look them over? I have attempted to made adjustments for some of the segments that have a different layout from that of the da850 and the am33xx, and I think I am close, but I am obviously missing something, and I could use a little help. thanks, adam > -Bin. > > On Mon, May 18, 2020 at 05:19:32AM -0500, Adam Ford wrote: > > On Mon, May 18, 2020 at 12:35 AM Sekhar Nori <nsekhar@xxxxxx> wrote: > > > > > > + 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. > > > > Thanks for adding Bin. > > > > I can post of code patches as an RFC if interested. They don't work > > any better, but they don't work any worse either. > > > > I have modifications to the am35x glue to support cppi41, cppi41 to > > support am35, and updates to the device tree to point the musb > > controller to the am35 glue with additions for cppi41 references and > > some additional clocks. > > > > adam > > > > > > > > > > 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 > > > > > > >
