All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <mike@compulab.co.il>
To: Vimal Singh <vimal.newwork@gmail.com>
Cc: tony@atomide.com, s-ghorai@ti.com, linux-omap@vger.kernel.org
Subject: Re: [PATCH 2/2] omap: gpmc-nand: add ability to keep timings defined by the bootloader
Date: Thu, 29 Apr 2010 10:27:33 +0300	[thread overview]
Message-ID: <4BD934E5.5080904@compulab.co.il> (raw)
In-Reply-To: <g2qce9ab5791004290011w84f68a4ak3e24acdc74016265@mail.gmail.com>

Vimal Singh wrote:
> On Thu, Apr 29, 2010 at 12:23 PM, Mike Rapoport <mike@compulab.co.il> wrote:
>> Vimal Singh wrote:
>>> On Wed, Apr 28, 2010 at 9:36 PM, Mike Rapoport <mike@compulab.co.il>
>>> wrote:
>>>> Signed-off-by: Mike Rapoport <mike@compulab.co.il>
>>>> +       if (gpmc_nand_data->keep_timings) {
>>>> +               gpmc_nand_detect_timings();
>>>> +               gpmc_nand_data->gpmc_t = &gpmc_default_timings;
>>>> +       }
>>>> +
>>> I guess moving this part to omap2_nand_gpmc_retime will be a good idea.
>>> As there, once we get old/default timings we can simply skip the
>>> rounding part and directly jump to setting the timings.
>> This way it would be the same as to pass 'gpmc_nand_data->gpmc_t =
>> NULL'. If I correctly understood the previous comments ([1]), the
>> problem with skipping retime is that when L3 clock changes, the gpmc
>> timings became wrong. So, if we convert old/default timings to
>> nanoseconds early during startup every time retime is called it will use
>> the timing settings in nanoseconds thus yielding proper gpmc registers
>> configuration.
> 
> OK. Then I think we can at least put __rounding__ code inside an 'if'
> case, something like:
> if (!gpmc_nand_data->keep_timings) {
> ...
> do rounding for supplied timings from board file.
> ...
> }

Sure, no problem.

>> And, if I'm not terribly mistaken retime should be called each time L3
>> frequency changes, though with current kernel it's not yet the case...
> 
> Yes. This is still left.
> 


-- 
Sincerely yours,
Mike.

      reply	other threads:[~2010-04-30 21:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-28 16:06 [PATCH 0/2] omap: gpmc-nand: add ability to keep timings defined by the bootloader Mike Rapoport
2010-04-28 16:06 ` [PATCH 1/2] omap: gpmc: add gpmc_cs_get_timings Mike Rapoport
2010-04-28 16:06 ` [PATCH 2/2] omap: gpmc-nand: add ability to keep timings defined by the bootloader Mike Rapoport
2010-04-29  4:27   ` Vimal Singh
2010-04-29  6:53     ` Mike Rapoport
2010-04-29  7:11       ` Vimal Singh
2010-04-29  7:27         ` Mike Rapoport [this message]

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=4BD934E5.5080904@compulab.co.il \
    --to=mike@compulab.co.il \
    --cc=linux-omap@vger.kernel.org \
    --cc=s-ghorai@ti.com \
    --cc=tony@atomide.com \
    --cc=vimal.newwork@gmail.com \
    /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.