[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121114084931.GA31837@avionic-0098.mockup.avionic-design.de>
Date: Wed, 14 Nov 2012 09:49:31 +0100
From: Thierry Reding <thierry.reding@...onic-design.de>
To: Terje Bergström <tbergstrom@...dia.com>
Cc: Stephen Warren <swarren@...dotorg.org>,
"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 10:35:31AM +0200, Terje Bergström wrote:
> On 09.11.2012 15:20, Thierry Reding wrote:
> > This commit adds the host1x node along with its children to the Tegra20
> > DTSI. Furthermore the OF auxiliary data table is updated to have proper
> > names assigned to the platform devices instantiated from the device
> > tree. Moreover, the clocks required by host1x and the two display
> > controllers are initialized and the pll_d frequency table is completed
> > with a few entries to support common HDMI and LVDS display modes.
>
> I tried to add nvhost on top of your patches and I noticed a glitch.
>
> > + { "host1x", "pll_c", 144000000, false },
>
> This line causes host1x not to operate correctly. I don't know why this
> is so, but when I try to initialize host1x, it hangs with this change,
> but everything works without this line.
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.
Thierry
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists