All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: linux-sh@vger.kernel.org
Subject: Re: [PATCH v7 1/6] clk: shmobile: sh73a0 common clock framework implementation
Date: Thu, 11 Dec 2014 14:19:20 +0000	[thread overview]
Message-ID: <1790029.xF99x3F1Em@avalon> (raw)
In-Reply-To: <1418222727-19888-2-git-send-email-ulrich.hecht+renesas@gmail.com>

Hi Magnus,

On Thursday 11 December 2014 19:07:27 Magnus Damm wrote:
> On Thu, Dec 11, 2014 at 3:39 AM, Laurent Pinchart wrote:
> > Hi Ulrich,
> > 
> > (CC'ing Morimoto-san)
> > 
> > On Wednesday 10 December 2014 17:53:22 Ulrich Hecht wrote:
> >> On Wed, Dec 10, 2014 at 4:38 PM, Laurent Pinchart wrote:
> >> > On Wednesday 10 December 2014 15:45:22 Ulrich Hecht wrote:
> >> >> Driver for the SH73A0's clocks that are too specific to be supported
> >> >> by a
> >> >> generic driver.
> >> 
> >> [...]
> >> 
> >> >> +static struct div4_clk div4_clks[] = {
> >> >> +     { "zg", "pll0", CPG_FRQCRA, 16 },
> >> > 
> >> > I've already commented on this in v6, the comment has probably been
> >> > overlooked. According to the datasheet the ZGFC value 1010 results in a
> >> > x1/5 factor, which  doesn't match the value in the div4_div_table
> >> > below.
> >> > I wonder if it could be an error in the datasheet though.
> >> 
> >> The legacy driver doesn't make an exception for zg.  Looks like an
> >> error in the datasheet to me.
> > 
> > Morimoto-san, do you think it would be possible to get that information
> > from the hardware team(s) ?
> > 
> > In the meantime I don't think this is a show stopper.
> 
> Let me step in here for a sec. I think getting reliable new information
> about sh73a0 is highly unlikely. That particular SoC is both old and part of
> the mobile line up that was chopped off quite some time ago. So I don't
> think anyone with knowledge is left in the company.

Fair enough, I was quite expecting that, but I possibly naively thought it 
would be worth trying :-)

It should in theory be possible to test this by measuring the SGX perfomances, 
but I don't think that would be feasible in practice in our team. I'm thus 
fine considering this as an error in the documentation until proven wrong. It 
should probably be captured in a comment in the source code though.

-- 
Regards,

Laurent Pinchart


  parent reply	other threads:[~2014-12-11 14:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-10 14:45 [PATCH v7 1/6] clk: shmobile: sh73a0 common clock framework implementation Ulrich Hecht
2014-12-10 15:38 ` Laurent Pinchart
2014-12-10 16:53 ` Ulrich Hecht
2014-12-10 18:39 ` Laurent Pinchart
2014-12-11 10:07 ` Magnus Damm
2014-12-11 14:15 ` Geert Uytterhoeven
2014-12-11 14:19 ` Laurent Pinchart [this message]
2014-12-11 14:38 ` Ulrich Hecht
2014-12-12  0:16 ` 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=1790029.xF99x3F1Em@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 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.