linux-kernel - Re: [PATCH 1/2] ARM: tegra: Add Tegra20 host1x support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 14 Nov 2012 21:04:15 +0100
From:	Thierry Reding <thierry.reding@...onic-design.de>
To:	Stephen Warren <swarren@...dotorg.org>
Cc:	Terje Bergström <tbergstrom@...dia.com>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] ARM: tegra: Add Tegra20 host1x support

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

Content of type "application/pgp-signature" skipped