linux_dsm_epyc7002/drivers/usb/phy/Kconfig

267 lines
8.1 KiB
Plaintext
Raw Normal View History

#
# Physical Layer USB driver configuration
#
menu "USB Physical Layer drivers"
config USB_PHY
def_bool n
config USB_OTG_FSM
bool "USB 2.0 OTG FSM implementation"
select USB_OTG
select USB_PHY
help
Implements OTG Final State Machine as specified in On-The-Go
and Embedded Host Supplement to the USB Revision 2.0 Specification.
#
# USB Transceiver Drivers
#
config AB8500_USB
tristate "AB8500 USB Transceiver Driver"
depends on AB8500_CORE
select USB_PHY
help
Enable this to support the USB OTG transceiver in AB8500 chip.
This transceiver supports high and full speed devices plus,
in host mode, low speed.
config FSL_USB2_OTG
bool "Freescale USB OTG Transceiver Driver"
depends on USB_EHCI_FSL && USB_FSL_USB2 && USB_OTG_FSM && PM_RUNTIME
select USB_OTG
select USB_PHY
help
Enable this to support Freescale USB OTG transceiver.
config ISP1301_OMAP
tristate "Philips ISP1301 with OMAP OTG"
depends on I2C && ARCH_OMAP_OTG
select USB_PHY
help
If you say yes here you get support for the Philips ISP1301
USB-On-The-Go transceiver working with the OMAP OTG controller.
The ISP1301 is a full speed USB transceiver which is used in
products including H2, H3, and H4 development boards for Texas
Instruments OMAP processors.
This driver can also be built as a module. If so, the module
will be called isp1301_omap.
config KEYSTONE_USB_PHY
tristate "Keystone USB PHY Driver"
depends on ARCH_KEYSTONE || COMPILE_TEST
select NOP_USB_XCEIV
help
Enable this to support Keystone USB phy. This driver provides
interface to interact with USB 2.0 and USB 3.0 PHY that is part
of the Keystone SOC.
config MV_U3D_PHY
bool "Marvell USB 3.0 PHY controller Driver"
depends on CPU_MMP3
select USB_PHY
help
Enable this to support Marvell USB 3.0 phy controller for Marvell
SoC.
config NOP_USB_XCEIV
tristate "NOP USB Transceiver Driver"
select USB_PHY
help
This driver is to be used by all the usb transceiver which are either
built-in with usb ip or which are autonomous and doesn't require any
phy programming such as ISP1x04 etc.
config OMAP_CONTROL_USB
tristate "OMAP CONTROL USB Driver"
usb: limit OMAP related USB options to OMAP2PLUS platforms commit 57f6ce072e35770a63be0c5d5e82f90d8da7d665 ("usb: phy: add a new driver for usb3 phy") added the new Kconfig option OMAP_USB3, but it had no dependencies whatsoever, and hence became available across all arch/platforms. Which presumably caused this to show up in x86 randconfig: warning: (USB_MUSB_HDRC && OMAP_USB3) selects \ OMAP_CONTROL_USB which has unmet direct \ dependencies (USB_SUPPORT && ARCH_OMAP2PLUS) Then commit 6992819feb39cb9adac72170555d957d07f869f2 ("usb: phy: fix Kconfig warning") was added. However, this just deleted the ARCH_OMAP2PLUS dependency from OMAP_CONTROL_USB, further compounding the problem by opening up OMAP_CONTROL_USB to all arch/platforms as well. Earlier it was suggested[1] that we revert the change of 6992819feb to restore the dependency, and add a same ARCH_OMAP2PLUS dependency to the new OMAP_USB3 entry. However that was discouraged on the grounds of people wanting the extra sanity compile testing on x86, even though the driver could probably never be used there. Now we have CONFIG_COMPILE_TEST, so developers who value the ability to compile drivers on an architecture that it never can be used for can have that, and people who want dependencies to shield them from seeing options that aren't relevant to their platform get what they want too. Here we restore the dependency but couple it with COMPILE_TEST, in order to achieve both of the above goals. [1] https://patchwork.kernel.org/patch/2194511/ Acked-by: Felipe Balbi <balbi@ti.com> Cc: Kishon Vijay Abraham I <kishon@ti.com> Cc: Moiz Sonasath <m-sonasath@ti.com> Cc: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-04 12:39:10 +07:00
depends on ARCH_OMAP2PLUS || COMPILE_TEST
help
Enable this to add support for the USB part present in the control
module. This driver has API to power on the USB2 PHY and to write to
the mailbox. The mailbox is present only in omap4 and the register to
power on the USB2 PHY is present in OMAP4 and OMAP5. OMAP5 has an
additional register to power on USB3 PHY.
config OMAP_USB3
tristate "OMAP USB3 PHY Driver"
usb: limit OMAP related USB options to OMAP2PLUS platforms commit 57f6ce072e35770a63be0c5d5e82f90d8da7d665 ("usb: phy: add a new driver for usb3 phy") added the new Kconfig option OMAP_USB3, but it had no dependencies whatsoever, and hence became available across all arch/platforms. Which presumably caused this to show up in x86 randconfig: warning: (USB_MUSB_HDRC && OMAP_USB3) selects \ OMAP_CONTROL_USB which has unmet direct \ dependencies (USB_SUPPORT && ARCH_OMAP2PLUS) Then commit 6992819feb39cb9adac72170555d957d07f869f2 ("usb: phy: fix Kconfig warning") was added. However, this just deleted the ARCH_OMAP2PLUS dependency from OMAP_CONTROL_USB, further compounding the problem by opening up OMAP_CONTROL_USB to all arch/platforms as well. Earlier it was suggested[1] that we revert the change of 6992819feb to restore the dependency, and add a same ARCH_OMAP2PLUS dependency to the new OMAP_USB3 entry. However that was discouraged on the grounds of people wanting the extra sanity compile testing on x86, even though the driver could probably never be used there. Now we have CONFIG_COMPILE_TEST, so developers who value the ability to compile drivers on an architecture that it never can be used for can have that, and people who want dependencies to shield them from seeing options that aren't relevant to their platform get what they want too. Here we restore the dependency but couple it with COMPILE_TEST, in order to achieve both of the above goals. [1] https://patchwork.kernel.org/patch/2194511/ Acked-by: Felipe Balbi <balbi@ti.com> Cc: Kishon Vijay Abraham I <kishon@ti.com> Cc: Moiz Sonasath <m-sonasath@ti.com> Cc: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-04 12:39:10 +07:00
depends on ARCH_OMAP2PLUS || COMPILE_TEST
select OMAP_CONTROL_USB
select USB_PHY
help
Enable this to support the USB3 PHY that is part of SOC. This
driver takes care of all the PHY functionality apart from comparator.
This driver interacts with the "OMAP Control USB Driver" to power
on/off the PHY.
config AM335X_CONTROL_USB
tristate
config AM335X_PHY_USB
tristate "AM335x USB PHY Driver"
depends on ARM || COMPILE_TEST
select USB_PHY
select AM335X_CONTROL_USB
select NOP_USB_XCEIV
help
This driver provides PHY support for that phy which part for the
AM335x SoC.
config SAMSUNG_USBPHY
tristate
help
Enable this to support Samsung USB phy helper driver for Samsung SoCs.
This driver provides common interface to interact, for Samsung USB 2.0 PHY
driver and later for Samsung USB 3.0 PHY driver.
config SAMSUNG_USB2PHY
tristate "Samsung USB 2.0 PHY controller Driver"
select SAMSUNG_USBPHY
select USB_PHY
help
Enable this to support Samsung USB 2.0 (High Speed) PHY controller
driver for Samsung SoCs.
config SAMSUNG_USB3PHY
tristate "Samsung USB 3.0 PHY controller Driver"
select SAMSUNG_USBPHY
select USB_PHY
help
Enable this to support Samsung USB 3.0 (Super Speed) phy controller
for samsung SoCs.
config TWL6030_USB
tristate "TWL6030 USB Transceiver Driver"
depends on TWL4030_CORE && OMAP_USB2 && USB_MUSB_OMAP2PLUS
help
Enable this to support the USB OTG transceiver on TWL6030
family chips. This TWL6030 transceiver has the VBUS and ID GND
and OTG SRP events capabilities. For all other transceiver functionality
UTMI PHY is embedded in OMAP4430. The internal PHY configurations APIs
are hooked to this driver through platform_data structure.
The definition of internal PHY APIs are in the mach-omap2 layer.
config USB_GPIO_VBUS
tristate "GPIO based peripheral-only VBUS sensing 'transceiver'"
Removal of GENERIC_GPIO for v3.10 GENERIC_GPIO now synonymous with GPIOLIB. There are no longer any valid cases for enableing GENERIC_GPIO without GPIOLIB, even though it is possible to do so which has been causing confusion and breakage. This branch does the work to completely eliminate GENERIC_GPIO. However, it is not trivial to just create a branch to remove it. Over the course of the v3.9 cycle more code referencing GENERIC_GPIO has been added to linux-next that conflicts with this branch. The following must be done to resolve the conflicts when merging this branch into mainline: * "git grep CONFIG_GENERIC_GPIO" should return 0 hits. Matches should be replaced with CONFIG_GPIOLIB * "git grep '\bGENERIC_GPIO\b'" should return 1 hit in the Chinese documentation. * Selectors of GENERIC_GPIO should be turned into selectors of GPIOLIB * definitions of the option in architecture Kconfig code should be deleted. Stephen has 3 merge fixup patches[1] that do the above. They are currently applicable on mainline as of May 2nd. [1] http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg428056.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAABAgAGBQJRifUnAAoJEEFnBt12D9kBs2YP/0U6+ia+xYvkVaJc28PDVIzn OReZNcJOYU8D5voxz0voaRD0EdcPwjbMu9Kp9aXMHlk4VxevF+8jCc/us0bIjtO1 VcB5VmSCIhMhxdnBlum11Mk7Vr5MCweyl9NBsypnPt8cl4obMBZHf2yzoodFktNb wtyYlOb6FALtc6iDbOO6dG3w9F7FAOLvskUFzdv89m8mupTsBu9jw9NqFDbJHOex rxq0Sdd+kWF/nkJVcV5Y6jIdletRlhpipefMJ9diexreHvwqh+c4kJEYZaXgB5+m ha95cPbReK1d+RqzM3A8d4irzSVSmq4k7ijI6QkFOr48+AH7XsgKv5so885LKzMN IIXg2Phm9i0H8+ecEvhcc4oIYBHJiEKK54Y0qUD9dqbFoDGPTCSqMHdSSMbpAY+J bIIXlVzj1En3PPNUJLPt8q8Qz6WxCT9mDST3QSGYnD4o90HT+1R9j92RxGL6McOq rUOyJDwmzFvpBvKK4raGdOU435M+ps2NPKKNIRaIGQPPY9rM1kN4YqvhXukEsC9L 3a3+3cQLh7iKxBHncxeQsJfethP1CPkJnzvF9r+ZZLf2rcPH4pbQIE2uO0XnX/nd 5/DKi0nGgAJ//GMMzdo3RiOA5zGFjIZ/KMvfhQldpP6qFJRhqdGi6FPlAcwr1z1n YnCByPwwlvfC4LTXFOGL =xodc -----END PGP SIGNATURE----- Merge tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux Pull removal of GENERIC_GPIO from Grant Likely: "GENERIC_GPIO now synonymous with GPIOLIB. There are no longer any valid cases for enableing GENERIC_GPIO without GPIOLIB, even though it is possible to do so which has been causing confusion and breakage. This branch does the work to completely eliminate GENERIC_GPIO." * tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux: gpio: update gpio Chinese documentation Remove GENERIC_GPIO config option Convert selectors of GENERIC_GPIO to GPIOLIB blackfin: force use of gpiolib m68k: coldfire: use gpiolib mips: pnx833x: remove requirement for GENERIC_GPIO openrisc: default GENERIC_GPIO to false avr32: default GENERIC_GPIO to false xtensa: remove explicit selection of GENERIC_GPIO sh: replace CONFIG_GENERIC_GPIO by CONFIG_GPIOLIB powerpc: remove redundant GENERIC_GPIO selection unicore32: default GENERIC_GPIO to false unicore32: remove unneeded select GENERIC_GPIO arm: plat-orion: use GPIO driver on CONFIG_GPIOLIB arm: remove redundant GENERIC_GPIO selection mips: alchemy: require gpiolib mips: txx9: change GENERIC_GPIO to GPIOLIB mips: loongson: use GPIO driver on CONFIG_GPIOLIB mips: remove redundant GENERIC_GPIO select
2013-05-09 23:59:16 +07:00
depends on GPIOLIB
select USB_PHY
help
Provides simple GPIO VBUS sensing for controllers with an
internal transceiver via the usb_phy interface, and
optionally control of a D+ pullup GPIO as well as a VBUS
current limit regulator.
config OMAP_OTG
tristate "OMAP USB OTG controller driver"
depends on ARCH_OMAP_OTG && EXTCON
help
Enable this to support some transceivers on OMAP1 platforms. OTG
controller is needed to switch between host and peripheral modes.
This driver can also be built as a module. If so, the module
will be called omap-otg.
config TAHVO_USB
tristate "Tahvo USB transceiver driver"
depends on MFD_RETU && EXTCON
select USB_PHY
help
Enable this to support USB transceiver on Tahvo. This is used
at least on Nokia 770.
config TAHVO_USB_HOST_BY_DEFAULT
depends on TAHVO_USB
boolean "Device in USB host mode by default"
help
Say Y here, if you want the device to enter USB host mode
by default on bootup.
config USB_ISP1301
tristate "NXP ISP1301 USB transceiver support"
depends on USB || USB_GADGET
depends on I2C
select USB_PHY
help
Say Y here to add support for the NXP ISP1301 USB transceiver driver.
This chip is typically used as USB transceiver for USB host, gadget
and OTG drivers (to be selected separately).
To compile this driver as a module, choose M here: the
module will be called isp1301.
config USB_MSM_OTG
tristate "OTG support for Qualcomm on-chip USB controller"
depends on (USB || USB_GADGET) && ARCH_MSM
select USB_PHY
help
Enable this to support the USB OTG transceiver on MSM chips. It
handles PHY initialization, clock management, and workarounds
required after resetting the hardware and power management.
This driver is required even for peripheral only or host only
mode configurations.
This driver is not supported on boards like trout which
has an external PHY.
config USB_MV_OTG
tristate "Marvell USB OTG support"
depends on USB_EHCI_MV && USB_MV_UDC && PM_RUNTIME
select USB_OTG
select USB_PHY
help
Say Y here if you want to build Marvell USB OTG transciever
driver in kernel (including PXA and MMP series). This driver
implements role switch between EHCI host driver and gadget driver.
To compile this driver as a module, choose M here.
config USB_MXS_PHY
tristate "Freescale MXS USB PHY support"
depends on ARCH_MXC || ARCH_MXS
select STMP_DEVICE
select USB_PHY
help
Enable this to support the Freescale MXS USB PHY.
MXS Phy is used by some of the i.MX SoCs, for example imx23/28/6x.
config USB_RCAR_PHY
tristate "Renesas R-Car USB PHY support"
depends on USB || USB_GADGET
select USB_PHY
help
Say Y here to add support for the Renesas R-Car USB common PHY driver.
This chip is typically used as USB PHY for USB host, gadget.
This driver supports R8A7778 and R8A7779.
To compile this driver as a module, choose M here: the
module will be called phy-rcar-usb.
config USB_RCAR_GEN2_PHY
tristate "Renesas R-Car Gen2 USB PHY support"
depends on ARCH_R8A7790 || ARCH_R8A7791 || COMPILE_TEST
select USB_PHY
help
Say Y here to add support for the Renesas R-Car Gen2 USB PHY driver.
It is typically used to control internal USB PHY for USBHS,
and to configure shared USB channels 0 and 2.
This driver supports R8A7790 and R8A7791.
To compile this driver as a module, choose M here: the
module will be called phy-rcar-gen2-usb.
config USB_ULPI
bool "Generic ULPI Transceiver Driver"
depends on ARM
help
Enable this to support ULPI connected USB OTG transceivers which
are likely found on embedded boards.
config USB_ULPI_VIEWPORT
bool
depends on USB_ULPI
help
Provides read/write operations to the ULPI phy register set for
controllers with a viewport register (e.g. Chipidea/ARC controllers).
endmenu