From mboxrd@z Thu Jan  1 00:00:00 1970
From: Kim Phillips <kim.phillips@freescale.com>
Date: Wed, 30 Mar 2011 20:14:14 -0500
Subject: [U-Boot] [PATCH] [MPC837x v2] Make it work again with USB.
In-Reply-To: <4D6BCADE.1060206@matrix-vision.de>
References: <1289911070-21742-1-git-send-email-andre.schwarz@matrix-vision.de>
	<20101128091038.bdcf8fd0.kim.phillips@freescale.com>
	<378632743.6.1291017561200.JavaMail.open-xchange@proteus>
	<20101213165238.0b496e57.kim.phillips@freescale.com>
	<4D6BCADE.1060206@matrix-vision.de>
Message-ID: <20110330201414.a930d14a.kim.phillips@freescale.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On Mon, 28 Feb 2011 17:18:38 +0100
Andre Schwarz <andre.schwarz@matrix-vision.de> wrote:

> sorry to bother you again, but I again stumbled over the discussed USB 
> init issue :
> >>> nack, 837x has a usb controller at IMMR+0x23000.
> >> yes - but offset 0x00-0xff is explicitly reserved regarding to the manual.
> >> Don't know whether it is a "should not" or "must not be touched".
> >>   
> >> All I can see is a CPU hang with arbiter event register reporting a timeout on
> >> 0xe0023000.
> >>   
> >>
> >>    Check to see whether there is an invalid USB clock setting in the SCCR? 
> >> All clocks are turned on except SEC and 2nd TSEC.
> >>   
> >> After all USB is running fine with this patch, i.e. there can hardly be a
> >> missing clock.
> >>
> >>
> >> Please re-think you NAK.
> > afaik, 834x and 837x don't have any special USB settings in common, so,
> > this patch, at least in it's current form, is not on.
> >
> > 0xe0023500 should be the address of the config register being accessed
> > here; please check the code isn't accessing 0xe0023000, as you mention
> > above.
> 
> ok - this was some kind of misunderstanding.
> ehci regs are based at immr + 0x23000 with the "config" pointing to 
> offset 0x500 inside ehci.
> This looks sane to me.

ok, as long as it's confirmed.

> > If that's correct, try something like the following so we can determine
> > what setting the USB controller didn't agree with:
> >
> > diff --git a/arch/powerpc/cpu/mpc83xx/cpu_init.c b/arch/powerpc/cpu/mpc83xx/cpu_init.c
> > index 7a1cae7..cbc4157 100644
> > --- a/arch/powerpc/cpu/mpc83xx/cpu_init.c
> > +++ b/arch/powerpc/cpu/mpc83xx/cpu_init.c
> > @@ -332,7 +332,7 @@ void cpu_init_f (volatile immap_t * im)
> >   	struct usb_ehci *ehci = (struct usb_ehci *)CONFIG_SYS_FSL_USB_ADDR;
> >
> >   	/* Configure interface. */
> > -	setbits_be32(&ehci->control, REFSEL_16MHZ | UTMI_PHY_EN);
> MPC837x has only 2 working bits inside the control register :
> 
> Bit29: USB_EN -> should be set to 1 before USB can be used.
> Bit31: ULPI_INT_EN -> enables an ULPI wake-up irq.
> 
> Both "REFSEL_16MHZ" and "UTMI_PHY_EN" are completely out of scope for 
> MPC837x.

that's why I'm suggesting we confirm that touching the REFSEL_16MHZ and
UTMI_PHY_EN bits aren't sending the 837x controller into oblivion - did
you test the patch?

> > +	setbits_be32(&ehci->control, 0);
> >
> >   	/* Wait for clock to stabilize */
> This loop never returns on MPC837x because "PHY_CLK_VALID" isn't valid.

right, we need to narrow down the reason for this.

> >   	do {    temp = __raw_readl(&ehci->control);
> >                  udelay(1000);
> >          } while (!(temp&  PHY_CLK_VALID));
> >
> I still wonder how there can be a single working MPC837x board with 
> CONFIG_USB_EHCI_FSL set.
> 
> Some pending patches on your side ?
> What kind of patch might get an ACK from your side ?

nothing that suggests 834x and 837x have any special USB settings in
common - because it's not true and therefore misleading.

Kim