On Wed, Nov 14, 2012 at 09:19:17AM -0700, Stephen Warren wrote: > On 11/14/2012 03:54 AM, Thierry Reding wrote: > > On Wed, Nov 14, 2012 at 12:23:42PM +0200, Terje Bergström wrote: > >> On 14.11.2012 10:49, Thierry Reding wrote: > >>> Can you find out how the host1x clock is setup without this > >>> change? I was told that freezes can occur when you try to > >>> access the registers without the host1x clock being enabled. > >>> However, the host1x driver should take care to properly setup > >>> the clock. > >>> > >>> To find out if the non-running clock is the issue, can you try > >>> to patch that line and make the final element true instead of > >>> false? That should enable the clock on boot so that it should > >>> always be running. > >> > >> I tried with fastboot and U-Boot, and whenever that line is > >> there, kernel boot will halt at nvhost init. Same happens if I > >> just change the false to true. > >> > >> nvhost will enable the clock and disable as it need. Also, part > >> of host1x initialization did proceed, but it ended up hanging > >> after a few registers were initialized. So it's not a case of > >> host1x being off, but host1x hanging after a while. > >> > >> If I change this line to: > >> > >> { "host1x", "pll_p", 216000000, false }, > >> > >> it will also work properly. It looks like we have some problem > >> with pll_c in Tegra20, or clock configuration with your patch. In > >> Tegra30, pll_c with 144MHz seems to work fine, but on Tegra20, it > >> doesn't. > >> > >> In internal kernel, we use pll_c for host1x, so hardware > >> shouldn't be the problem here. > > > > I suppose that if things work properly without this line, then we > > should probably just drop it. Stephen, any objections? > > I'd rather initialize it explicitly. If setting it to 216MHz works > fine as Terje indicated, we may as well just do that. > > I suspect the issue with the original code: > > > { "host1x", "pll_c", 144000000, false }, > > ... is that perhaps the requested 144MHz can't be generated from > pll_c's 600MHz rate, since there's a simple U7.1 divider there (you > could get 120, 133.333, 150), so the clock ends up being programmed to > some incorrect value. In the pll_p/216MHz case, pll_p is programmed to > generate 216MHz anyway, so requesting the same rate for host1x yields > a divider of 1 exactly which works fine. According to tegra20_clocks_data.c, the maximum clock frequency for host1x is 166 MHz, so 216 is probably not a good idea. 150 MHz sounds sensible, though. I was going to send a new version of the patch set tonight, but I'll wait until I can test it tomorrow and once Terje has reported back that things work fine. Thierry
Attachment:
pgpxzswT03Si6.pgp
Description: PGP signature