Tony Lindgren wrote:
* Mike Rapoport <mike@xxxxxxxxxxxxxx> [100427 00:40]:
Tony Lindgren wrote:
* Mike Rapoport <mike@xxxxxxxxxxxxxx> [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.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
