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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Mohammed, Afzal <afzal@xxxxxx> [120613 06:10]:
> Hi Tony,
> 
> On Wed, Jun 13, 2012 at 17:32:09, Tony Lindgren wrote:
> > * Mohammed, Afzal <afzal@xxxxxx> [120612 22:24]:
> > > Hi Jon,
> > > 
> > > On Tue, Jun 12, 2012 at 23:10:01, Hunter, Jon wrote:
> 
> > > > Right but potentially, this could be done by the driver.
> > > 
> > > I do not think it is practically possible. Please see timing calculations
> > > in arch/arm/mach-omap2/gpmc-*, the way it is done for different
> > > peripherals are different, and we cannot expect gpmc driver to do those as
> > > that would require gpmc driver being aware of type of peripheral connected.
> > > 
> > > And all those gpmc-* timing calculation needs to be done before driver
> > > is ready, they rely on functions like gpmc_get_fclk_rate(), which in turn
> > > requires the clk rate to be available before driver is probed.
> > 
> > Yeah I also think the GPMC code should handle the L3 timings, and dynamically
> > calculate them for DVFS when L3 frequency changes. Does the GPMC have enough
> > information now to do that?
> 
> 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.
 
> 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.

Regards,

Tony
--
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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux