Re: [PATCH] usb: host: tegra: Reset Tegra USB controller before init

[Stephen Warren <swarren@wwwdotorg.org>]

On 02/27/2013 11:36 PM, Venu Byravarasu wrote:
> To clear any configurations made by U-Boot on Tegra USB controller,
> reset it before init in probe.

> diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c

> @@ -691,6 +692,10 @@ static int tegra_ehci_probe(struct platform_device *pdev)
>  	if (err)
>  		goto fail_clk;
>  
> +	tegra_periph_reset_assert(tegra->clk);
> +	udelay(1);
> +	tegra_periph_reset_deassert(tegra->clk);

I think this patch might cause unintended consequences.

When the Tegra PHY code is converted to a driver (i.e. has its own
probe), the initial order of execution of the PHY and EHCI driver probes
will not be guaranteed.

In particular, since the EHCI probe will attempt to "find" the PHY
device, and defer the EHCI probe until it can do so, this guarantees
that the PHY's probe() will have completed before EHCI's probe()
completes (although EHCI's probe may start running first some number of
times, and be retried with -EPROBE_DEFERRED for a variety of reasons).

Now, if the PHY driver's probe() actually touches HW and sets up some
registers, isn't this reset call going to trash any of that register
setup? Or, will PHY probe() not touch registers, but only do so during
the standard PHY open/init "op"/API calls?

I think the way to solve this is to put the reset call into the PHY
driver. I assume it has access to the appropriate clock object. This may
also address Alan's query re: when the unexpected interrupt occurs; it's
triggered by (or correlated with at least) the PHY (or USB port in
general) being in device mode due to the boot ROM setting it up this
way, then switching to host mode via the Linux driver. I /think/ that
device/host mode switching is more related to the PHY than EHCI driver,
although I could well be wrong here.