All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@kernel.org>
To: Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Boris Brezillon <boris.brezillon@free-electrons.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Marcin Ziemianowicz <marcin@ziemianowicz.com>,
	Nicolas Ferre <nicolas.ferre@microchip.com>
Cc: Marcin Ziemianowicz <marcin@ziemianowicz.com>,
	stable@vger.kernel.org,
	Boris Brezillon <boris.brezillon@bootlin.com>,
	Michael Turquette <mturquette@baylibre.com>,
	linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH V4] clk: at91: PLL recalc_rate() now using cached MUL and DIV values
Date: Tue, 15 May 2018 23:39:42 -0700	[thread overview]
Message-ID: <152645278298.237094.13637070780064221668@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <20180429190111.14247-1-marcin@ziemianowicz.com>

Quoting Marcin Ziemianowicz (2018-04-29 12:01:11)
> When a USB device is connected to the USB host port on the SAM9N12 then
> you get "-62" error which seems to indicate USB replies from the device
> are timing out. Based on a logic sniffer, I saw the USB bus was running
> at half speed.
> 
> The PLL code uses cached MUL and DIV values which get set in set_rate()
> and applied in prepare(), but the recalc_rate() function instead
> queries the hardware instead of using these cached values. Therefore,
> if recalc_rate() is called between a set_rate() and prepare(), the
> wrong frequency is calculated and later the USB clock divider for the
> SAM9N12 SOC will be configured for an incorrect clock.
> 
> In my case, the PLL hardware was set to 96 Mhz before the OHCI
> driver loads, and therefore the usb clock divider was being set
> to /2 even though the OHCI driver set the PLL to 48 Mhz.
> 
> As an alternative explanation, I noticed this was fixed in the past by
> 87e2ed338f1b ("clk: at91: fix recalc_rate implementation of PLL
> driver") but the bug was later re-introduced by 1bdf02326b71 ("clk:
> at91: make use of syscon/regmap internally").
> 
> Fixes: 1bdf02326b71 ("clk: at91: make use of syscon/regmap internally)
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Marcin Ziemianowicz <marcin@ziemianowicz.com>
> ---

Applied to clk-next

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Boyd <sboyd@kernel.org>
To: Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Boris Brezillon <boris.brezillon@free-electrons.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Marcin Ziemianowicz <marcin@ziemianowicz.com>,
	Nicolas Ferre <nicolas.ferre@microchip.com>
Cc: Marcin Ziemianowicz <marcin@ziemianowicz.com>,
	stable@vger.kernel.org,
	Boris Brezillon <boris.brezillon@bootlin.com>,
	Michael Turquette <mturquette@baylibre.com>,
	linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH V4] clk: at91: PLL recalc_rate() now using cached MUL and DIV values
Date: Tue, 15 May 2018 23:39:42 -0700	[thread overview]
Message-ID: <152645278298.237094.13637070780064221668@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <20180429190111.14247-1-marcin@ziemianowicz.com>

Quoting Marcin Ziemianowicz (2018-04-29 12:01:11)
> When a USB device is connected to the USB host port on the SAM9N12 then
> you get "-62" error which seems to indicate USB replies from the device
> are timing out. Based on a logic sniffer, I saw the USB bus was running
> at half speed.
> =

> The PLL code uses cached MUL and DIV values which get set in set_rate()
> and applied in prepare(), but the recalc_rate() function instead
> queries the hardware instead of using these cached values. Therefore,
> if recalc_rate() is called between a set_rate() and prepare(), the
> wrong frequency is calculated and later the USB clock divider for the
> SAM9N12 SOC will be configured for an incorrect clock.
> =

> In my case, the PLL hardware was set to 96 Mhz before the OHCI
> driver loads, and therefore the usb clock divider was being set
> to /2 even though the OHCI driver set the PLL to 48 Mhz.
> =

> As an alternative explanation, I noticed this was fixed in the past by
> 87e2ed338f1b ("clk: at91: fix recalc_rate implementation of PLL
> driver") but the bug was later re-introduced by 1bdf02326b71 ("clk:
> at91: make use of syscon/regmap internally").
> =

> Fixes: 1bdf02326b71 ("clk: at91: make use of syscon/regmap internally)
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Marcin Ziemianowicz <marcin@ziemianowicz.com>
> ---

Applied to clk-next

WARNING: multiple messages have this Message-ID (diff)
From: sboyd@kernel.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V4] clk: at91: PLL recalc_rate() now using cached MUL and DIV values
Date: Tue, 15 May 2018 23:39:42 -0700	[thread overview]
Message-ID: <152645278298.237094.13637070780064221668@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <20180429190111.14247-1-marcin@ziemianowicz.com>

Quoting Marcin Ziemianowicz (2018-04-29 12:01:11)
> When a USB device is connected to the USB host port on the SAM9N12 then
> you get "-62" error which seems to indicate USB replies from the device
> are timing out. Based on a logic sniffer, I saw the USB bus was running
> at half speed.
> 
> The PLL code uses cached MUL and DIV values which get set in set_rate()
> and applied in prepare(), but the recalc_rate() function instead
> queries the hardware instead of using these cached values. Therefore,
> if recalc_rate() is called between a set_rate() and prepare(), the
> wrong frequency is calculated and later the USB clock divider for the
> SAM9N12 SOC will be configured for an incorrect clock.
> 
> In my case, the PLL hardware was set to 96 Mhz before the OHCI
> driver loads, and therefore the usb clock divider was being set
> to /2 even though the OHCI driver set the PLL to 48 Mhz.
> 
> As an alternative explanation, I noticed this was fixed in the past by
> 87e2ed338f1b ("clk: at91: fix recalc_rate implementation of PLL
> driver") but the bug was later re-introduced by 1bdf02326b71 ("clk:
> at91: make use of syscon/regmap internally").
> 
> Fixes: 1bdf02326b71 ("clk: at91: make use of syscon/regmap internally)
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Marcin Ziemianowicz <marcin@ziemianowicz.com>
> ---

Applied to clk-next

  parent reply	other threads:[~2018-05-16  6:39 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-29 19:01 [PATCH V4] clk: at91: PLL recalc_rate() now using cached MUL and DIV values Marcin Ziemianowicz
2018-04-29 19:01 ` Marcin Ziemianowicz
2018-04-30  5:58 ` Boris Brezillon
2018-04-30  5:58   ` Boris Brezillon
2018-05-09  4:32   ` Marcin Ziemianowicz
2018-05-09  4:32     ` Marcin Ziemianowicz
2018-05-15 23:04     ` Stephen Boyd
2018-05-15 23:04       ` Stephen Boyd
2018-05-15 23:04       ` Stephen Boyd
2018-05-16  6:39 ` Stephen Boyd [this message]
2018-05-16  6:39   ` Stephen Boyd
2018-05-16  6:39   ` Stephen Boyd
  -- strict thread matches above, loose matches on Subject: below --
2018-04-29 18:50 Marcin Ziemianowicz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=152645278298.237094.13637070780064221668@swboyd.mtv.corp.google.com \
    --to=sboyd@kernel.org \
    --cc=alexandre.belloni@bootlin.com \
    --cc=boris.brezillon@bootlin.com \
    --cc=boris.brezillon@free-electrons.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcin@ziemianowicz.com \
    --cc=mturquette@baylibre.com \
    --cc=nicolas.ferre@microchip.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.