Hi,
On Thu, Jan 12, 2023 at 11:19:53AM +0100, Arnd Bergmann wrote:
> On Thu, Jan 12, 2023, at 10:53, Tony Lindgren wrote:
> > * Arnd Bergmann <arnd@xxxxxxxx> [230112 09:03]:
> >> On Thu, Jan 12, 2023, at 09:37, Lukas Bulwahn wrote:
> >> > Commit 0fee2eac5c2b ("usb: phy: remove phy-isp1301-omap driver") removes
> >> > the Philips ISP1301 with OMAP OTG driver and its corresponding config
> >> > ISP1301_OMAP. The drivers, OMAP USB Device Controller and OHCI support for
> >> > OMAP1/2 chips, with corresponding configs, USB_OMAP and USB_OHCI_HCD_OMAP1,
> >> > need this removed driver (see "depends on ISP1301_OMAP") to build.
> >> >
> >> > Remove those two drivers.
> >> >
> >> > With the config USB_OMAP removed in this commit, remove some further code
> >> > in the omap-dma header and mach-omap1 architecture code.
> >> >
> >> > Signed-off-by: Lukas Bulwahn <lukas.bulwahn@xxxxxxxxx>
> >>
> >> This would be a great cleanup because of the simplications of the
> >> omap-dma code. I had previously looked at it and concluded that
> >> the driver is still in use though, and I think my mistake was
> >> just in the Kconfig part of this patch:
> >
> > It sure would be nice to drop the old custom dma api in omap-dma.c
> > while keeping the dma.c in arch/arm/mach-omap1.
>
> I see that four out of the five remaining board files still use
> omap_udc, which is the only remaining user of the custom
> DMA interface. What I had not noticed earlier is that DMA support
> in that driver is actually optional, though it's hardwired
> to be enabled.
>
> So if we want to kill off the old DMA stuff there is actually
> a choice between either making omap_udc PIO-only or converting
> it to use the standard dmaengine interface.
I use this driver on Palm TE and 770, and without it those boards would
be useless for my use cases. Also DMA doubles the throughput, probably
also power usage is smaller.
A.
