| Message ID | 20230112083746.9551-1-lukas.bulwahn@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Further code removal after Arnd's latest cleanup | expand |
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@gmail.com> 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: commit c32fd10914a314dd96c5d24030200070c84df5f1 Author: Arnd Bergmann <arnd@arndb.de> Date: Thu Sep 29 15:38:56 2022 +0200 ARM: omap1: remove unused board files All board support that was marked as 'unused' earlier can now be removed, leaving the five machines that that still had someone using them in 2022, or that are supported in qemu. Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Janusz Krzysztofik <jmkrzyszt@gmail.com> Cc: Tony Lindgren <tony@atomide.com> Cc: linux-omap@vger.kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig index b3006d8b04ab..95751062078e 100644 --- a/drivers/usb/gadget/udc/Kconfig +++ b/drivers/usb/gadget/udc/Kconfig @@ -118,7 +118,7 @@ config USB_GR_UDC config USB_OMAP tristate "OMAP USB Device Controller" depends on ARCH_OMAP1 - depends on ISP1301_OMAP || !(MACH_OMAP_H2 || MACH_OMAP_H3) + depends on ISP1301_OMAP help Many Texas Instruments OMAP processors have flexible full speed USB device controllers, with support for up to 30 diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 0442dc4bc334..a0c14c62ff32 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -409,7 +409,7 @@ if USB_OHCI_HCD config USB_OHCI_HCD_OMAP1 tristate "OHCI support for OMAP1/2 chips" depends on ARCH_OMAP1 - depends on ISP1301_OMAP || !(MACH_OMAP_H2 || MACH_OMAP_H3) + depends on ISP1301_OMAP default y help Enables support for the OHCI controller on OMAP1/2 chips. Instead of changing this to 'depends on ISP1301_OMAP', the line probably should just be dropped entirely. Arnd
On Thu, Jan 12, 2023 at 10:03 AM Arnd Bergmann <arnd@arndb.de> wrote: > > 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@gmail.com> > > 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: > > commit c32fd10914a314dd96c5d24030200070c84df5f1 > Author: Arnd Bergmann <arnd@arndb.de> > Date: Thu Sep 29 15:38:56 2022 +0200 > > ARM: omap1: remove unused board files > > All board support that was marked as 'unused' earlier can > now be removed, leaving the five machines that that still > had someone using them in 2022, or that are supported in > qemu. > > Cc: Aaro Koskinen <aaro.koskinen@iki.fi> > Cc: Janusz Krzysztofik <jmkrzyszt@gmail.com> > Cc: Tony Lindgren <tony@atomide.com> > Cc: linux-omap@vger.kernel.org > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > > diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig > index b3006d8b04ab..95751062078e 100644 > --- a/drivers/usb/gadget/udc/Kconfig > +++ b/drivers/usb/gadget/udc/Kconfig > @@ -118,7 +118,7 @@ config USB_GR_UDC > config USB_OMAP > tristate "OMAP USB Device Controller" > depends on ARCH_OMAP1 > - depends on ISP1301_OMAP || !(MACH_OMAP_H2 || MACH_OMAP_H3) > + depends on ISP1301_OMAP > help > Many Texas Instruments OMAP processors have flexible full > speed USB device controllers, with support for up to 30 > diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig > index 0442dc4bc334..a0c14c62ff32 100644 > --- a/drivers/usb/host/Kconfig > +++ b/drivers/usb/host/Kconfig > @@ -409,7 +409,7 @@ if USB_OHCI_HCD > config USB_OHCI_HCD_OMAP1 > tristate "OHCI support for OMAP1/2 chips" > depends on ARCH_OMAP1 > - depends on ISP1301_OMAP || !(MACH_OMAP_H2 || MACH_OMAP_H3) > + depends on ISP1301_OMAP > default y > help > Enables support for the OHCI controller on OMAP1/2 chips. > > Instead of changing this to 'depends on ISP1301_OMAP', the line > probably should just be dropped entirely. > I see. Yes, probably, !(MACH_OMAP_H2 || MACH_OMAP_H3) is really in the current state of the repository "always true", and hence this dependency "depends on ISP1301_OMAP || !(MACH_OMAP_H2 || MACH_OMAP_H3)" is always independent of ISP1301_OMAP. Are you going to fix up your commit "ARM: omap1: remove unused board files" with this change? Please ignore this patch then; patch 1 and 4 still seem good to pick, though. Lukas
* Arnd Bergmann <arnd@arndb.de> [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@gmail.com> > > 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. Regards, Tony
On Thu, Jan 12, 2023, at 10:19, Lukas Bulwahn wrote: > On Thu, Jan 12, 2023 at 10:03 AM Arnd Bergmann <arnd@arndb.de> wrote: > > I see. Yes, probably, !(MACH_OMAP_H2 || MACH_OMAP_H3) is really in the > current state of the repository "always true", and hence this > dependency "depends on ISP1301_OMAP || !(MACH_OMAP_H2 || > MACH_OMAP_H3)" is always independent of ISP1301_OMAP. > > Are you going to fix up your commit "ARM: omap1: remove unused board > files" with this change? > > Please ignore this patch then; patch 1 and 4 still seem good to pick, though. Done, I've applied those two and fixed up the other patch. Thanks a lot for your series! Arnd
On Thu, Jan 12, 2023, at 10:53, Tony Lindgren wrote: > * Arnd Bergmann <arnd@arndb.de> [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@gmail.com> >> >> 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
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@arndb.de> [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@gmail.com> > >> > >> 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.
On Thu, Jan 12, 2023, at 15:05, Aaro Koskinen wrote: > On Thu, Jan 12, 2023 at 11:19:53AM +0100, Arnd Bergmann wrote: >> On Thu, Jan 12, 2023, at 10:53, Tony Lindgren wrote: >> >> 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. Ok, if the performance is important, converting to dmaengine is probably best. Do you know if this is just a straightforward replacement of the function calls, or are there technical reasons why it's not using the dmaengine interface yet? Arnd
* Arnd Bergmann <arnd@arndb.de> [230112 14:31]: > On Thu, Jan 12, 2023, at 15:05, Aaro Koskinen wrote: > > On Thu, Jan 12, 2023 at 11:19:53AM +0100, Arnd Bergmann wrote: > >> On Thu, Jan 12, 2023, at 10:53, Tony Lindgren wrote: > >> > >> 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. > > Ok, if the performance is important, converting to dmaengine > is probably best. Do you know if this is just a straightforward > replacement of the function calls, or are there technical reasons > why it's not using the dmaengine interface yet? Yes I agree dmaengine is the best solution. Seems like this is the last driver using the old api that never got updated probably because it's not used on the newer SoCs. I don't think there are any technical reasons to not use dmaengine here. FYI, the last blocker for dmaengine use was for drivers using port_window that got added with the drivers/usb/musb/tusb6010_omap.c dmaengine conversion a few years back. Regards, Tony
Dear Arnd, you have shared some further clean-up activities in linux-next (see the specific commits mentioned in the patches for details). This allows us to clean up even more code in the repository. Please pick these patches on top of the commits mentioned in the corresponding patches (I assume that it is your soc-next tree?). Best regards, Lukas Lukas Bulwahn (4): ARM: s3c: remove obsolete s3c-cpu-freq header ARM: pxa: remove further dead code after pxa93 support removal usb: remove OMAP USB Device Controller and OHCI support for OMAP1/2 chips ARM: debug: remove references in DEBUG_UART_8250_SHIFT to removed configs arch/arm/Kconfig.debug | 3 +- arch/arm/mach-omap1/board-osk.c | 5 - arch/arm/mach-omap1/omap-dma.c | 455 ---- arch/arm/mach-omap1/usb.c | 67 - arch/arm/mach-omap1/usb.h | 4 - drivers/usb/gadget/udc/Kconfig | 15 - drivers/usb/gadget/udc/Makefile | 1 - drivers/usb/gadget/udc/omap_udc.c | 3001 ---------------------- drivers/usb/gadget/udc/omap_udc.h | 207 -- drivers/usb/host/Kconfig | 8 - drivers/usb/host/Makefile | 1 - drivers/usb/host/ohci-omap.c | 435 ---- include/linux/omap-dma.h | 28 - include/linux/soc/pxa/cpu.h | 47 - include/linux/soc/samsung/s3c-cpu-freq.h | 145 -- 15 files changed, 1 insertion(+), 4421 deletions(-) delete mode 100644 drivers/usb/gadget/udc/omap_udc.c delete mode 100644 drivers/usb/gadget/udc/omap_udc.h delete mode 100644 drivers/usb/host/ohci-omap.c delete mode 100644 include/linux/soc/samsung/s3c-cpu-freq.h