[PATCH v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD
afzal at ti.com
Thu Jun 14 03:07:52 EDT 2012
On Wed, Jun 13, 2012 at 20:38:09, Hunter, Jon wrote:
> On 06/13/2012 08:05 AM, Mohammed, Afzal 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.
> I guess I still don't agree with this. From the gpmc timing point of
> view it should not care what device is connected, it just needs to know
> the associated timings. Therefore, the gpmc driver just needs the time
> associated with the different timings fields in the various GPMC_CONFIGx
> registers and then convert to clocks based upon the gpmc fclk. The only
> item that is device specific here is the actual timing values and these
> can be passed to the driver.
> Furthermore, gpmc_cs_set_timings function is completely device agnostic.
> Why can we not call this from within the driver? Why does it need to be
> called outside the driver?
As mentioned in one of my previous mails, input to gpmc_cs_set_timings
sometimes are a function of gpmc clock, and that function can vary with
the type of peripheral connected.
More information about the linux-arm-kernel