Patches for next merge window
Subsystems (5)
cover Patches for next merge window
Hi Tony,
here are the patches for next merge window which I have queued for you. A pull request is comming tomorrow.
All patches where boot tested on omap4430 pandaboard.
Anand Gadiyar (2):
arm: omap4: usb: explicitly configure MUSB pads
arm: omap4: 4430sdp: drop ehci support
Hema HK (5):
OMAP2430: hwmod data: Add USBOTG
OMAP3xxx: hwmod data: Add USBOTG
AM35xx: hwmod data: Add USBOTG
OMAP4430: hwmod data: Adding USBOTG
OMAP2+: musb: hwmod adaptation for musb registration
arch/arm/mach-omap2/board-4430sdp.c | 19 --- arch/arm/mach-omap2/omap_hwmod_2430_data.c | 98 ++++++++++++++++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 166 ++++++++++++++++++++++++++++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 93 ++++++++++++++++ arch/arm/mach-omap2/usb-musb.c | 122 ++++++++++++++------- 5 files changed, 440 insertions(+), 58 deletions(-)
Signature · 1 line
1.7.4.rc2
PATCH 1/7 arm: omap4: usb: explicitly configure MUSB pads
From: Anand Gadiyar <[email protected]>
Use the mux framework APIs to explicitly configure the MUSB pads. The MUSB controller in OMAP4 can use either the old ULPI interface, or the new internal PHY. Configure the pads accordingly.
--- arch/arm/mach-omap2/usb-musb.c | 40 ++++++++++++++++++++++++++++++++++++++++ 1 files changed, 40 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/usb-musb.c +40 -0
@@ -31,6 +31,7 @@#include <mach/am35xx.h> #include <plat/usb.h> #include "control.h" +#include "mux.h" #if defined(CONFIG_USB_MUSB_OMAP2PLUS ) || defined (CONFIG_USB_MUSB_AM35X )
@@ -181,6 +182,43 @@ static struct platform_device musb_device = { .resource = musb_resources, }; +static void usb_musb_mux_init (struct omap_musb_board_data *board_data) +{ +switch (board_data->interface_type) { +case MUSB_INTERFACE_UTMI : +omap_mux_init_signal ("usba0_otg_dp" ,OMAP_PIN_INPUT ); +omap_mux_init_signal ("usba0_otg_dm" ,OMAP_PIN_INPUT ); +break ; +case MUSB_INTERFACE_ULPI : +omap_mux_init_signal ("usba0_ulpiphy_clk" , +OMAP_PIN_INPUT_PULLDOWN ); +omap_mux_init_signal ("usba0_ulpiphy_stp" , +OMAP_PIN_INPUT_PULLDOWN ); +omap_mux_init_signal ("usba0_ulpiphy_dir" , +OMAP_PIN_INPUT_PULLDOWN ); +omap_mux_init_signal ("usba0_ulpiphy_nxt" , +OMAP_PIN_INPUT_PULLDOWN ); +omap_mux_init_signal ("usba0_ulpiphy_dat0" , +OMAP_PIN_INPUT_PULLDOWN ); +omap_mux_init_signal ("usba0_ulpiphy_dat1" , +OMAP_PIN_INPUT_PULLDOWN ); +omap_mux_init_signal ("usba0_ulpiphy_dat2" , +OMAP_PIN_INPUT_PULLDOWN ); +omap_mux_init_signal ("usba0_ulpiphy_dat3" , +OMAP_PIN_INPUT_PULLDOWN ); +omap_mux_init_signal ("usba0_ulpiphy_dat4" , +OMAP_PIN_INPUT_PULLDOWN ); +omap_mux_init_signal ("usba0_ulpiphy_dat5" , +OMAP_PIN_INPUT_PULLDOWN ); +omap_mux_init_signal ("usba0_ulpiphy_dat6" , +OMAP_PIN_INPUT_PULLDOWN ); +omap_mux_init_signal ("usba0_ulpiphy_dat7" , +OMAP_PIN_INPUT_PULLDOWN ); +break ; +default : +break ; + } +}void __init usb_musb_init (struct omap_musb_board_data *board_data) {if (cpu_is_omap243x ()) {
@@ -199,6 +237,8 @@ void __init usb_musb_init(struct omap_musb_board_data *board_data) musb_resources[0 ].start =OMAP44XX_HSUSB_OTG_BASE ; musb_resources[1 ].start =OMAP44XX_IRQ_HS_USB_MC_N ; musb_resources[2 ].start =OMAP44XX_IRQ_HS_USB_DMA_N ; + +usb_musb_mux_init (board_data); } musb_resources[0 ].end = musb_resources[0 ].start +SZ_4K -1 ;
Signature · 1 line
1.7.4.rc2
PATCH 2/7 arm: omap4: 4430sdp: drop ehci support
In reply to Felipe BalbiFrom: Anand Gadiyar <[email protected]>
Most revisions of the OMAP4 Blaze/SDP platform do not have the EHCI signals routed by default. The pads are routed for the alternate HSI functionality instead, and explicit board modifications are needed to route the signals to the USB PHY on the board.
Also, turning on the PHY connected to the EHCI port causes a board reboot during bootup due to an unintended short on the rails - this affects many initial revisions of the board, and needs a minor board mod to fix (or as a workaround, one should not attempt to power on the USB PHY).
Given that these boards need explicit board mods to even get EHCI working (separate from the accidental short above), we should not attempt to enable EHCI by default.
So drop the EHCI support from the board files for the Blaze/SDP platforms.
--- arch/arm/mach-omap2/board-4430sdp.c | 19 ------------------- 1 files changed, 0 insertions(+), 19 deletions(-)
arch/arm/mach-omap2/board-4430sdp.c +0 -19
@@ -44,7 +44,6 @@#define ETH_KS8851_IRQ 34#define ETH_KS8851_POWER_ON 48#define ETH_KS8851_QUART 138 -#define OMAP4SDP_MDM_PWR_EN_GPIO 157#define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO 184#define OMAP4_SFH7741_ENABLE_GPIO 188
@@ -251,16 +250,6 @@ static void __init omap_4430sdp_init_irq(void)gic_init_irq (); } -static const struct ehci_hcd_omap_platform_data ehci_pdata__initconst = { - .port_mode[0 ] =EHCI_HCD_OMAP_MODE_PHY , - .port_mode[1 ] =EHCI_HCD_OMAP_MODE_UNKNOWN , - .port_mode[2 ] =EHCI_HCD_OMAP_MODE_UNKNOWN , - .phy_reset = false, - .reset_gpio_port[0 ] = -EINVAL , - .reset_gpio_port[1 ] = -EINVAL , - .reset_gpio_port[2 ] = -EINVAL , -}; -static struct omap_musb_board_data musb_board_data = { .interface_type =MUSB_INTERFACE_UTMI , .mode =MUSB_OTG ,
@@ -576,14 +565,6 @@ static void __init omap_4430sdp_init(void)omap_serial_init ();omap4_twl6030_hsmmc_init (mmc); -/* Power on the ULPI PHY */ - status =gpio_request (OMAP4SDP_MDM_PWR_EN_GPIO ,"USBB1 PHY VMDM_3V3" ); -if (status) -pr_err ("%s: Could not get USBB1 PHY GPIO\n" , __func__); -else -gpio_direction_output (OMAP4SDP_MDM_PWR_EN_GPIO ,1 ); - -usb_ehci_init (&ehci_pdata);usb_musb_init (&musb_board_data); status =omap_ethernet_init ();
Signature · 1 line
1.7.4.rc2
PATCH 3/7 OMAP2430: hwmod data: Add USBOTG
In reply to Felipe BalbiFrom: Hema HK <[email protected]>
OMAP2430 hwmod data structures are populated with base address, L3 and L4 interface clocks, IRQs and sysconfig register details.
As per OMAP USBOTG specification, need to configure the USBOTG to smart idle/standby or no idle/standby during data transfer and force idle/standby when not in use to support retention and off-mode. By setting HWMOD_SWSUP_SIDLE and HWMOD_SWSUP_MSTANDBY flags, framework will take care of configuring to no idle/standby when module is enabled and force idle/standby when suspended.
--- arch/arm/mach-omap2/omap_hwmod_2430_data.c | 98 ++++++++++++++++++++++++++++ 1 files changed, 98 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/omap_hwmod_2430_data.c +98 -0
@@ -89,6 +89,16 @@ static struct omap_hwmod omap2430_uart3_hwmod;static struct omap_hwmod omap2430_i2c1_hwmod;static struct omap_hwmod omap2430_i2c2_hwmod; +static struct omap_hwmod omap2430_usbhsotg_hwmod; + +/* l3_core -> usbhsotg interface */ +static struct omap_hwmod_ocp_if omap2430_usbhsotg__l3 = { + .master = &omap2430_usbhsotg_hwmod, + .slave = &omap2430_l3_main_hwmod, + .clk ="core_l3_ck" , + .user =OCP_USER_MPU , +}; +/* I2C IP block address space length (in bytes) */ #define OMAP2_I2C_AS_LEN 128
@@ -189,6 +199,35 @@ static struct omap_hwmod_ocp_if omap2_l4_core__uart3 = { .user = OCP_USER_MPU | OCP_USER_SDMA, }; +/* +* usbhsotg interface data +*/ +static struct omap_hwmod_addr_space omap2430_usbhsotg_addrs[] = { + { + .pa_start =OMAP243X_HS_BASE , + .pa_end =OMAP243X_HS_BASE +SZ_4K -1 , + .flags =ADDR_TYPE_RT + }, +}; + +/* l4_core ->usbhsotg interface */ +static struct omap_hwmod_ocp_if omap2430_l4_core__usbhsotg = { + .master = &omap2430_l4_core_hwmod, + .slave = &omap2430_usbhsotg_hwmod, + .clk ="usb_l4_ick" , + .addr = omap2430_usbhsotg_addrs, + .addr_cnt =ARRAY_SIZE (omap2430_usbhsotg_addrs), + .user =OCP_USER_MPU , +}; + +static struct omap_hwmod_ocp_if *omap2430_usbhsotg_masters[] = { + &omap2430_usbhsotg__l3, +}; + +static struct omap_hwmod_ocp_if *omap2430_usbhsotg_slaves[] = { + &omap2430_l4_core__usbhsotg, +}; +/* Slave interfaces on the L4_CORE interconnect */ static struct omap_hwmod_ocp_if *omap2430_l4_core_slaves[] = { &omap2430_l3_main__l4_core,
@@ -919,6 +958,62 @@ static struct omap_hwmod omap2430_dma_system_hwmod = { .flags = HWMOD_NO_IDLEST, }; +/* +* usbhsotg +*/ +static struct omap_hwmod_class_sysconfig omap2430_usbhsotg_sysc = { + .rev_offs =0x0400 , + .sysc_offs =0x0404 , + .syss_offs =0x0408 , + .sysc_flags = (SYSC_HAS_SIDLEMODE |SYSC_HAS_MIDLEMODE | +SYSC_HAS_ENAWAKEUP |SYSC_HAS_SOFTRESET | +SYSC_HAS_AUTOIDLE ), + .idlemodes = (SIDLE_FORCE |SIDLE_NO |SIDLE_SMART | +MSTANDBY_FORCE |MSTANDBY_NO |MSTANDBY_SMART ), + .sysc_fields = &omap_hwmod_sysc_type1, +}; + +static struct omap_hwmod_class usbotg_class = { + .name ="usbotg" , + .sysc = &omap2430_usbhsotg_sysc, +}; + +/* usb_otg_hs */ +static struct omap_hwmod_irq_info omap2430_usbhsotg_mpu_irqs[] = { + + { .name ="mc" , .irq =92 }, + { .name ="dma" , .irq =93 }, +}; + +static struct omap_hwmod omap2430_usbhsotg_hwmod = { + .name ="usb_otg_hs" , + .mpu_irqs = omap2430_usbhsotg_mpu_irqs, + .mpu_irqs_cnt =ARRAY_SIZE (omap2430_usbhsotg_mpu_irqs), + .main_clk ="usbhs_ick" , + .prcm = { + .omap2 = { + .prcm_reg_id =1 , + .module_bit =OMAP2430_EN_USBHS_MASK , + .module_offs =CORE_MOD , + .idlest_reg_id =1 , + .idlest_idle_bit =OMAP2430_ST_USBHS_SHIFT , + }, + }, + .masters = omap2430_usbhsotg_masters, + .masters_cnt =ARRAY_SIZE (omap2430_usbhsotg_masters), + .slaves = omap2430_usbhsotg_slaves, + .slaves_cnt =ARRAY_SIZE (omap2430_usbhsotg_slaves), + .class = &usbotg_class, +/* +* Erratum ID: i479 idle_req / idle_ack mechanism potentially +* broken when autoidle is enabled +* workaround is to disable the autoidle bit at module level. +*/ + .flags =HWMOD_NO_OCP_AUTOIDLE |HWMOD_SWSUP_SIDLE + |HWMOD_SWSUP_MSTANDBY , + .omap_chip =OMAP_CHIP_INIT (CHIP_IS_OMAP2430 ) +}; +static __initdata struct omap_hwmod *omap2430_hwmods[] = { &omap2430_l3_main_hwmod, &omap2430_l4_core_hwmod,
@@ -941,6 +1036,9 @@ static __initdata struct omap_hwmod *omap2430_hwmods[] = {/* dma_system class*/ &omap2430_dma_system_hwmod, + +/* usbotg class*/ + &omap2430_usbhsotg_hwmod, NULL, };
Signature · 1 line
1.7.4.rc2
PATCH 4/7 OMAP3xxx: hwmod data: Add USBOTG
In reply to Felipe BalbiFrom: Hema HK <[email protected]>
OMAP3 hwmod data structures are populated for USBOTG with base address, L3 and L4 interface clocks, IRQs and sysconfig register details. This is applicable for OMAP3430 amd OMAP3630.
As per OMAP USBOTG specification, need to configure the USBOTG to smart idle/standby or no idle/standby during data transfer and force idle/standby when not in use to support retention and offmode. By setting HWMOD_SWSUP_SIDLE and HWMOD_SWSUP_MSTANDBY flags, framework will take care of configuring to no idle/standby when module is enabled and force idle/standby when idled.
--- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 101 ++++++++++++++++++++++++++++ 1 files changed, 101 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +101 -0
@@ -107,6 +107,15 @@ static struct omap_hwmod omap3xxx_uart1_hwmod;static struct omap_hwmod omap3xxx_uart2_hwmod;static struct omap_hwmod omap3xxx_uart3_hwmod;static struct omap_hwmod omap3xxx_uart4_hwmod; +static struct omap_hwmod omap3xxx_usbhsotg_hwmod; + +/* l3_core -> usbhsotg interface */ +static struct omap_hwmod_ocp_if omap3xxx_usbhsotg__l3 = { + .master = &omap3xxx_usbhsotg_hwmod, + .slave = &omap3xxx_l3_main_hwmod, + .clk ="core_l3_ick" , + .user =OCP_USER_MPU , +};/* L4_CORE -> L4_WKUP interface */ static struct omap_hwmod_ocp_if omap3xxx_l4_core__l4_wkup = {
@@ -301,6 +310,36 @@ static struct omap_hwmod_ocp_if omap3_l4_core__sr2 = { .user = OCP_USER_MPU, }; +/* +* usbhsotg interface data +*/ + +static struct omap_hwmod_addr_space omap3xxx_usbhsotg_addrs[] = { + { + .pa_start =OMAP34XX_HSUSB_OTG_BASE , + .pa_end =OMAP34XX_HSUSB_OTG_BASE +SZ_4K -1 , + .flags =ADDR_TYPE_RT + }, +}; + +/* l4_core -> usbhsotg */ +static struct omap_hwmod_ocp_if omap3xxx_l4_core__usbhsotg = { + .master = &omap3xxx_l4_core_hwmod, + .slave = &omap3xxx_usbhsotg_hwmod, + .clk ="l4_ick" , + .addr = omap3xxx_usbhsotg_addrs, + .addr_cnt =ARRAY_SIZE (omap3xxx_usbhsotg_addrs), + .user =OCP_USER_MPU , +}; + +static struct omap_hwmod_ocp_if *omap3xxx_usbhsotg_masters[] = { + &omap3xxx_usbhsotg__l3, +}; + +static struct omap_hwmod_ocp_if *omap3xxx_usbhsotg_slaves[] = { + &omap3xxx_l4_core__usbhsotg, +}; +/* Slave interfaces on the L4_CORE interconnect */ static struct omap_hwmod_ocp_if *omap3xxx_l4_core_slaves[] = { &omap3xxx_l3_main__l4_core,
@@ -1356,6 +1395,64 @@ static struct omap_hwmod omap36xx_sr2_hwmod = { .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3630ES1), }; +/* +* usbhsotg +*/ +static struct omap_hwmod_class_sysconfig omap3xxx_usbhsotg_sysc = { + .rev_offs =0x0400 , + .sysc_offs =0x0404 , + .syss_offs =0x0408 , + .sysc_flags = (SYSC_HAS_SIDLEMODE |SYSC_HAS_MIDLEMODE | +SYSC_HAS_ENAWAKEUP |SYSC_HAS_SOFTRESET | +SYSC_HAS_AUTOIDLE ), + .idlemodes = (SIDLE_FORCE |SIDLE_NO |SIDLE_SMART | +MSTANDBY_FORCE |MSTANDBY_NO |MSTANDBY_SMART ), + .sysc_fields = &omap_hwmod_sysc_type1, +}; + +static struct omap_hwmod_class usbotg_class = { + .name ="usbotg" , + .sysc = &omap3xxx_usbhsotg_sysc, +}; + +/* usb_otg_hs */ +static struct omap_hwmod_irq_info omap3xxx_usbhsotg_mpu_irqs[] = { + + { .name ="mc" , .irq =92 }, + { .name ="dma" , .irq =93 }, +}; + +static struct omap_hwmod omap3xxx_usbhsotg_hwmod = { + .name ="usb_otg_hs" , + .mpu_irqs = omap3xxx_usbhsotg_mpu_irqs, + .mpu_irqs_cnt =ARRAY_SIZE (omap3xxx_usbhsotg_mpu_irqs), + .main_clk ="hsotgusb_ick" , + .prcm = { + .omap2 = { + .prcm_reg_id =1 , + .module_bit =OMAP3430_EN_HSOTGUSB_SHIFT , + .module_offs =CORE_MOD , + .idlest_reg_id =1 , + .idlest_idle_bit =OMAP3430ES2_ST_HSOTGUSB_IDLE_SHIFT , + .idlest_stdby_bit =OMAP3430ES2_ST_HSOTGUSB_STDBY_SHIFT + }, + }, + .masters = omap3xxx_usbhsotg_masters, + .masters_cnt =ARRAY_SIZE (omap3xxx_usbhsotg_masters), + .slaves = omap3xxx_usbhsotg_slaves, + .slaves_cnt =ARRAY_SIZE (omap3xxx_usbhsotg_slaves), + .class = &usbotg_class, + +/* +* Erratum ID: i479 idle_req / idle_ack mechanism potentially +* broken when autoidle is enabled +* workaround is to disable the autoidle bit at module level. +*/ + .flags =HWMOD_NO_OCP_AUTOIDLE |HWMOD_SWSUP_SIDLE + |HWMOD_SWSUP_MSTANDBY , + .omap_chip =OMAP_CHIP_INIT (CHIP_IS_OMAP3430 ) +}; +static __initdata struct omap_hwmod *omap3xxx_hwmods[] = { &omap3xxx_l3_main_hwmod, &omap3xxx_l4_core_hwmod,
@@ -1387,6 +1484,10 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {/* dma_system class*/ &omap3xxx_dma_system_hwmod, + +/* usbotg class */ + &omap3xxx_usbhsotg_hwmod, + NULL, };
Signature · 1 line
1.7.4.rc2
PATCH 5/7 AM35xx: hwmod data: Add USBOTG
In reply to Felipe BalbiFrom: Hema HK <[email protected]>
AM35xx hwmod data structures are populated for USBOTG with base address, L3 and L4 interface clocks and IRQ.
--- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 65 ++++++++++++++++++++++++++++ 1 files changed, 65 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +65 -0
@@ -28,6 +28,7 @@#include "prm-regbits-34xx.h" #include "cm-regbits-34xx.h" #include "wd_timer.h" +#include <mach/am35xx.h> /* * OMAP3xxx hardware module integration data
@@ -55,6 +56,8 @@ static struct omap_hwmod omap3xxx_gpio5_hwmod;static struct omap_hwmod omap3xxx_gpio6_hwmod;static struct omap_hwmod omap34xx_sr1_hwmod;static struct omap_hwmod omap34xx_sr2_hwmod; +static struct omap_hwmod am35xx_usbhsotg_hwmod; +static struct omap_hwmod omap3xxx_dma_system_hwmod;
@@ -117,6 +120,13 @@ static struct omap_hwmod_ocp_if omap3xxx_usbhsotg__l3 = { .user = OCP_USER_MPU, }; +/* l3_core -> am35xx_usbhsotg interface */ +static struct omap_hwmod_ocp_if am35xx_usbhsotg__l3 = { + .master = &am35xx_usbhsotg_hwmod, + .slave = &omap3xxx_l3_main_hwmod, + .clk ="core_l3_ick" , + .user =OCP_USER_MPU , +};/* L4_CORE -> L4_WKUP interface */ static struct omap_hwmod_ocp_if omap3xxx_l4_core__l4_wkup = { .master = &omap3xxx_l4_core_hwmod,
@@ -340,6 +350,31 @@ static struct omap_hwmod_ocp_if *omap3xxx_usbhsotg_slaves[] = { &omap3xxx_l4_core__usbhsotg, }; +static struct omap_hwmod_addr_space am35xx_usbhsotg_addrs[] = { + { + .pa_start =AM35XX_IPSS_USBOTGSS_BASE , + .pa_end =AM35XX_IPSS_USBOTGSS_BASE +SZ_4K -1 , + .flags =ADDR_TYPE_RT + }, +}; + +/* l4_core -> usbhsotg */ +static struct omap_hwmod_ocp_if am35xx_l4_core__usbhsotg = { + .master = &omap3xxx_l4_core_hwmod, + .slave = &am35xx_usbhsotg_hwmod, + .clk ="l4_ick" , + .addr = am35xx_usbhsotg_addrs, + .addr_cnt =ARRAY_SIZE (am35xx_usbhsotg_addrs), + .user =OCP_USER_MPU , +}; + +static struct omap_hwmod_ocp_if *am35xx_usbhsotg_masters[] = { + &am35xx_usbhsotg__l3, +}; + +static struct omap_hwmod_ocp_if *am35xx_usbhsotg_slaves[] = { + &am35xx_l4_core__usbhsotg, +};/* Slave interfaces on the L4_CORE interconnect */ static struct omap_hwmod_ocp_if *omap3xxx_l4_core_slaves[] = { &omap3xxx_l3_main__l4_core,
@@ -1452,6 +1487,33 @@ static struct omap_hwmod omap3xxx_usbhsotg_hwmod = { | HWMOD_SWSUP_MSTANDBY, .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430) }; +/* usb_otg_hs */ +static struct omap_hwmod_irq_info am35xx_usbhsotg_mpu_irqs[] = { + + { .name ="mc" , .irq =71 }, +}; + +static struct omap_hwmod_class am35xx_usbotg_class = { + .name ="am35xx_usbotg" , + .sysc =NULL , +}; + +static struct omap_hwmod am35xx_usbhsotg_hwmod = { + .name ="am35x_otg_hs" , + .mpu_irqs = am35xx_usbhsotg_mpu_irqs, + .mpu_irqs_cnt =ARRAY_SIZE (am35xx_usbhsotg_mpu_irqs), + .main_clk =NULL , + .prcm = { + .omap2 = { + }, + }, + .masters = am35xx_usbhsotg_masters, + .masters_cnt =ARRAY_SIZE (am35xx_usbhsotg_masters), + .slaves = am35xx_usbhsotg_slaves, + .slaves_cnt =ARRAY_SIZE (am35xx_usbhsotg_slaves), + .class = &am35xx_usbotg_class, + .omap_chip =OMAP_CHIP_INIT (CHIP_IS_OMAP3430ES3_1 ) +};static __initdata struct omap_hwmod *omap3xxx_hwmods[] = { &omap3xxx_l3_main_hwmod,
@@ -1488,6 +1550,9 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {/* usbotg class */ &omap3xxx_usbhsotg_hwmod, +/* usbotg for am35x */ + &am35xx_usbhsotg_hwmod, + NULL, };
Signature · 1 line
1.7.4.rc2
PATCH 5/7 AM35xx: hwmod data: Add USBOTG
Quoted 25 lines
-----Original Message-----
From: linux-omap-owner at vger.kernel.org [mailto:linux-omap- owner at vger.kernel.org] On Behalf Of Balbi, Felipe
Sent: Thursday, February 17, 2011 6:11 PM
To: Tony Lindgren
Cc: Linux OMAP Mailing List; Linux ARM Kernel Mailing List; Kalliguddi, Hema; Kevin Hilman; Cousson, Benoit; Paul Walmsley; Balbi, Felipe
Subject: [patch-v2.6.39 5/7] AM35xx: hwmod data: Add USBOTGFrom: Hema HK <[email protected]>
AM35xx hwmod data structures are populated for USBOTG with base address, L3 and L4 interface clocks and IRQ.
Signed-off-by Hema HK <[email protected]>Cc Tony Lindgren <[email protected]>Cc Kevin Hilman <[email protected]>Cc Cousson, Benoit <[email protected]>Cc Paul Walmsley <[email protected]>Signed-off-by Felipe Balbi <[email protected]>--- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 65 ++++++++++++++++++++++++++++ 1 files changed, 65 insertions(+), 0 deletions(-)
[snip]
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c static __initdata struct omap_hwmod *omap3xxx_hwmods[] = { · line 1556
Quoted 5 lines
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +3
-0+/* usbotg for am35x */ + &am35xx_usbhsotg_hwmod, + NULL,
Felipe, Hema,
This patch will break all existing OMAP35x (and I believe OMAP3430 - since there is no difference - unless there is some trick in the USB driver code).
I have seen similar problems with smart reflex included in the AM35x hwmod data.
In this case accessing "unknown" registers corresponding to SmartReflex in _setup() causes crash.
(http://marc.info/?l=linux-omap&m=129777408503329&w=2)
I expect similar to be happening on OMAP35x with inclusion of am35xx_usbhsotg_hwmod. If you don't see any crash, there would be side-effects - and _setup() would be initializing non-existent OTG registers on OMAP35x.
Did you see any problems while testing?
~sanjeev
PS: Sending mail via webmailer. Formatting may break
Quoted 9 lines
};
--
1.7.4.rc2--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH 5/7 AM35xx: hwmod data: Add USBOTG
Hi Premi,
Quoted 44 lines
-----Original Message-----
From: Premi, Sanjeev [mailto:premi at ti.com]
Sent: Friday, February 18, 2011 4:59 PM
To: Balbi, Felipe; Tony Lindgren
Cc: Linux OMAP Mailing List; Linux ARM Kernel Mailing List; Kalliguddi, Hema; Kevin Hilman; Cousson, Benoit; Paul Walmsley
Subject: RE: [patch-v2.6.39 5/7] AM35xx: hwmod data: Add USBOTGQuoted 6 lines
-----Original Message-----
From: linux-omap-owner at vger.kernel.org [mailto:linux-omap- owner at vger.kernel.org] On Behalf Of Balbi, Felipe
Sent: Thursday, February 17, 2011 6:11 PM
To: Tony Lindgren
Cc: Linux OMAP Mailing List; Linux ARM Kernel Mailing List;Kalliguddi,
Quoted 6 lines
Hema; Kevin Hilman; Cousson, Benoit; Paul Walmsley; Balbi, Felipe
Subject: [patch-v2.6.39 5/7] AM35xx: hwmod data: Add USBOTGFrom: Hema HK <[email protected]>
AM35xx hwmod data structures are populated for USBOTG with
base address,
Quoted 13 lines
L3 and L4 interface clocks and IRQ.
Signed-off-by Hema HK <[email protected]>Cc Tony Lindgren <[email protected]>Cc Kevin Hilman <[email protected]>Cc Cousson, Benoit <[email protected]>Cc Paul Walmsley <[email protected]>Signed-off-by Felipe Balbi <[email protected]>--- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 65 ++++++++++++++++++++++++++++ 1 files changed, 65 insertions(+), 0 deletions(-)[snip]
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c static __initdata struct omap_hwmod *omap3xxx_hwmods[] = { · line 1556
Quoted 5 lines
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +3
-0+/* usbotg for am35x */ + &am35xx_usbhsotg_hwmod, + NULL,Felipe, Hema,
Quoted 4 lines
This patch will break all existing OMAP35x (and I believe OMAP3430 - since there is no difference - unless there is some trick in the USB driver code).
I agree that this will break the AM35x because there is no separate CHIP_IS* defined for AM35x.
AM35x is treated as one of the version of OMAP3430.
Quoted 2 lines
I have seen similar problems with smart reflex included in the AM35x hwmod data.
Unless the new CHIP_IS_* introduced for AM35x this problem will still exists.
I thought you are already working on this because you were asking the questions in the list.
Quoted 10 lines
In this case accessing "unknown" registers corresponding to SmartReflex in
_setup()causes crash.
(http://marc.info/?l=linux-omap&m=129777408503329&w=2)I expect similar to be happening on OMAP35x with inclusion of
am35xx_usbhsotg_hwmod. If you don't see any crash, there would be side-effects - and_setup()would be initializing non-existent OTG registers on OMAP35x.
This will not impact for OMAP3 as the IDCODE is different AM35x and OMAP3, so passing the right chip version in the HWMOD database for AM35x will avoid the hwod init incase of OMAP3.
Quoted 2 lines
Did you see any problems while testing?
I tested with OMAP3430SDP and OMAP3630Zoom3 and did not see the problem.
Regards,
Hema
Quoted 15 lines
~sanjeev
PS: Sending mail via webmailer. Formatting may break
Quoted 7 lines
};
--
1.7.4.rc2--
To unsubscribe from this list: send the line "unsubscribelinux-omap" in
Quoted 2 lines
the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH 5/7 AM35xx: hwmod data: Add USBOTG
Quoted 63 lines
-----Original Message-----
From: Kalliguddi, Hema
Sent: Friday, February 18, 2011 6:37 PM
To: Premi, Sanjeev; Balbi, Felipe; Tony Lindgren
Cc: Linux OMAP Mailing List; Linux ARM Kernel Mailing List; Kevin Hilman; Cousson, Benoit; Paul Walmsley
Subject: RE: [patch-v2.6.39 5/7] AM35xx: hwmod data: Add USBOTGHi Premi,
Quoted 44 lines
-----Original Message-----
From: Premi, Sanjeev [mailto:premi at ti.com]
Sent: Friday, February 18, 2011 4:59 PM
To: Balbi, Felipe; Tony Lindgren
Cc: Linux OMAP Mailing List; Linux ARM Kernel Mailing List; Kalliguddi, Hema; Kevin Hilman; Cousson, Benoit; Paul Walmsley
Subject: RE: [patch-v2.6.39 5/7] AM35xx: hwmod data: Add USBOTGQuoted 6 lines
-----Original Message-----
From: linux-omap-owner at vger.kernel.org [mailto:linux-omap- owner at vger.kernel.org] On Behalf Of Balbi, Felipe
Sent: Thursday, February 17, 2011 6:11 PM
To: Tony Lindgren
Cc: Linux OMAP Mailing List; Linux ARM Kernel Mailing List;Kalliguddi,
Quoted 6 lines
Hema; Kevin Hilman; Cousson, Benoit; Paul Walmsley; Balbi, Felipe
Subject: [patch-v2.6.39 5/7] AM35xx: hwmod data: Add USBOTGFrom: Hema HK <[email protected]>
AM35xx hwmod data structures are populated for USBOTG with
base address,
Quoted 13 lines
L3 and L4 interface clocks and IRQ.
Signed-off-by Hema HK <[email protected]>Cc Tony Lindgren <[email protected]>Cc Kevin Hilman <[email protected]>Cc Cousson, Benoit <[email protected]>Cc Paul Walmsley <[email protected]>Signed-off-by Felipe Balbi <[email protected]>--- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 65 ++++++++++++++++++++++++++++ 1 files changed, 65 insertions(+), 0 deletions(-)[snip]
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c static __initdata struct omap_hwmod *omap3xxx_hwmods[] = { · line 1556
Quoted 5 lines
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +3
-0+/* usbotg for am35x */ + &am35xx_usbhsotg_hwmod, + NULL,Felipe, Hema,
Quoted 4 lines
This patch will break all existing OMAP35x (and I believe OMAP3430 - since there is no difference - unless there is some trick in the USB driver code).
I agree that this will break the AM35x because there is no separate CHIP_IS* defined for AM35x.
AM35x is treated as one of the version of OMAP3430.
Quoted 8 lines
Quoted 2 lines
I have seen similar problems with smart reflex included in the AM35x hwmod data.
Unless the new CHIP_IS_* introduced for AM35x this problem will still exists.
I thought you are already working on this because you were asking the questions in the list.
[sp] Yes. I am working on it. Just responded to same query.
Quoted 6 lines
Quoted 6 lines
In this case accessing "unknown" registers corresponding to SmartReflex in
_setup()causes crash.
(http://marc.info/?l=linux-omap&m=129777408503329&w=2)
Quoted 8 lines
Quoted 5 lines
I expect similar to be happening on OMAP35x with inclusion of
am35xx_usbhsotg_hwmod. If you don't see any crash, there would be side-effects - and_setup()would be initializing non-existent OTG registers on OMAP35x.This will not impact for OMAP3 as the IDCODE is different AM35x and OMAP3, so passing the right chip version in the HWMOD database for AM35x will avoid the hwod init incase of OMAP3.
[sp] Are you saying that IDCODE is being used in HWMOD to prevent
possible 'pollution' in the current implementation of am35xx_usbhsotg_hwmod?
Quoted 5 lines
Quoted 3 lines
Did you see any problems while testing?
I tested with OMAP3430SDP and OMAP3630Zoom3 and did not see the problem.
[sp] Could this be due to difference in kind of processing done
in _setup() for this hwmod. OR that addresses are (possibly) overlapping/ or not used?
I suggest verifying this at the earliest.
Quoted 19 lines
Regards,
HemaQuoted 15 lines
~sanjeev
PS: Sending mail via webmailer. Formatting may break
Quoted 7 lines
};
--
1.7.4.rc2--
To unsubscribe from this list: send the line "unsubscribelinux-omap" in
Quoted 2 lines
the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
In reply to Felipe BalbiFrom: Hema HK <[email protected]>
OMAP4 hwmod data structures are populated with base address, L3 and L4 interface clocks, IRQs and sysconfig register details.
As per OMAP USBOTG specification, need to configure the USBOTG to smart idle/standby or no idle/standby during data transfer and force idle/standby when not in use to support retention and offmode. By setting HWMOD_SWSUP_SIDLE and HWMOD_SWSUP_MSTANDBY flags,framework will take care of configuring to no idle/standby when module is enabled and force idle/standby when idled.
--- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 93 ++++++++++++++++++++++++++++ 1 files changed, 93 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/omap_hwmod_44xx_data.c +93 -0
@@ -55,6 +55,7 @@ static struct omap_hwmod omap44xx_l4_per_hwmod;static struct omap_hwmod omap44xx_l4_wkup_hwmod;static struct omap_hwmod omap44xx_mpu_hwmod;static struct omap_hwmod omap44xx_mpu_private_hwmod; +static struct omap_hwmod omap44xx_usb_otg_hs_hwmod;/* * Interconnects omap_hwmod structures
@@ -286,12 +287,21 @@ static struct omap_hwmod_ocp_if omap44xx_l4_cfg__l3_main_2 = { .user = OCP_USER_MPU | OCP_USER_SDMA, }; +/* usb_otg_hs -> l3_main_2 */ +static struct omap_hwmod_ocp_if omap44xx_usb_otg_hs__l3_main_2 = { + .master = &omap44xx_usb_otg_hs_hwmod, + .slave = &omap44xx_l3_main_2_hwmod, + .clk ="l3_div_ck" , + .user =OCP_USER_MPU |OCP_USER_SDMA , +}; +/* l3_main_2 slave ports */ static struct omap_hwmod_ocp_if *omap44xx_l3_main_2_slaves[] = { &omap44xx_dma_system__l3_main_2, &omap44xx_iva__l3_main_2, &omap44xx_l3_main_1__l3_main_2, &omap44xx_l4_cfg__l3_main_2, + &omap44xx_usb_otg_hs__l3_main_2, };static struct omap_hwmod omap44xx_l3_main_2_hwmod = {
@@ -2001,6 +2011,87 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = { .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430), }; +/* +* 'usb_otg_hs' class +* high-speed on-the-go universal serial bus (usb_otg_hs) controller +*/ + +static struct omap_hwmod_class_sysconfig omap44xx_usb_otg_hs_sysc = { + .rev_offs =0x0400 , + .sysc_offs =0x0404 , + .syss_offs =0x0408 , + .sysc_flags = (SYSC_HAS_SIDLEMODE |SYSC_HAS_MIDLEMODE | +SYSC_HAS_ENAWAKEUP |SYSC_HAS_SOFTRESET | +SYSC_HAS_AUTOIDLE ), + .idlemodes = (SIDLE_FORCE |SIDLE_NO |SIDLE_SMART | +MSTANDBY_FORCE |MSTANDBY_NO |MSTANDBY_SMART ), + .sysc_fields = &omap_hwmod_sysc_type1, +}; + +static struct omap_hwmod_class omap44xx_usb_otg_hs_hwmod_class = { + .name ="usb_otg_hs" , + .sysc = &omap44xx_usb_otg_hs_sysc, +}; + +/* usb_otg_hs */ +static struct omap_hwmod_irq_info omap44xx_usb_otg_hs_irqs[] = { + { .name ="mc" , .irq =92 +OMAP44XX_IRQ_GIC_START }, + { .name ="dma" , .irq =93 +OMAP44XX_IRQ_GIC_START }, +}; + +/* usb_otg_hs master ports */ +static struct omap_hwmod_ocp_if *omap44xx_usb_otg_hs_masters[] = { + &omap44xx_usb_otg_hs__l3_main_2, +}; + +static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = { + { + .pa_start =OMAP44XX_HSUSB_OTG_BASE , + .pa_end =OMAP44XX_HSUSB_OTG_BASE +SZ_4K -1 , + .flags =ADDR_TYPE_RT + }, +}; + +/* l4_cfg -> usb_otg_hs */ +static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_otg_hs = { + .master = &omap44xx_l4_cfg_hwmod, + .slave = &omap44xx_usb_otg_hs_hwmod, + .clk ="l4_div_ck" , + .addr = omap44xx_usb_otg_hs_addrs, + .addr_cnt =ARRAY_SIZE (omap44xx_usb_otg_hs_addrs), + .user =OCP_USER_MPU |OCP_USER_SDMA , +}; + +/* usb_otg_hs slave ports */ +static struct omap_hwmod_ocp_if *omap44xx_usb_otg_hs_slaves[] = { + &omap44xx_l4_cfg__usb_otg_hs, +}; + +static struct omap_hwmod_opt_clk usb_otg_hs_opt_clks[] = { + { .role ="xclk" , .clk ="otg_60m_gfclk_ck" }, +}; + +static struct omap_hwmod omap44xx_usb_otg_hs_hwmod = { + .name ="usb_otg_hs" , + .class = &omap44xx_usb_otg_hs_hwmod_class, + .mpu_irqs = omap44xx_usb_otg_hs_irqs, + .mpu_irqs_cnt =ARRAY_SIZE (omap44xx_usb_otg_hs_irqs), + .main_clk ="usb_otg_hs_ick" , + .prcm = { + .omap4 = { + .clkctrl_reg =OMAP4430_CM_L3INIT_USB_OTG_CLKCTRL , + }, + }, + .opt_clks = usb_otg_hs_opt_clks, + .opt_clks_cnt =ARRAY_SIZE (usb_otg_hs_opt_clks), + .slaves = omap44xx_usb_otg_hs_slaves, + .slaves_cnt =ARRAY_SIZE (omap44xx_usb_otg_hs_slaves), + .masters = omap44xx_usb_otg_hs_masters, + .masters_cnt =ARRAY_SIZE (omap44xx_usb_otg_hs_masters), + .flags =HWMOD_SWSUP_SIDLE |HWMOD_SWSUP_MSTANDBY , + .omap_chip =OMAP_CHIP_INIT (CHIP_IS_OMAP4430 ), +}; +static __initdata struct omap_hwmod *omap44xx_hwmods[] = {/* dmm class */
@@ -2068,6 +2159,8 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = { &omap44xx_wd_timer2_hwmod, &omap44xx_wd_timer3_hwmod, +/* hsusb otg class */ + &omap44xx_usb_otg_hs_hwmod, NULL, };
Signature · 1 line
1.7.4.rc2
PATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
Hi Felipe and Hema,
Sorry for this late review, but I have a couple of comments on this one.
Since I was planning to send usb hwmod data file to Tony directly like I did for the other drivers, I can handle the update myself if you want.
Quoted 1 line · Felipe
From: Hema HK<[email protected]>
The authorship is not correct. It should be me.
[...]
Review
Quoted 7 lines
(quoted diff) +7
-0+static struct omap_hwmod_class_sysconfig omap44xx_usb_otg_hs_sysc = { + .rev_offs = 0x0400, + .sysc_offs = 0x0404, + .syss_offs = 0x0408, + .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE| + SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET | + SYSC_HAS_AUTOIDLE),
These flags does not contains the latest reset flag (SYSS_HAS_RESET_STATUS) introduced in 2.6.37.
[...]
Review
Quoted 4 lines
(quoted diff) +4
-0+static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = { + { + .pa_start = OMAP44XX_HSUSB_OTG_BASE, + .pa_end = OMAP44XX_HSUSB_OTG_BASE + SZ_4K - 1,
You should not use the defines anymore, since the only user of the physical address should be this file.
[...]
Review
Quoted 2 lines
(quoted diff) +2
-0+static struct omap_hwmod_opt_clk usb_otg_hs_opt_clks[] = { + { .role = "xclk", .clk = "otg_60m_gfclk_ck" },
That optional clock does not exist anymore, it should be "usb_otg_hs_xclk".
[...]
Review static __initdata struct omap_hwmod *omap44xx_hwmods[] = { · line 2163
Quoted 6 lines
(quoted diff) +2
-0@@ -2068,6 +2159,8 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = { &omap44xx_wd_timer2_hwmod, &omap44xx_wd_timer3_hwmod, + /* hsusb otg class */ + &omap44xx_usb_otg_hs_hwmod,
"usb_otb_hs" should be before "wd_timer2".
For information, the updated version is below. It is based on rc5 + for_2.6.39/omap4_hwmod_data series I've just sent.
Regards,
Benoit
---
From 5c2017f9405588127bf0b41f718409411d01abf8 Mon Sep 17 00:00:00 2001
From: Benoit Cousson <[email protected]>
Date: Thu, 17 Feb 2011 12:41:05 +0000
Subject: [PATCH] OMAP4430: hwmod data: Add USBOTG
OMAP4 hwmod data structures are populated with base address, L3 and L4 interface clocks, IRQs and sysconfig register details.
As per OMAP USBOTG specification, need to configure the USBOTG to smart idle/standby or no idle/standby during data transfer and force idle/standby when not in use to support retention and offmode. By setting HWMOD_SWSUP_SIDLE and HWMOD_SWSUP_MSTANDBY flags,framework will take care of configuring to no idle/standby when module is enabled and force idle/standby when idled.
--- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 95 ++++++++++++++++++++++++++++ 1 files changed, 95 insertions(+), 0 deletions(-)
(quoted diff) +0 -0
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 989bc96..b27e1e3 100644
arch/arm/mach-omap2/omap_hwmod_44xx_data.c +1 -0
@@ -62,6 +62,7 @@ static struct omap_hwmod omap44xx_mmc1_hwmod;static struct omap_hwmod omap44xx_mmc2_hwmod;static struct omap_hwmod omap44xx_mpu_hwmod;static struct omap_hwmod omap44xx_mpu_private_hwmod; +static struct omap_hwmod omap44xx_usb_otg_hs_hwmod;/* * Interconnects omap_hwmod structures
@@ -344,6 +345,14 @@ static struct omap_hwmod_ocp_if
omap44xx_l4_cfg__l3_main_2 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* usb_otg_hs -> l3_main_2 */
+static struct omap_hwmod_ocp_if omap44xx_usb_otg_hs__l3_main_2 = {
+ .master = &omap44xx_usb_otg_hs_hwmod,
+ .slave = &omap44xx_l3_main_2_hwmod,
+ .clk = "l3_div_ck",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l3_main_2 slave ports */
static struct omap_hwmod_ocp_if *omap44xx_l3_main_2_slaves[] = {
&omap44xx_dma_system__l3_main_2,
@@ -353,6 +362,7 @@ static struct omap_hwmod_ocp_if *omap44xx_l3_main_2_slaves[] = {
&omap44xx_iva__l3_main_2, &omap44xx_l3_main_1__l3_main_2, &omap44xx_l4_cfg__l3_main_2,
+ &omap44xx_usb_otg_hs__l3_main_2,
};
static struct omap_hwmod omap44xx_l3_main_2_hwmod = {
@@ -4725,6 +4735,88 @@ static struct omap_hwmod omap44xx_uart4_hwmod = {
};
/*
+ * 'usb_otg_hs' class
+ * high-speed on-the-go universal serial bus (usb_otg_hs) controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_usb_otg_hs_sysc = {
+ .rev_offs = 0x0400,
+ .sysc_offs = 0x0404,
+ .syss_offs = 0x0408,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_ENAWAKEUP |
+ SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE | + SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+ MSTANDBY_SMART),
+ .sysc_fields = &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_usb_otg_hs_hwmod_class = {
+ .name = "usb_otg_hs",
+ .sysc = &omap44xx_usb_otg_hs_sysc,
+};
+
+/* usb_otg_hs */
+static struct omap_hwmod_irq_info omap44xx_usb_otg_hs_irqs[] = {
+ { .name = "mc", .irq = 92 + OMAP44XX_IRQ_GIC_START },
+ { .name = "dma", .irq = 93 + OMAP44XX_IRQ_GIC_START },
+};
+
+/* usb_otg_hs master ports */
+static struct omap_hwmod_ocp_if *omap44xx_usb_otg_hs_masters[] = {
+ &omap44xx_usb_otg_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
+ {
+ .pa_start = 0x4a0ab000,
+ .pa_end = 0x4a0ab003,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_cfg -> usb_otg_hs */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_otg_hs = {
+ .master = &omap44xx_l4_cfg_hwmod,
+ .slave = &omap44xx_usb_otg_hs_hwmod,
+ .clk = "l4_div_ck",
+ .addr = omap44xx_usb_otg_hs_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_usb_otg_hs_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* usb_otg_hs slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_usb_otg_hs_slaves[] = {
+ &omap44xx_l4_cfg__usb_otg_hs,
+};
+
+static struct omap_hwmod_opt_clk usb_otg_hs_opt_clks[] = {
+ { .role = "xclk", .clk = "otg_60m_gfclk_ck" },
+};
+
+static struct omap_hwmod omap44xx_usb_otg_hs_hwmod = {
+ .name = "usb_otg_hs",
+ .class = &omap44xx_usb_otg_hs_hwmod_class,
+ .mpu_irqs = omap44xx_usb_otg_hs_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_usb_otg_hs_irqs),
+ .main_clk = "usb_otg_hs_ick",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_L3INIT_USB_OTG_CLKCTRL,
+ },
+ },
+ .opt_clks = usb_otg_hs_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(usb_otg_hs_opt_clks),
+ .slaves = omap44xx_usb_otg_hs_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_usb_otg_hs_slaves),
+ .masters = omap44xx_usb_otg_hs_masters,
+ .masters_cnt = ARRAY_SIZE(omap44xx_usb_otg_hs_masters),
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/*
* 'wd_timer' class
* 32-bit watchdog upward counter that generates a pulse on the reset
pin on
* overflow condition
@@ -4995,6 +5087,9 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
&omap44xx_uart3_hwmod,
&omap44xx_uart4_hwmod,
+ /* usb_otg_hs class */
+ &omap44xx_usb_otg_hs_hwmod,
+
/* wd_timer class */
&omap44xx_wd_timer2_hwmod,
&omap44xx_wd_timer3_hwmod,
Signature · 1 line
1.7.0.4
PATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
Benoit,
Quoted 8 lines
-----Original Message-----
From: Cousson, Benoit [mailto:b-cousson at ti.com]
Sent: Thursday, February 17, 2011 7:13 PM
To: Balbi, Felipe
Cc: Tony Lindgren; Linux OMAP Mailing List; Linux ARM Kernel Mailing List; Kalliguddi, Hema; Kevin Hilman; Paul Walmsley
Subject: Re: [patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG
Quoted 4 lines
Hi Felipe and Hema,
Sorry for this late review, but I have a couple of comments on this one.
:-)....
Quoted 5 lines
Since I was planning to send usb hwmod data file to Tony directly like I
did for the other drivers, I can handle the update myself if you want.
I was not aware that you are sending the Hwmod patches for OMAP4 for all the drivers. Anyway I am OK with you sending the patch or required I can also send it.
Quoted 6 lines · Felipe
Quoted 1 line
From: Hema HK<[email protected]>
The authorship is not correct. It should be me.
Yes. I agree. It is a mistake.
Quoted 4 lines
[...]
Quoted 1 line
+static struct
omap_hwmod_class_sysconfig
omap44xx_usb_otg_hs_sysc= {
Quoted 9 lines
Review
Quoted 6 lines
(quoted diff) +6
-0+ .rev_offs = 0x0400, + .sysc_offs = 0x0404, + .syss_offs = 0x0408, + .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE| + SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET | + SYSC_HAS_AUTOIDLE),These flags does not contains the latest reset flag (
SYSS_HAS_RESET_STATUS) introduced in 2.6.37.
OK.
Quoted 10 lines
[...]
Review
Quoted 4 lines
(quoted diff) +4
-0+static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = { + { + .pa_start = OMAP44XX_HSUSB_OTG_BASE, + .pa_end = OMAP44XX_HSUSB_OTG_BASE + SZ_4K - 1,You should not use the defines anymore, since the only user of the physical address should be this file.
Then we shlould be removing these defines right?
Quoted 9 lines
[...]
Review
Quoted 2 lines
(quoted diff) +2
-0+static struct omap_hwmod_opt_clk usb_otg_hs_opt_clks[] = { + { .role = "xclk", .clk = "otg_60m_gfclk_ck" },That optional clock does not exist anymore, it should be "
usb_otg_hs_xclk".
Since this clock is not enabled for musb as 60Mhz clock is external, I did not notice this.
In your updated patch below still the optional clock name is not changed.
Quoted 11 lines
[...]
Review static __initdata struct omap_hwmod
Quoted 1 line
(quoted diff) +0
-0@@ -2068,6 +2159,8 @@ static __initdata struct omap_hwmod*omap44xx_hwmods[] = {
Review static __initdata struct omap_hwmod · line 2163
Quoted 5 lines
(quoted diff) +2
-0&omap44xx_wd_timer2_hwmod, &omap44xx_wd_timer3_hwmod, + /* hsusb otg class */ + &omap44xx_usb_otg_hs_hwmod,"
usb_otb_hs" should be before "wd_timer2".
Is this because of the automated scripts which generates the hwmod?
Quoted 3 lines
For information, the updated version is below. It is based on rc5 + for_2.6.39/omap4_hwmod_data series I've just sent.
Regards,
Hema
Quoted 180 lines
Regards,
Benoit---
From5c2017f9405588127bf0b41f718409411d01abf8Mon Sep 17 00:00:00 2001
From: Benoit Cousson <[email protected]>
Date: Thu, 17 Feb 2011 12:41:05 +0000
Subject: [PATCH] OMAP4430: hwmod data: Add USBOTGOMAP4 hwmod data structures are populated with base address, L3 and L4 interface clocks, IRQs and sysconfig register details.
As per OMAP USBOTG specification, need to configure the USBOTG to smart idle/standby or no idle/standby during data transfer and force idle/standby when not in use to support retention and offmode. By setting
HWMOD_SWSUP_SIDLEandHWMOD_SWSUP_MSTANDBYflags,framework will take care of configuring to no idle/standby when module is enabled and force idle/standby when idled.Signed-off-by Cousson, Benoit <[email protected]>Signed-off-by Hema HK <[email protected]>Cc Tony Lindgren <[email protected]>Cc Kevin Hilman <[email protected]>Cc Paul Walmsley <[email protected]>Signed-off-by Felipe Balbi <[email protected]>[b-cousson at ti.com: Fix position, opt_clk, and author]--- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 95 ++++++++++++++++++++++++++++ 1 files changed, 95 insertions(+), 0 deletions(-)arch/arm/mach-omap2/omap_hwmod_44xx_data.c +9
-0@@ -62,6 +62,7 @@ static struct omap_hwmod omap44xx_mmc1_hwmod;static struct omap_hwmod omap44xx_mmc2_hwmod;static struct omap_hwmod omap44xx_mpu_hwmod;static struct omap_hwmod omap44xx_mpu_private_hwmod; +static struct omap_hwmod omap44xx_usb_otg_hs_hwmod;/* * Interconnects omap_hwmod structures @@ -344,6 +345,14 @@ static struct omap_hwmod_ocp_if omap44xx_l4_cfg__l3_main_2 = { .user = OCP_USER_MPU | OCP_USER_SDMA, }; +/* usb_otg_hs -> l3_main_2 */ +static struct omap_hwmod_ocp_if omap44xx_usb_otg_hs__l3_main_2 = { + .master = &omap44xx_usb_otg_hs_hwmod, + .slave = &omap44xx_l3_main_2_hwmod, + .clk ="l3_div_ck" , + .user =OCP_USER_MPU |OCP_USER_SDMA , +}; +/* l3_main_2 slave ports */ static struct omap_hwmod_ocp_if *omap44xx_l3_main_2_slaves[] = {arch/arm/mach-omap2/omap_hwmod_44xx_data.c +1
-0&omap44xx_dma_system__l3_main_2,@@ -353,6 +362,7 @@ static struct omap_hwmod_ocp_if *omap44xx_l3_main_2_slaves[] = { &omap44xx_iva__l3_main_2, &omap44xx_l3_main_1__l3_main_2, &omap44xx_l4_cfg__l3_main_2, + &omap44xx_usb_otg_hs__l3_main_2, };static struct
omap_hwmodomap44xx_l3_main_2_hwmod= {arch/arm/mach-omap2/omap_hwmod_44xx_data.c +13
-0@@ -4725,6 +4735,88 @@ static struct omap_hwmod omap44xx_uart4_hwmod = { };/* +* 'usb_otg_hs' class +* high-speed on-the-go universal serial bus (usb_otg_hs) controller +*/ + +static struct omap_hwmod_class_sysconfig omap44xx_usb_otg_hs_sysc = { + .rev_offs =0x0400 , + .sysc_offs =0x0404 , + .syss_offs =0x0408 , + .sysc_flags = (SYSC_HAS_AUTOIDLE |SYSC_HAS_ENAWAKEUP | +SYSC_HAS_MIDLEMODE |SYSC_HAS_SIDLEMODE | +SYSC_HAS_SOFTRESET |SYSS_HAS_RESET_STATUS ), + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART | + SIDLE_SMART_WKUP | MSTANDBY_FORCE |
MSTANDBY_NO|arch/arm/mach-omap2/omap_hwmod_44xx_data.c +56
-0+ MSTANDBY_SMART), + .sysc_fields = &omap_hwmod_sysc_type1, +}; + +static struct omap_hwmod_class omap44xx_usb_otg_hs_hwmod_class = { + .name ="usb_otg_hs" , + .sysc = &omap44xx_usb_otg_hs_sysc, +}; + +/* usb_otg_hs */ +static struct omap_hwmod_irq_info omap44xx_usb_otg_hs_irqs[] = { + { .name ="mc" , .irq =92 +OMAP44XX_IRQ_GIC_START }, + { .name ="dma" , .irq =93 +OMAP44XX_IRQ_GIC_START }, +}; + +/* usb_otg_hs master ports */ +static struct omap_hwmod_ocp_if *omap44xx_usb_otg_hs_masters[] = { + &omap44xx_usb_otg_hs__l3_main_2, +}; + +static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = { + { + .pa_start =0x4a0ab000 , + .pa_end =0x4a0ab003 , + .flags =ADDR_TYPE_RT + }, +}; + +/* l4_cfg -> usb_otg_hs */ +static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_otg_hs = { + .master = &omap44xx_l4_cfg_hwmod, + .slave = &omap44xx_usb_otg_hs_hwmod, + .clk ="l4_div_ck" , + .addr = omap44xx_usb_otg_hs_addrs, + .addr_cnt =ARRAY_SIZE (omap44xx_usb_otg_hs_addrs), + .user =OCP_USER_MPU |OCP_USER_SDMA , +}; + +/* usb_otg_hs slave ports */ +static struct omap_hwmod_ocp_if *omap44xx_usb_otg_hs_slaves[] = { + &omap44xx_l4_cfg__usb_otg_hs, +}; + +static struct omap_hwmod_opt_clk usb_otg_hs_opt_clks[] = { + { .role ="xclk" , .clk ="otg_60m_gfclk_ck" }, +}; + +static struct omap_hwmod omap44xx_usb_otg_hs_hwmod = { + .name ="usb_otg_hs" , + .class = &omap44xx_usb_otg_hs_hwmod_class, + .mpu_irqs = omap44xx_usb_otg_hs_irqs, + .mpu_irqs_cnt =ARRAY_SIZE (omap44xx_usb_otg_hs_irqs), + .main_clk ="usb_otg_hs_ick" , + .prcm = { + .omap4 = { + .clkctrl_reg =
OMAP4430_CM_L3INIT_USB_OTG_CLKCTRL,arch/arm/mach-omap2/omap_hwmod_44xx_data.c +13
-0+ }, + }, + .opt_clks = usb_otg_hs_opt_clks, + .opt_clks_cnt = ARRAY_SIZE(usb_otg_hs_opt_clks), + .slaves = omap44xx_usb_otg_hs_slaves, + .slaves_cnt = ARRAY_SIZE(omap44xx_usb_otg_hs_slaves), + .masters = omap44xx_usb_otg_hs_masters, + .masters_cnt = ARRAY_SIZE(omap44xx_usb_otg_hs_masters), + .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY, + .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430), +}; + +/* * 'wd_timer' class * 32-bit watchdog upward counter that generates a pulse on the reset
pin on
* overflow conditionarch/arm/mach-omap2/omap_hwmod_44xx_data.c +3
-0@@ -4995,6 +5087,9 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = { &omap44xx_uart3_hwmod, &omap44xx_uart4_hwmod, +/* usb_otg_hs class */ + &omap44xx_usb_otg_hs_hwmod, +/* wd_timer class */ &omap44xx_wd_timer2_hwmod,
&omap44xx_wd_timer3_hwmod,
--
1.7.0.4
PATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
In reply to Cousson, BenoitQuoted 7 lines · Benoit
Hi Felipe and Hema,
Sorry for this late review, but I have a couple of comments on this one.
Since I was planning to send usb hwmod data file to Tony directly like I did for the other drivers, I can handle the update myself if you want.
I'll change this particular patch to yours.
Signature · 1 line
balbi
PATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
Quoted 10 lines · Felipe Balbi
Quoted 7 lines · Benoit
Hi Felipe and Hema,
Sorry for this late review, but I have a couple of comments on this one.
Since I was planning to send usb hwmod data file to Tony directly like I did for the other drivers, I can handle the update myself if you want.
I'll change this particular patch to yours.
doesn't apply:
$ patch -p1 < ~/benoit.diff
patching file arch/arm/mach-omap2/omap_hwmod_44xx_data.c
Hunk #1 succeeded at 55 with fuzz 1 (offset -7 lines).
patch: **** malformed patch@line 42: omap44xx_l4_cfg__l3_main_2 = {could you base this off of v2.6.38-rc5 ?
Signature · 1 line
balbi
PATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
Quoted 12 lines · Felipe
Quoted 10 lines · Felipe Balbi
Quoted 7 lines · Benoit
Hi Felipe and Hema,
Sorry for this late review, but I have a couple of comments on this one.
Since I was planning to send usb hwmod data file to Tony directly like I did for the other drivers, I can handle the update myself if you want.
I'll change this particular patch to yours.
Quoted 8 lines
doesn't apply:
$ patch -p1< ~/benoit.diff patching file arch/arm/mach-omap2/omap_hwmod_44xx_data.c Hunk #1 succeeded at 55 with fuzz 1 (offset -7 lines). patch: **** malformed patch at line 42: omap44xx_l4_cfg__l3_main_2 = {could you base this off of v2.6.38-rc5 ?
This is what I was about to say.
You have a dependency with the for_2.6.39/omap4_hwmod_data branch in git://gitorious.org/omap-pm/linux.git.
Benoit
PATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
Quoted 20 lines · Benoit
Quoted 19 lines · Felipe
Quoted 10 lines · Felipe Balbi
Quoted 7 lines · Benoit
Hi Felipe and Hema,
Sorry for this late review, but I have a couple of comments on this one.
Since I was planning to send usb hwmod data file to Tony directly like I did for the other drivers, I can handle the update myself if you want.
I'll change this particular patch to yours.
doesn't apply:
$ patch -p1< ~/benoit.diff patching file arch/arm/mach-omap2/omap_hwmod_44xx_data.c Hunk #1 succeeded at 55 with fuzz 1 (offset -7 lines). patch: **** malformed patch at line 42: omap44xx_l4_cfg__l3_main_2 = {
Quoted 5 lines
Quoted 1 line
could you base this off of v2.6.38-rc5 ?
This is what I was about to say.
You have a dependency with the for_2.6.39/omap4_hwmod_data branch ingit://gitorious.org/omap-pm/linux.git.
I cannot have such a dependency and if you create that I can't send a pull request to Tony otherwise we will have conflicts later. Either you clear up that dependency or Tony will have to manually apply the patches I have queued. It's only 7 of them anyway, so maybe not a big deal.
Tony, what do you prefer ? Do we clear out the dependency, or you queue all the patches I have manually ??
A simple way to clear this out would be with a git rebase -i v2.6.38-rc5 and moving the MUSB HWMOD to be the first one in the series, then it should apply cleanly on my tree.
Signature · 1 line
balbi
PATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
Quoted 23 lines · Felipe
Quoted 22 lines · Benoit
Quoted 20 lines · Felipe
Quoted 10 lines · Felipe Balbi
Quoted 7 lines · Benoit
Hi Felipe and Hema,
Sorry for this late review, but I have a couple of comments on this one.
Since I was planning to send usb hwmod data file to Tony directly like I did for the other drivers, I can handle the update myself if you want.
I'll change this particular patch to yours.
doesn't apply:
$ patch -p1< ~/benoit.diff patching file arch/arm/mach-omap2/omap_hwmod_44xx_data.c Hunk #1 succeeded at 55 with fuzz 1 (offset -7 lines). patch: **** malformed patch at line 42: omap44xx_l4_cfg__l3_main_2 = {could you base this off of v2.6.38-rc5 ?
Quoted 8 lines
Quoted 3 lines
This is what I was about to say.
You have a dependency with the for_2.6.39/omap4_hwmod_data branch ingit://gitorious.org/omap-pm/linux.git.I cannot have such a dependency and if you create that I can't send a pull request to Tony otherwise we will have conflicts later. Either you clear up that dependency or Tony will have to manually apply the patches I have queued. It's only 7 of them anyway, so maybe not a big deal.
I will try to rebase that one on v2.6.38-rc5 and see if it will generate any issue during the merge with the omap4_hwmod_data series. Generally issues appears if the data are located at the same place in the file. Since the usb is between uart and wd_timer, that might work.
Benoit
Tony Lindgren
maintainerPATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
Quoted 33 lines · Cousson, Benoit
Quoted 23 lines · Felipe
Quoted 22 lines · Benoit
Quoted 20 lines · Felipe
Quoted 10 lines · Felipe Balbi
Quoted 7 lines · Benoit
Hi Felipe and Hema,
Sorry for this late review, but I have a couple of comments on this one.
Since I was planning to send usb hwmod data file to Tony directly like I did for the other drivers, I can handle the update myself if you want.
I'll change this particular patch to yours.
doesn't apply:
$ patch -p1< ~/benoit.diff patching file arch/arm/mach-omap2/omap_hwmod_44xx_data.c Hunk #1 succeeded at 55 with fuzz 1 (offset -7 lines). patch: **** malformed patch at line 42: omap44xx_l4_cfg__l3_main_2 = {could you base this off of v2.6.38-rc5 ?
Quoted 8 lines
Quoted 3 lines
This is what I was about to say.
You have a dependency with the for_2.6.39/omap4_hwmod_data branch ingit://gitorious.org/omap-pm/linux.git.I cannot have such a dependency and if you create that I can't send a pull request to Tony otherwise we will have conflicts later. Either you clear up that dependency or Tony will have to manually apply the patches I have queued. It's only 7 of them anyway, so maybe not a big deal.
Quoted 5 lines
I will try to rebase that one on v2.6.38-rc5 and see if it will generate any issue during the merge with the
omap4_hwmod_dataseries. Generally issues appears if the data are located at the same place in the file. Since the usb is between uart andwd_timer, that might work.
Maybe no need to rebase, I'll apply Benoit's series first into omap-for-linus, then let's applying the other hwmod related patches should be trivial.
Regards,
Tony
PATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
Quoted 40 lines · Tony Lindgren
Quoted 33 lines · Cousson, Benoit
Quoted 23 lines · Felipe
Quoted 22 lines · Benoit
Quoted 20 lines · Felipe
Quoted 10 lines · Felipe Balbi
Quoted 7 lines · Benoit
Hi Felipe and Hema,
Sorry for this late review, but I have a couple of comments on this one.
Since I was planning to send usb hwmod data file to Tony directly like I did for the other drivers, I can handle the update myself if you want.
I'll change this particular patch to yours.
doesn't apply:
$ patch -p1< ~/benoit.diff patching file arch/arm/mach-omap2/omap_hwmod_44xx_data.c Hunk #1 succeeded at 55 with fuzz 1 (offset -7 lines). patch: **** malformed patch at line 42: omap44xx_l4_cfg__l3_main_2 = {could you base this off of v2.6.38-rc5 ?
Quoted 8 lines
Quoted 3 lines
This is what I was about to say.
You have a dependency with the for_2.6.39/omap4_hwmod_data branch ingit://gitorious.org/omap-pm/linux.git.I cannot have such a dependency and if you create that I can't send a pull request to Tony otherwise we will have conflicts later. Either you clear up that dependency or Tony will have to manually apply the patches I have queued. It's only 7 of them anyway, so maybe not a big deal.
Quoted 5 lines
I will try to rebase that one on v2.6.38-rc5 and see if it will generate any issue during the merge with the
omap4_hwmod_dataseries. Generally issues appears if the data are located at the same place in the file. Since the usb is between uart andwd_timer, that might work.
Quoted 3 lines
Maybe no need to rebase, I'll apply Benoit's series first into omap-for-linus, then let's applying the other hwmod related patches should be trivial.
So I can drop the omap4 HWMOD part from my branch ?
Signature · 1 line
balbi
Tony Lindgren
maintainerPATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
Quoted 7 lines · Felipe Balbi
Quoted 4 lines · Tony Lindgren
Maybe no need to rebase, I'll apply Benoit's series first into omap-for-linus, then let's applying the other hwmod related patches should be trivial.
So I can drop the omap4 HWMOD part from my branch ?
Yeh assuming Benoit's data is correct.
Tony
PATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
Quoted 10 lines · Tony Lindgren
Quoted 7 lines · Felipe Balbi
Quoted 4 lines · Tony Lindgren
Maybe no need to rebase, I'll apply Benoit's series first into omap-for-linus, then let's applying the other hwmod related patches should be trivial.
So I can drop the omap4 HWMOD part from my branch ?
Yeh assuming Benoit's data is correct.
Of course, it is :-)
Then I will add USB in my series.
Benoit
PATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
Quoted 8 lines · Benoit
Quoted 7 lines · Tony Lindgren
Quoted 6 lines · Felipe Balbi
Quoted 4 lines · Tony Lindgren
Maybe no need to rebase, I'll apply Benoit's series first into omap-for-linus, then let's applying the other hwmod related patches should be trivial.
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
So I can drop the omap4 HWMOD part from my branch ?
Yeh assuming Benoit's data is correct.
Of course, it is :-)
Then I will add USB in my series.
Cool, my for-tony branch has been updated without OMAP4 HWMOD data.
Signature · 1 line
balbi
PATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
In reply to Cousson, BenoitQuoted 8 lines · Benoit
Quoted 7 lines · Tony Lindgren
Quoted 6 lines · Felipe Balbi
Quoted 4 lines · Tony Lindgren
Maybe no need to rebase, I'll apply Benoit's series first into omap-for-linus, then let's applying the other hwmod related patches should be trivial.
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
So I can drop the omap4 HWMOD part from my branch ?
Yeh assuming Benoit's data is correct.
Of course, it is :-)
Then I will add USB in my series.
BTW, which branch should I use from your tree to test ?
Signature · 1 line
balbi
PATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
Quoted 11 lines · Felipe
Quoted 10 lines · Benoit
Quoted 9 lines · Tony Lindgren
Quoted 7 lines · Felipe Balbi
Quoted 4 lines · Tony Lindgren
Maybe no need to rebase, I'll apply Benoit's series first into omap-for-linus, then let's applying the other hwmod related patches should be trivial.
So I can drop the omap4 HWMOD part from my branch ?
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
Yeh assuming Benoit's data is correct.
Of course, it is :-)
Then I will add USB in my series.
BTW, which branch should I use from your tree to test ?
I'll put that in the refresh version of the branch I have done for Tony. I messed up the McSPI changelog... and Tony caught me :-)
I'll push that in 5 minutes.
Benoit
PATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
Quoted 16 lines · Benoit
Quoted 15 lines · Felipe
Quoted 14 lines · Benoit
Quoted 10 lines · Tony Lindgren
Quoted 7 lines · Felipe Balbi
Quoted 4 lines · Tony Lindgren
Maybe no need to rebase, I'll apply Benoit's series first into omap-for-linus, then let's applying the other hwmod related patches should be trivial.
So I can drop the omap4 HWMOD part from my branch ?
Yeh assuming Benoit's data is correct.
Of course, it is :-)
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
Then I will add USB in my series.
BTW, which branch should I use from your tree to test ?
I'll put that in the refresh version of the branch I have done for Tony. I messed up the McSPI changelog... and Tony caught me :-)
I'll push that in 5 minutes.
cool, let me know
Signature · 1 line
balbi
PATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
Quoted 19 lines · Felipe
Quoted 18 lines · Benoit
Quoted 17 lines · Felipe
Quoted 15 lines · Benoit
Quoted 10 lines · Tony Lindgren
Quoted 7 lines · Felipe Balbi
Quoted 4 lines · Tony Lindgren
Maybe no need to rebase, I'll apply Benoit's series first into omap-for-linus, then let's applying the other hwmod related patches should be trivial.
So I can drop the omap4 HWMOD part from my branch ?
Yeh assuming Benoit's data is correct.
Of course, it is :-)
Then I will add USB in my series.
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
BTW, which branch should I use from your tree to test ?
I'll put that in the refresh version of the branch I have done for Tony. I messed up the McSPI changelog... and Tony caught me :-)
I'll push that in 5 minutes.
cool, let me know
Done, boot tested, and that does remove the warning about the missing opt clock you had with the previous data.
git://gitorious.org/omap-pm/linux.git for_2.6.39/omap4_hwmod_data
Just let me know if it does break anything else.
Thanks,
Benoit
PATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
Quoted 27 lines · Benoit
Quoted 26 lines · Felipe
Quoted 24 lines · Benoit
Quoted 11 lines · Felipe
Quoted 10 lines · Benoit
Quoted 9 lines · Tony Lindgren
Quoted 7 lines · Felipe Balbi
Quoted 4 lines · Tony Lindgren
Maybe no need to rebase, I'll apply Benoit's series first into omap-for-linus, then let's applying the other hwmod related patches should be trivial.
So I can drop the omap4 HWMOD part from my branch ?
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
Yeh assuming Benoit's data is correct.
Of course, it is :-)
Then I will add USB in my series.
BTW, which branch should I use from your tree to test ?
I'll put that in the refresh version of the branch I have done for Tony. I messed up the McSPI changelog... and Tony caught me :-)
I'll push that in 5 minutes.
Quoted 8 lines
Quoted 1 line
cool, let me know
Done, boot tested, and that does remove the warning about the missing opt clock you had with the previous data.
git://gitorious.org/omap-pm/linux.gitfor_2.6.39/omap4_hwmod_dataJust let me know if it does break anything else.
Ok, pulling ;-)
Signature · 1 line
balbi
PATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
Quoted 30 lines · Felipe Balbi
Quoted 29 lines · Benoit
Quoted 27 lines · Felipe
Quoted 16 lines · Benoit
Quoted 15 lines · Felipe
Quoted 14 lines · Benoit
Quoted 10 lines · Tony Lindgren
Quoted 7 lines · Felipe Balbi
Quoted 4 lines · Tony Lindgren
Maybe no need to rebase, I'll apply Benoit's series first into omap-for-linus, then let's applying the other hwmod related patches should be trivial.
So I can drop the omap4 HWMOD part from my branch ?
Yeh assuming Benoit's data is correct.
Of course, it is :-)
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
Then I will add USB in my series.
BTW, which branch should I use from your tree to test ?
I'll put that in the refresh version of the branch I have done for Tony. I messed up the McSPI changelog... and Tony caught me :-)
I'll push that in 5 minutes.
cool, let me know
Quoted 8 lines
Quoted 6 lines
Done, boot tested, and that does remove the warning about the missing opt clock you had with the previous data.
git://gitorious.org/omap-pm/linux.gitfor_2.6.39/omap4_hwmod_dataJust let me know if it does break anything else.
Ok, pulling ;-)
Just tested, all good ;-) Tomorrow I'll test more and send my pull request.
Signature · 1 line
balbi
Tony Lindgren
maintainerPATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
In reply to Cousson, BenoitQuoted 7 lines · Cousson, Benoit
Done, boot tested, and that does remove the warning about the missing opt clock you had with the previous data.
git://gitorious.org/omap-pm/linux.gitfor_2.6.39/omap4_hwmod_dataJust let me know if it does break anything else.
Pulled into omap-for-linus. Also now merged are the devel-hwspinlock and devel-mcspi branches.
Tony
PATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
Quoted 11 lines · Tony Lindgren
Quoted 7 lines · Cousson, Benoit
Done, boot tested, and that does remove the warning about the missing opt clock you had with the previous data.
git://gitorious.org/omap-pm/linux.gitfor_2.6.39/omap4_hwmod_dataJust let me know if it does break anything else.
Pulled into omap-for-linus. Also now merged are the devel-hwspinlock and devel-mcspi branches.
Ok good. Tomorrow I'll send you a proper pull request for my part, will leave testusb running over night.
Signature · 1 line
balbi
Tony Lindgren
maintainerPATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
Quoted 8 lines · Felipe Balbi
Quoted 7 lines · Tony Lindgren
Quoted 6 lines · Cousson, Benoit
Done, boot tested, and that does remove the warning about the missing opt clock you had with the previous data.
git://gitorious.org/omap-pm/linux.gitfor_2.6.39/omap4_hwmod_data
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
Just let me know if it does break anything else.
Pulled into omap-for-linus. Also now merged are the devel-hwspinlock and devel-mcspi branches.
Ok good. Tomorrow I'll send you a proper pull request for my part, will leave testusb running over night.
OK sounds good to me.
Tony
PATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
In reply to Tony LindgrenHi Tony
Quoted 11 lines · Tony Lindgren
Quoted 7 lines · Cousson, Benoit
Done, boot tested, and that does remove the warning about the missing opt clock you had with the previous data.
git://gitorious.org/omap-pm/linux.gitfor_2.6.39/omap4_hwmod_dataJust let me know if it does break anything else.
Pulled into omap-for-linus. Also now merged are the devel-hwspinlock and devel-mcspi branches.
McSPI OMAP4 hwmod data are missing a couple of flags that break the boot for the moment.
Govindraj should rebase on the omap4_hwmod_data branch and add the missing rev and dev_attr for the McSPI.
Unfortunately, even with that patch omap-for-linus boot hangs after the following trace:
[ 0.875091] omap_device: omap2_mcspi.1: new worst case activate latency 0: 30517 [ 0.886657] usbcore: registered new interface driver usbfs [ 0.892822] usbcore: registered new interface driver hub [ 0.898681] usbcore: registered new device driver usb [ 0.904815] omap_i2c omap_i2c.1: bus 1 rev4.0 at 400 kHz
Regards,
Benoit
PATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
Hi all,
Quoted 17 lines · Benoit
Quoted 11 lines · Tony Lindgren
Quoted 7 lines · Cousson, Benoit
Done, boot tested, and that does remove the warning about the missing opt clock you had with the previous data.
git://gitorious.org/omap-pm/linux.gitfor_2.6.39/omap4_hwmod_dataJust let me know if it does break anything else.
Pulled into omap-for-linus. Also now merged are the devel-hwspinlock and devel-mcspi branches.
McSPI OMAP4 hwmod data are missing a couple of flags that break the boot for the moment.
Govindraj should rebase on the
omap4_hwmod_databranch and add the missing rev anddev_attrfor the McSPI.
Quoted 7 lines
Unfortunately, even with that patch omap-for-linus boot hangs after the following trace:
[ 0.875091] omap_device: omap2_mcspi.1: new worst case activate latency 0: 30517 [ 0.886657] usbcore: registered new interface driver usbfs [ 0.892822] usbcore: registered new interface driver hub [ 0.898681] usbcore: registered new device driver usb [ 0.904815] omap_i2c omap_i2c.1: bus 1 rev4.0 at 400 kHz
I tested your branch merged with mine and it was working fine. What else is on omap-for-linus ? There are only 28 patches on that branch, a bisect would be quick ?
Signature · 1 line
balbi
PATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
Hi Felipe,
Quoted 28 lines · Felipe
Hi all,
Quoted 17 lines · Benoit
Quoted 11 lines · Tony Lindgren
Quoted 7 lines · Cousson, Benoit
Done, boot tested, and that does remove the warning about the missing opt clock you had with the previous data.
git://gitorious.org/omap-pm/linux.gitfor_2.6.39/omap4_hwmod_dataJust let me know if it does break anything else.
Pulled into omap-for-linus. Also now merged are the devel-hwspinlock and devel-mcspi branches.
McSPI OMAP4 hwmod data are missing a couple of flags that break the boot for the moment.
Govindraj should rebase on the
omap4_hwmod_databranch and add the missing rev anddev_attrfor the McSPI.Quoted 7 lines
Unfortunately, even with that patch omap-for-linus boot hangs after the following trace:
[ 0.875091] omap_device: omap2_mcspi.1: new worst case activate latency 0: 30517 [ 0.886657] usbcore: registered new interface driver usbfs [ 0.892822] usbcore: registered new interface driver hub [ 0.898681] usbcore: registered new device driver usb [ 0.904815] omap_i2c omap_i2c.1: bus 1 rev4.0 at 400 kHz
Quoted 3 lines
I tested your branch merged with mine and it was working fine. What else is on omap-for-linus ? There are only 28 patches on that branch, a bisect would be quick ?
This is what I observed too. There are some early stuff in it + some TI816X... I do not know what is going wrong. Please note that there are a little bit more (47) stuff added but they are below the -rc5 tag... The bisect will be longer :-)
+ [HEAD^2] OMAP: runtime: McSPI driver runtime conversion
+ [HEAD^2^] OMAP: devices: Modify McSPI device to adapt to hwmod framework
+ [HEAD^2~2] OMAP3: hwmod data: Add McSPI
+ [HEAD^2~3] OMAP2430: hwmod data: Add McSPI
+ [HEAD^2~4] OMAP2420: hwmod data: Add McSPI
+ [HEAD^] omap: add hwspinlock device
+ [HEAD~2] drivers: hwspinlock: add OMAP implementation
+ [HEAD~3] drivers: hwspinlock: add framework
+ [HEAD~4^2] OMAP4: hwmod data: Add USBOTG
+ [HEAD~4^2^] OMAP4: hwmod data: Add AESS, McPDM, bandgap, counter_32k, MMC, KBD, ISS & IPU
+ [HEAD~4^2~2] OMAP4: hwmod data: Add McBSP
+ [HEAD~4^2~3] OMAP4: hwmod data: Add DMIC
+ [HEAD~4^2~4] OMAP4: hwmod data: Add mailbox
+ [HEAD~4^2~5] OMAP4: hwmod data: Add DSS, DISPC, DSI1&2, RFBI, HDMI and VENC
+ [HEAD~4^2~6] OMAP4: hwmod data: Add timer
+ [HEAD~4^2~7] OMAP4: hwmod data: Add McSPI
+ [HEAD~4^2~8] OMAP4: hwmod data: Add hwspinlock
+ [HEAD~5^3] TI816X: Update to use init_early
+ [HEAD~5^3^] TI816X: Add low level debug support
+ [HEAD~5^3~2] TI816X: Create board support and enable build for TI816X EVM
+ [HEAD~5^3~3] TI816X: Update common OMAP machine specific sources
+ [HEAD~5^3~4] TI816X: Update common omap platform files
+ [HEAD~5^3~5] omap: hwmod: Populate _mpu_rt_va later on in omap_hwmod_late_init
+ [HEAD~5^3~6] omap2+: Fix omap_serial_early_init to work with init_early hook
+ [HEAD~5^3~7] omap2+: Make omap_hwmod_late_init into core_initcall
+ [HEAD~5^3~8] ARM: OMAP2: use early init hook
+ [HEAD~5^2] omap: McBSP: Remove unused audio macros in mcbsp.h
+ [HEAD~5^2^] wip: fix section mismatches in omap1_defconfig
+ [HEAD~5^2~2] ARM: omap: move omap_board_config_kernel to .init.data
+ [HEAD~5^2~3] ARM: omap: move omap_get_config et al. to .init.text
+ [HEAD~5^2~4] ARM: omap1/nokia770: mark some functions __init
+ [HEAD~5^2~5] arm: mach-omap1: board-voiceblue: add missing include
+ [HEAD~5^2~6] ARM: OMAP: Allow platforms to hook reset cleanly
+ [HEAD~5^2~7] arm: mach-omap1: board-h3: make nand_platdata static
+ [HEAD~5^2~8] arm: mach-omap1: board-htcherald: make htcpld_chips and htcpld_pfdata static
+ [HEAD~5^2~9] arm: mach-omap1: board-innovator: make innovator_mmc_init() static
+ [HEAD~5^2~10] arm: mach-omap1: board-h2: make h2_nand_platdata static
+ [HEAD~5^2~11] arm: plat-omap: dma: make omap_dma_in_1510_mode() static
+ [HEAD~5^2~12] arm: omap2: irq: fix compile warning:
+ [HEAD~5^2~13] arm: omap1: fix a bunch of section mismatches
+ [HEAD~5^2~14] arm: omap1: fix compile warnings
+ [HEAD~5^2~15] arm: omap1: fix compile warning
+ [HEAD~5^2~16] arm: omap: i2c: fix compile warning
+ [HEAD~5^2~17] omap: Start using CONFIG_SOC_OMAP
++ [85e2efb] Linux 2.6.38-rc5
Regards,
Benoit
PATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
In reply to Felipe BalbiQuoted 28 lines · Felipe
Hi all,
Quoted 17 lines · Benoit
Quoted 11 lines · Tony Lindgren
Quoted 7 lines · Cousson, Benoit
Done, boot tested, and that does remove the warning about the missing opt clock you had with the previous data.
git://gitorious.org/omap-pm/linux.gitfor_2.6.39/omap4_hwmod_dataJust let me know if it does break anything else.
Pulled into omap-for-linus. Also now merged are the devel-hwspinlock and devel-mcspi branches.
McSPI OMAP4 hwmod data are missing a couple of flags that break the boot for the moment.
Govindraj should rebase on the
omap4_hwmod_databranch and add the missing rev anddev_attrfor the McSPI.Quoted 7 lines
Unfortunately, even with that patch omap-for-linus boot hangs after the following trace:
[ 0.875091] omap_device: omap2_mcspi.1: new worst case activate latency 0: 30517 [ 0.886657] usbcore: registered new interface driver usbfs [ 0.892822] usbcore: registered new interface driver hub [ 0.898681] usbcore: registered new device driver usb [ 0.904815] omap_i2c omap_i2c.1: bus 1 rev4.0 at 400 kHz
Quoted 3 lines
I tested your branch merged with mine and it was working fine. What else is on omap-for-linus ? There are only 28 patches on that branch, a bisect would be quick ?
This patch is at least fixing the McSPI crash. I still don't have a clue about the final hang :-(
Benoit
---
From b2190f0d339c9d843eb5e370d0db8b7090fbcfab Mon Sep 17 00:00:00 2001
From: Benoit Cousson <[email protected]>
Date: Fri, 18 Feb 2011 14:01:06 +0100
Subject: [PATCH] OMAP4: hwmod data: Add rev and dev_attr fields in McSPI
- Add a rev attribute to identify various McSPI IP version.
- Add a dev_attr structure to provide the number of chipselect supported by the instance.
--- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 26 ++++++++++++++++++++++++++ 1 files changed, 26 insertions(+), 0 deletions(-)
(quoted diff) +0 -0
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 84e795c..182aa79 100644
arch/arm/mach-omap2/omap_hwmod_44xx_data.c +1 -0
@@ -24,6 +24,7 @@#include <plat/cpu.h> #include <plat/gpio.h> #include <plat/dma.h> +#include <plat/mcspi.h> #include "omap_hwmod_common_data.h"
@@ -3114,6 +3115,7 @@ static struct omap_hwmod_class_sysconfig
omap44xx_mcspi_sysc = {
static struct omap_hwmod_class omap44xx_mcspi_hwmod_class = {
.name = "mcspi",
.sysc = &omap44xx_mcspi_sysc,
+ .rev = OMAP4_MCSPI_REV,
};
/* mcspi1 */
@@ -3156,6 +3158,11 @@ static struct omap_hwmod_ocp_if *omap44xx_mcspi1_slaves[] = {
&omap44xx_l4_per__mcspi1,
};
+/* mcspi1 dev_attr */
+static struct omap2_mcspi_dev_attr mcspi1_dev_attr = {
+ .num_chipselect = 4,
+};
+
static struct omap_hwmod omap44xx_mcspi1_hwmod = {
.name = "mcspi1",
.class = &omap44xx_mcspi_hwmod_class,
@@ -3169,6 +3176,7 @@ static struct omap_hwmod omap44xx_mcspi1_hwmod = {
.clkctrl_reg = OMAP4430_CM_L4PER_MCSPI1_CLKCTRL,
},
},
+ .dev_attr = &mcspi1_dev_attr,
.slaves = omap44xx_mcspi1_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_mcspi1_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
@@ -3210,6 +3218,11 @@ static struct omap_hwmod_ocp_if *omap44xx_mcspi2_slaves[] = {
&omap44xx_l4_per__mcspi2,
};
+/* mcspi2 dev_attr */
+static struct omap2_mcspi_dev_attr mcspi2_dev_attr = {
+ .num_chipselect = 2,
+};
+
static struct omap_hwmod omap44xx_mcspi2_hwmod = {
.name = "mcspi2",
.class = &omap44xx_mcspi_hwmod_class,
@@ -3223,6 +3236,7 @@ static struct omap_hwmod omap44xx_mcspi2_hwmod = {
.clkctrl_reg = OMAP4430_CM_L4PER_MCSPI2_CLKCTRL,
},
},
+ .dev_attr = &mcspi2_dev_attr,
.slaves = omap44xx_mcspi2_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_mcspi2_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
@@ -3264,6 +3278,11 @@ static struct omap_hwmod_ocp_if *omap44xx_mcspi3_slaves[] = {
&omap44xx_l4_per__mcspi3,
};
+/* mcspi3 dev_attr */
+static struct omap2_mcspi_dev_attr mcspi3_dev_attr = {
+ .num_chipselect = 2,
+};
+
static struct omap_hwmod omap44xx_mcspi3_hwmod = {
.name = "mcspi3",
.class = &omap44xx_mcspi_hwmod_class,
@@ -3277,6 +3296,7 @@ static struct omap_hwmod omap44xx_mcspi3_hwmod = {
.clkctrl_reg = OMAP4430_CM_L4PER_MCSPI3_CLKCTRL,
},
},
+ .dev_attr = &mcspi3_dev_attr,
.slaves = omap44xx_mcspi3_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_mcspi3_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
@@ -3316,6 +3336,11 @@ static struct omap_hwmod_ocp_if *omap44xx_mcspi4_slaves[] = {
&omap44xx_l4_per__mcspi4,
};
+/* mcspi4 dev_attr */
+static struct omap2_mcspi_dev_attr mcspi4_dev_attr = {
+ .num_chipselect = 1,
+};
+
static struct omap_hwmod omap44xx_mcspi4_hwmod = {
.name = "mcspi4",
.class = &omap44xx_mcspi_hwmod_class,
@@ -3329,6 +3354,7 @@ static struct omap_hwmod omap44xx_mcspi4_hwmod = {
.clkctrl_reg = OMAP4430_CM_L4PER_MCSPI4_CLKCTRL,
},
},
+ .dev_attr = &mcspi4_dev_attr,
.slaves = omap44xx_mcspi4_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_mcspi4_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
Signature · 1 line
1.7.0.4
Tony Lindgren
maintainerPATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
Quoted 9 lines · Cousson, Benoit
---
Fromb2190f0d339c9d843eb5e370d0db8b7090fbcfabMon Sep 17 00:00:00 2001
From: Benoit Cousson <[email protected]>
Date: Fri, 18 Feb 2011 14:01:06 +0100
Subject: [PATCH] OMAP4: hwmod data: Add rev anddev_attrfields in McSPI- Add a rev attribute to identify various McSPI IP version.
- Add adev_attrstructure to provide the number of chipselect supported by the instance.
Looks like one seems to be wrapped and does not apply even after unwapping..
Tony
PATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
Quoted 7 lines · Tony Lindgren
Quoted 6 lines · Cousson, Benoit
---
Fromb2190f0d339c9d843eb5e370d0db8b7090fbcfabMon Sep 17 00:00:00 2001
From: Benoit Cousson<[email protected]>
Date: Fri, 18 Feb 2011 14:01:06 +0100
Subject: [PATCH] OMAP4: hwmod data: Add rev anddev_attrfields in McSPI
Quoted 5 lines
Quoted 3 lines
- Add a rev attribute to identify various McSPI IP version.
- Add adev_attrstructure to provide the number of chipselect supported by the instance.Looks like one seems to be wrapped and does not apply even after unwapping..
#$*%&!@ Thunderbird...
Here is the same one without the "enable word wrap" and attached as well just in case.
It should apply on your omap-for-linus branch at commit df7ffd3.
Regards,
Benoit
---
Tony Lindgren
maintainerPATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
Quoted 8 lines · Cousson, Benoit
Quoted 7 lines · Tony Lindgren
Quoted 6 lines · Cousson, Benoit
---
Fromb2190f0d339c9d843eb5e370d0db8b7090fbcfabMon Sep 17 00:00:00 2001
From: Benoit Cousson<[email protected]>
Date: Fri, 18 Feb 2011 14:01:06 +0100
Subject: [PATCH] OMAP4: hwmod data: Add rev anddev_attrfields in McSPI
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
- Add a rev attribute to identify various McSPI IP version.
- Add adev_attrstructure to provide the number of chipselect supported by the instance.Looks like one seems to be wrapped and does not apply even after unwapping..
#$*%&!@ Thunderbird...
:) The earlier one had double spaces in the beginning of each line in addition to the line wrapping..
Quoted 3 lines
Here is the same one without the "enable word wrap" and attached as well just in case.
It should apply on your omap-for-linus branch at commit df7ffd3.
Thanks, I'll apply it to omap-for-linus. The omap4 hang seems to be caused by the timer patch, the following fixes it. How do you want to deal with fixing this issue?
Tony
arch/arm/mach-omap2/omap_hwmod_44xx_data.c +1 -1
@@ -5094,7 +5094,7 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = { &omap44xx_spinlock_hwmod,/* timer class */ - &omap44xx_timer1_hwmod, +/* &omap44xx_timer1_hwmod, */ &omap44xx_timer2_hwmod, &omap44xx_timer3_hwmod, &omap44xx_timer4_hwmod,
PATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
Quoted 13 lines · Tony Lindgren
Quoted 12 lines · Cousson, Benoit
Quoted 11 lines · Tony Lindgren
Quoted 9 lines · Cousson, Benoit
---
Fromb2190f0d339c9d843eb5e370d0db8b7090fbcfabMon Sep 17 00:00:00 2001
From: Benoit Cousson<[email protected]>
Date: Fri, 18 Feb 2011 14:01:06 +0100
Subject: [PATCH] OMAP4: hwmod data: Add rev anddev_attrfields in McSPI- Add a rev attribute to identify various McSPI IP version.
- Add adev_attrstructure to provide the number of chipselect supported by the instance.
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
Looks like one seems to be wrapped and does not apply even after unwapping..
#$*%&!@ Thunderbird...
:) The earlier one had double spaces in the beginning of each line in addition to the line wrapping..
...The Thunderbird wrapping option is more powerful than expected...
Quoted 7 lines
Quoted 3 lines
Here is the same one without the "enable word wrap" and attached as well just in case.
It should apply on your omap-for-linus branch at commit df7ffd3.
Thanks, I'll apply it to omap-for-linus. The omap4 hang seems to be caused by the timer patch, the following fixes it. How do you want to deal with fixing this issue?
I guess it is due to the early_init change?
I have some concern bypassing hwmod to handle system timer. The idea, before the introduction of the early_init, was to use hwmod for early initialization as well including timers. It will become a little bit harder now :-(
I still didn't fully understand the rational behind that early_init for timer BTW.
Meanwhile, the following will just prevent the fmwk to reset and idle the timer during hwmod_init.
Regards,
Benoit
arch/arm/mach-omap2/omap_hwmod_44xx_data.c +0 -0
@@ -3989,6 +3989,7 @@ static struct omap_hwmod_ocp_if
*omap44xx_timer1_slaves[] = {
static struct omap_hwmod omap44xx_timer1_hwmod = {
.name = "timer1",
.class = &omap44xx_timer_1ms_hwmod_class,
+ .flags = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
.mpu_irqs = omap44xx_timer1_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_timer1_irqs),
.main_clk = "timer1_fck",
Tony Lindgren
maintainerPATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
Quoted 7 lines · Cousson, Benoit
Quoted 4 lines · Tony Lindgren
Thanks, I'll apply it to omap-for-linus. The omap4 hang seems to be caused by the timer patch, the following fixes it. How do you want to deal with fixing this issue?
I guess it is due to the
early_initchange?
Yes that seems to be the case.
Quoted 4 lines
I have some concern bypassing hwmod to handle system timer. The idea, before the introduction of the
early_init, was to use hwmod for early initialization as well including timers. It will become a little bit harder now :-(
If we get rid of the system timer dependency to hwmod we can pretty much initialize everything later on and don't need to use early_init stuff at all.
Quoted 2 lines
I still didn't fully understand the rational behind that
early_initfor timer BTW.
I'm currently thinking that we should just have omap[234]_init_timer functions that do not depend on hwmod at all.
Quoted 2 lines
Meanwhile, the following will just prevent the fmwk to reset and idle the timer during
hwmod_init.
That seems like a good to fix for now until the hwmod timer changes are sorted out.
Tony
Quoted 12 lines
arch/arm/mach-omap2/omap_hwmod_44xx_data.c +1
-0@@ -3989,6 +3989,7 @@ static struct omap_hwmod_ocp_if *omap44xx_timer1_slaves[] = {static struct omap_hwmod omap44xx_timer1_hwmod = { .name ="timer1" , .class = &omap44xx_timer_1ms_hwmod_class, + .flags =HWMOD_INIT_NO_IDLE |HWMOD_INIT_NO_RESET , .mpu_irqs = omap44xx_timer1_irqs, .mpu_irqs_cnt =ARRAY_SIZE (omap44xx_timer1_irqs),.main_clk = "
timer1_fck",
PATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
In reply to Cousson, BenoitQuoted 2 lines · Benoit
I still didn't fully understand the rational behind that
early_initfor timer BTW.
To ensure that sched_clock() is setup and running before its first use.
Paul Walmsley
maintainerPATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
In reply to Cousson, BenoitQuoted 5 lines · Benoit
Meanwhile, the following will just prevent the fmwk to reset and idle the timer during
hwmod_init.Regards,
Benoit
Looks okay to me for the time being.
Quoted 12 lines
arch/arm/mach-omap2/omap_hwmod_44xx_data.c +1
-0@@ -3989,6 +3989,7 @@ static struct omap_hwmod_ocp_if *omap44xx_timer1_slaves[] = {static struct omap_hwmod omap44xx_timer1_hwmod = { .name ="timer1" , .class = &omap44xx_timer_1ms_hwmod_class, + .flags =HWMOD_INIT_NO_IDLE |HWMOD_INIT_NO_RESET , .mpu_irqs = omap44xx_timer1_irqs, .mpu_irqs_cnt =ARRAY_SIZE (omap44xx_timer1_irqs),
Quoted 2 lines
.main_clk = "
timer1_fck",
- Paul
Tony Lindgren
maintainerPATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
In reply to Felipe BalbiQuoted 3 lines · Felipe Balbi
Tony, what do you prefer ? Do we clear out the dependency, or you queue all the patches I have manually ??
Let's apply Benoit's hwmod data patches first into omap-for-linus, then rebasing other patches to that should be trivial and I can pull in your patches.
Regards,
Tony
PATCH 6/7 OMAP4430: hwmod data: Adding USBOTG
Quoted 8 lines · Tony Lindgren
Quoted 3 lines · Felipe Balbi
Tony, what do you prefer ? Do we clear out the dependency, or you queue all the patches I have manually ??
Let's apply Benoit's hwmod data patches first into omap-for-linus, then rebasing other patches to that should be trivial and I can pull in your patches.
ok, let me know and I'll rebase on top of omap-for-linus.
Signature · 1 line
balbi
PATCH 7/7 OMAP2+: musb: hwmod adaptation for musb registration
In reply to Felipe BalbiFrom: Hema HK <[email protected]>
Using omap_device_build API instead of platform_device_register for OMAP2430,OMAP3xxx, OMAP4430 and AM35x musb device registration. The device specific resources defined in centralized database will be used.
--- arch/arm/mach-omap2/usb-musb.c | 84 +++++++++++++++++++++------------------- 1 files changed, 44 insertions(+), 40 deletions(-)
arch/arm/mach-omap2/usb-musb.c +44 -40
@@ -30,6 +30,7 @@#include <mach/irqs.h> #include <mach/am35xx.h> #include <plat/usb.h> +#include <plat/omap_device.h> #include "control.h" #include "mux.h"
@@ -127,22 +128,6 @@ static void am35x_musb_set_mode(u8 musb_mode)omap_ctrl_writel (devconf2,AM35XX_CONTROL_DEVCONF2 ); } -static struct resource musb_resources[] = { - [0 ] = {/* start and end set dynamically */ - .flags =IORESOURCE_MEM , - }, - [1 ] = {/* general IRQ */ - .start =INT_243X_HS_USB_MC , - .flags =IORESOURCE_IRQ , - .name ="mc" , - }, - [2 ] = {/* DMA IRQ */ - .start =INT_243X_HS_USB_DMA , - .flags =IORESOURCE_IRQ , - .name ="dma" , - }, -}; -static struct musb_hdrc_config musb_config = { .multipoint =1 , .dyn_fifo =1 ,
@@ -170,16 +155,12 @@ static struct musb_hdrc_platform_data musb_plat = {static u64 musb_dmamask =DMA_BIT_MASK (32 ); -static struct platform_device musb_device = { - .name ="musb-omap2430" , - .id =-1 , - .dev = { - .dma_mask = &musb_dmamask, - .coherent_dma_mask =DMA_BIT_MASK (32 ), - .platform_data = &musb_plat, +static struct omap_device_pm_latency omap_musb_latency[] = { + { + .deactivate_func = omap_device_idle_hwmods, + .activate_func = omap_device_enable_hwmods, + .flags =OMAP_DEVICE_LATENCY_AUTO_ADJUST , }, - .num_resources =ARRAY_SIZE (musb_resources), - .resource = musb_resources, };static void usb_musb_mux_init (struct omap_musb_board_data *board_data)
@@ -219,28 +200,24 @@ static void usb_musb_mux_init(struct omap_musb_board_data *board_data)break ; } } +void __init usb_musb_init (struct omap_musb_board_data *board_data) { -if (cpu_is_omap243x ()) { - musb_resources[0 ].start =OMAP243X_HS_BASE ; - }else if (cpu_is_omap3517 () ||cpu_is_omap3505 ()) { - musb_device.name ="musb-am35x" ; - musb_resources[0 ].start =AM35XX_IPSS_USBOTGSS_BASE ; - musb_resources[1 ].start =INT_35XX_USBOTG_IRQ ; +struct omap_hwmod *oh; +struct omap_device *od; +struct platform_device *pdev; +struct device *dev; +int bus_id =-1 ; +const char *oh_name, *name; + +if (cpu_is_omap3517 () ||cpu_is_omap3505 ()) { board_data->set_phy_power = am35x_musb_phy_power; board_data->clear_irq = am35x_musb_clear_irq; board_data->set_mode = am35x_musb_set_mode; board_data->reset = am35x_musb_reset; - }else if (cpu_is_omap34xx ()) { - musb_resources[0 ].start =OMAP34XX_HSUSB_OTG_BASE ; }else if (cpu_is_omap44xx ()) { - musb_resources[0 ].start =OMAP44XX_HSUSB_OTG_BASE ; - musb_resources[1 ].start =OMAP44XX_IRQ_HS_USB_MC_N ; - musb_resources[2 ].start =OMAP44XX_IRQ_HS_USB_DMA_N ; -usb_musb_mux_init (board_data); } - musb_resources[0 ].end = musb_resources[0 ].start +SZ_4K -1 ;/* * REVISIT: This line can be removed once all the platforms using
@@ -252,8 +229,35 @@ void __init usb_musb_init(struct omap_musb_board_data *board_data) musb_plat.mode = board_data->mode; musb_plat.extvbus = board_data->extvbus; -if (platform_device_register (&musb_device) <0 ) - printk(KERN_ERR "Unable to register HS-USB (MUSB) device\n"); +if (cpu_is_omap3517 () ||cpu_is_omap3505 ()) { + oh_name ="am35x_otg_hs" ; + name ="musb-am35x" ; + }else { + oh_name ="usb_otg_hs" ; + name ="musb-omap2430" ; + } + + oh =omap_hwmod_lookup (oh_name); +if (!oh) { +pr_err ("Could not look up %s\n" , oh_name); +return ; + } + + od =omap_device_build (name, bus_id, oh, &musb_plat, +sizeof (musb_plat), omap_musb_latency, +ARRAY_SIZE (omap_musb_latency), false); +if (IS_ERR (od)) { +pr_err ("Could not build omap_device for %s %s\n" , + name, oh_name); +return ; + } + + pdev = &od->pdev; + dev = &pdev->dev; +get_device (dev); + dev->dma_mask = &musb_dmamask; + dev->coherent_dma_mask = musb_dmamask; + put_device(dev); }#else
Signature · 1 line
1.7.4.rc2