[PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
From: tony@atomide.com (Tony Lindgren)
Date: 2012-07-10 09:45:38
Also in:
linux-omap
* Mohammed, Afzal [off-list ref] [120709 23:24]:
Hi Tony, Could not respond you earlier as was sick On Fri, Jul 06, 2012 at 17:35:33, Tony Lindgren wrote:quoted
* Mohammed, Afzal [off-list ref] [120705 07:56]:quoted
On Thu, Jul 05, 2012 at 16:25:35, Tony Lindgren wrote:quoted
quoted
Presently bigger issue that I am facing w.r.t driver conversion is the requirement of peripheral specific gpmc timing calculation before probe. I believe currently in mainline runtime gpmc clock changes are not handledHmm I don't follow, why can't the timings be set during the peripheral specific driver probe?My viewpoint while making the above comment was with gpmc driver series that was posted, in that it was required to do peripheral specific timings calculation before probe. With your suggested peripheral specific driver for the purpose of handling retime, it is not a problem, a solution on how to integrate it has to be found though.
The connected peripheral probe should be able to set the gpmc timings just fine before registering with the gpmc.
quoted
quoted
quoted
The peripheral driver can register it's retime function with gpmc and get a cookie back that allows getting the DT provided timings from gpmc. And after that the initial timings can be set.If timings peripheral timings can be fully contained in driver, should we try to pass the same timings translated in terms of gpmc timings through DT ?, and how do we get equivalent gpmc timings to update DT, manually calculate similar to platform init code ?, or I misunderstood youquoted
Well yes the timings should be passed via devicetree in a gpmc specificI assume with the above, you were referring to peripherals that does not have retime function.
It can still have a retime function, it just needs to be registered during the probe of the connected peripheral as we can't pass that from device tree.
quoted
format. But the peripheral specific retime function still needs to be also registered for peripherals that need it.For the peripherals requiring retime, we cannot (as otherwise whatever retime does would have to be manually done based on the knowledge of boot time gpmc clock period to calculate gpmc timings to be fed to DT) pass gpmc timings via device tree, right ?
We can still do it when the connected peripheral probe registers with gpmc. Regards, Tony