Re: [PATCH 3/3] ARM: OMAP2+: gpmc: handle additional timings

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

 



* Mohammed, Afzal <afzal@xxxxxx> [120614 23:20]:
> Hi Tony,
> 
> On Fri, Jun 15, 2012 at 11:12:46, Mohammed, Afzal wrote:
> 
> > But I am unable to find reason for failure upon using
> > gpmc_ticks_to_ns(1), which seems to me right thing to be used.
> > Let me try to invoke tusb6010 functions in beagle board,
> > observe timings so that at least I will get an idea
> > what is going on here (even though it is guaranteed to crash)
> 
> Checked simulating on beagle board, I am at total loss to
> understand why using gpmc_ticks_to_ns(1) has failed for n8x0
> 
> clk_activation timings with both values as follows,
>  
> [1] With t.clk_activation = gpmc_ticks_to_ns(1);
> 
> GPMC CS4: clk_activation:   1 ticks,   6 ns (was   0 ticks)   6 ns
> 
> [2] With t.clk_activation = 1;
> 
> GPMC CS4: clk_activation:   1 ticks,   6 ns (was   0 ticks)   1 ns
> 
> Last field show in ns the time we are trying to set,
> and for both cases, 1 ticks are being programmed in register.

Yes tired it again it is working correctly. I must have messed up
something yesterday when manually patching the clk_activation, maybe
I put the clk_activation value into async timings instead as I was
seeing the tick value set to 0 for the sync mode.

So looks OK to me, n800 tusb6010 and onenand behave as earlier,
also onenand on n900 seems to get detected as earlier.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

  Powered by Linux