>-----Original Message----- >From: linuxppc-dev-bounces+tmarri=amcc.com@xxxxxxxxxxxxxxxx >[mailto:linuxppc-dev-bounces+tmarri=amcc.com@xxxxxxxxxxxxxxxx] On Behalf >Of Pratyush Anand >Sent: Thursday, October 20, 2011 2:12 AM >To: tmarri@xxxxxxx >Cc: Mark Miesfeld; greg@xxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx; linuxppc- >dev@xxxxxxxxxxxxxxxx; Fushen Chen >Subject: Re: [PATCH v14 03/10] USB/ppc4xx: Add Synopsys DWC OTG Core >Interface Layer (CIL) > >On Fri, Oct 7, 2011 at 8:00 AM, <tmarri@xxxxxxx> wrote: >> From: Tirumala Marri <tmarri@xxxxxxx> >> > >[...] > >> + * Do core a soft reset of the core. Be careful with this because it >> + * resets all the internal state machines of the core. >> + */ >> +static void dwc_otg_core_reset(struct core_if *core_if) >> +{ >> + ulong global_regs = core_if->core_global_regs; >> + u32 greset = 0; >> + int count = 0; >> + >> + /* Wait for AHB master IDLE state. */ >> + do { >> + udelay(10); >> + greset = dwc_reg_read(global_regs, DWC_GRSTCTL); >> + if (++count > 100000) { >> + pr_warning("%s() HANG! AHB Idle >GRSTCTL=%0x\n", >> + __func__, greset); >> + return; >> + } >> + } while (greset & DWC_RSTCTL_AHB_IDLE); > >As per sepcs: >Bit 31: AHB Master Idle (AHBIdle): Indicates that the AHB Master State >Machine is in the IDLE condition. >So when this bit is 1 , AHB would be idle. So, what do you want here? >If AHB is idle, control wil return from above loop rather going ahead to >execute >this function. What we are trying to do is waiting for the idle before we reset the core. We want to make sure state machine is settle down and all the transactions Are finished before reset. > >> + nptxsize = >> + DWC_RX_FIFO_START_ADDR_WR(nptxsize, >> + params- >>dev_rx_fifo_size); >> + dwc_reg_write(regs, DWC_GNPTXFSIZ, nptxsize); >> + >> + ptxsize = DWC_RX_FIFO_START_ADDR_WR(ptxsize, >> + >(DWC_RX_FIFO_START_ADDR_RD >> + (nptxsize) + >> + >DWC_RX_FIFO_DEPTH_RD >> + (nptxsize))); >> + for (i = 0; >> + i < DWC_HWCFG4_NUM_DEV_PERIO_IN_EP_RD(core_if- >>hwcfg4); >> + i++) { > > >Reading hwcfg4 will give you maximum nuber of fifos provided by >hardware. >But, a particular application (platform) may not need all those fifo. >Since, you >have a vriable fifo_num in your param list, so why not use that? > I am not sure about that. I think it should come from device tree Based on how board is going to be configured. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
