Bug in omap2_nand_gpmc_retime? (was: Re: [PATCH] OMAP: fix gpmc nand setup when no timings supplied)

[Mike Rapoport <mike@compulab.co.il>]

Tony Lindgren wrote:
> * Mike Rapoport <mike@compulab.co.il> [100427 00:40]:
>> Tony Lindgren wrote:
>>> * Mike Rapoport <mike@compulab.co.il> [100422 01:41]:
>>>> Ghorai, Sukumar wrote:
>>>>
>>>> CM-T35, for instance can be assembled with different NAND flash
>>>> chips. Besides, boards that use NAND as primary boot device, we
>>>> anyway depend on proper GPMC configuration in the bootloader chain.
>>>> Having ability to define GPMC timings in the kernel and keep the
>>>> settings made by the bootloader adds flexibility level for board
>>>> designers.
>>> Not implementing the retime function for GPMC will cause issues
>>> with PM as you cannot scale the L3 frequency without breaking
>>> your GPMC timings.
>> I agree that without retime function scaling the frequency will
>> break the GPMC timings. But my point was that there should be an
>> _option_ to keep the timings defined by the bootloader rather than
>> enforce board files to specify timings.
> 
> Sure. Can you please check one more time your patch and what is
> still missing after Stanley's fix? That's now in omap-fixes and master
> branches as commit 11e1ef2d105900a302b7ca92bcaf96a96d0274a1.
> 
>> Since skipping the retime function will break gpmc timings in
>> PM-enabled  kernel, we need to implement this option in smarter way.
>> E.g. something like:
> 
> Yeah we should print some warning if the retime function is not
> implemented as it can cause mysterious bugs later on. I guess
> implementing a dummy retime function would be best as then the
> warning would be related to the actual L3 rate change.

While working on implementation of gpmc_nand_detect_timings I've seen 
that omap2_nand_gpmc_retime converts the timings supplied by the 
platform to ticks and passes it to gpmc_cs_set_timings which in turn 
converts the timings to ticks. Is it a bug or am I missing something?

> Regards,
> 
> Tony
>  
-- 
Sincerely yours,
Mike.