RE: gpmc generic retime function (subject was RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration)
Hi Jon, On Fri, Aug 17, 2012 at 20:32:34, Hunter, Jon wrote: And we have been able to create such a function. Below is an implementation that has been made for handling asynchronous timings. It has been tested for OneNAND SMSC on OMAP3EVM (rev G C) with [1-4]. OneNAND was tested using [5] (OMAP3EVM OneNAND works in async mode) SMSC using [6] (mainline does not have a timing calculation for smsc911x) Are you able to verify that the timing calculated by this function are identical? May be some more details on exactly how you tested this would be good. Yes, it was verified. A new driver preparation series has been posted, http://marc.info/?l=linux-omapm=134554573104116w=2 that includes generic timing calculation method. The new series mentions how timing values were validated. There are a couple of timing parameters that would vary as mentioned in the above mentioned mail, but these I don't expect to create problems as this is more inline with gpmc peripheral timings. And both of the these has been verified that it would not create problem with peripheral functionality. One was tested directly (we_on related for OneNAND) and other indirectly (adv_rd(wr)_off on SMSC 9220 for SMSC 91C96). Reason for doing so was that quirks required to handle these specific cases could be avoided, otherwise new peripheral timing data would be required and it would be difficult to achieve DT bindings (when DT happens) for these kind of fixup timings. But if this causes any problems (which I don't expect), then we will have to fallback to the quirks that I wanted to avoid. Do you think that there is any value in making the tusb member a u32 dev_type and then set it too GPMC_DEVICE_TUSB then this could be used for other devices in the future too if needed? Would it be possible to create a sub-function called gpmc_calc_timings_tusb() and put all these if (tusb) statements in there? Or maybe a generic function called gpmc_calc_timings_prepare(). Usage of a tusb check was something that I really wanted to avoid as that was making generic timing calculation function peripheral Gnostic. With the newly posted series, tusb field has been removed. Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gpmc generic retime function (subject was RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration)
Hi Afzal,
Sorry for the delay, I have been out of the office.
On 08/06/2012 08:38 AM, Mohammed, Afzal wrote:
Hi Tony, Jon,
On Wed, Jul 11, 2012 at 12:17:25, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [120710 10:20]:
The DT node should simply have the information required by the retime
function or gpmc timings themselves if available. In the case of OneNAND
These can be stored in the DT and then translated to gpmc timings at
runtime. DT should only store static timing or clock information known
Yup. And the format of the timing data in DT should be standardized so
the only differences for each connected peripheral is the retime function.
If we are able to achieve a generic retime function applicable to all
peripherals then we don't need wrapper layer for retime handling or two
linux devices and drivers (one the existing and the other to handle retime)
to represent a single physical gpmc peripheral device (for DT conversion).
Then handling core frequency scaling and DT conversion would be easier.
We were trying to create such a retime function that would be generic so
as to handle different types of gpmc peripherals.
Sounds like a much better approach!
And we have been able to create such a function. Below is an implementation
that has been made for handling asynchronous timings. It has been tested for
OneNAND SMSC on OMAP3EVM (rev G C) with [1-4]. OneNAND was tested using
[5] (OMAP3EVM OneNAND works in async mode) SMSC using [6] (mainline does
not have a timing calculation for smsc911x)
Are you able to verify that the timing calculated by this function are
identical? May be some more details on exactly how you tested this would
be good.
It was difficult to squeeze tusb6010 timing calculation into generic timing
calculation, hence a boolean tusb has been used. This is what I could
achieve based on existing retime for tusb6010 and for lack of tusb6010
timing specifications.
8---
/* Device timings in picoseconds */
struct gpmc_device_timings {
u32 cs_setup; /* CS setup time */
u32 adv_setup; /* ADV setup time */
u32 adv_rd_off; /* ADV read off time */
u32 adv_add_hold; /* address hold time */
u32 oe_setup; /* OE setup time */
u32 adv_access; /* access time from ADV assertion */
u32 rd_access; /* read access time */
u32 oe_access; /* access time from OE assertion */
u32 cs_access; /* access time from CS asertion */
u32 rd_cycle; /* read cycle time */
u32 cs_highz; /* CS deassertion to high Z */
u32 oe_highz; /* OE deassertion to high Z */
u32 adv_wr_off; /* ADV write off time */
u32 we_setup; /* WE setup time */
u32 wr_pulse; /* write assertion time */
u32 wr_data_setup; /* data setup time from write assertion */
u32 wr_high;/* write deassertion time */
u32 we_highz; /* WE deassertion to high Z */
u32 wr_cycle; /* write cycle time */
boolmux;/* address data muxed */
booltusb; /* peripheral is tusb6010 */
Do you think that there is any value in making the tusb member a u32
dev_type and then set it too GPMC_DEVICE_TUSB then this could be used
for other devices in the future too if needed?
};
struct gpmc_timings gpmc_calc_timings(struct gpmc_device_timings *dev_t)
{
struct gpmc_timings gpmc_t;
bool mux = dev_t-mux;
bool tusb = dev_t-tusb;
u32 temp;
memset(gpmc_t, 0, sizeof(gpmc_t));
/* cs_on */
gpmc_t.cs_on = gpmc_round_ns_to_ticks(dev_t-cs_setup / 1000);
/* adv_on */
temp = dev_t-adv_setup;
if (tusb)
temp = max_t(u32,
(gpmc_t.cs_on + gpmc_ticks_to_ns(1)) * 1000, temp);
gpmc_t.adv_on = gpmc_round_ns_to_ticks(temp / 1000);
Would it be possible to create a sub-function called
gpmc_calc_timings_tusb() and put all these if (tusb) statements in
there? Or maybe a generic function called gpmc_calc_timings_prepare().
For the above case could have ...
void gpmc_calc_timings_prepare(struct gpmc_device_timings *dev_t)
{
if (dev_t-tusb) {
dev_t-adv_on = max_t(u32,
(gpmc_t.cs_on + gpmc_ticks_to_ns(1)) * 1000,
dev_t-adv_setup);
...
} else {
dev_t-adv_on = dev_t-adv_setup;
...
}
}
And then in the gpmc_calc_timings() you would just have ...
gpmc_t.adv_on = gpmc_round_ns_to_ticks(dev_t-adv_on / 1000);
/* adv_rd_off */
temp = dev_t-adv_rd_off;
if (tusb)
temp = max_t(u32,
gpmc generic retime function (subject was RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration)
Hi Tony, Jon,
On Wed, Jul 11, 2012 at 12:17:25, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [120710 10:20]:
The DT node should simply have the information required by the retime
function or gpmc timings themselves if available. In the case of OneNAND
These can be stored in the DT and then translated to gpmc timings at
runtime. DT should only store static timing or clock information known
Yup. And the format of the timing data in DT should be standardized so
the only differences for each connected peripheral is the retime function.
If we are able to achieve a generic retime function applicable to all
peripherals then we don't need wrapper layer for retime handling or two
linux devices and drivers (one the existing and the other to handle retime)
to represent a single physical gpmc peripheral device (for DT conversion).
Then handling core frequency scaling and DT conversion would be easier.
We were trying to create such a retime function that would be generic so
as to handle different types of gpmc peripherals.
And we have been able to create such a function. Below is an implementation
that has been made for handling asynchronous timings. It has been tested for
OneNAND SMSC on OMAP3EVM (rev G C) with [1-4]. OneNAND was tested using
[5] (OMAP3EVM OneNAND works in async mode) SMSC using [6] (mainline does
not have a timing calculation for smsc911x)
It was difficult to squeeze tusb6010 timing calculation into generic timing
calculation, hence a boolean tusb has been used. This is what I could
achieve based on existing retime for tusb6010 and for lack of tusb6010
timing specifications.
8---
/* Device timings in picoseconds */
struct gpmc_device_timings {
u32 cs_setup; /* CS setup time */
u32 adv_setup; /* ADV setup time */
u32 adv_rd_off; /* ADV read off time */
u32 adv_add_hold; /* address hold time */
u32 oe_setup; /* OE setup time */
u32 adv_access; /* access time from ADV assertion */
u32 rd_access; /* read access time */
u32 oe_access; /* access time from OE assertion */
u32 cs_access; /* access time from CS asertion */
u32 rd_cycle; /* read cycle time */
u32 cs_highz; /* CS deassertion to high Z */
u32 oe_highz; /* OE deassertion to high Z */
u32 adv_wr_off; /* ADV write off time */
u32 we_setup; /* WE setup time */
u32 wr_pulse; /* write assertion time */
u32 wr_data_setup; /* data setup time from write assertion */
u32 wr_high;/* write deassertion time */
u32 we_highz; /* WE deassertion to high Z */
u32 wr_cycle; /* write cycle time */
boolmux;/* address data muxed */
booltusb; /* peripheral is tusb6010 */
};
struct gpmc_timings gpmc_calc_timings(struct gpmc_device_timings *dev_t)
{
struct gpmc_timings gpmc_t;
bool mux = dev_t-mux;
bool tusb = dev_t-tusb;
u32 temp;
memset(gpmc_t, 0, sizeof(gpmc_t));
/* cs_on */
gpmc_t.cs_on = gpmc_round_ns_to_ticks(dev_t-cs_setup / 1000);
/* adv_on */
temp = dev_t-adv_setup;
if (tusb)
temp = max_t(u32,
(gpmc_t.cs_on + gpmc_ticks_to_ns(1)) * 1000, temp);
gpmc_t.adv_on = gpmc_round_ns_to_ticks(temp / 1000);
/* adv_rd_off */
temp = dev_t-adv_rd_off;
if (tusb)
temp = max_t(u32,
(gpmc_t.adv_on + gpmc_ticks_to_ns(1)) * 1000, temp);
gpmc_t.adv_rd_off = gpmc_round_ns_to_ticks(temp / 1000);
/* oe_on */
if (mux)
temp = gpmc_t.adv_rd_off * 1000 + dev_t-adv_add_hold;
else
temp = dev_t-oe_setup;
if (tusb)
temp = max_t(u32,
(gpmc_t.adv_rd_off + gpmc_ticks_to_ns(1)) * 1000, temp);
gpmc_t.oe_on = gpmc_round_ns_to_ticks(temp / 1000);
/* access */
temp = max_t(u32, dev_t-rd_access,
gpmc_t.oe_on * 1000 + dev_t-oe_access);
temp = max_t(u32, temp,
gpmc_t.cs_on * 1000 + dev_t-cs_access);
temp = max_t(u32, temp,
gpmc_t.adv_on * 1000 + dev_t-adv_access);
if (tusb) {
temp = max_t(u32, temp,
(gpmc_t.oe_on + gpmc_ticks_to_ns(1)) * 1000);
temp = max_t(u32, temp, gpmc_t.oe_on * 1000 + 300);
}
gpmc_t.access = gpmc_round_ns_to_ticks(temp / 1000);
gpmc_t.oe_off = gpmc_t.access + gpmc_ticks_to_ns(1);
gpmc_t.cs_rd_off = gpmc_t.oe_off;
/* rd_cycle */
temp = max_t(u32,
RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Tony, On Thu, Jun 28, 2012 at 18:14:30, Mohammed, Afzal wrote: On Thu, Jun 28, 2012 at 18:02:07, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [120628 02:36]: diff --git a/arch/arm/mach-omap2/gpmc-onenand.c b/arch/arm/mach-omap2/gpmc-onenand.c index c8a9487..bbae674 100644 --- a/arch/arm/mach-omap2/gpmc-onenand.c +++ b/arch/arm/mach-omap2/gpmc-onenand.c @@ -364,6 +364,8 @@ static int omap2_onenand_setup_async(void __iomem *onenand_base) struct gpmc_timings t; int ret; + omap2_onenand_set_async_mode(onenand_base); + t = omap2_onenand_calc_async_timings(); ret = gpmc_set_async_mode(gpmc_onenand_data-cs, t); Yes that seems to do the trick, thanks! I can fold that into the breaking patch when applying. Also following needs to be removed from commit message, Ensuring sync read/write are disabled in onenand cannot be expected to work properly unless GPMC is setup, this has been removed. With the above diff we are in effect disabling sync mode in onenand before GPMC has been setup in the Kernel If you want, I can sent a new series too. Can you please take this series along with the above changes folded in $subject patch. I Jon concurred on this as a solution in this same thread (along with preventing hwmod reset, which is taken care in hwmod patch). Please let me know whether you prefer to have a separate series posted inclusive of the above changes. Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Tony, Jon, Thanks for your explanations, ideas suggestions. Let me try to come up with a solution based on these. Regards Afzal On Wed, Jul 11, 2012 at 12:17:25, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [120710 10:20]: Hi Afzal, On 07/10/2012 08:47 AM, Mohammed, Afzal wrote: Hi Tony, On Tue, Jul 10, 2012 at 18:47:34, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [120710 03:09]: On Tue, Jul 10, 2012 at 15:15:38, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [120709 23:24]: 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. Were you actually referring to updating kernel view of device tree nodes, and not the device tree file (not sure whether it is really possible) ? I believe that Tony is suggesting performing the retime at probe time. In the case of OneNand you would simply call the onenand_set_async_mode/sync_mode from within the probe as a retime function. Yes there's no need to do it earlier. We can, but would it be feasible practically ?, gpmc timings to update in DT for a such a peripheral (requiring retime) can be found out only by manual calculation similar to the way done in retime function (based on peripheral's timings and boot time gpmc clock period), correct ?, Also wouldn't this make it necessary to know gpmc clock period at boot time for properly updating gpmc timing entry in DT ? The gpmc clock period can be returned to the connected peripheral when it's registering. Well basically we can call the retime function upon registering and pass the gpmc clock period. Won't this lead to the necessity of particular driver load order problem ?, As per the above, to return gpmc clock period to the connected peripheral, we need to ensure that gpmc driver is probed before peripheral driver. I think it is more like when probing the gpmc, the retime function for the connected peripheral is called passing the gpmc clock freq. Right, there's no need to do any of that at gpmc probe time. And the module dependencies take care of the load ordrer as gpmc_cs_request() is exported. And in that case how can gpmc driver rely on DT as gpmc timings for the peripheral requiring retime would not yet be available as peripheral driver is not yet probed, seems like a circular dependency. The DT node should simply have the information required by the retime function or gpmc timings themselves if available. In the case of OneNAND async mode you have a bunch of constants such as ... const int t_cer = 15; const int t_avdp = 12; const int t_cez = 20; /* max of t_cez, t_oez */ const int t_ds = 30; const int t_wpl = 40; const int t_wph = 30 These can be stored in the DT and then translated to gpmc timings at runtime. DT should only store static timing or clock information known at compile time. Yup. And the format of the timing data in DT should be standardized so the only differences for each connected peripheral is the retime function. And in this case, we are going to register retime function, so instead of relying on DT to provide gpmc timings for such a peripheral, won't it be better to make use of retime that is already registered ? No we need to pass the timings from device tree as they may be different for similar boards. For example, different level shifters used on similar boards may affect the timings, although the retime function can be the same. Unless I am missing something, could not see this scenario taken care in the existing retime functions, did see one comment for smc91x, but seems in that case Kernel doesn't do any timing configuration and leave timings as configured by bootloader I think that we just need to adapt the current functions that our calculating the timings so that ... 1. We can call from them within the gpmc probe to setup the timings versus having the peripherals program the gpmc priory to probe. 2. Any static timing information needed by the retime function is part of the platform data passed to the gpmc probe and therefore can also be read from DT. Yup, and also: 3. Disable frequency scaling for L3 if no retime function is specified In that case we may have a generic default function that just sets the boot time values and disables the L3 scaling. From a high-level I think that the goal should be ... gpmc_probe -- request CS -- calls retime function to calculate gpmc timing (optional) -- configures CS -- registers peripheral device Yes with few additions.. Connected peripheral
Re: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
* Jon Hunter jon-hun...@ti.com [120710 10:20]: Hi Afzal, On 07/10/2012 08:47 AM, Mohammed, Afzal wrote: Hi Tony, On Tue, Jul 10, 2012 at 18:47:34, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [120710 03:09]: On Tue, Jul 10, 2012 at 15:15:38, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [120709 23:24]: 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. Were you actually referring to updating kernel view of device tree nodes, and not the device tree file (not sure whether it is really possible) ? I believe that Tony is suggesting performing the retime at probe time. In the case of OneNand you would simply call the onenand_set_async_mode/sync_mode from within the probe as a retime function. Yes there's no need to do it earlier. We can, but would it be feasible practically ?, gpmc timings to update in DT for a such a peripheral (requiring retime) can be found out only by manual calculation similar to the way done in retime function (based on peripheral's timings and boot time gpmc clock period), correct ?, Also wouldn't this make it necessary to know gpmc clock period at boot time for properly updating gpmc timing entry in DT ? The gpmc clock period can be returned to the connected peripheral when it's registering. Well basically we can call the retime function upon registering and pass the gpmc clock period. Won't this lead to the necessity of particular driver load order problem ?, As per the above, to return gpmc clock period to the connected peripheral, we need to ensure that gpmc driver is probed before peripheral driver. I think it is more like when probing the gpmc, the retime function for the connected peripheral is called passing the gpmc clock freq. Right, there's no need to do any of that at gpmc probe time. And the module dependencies take care of the load ordrer as gpmc_cs_request() is exported. And in that case how can gpmc driver rely on DT as gpmc timings for the peripheral requiring retime would not yet be available as peripheral driver is not yet probed, seems like a circular dependency. The DT node should simply have the information required by the retime function or gpmc timings themselves if available. In the case of OneNAND async mode you have a bunch of constants such as ... const int t_cer = 15; const int t_avdp = 12; const int t_cez = 20; /* max of t_cez, t_oez */ const int t_ds = 30; const int t_wpl = 40; const int t_wph = 30 These can be stored in the DT and then translated to gpmc timings at runtime. DT should only store static timing or clock information known at compile time. Yup. And the format of the timing data in DT should be standardized so the only differences for each connected peripheral is the retime function. And in this case, we are going to register retime function, so instead of relying on DT to provide gpmc timings for such a peripheral, won't it be better to make use of retime that is already registered ? No we need to pass the timings from device tree as they may be different for similar boards. For example, different level shifters used on similar boards may affect the timings, although the retime function can be the same. Unless I am missing something, could not see this scenario taken care in the existing retime functions, did see one comment for smc91x, but seems in that case Kernel doesn't do any timing configuration and leave timings as configured by bootloader I think that we just need to adapt the current functions that our calculating the timings so that ... 1. We can call from them within the gpmc probe to setup the timings versus having the peripherals program the gpmc priory to probe. 2. Any static timing information needed by the retime function is part of the platform data passed to the gpmc probe and therefore can also be read from DT. Yup, and also: 3. Disable frequency scaling for L3 if no retime function is specified In that case we may have a generic default function that just sets the boot time values and disables the L3 scaling. From a high-level I think that the goal should be ... gpmc_probe -- request CS -- calls retime function to calculate gpmc timing (optional) -- configures CS -- registers peripheral device Yes with few additions.. Connected peripheral probe requests CS from gpmc with the optional retime function pointer passed as a parameter. After gpmc code has determined the CS is available, it calls the optional retime function before returning back to the connected peripheral probe. So how about the following with a bit more details: gpmc_probe
RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Tony, Could not respond you earlier as was sick On Fri, Jul 06, 2012 at 17:35:33, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [120705 07:56]: On Thu, Jul 05, 2012 at 16:25:35, Tony Lindgren wrote: 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 handled Hmm 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 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 you Well yes the timings should be passed via devicetree in a gpmc specific I assume with the above, you were referring to peripherals that does not have retime function. 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 ? Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
* Mohammed, Afzal af...@ti.com [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: * Mohammed, Afzal af...@ti.com [120705 07:56]: On Thu, Jul 05, 2012 at 16:25:35, Tony Lindgren wrote: 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 handled Hmm 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. 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 you Well yes the timings should be passed via devicetree in a gpmc specific I 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. 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Tony, On Tue, Jul 10, 2012 at 15:15:38, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [120709 23:24]: On Fri, Jul 06, 2012 at 17:35:33, Tony Lindgren wrote: 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. We can, but would it be feasible practically ?, gpmc timings to update in DT for a such a peripheral (requiring retime) can be found out only by manual calculation similar to the way done in retime function (based on peripheral's timings and boot time gpmc clock period), correct ?, Also wouldn't this make it necessary to know gpmc clock period at boot time for properly updating gpmc timing entry in DT ? And in this case, we are going to register retime function, so instead of relying on DT to provide gpmc timings for such a peripheral, won't it be better to make use of retime that is already registered ? Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
* Mohammed, Afzal af...@ti.com [120710 03:09]: Hi Tony, On Tue, Jul 10, 2012 at 15:15:38, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [120709 23:24]: On Fri, Jul 06, 2012 at 17:35:33, Tony Lindgren wrote: 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. We can, but would it be feasible practically ?, gpmc timings to update in DT for a such a peripheral (requiring retime) can be found out only by manual calculation similar to the way done in retime function (based on peripheral's timings and boot time gpmc clock period), correct ?, Also wouldn't this make it necessary to know gpmc clock period at boot time for properly updating gpmc timing entry in DT ? The gpmc clock period can be returned to the connected peripheral when it's registering. Well basically we can call the retime function upon registering and pass the gpmc clock period. And in this case, we are going to register retime function, so instead of relying on DT to provide gpmc timings for such a peripheral, won't it be better to make use of retime that is already registered ? No we need to pass the timings from device tree as they may be different for similar boards. For example, different level shifters used on similar boards may affect the timings, although the retime function can be the same. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Tony, On Tue, Jul 10, 2012 at 18:47:34, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [120710 03:09]: On Tue, Jul 10, 2012 at 15:15:38, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [120709 23:24]: 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. Were you actually referring to updating kernel view of device tree nodes, and not the device tree file (not sure whether it is really possible) ? We can, but would it be feasible practically ?, gpmc timings to update in DT for a such a peripheral (requiring retime) can be found out only by manual calculation similar to the way done in retime function (based on peripheral's timings and boot time gpmc clock period), correct ?, Also wouldn't this make it necessary to know gpmc clock period at boot time for properly updating gpmc timing entry in DT ? The gpmc clock period can be returned to the connected peripheral when it's registering. Well basically we can call the retime function upon registering and pass the gpmc clock period. Won't this lead to the necessity of particular driver load order problem ?, As per the above, to return gpmc clock period to the connected peripheral, we need to ensure that gpmc driver is probed before peripheral driver. And in that case how can gpmc driver rely on DT as gpmc timings for the peripheral requiring retime would not yet be available as peripheral driver is not yet probed, seems like a circular dependency. And in this case, we are going to register retime function, so instead of relying on DT to provide gpmc timings for such a peripheral, won't it be better to make use of retime that is already registered ? No we need to pass the timings from device tree as they may be different for similar boards. For example, different level shifters used on similar boards may affect the timings, although the retime function can be the same. Unless I am missing something, could not see this scenario taken care in the existing retime functions, did see one comment for smc91x, but seems in that case Kernel doesn't do any timing configuration and leave timings as configured by bootloader Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Afzal, On 07/10/2012 08:47 AM, Mohammed, Afzal wrote: Hi Tony, On Tue, Jul 10, 2012 at 18:47:34, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [120710 03:09]: On Tue, Jul 10, 2012 at 15:15:38, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [120709 23:24]: 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. Were you actually referring to updating kernel view of device tree nodes, and not the device tree file (not sure whether it is really possible) ? I believe that Tony is suggesting performing the retime at probe time. In the case of OneNand you would simply call the onenand_set_async_mode/sync_mode from within the probe as a retime function. We can, but would it be feasible practically ?, gpmc timings to update in DT for a such a peripheral (requiring retime) can be found out only by manual calculation similar to the way done in retime function (based on peripheral's timings and boot time gpmc clock period), correct ?, Also wouldn't this make it necessary to know gpmc clock period at boot time for properly updating gpmc timing entry in DT ? The gpmc clock period can be returned to the connected peripheral when it's registering. Well basically we can call the retime function upon registering and pass the gpmc clock period. Won't this lead to the necessity of particular driver load order problem ?, As per the above, to return gpmc clock period to the connected peripheral, we need to ensure that gpmc driver is probed before peripheral driver. I think it is more like when probing the gpmc, the retime function for the connected peripheral is called passing the gpmc clock freq. And in that case how can gpmc driver rely on DT as gpmc timings for the peripheral requiring retime would not yet be available as peripheral driver is not yet probed, seems like a circular dependency. The DT node should simply have the information required by the retime function or gpmc timings themselves if available. In the case of OneNAND async mode you have a bunch of constants such as ... const int t_cer = 15; const int t_avdp = 12; const int t_cez = 20; /* max of t_cez, t_oez */ const int t_ds = 30; const int t_wpl = 40; const int t_wph = 30 These can be stored in the DT and then translated to gpmc timings at runtime. DT should only store static timing or clock information known at compile time. And in this case, we are going to register retime function, so instead of relying on DT to provide gpmc timings for such a peripheral, won't it be better to make use of retime that is already registered ? No we need to pass the timings from device tree as they may be different for similar boards. For example, different level shifters used on similar boards may affect the timings, although the retime function can be the same. Unless I am missing something, could not see this scenario taken care in the existing retime functions, did see one comment for smc91x, but seems in that case Kernel doesn't do any timing configuration and leave timings as configured by bootloader I think that we just need to adapt the current functions that our calculating the timings so that ... 1. We can call from them within the gpmc probe to setup the timings versus having the peripherals program the gpmc priory to probe. 2. Any static timing information needed by the retime function is part of the platform data passed to the gpmc probe and therefore can also be read from DT. From a high-level I think that the goal should be ... gpmc_probe -- request CS -- calls retime function to calculate gpmc timing (optional) -- configures CS -- registers peripheral device Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
* Mohammed, Afzal af...@ti.com [120705 07:56]: Hi Tony, On Thu, Jul 05, 2012 at 16:25:35, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [120705 03:29]: I have a doubt whether we are talking about the same thing, presently our main issue is in eliminating the necessity of peripheral specific functions like gpmc_onenand_init, tusb_setup_interface (which calls tusb6010_platform_retime), etc., which calculate gpmc timings by processing peripheral specific timings over gpmc clock period and these processing were required before gpmc driver probe gets invoked as gpmc driver needed timings which gpmc can understand to configure gpmc. Right. The issue is that both the gpmc clock and the peripheral clock may change, and both cause the need to reprogram the gpmc timings. 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 handled Hmm I don't follow, why can't the timings be set during the peripheral specific driver probe? By we should be able to do it at gpmc level, I am unable to understand what you are suggesting. Right, gpmc should be able to handle things alone with the registered retime function for smsc911x, where the driver does not even know about the bus. With DT, the platform init code gpmc-smsc911x.c should become a driver that registers with gpmc and provides the retime function. So then we would be having two devices drivers to represent gpmc peripheral like smsc911x, one existing ethernet driver and other one for handling gpmc timings, right ?. And with DT, so we need two nodes to represent a gpmc peripheral ? Well ideally we'd have some kind of bus glue setup eventually so we'll have just one device for smsc911x.. But like I said, that part is a bit open still. At least I don't have any clear solution in mind for how to do the bus specific wrapper drivers. So timing information that would be passed from DT should be for exact gpmc timings like cs_on, cs_off etc., right ?, in that case should we manually calculate (like as now done by Kernel in gpmc-onenand.c etc) it by having the knowledge of connected peripheral gpmc frequency at boot time and update it in DT ?, as we can't apply retime on it as we don't know the connected peripheral in gpmc driver. Or do you want another field through DT to decide retime that is to be used, then I think passing timing from DT would not be needed The timings values should be passed to gpmc from DT. We need to be able to pass both cycle and time based values. If no cycle based value is passed, the time based value should be used. This is because some peripheral timings can be cycle based, while others can be time based. If we can describe gpmc timings purely based on time and cycles field for all the peripherals, can we not remove all the retime functions like timing calculation done in gpmc-onenand.c ? No that's probably not enough because the time and cycles for a peripheral may need to be different if the peripheral clock rate changes. 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 you Sorry to trouble you with more questions, I wanted to understand the way you want to deal with the issue. Well yes the timings should be passed via devicetree in a gpmc specific format. But the peripheral specific retime function still needs to be also registered for peripherals that need it. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Tony, On Wed, Jul 04, 2012 at 13:21:59, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [120704 00:05]: On Tue, Jul 03, 2012 at 13:47:47, Tony Lindgren wrote: Yes how about the gpmc using driver code registers itself with the gpmc code and also registers it's retime function with the gpmc? That way the gpmc fck stays inside the gpmc code, and the driver specific retime function should be able to do the calculation based on driver clocks. The retime function needs to have also a pointer to driver private data for it's clocks etc. Sorry, not sure whether I follow you properly, based on what has been understood, will try to rephrase, All the present gpmc timing calculation done in arch/arm/mach-omap2/gpmc-* to be moved to gpmc driver. And all the peripheral drivers using gpmc, i.e like smsc911x, tusb6010 needs to register their retime function with gpmc driver. And gpmc driver will invoke these registered retime function, when clock frequency changes. But wouldn't it need changes in the existing drivers like smsc911x that are used by multiple architectures with gpmc specific registration (put under a macro ?). We will be having gpmc driver code that contains knowledge about peripheral timing calculation, seems there is no way out of this. Peripheral agnostic gpmc code may not happen it seems It depends. For some drivers scaling both gpmc clock and the device clock can happen, like with tusb6010 for example. But the smsc911x does not know about the clocks.. So to additional changes to the driver would be required to if device clocks need scaling. But for now, we should be able to do it at gpmc level with the retime function, or just disable DFS for those clocks if not supported. I have a doubt whether we are talking about the same thing, presently our main issue is in eliminating the necessity of peripheral specific functions like gpmc_onenand_init, tusb_setup_interface (which calls tusb6010_platform_retime), etc., which calculate gpmc timings by processing peripheral specific timings over gpmc clock period and these processing were required before gpmc driver probe gets invoked as gpmc driver needed timings which gpmc can understand to configure gpmc. During boot time, gpmc driver needs to know timings in terms of gpmc parameters to configure gpmc, what I unable to understand from your proposal is how gpmc driver knows which retime function to invoke (so that gpmc timings can be calculated based on the type of peripheral) to calculate gpmc timings. Or do you want a DT field specifying type of peripheral connected and so that at probe time the relevant retime can be invoked ? Initially I thought you were suggesting that all peripheral drivers connected to gpmc should register their retime function (where function will be an exported symbol - part of gpmc code) and invoke the respective retime as part of peripheral driver probe, hence relieve gpmc driver of doing it, even though retime would be present as part of gpmc code. But seems that is not what you were suggesting. By we should be able to do it at gpmc level, I am unable to understand what you are suggesting. In that case gpmc driver probe would have to be relieved of the task of setting up gpmc timings as we have to wait till peripheral drivers register their callback, right ?, seems in that case no timing information needs (or can be) to be passed from DT Well we should pass all the gpmc timing information from DT. And then the driver also still needs to register it's retime function with gpmc. So timing information that would be passed from DT should be for exact gpmc timings like cs_on, cs_off etc., right ?, in that case should we manually calculate (like as now done by Kernel in gpmc-onenand.c etc) it by having the knowledge of connected peripheral gpmc frequency at boot time and update it in DT ?, as we can't apply retime on it as we don't know the connected peripheral in gpmc driver. Or do you want another field through DT to decide retime that is to be used, then I think passing timing from DT would not be needed Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
* Mohammed, Afzal af...@ti.com [120705 03:29]: I have a doubt whether we are talking about the same thing, presently our main issue is in eliminating the necessity of peripheral specific functions like gpmc_onenand_init, tusb_setup_interface (which calls tusb6010_platform_retime), etc., which calculate gpmc timings by processing peripheral specific timings over gpmc clock period and these processing were required before gpmc driver probe gets invoked as gpmc driver needed timings which gpmc can understand to configure gpmc. Right. The issue is that both the gpmc clock and the peripheral clock may change, and both cause the need to reprogram the gpmc timings. During boot time, gpmc driver needs to know timings in terms of gpmc parameters to configure gpmc, what I unable to understand from your proposal is how gpmc driver knows which retime function to invoke (so that gpmc timings can be calculated based on the type of peripheral) to calculate gpmc timings. Or do you want a DT field specifying type of peripheral connected and so that at probe time the relevant retime can be invoked ? The peripheral init code should register it's timings with gpmc, and also register a retime function for the gpmc code to use. Then the timings can eventually come from DT. Initially I thought you were suggesting that all peripheral drivers connected to gpmc should register their retime function (where function will be an exported symbol - part of gpmc code) and invoke the respective retime as part of peripheral driver probe, hence relieve gpmc driver of doing it, even though retime would be present as part of gpmc code. But seems that is not what you were suggesting. Yes that's what I was suggesting. By we should be able to do it at gpmc level, I am unable to understand what you are suggesting. Right, gpmc should be able to handle things alone with the registered retime function for smsc911x, where the driver does not even know about the bus. With DT, the platform init code gpmc-smsc911x.c should become a driver that registers with gpmc and provides the retime function. For some drivers, like tusb6010, also the peripheral clock affects the timings. So both gpmc and the driver may need to be able to call the retime function. In that case gpmc driver probe would have to be relieved of the task of setting up gpmc timings as we have to wait till peripheral drivers register their callback, right ?, seems in that case no timing information needs (or can be) to be passed from DT Well we should pass all the gpmc timing information from DT. And then the driver also still needs to register it's retime function with gpmc. So timing information that would be passed from DT should be for exact gpmc timings like cs_on, cs_off etc., right ?, in that case should we manually calculate (like as now done by Kernel in gpmc-onenand.c etc) it by having the knowledge of connected peripheral gpmc frequency at boot time and update it in DT ?, as we can't apply retime on it as we don't know the connected peripheral in gpmc driver. Or do you want another field through DT to decide retime that is to be used, then I think passing timing from DT would not be needed The timings values should be passed to gpmc from DT. We need to be able to pass both cycle and time based values. If no cycle based value is passed, the time based value should be used. This is because some peripheral timings can be cycle based, while others can be time based. 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. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Tony, On Thu, Jul 05, 2012 at 16:25:35, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [120705 03:29]: Initially I thought you were suggesting that all peripheral drivers connected to gpmc should register their retime function (where Yes that's what I was suggesting. To understand you better, peripheral drivers above refers to driver created out of present gpmc platform init code like gpmc-smsc911x.c. You were not referring to drivers/net/ethernet/smsc/smsc911x.c, right ? Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
* Mohammed, Afzal af...@ti.com [120705 05:03]: Hi Tony, On Thu, Jul 05, 2012 at 16:25:35, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [120705 03:29]: Initially I thought you were suggesting that all peripheral drivers connected to gpmc should register their retime function (where Yes that's what I was suggesting. To understand you better, peripheral drivers above refers to driver created out of present gpmc platform init code like gpmc-smsc911x.c. You were not referring to drivers/net/ethernet/smsc/smsc911x.c, right ? Yes arch/arm/mach-omap2/gpmc-smsc911x.c for now, but eventually that too should probably be just a regular driver. Just how it will work together with drivers/net/ethernet/smsc/smsc911x.c is still a bit open though :) Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Tony, On Thu, Jul 05, 2012 at 16:25:35, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [120705 03:29]: I have a doubt whether we are talking about the same thing, presently our main issue is in eliminating the necessity of peripheral specific functions like gpmc_onenand_init, tusb_setup_interface (which calls tusb6010_platform_retime), etc., which calculate gpmc timings by processing peripheral specific timings over gpmc clock period and these processing were required before gpmc driver probe gets invoked as gpmc driver needed timings which gpmc can understand to configure gpmc. Right. The issue is that both the gpmc clock and the peripheral clock may change, and both cause the need to reprogram the gpmc timings. 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 handled By we should be able to do it at gpmc level, I am unable to understand what you are suggesting. Right, gpmc should be able to handle things alone with the registered retime function for smsc911x, where the driver does not even know about the bus. With DT, the platform init code gpmc-smsc911x.c should become a driver that registers with gpmc and provides the retime function. So then we would be having two devices drivers to represent gpmc peripheral like smsc911x, one existing ethernet driver and other one for handling gpmc timings, right ?. And with DT, so we need two nodes to represent a gpmc peripheral ? So timing information that would be passed from DT should be for exact gpmc timings like cs_on, cs_off etc., right ?, in that case should we manually calculate (like as now done by Kernel in gpmc-onenand.c etc) it by having the knowledge of connected peripheral gpmc frequency at boot time and update it in DT ?, as we can't apply retime on it as we don't know the connected peripheral in gpmc driver. Or do you want another field through DT to decide retime that is to be used, then I think passing timing from DT would not be needed The timings values should be passed to gpmc from DT. We need to be able to pass both cycle and time based values. If no cycle based value is passed, the time based value should be used. This is because some peripheral timings can be cycle based, while others can be time based. If we can describe gpmc timings purely based on time and cycles field for all the peripherals, can we not remove all the retime functions like timing calculation done in gpmc-onenand.c ? 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 you Sorry to trouble you with more questions, I wanted to understand the way you want to deal with the issue. Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Tony, On Tue, Jul 03, 2012 at 13:47:47, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [120702 10:30]: 2. Provide some sort of retime callback that the gpmc driver can call at probe time to calculate the timings. Yes how about the gpmc using driver code registers itself with the gpmc code and also registers it's retime function with the gpmc? That way the gpmc fck stays inside the gpmc code, and the driver specific retime function should be able to do the calculation based on driver clocks. The retime function needs to have also a pointer to driver private data for it's clocks etc. Sorry, not sure whether I follow you properly, based on what has been understood, will try to rephrase, All the present gpmc timing calculation done in arch/arm/mach-omap2/gpmc-* to be moved to gpmc driver. And all the peripheral drivers using gpmc, i.e like smsc911x, tusb6010 needs to register their retime function with gpmc driver. And gpmc driver will invoke these registered retime function, when clock frequency changes. But wouldn't it need changes in the existing drivers like smsc911x that are used by multiple architectures with gpmc specific registration (put under a macro ?). We will be having gpmc driver code that contains knowledge about peripheral timing calculation, seems there is no way out of this. Peripheral agnostic gpmc code may not happen it seems In that case gpmc driver probe would have to be relieved of the task of setting up gpmc timings as we have to wait till peripheral drivers register their callback, right ?, seems in that case no timing information needs (or can be) to be passed from DT It seems this retime function may need to be called by the gpmc code when L3 changes, and the driver code if the driver is switching between runtime and idle clocks like tusb6010 for example does. I believe you are referring to tusb6010_platform_retime(), other than during initial setup, i.e. in tusb6010_setup_interface(), it is not invoked. tusb6010_platform_retime() is an exported symbol, unless I am missing something it is not invoked other than during initial setup. Did find this function in tusb6010.c, it is commented out, may be this was present earlier ? Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
* Mohammed, Afzal af...@ti.com [120704 00:05]: Hi Tony, On Tue, Jul 03, 2012 at 13:47:47, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [120702 10:30]: 2. Provide some sort of retime callback that the gpmc driver can call at probe time to calculate the timings. Yes how about the gpmc using driver code registers itself with the gpmc code and also registers it's retime function with the gpmc? That way the gpmc fck stays inside the gpmc code, and the driver specific retime function should be able to do the calculation based on driver clocks. The retime function needs to have also a pointer to driver private data for it's clocks etc. Sorry, not sure whether I follow you properly, based on what has been understood, will try to rephrase, All the present gpmc timing calculation done in arch/arm/mach-omap2/gpmc-* to be moved to gpmc driver. And all the peripheral drivers using gpmc, i.e like smsc911x, tusb6010 needs to register their retime function with gpmc driver. And gpmc driver will invoke these registered retime function, when clock frequency changes. But wouldn't it need changes in the existing drivers like smsc911x that are used by multiple architectures with gpmc specific registration (put under a macro ?). We will be having gpmc driver code that contains knowledge about peripheral timing calculation, seems there is no way out of this. Peripheral agnostic gpmc code may not happen it seems It depends. For some drivers scaling both gpmc clock and the device clock can happen, like with tusb6010 for example. But the smsc911x does not know about the clocks.. So to additional changes to the driver would be required to if device clocks need scaling. But for now, we should be able to do it at gpmc level with the retime function, or just disable DFS for those clocks if not supported. The ideal solution in the long run would be to have gpmc scaling frequency as the bus and device scaling frequency using cpufreq/devicefreq whatever notifiers. In that case gpmc driver probe would have to be relieved of the task of setting up gpmc timings as we have to wait till peripheral drivers register their callback, right ?, seems in that case no timing information needs (or can be) to be passed from DT Well we should pass all the gpmc timing information from DT. And then the driver also still needs to register it's retime function with gpmc. It seems this retime function may need to be called by the gpmc code when L3 changes, and the driver code if the driver is switching between runtime and idle clocks like tusb6010 for example does. I believe you are referring to tusb6010_platform_retime(), other than during initial setup, i.e. in tusb6010_setup_interface(), it is not invoked. tusb6010_platform_retime() is an exported symbol, unless I am missing something it is not invoked other than during initial setup. Did find this function in tusb6010.c, it is commented out, may be this was present earlier ? Hmm yes looks like it's commented out.. But in theory the retime function should be called between idle clock and runtime clock. And also for DFS, so it's something we should be considered for proper gpmc support. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
* Jon Hunter jon-hun...@ti.com [120702 10:30]: On 07/02/2012 01:36 AM, Tony Lindgren wrote: In general, I doubt that we can come up with better calculations. The existing code pretty well already follows the device spec timings. And using cycle values for some registers is the right thing to do according to the connected device specs no matter what the frequency is. In those cases converting from time values to cycles does not make sense. Ok agree, but the problem here is how to provide the timings to the driver. The onenand code is doing a lot of rounding based upon the gpmc clock before it presents the timings (in nano-seconds) to the gpmc function to calculate the final timings and program the gpmc chip-select. So therefore I think that we have the following options ... 1. The simplest is to continue using a global variable for storing the gpmc f-clk handle and have the OneNAND timings calculated prior to probing the gpmc driver. Well we should not expose gpmc fck handle to the drivers.. 2. Provide some sort of retime callback that the gpmc driver can call at probe time to calculate the timings. Yes how about the gpmc using driver code registers itself with the gpmc code and also registers it's retime function with the gpmc? That way the gpmc fck stays inside the gpmc code, and the driver specific retime function should be able to do the calculation based on driver clocks. The retime function needs to have also a pointer to driver private data for it's clocks etc. It seems this retime function may need to be called by the gpmc code when L3 changes, and the driver code if the driver is switching between runtime and idle clocks like tusb6010 for example does. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
On 07/02/2012 11:35 PM, Mohammed, Afzal wrote:
Hi Jon,
On Mon, Jul 02, 2012 at 22:59:03, Hunter, Jon wrote:
On 07/02/2012 04:43 AM, Mohammed, Afzal wrote:
Not sure whether you are fine with fixing up this patch with added diff
Assuming inferences so far is not wrong, right now this patch with the
added diff
would be perfectly fine.
Problem would happen when we are at a stage to do gpmc reset using hwmod
[seems
miles to go before I sleep {or read gpmc hwmod reset} ;)]. If bootloader
left
onenand configured in sync mode, to switch onenand to async mode, first
configuring
gpmc to sync mode would be required for that we need frequency information
from onenand and to get that information from onenand, gpmc has to be
configured
for sync mode and to configure gpmc to sync mode
You are concerned about hwmod performing a reset of the gpmc during
boot? We should be able to use the HWMOD_INIT_NO_RESET flag to prevent
this. Would that work?
Yes that will work in the short term, the reason I am trying to avoid no
reset flag in the long term is to prevent this board support being broken,
please refer Paul's requirement [1] in accepting gpmc hwmod patch
Ok, thanks for the reminder.
So we have 2 options here ...
1. Use the HWMOD_INIT_NO_RESET for now and your updated version of this
patch
2. See if there is a gpio available to control the OneNAND reset on the
n900.
Do you agree? Any other options?
Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
On 07/03/2012 03:17 AM, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [120702 10:30]: On 07/02/2012 01:36 AM, Tony Lindgren wrote: In general, I doubt that we can come up with better calculations. The existing code pretty well already follows the device spec timings. And using cycle values for some registers is the right thing to do according to the connected device specs no matter what the frequency is. In those cases converting from time values to cycles does not make sense. Ok agree, but the problem here is how to provide the timings to the driver. The onenand code is doing a lot of rounding based upon the gpmc clock before it presents the timings (in nano-seconds) to the gpmc function to calculate the final timings and program the gpmc chip-select. So therefore I think that we have the following options ... 1. The simplest is to continue using a global variable for storing the gpmc f-clk handle and have the OneNAND timings calculated prior to probing the gpmc driver. Well we should not expose gpmc fck handle to the drivers.. Yes, I was hoping we could avoid continuing to do this. 2. Provide some sort of retime callback that the gpmc driver can call at probe time to calculate the timings. Yes how about the gpmc using driver code registers itself with the gpmc code and also registers it's retime function with the gpmc? That way the gpmc fck stays inside the gpmc code, and the driver specific retime function should be able to do the calculation based on driver clocks. The retime function needs to have also a pointer to driver private data for it's clocks etc. It seems this retime function may need to be called by the gpmc code when L3 changes, and the driver code if the driver is switching between runtime and idle clocks like tusb6010 for example does. Seems fine to me. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Jon, Tony, On Tue, Jul 03, 2012 at 20:40:03, Hunter, Jon wrote: So we have 2 options here ... 1. Use the HWMOD_INIT_NO_RESET for now and your updated version of this patch 2. See if there is a gpio available to control the OneNAND reset on the n900. Do you agree? Any other options? Yes agree, I am fine either way, unable to see any other option HWMOD_INIT_NO_RESET is any way required to start driver conversion as both new old interface needs to be supported till all machines are converted to use the new driver interface as well as at least till all machines are made independent of bootloader w.r.t GPMC As of now I feel we should go with option 1 If we need to go with option 2, (assuming OneNAND reset is solution to the problem) all machines that is configured for sync mode presently (n8x0, rx51, rm680) has to be made intelligent to do OneNAND reset (provided gpio is connected to reset). And for all these machines including N900 (seems rx51), information on gpio pin connected to reset (if at all connected) and the way to do reset is required, which I am so far unable to get. Once this information could be obtained, I can make the patch and then need help from someone who has the board to test it Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
On 07/02/2012 01:36 AM, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [120628 09:48]: [2.792510] OneNAND driver initializing [2.797576] omap2-onenand omap2-onenand: initializing on CS2, phys base 0x2000, virtual base c88c, freq 0 MHz [2.808929] OneNAND Manufacturer: Samsung (0xec) [2.808990] Muxed OneNAND 256MB 1.8V 16-bit (0x40) [2.814208] OneNAND version = 0x002c The above change seems to imply that Tony's n900 is dependent on the bootloader settings and not those being set by the kernel. Ideally, we should not need to set the async mode in the onenand before we set the onenand timings in the gpmc (per Afzal's changelog comment). This appears backwards. That should not be the case, I'm more likely to believe in Afzal's explanation. Right I agree with Afzal's explanation now too. The other thing to note is that the 3430sdp has samsung onenand where as the n900 has Numonyx. The gpmc-onenand.c only has one set of settings that it is using for all devices. However, it would appear that at least the async settings are not working for the Numonyx. Therefore, may be we need to get a dump of Tony's n900 settings and make sure the right settings are being used for the appropriate board. Hmm I would assume the n900 onenand settings are the most tested settings we have. And AFAIK have also been tested with L3 frequency scaling. So let's assume they're mostly right. These onenand settings are really killing us. I don't want us to have to spend alot of time re-calculating this stuff but the way it has been written to begin with is not driver friendly. I really wonder if we need to have some sort of callback for the onenand timings from the driver. It is ugly, but the alternative is that someone needs to sit down and re-calculate all the timings again to get them into a driver friendly format. Furthermore, it seems that onenand is no longer available from the likes of samsung and numonyx (micron) so it is hard to justify re-calculating everything again. I am not even sure if we have all the datasheets! Let me know your thoughts. I don't think we should spend much time working on the recalculations. Let's rather use these known working cases as examples. If they don't work, it's likely that adding any new devices won't work either. For the timings, we should allow specifying either cycles or time values in the data struct. And always just use the cycle value directly if specified, and othewise use the time value. We may be able to limit the registers where we need to allow either cycle or time value depending on the device futher. In general, I doubt that we can come up with better calculations. The existing code pretty well already follows the device spec timings. And using cycle values for some registers is the right thing to do according to the connected device specs no matter what the frequency is. In those cases converting from time values to cycles does not make sense. Ok agree, but the problem here is how to provide the timings to the driver. The onenand code is doing a lot of rounding based upon the gpmc clock before it presents the timings (in nano-seconds) to the gpmc function to calculate the final timings and program the gpmc chip-select. So therefore I think that we have the following options ... 1. The simplest is to continue using a global variable for storing the gpmc f-clk handle and have the OneNAND timings calculated prior to probing the gpmc driver. 2. Provide some sort of retime callback that the gpmc driver can call at probe time to calculate the timings. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
On 07/02/2012 04:43 AM, Mohammed, Afzal wrote:
Hi Tony,
On Mon, Jul 02, 2012 at 12:06:51, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [120628 09:48]:
The above change seems to imply that Tony's n900 is dependent on the
bootloader settings
and not those being set by the kernel. Ideally, we should not need to set
the async mode
in the onenand before we set the onenand timings in the gpmc (per Afzal's
changelog
comment). This appears backwards.
That should not be the case, I'm more likely to believe in Afzal's
explanation.
Not sure whether you are fine with fixing up this patch with added diff
Assuming inferences so far is not wrong, right now this patch with the added
diff
would be perfectly fine.
Problem would happen when we are at a stage to do gpmc reset using hwmod
[seems
miles to go before I sleep {or read gpmc hwmod reset} ;)]. If bootloader left
onenand configured in sync mode, to switch onenand to async mode, first
configuring
gpmc to sync mode would be required for that we need frequency information
from onenand and to get that information from onenand, gpmc has to be
configured
for sync mode and to configure gpmc to sync mode
You are concerned about hwmod performing a reset of the gpmc during
boot? We should be able to use the HWMOD_INIT_NO_RESET flag to prevent
this. Would that work?
Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Jon,
On Mon, Jul 02, 2012 at 22:59:03, Hunter, Jon wrote:
On 07/02/2012 04:43 AM, Mohammed, Afzal wrote:
Not sure whether you are fine with fixing up this patch with added diff
Assuming inferences so far is not wrong, right now this patch with the
added diff
would be perfectly fine.
Problem would happen when we are at a stage to do gpmc reset using hwmod
[seems
miles to go before I sleep {or read gpmc hwmod reset} ;)]. If bootloader
left
onenand configured in sync mode, to switch onenand to async mode, first
configuring
gpmc to sync mode would be required for that we need frequency information
from onenand and to get that information from onenand, gpmc has to be
configured
for sync mode and to configure gpmc to sync mode
You are concerned about hwmod performing a reset of the gpmc during
boot? We should be able to use the HWMOD_INIT_NO_RESET flag to prevent
this. Would that work?
Yes that will work in the short term, the reason I am trying to avoid no
reset flag in the long term is to prevent this board support being broken,
please refer Paul's requirement [1] in accepting gpmc hwmod patch
Regards
Afzal
[1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69041.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
* Jon Hunter jon-hun...@ti.com [120628 12:05]: Tony, have you tried using any of the mtd kernel tests to verify OneNAND read/write is working on your n900? For example ... # insmod mtd_pagetest.ko dev=mtd-part-num _NOTE_ that above test erases the OneNAND! ;-) Ehh not thanks. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
* Jon Hunter jon-hun...@ti.com [120628 09:48]: [2.792510] OneNAND driver initializing [2.797576] omap2-onenand omap2-onenand: initializing on CS2, phys base 0x2000, virtual base c88c, freq 0 MHz [2.808929] OneNAND Manufacturer: Samsung (0xec) [2.808990] Muxed OneNAND 256MB 1.8V 16-bit (0x40) [2.814208] OneNAND version = 0x002c The above change seems to imply that Tony's n900 is dependent on the bootloader settings and not those being set by the kernel. Ideally, we should not need to set the async mode in the onenand before we set the onenand timings in the gpmc (per Afzal's changelog comment). This appears backwards. That should not be the case, I'm more likely to believe in Afzal's explanation. The other thing to note is that the 3430sdp has samsung onenand where as the n900 has Numonyx. The gpmc-onenand.c only has one set of settings that it is using for all devices. However, it would appear that at least the async settings are not working for the Numonyx. Therefore, may be we need to get a dump of Tony's n900 settings and make sure the right settings are being used for the appropriate board. Hmm I would assume the n900 onenand settings are the most tested settings we have. And AFAIK have also been tested with L3 frequency scaling. So let's assume they're mostly right. These onenand settings are really killing us. I don't want us to have to spend alot of time re-calculating this stuff but the way it has been written to begin with is not driver friendly. I really wonder if we need to have some sort of callback for the onenand timings from the driver. It is ugly, but the alternative is that someone needs to sit down and re-calculate all the timings again to get them into a driver friendly format. Furthermore, it seems that onenand is no longer available from the likes of samsung and numonyx (micron) so it is hard to justify re-calculating everything again. I am not even sure if we have all the datasheets! Let me know your thoughts. I don't think we should spend much time working on the recalculations. Let's rather use these known working cases as examples. If they don't work, it's likely that adding any new devices won't work either. For the timings, we should allow specifying either cycles or time values in the data struct. And always just use the cycle value directly if specified, and othewise use the time value. We may be able to limit the registers where we need to allow either cycle or time value depending on the device futher. In general, I doubt that we can come up with better calculations. The existing code pretty well already follows the device spec timings. And using cycle values for some registers is the right thing to do according to the connected device specs no matter what the frequency is. In those cases converting from time values to cycles does not make sense. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Tony,
On Mon, Jul 02, 2012 at 12:06:51, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [120628 09:48]:
The above change seems to imply that Tony's n900 is dependent on the
bootloader settings
and not those being set by the kernel. Ideally, we should not need to set
the async mode
in the onenand before we set the onenand timings in the gpmc (per Afzal's
changelog
comment). This appears backwards.
That should not be the case, I'm more likely to believe in Afzal's
explanation.
Not sure whether you are fine with fixing up this patch with added diff
Assuming inferences so far is not wrong, right now this patch with the added
diff
would be perfectly fine.
Problem would happen when we are at a stage to do gpmc reset using hwmod [seems
miles to go before I sleep {or read gpmc hwmod reset} ;)]. If bootloader left
onenand configured in sync mode, to switch onenand to async mode, first
configuring
gpmc to sync mode would be required for that we need frequency information
from onenand and to get that information from onenand, gpmc has to be configured
for sync mode and to configure gpmc to sync mode
Seems like chicken and egg problem.
N900, I believe is board-rx51, could not get proper schematic for onenand
connections, nor do I have the Numonyx datsheet, or the board, hence not
sure whether resetting onenand may resolve the issue. But if you feel that
it is the right solution it would resolve the issue, and if you can let
me know gpio connected (if any) to onenand reset or else some pointers to
achieving it, I can try making a patch to do onenand reset
Regards
Afzal
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Jon, On Fri, Jun 29, 2012 at 19:45:37, Hunter, Jon wrote: On 06/29/2012 01:15 AM, Mohammed, Afzal wrote: I have a different opinion, even with the existing code, with the default timings for onenand, Numonyx is working in async mode, reason being that frequency is being obtained with read operation executed in async mode (later based on this frequency, code calculates sync timings then set to sync mode) I don't follow frequency is being obtained with read operation executed in async mode. Can you give a code reference? In the present code, for sync mode, omap2_onenand_set_sync_mode() invokes omap2_onenand_set_async_mode() initially, to set onenand gpmc to async mode, then invokes omap2_onenand_get_freq() to get frequency, here finding out frequency from onenand is done by reading relevant onenand register in async mode. Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Tony, Jon, On Thu, Jun 28, 2012 at 22:13:37, Hunter, Jon wrote: On 06/28/2012 07:32 AM, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [120628 02:36]: On Wed, Jun 27, 2012 at 20:28:45, Tony Lindgren wrote: The last patch in this series causes onenand not to show up on my n900. I believe the problem has been there earlier too, but I just did not notice it. Yes that seems to do the trick, thanks! I can fold that into the breaking patch when applying. I am not sure what to make of this. Testing Afzal's this series along with the other gpmc-prep series [1], onenand is working fine on my 3430sdp and I see ... [2.792510] OneNAND driver initializing [2.797576] omap2-onenand omap2-onenand: initializing on CS2, phys base 0x2000, virtual base c88c, freq 0 MHz [2.808929] OneNAND Manufacturer: Samsung (0xec) [2.808990] Muxed OneNAND 256MB 1.8V 16-bit (0x40) [2.814208] OneNAND version = 0x002c The above change seems to imply that Tony's n900 is dependent on the bootloader settings and not those being set by the kernel. Ideally, we should not need to set the async mode In one of the Samsumg onenand datasheet, it was mentioned, (seems Numonyx datasheet is under NDA) [A] If device is accessed synchronously, while set to asynchronous read mode, it is possible to read out first data without problems It seems even though above may not imply the below, chances are that below would be true [B] If device is accessed asynchronously, while set to synchronous read mode, it will not be possible to read out data And B seems logical(to me); if onenand is set to synchronous mode, it would expect clocks to transfer data which may not happen with asynchronous operation from gpmc. Here the problem with Tony's n900 (expecting it to use one of mach-id in n8x0, hence flag sync read) board may be that bootloader (could not find uboot handling these machines) before handing over control to Kernel, sets it to synchronous mode. And then if we apply B, we can expect what we are seeing here. Assuming above is a explanation to what Tony is observing on n900, perhaps, resetting onenand may help Kernel work even without the proposed diff. There is a gpio pin field used in n8x0, if that is connected to reset of onenand, may be it can achieve what we want without the diff. Numonyx. The gpmc-onenand.c only has one set of settings that it is using for all devices. However, it would appear that at least the async settings are not working for the Numonyx. Therefore, may be we need to get a dump of Tony's n900 settings and make I have a different opinion, even with the existing code, with the default timings for onenand, Numonyx is working in async mode, reason being that frequency is being obtained with read operation executed in async mode (later based on this frequency, code calculates sync timings then set to sync mode) This change indeed has brought to our notice one instance where Kernel can't handle gpmc by itself, may be resetting onenand is a solution, as it seems bootloader is leaving it in sync mode. Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Afzal, On 06/29/2012 01:15 AM, Mohammed, Afzal wrote: Hi Tony, Jon, On Thu, Jun 28, 2012 at 22:13:37, Hunter, Jon wrote: On 06/28/2012 07:32 AM, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [120628 02:36]: On Wed, Jun 27, 2012 at 20:28:45, Tony Lindgren wrote: The last patch in this series causes onenand not to show up on my n900. I believe the problem has been there earlier too, but I just did not notice it. Yes that seems to do the trick, thanks! I can fold that into the breaking patch when applying. I am not sure what to make of this. Testing Afzal's this series along with the other gpmc-prep series [1], onenand is working fine on my 3430sdp and I see ... [2.792510] OneNAND driver initializing [2.797576] omap2-onenand omap2-onenand: initializing on CS2, phys base 0x2000, virtual base c88c, freq 0 MHz [2.808929] OneNAND Manufacturer: Samsung (0xec) [2.808990] Muxed OneNAND 256MB 1.8V 16-bit (0x40) [2.814208] OneNAND version = 0x002c The above change seems to imply that Tony's n900 is dependent on the bootloader settings and not those being set by the kernel. Ideally, we should not need to set the async mode In one of the Samsumg onenand datasheet, it was mentioned, (seems Numonyx datasheet is under NDA) [A] If device is accessed synchronously, while set to asynchronous read mode, it is possible to read out first data without problems It seems even though above may not imply the below, chances are that below would be true [B] If device is accessed asynchronously, while set to synchronous read mode, it will not be possible to read out data And B seems logical(to me); if onenand is set to synchronous mode, it would expect clocks to transfer data which may not happen with asynchronous operation from gpmc. Here the problem with Tony's n900 (expecting it to use one of mach-id in n8x0, hence flag sync read) board may be that bootloader (could not find uboot handling these machines) before handing over control to Kernel, sets it to synchronous mode. And then if we apply B, we can expect what we are seeing here. Ok, that is a good point. However, there is also the possibility that the OneNAND is in async mode and after changing the gpmc async timings writes are no longer working. Although, it that was the case then maybe we would never be able to switch to sync mode again. So may be it is more likely that it is in sync mode. A dump of the gpmc registers should tell us. Assuming above is a explanation to what Tony is observing on n900, perhaps, resetting onenand may help Kernel work even without the proposed diff. There is a gpio pin field used in n8x0, if that is connected to reset of onenand, may be it can achieve what we want without the diff. Numonyx. The gpmc-onenand.c only has one set of settings that it is using for all devices. However, it would appear that at least the async settings are not working for the Numonyx. Therefore, may be we need to get a dump of Tony's n900 settings and make I have a different opinion, even with the existing code, with the default timings for onenand, Numonyx is working in async mode, reason being that frequency is being obtained with read operation executed in async mode (later based on this frequency, code calculates sync timings then set to sync mode) I don't follow frequency is being obtained with read operation executed in async mode. Can you give a code reference? Frequency of the OneNAND is not important for async mode (as only sync mode uses a clock), only the gpmc clock frequency is important for calculating the timings. For async mode the OneNAND timings are static. For configuring the async timings the code does not distinguish between different OneNAND devices and therefore, assumes that the async timings are the same for all devices. I cannot believe that a Samsung and Numonyx device would have identical async timings. However, if the timings are not optimal there is a chance they could work for all devices. This change indeed has brought to our notice one instance where Kernel can't handle gpmc by itself, may be resetting onenand is a solution, as it seems bootloader is leaving it in sync mode. It would be an interesting test. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Tony, On Wed, Jun 27, 2012 at 20:28:45, Tony Lindgren wrote: The last patch in this series causes onenand not to show up on my n900. I believe the problem has been there earlier too, but I just did not notice it. Sorry for the delayed response, could reach workplace a short while ago only Could the diff [1] be tried and check whether it resolves the issue, Regards Afzal [1] diff --git a/arch/arm/mach-omap2/gpmc-onenand.c b/arch/arm/mach-omap2/gpmc-onenand.c index c8a9487..bbae674 100644 --- a/arch/arm/mach-omap2/gpmc-onenand.c +++ b/arch/arm/mach-omap2/gpmc-onenand.c @@ -364,6 +364,8 @@ static int omap2_onenand_setup_async(void __iomem *onenand_base) struct gpmc_timings t; int ret; + omap2_onenand_set_async_mode(onenand_base); + t = omap2_onenand_calc_async_timings(); ret = gpmc_set_async_mode(gpmc_onenand_data-cs, t); -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
* Mohammed, Afzal af...@ti.com [120628 02:36]: Hi Tony, On Wed, Jun 27, 2012 at 20:28:45, Tony Lindgren wrote: The last patch in this series causes onenand not to show up on my n900. I believe the problem has been there earlier too, but I just did not notice it. Sorry for the delayed response, could reach workplace a short while ago only Could the diff [1] be tried and check whether it resolves the issue, Regards Afzal [1] diff --git a/arch/arm/mach-omap2/gpmc-onenand.c b/arch/arm/mach-omap2/gpmc-onenand.c index c8a9487..bbae674 100644 --- a/arch/arm/mach-omap2/gpmc-onenand.c +++ b/arch/arm/mach-omap2/gpmc-onenand.c @@ -364,6 +364,8 @@ static int omap2_onenand_setup_async(void __iomem *onenand_base) struct gpmc_timings t; int ret; + omap2_onenand_set_async_mode(onenand_base); + t = omap2_onenand_calc_async_timings(); ret = gpmc_set_async_mode(gpmc_onenand_data-cs, t); Yes that seems to do the trick, thanks! I can fold that into the breaking patch when applying. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Tony, On Thu, Jun 28, 2012 at 18:02:07, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [120628 02:36]: Yes that seems to do the trick, thanks! I can fold that into the breaking patch when applying. Relieved, thanks Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Tony, On Thu, Jun 28, 2012 at 18:02:07, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [120628 02:36]: diff --git a/arch/arm/mach-omap2/gpmc-onenand.c b/arch/arm/mach-omap2/gpmc-onenand.c index c8a9487..bbae674 100644 --- a/arch/arm/mach-omap2/gpmc-onenand.c +++ b/arch/arm/mach-omap2/gpmc-onenand.c @@ -364,6 +364,8 @@ static int omap2_onenand_setup_async(void __iomem *onenand_base) struct gpmc_timings t; int ret; + omap2_onenand_set_async_mode(onenand_base); + t = omap2_onenand_calc_async_timings(); ret = gpmc_set_async_mode(gpmc_onenand_data-cs, t); Yes that seems to do the trick, thanks! I can fold that into the breaking patch when applying. Also following needs to be removed from commit message, Ensuring sync read/write are disabled in onenand cannot be expected to work properly unless GPMC is setup, this has been removed. With the above diff we are in effect disabling sync mode in onenand before GPMC has been setup in the Kernel If you want, I can sent a new series too. Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Tony, Afzal, On 06/28/2012 07:32 AM, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [120628 02:36]: Hi Tony, On Wed, Jun 27, 2012 at 20:28:45, Tony Lindgren wrote: The last patch in this series causes onenand not to show up on my n900. I believe the problem has been there earlier too, but I just did not notice it. Sorry for the delayed response, could reach workplace a short while ago only Could the diff [1] be tried and check whether it resolves the issue, Regards Afzal [1] diff --git a/arch/arm/mach-omap2/gpmc-onenand.c b/arch/arm/mach-omap2/gpmc-onenand.c index c8a9487..bbae674 100644 --- a/arch/arm/mach-omap2/gpmc-onenand.c +++ b/arch/arm/mach-omap2/gpmc-onenand.c @@ -364,6 +364,8 @@ static int omap2_onenand_setup_async(void __iomem *onenand_base) struct gpmc_timings t; int ret; + omap2_onenand_set_async_mode(onenand_base); + t = omap2_onenand_calc_async_timings(); ret = gpmc_set_async_mode(gpmc_onenand_data-cs, t); Yes that seems to do the trick, thanks! I can fold that into the breaking patch when applying. I am not sure what to make of this. Testing Afzal's this series along with the other gpmc-prep series [1], onenand is working fine on my 3430sdp and I see ... [2.792510] OneNAND driver initializing [2.797576] omap2-onenand omap2-onenand: initializing on CS2, phys base 0x2000, virtual base c88c, freq 0 MHz [2.808929] OneNAND Manufacturer: Samsung (0xec) [2.808990] Muxed OneNAND 256MB 1.8V 16-bit (0x40) [2.814208] OneNAND version = 0x002c The above change seems to imply that Tony's n900 is dependent on the bootloader settings and not those being set by the kernel. Ideally, we should not need to set the async mode in the onenand before we set the onenand timings in the gpmc (per Afzal's changelog comment). This appears backwards. The other thing to note is that the 3430sdp has samsung onenand where as the n900 has Numonyx. The gpmc-onenand.c only has one set of settings that it is using for all devices. However, it would appear that at least the async settings are not working for the Numonyx. Therefore, may be we need to get a dump of Tony's n900 settings and make sure the right settings are being used for the appropriate board. These onenand settings are really killing us. I don't want us to have to spend alot of time re-calculating this stuff but the way it has been written to begin with is not driver friendly. I really wonder if we need to have some sort of callback for the onenand timings from the driver. It is ugly, but the alternative is that someone needs to sit down and re-calculate all the timings again to get them into a driver friendly format. Furthermore, it seems that onenand is no longer available from the likes of samsung and numonyx (micron) so it is hard to justify re-calculating everything again. I am not even sure if we have all the datasheets! Let me know your thoughts. Cheers Jon [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg70096.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Tony, Afzal, On 06/28/2012 11:43 AM, Jon Hunter wrote: Hi Tony, Afzal, On 06/28/2012 07:32 AM, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [120628 02:36]: Hi Tony, On Wed, Jun 27, 2012 at 20:28:45, Tony Lindgren wrote: The last patch in this series causes onenand not to show up on my n900. I believe the problem has been there earlier too, but I just did not notice it. Sorry for the delayed response, could reach workplace a short while ago only Could the diff [1] be tried and check whether it resolves the issue, Regards Afzal [1] diff --git a/arch/arm/mach-omap2/gpmc-onenand.c b/arch/arm/mach-omap2/gpmc-onenand.c index c8a9487..bbae674 100644 --- a/arch/arm/mach-omap2/gpmc-onenand.c +++ b/arch/arm/mach-omap2/gpmc-onenand.c @@ -364,6 +364,8 @@ static int omap2_onenand_setup_async(void __iomem *onenand_base) struct gpmc_timings t; int ret; + omap2_onenand_set_async_mode(onenand_base); + t = omap2_onenand_calc_async_timings(); ret = gpmc_set_async_mode(gpmc_onenand_data-cs, t); Yes that seems to do the trick, thanks! I can fold that into the breaking patch when applying. I am not sure what to make of this. Testing Afzal's this series along with the other gpmc-prep series [1], onenand is working fine on my 3430sdp and I see ... [2.792510] OneNAND driver initializing [2.797576] omap2-onenand omap2-onenand: initializing on CS2, phys base 0x2000, virtual base c88c, freq 0 MHz I realised that the above print showing 0 MHz is another clue as to why the above change is needed for the n900. It is printing 0 MHz because the OMAP3430 SDP does not support sync read or write. The frequency is only queried during the configuration of the sync mode timings and not the async. I had just submitted a 2 patch series to fix this so that is displays the correct frequency for all boards [1]. If you agree with my changes may be we can include them in Afzal's series. However, more importantly with my fix, I now see that the frequency supporting by the OneNAND on the SDP is 66MHz. On Tony's n900 it shows 83MHz. The timings for async mode are hard-coded in the gpmc-onenand.c and it does not have different timings for different devices and different frequencies. Hence, this is probably why the async timings in the gpmc-onenand.c do not work for the n900. The problem is that unlike nand, where it is clear which boards were dependent on the bootloader timings, for onenand it really is not 100% clear. Some boards support ONENAND_SYNC_READWRITE and so these are not using the async timings. However, the n8x0 appears only to use sync read. Does the n900 use the same settings as the n8x0? Tony, have you tried using any of the mtd kernel tests to verify OneNAND read/write is working on your n900? For example ... # insmod mtd_pagetest.ko dev=mtd-part-num _NOTE_ that above test erases the OneNAND! ;-) Cheers Jon [1] http://marc.info/?l=linux-omapm=134090910321284w=2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
* Afzal Mohammed af...@ti.com [120626 23:53]: Reorganize gpmc-onenand initialization so that changes required for gpmc driver migration can be made smooth. Ensuring sync read/write are disabled in onenand cannot be expected to work properly unless GPMC is setup, this has been removed. Refactor set_async_mode set_sync_mode functions to separate out timing calculation actual configuration (GPMC OneNAND side). The last patch in this series causes onenand not to show up on my n900. I believe the problem has been there earlier too, but I just did not notice it. Without the last patch in this series I get: [1.650207] OneNAND driver initializing [1.655487] omap2-onenand omap2-onenand: initializing on CS0, phys base 0x0400, virtual base d088, freq 83 MHz [1.666931] OneNAND Manufacturer: Numonyx (0x20) [1.671905] Muxed OneNAND 256MB 1.8V 16-bit (0x40) [1.676971] OneNAND version = 0x0031 [1.918762] Creating 6 MTD partitions on omap2-onenand: And with this patch applied I get: [1.634643] OneNAND driver initializing [1.640075] omap2-onenand omap2-onenand: initializing on CS0, phys base 0x0400, virtual base d088, freq 54 MHz [1.651519] OneNAND Manufacturer: Unknown (0xa0) Any ideas? Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
