SUPERH platform development
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: linux-sh@vger.kernel.org
Subject: Re: [PATCH] [RFC] ARM: shmobile: koelsch-reference: Work around core clock issues
Date: Fri, 14 Mar 2014 12:43:36 +0000	[thread overview]
Message-ID: <13414243.kopWWn3B9h@avalon> (raw)
In-Reply-To: <1394720970-4749-1-git-send-email-geert@linux-m68k.org>

Hi Geert,

On Friday 14 March 2014 13:39:43 Geert Uytterhoeven wrote:
> On Fri, Mar 14, 2014 at 12:10 PM, Ben Dooks wrote:
> > On 14/03/14 11:02, Laurent Pinchart wrote:
> >> On Thursday 13 March 2014 15:29:30 Geert Uytterhoeven wrote:
> >>> From: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
> >>> 
> >>> Due to issues with runtime PM clock management, clocks not explicitly
> >>> managed by their drivers may not be enabled at all, or be inadvertently
> >>> disabled by the clk_disable_unused() late initcall.
> >>> 
> >>> Until this is fixed, add a temporary workaround, calling
> >>> shmobile_clk_workaround() with enable = true.
> >>> 
> >>> For now this enables the clocks for: ether, i2c2, msiof0, qspi_mod, and
> >>> thermal. More clocks can be added if needed.
> >> 
> >> This should do the job, but as you mentioned, it's a crude hack. As we're
> >> targeting v3.16, is there a chance we could fix the problem properly
> >> instead ?
> 
> Of course the goal is to fix it for real, so the crude hack will no longer
> be needed. But for now, it looks like a good short-term workaround.
> 
> > The best fix would be to re-enable the PM and find out what is
> 
> Sure, but in a multiplatform-aware way.

Of course. Are you working on that, or should I give it a try ? Would you like 
to discuss this ?

> > actually causing the external abort. However currently there is
> > no information in the manuals about anything we could find out from
> > the AXI busses as to what the source actually is.
> 
> I re-applied your patch "ARM: shmobile: compile drivers/sh for
> CONFIG_ARCH_SHMOBILE_MULTI", and surprisingly, I no longer get the external
> abort.
> 
> Some experimenting revealed it's due to the "ether" clock in the
> clk_enables[] array. As long as that's enabled early, the system seems to
> boot fine with your patch.

At what point do you get the external abort without the ether clock workaround 
?

-- 
Regards,

Laurent Pinchart


  parent reply	other threads:[~2014-03-14 12:43 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-13 14:29 [PATCH] [RFC] ARM: shmobile: koelsch-reference: Work around core clock issues Geert Uytterhoeven
2014-03-14  8:51 ` Simon Horman
2014-03-14  8:53 ` Magnus Damm
2014-03-14  9:09 ` Geert Uytterhoeven
2014-03-14  9:23 ` Magnus Damm
2014-03-14 11:02 ` Laurent Pinchart
2014-03-14 11:10 ` Ben Dooks
2014-03-14 12:39 ` Geert Uytterhoeven
2014-03-14 12:43 ` Laurent Pinchart [this message]
2014-03-14 13:02 ` Geert Uytterhoeven
2014-03-14 14:13 ` Ben Dooks
2014-03-14 14:26 ` Laurent Pinchart
2014-03-14 14:43 ` Laurent Pinchart
2014-03-14 14:45 ` Ben Dooks
2014-03-14 15:51 ` Ben Dooks
2014-03-14 16:48 ` Magnus Damm
2014-03-14 17:11 ` Ben Dooks
2014-03-14 17:33 ` Ben Dooks
2014-03-14 17:55 ` Ben Dooks
2014-03-14 18:20 ` Ben Dooks
2014-03-17  1:15 ` Simon Horman
2014-03-18  0:25 ` Simon Horman

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=13414243.kopWWn3B9h@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=linux-sh@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox