RE: [PATCH] select NOP_USB_XCEIV for OMAP4
-Original Message- From: Gadiyar, Anand Sent: Wednesday, June 23, 2010 6:03 PM To: Koen Kooi; Kevin Hilman; Hunter, Jon Cc: Anders, David; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Gupta, Ajay Kumar; felipe.ba...@nokia.com Subject: RE: [PATCH] select NOP_USB_XCEIV for OMAP4 Koen Kooi wrote: Op 23 jun 2010, om 22:33 heeft Kevin Hilman het volgende geschreven: David Anders x0132...@ti.com writes: Add select statement to force selection of NOP_USB_XCEIV for OMAP4. Signed-off-by: David Anders x0132...@ti.com --- drivers/usb/musb/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index cfd38ed..e4624bc 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -11,6 +11,7 @@ config USB_MUSB_HDRC depends on (USB || USB_GADGET) depends on (ARM || (BF54x !BF544) || (BF52x !BF522 !BF523)) select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) +select NOP_USB_XCEIV if ARCH_OMAP4 select TWL4030_USB if MACH_OMAP_3430SDP select USB_OTG_UTILS tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' Shouldn't this be a board-specific option, and not set for every OMAP4-based config? If that's true, why do the davinci and blackfin archs force it? Kevin's right. For OMAP4 at least, this is something that is probably' best left up to the board to select. For the davinci's and blackfins, they don't have an option. They have a fully transparent internal PHY which doesn't need any configuring. However, with the OMAP4, you could potentially use an external ULPI transceiver. This can be another transparent PHY for which we could select the NOP_XCEIV. Or it could be something like the PHY in the TWL5030 which may need configuring over an I2C interface. - Anand Normally I would agree with you, however there are a number of items that I would like to iterate: 1. 100% of the currently known OMAP4 platforms use the NOP, wouldn't it be easier to add an exception if/when one exists rather than add each individual board that does require the NOP? 2. Including the NOP does not preclude the usage of another transceiver, simply don't register the NOP in your machine file. 3. The omap3_defconfig already has the NOP enabled. If we are pushing towards a unified defconfig for omap2/3/4, then the NOP will be enabled anyway. Linus is already pushing for more decisions to be made directly in the Kconfig and consoldation of defconfigs(and/or removal of them). 4. The NOP will need to be enabled if we intend to truly push for a Multi-Boot image that will boot multiple omap3 and omap4 platforms. For example if we have a kernel image that is intended to boot the 4430sdp, blaze, panda, and board-X(with an external transceiver), NOP is going to be included anyway. If the community in general is going to push for consolidated defconfigs, more robust decision making in Kconfig, and Multi-Boot support, then the way we thinking about what goes into Kconfig will have to change as well. Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] select NOP_USB_XCEIV for OMAP4
Anders, David wrote: -Original Message- From: Gadiyar, Anand Sent: Wednesday, June 23, 2010 6:03 PM To: Koen Kooi; Kevin Hilman; Hunter, Jon Cc: Anders, David; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Gupta, Ajay Kumar; felipe.ba...@nokia.com Subject: RE: [PATCH] select NOP_USB_XCEIV for OMAP4 Koen Kooi wrote: Op 23 jun 2010, om 22:33 heeft Kevin Hilman het volgende geschreven: David Anders x0132...@ti.com writes: Add select statement to force selection of NOP_USB_XCEIV for OMAP4. Signed-off-by: David Anders x0132...@ti.com --- drivers/usb/musb/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index cfd38ed..e4624bc 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -11,6 +11,7 @@ config USB_MUSB_HDRC depends on (USB || USB_GADGET) depends on (ARM || (BF54x !BF544) || (BF52x !BF522 !BF523)) select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) + select NOP_USB_XCEIV if ARCH_OMAP4 select TWL4030_USB if MACH_OMAP_3430SDP select USB_OTG_UTILS tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' Shouldn't this be a board-specific option, and not set for every OMAP4-based config? If that's true, why do the davinci and blackfin archs force it? Kevin's right. For OMAP4 at least, this is something that is probably' best left up to the board to select. For the davinci's and blackfins, they don't have an option. They have a fully transparent internal PHY which doesn't need any configuring. However, with the OMAP4, you could potentially use an external ULPI transceiver. This can be another transparent PHY for which we could select the NOP_XCEIV. Or it could be something like the PHY in the TWL5030 which may need configuring over an I2C interface. - Anand Normally I would agree with you, however there are a number of items that I would like to iterate: 1. 100% of the currently known OMAP4 platforms use the NOP, wouldn't it be easier to add an exception if/when one exists rather than add each individual board that does require the NOP? 2. Including the NOP does not preclude the usage of another transceiver, simply don't register the NOP in your machine file. 3. The omap3_defconfig already has the NOP enabled. If we are pushing towards a unified defconfig for omap2/3/4, then the NOP will be enabled anyway. Linus is already pushing for more decisions to be made directly in the Kconfig and consoldation of defconfigs(and/or removal of them). 4. The NOP will need to be enabled if we intend to truly push for a Multi-Boot image that will boot multiple omap3 and omap4 platforms. For example if we have a kernel image that is intended to boot the 4430sdp, blaze, panda, and board-X(with an external transceiver), NOP is going to be included anyway. If the community in general is going to push for consolidated defconfigs, more robust decision making in Kconfig, and Multi-Boot support, then the way we thinking about what goes into Kconfig will have to change as well. I see what you mean. Agree with all your points. Having the NOP_XCEIV selected doesn't prevent us from using an external PHY as long as the board file doesn't register a NOP_XCEIV. - Anand -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] select NOP_USB_XCEIV for OMAP4
-Original Message- From: Gadiyar, Anand Sent: Thursday, June 24, 2010 10:53 AM To: Anders, David; Koen Kooi; Kevin Hilman; Hunter, Jon Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Gupta, Ajay Kumar; felipe.ba...@nokia.com Subject: RE: [PATCH] select NOP_USB_XCEIV for OMAP4 Anders, David wrote: -Original Message- From: Gadiyar, Anand Sent: Wednesday, June 23, 2010 6:03 PM To: Koen Kooi; Kevin Hilman; Hunter, Jon Cc: Anders, David; linux-...@vger.kernel.org; linux- o...@vger.kernel.org; Gupta, Ajay Kumar; felipe.ba...@nokia.com Subject: RE: [PATCH] select NOP_USB_XCEIV for OMAP4 Koen Kooi wrote: Op 23 jun 2010, om 22:33 heeft Kevin Hilman het volgende geschreven: David Anders x0132...@ti.com writes: Add select statement to force selection of NOP_USB_XCEIV for OMAP4. Signed-off-by: David Anders x0132...@ti.com --- drivers/usb/musb/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index cfd38ed..e4624bc 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -11,6 +11,7 @@ config USB_MUSB_HDRC depends on (USB || USB_GADGET) depends on (ARM || (BF54x !BF544) || (BF52x !BF522 !BF523)) select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) +select NOP_USB_XCEIV if ARCH_OMAP4 select TWL4030_USB if MACH_OMAP_3430SDP select USB_OTG_UTILS tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' Shouldn't this be a board-specific option, and not set for every OMAP4-based config? If that's true, why do the davinci and blackfin archs force it? Kevin's right. For OMAP4 at least, this is something that is probably' best left up to the board to select. For the davinci's and blackfins, they don't have an option. They have a fully transparent internal PHY which doesn't need any configuring. However, with the OMAP4, you could potentially use an external ULPI transceiver. This can be another transparent PHY for which we could select the NOP_XCEIV. Or it could be something like the PHY in the TWL5030 which may need configuring over an I2C interface. - Anand Normally I would agree with you, however there are a number of items that I would like to iterate: 1. 100% of the currently known OMAP4 platforms use the NOP, wouldn't it be easier to add an exception if/when one exists rather than add each individual board that does require the NOP? 2. Including the NOP does not preclude the usage of another transceiver, simply don't register the NOP in your machine file. 3. The omap3_defconfig already has the NOP enabled. If we are pushing towards a unified defconfig for omap2/3/4, then the NOP will be enabled anyway. Linus is already pushing for more decisions to be made directly in the Kconfig and consoldation of defconfigs(and/or removal of them). 4. The NOP will need to be enabled if we intend to truly push for a Multi-Boot image that will boot multiple omap3 and omap4 platforms. For example if we have a kernel image that is intended to boot the 4430sdp, blaze, panda, and board-X(with an external transceiver), NOP is going to be included anyway. If the community in general is going to push for consolidated defconfigs, more robust decision making in Kconfig, and Multi-Boot support, then the way we thinking about what goes into Kconfig will have to change as well. I see what you mean. Agree with all your points. Having the NOP_XCEIV selected doesn't prevent us from using an external PHY as long as the board file doesn't register a NOP_XCEIV. - Anand If there are no other objects, can we get someone to signoff/ack on this? Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] select NOP_USB_XCEIV for OMAP4
Anders, David x0132...@ti.com writes: -Original Message- From: Gadiyar, Anand Sent: Wednesday, June 23, 2010 6:03 PM To: Koen Kooi; Kevin Hilman; Hunter, Jon Cc: Anders, David; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Gupta, Ajay Kumar; felipe.ba...@nokia.com Subject: RE: [PATCH] select NOP_USB_XCEIV for OMAP4 Koen Kooi wrote: Op 23 jun 2010, om 22:33 heeft Kevin Hilman het volgende geschreven: David Anders x0132...@ti.com writes: Add select statement to force selection of NOP_USB_XCEIV for OMAP4. Signed-off-by: David Anders x0132...@ti.com --- drivers/usb/musb/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index cfd38ed..e4624bc 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -11,6 +11,7 @@ config USB_MUSB_HDRC depends on (USB || USB_GADGET) depends on (ARM || (BF54x !BF544) || (BF52x !BF522 !BF523)) select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) + select NOP_USB_XCEIV if ARCH_OMAP4 select TWL4030_USB if MACH_OMAP_3430SDP select USB_OTG_UTILS tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' Shouldn't this be a board-specific option, and not set for every OMAP4-based config? If that's true, why do the davinci and blackfin archs force it? Kevin's right. For OMAP4 at least, this is something that is probably' best left up to the board to select. For the davinci's and blackfins, they don't have an option. They have a fully transparent internal PHY which doesn't need any configuring. However, with the OMAP4, you could potentially use an external ULPI transceiver. This can be another transparent PHY for which we could select the NOP_XCEIV. Or it could be something like the PHY in the TWL5030 which may need configuring over an I2C interface. - Anand Normally I would agree with you, however there are a number of items that I would like to iterate: 1. 100% of the currently known OMAP4 platforms use the NOP, wouldn't it be easier to add an exception if/when one exists rather than add each individual board that does require the NOP? Easier, yes. But easier isn't always the guiding principle for scalable, portable software. Personally, I would rather see these kinds of dependencies stated explicitly only where they are needed, and not stated in general rules with exceptons. 2. Including the NOP does not preclude the usage of another transceiver, simply don't register the NOP in your machine file. 3. The omap3_defconfig already has the NOP enabled. If we are pushing towards a unified defconfig for omap2/3/4, then the NOP will be enabled anyway. Linus is already pushing for more decisions to be made directly in the Kconfig and consoldation of defconfigs(and/or removal of them). 4. The NOP will need to be enabled if we intend to truly push for a Multi-Boot image that will boot multiple omap3 and omap4 platforms. For example if we have a kernel image that is intended to boot the 4430sdp, blaze, panda, and board-X(with an external transceiver), NOP is going to be included anyway. The other thing to keep in mind is on the opposite end of the spectrum from multi-boot kernels. Namely, minimal, tiny kernels targeted at specific platforms. By always enabling a feature that is not needed, there is unncessary code in your kernel image. I admit that for this particular feature, the code bloat is rather small. But the point is we don't want to enable features just because it's easier, when there are code bloat side effects. Even small amounts add up. If the community in general is going to push for consolidated defconfigs, more robust decision making in Kconfig, and Multi-Boot support, then the way we thinking about what goes into Kconfig will have to change as well. Agreed. But for this to scale, the dependencies must be stated specifically, not generally. In this case, the specific dependencies are on *boards*, not on the SoC. All that being said, I am not the maintainer of this area, so I'll leave it to Anand/Felipe/Ajay to make the call. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] select NOP_USB_XCEIV for OMAP4
Add select statement to force selection of NOP_USB_XCEIV for OMAP4. Signed-off-by: David Anders x0132...@ti.com --- drivers/usb/musb/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index cfd38ed..e4624bc 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -11,6 +11,7 @@ config USB_MUSB_HDRC depends on (USB || USB_GADGET) depends on (ARM || (BF54x !BF544) || (BF52x !BF522 !BF523)) select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) + select NOP_USB_XCEIV if ARCH_OMAP4 select TWL4030_USB if MACH_OMAP_3430SDP select USB_OTG_UTILS tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' -- 1.6.3.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] select NOP_USB_XCEIV for OMAP4
David Anders x0132...@ti.com writes: Add select statement to force selection of NOP_USB_XCEIV for OMAP4. Signed-off-by: David Anders x0132...@ti.com --- drivers/usb/musb/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index cfd38ed..e4624bc 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -11,6 +11,7 @@ config USB_MUSB_HDRC depends on (USB || USB_GADGET) depends on (ARM || (BF54x !BF544) || (BF52x !BF522 !BF523)) select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) + select NOP_USB_XCEIV if ARCH_OMAP4 select TWL4030_USB if MACH_OMAP_3430SDP select USB_OTG_UTILS tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' Shouldn't this be a board-specific option, and not set for every OMAP4-based config? Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] select NOP_USB_XCEIV for OMAP4
Op 23 jun 2010, om 22:33 heeft Kevin Hilman het volgende geschreven: David Anders x0132...@ti.com writes: Add select statement to force selection of NOP_USB_XCEIV for OMAP4. Signed-off-by: David Anders x0132...@ti.com --- drivers/usb/musb/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index cfd38ed..e4624bc 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -11,6 +11,7 @@ config USB_MUSB_HDRC depends on (USB || USB_GADGET) depends on (ARM || (BF54x !BF544) || (BF52x !BF522 !BF523)) select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) +select NOP_USB_XCEIV if ARCH_OMAP4 select TWL4030_USB if MACH_OMAP_3430SDP select USB_OTG_UTILS tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' Shouldn't this be a board-specific option, and not set for every OMAP4-based config? If that's true, why do the davinci and blackfin archs force it? regards, Koen -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] select NOP_USB_XCEIV for OMAP4
Hello. Koen Kooi wrote: Add select statement to force selection of NOP_USB_XCEIV for OMAP4. Signed-off-by: David Anders x0132...@ti.com --- drivers/usb/musb/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index cfd38ed..e4624bc 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -11,6 +11,7 @@ config USB_MUSB_HDRC depends on (USB || USB_GADGET) depends on (ARM || (BF54x !BF544) || (BF52x !BF522 !BF523)) select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) + select NOP_USB_XCEIV if ARCH_OMAP4 select TWL4030_USB if MACH_OMAP_3430SDP select USB_OTG_UTILS tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' Shouldn't this be a board-specific option, and not set for every OMAP4-based config? If that's true, why do the davinci and blackfin archs force it? DaVincis have an integrated transceiver. WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] select NOP_USB_XCEIV for OMAP4
On 6/23/2010 4:10 PM, Anders, David wrote: Shouldn't this be a board-specific option, and not set for every OMAP4-based config? As I understand it, any of the omap4 devices that are using the Inventra need to have at a minimum of the NOP USB Transceiver. Enabling the NOP transceiver doesn't preclude the use of other external transceivers. The NOP USB Transceiver will still need to be registered in the board-specific machine file therefore doesn't impact a board that doesn't use it. The OMAP4 TRM states: The high-speed USB OTG controller supports a single USB port, which uses the ULPI interface mode, to connect to an off-chip transceiver (12-pin/8-bit data SDR mode) and to connect on D+/D- (+ID) USB bus thanks to an embedded USB-HS OTG PHY. So I read this as you can use either the on-chip PHY or an external PHY. Therefore, if you did opt to use an external PHY I am not sure I understand why the NOP transceiver I still needed. The OMAP4 an external configuration looks the same as OMAP3 to me... Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] select NOP_USB_XCEIV for OMAP4
On 6/23/2010 4:12 PM, Koen Kooi wrote: Shouldn't this be a board-specific option, and not set for every OMAP4-based config? If that's true, why do the davinci and blackfin archs force it? DaVinci only has an internal PHY, I don't think that there is anyway to use an external PHY with DaVinci like you can with OMAP4. Not sure about blackfin... Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] select NOP_USB_XCEIV for OMAP4
Koen Kooi wrote: Op 23 jun 2010, om 22:33 heeft Kevin Hilman het volgende geschreven: David Anders x0132...@ti.com writes: Add select statement to force selection of NOP_USB_XCEIV for OMAP4. Signed-off-by: David Anders x0132...@ti.com --- drivers/usb/musb/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index cfd38ed..e4624bc 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -11,6 +11,7 @@ config USB_MUSB_HDRC depends on (USB || USB_GADGET) depends on (ARM || (BF54x !BF544) || (BF52x !BF522 !BF523)) select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) + select NOP_USB_XCEIV if ARCH_OMAP4 select TWL4030_USB if MACH_OMAP_3430SDP select USB_OTG_UTILS tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' Shouldn't this be a board-specific option, and not set for every OMAP4-based config? If that's true, why do the davinci and blackfin archs force it? Kevin's right. For OMAP4 at least, this is something that is probably' best left up to the board to select. For the davinci's and blackfins, they don't have an option. They have a fully transparent internal PHY which doesn't need any configuring. However, with the OMAP4, you could potentially use an external ULPI transceiver. This can be another transparent PHY for which we could select the NOP_XCEIV. Or it could be something like the PHY in the TWL5030 which may need configuring over an I2C interface. - Anand -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
