Message-id: <7AFBEAB40137492BBF4D80EBC3E6EBB3@sisodomain.com>
Date:	Thu, 11 Sep 2014 08:50:30 +0530
From:	Vivek Gautam <gautam.vivek@...sung.com>
To:	Julius Werner <jwerner@...gle.com>, Felipe Balbi <balbi@...com>
Cc:	Julius Werner <jwerner@...omium.org>,
	Linux USB Mailing List <linux-usb@...r.kernel.org>,
	linux-samsung-soc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	Greg KH <gregkh@...uxfoundation.org>, kishon <kishon@...com>,
	Alan Stern <stern@...land.harvard.edu>,
	Kukjin Kim <kgene.kim@...sung.com>,
	Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
	Mathias Nyman <mathias.nyman@...el.com>,
	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
	Jingoo Han <jg1.han@...sung.com>, abrestic@...omium.org
Subject: Re: [PATCH v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for
 exynos5420/5800


Hi,


On Thursday, September 11, 2014 1:52 AM, "Julius Werner" 
<jwerner@...gle.com> wrote


>>> right, use that to call phy_init() at the right time, then you need to
>>> add a new ->calibrate() method which, likely, will only be used by you
>>> ;-)
>
>> so you mean, the xhci should itself call phy_init() at a time suitable,
>> so that ->calibrate() is not required at all ?
>
> I'm not sure if that's a good idea because it would require phy_init()
> and calibrate() to always mean the same thing. The calibrate() for
> Exynos5420 needs to be called both during boot and after system
> resume, but there might be other platforms that don't want to
> completely shutdown and reinit their PHYs during suspend/resume with
> the same functions used for boot. For example, Tegra5 (proposed driver
> at http://www.spinics.net/lists/linux-usb/msg113093.html) can
> power-gate the PHY during suspend, but that's not running the same
> code as in the phy_init()/phy_shutdown() methods (the posted patch
> doesn't contain all power-gating code yet, but you can get an idea
> about how it has to work from
> https://chromium.googlesource.com/chromiumos/third_party/kernel-next/+/chromeos-3.10/drivers/usb/host/xhci-tegra.c).
> It would also mean that the initial phy_init() call must always come
> after the XHCI reset, and I am not sure if that would fit nicely with
> all platforms.
>
>> right, and what's more generic than adding the support for PHYs straight 
>> into xHCI ?
>
> Well, if we are going to have a calibrate() method (as in "stuff the
> PHY does after every controller reset if it needs to"), we have to add
> it either to the XHCI stack or the USB core.
> I thought the USB core would be more generic, because in theory it's 
> possible that e.g. an
> EHCI controller might have a similar requirement.

Atleast on Exynos systems I can see that unless PHY is initialized the 
controller
fails to reset. So taking a path wherein we initialize the PHYs after 
controller resets
is not going to help us generically across all controllers.
With XHCI though things are OK while resetting, and we can initialize the 
PHYs
after controller reset happens but here too DWC3 is already initializing the 
PHYs
for exynos systems too, so it may not be very wise to do that initialization 
stuff
once again. Plus the PHY core prevents multiple initialization anyways.

> (Also, we have the gen_phy pointer in a USB core structure (struct 
> usb_hcd), so I thought
> making this feature generic to the USB core and thus available to all
> kinds of host controllers would be more natural.) 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists