[PATCH v14 03/10] USB/ppc4xx: Add Synopsys DWC OTG Core Interface Layer (CIL)

[Tirumala Marri]

>-----Original Message-----
>From: linuxppc-dev-bounces+tmarri=amcc.com at lists.ozlabs.org
>[mailto:linuxppc-dev-bounces+tmarri=amcc.com at lists.ozlabs.org] On Behalf
>Of Pratyush Anand
>Sent: Thursday, October 20, 2011 2:12 AM
>To: tmarri at apm.com
>Cc: Mark Miesfeld; greg at kroah.com; linux-usb at vger.kernel.org; linuxppc-
>dev at lists.ozlabs.org; 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 at apm.com> wrote:
>> From: Tirumala Marri <tmarri at apm.com>
>>
>
>[...]
>
>> + * 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.