Hi Jon,
On Tue, Aug 28, 2012 at 02:00:13, Hunter, Jon wrote:
On 08/27/2012 05:37 AM, Mohammed, Afzal wrote:
And at least for initial users, they are expected to have
some grasp on how to calculate timings, such a user will
not be much worried about your 3 concerns above, anyway as
of
Hi Jon,
On Thu, Aug 23, 2012 at 08:28:44, Hunter, Jon wrote:
On 08/21/2012 05:45 AM, Afzal Mohammed wrote:
+/* can the cycles be avoided ? */
What is the above comment referring too?
This was added in the initial stages and refers to the usage of
cycles in struct gpmc_device_timings. I
Hi Tony,
On Sat, Aug 25, 2012 at 01:24:47, Tony Lindgren wrote:
Yes agreed. Also as some values make sense only in cycles, converting them
back and forth to time is wrong. So at least some values should have an
option to specify them in cycles directly, and then ignore any time based
values.
Hi Afzal,
On 08/27/2012 05:37 AM, Mohammed, Afzal wrote:
On Thu, Aug 23, 2012 at 08:28:44, Hunter, Jon wrote:
[snip]
I understand that this is based upon how timings for onenand and tusb
are being calculated today, but I am not sure that this is the way to go
for all devices. Personally, I
* Jon Hunter jon-hun...@ti.com [120822 19:58]:
So although this may consolidate how the timings are calculated today, I
am concerned it will be confusing to add timings for a new device. At
least if I am calculating timings, I am taking the timing information
for the device and translating
Hi Afzal,
On 08/21/2012 05:45 AM, Afzal Mohammed wrote:
Presently there are three peripherals that gets it timing
by runtime calculation. Those peripherals can work with
frequency scaling that affects gpmc clock. But timing
calculation for them are in different ways.
Here a generic runtime
Presently there are three peripherals that gets it timing
by runtime calculation. Those peripherals can work with
frequency scaling that affects gpmc clock. But timing
calculation for them are in different ways.
Here a generic runtime calculation method is proposed. Input
to this function were
