[PATCH v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD

Mohammed, Afzal afzal at ti.com
Wed Jun 13 09:59:23 EDT 2012


Hi Tony,

On Wed, Jun 13, 2012 at 19:09:38, Tony Lindgren wrote:
> * Mohammed, Afzal <afzal at ti.com> [120613 06:10]:
> > On Wed, Jun 13, 2012 at 17:32:09, Tony Lindgren wrote:

> > Do you mean that gpmc driver should have the capability to calculate peripheral
> > timings at runtime based on frequency ?, I am not sure how this can be handled
> > by gpmc driver as calculation for different peripherals are done in different
> > way, requiring gpmc driver to know about connected peripheral, that would imply
> > that gpmc driver would not be peripheral agnostic.
> > 
> > Or else some sort of a callback to be used ?
> 
> Oops yeah right, we have some platform_retime functions that are in the
> driver platform init code. It would be best that the drivers can do the
> recalculation with no platform init code callbacks needed.

Other than using a platform callback, I am not getting any idea as of now,
how this can be achieved, let me think over it, if you have any suggestions
on ways to deal it, please let me know.

>  
> > Out of the 20,14 are depending on bootloader, both omap3evm & beagle has been
> > converted to utilize runtime calculation, but for other 12 boards, first
> > we need to get values used by bootloader (those include peripherals that doesn't
> > have gpmc-* helpers), then derive it based on expression, after that only, we
> > will have information to achieve it and those are the ones that I do not
> > have access to.
> 
> It's OK to use fixed timings as long as we disable L3 scaling. Some of
> these values we'll probably never be able to calculate dynamically.

Ok

Regards
Afzal



More information about the linux-arm-kernel mailing list