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.
Arnd
