From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from galahad.ideasonboard.com ([185.26.127.97]:58921 "EHLO galahad.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752900AbdACWQx (ORCPT ); Tue, 3 Jan 2017 17:16:53 -0500 From: Laurent Pinchart To: Stephen Boyd Cc: Adam Ford , linux-omap@vger.kernel.org, linux-clk@vger.kernel.org, Paul Walmsley , Tero Kristo , Richard Watts , Tony Lindgren , Alexander Kinzer Subject: Re: [PATCH v3] clk: ti: omap36xx: Work around sprz319 advisory 2.1 Date: Wed, 04 Jan 2017 00:16:55 +0200 Message-ID: <8244231.MVTltJ04HJ@avalon> In-Reply-To: <20170103184956.GJ17126@codeaurora.org> References: <1480713278-6884-1-git-send-email-laurent.pinchart@ideasonboard.com> <20170103184956.GJ17126@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: linux-clk-owner@vger.kernel.org List-ID: On Tuesday 03 Jan 2017 10:49:56 Stephen Boyd wrote: > On 01/03, Adam Ford wrote: > > On Thu, Dec 8, 2016 at 3:24 PM, Laurent Pinchart wrote: > >> On Thursday 08 Dec 2016 13:16:01 Stephen Boyd wrote: > >>> On 12/02, Laurent Pinchart wrote: > >>>> From: Richard Watts > >>>> > >>>> The OMAP36xx DPLL5, driving EHCI USB, can be subject to a long-term > >>>> frequency drift. The frequency drift magnitude depends on the VCO > >>>> update rate, which is inversely proportional to the PLL divider. The > >>>> kernel DPLL configuration code results in a high value for the divider, > >>>> leading to a long term drift high enough to cause USB transmission > >>>> errors. In the worst case the USB PHY's ULPI interface can stop > >>>> responding, breaking USB operation completely. This manifests itself on > >>>> the Beagleboard xM by the LAN9514 reporting 'Cannot enable port 2. > >>>> Maybe the cable is bad?' in the kernel log. > >>>> > >>>> Errata sprz319 advisory 2.1 documents PLL values that minimize the > >>>> drift. Use them automatically when DPLL5 is used for USB operation, > >>>> which we detect based on the requested clock rate. The clock > >>>> framework will still compute the PLL parameters and resulting rate as > >>>> usual, but the PLL M and N values will then be overridden. This can > >>>> result in the effective clock rate being slightly different than the > >>>> rate cached by the clock framework, but won't cause any adverse effect > >>>> to USB operation. > >>>> > >>>> Signed-off-by: Richard Watts > >>>> [Upported from v3.2 to v4.9] > >>>> Signed-off-by: Laurent Pinchart > >>>> --- > >>> > >>> Applied to clk-next > > > > Since this fixes an errata issue, is there any way we can get this > > patch applied to the older LTS kernels? (4.4 seems to apply cleanly, > > but I didn't try any older than that) > > Sure. Just follow the stable kernel rules. See > Documentation/process/stable-kernel-rules.rst, specifically > option #2. And needless to say, please test the backported patch before requesting it to be included in stable kernels :-) -- Regards, Laurent Pinchart