Re: [PATCH resend 1/3] AM35x: Add musb support
Hi, On Wed, Jul 07, 2010 at 04:16:04AM +0530, Gadiyar, Anand wrote: Like it is done in ehci-hcd.c/ohci-hcd.c? That's different, they export the platform_driver which gets probed by ehci-hcd.c, here we would have a parent platform_driver instianting correct dma device and musb device. This looks much easier to maintain. Do you already have a patch doing this, or would you like me to spin one for RFC/RFT? I started this yesterday before leaving the office, so not much done. If you beat me to it, go for it :-) -- balbi -- 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 resend 1/3] AM35x: Add musb support
Hi, If a Kconfig option is needed for optionally compiling in the support for am35x musb, it should be called USB_MUSB_AM35X or similar that gets selected if the boards using it are selected. Do you mean that we should have this option in drivers/usb/musb/Kconfig? Yeah, it could be set automatically with default y if MACH_AM35X_SOME_BOARD. Then options like this should not be mutually exclusive like they currently are for musb, that breaks using musb with multi omap. Choosing USB_MUSB_AM35X would anyways compile am35x.c and not omap2430.c File; thus musb would not work on OMAP3x boards with same binary. You should set up things so both can be compiled in, that's standard behaviour for all Linux drivers :) This is much easier said than done. Tony, As musb controllers are quite different between OMAPs and AM35x so it would be difficult in terms of software maintenance with such approach. Some of the major changes in AM35x are, - Has builtin USB PHY - It doesn't use Mentor DMA but uses CPPI4.1 DMA - Has set of wrapper register which are not present on OMAPs. - Doesn't have SYSCONFIG registers which are present on OMAPs. - Has bytewise read limitation which is not applicable to OMAPs. Musb on AM35x is actually quite similar to musb on DA8xx family of Devices. I can update the patches to use USB_MUSB_AM35X config within drivers/usb/musb/ but that would still not be able to compile in Both omapx and am35x stuff in single binary. Thanks, Ajay I will update the patches and submit for further reviews. Thanks, Tony 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 resend 1/3] AM35x: Add musb support
* Gupta, Ajay Kumar ajay.gu...@ti.com [100706 10:17]: As musb controllers are quite different between OMAPs and AM35x so it would be difficult in terms of software maintenance with such approach. Hmm, this is all pretty standard stuff.. Some of the major changes in AM35x are, - Has builtin USB PHY Register the PHY from platform data. - It doesn't use Mentor DMA but uses CPPI4.1 DMA Register DMA functions from platform data. - Has set of wrapper register which are not present on OMAPs. Yeah tusb6010 has the same problem, but that's already dealt with I believe. - Doesn't have SYSCONFIG registers which are present on OMAPs. - Has bytewise read limitation which is not applicable to OMAPs. Sounds like this has been mostly dealt with already with tusb6010. Musb on AM35x is actually quite similar to musb on DA8xx family of Devices. I can update the patches to use USB_MUSB_AM35X config within drivers/usb/musb/ but that would still not be able to compile in Both omapx and am35x stuff in single binary. Sounds like we should first fix thing before adding new code that will make fixing the basic issues harder. Tony -- 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 resend 1/3] AM35x: Add musb support
Hi,
On Tue, Jul 06, 2010 at 09:57:09AM +0200, ext Tony Lindgren wrote:
Sounds like we should first fix thing before adding new code
that will make fixing the basic issues harder.
my idea to deal with this is to have a set of platform glue drivers.
So omap2430.c, blackfin.c, tusb6010 and davinci.c would become a
platform driver themselves that would instantiate musb-hdrc
platform_driver and the correct dma driver (inventra, omap, cppi, etc).
It would look something like:
#include plat/usb.h
static struct musb_hdrc_ops omap2430_musb_ops = {
.readb = generic_readb,
.readw = generic_readw,
.readl = generic_readl,
.writeb = generic_writeb,
.writew = generic_writew,
.writel = generic_writel,
};
static struct musb_platform_data omap2430_musb_data = {
.ops= omap2430_musb_ops,
.mode = -EINVAL, /* change it later */
};
static int __init omap2430_musb_probe(struct platform_device *pdev)
{
struct omap24030_musb_platform_data pdata = pdev-dev.platform_data;
musb = platform_device_alloc(musb-hdrc, -1);
/* check error */
musb-dev.parent = pdev-dev;
omap2430_musb_data.mode = pdata-mode;
/* initialize every other necessary field */
platform_device_add_data(musb, omap2430_musb_data);
dma = platform_device_alloc(dma-inventra, -1);
/* check error */
dma-dev.parent = pdev-dev;
/* add both devices */
return 0;
}
static int omap2430_musb_suspend(struct platform_device *pdev,
pm_message_t state)
{
return omap2430_musb_save_context(pdev);
}
static int omap2430_musb_resume(stuct platform_device *pdev)
{
omap2430_musb_restore_context(pdev);
}
this would allow us to factor-out save/restore context, get rid of all
exported functions (by just adding every necessary function to
musb_hdrc_ops) and compile in every single musb file in one driver and
still have it working. Boards would, then, just instantiate
musb-omap2430/musb-blackfin/musb-tusb6010/musb-davinci
platform_driver(s) and the rest would be done on runtime, since only the
driver that matches would actually probe.
How does that sound ??
--
balbi
DefectiveByDesign.org
--
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 resend 1/3] AM35x: Add musb support
* Felipe Balbi felipe.ba...@nokia.com [100706 11:40]:
Hi,
On Tue, Jul 06, 2010 at 09:57:09AM +0200, ext Tony Lindgren wrote:
Sounds like we should first fix thing before adding new code
that will make fixing the basic issues harder.
my idea to deal with this is to have a set of platform glue
drivers. So omap2430.c, blackfin.c, tusb6010 and davinci.c would
become a platform driver themselves that would instantiate musb-hdrc
platform_driver and the correct dma driver (inventra, omap, cppi,
etc).
It would look something like:
#include plat/usb.h
static struct musb_hdrc_ops omap2430_musb_ops = {
.readb = generic_readb,
.readw = generic_readw,
.readl = generic_readl,
.writeb = generic_writeb,
.writew = generic_writew,
.writel = generic_writel,
};
static struct musb_platform_data omap2430_musb_data = {
.ops= omap2430_musb_ops,
.mode = -EINVAL, /* change it later */
};
static int __init omap2430_musb_probe(struct platform_device *pdev)
{
struct omap24030_musb_platform_data pdata = pdev-dev.platform_data;
musb = platform_device_alloc(musb-hdrc, -1);
/* check error */
musb-dev.parent = pdev-dev;
omap2430_musb_data.mode = pdata-mode;
/* initialize every other necessary field */
platform_device_add_data(musb, omap2430_musb_data);
dma = platform_device_alloc(dma-inventra, -1);
/* check error */
dma-dev.parent = pdev-dev;
/* add both devices */
return 0;
}
static int omap2430_musb_suspend(struct platform_device *pdev,
pm_message_t state)
{
return omap2430_musb_save_context(pdev);
}
static int omap2430_musb_resume(stuct platform_device *pdev)
{
omap2430_musb_restore_context(pdev);
}
this would allow us to factor-out save/restore context, get rid of
all exported functions (by just adding every necessary function to
musb_hdrc_ops) and compile in every single musb file in one driver
and still have it working. Boards would, then, just instantiate
musb-omap2430/musb-blackfin/musb-tusb6010/musb-davinci
platform_driver(s) and the rest would be done on runtime, since only
the driver that matches would actually probe.
How does that sound ??
That sounds good to me! It would be nice to have usable musb with
soon-to-be-gone omap3_defconfig :)
Tony
--
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 resend 1/3] AM35x: Add musb support
Felipe Balbi wrote:
On Tue, Jul 06, 2010 at 09:57:09AM +0200, ext Tony Lindgren wrote:
Sounds like we should first fix thing before adding new code
that will make fixing the basic issues harder.
my idea to deal with this is to have a set of platform glue drivers.
So omap2430.c, blackfin.c, tusb6010 and davinci.c would become a
platform driver themselves that would instantiate musb-hdrc
platform_driver and the correct dma driver (inventra, omap, cppi, etc).
It would look something like:
#include plat/usb.h
static struct musb_hdrc_ops omap2430_musb_ops = {
.readb = generic_readb,
.readw = generic_readw,
.readl = generic_readl,
.writeb = generic_writeb,
.writew = generic_writew,
.writel = generic_writel,
};
static struct musb_platform_data omap2430_musb_data = {
.ops= omap2430_musb_ops,
.mode = -EINVAL, /* change it later */
};
static int __init omap2430_musb_probe(struct platform_device *pdev)
{
struct omap24030_musb_platform_data pdata = pdev-dev.platform_data;
musb = platform_device_alloc(musb-hdrc, -1);
/* check error */
musb-dev.parent = pdev-dev;
omap2430_musb_data.mode = pdata-mode;
/* initialize every other necessary field */
platform_device_add_data(musb, omap2430_musb_data);
dma = platform_device_alloc(dma-inventra, -1);
/* check error */
dma-dev.parent = pdev-dev;
/* add both devices */
return 0;
}
static int omap2430_musb_suspend(struct platform_device *pdev,
pm_message_t state)
{
return omap2430_musb_save_context(pdev);
}
static int omap2430_musb_resume(stuct platform_device *pdev)
{
omap2430_musb_restore_context(pdev);
}
this would allow us to factor-out save/restore context, get rid of all
exported functions (by just adding every necessary function to
musb_hdrc_ops) and compile in every single musb file in one driver and
still have it working. Boards would, then, just instantiate
musb-omap2430/musb-blackfin/musb-tusb6010/musb-davinci
platform_driver(s) and the rest would be done on runtime, since only the
driver that matches would actually probe.
How does that sound ??
Like it is done in ehci-hcd.c/ohci-hcd.c?
This looks much easier to maintain.
Do you already have a patch doing this, or would you like me to spin one
for RFC/RFT?
- 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 resend 1/3] AM35x: Add musb support
* Ajay Kumar Gupta ajay.gu...@ti.com [100702 09:52]: AM35x has musb interface (version 1.8) and uses CPPI41 DMA engine. It has USB phy built inside the IP itself. Also added ARCH_AM35x which is required to differentiate musb ips between OMAP3x and AM35x. This config would be used for below purposes, - Select am35x.c instead of omap2430.c for compilation at drivers/usb/musb directory. Please note there are significant differneces in these two files as musb ip in quite different on AM35x. - Select workaround codes applicable for AM35x musb issues. one such workaround is for bytewise read issue on AM35x. snip diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index b31b6f1..52a6752 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -84,6 +84,7 @@ config MACH_OMAP3517EVM bool OMAP3517/ AM3517 EVM board depends on ARCH_OMAP3 select OMAP_PACKAGE_CBB + select ARCH_AM35x config MACH_OMAP3_PANDORA bool OMAP3 Pandora No thanks.. --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -5,6 +5,14 @@ menu TI OMAP Implementations config ARCH_OMAP_OTG bool +config ARCH_AM35x + bool + help + Select this option if your platform is based on AM35x. As + AM35x has an updated MUSB with CPPI4.1 DMA so this config + is introduced to differentiate musb ip between OMAP3x and + AM35x platforms. + choice prompt OMAP System Type default ARCH_OMAP2PLUS ..this should not be needed. Regards, Tony -- 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 resend 1/3] AM35x: Add musb support
Hello. Tony Lindgren wrote: AM35x has musb interface (version 1.8) and uses CPPI41 DMA engine. It has USB phy built inside the IP itself. Also added ARCH_AM35x which is required to differentiate musb ips between OMAP3x and AM35x. This config would be used for below purposes, - Select am35x.c instead of omap2430.c for compilation at drivers/usb/musb directory. Please note there are significant differneces in these two files as musb ip in quite different on AM35x. - Select workaround codes applicable for AM35x musb issues. one such workaround is for bytewise read issue on AM35x. snip diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index b31b6f1..52a6752 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -84,6 +84,7 @@ config MACH_OMAP3517EVM bool OMAP3517/ AM3517 EVM board depends on ARCH_OMAP3 select OMAP_PACKAGE_CBB + select ARCH_AM35x config MACH_OMAP3_PANDORA bool OMAP3 Pandora No thanks.. --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -5,6 +5,14 @@ menu TI OMAP Implementations config ARCH_OMAP_OTG bool +config ARCH_AM35x + bool + help + Select this option if your platform is based on AM35x. As + AM35x has an updated MUSB with CPPI4.1 DMA so this config + is introduced to differentiate musb ip between OMAP3x and + AM35x platforms. + choice prompt OMAP System Type default ARCH_OMAP2PLUS ..this should not be needed. I think Ajay has explained why it's needed. The option is necessary in one or another form. Regards, Tony 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 resend 1/3] AM35x: Add musb support
* Sergei Shtylyov sshtyl...@mvista.com [100705 12:57]: Hello. Tony Lindgren wrote: AM35x has musb interface (version 1.8) and uses CPPI41 DMA engine. It has USB phy built inside the IP itself. Also added ARCH_AM35x which is required to differentiate musb ips between OMAP3x and AM35x. This config would be used for below purposes, - Select am35x.c instead of omap2430.c for compilation at drivers/usb/musb directory. Please note there are significant differneces in these two files as musb ip in quite different on AM35x. - Select workaround codes applicable for AM35x musb issues. one such workaround is for bytewise read issue on AM35x. snip diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index b31b6f1..52a6752 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -84,6 +84,7 @@ config MACH_OMAP3517EVM bool OMAP3517/ AM3517 EVM board depends on ARCH_OMAP3 select OMAP_PACKAGE_CBB + select ARCH_AM35x config MACH_OMAP3_PANDORA bool OMAP3 Pandora No thanks.. --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -5,6 +5,14 @@ menu TI OMAP Implementations config ARCH_OMAP_OTG bool +config ARCH_AM35x + bool + help + Select this option if your platform is based on AM35x. As + AM35x has an updated MUSB with CPPI4.1 DMA so this config + is introduced to differentiate musb ip between OMAP3x and + AM35x platforms. + choice prompt OMAP System Type default ARCH_OMAP2PLUS ..this should not be needed. I think Ajay has explained why it's needed. The option is necessary in one or another form. It's not needed for omaps, we can already build in support for omap2, omap3 and omap4 into the same kernel binary. If a Kconfig option is needed for optionally compiling in the support for am35x musb, it should be called USB_MUSB_AM35X or similar that gets selected if the boards using it are selected. Regards, Tony -- 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 resend 1/3] AM35x: Add musb support
Hello. Tony Lindgren wrote: AM35x has musb interface (version 1.8) and uses CPPI41 DMA engine. It has USB phy built inside the IP itself. Also added ARCH_AM35x which is required to differentiate musb ips between OMAP3x and AM35x. This config would be used for below purposes, - Select am35x.c instead of omap2430.c for compilation at drivers/usb/musb directory. Please note there are significant differneces in these two files as musb ip in quite different on AM35x. - Select workaround codes applicable for AM35x musb issues. one such workaround is for bytewise read issue on AM35x. snip diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index b31b6f1..52a6752 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -84,6 +84,7 @@ config MACH_OMAP3517EVM bool OMAP3517/ AM3517 EVM board depends on ARCH_OMAP3 select OMAP_PACKAGE_CBB + select ARCH_AM35x config MACH_OMAP3_PANDORA bool OMAP3 Pandora No thanks.. --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -5,6 +5,14 @@ menu TI OMAP Implementations config ARCH_OMAP_OTG bool +config ARCH_AM35x + bool + help + Select this option if your platform is based on AM35x. As + AM35x has an updated MUSB with CPPI4.1 DMA so this config + is introduced to differentiate musb ip between OMAP3x and + AM35x platforms. + choice prompt OMAP System Type default ARCH_OMAP2PLUS ..this should not be needed. I think Ajay has explained why it's needed. The option is necessary in one or another form. It's not needed for omaps, we can already build in support for omap2, omap3 and omap4 into the same kernel binary. Not with AM35x USB support merged -- at least you won't be able to build single kernel with monolithic MUSB support. If a Kconfig option is needed for optionally compiling in the support for am35x musb, it should be called USB_MUSB_AM35X or similar that gets selected if the boards using it are selected. Do you mean that we should have this option in drivers/usb/musb/Kconfig? Regards, Tony 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 resend 1/3] AM35x: Add musb support
* Sergei Shtylyov sshtyl...@mvista.com [100705 13:29]: snip choice prompt OMAP System Type default ARCH_OMAP2PLUS ..this should not be needed. I think Ajay has explained why it's needed. The option is necessary in one or another form. It's not needed for omaps, we can already build in support for omap2, omap3 and omap4 into the same kernel binary. Not with AM35x USB support merged -- at least you won't be able to build single kernel with monolithic MUSB support. Right. I believe musb is pretty much the only remaining driver that won't behave with multi-omap. But let's not merge code that would make fixing that even harder. If a Kconfig option is needed for optionally compiling in the support for am35x musb, it should be called USB_MUSB_AM35X or similar that gets selected if the boards using it are selected. Do you mean that we should have this option in drivers/usb/musb/Kconfig? Yeah, it could be set automatically with default y if MACH_AM35X_SOME_BOARD. Then options like this should not be mutually exclusive like they currently are for musb, that breaks using musb with multi omap. Regards, Tony -- 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 resend 1/3] AM35x: Add musb support
I think Ajay has explained why it's needed. The option is necessary in one or another form. It's not needed for omaps, we can already build in support for omap2, omap3 and omap4 into the same kernel binary. Not with AM35x USB support merged -- at least you won't be able to build single kernel with monolithic MUSB support. Right. I believe musb is pretty much the only remaining driver that won't behave with multi-omap. But let's not merge code that would make fixing that even harder. If a Kconfig option is needed for optionally compiling in the support for am35x musb, it should be called USB_MUSB_AM35X or similar that gets selected if the boards using it are selected. Do you mean that we should have this option in drivers/usb/musb/Kconfig? Yeah, it could be set automatically with default y if MACH_AM35X_SOME_BOARD. Then options like this should not be mutually exclusive like they currently are for musb, that breaks using musb with multi omap. Choosing USB_MUSB_AM35X would anyways compile am35x.c and not omap2430.c File; thus musb would not work on OMAP3x boards with same binary. I will update the patches and submit for further reviews. Thanks, Ajay Regards, Tony -- 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 resend 1/3] AM35x: Add musb support
* Gupta, Ajay Kumar ajay.gu...@ti.com [100705 14:48]: I think Ajay has explained why it's needed. The option is necessary in one or another form. It's not needed for omaps, we can already build in support for omap2, omap3 and omap4 into the same kernel binary. Not with AM35x USB support merged -- at least you won't be able to build single kernel with monolithic MUSB support. Right. I believe musb is pretty much the only remaining driver that won't behave with multi-omap. But let's not merge code that would make fixing that even harder. If a Kconfig option is needed for optionally compiling in the support for am35x musb, it should be called USB_MUSB_AM35X or similar that gets selected if the boards using it are selected. Do you mean that we should have this option in drivers/usb/musb/Kconfig? Yeah, it could be set automatically with default y if MACH_AM35X_SOME_BOARD. Then options like this should not be mutually exclusive like they currently are for musb, that breaks using musb with multi omap. Choosing USB_MUSB_AM35X would anyways compile am35x.c and not omap2430.c File; thus musb would not work on OMAP3x boards with same binary. You should set up things so both can be compiled in, that's standard behaviour for all Linux drivers :) I will update the patches and submit for further reviews. Thanks, Tony -- 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 resend 1/3] AM35x: Add musb support
Hello. Tony Lindgren wrote: I think Ajay has explained why it's needed. The option is necessary in one or another form. It's not needed for omaps, we can already build in support for omap2, omap3 and omap4 into the same kernel binary. Don't see how it hinders that. Not with AM35x USB support merged -- at least you won't be able to build single kernel with monolithic MUSB support. Right. I believe musb is pretty much the only remaining driver that won't behave with multi-omap. But let's not merge code that would make fixing that even harder. I don't see how it's making fixing this harder... (though it's already hard). If a Kconfig option is needed for optionally compiling in the support for am35x musb, it should be called USB_MUSB_AM35X or similar that gets selected if the boards using it are selected. Do you mean that we should have this option in drivers/usb/musb/Kconfig? Yeah, it could be set automatically with default y if MACH_AM35X_SOME_BOARD. Then options like this should not be mutually exclusive like they currently are for musb, that breaks using musb with multi omap. Choosing USB_MUSB_AM35X would anyways compile am35x.c and not omap2430.c File; thus musb would not work on OMAP3x boards with same binary. You should set up things so both can be compiled in, that's standard behaviour for all Linux drivers :) This is much easier said than done. I will update the patches and submit for further reviews. Thanks, Tony 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
