* AM3517 MUSB and CPPI @ 2020-05-18 2:47 Adam Ford 2020-05-18 5:35 ` Sekhar Nori 0 siblings, 1 reply; 6+ messages in thread From: Adam Ford @ 2020-05-18 2:47 UTC (permalink / raw) To: Linux-OMAP; +Cc: Tero Kristo, Tony Lindgren 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: AM3517 MUSB and CPPI 2020-05-18 2:47 AM3517 MUSB and CPPI Adam Ford @ 2020-05-18 5:35 ` Sekhar Nori 2020-05-18 10:19 ` Adam Ford 0 siblings, 1 reply; 6+ messages in thread From: Sekhar Nori @ 2020-05-18 5:35 UTC (permalink / raw) To: Adam Ford, Linux-OMAP; +Cc: Tero Kristo, Tony Lindgren, Liu, Bin + 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 > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: AM3517 MUSB and CPPI 2020-05-18 5:35 ` Sekhar Nori @ 2020-05-18 10:19 ` Adam Ford 2020-05-19 15:42 ` Tony Lindgren 2020-05-21 2:44 ` Bin Liu 0 siblings, 2 replies; 6+ messages in thread From: Adam Ford @ 2020-05-18 10:19 UTC (permalink / raw) To: Sekhar Nori; +Cc: Linux-OMAP, Tero Kristo, Tony Lindgren, Liu, Bin On Mon, May 18, 2020 at 12:35 AM Sekhar Nori <nsekhar@ti.com> 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 > > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: AM3517 MUSB and CPPI 2020-05-18 10:19 ` Adam Ford @ 2020-05-19 15:42 ` Tony Lindgren 2020-05-21 2:44 ` Bin Liu 1 sibling, 0 replies; 6+ messages in thread From: Tony Lindgren @ 2020-05-19 15:42 UTC (permalink / raw) To: Adam Ford; +Cc: Sekhar Nori, Linux-OMAP, Tero Kristo, Liu, Bin * Adam Ford <aford173@gmail.com> [200518 10:20]: > On Mon, May 18, 2020 at 12:35 AM Sekhar Nori <nsekhar@ti.com> 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. Sorry no idea about am3517 for musb. Sounds like it's similar to the am335x though. The USB PHY(s) is probably different though and maybe you need a separate drivers/phy driver. Maybe check the phy drivers we have for davinci/dm814x/dm816x, maybe it's similar to those if not the same as on am335x. Regards, Tony ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: AM3517 MUSB and CPPI 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 1 sibling, 1 reply; 6+ messages in thread From: Bin Liu @ 2020-05-21 2:44 UTC (permalink / raw) To: Adam Ford; +Cc: Sekhar Nori, Linux-OMAP, Tero Kristo, Tony Lindgren 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. 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@ti.com> 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 > > > > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: AM3517 MUSB and CPPI 2020-05-21 2:44 ` Bin Liu @ 2020-05-22 10:16 ` Adam Ford 0 siblings, 0 replies; 6+ messages in thread From: Adam Ford @ 2020-05-22 10:16 UTC (permalink / raw) To: Bin Liu, Adam Ford, Sekhar Nori, Linux-OMAP, Tero Kristo, Tony Lindgren On Wed, May 20, 2020 at 9:44 PM Bin Liu <b-liu@ti.com> wrote: > > Hi Adam, > > First of all for my curiosity, what motivates you to bring up the AM3517 > MUSB support up to date? I work for Logic PD, now called Beacon EmbeddedWorks, and we still get inquiries for that SOM. I've been trying to keep all the older SOM's up-to-date in my spare time. We have an L138/AM1808 SOM that seems like it's in decent shape, as well as an OMAP3530 and a DM3730 which all have most of their functionality. The last remaining SOM to need some fixing is the AM3517. > > 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. I do not have either PIO nor CPPI41 support working yet. I've been using the L138 and the am335x as references because the AM3517 seems very similar to both in some ways. It appears more similar to the am335x. > 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. I've been working on that too, and the glue for the am35x glue that was present before now probes when adding DT support and pointing the am3517 OTG node to it. > So I am not sure which glue driver should be used for AM3517 MUSB. There was an am35x glue driver already present, but it was incomplete. > > 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. That's what worries me. I am OK with using PIO instead of the DMA, but I wasn't sure which driver to use as an example to follow. If you have any suggestions or pointers, I'm fine with PIO. My main goal is to get the MUSB working again, and we can improve power or performance later. thanks > > -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@ti.com> 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 > > > > > > > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-05-22 10:16 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-05-18 2:47 AM3517 MUSB and CPPI Adam Ford 2020-05-18 5:35 ` Sekhar Nori 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
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).